Думаю, многие были в такой ситуации, когда каналы данных разрываются от бешеного количества алертов, находя нас, где бы мы ни были — когда мы едим, спим, в дороге или в душе. Когда мы уже боимся любого звука, который исходит от телефона. Когда уведомления — это белый шум, который мешает, а не помогает находить проблемы в инфраструктуре.

Но статья будет не про сравнение систем мониторинга или методов, а про простые практики, которые каждый из вас может применить. Про здравый смысл в применении этих практик. И про опыт ЦФТ — про те боль и проблемы, с которыми столкнулась компания, как их решала и к чему в итоге пришла. Эта история о том, как перестроить процессы внутри компании, чтобы мониторинг перестал быть стихийным и стал актуальным и управляемым.

Нормально делай — нормально будет, и Виталий Медведев, инженер по автоматизации ЦФТ, разделяет эту истину. Эта статья написана по его выступлению на конференции Saint HighLoad 2021.

Лет 7 назад в ЦФТ произошла крупная трансформация процессов. Но мониторинг не успел за изменениями, и инженеров завалило огромное количество ложных алертов. Собравшись с силами, они объявили крестовый поход, героическими усилиями всё исправили и какое-то время могли спать спокойно.

Но потом прошла следующая волна трансформации, и всё повторилось снова. Конечно, был объявлен второй крестовый поход, в котором снова всё героически исправили. Тем не менее пару лет назад, когда ситуация повторилась в третий или четвертый раз, стало понятно, что крестовые походы не работают. Нужен был процесс, чтобы гибко реагировать на изменяющуюся ситуацию и держать ее под контролем. 

Для решения проблем сначала нужно было определиться с целями.

Цели

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

Какие основные проблемы при этом нужно было решить?

Проблемы

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

Много ложных оповещений. Флаппающие алерты, которые были когда-то критичными, перестали таковыми быть. Их становится много, и среди этого шума теряются уведомления с действительно высоким уровнем критичности, на которые нужно обязательно отреагировать. От этого инженеры сильно устают, это вызывает отвращение к работе. Ребята просто ждут, чтобы закончилось дежурство и этот огромный поток сообщений начал разбирать кто-нибудь другой. Это очень плохо!

Не знаем, что с этим делать. Бывают ситуации, когда в три часа ночи приходит уведомление: например, что в очереди с непонятным названием-аббревиатурой скопилось 150 сообщений — но что это значит? Что за очередь, где она находится — в каком-то брокере или в какой-то базе? С алертом, тем не менее, нужно разбираться, а значит — искать, кто может помочь, и звонить ему. Он может оказаться в отпуске и посылает нас к другому, и так по цепочке дежурный будит от трех до пяти человек. 

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

Низкое качество правил. Всё это складывается из того, что чаще всего качество правил мониторинга достаточно низкое. Функционал скорее выносится на продакшн, внедряются новые технологии, в том числе и что-то от комьюнити — набор метрик или правил — но почти всегда в них что-то нужно тюнить. Очень редко бывают ситуации, когда они нам полностью подходят и срабатывают только по делу. Это одна проблема.

Вторая проблема — ожидание, что раз обложились всеми метриками и создали все алерты, которые только возможны, то они просто будут приходить, а дежурные — постепенно их разгребать. Но нет. Пока  исправляется одно, загорается с другой стороны.

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

Но почему эти проблемы проявились?

Причины

В первую очередь, в ЦФТ изменились процессы разработки и поставки. Раньше было, условно говоря, «два монолита и три хоста», а потом появились новый стек, Kubernetes и множество кластеров. После изменений процессов вырос штат разработчиков и количество команд, но ops’ы остались в том же количестве. Времени у дежурных на всё перестало хватать. Хотя задач и работы никогда меньше не станет, и нужно в любом случае откуда-то это время найти, чтобы инженеры смогли разобрать все задачи.

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

Вместе с мониторингом менялось и всё остальное: появлялись и исчезали новые сервисы, хосты, кластеры. Старого статичного состояния с несколькими известными не стало, а новое с множеством неизвестных нужно было как-то дискаверить. Все постоянно меняется и будет меняться — в ЦФТ больше не было правил, которые неизменны всегда.

Итак, проблемы были описаны, причины найдены, а цели сформулированы — осталось только всё реализовать.

Трансформация

Что касается двух первых причин, то это очень обширная тема. ЦФТ посвятил ей два доклада на весеннем HighLoad++ 2021:

• Flux, flux и в production. Доклад про инструменты, которые используются, чтобы стандартизировать поставку сервисов на продакшн и дать время отделу эксплуатации на развитие.

• 500 Dev vs 10 Ops. Этот доклад о процессе взаимодействия между командами, некая эволюция DevOps. По мотивам доклада была также статья на Хабре.

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

Время для дежурных

На тот момент в команде дежурных инженеров в ЦФТ сложилось несколько ролей. Каждый дежурный на заявках на одну неделю выходил заниматься только операционкой: простейшими инструкциями, как создать пользователя или выдать права. Это достаточно мелкие задачи, которые надо просто взять и сделать, поэтому постоянно отвлекать всех в отделе на такую работу было бы неправильно.

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

Что здесь не так? Дело было в том, что заявки хоть и были простыми, но их было много — и могло так случиться, что после очередного этапа изменений в процессах их становилось еще больше. А еще была «сезонность»: в понедельник люди запланировали, что будут делать всю неделю и к среде-четвергу начинали дружно выкатывать версии. И у дежурного в понедельник было 10 заявок, в среду уже 30, а в четверг — 50. 

Понятно, что основное решение здесь — автоматизировать всё, что можно. Но это не всегда можно сделать быстро, и параллельно с автоматизацией первым шагом поменяли дежурства местами:

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

ОК, тогда реорганизовали так:

Одну неделю от проектных задач передали в работу над мониторингом, чтобы за неделю дежурному можно было спокойно почистить все «хвосты». Если на решение было нужно больше недели, то она переводилась в проекты, которыми дежурный займется в соответствующую неделю. И это сработало.

После реорганизации дежурства осталось «самое простое» — взять стихийный мониторинг, который пять лет развивался сам собой, и привести его в порядок.

Мониторинг

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

Аналитика и отчёты

Сначала инженеры использовали встроенные средства из имеющихся нескольких систем мониторинга. Чтобы агрегировать всю собранную информацию, пришлось написать свой сервис. Очень простой — система мониторинга отправляла дежурному уведомление и одновременно — JSON в сервис. Сервис парсил JSON — вытаскивал оттуда время, название алерта, о чем он и его уровень критичности, откуда он пришел — и складывал всю информацию в SQL-таблицу:

Как только это всё визуализировали в Grafana, сразу стало понятно, что буквально 3-4 алерта генерят порядка тысячи уведомлений в месяц. Что достаточно исправить только их, чтобы вместо тысячи уведомлений получить тридцать, сократив на два порядка «белый шум».

Категоризация алертов

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

Для категоризации, во-первых, выделили отдельный severity, и поменяли его у всех алертов. Этот severity был не минимальным, но близким к максимальному, то есть он приходил по большому количеству каналов, чтобы не пропустить что-то реально критичное, замаскированное под уровень info. И дальше каждую неделю дежурные распределяли эти алерты: из отчета по этому severity брали ТОП-10 и исправляли.

Через 10 недель в отчете не осталось ни одного уведомления с таким severity, а оставшиеся распределили вручную. На весь процесс ушло три месяца, и все правила были приведены в порядок с точки зрения категоризации.

Еженедельная встреча

Основными в новом процессе стали еженедельные встречи  вечером каждый понедельник. Они были необходимы, хотя никто не любит встречи, потому что они отвлекают от работы. 

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

На первую встречу вместо запланированного часа ушло полтора, потому что у каждого было свое мнение и все считали свой взгляд на то, как должен быть устроен мониторинг, самым правильным: «Эти метрики нужны! Эти алерты вообще необходимы! Я помню, как их настраивал, потому что без них мы не можем жить!»

Но на следующих встречах инженеры поняли, каких правил и соглашений по поводу мониторинга внутри отдела они сами хотят придерживаться, и все обсуждения стали проходить гораздо быстрее. Последняя встреча заняла 7 минут: «Это делаем так и так, а новые мониторинги вот такие. Работаем!» — и разошлись.

Очень полезно стало также обсуждать на таких встречах задачи, стоящие в работе. Так происходил обмен знаниями, потому что сложность систем в ЦФТ становилась всё больше, и один человек уже не мог знать, что происходит везде. Если срабатывал неизвестный алерт, на встрече можно было выяснить, что с ним делать, либо встретиться отдельно, если остальные об этом алерте уже знали.

Runbooks

Конечно, базы знаний, документация — это всё существует и ведётся. Но с ними есть небольшой нюанс. Чаще всего там слишком «много букв» — официальная документация продукта может выдать десятки разделов, сотни или тысячи статей, ссылок и комментариев — как найти нужную информацию? Во внутренней документации может быть всего 3 страницы информации, но в три часа ночи и этого будет слишком много.

Для лучшего понимания, что делать с алертом — внедрили Runbooks. В них кратко и просто написали, о чём уведомление. Но не описание вида: «В очереди скопилось 100 сообщений» (спасибо, капитан, я это и так понимаю из текста сообщения). Нет, там было описано: «Очередь находится в Rabbit, связана с таким-то сервисом, нужна для того и того».

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

