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

Раньше вели документ в Confluence, который заполняли руками – но решение так себе, ибо 90% инцидентов просто решали без добавления записей о них.

Захотелось как-то навести порядок, ввести более адекватный Incidents Management (IcM), и вообще автоматизировать это дело.

Для отправки уведомлений кроме Prometheus Alertmanager, который шлёт уведомления в Slack, мы используем OpsGenie, который шлёт уведомления в мобильное приложение и выполняет звонок бота. Кроме того, в нём есть возможность создавать Incidents, которым и решил воспользоваться.

Причём, создавать их можно как вручную (см. Manual Incident Creation) так и автоматически при срабатывании алерта, см. Automate Incident Creation.

Сами Incidents по сути являются продвинутыми алертами: в них можно вносить комментарии, апдейты по процессу фикса, отправлять уведомления и так далее.

Документация тут>>>, но местами устаревшая. Однако, у OpsGenie отличная поддержка и все вопросы можно решить в минуты через чатик.

Содержание

Alerts notifications rules

И в целом хочется пересмотреть систему нашего алертинга: сейчас у нас Prometheus Alertmanager шлёт алерты уровня WARNING и CRITICAL в Slack и OpsGenie, см. Prometheus: OpsGenie и Alertmanager — уведомления в почту/SMS/телефон и Prometheus: роутинг алертов в Alertmanager.

OpsGenie в свою очередь алерты уровня Critical шлёт в почту + выполняет звонок держурному инженеру.

Вместо этого сделаем иначе – Prometheus будет слать алерты прямо в OpsGenie и только, а уже OpsGenie будет выполнять отправку в Slack через Slack-интеграцию (по интеграции OpsGenie и Slack будет отдельный пост.).

Нужно это для того, что бы через интеграцию OpsGenie с другими системами (Logz.io, Instana, AWS CloudWatch, Jenkins) иметь единую точку отправки алертов.

Т.е. мы сначала собираем все алерты в самом OpsGenie, а потом уже его настройки определяют, что делать с алертом – проигнорировать, отправить сообщение только в Slack, если это Warning, или отправить в Slack + отправить на почту + позвонить держурному + создать инцидент.

При этом из Slack можно сразу установить Acknowledge для алерта.

Incidents Management processes

Как говорил один хороший человек – “Процессы прежде утилит“, поэтому сначала опишите процессы – кто, как и за что отвечает, процесс рекции на инциденты.

Я набросал черновик, который включает в себя:

Roles

В Roles пока описаны только две роли: Incident Commander – “вечный дежурный”, главное ответсвенное лицо, и OnCall duty – наша DevOps team, чередуются через день по расписанию в OpsGenie.

Incidents severity

В Incidents severity описаны уровни важности – от P5 (Info) до P1 (Critical) в зависимости от влияния события на бизнесс-процессы и процессы разработки приложений.

Например, уровень P1 может означать, что затронуты конечные пользователи наших приложений – они не могут совершать покупки или полноценно пользоваться приложением. Тут может быть затронут API-бекенд, к которому обращаются мобильные клиенты, или падение AWS-сервиса, того же RDS, к которому обращается приложение API-бекенда.

P2, более низкий – влияет на процессы разработки. К примеру – падение Jenkins, что приводит к простою в билдах-деплоях. Уровень высокий, т.к. это тоже business-value, но не такой критичный, как влияние на конечных пользователей.

Ну а самый нижний уровень P5 – просто Info/Debug сообщения типа “На Dev-кластере Kubernetes какой-то под ушёл в постоянный рестарт”.

Incident domains

Области инцидентов. К ним потом можно будет “замапить” Services из OpsGenie (Сервисы рассмотрим ниже).

Пока в виде черновика выглядит так:

Почитать:

OpsGenie – включение Incidents

Как подключить:

Opsgenie is included in all cloud plans of Jira Service Management – если вы пользуетесь Jira Service Management, то OpsGenie там уже есть
Opsgenie is available as a standalone offering – купить отдельно (есть бесплатный доступ, но он очень ограничен, мы пользуемся Standart)

У нас возникла проблема из-за того, что наш аккаунт OpsGenie покупался давно, ещё до покупки OpsGenie компанией Atlassian, и у нас не было Incidents в панели вообще.

Что бы активировать их – надо перевести аккаунт из Legace Subscriptions в Atlassian Subscriptions.

Для этого идём в управление подписками и просто выбираем Standart ещё раз:

План поменяется со следующего биллинг-периода, но через обращение в Саппорт можно переключить сразу

Теперь Инциденты должны быть доступны.

Настройка OpsGenie Services

Инциденты привязаны к конкретным Services, т.н. Service-Aware Incident Management, поэтому начнём с создания такого Сервиса.

В роли Сервиса может выступать часть инфрастуктуры (например – AWS RDS, или весь AWS), какая-то утилита, к примеру система сборки и деплоя типа Jenkins, или ваше приложение, в нашем случае это может быть API-бекенд наших мобильных приложений.

Сначала создаём Service, а для этого сервиса настраиваются Rules, Responders и Stakeholders.

Rules: описывают правила, по которым создаются Инциденты. Кроме того, эти Правила потом используются для проверки статуса Сервиса – выводят список связанных с этим сервисом Алертов.
Responders: ответственные за работу этого Сервиса, которым будут отправляться уведомления о новых Инцидентах, связанных с этим Сервисом.
Stakeholders: условно говоря люди, которые этим Сервисом пользуются. Им можно будет отправлять апдейты во время работы над инцидентом.

Создание Service

Переходим в Services:

Кликаем Add service, создадим Сервис для нашего Jenkins.

В Owner team указываем группу, ответственную за этот сервис. Но в нашем OpsGenie всего одна команда DevOps, так что везде будет фигурировать она:

Для настройки Rules и прочего – кликаем на Team settings:

В Service relationship можем связать несколько сервисов.

К примеру, у нас будет сервис AWS, в котором работает EC2, на котором работает Jenkins. Либо можно добавить сервис Kubernetes, в котором Jenkins запускает своих слейвов – тогда Jenkins будет Depends On Kubernetes (а Kubernetes – Depends On AWS):

Добавление Rules

Правила описывают то, как мы хотим автоматически создавать Инциденты из Алертов.

Переходим в Rules, кликаем Add incident rule:

В поле If the following condition(s) are met выбираем условия, при которых Инцидент будет создан, и как к нему потом будут подзвязываться алерты.

К примеру, у нас есть алерт для Jenkins с уровнем Critical, который сообщает о том, что у него на диске заканчивается свободное место:

  - alert: JenkinsLowDataDiskCritical
    expr: ((node_filesystem_size_bytes{mountpoint="/rootfs/data",host="jenkins-production"} - node_filesystem_free_bytes{mountpoint="/rootfs/data",host="jenkins-production"} ) / node_filesystem_size_bytes{mountpoint="/rootfs/data",host="jenkins-production"} * 100) > 95
    for: 1s
    labels:
      severity: critical
...

Изменим > на <, что бы он затриггерился, и получаем алерт в OpsGenie с уровнем P1:

Теперь настраиваем создание Инцидента по такому алерту, используя поля алерта Message и Priority:

В поля Incident Message и Incident Summary можно добавить дополнительную информацию, например – priority и source, с которого получен алерт, а в Incident Priority указать важность инцидента: