Заметки с тегом «Инфраструктура»

С 2018 года я публично ругаю привычку многих админов тащить с собой ИТ-инфраструктуру: поднимать локальные GitLab и Sentry, использовать собственные сервисы вместо PaaS, DBaaS и прочих -aaS. Вот пост об анализаторах логов и огородиках, с которого всё началось.

После 24 февраля меня стали спрашивать, насколько поменялось моё отношение к внешним сервисам, многие из которых в один момент взяли и перестали обслуживать (российскую) часть своих пользователей. Попробую ответить.

В использовании заёмной инфраструктуры всегда есть риски. Текущие события — всего лишь один из большого количества рисков: подводные лодки рвут морские кабели, бандиты вламываются в датацентры, а ваш поставщик услуг просто молча отваливается на две недели. Вообще, все наши ИТ-шные риски — это тоже только часть угроз, которые нависают на бизнесом: есть ещё финансовые, правовые и репутационные риски.

Когда бизнес только-только открывается, рисков — куча: у собственника нет денег на дорогих юристов и программистов, не получается собрать финансовую подушку (а та, что получилась, лежит в том же банке, что и основной счёт). Компания может просто не попасть в рынок, или на этот рынок придёт условный Яндекс заберёт себе клиентов через новый Яндекс.Всё.

По мере роста владельцы защищаются от рисков — нанимают больше профессионалов, забирают себе больше инфраструктуры, выходят на другие рынки, чтобы диверсифицировать бизнес. Точно такая же картина и с SaaS-ами. Если вы стартап — у вас по прежнему нет ресурсов на операционную поддержку собственных огородиков. По мере роста вы становитесь всё более и более независимы. Когда дорастаете до Амазона — строите собственные датацентры.

После 24 февраля поменялся только набор SaaS — больше нет Mailchimp, Slack или продуктов Atlassian. Но у всех этих сервисов есть менее крупные аналоги, которые продолжают работать с русскими. Да и отечественный производитель не отстаёт — у большинства сервисов уже есть замены. И пусть эти замены обычно выглядят как жигули, и от езды на них болит спина — они всё равно снимают с бизнеса огромное количество нагрузки: вам не нужно мониторить серверы, обновлять версии ПО, разбираться в протоколах взаимодействия сервисов друг с другом.

Так что огородики — это норм, если вы можете себе позволить не есть огурцы с рынка. А если не можете — для вас картина сильно не поменялась.

Ложные срабатывания — это бич большинства самодельных систем мониторинга, которые я встречал. Ложное срабатывание — это когда живым людям приходит алёрт, хотя система находится в работоспособном состоянии или хотя бы может вылечить сама себя.

Вот дежурите вы он-колл в выходные, с друзьями на шашлыках. Вам приходит сообщение — «сайт упал». Аларм! Бросаете все дела, залезаете на самую высокую берёзу и видите, что по графикам всё норм. Система решила, что сайт упал, потому что сервер один раз не ответил вашей пинговалке из заббикса. Будете ли вы и дальше доверять сообщениям такого мониторинга? Уже гораздо меньше. А если получите ещё пару СМС в тот же день — то и вообще перестанете. Если такие сообщения будут приходить каждый день — уведомления со временем превратятся в белый шум.

Или представьте, что вам на почту или в слак каждый день падают сообщения о десятке новых ошибок в Сентри. Даже если среди них есть одно важное, которое касается кода, который вы вчера задеплоили, вряд ли вы его увидите, потому что мимо вас прошла сотня-другая мусорных писем.

Если формулировать общее правило — ложные срабатывания дискредитируют всю вашу систему алёртов, как в басне про Мальчика и волков. Если ваша система сыпет мусором — смело вырубайте все уведомления от неё: всё равно никто из вашей команды их не читает, даже если и делает вид.

Дайте людям привыкнуть к тишине, а затем потихоньку вводите алёрты, в которых вы уверены на 100%.

Вот упал у вас прод, вы заходите по ssh и видите, что Load Average в 10 раз больше, чем количество ядер. Люди не могут воспользоваться сервисом, партнёры задают вопросы, а всё, что вы знаете, — это то, что нагрузка выше номинальной. Где именно, из-за чего всё это случилось — непонятно.

Вы залезаете в консоль, ищете по логам (медленно, сервер-то перегружен), запускаете ps и strace, совершаете другие шаманские действия. Чувствуете, что двигаетесь по тёмному лесу с закрытыми глазами, как бегуны из старого клипа Pendulum.