Или приходит алерт: «Через 2 часа произойдет заполнение диска и Elasticsearch перейдет в read-only». Инженер знает, что посмотреть, но может не помнить команд, а открыв Runbook, может получить их. В Runbooks не должно быть простыней, только конкретные и простые вещи. 

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

Казалось бы, простые вещи. Мы читаем о них в статьях и думаем: «Да-да!» — и никогда не делаем. Инженерам ЦФТ это наконец надоело, и они это реализовали. Это просто, но это работает.

Гарантийный срок 

В самом начале становления этого процесса алерты менялись пачками: у этих десяти поменяли критичность, а у тех пяти — изменили правила. Но получалось несправедливо, когда один инженер вроде бы поправил, но оно не исправилось — а разбирался должен уже следующий дежурный. Поэтому добавили гарантийный срок в 30 дней с того момента, как была закончена работа над каким-то правилом мониторинга.

Почему 30 дней? Если алерт частый, то он за это время сработает, и вы быстро его исправите. Если нечастый или был не учтен пограничный случай, то через 30 дней тот, кто его правил, ничем не отличается от инженера, который сейчас дежурит. Ему так же придется вспоминать, о чем речь, поднимать информацию и изучать ее. Поэтому 30 дней — достаточный срок. Это тоже было просто, но сработало хорошо: повысилось качество правил, которые инженеры сами создают и меняют. 

Культура проведения плановых работ 

Десять лет назад плановые работы в ЦФТ проводились глубоко ночью. Всё останавливалось (в том числе и мониторинг) вручную, все быстро выполняли работы и поднимали сервисы. 

Теперь есть сотни нод и балансировщики, которые всё сами балансируют, а Kubernetes сам всё поднимает и апдейтит. И на плановых работах  нужно не забывать отключать мониторинг, чтобы 20-30 алертов не падали на голову дежурному инженеру. Хорошо, если он знает о плановых работах. А если он ничего не знает, то это будет беда для его нервной системы. Это тоже просто — вы работаете в команде, уважайте своих коллег, проводите плановые работы с отключением мониторинга.

Также редко кто руками что-то катит. Обычно это скрипты, тулзы и прочее. Но добавьте в них автоматическое отключение алертов, чтобы они сами гасились, если всё включилось — и дежурным не будут приходить ненужные уведомления.

Автоматизация

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

Результаты

В апреле 2020 года инженерам приходило 11 тысяч уведомлений — это 300 с лишним в день! По новому процессу они начали работать летом того же года, и результат был практически сразу — в три раза снизилось количество уведомлений, которые получает дежурный:

При этом в первую очередь пропали флаппающие мониторинги, которые чаще всего и срабатывают. Инженеры стали спать ночью, потому что приходило только то, что реально сломалось. Правда, первые несколько дней некоторые не могли спать, потому что думали, что мониторинг сломался: «Ничего не приходит!» Но к хорошему быстро привыкаешь.

Бонусы

Бонусом инженеры получили, во-первых, разбор техдолга — он начал понемногу сам собой разгребаться. Во-вторых, улучшился обмен знаниями. На встречах становилось понятно, что происходит и зачем внедрялись какие-то мониторинги. Для новых сотрудников это очень полезно. В тех же Runbooks теперь есть краткие и понятные вещи. Уровень осведомленности вырос, а пресловутый bus factor уменьшился.

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

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

Выводы

Не недооценивайте аналитику. Это тот инструмент, который поможет в любой ситуации. Сделайте отчеты и сразу станет понятно, в чем проблема, куда копать, и как ее решить.

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

Не бойтесь объёмов и не усложняйте. Соберитесь с духом, не стройте ракет, но простыми способами шаг за шагом исправляйте ситуацию. Тем более, что вы не одни. У вас в команде есть другие люди, которых  эта ситуация тоже бесит, и они с радостью вам помогут. Без людей ничего не получится — даже если вы нарисуете красивый процесс и всё автоматизируете, без пользователей системы ничего не заработает.

Культура внутри команды – путь к успеху. Если у вас в команде с культурой здорово, то всё у вас получится. И спать вы будете как Том.

Видео выступления Виталия Медведева на конференции Saint HighLoad 2021:

В Онтико работа кипит, мы приближаемся к главному событию весны – конференции HighLoad++ Foundation. Планируйте свое участие — расписание уже на сайте. Вас ждут интересные и полезные доклады от спикеров, нетворкинг, безумство на стендах партнеров, а также крутые спецпроекты. Полный список тем и тезисов смотрите на нашем сайте.

Встречаемся 17 и 18 марта в Москве в Крокус Экспо!