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

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

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

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

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

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

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

Тут в статье для терминов «инцидент» и «инцидент‑менеджмент» мы используем определения, принятые в 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, там разработчики довольно оперативно и доброжелательно могут дать наводку на интересующую вас информацию.

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

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

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

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

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

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

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

Комментарии (2)


  1. 1nd1go
    27.03.2024 02:27

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

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


    1. banet1k Автор
      27.03.2024 02:27

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