IMPulse — наш взгляд на менеджмент инцидентов

Если ваша компания всё ещё не использует средства для менеджмента инцидентов, а утопает в обычных алертах из Alertmanager’а, эта статья для вас. Если ваша компания из-за санкций или соображений безопасности не может отправлять алерты в зарубежные системы менеджмента инцидентов, эта статья для вас. Если вы DevOps и уже изрядно намучились с поиском подобного решения (как я) — статья и для вас тоже.

В статье мы презентуем наше open source решение для работы с алертами.

Приглашаю всех заинтересованных под кат.

Начало

О важности мониторинга писать не буду, ведь мы на Хабре, но вот софт для менеджмента инцидентов используют далеко не все компании.

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

Таким образом софт для менеджмента инцидентов делает алертинг вашим помощником и союзником, а не надоедливым раздражителем.

В своей работе я чувствовал необходимость в подобном софте, знал о существующих cloud решениях, но только в начале этого года впервые столкнулся с открытой реализацией такого софта, Grafana OnCall.

Конечно же, я бы не взялся за реализацию альтернативного решения, если бы меня всё устроило в существующем. В IMPulse мы закрыли те проблемы, которые мешали работать с OnCall, наверняка создали какие-то свои и двигаемся дальше. В конце статьи будет сравнение OnCall и нашего решения.

IMPulse. Подходы и принципы

KISS

В компании Prometheus сделали очень качественный и надёжный софт, и наша задача состоит в том, чтобы максимально приблизиться по стабильности работы к их решениям.

Для этого мы стараемся как можно лучше оптимизировать наши небольшие ресурсы, выбрасываем всё лишнее и неэффективное, оставляем нужное.

Мы придерживаемся подхода KISS и стараемся делать всё настолько просто, насколько это возможно. Однако, если простота скрывает детали мониторинга, мы отдаём предпочтение открытости и деталям, не перегружая лишней информацией.

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

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

IaC

На наш взгляд без IaC сейчас нельзя и поэтому IMPulse полностью разворачивается с помощью кода. Вся конфигурация содержится в переменных окружения и одном конфигурационном YML файле. Складывайте IMPulse в систему менеджмента конфигураций и разворачивайте автоматически. Вам не нужно ничего дополнительно настраивать, чтобы получить полностью готовую к работе конфигурацию. 

Лучшие практики

Мы сознательно «воруем» устоявшиеся хорошие решения. Так, роутинг алертов максимально похож на тот, что используется в Alertmanager, с некоторым необходимым упрощением. В случае, если ваша конфигурация роутинга алертов росла долгие годы и сейчас насчитывает сотни строк кода, такой подход значительно упростит переход с Alertmanager’а на IMPulse. В других местах конфигурации вы также увидите знакомые подходы.

Прямолинейность

Чтобы наиболее эффективно взаимодействовать с неприятным миром алертов, на наш взгляд, система менеджмента инцидентов должна быть максимально понятной. Чтобы достичь этого мы в IMPulse стараемся использовать везде одни и те же понятия, даже если это чуть снижает привлекательность. Если в рамках файла конфигурации impulse.yml вы определили, что алерт должен уведомить группу пользователей (user_group) с названием ‘Jedies’, ровно это вы увидите потом в треде по инциденту:

В случае если роутинг у вас был по ошибке настроен некорректно, это упростит поиск проблемы.

IMPulse. Ключевые особенности

Уведомления и интеграции

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

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

В качестве альтернативного мы оставили только один способ уведомлений, webhook. Он достаточно гибок и вы сможете настроить дополнительные интеграции через него. Помимо отправки самого запроса через webhook, IMPulse также напишет в треде, какой webhook был отправлен и код ответа от сервера:

В документации есть примеры работы со звонками в Twilio.com и Zvonok.com.

Жизненный цикл инцидентов

