Привет, меня зовут Иван, я инцидент‑менеджер в Сравни. Давайте обсудим, как добавить системности в мониторинг проблем на продакшене — поговорим об инцидент‑менеджменте.

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

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

Давайте поговорим, как подойти к вопросу мониторинга методологически — задействовать инструментарий инцидент‑менеджмента. Обсудим, как оценивать критичность сервисов и какие системы могут быть полезны для отслеживания проблем.

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

Что-то сломалось — о чём именно речь? 

«На проде проблемы» — такую фразу можно услышать от коллег о совершенно разных вещах.

Тут в статье для терминов «инцидент» и «инцидент‑менеджмент» мы используем определения, принятые в ITIL и ITSM (вот неплохая вводная статья от Atlassian).

В рамках такого подхода выделяют следующие категории инцидентов:

• деградация производительности;

• частичная недоступность;

• полная недоступность;

• нарушение безопасности хранения данных.

На пальцах всё более‑менее понятно, но как только идёшь договариваться о процессах, кто‑то кому‑то начинает быть что‑то должен, могут возникнуть вопросы из серии «А точно ли оно нужно?».

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

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

• Незаработанные деньги — если сервис недоступен, люди склонны переставать нам за него платить; хотим этого избежать.

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

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

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

Ок, представим, что все со всеми договорились, и у нас есть «зелёный свет» на инцидент‑менеджмент — давайте поговорим о первых шагах.

Инцидент-менеджмент: с чего начать

В нашем случае первые шаги выглядели следующим образом:

• найти крайнего ответственного;

• рассказать всем, что именно будет происходить;

• обойти все команды.

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

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

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

Ключевая часть анонса: договориться о параметрах мониторинга.

Мы выбрали следующие:

• критичность сервиса для бизнеса;

• есть ли дежурные;

• как зависит от внутренних сервисов;

• какие есть зависимости от внешних сервисов.

Для критичности мы выделили три уровня:

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

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

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

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

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

Зависимость от внешних сервисов — прописываем и перепроверяем, что у нас обязательно есть контакты с той стороны, с явным SLA для времени реакции на наши запросы.

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

У нас в Сравни есть правило: в среднем по компании время uptime для сервиса должно быть 95%. Но в разных командах есть свои нюансы, мы попросили всех лишний раз обсудить с бизнесом, чтобы всех всё устраивало.

Инструменты инцидент-менеджмента

Договоренности с коллегами и внешними контрагентами — сложная часть дела, но не единственная сторона вопроса, где что‑то может пойти не так. Для инцидент‑менеджмента важно аккуратно настроить соответствующий тулинг, и тут, как водится, есть свои нюансы.

Наши основные инструменты для мониторинга: Apdex, Sloth, Grafana OnCall. Давайте расскажу о них чуть подробнее.

Apdex

Application Performance Index (Apdex) — это стандартизированный показатель, который дает простую и понятную оценку эффективности работы приложения с точки зрения пользователей.

Для нас это инструмент, который показывает работу наших сервисов по шкале от 0 до 1, где 0 — «сервису совсем плохо», 0.5–0.75 — «сервису в целом ок, но может быть и лучше», 1 — «сервис чувствует себя замечательно». Детектируются ошибки, а также скорость ответа на запросы, время отклика сервисов.

Из нюансов: прикрутить Apdex получится только к ручкам, у которых >1 RPS. Для <1 RPS, вместо Apdex мы смотрим на их Error Rate (отношение количества нормальных ответов к количеству ошибок).

Sloth

Service Level Objectives (SLO) — цель по уровню обслуживания, которая определяет ожидаемое качество и производительность сервиса. Sloth — инструмент на базе Prometheus, который упрощает и стандартизирует создание SLO, делая этот процесс более быстрым, простым и надежным.

С его помощью мы можем посмотреть, как сервис чувствует себя в ретроспективе. Кроме этого, инструмент включает в себя поддержку создания дашбордов для Grafana, что делает мониторинг и анализ SLO удобнее и доступнее.

Тут тоже не обошлось без нюансов. Если вы уже подключили Apdex, то вам не составит труда подключить Sloth. Если работа с Apdex не настроена, то придется писать кастомные запросы на специальном языке для Grafana.

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

Grafana OnCall

Здесь чеклист по настройке:

1. Завести команду людей по работе с инцидентами.

2. Добавить членов команды — всех, кого хотим привлекать к взаимодействию с инцидентами.

3. Создать расписание дежурств.

4. Задать правила эскалации — в каких случаях достаточно прислать дежурному оповещение в условный Telegram, а когда нужно звонить СТО на телефон.

5. Включить интеграции — в нашем случае все алерты прилетают в общий канал в рабочем мессенджере.

6. Связать алерты с правилами эскалации.

Прилетающие в рабочий мессенджер алерты у нас выглядят вот так:

Интеграция Grafana OnCall с Jira

Интеграция с таск‑трекером настраивается в интерфейсе Grafana OnCall с помощью вебхука (вот инструкция).

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

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

Инцидент-менеджмент: необходимое и достаточное условия 

Но ведь есть же компании, которые живут без инцидент‑менеджмента и ничего, как‑то справляются?

Это правда. Вопросы «а точно ли нам нужно?» и «если да, то когда начинать?» — во многом лежат в плоскости верхнеуровневых принципов ИТ‑команды.

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

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

Как оно будет в вашем случае — перепроверьте в культуре ИТ‑команды. Каким бы ни было отношение к инцидент‑менеджменту, про сами инциденты хочется пожелать всем, чтобы случались пореже!

Расскажите в комментариях — как у вас устроен процесс работы с инцидентами — есть выделенные люди на такие задачи, какими инструментами пользуетесь, как оцениваете критичность сервисов?