Выход простой — сделайте себе нормальные органы чувств. Заведите  дашборды, которые покажут 4 золотых сигнала (время ответа, количество запросов, рейт ошибок и запас нагрузки) и ТОП-10 самых нагруженных эндпоинтов (отдельно по количетву запросов, отдельно — по затраченному машинному времени). 4 сигнала заменяют кучу производных метрик и позволяют однозначно сказать, лежит ли прод:

ТОП-10 запросов декомпозирует проблему из «упал прод» в «у нас тормозит эндпоинт деталей товара». Теперь легко локализовать источник — если увеличилось количество запросов, то ищем, того, кто их делает. Если запросов столько же, а нагрузка выросла — ищем, что поменялось в коде, или какие проблемы у нас могут быть на внешних ресурсах: базе данных, кеше или партнёрских API. Во втором случае здорово помогает разобрать поток выполнения — у каждого запроса, который обработал сервер, мы записываем трейс, в котором видно, сколько времени приложение потратило на каждую активность, а затем визуализируем это примерно вот так:

Такая работа с цифрами и статистикой называется APM — App Performance Management. Мой любимый сервис для APM — Datadog. Я выбрал его когда-то за хороший дизайн: Datadog не просто даёт инструменты, которые собирают цифры, но и подсвечивает и объясняет самые важные из них.

Если у вас есть хоть какой-то продакшн, который до сих пор не обложен цифрами — прикрутите к нему APM. Не хотите Датадог —  есть куча конкурентов: New Relic, AppDynamics, AppOptics, Elastic APM.

Один из ботов, которых мы активно используем в Гитхабе ГдеМатериала — stale. Задача бота очень простая — приходить в каждый пулл-реквест, в котором ничего не происходит.

Вот к примеру сделал я ПР, который немного улучшает кодовую базу. Хотел показать коллегам-разработчикам, и забыл — так пулл-реквест и остался висеть. Бизнес-стейкхолдера у задачи нет, поэтому никто, кроме меня, про неё не напомнит. Или пришёл бизнес с задачей, мы её начали делать, задали пару вопросов — а нам никто не отвечает.

Бот приходит в такие задачи и напоминает, что ничего не происходит. Если работа по задаче не активизируется — закрывает задачу.

Жёсткий автомат формирует в голове тупое правило: забиваешь на свою работу — значит её выкидывают. Такое правило здорово помогает всем отвечать друг-другу вовремя.

Наш бот не совсем политкорректный — ведь незавершённая работа это так плохо:

Если вы задаетесь этим вопросом, значит вам — не нужен.

Проблема докера — в пороге вхождения. Уметь докер — это как уметь HTML: чтобы его применить, нужно учить еще вагон технологий: CSS, JS, и еще бекенд желательно. У докера этот вагон состоит минимум из swarm (а лучше k8s), чтобы запускать контейнеры, prometheus, чтобы их мониторить, и кучи самописных скриптов, чтобы все это деплоить.

Такие сложности имеют смысл, когда ваша команда дорастает до разделения на разработку и эксплуатацию, или вы начинаете БЫСТРО масштабироваться. Тогда докер становится удобным языком общения между командами и хорошим помощником, чтобы моментально поднимать инфраструктуру на любой площадке.

Если вы до этого еще не доросли, то используйте докер «как все» — чтобы быстро разворачивать куски инфраструктуры на машине разработчика.

Триггеры, когда действительно пора задуматься про докер:

У вас появился выделенный тестировщик. Тестировщикам нужно окружение для каждой новой задачи. Если задача упала тестировщику — рядом с ней должна лежать ссылка на песочницу, в которой ее можно потыкать.

Вы раскладываете код больше, чем на одну машину. Большинство провайдеров позволяют строить на своей базе достаточно мощные виртуалки, и по началу действует модель масштабирования, при которой вы просто разносите сервисы по разным хостам. Когда единственного сервера с приложениями становится мало, вот тогда пора добавлять докер.

Ни в коем случае не стоит добавлять докер, если вы хотите просто автоматизировать деплой — даже если у вас десяток сервисов, без него будет проще. Если надоело вручную настраивать сервера — тоже не стоит, лучше освойте какой-нибудь Ansible.

Сначала эта заметка вышла на моем телеграм-канале. Подписывайтесь, чтобы читать быстрее и больше.