Одна из проблем, которая меня раздражала в OnCall, — это большое количество инцидентов и, соответственно, уведомлений. Возникает она потому что многие алерты имеют плавающий характер: он то в статусе “firing”, то в статусе “resolved”. И каждое такое переключение создаёт новый инцидент в OnCall, хотя это не новая, а всё та же проблема. И закапываясь во всё новых инцидентах, отслеживать изначальную проблему становится сложнее.

Мы решили эту проблему архитектурно. В IMPulse у инцидентов существует жизненный цикл:

Мы не закрываем инциденты сразу после получения статуса “resolved”, а ждём заданное время и закрываем уже после, устанавливая статус closed. Таким образом не создаются лишние инциденты, не создаются цепочки уведомлений по ним и нагрузка на инженеров снижается. Пример такого инцидента:

По отдельным алертам количество создаваемых инцидентов падает на порядок. Подробности работы этого механизма есть в документации.

unknown

Помимо статуса “closed”, мы также добавили важный статус “unknown”.

Alertmanager имеет настройки, которые обязывают его переотправлять состояние алерта независимо от того изменилось оно или нет. В свою очередь мы в IMPulse рекомендуем устанавливать соответствующие временные интервалы, в течение которых алерт считается актуальным. В случае, если спустя это время IMPulse не получит обновление по алерту от Alertmanager’а, он выставит статус “unknown”. Этот статус говорит о том, что в связке Alertmanager’а и IMPulse’а есть проблема. Например, это возможно если IMPulse становится по какой-то причине недоступен для Alertmanager’а или же умирает Alertmanager. Также этот статус вы увидите, если поставите на алерте silence. Получается, такая дополнительная двусторонняя проверка, что проблем с мониторингом нет. Подробнее об этом написано в документации.

При появлении у инцидента такого статуса, будут уведомлены администраторы IMPulse’а (опция application.admin_users) таким образом:

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

---

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

Сравнение с Grafana OnCall

Отсутствие лишних Incident’ов

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

IaC

Возможность полностью конфигурировать IMPulse через файл сильно экономит время как при первоначальном развёртывании, так и при поддержке системы менеджмента инцидентов в актуальном состоянии.

UI

В OnCall крайне неудобно создавать длинные списки маршрутизации + глючит прокрутка этого списка. Проблемы UI у нас решены радикально: в IMPulse его нет.

Ответственность администраторов

В OnCall способы уведомления настраиваются самими дежурными и если для дежурных это не основная деятельность, а дополнительная, они могут сделать это некорректно.

В IMPulse за конфигурацию цепочек уведомлений и route’ов отвечают в первую очередь администраторы (admin_users). Они же получат уведомления, если что-то идёт не так. Этот подход помогает не распылять ответственность на всех и выстраивает для бизнеса понятную иерархию ответственности.

Группа юзеров

Благодаря наличию user_group, в IMPulse можно уведомить нескольких человек одновременно одним сообщением. В этом случае каждый из них получит только одно уведомление. Так это выглядит в Slack’е:

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

KISS

В отличие от OnCall, в IMPulse нет Celery, нет RabbitMQ, нет Redis, нет базы данных, Docker по желанию. Это позволяет минимизировать затраты на настройку и гарантировать, что весь этот букет технологий не развалится в ответственный момент. Также это нас приводит к следующему пункту.

Потребление ресурсов

На продакшене, где сейчас используется IMPulse, при одинаковых конфигах и нагрузке, контейнер IMPulse занимает 45 MB оперативной памяти против суммарных 1400 MB у всех контейнеров OnCall.

CPU IMPulse потребляет также в 20-40 раз меньше.

Mattermost

Помимо Slack, мы поддерживаем self-hosted мессенджер Mattermost, а также его клонов (например TiMe).

Ссылки

Если вам интересен наш продукт, но не хватает интеграций, пожалуйста, проголосуйте за интересующие здесь. Если не хватает какого‑то функционала — можно написать здесь. Замечания по релизам — здесь. Всё взаимодействие в GitHub мы ведём на английском языке.

Заключение

У данной статьи есть две задачи.

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

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

Спасибо за внимание!