Сервисы#

Сервисы представляют технические системы, затрагиваемые алертами: API, сайты, базы данных, очереди, воркеры, cron-задания, инфраструктурные компоненты, внешние зависимости и другие логические системы.

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

Зачем нужны сервисы#

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

Это разделение позволяет:

• группировать алерты по затронутой системе;
• показывать специфичные для сервиса runbook'и и ссылки;
• рассчитывать влияние зависимостей;
• понимать радиус поражения;
• строить аналитику по затронутой системе;
• связывать инциденты и окна обслуживания с техническими системами.

Метаданные сервиса#

Общие поля сервиса:

• имя и slug;
• команда-владелец;
• тип, окружение, критичность и уровень (tier);
• текущий статус и сообщение о статусе;
• ротация и политика эскалации по умолчанию;
• метки (labels), теги и метаданные;
• состояние включён/отключён.

Ссылки сервиса#

Ссылки сервиса прикрепляют полезные URL к сервису:

• дашборды;
• метрики;
• логи;
• трейсы;
• репозитории;
• документация;
• страницы статуса;
• вики-страницы.

Ссылки помогают ответственным перейти от алерта или инцидента к правильному операционному контексту.

Runbook'и#

Runbook'и прикрепляют инструкции по реагированию к сервису.

Runbook'и могут включать опциональные матчеры, чтобы у сервиса могли быть как общие, так и специфичные для алерта инструкции.

Примеры сценариев использования:

• процедура при отказе базы данных;
• расследование задержек API;
• смягчение накопления очереди;
• шаги отката развёртывания.

Зависимости#

Зависимости описывают связи между сервисами.

Зависимость имеет:

• depends_on_service_id
• dependency_type — hard, soft, external, informational
• criticality — required, important, optional
• correlation_enabled — может ли эта зависимость использоваться для корреляции алертов.
• propagation_delay_seconds — ожидаемое окно задержки для связанных алертов.

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

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

Подробнее: Корреляция алертов с учётом зависимостей.

Service Impact v2#

Service Impact v2 вычисляет текущий эффективный статус для каждого читаемого сервиса.

Влияние объединяет:

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

Влияние намеренно основано на AlertGroup, а не на сырых событиях алертов. Сгруппированный алерт представляет операционное состояние, которое пользователи подтверждают, разрешают, временно откладывают (shelve), заглушают и расследуют.

Каждый элемент влияния содержит:

• own_status и own_impact_score — сам статус сервиса;
• alert_impact_status и alert_impact_score — влияние, вызванное открытыми сгруппированными алертами;
• dependency_impact_status и dependency_impact_score — влияние, распространённое от вышестоящих сервисов;
• effective_status и effective_impact_score — итоговый вычисленный статус и оценка;
• primary_reason — почему был выбран итоговый статус;
• root_causes — сервисы, где возникла проблема;
• explanation — человекочитаемое объяснение и пути зависимостей;
• blast_radius — нижестоящие сервисы, которые могут быть затронуты этим сервисом.

Первопричины#

Первопричина — это сервис, в котором началось влияние.

Примеры:

• сервис с критической срабатывающей группой алертов;
• сервис с ручным собственным статусом major_outage;
• отключённый сервис;
• сервис в статусе обслуживания.

Нижестоящие сервисы ссылаются на ту же первопричину через пути зависимостей.

Пути зависимостей#

Путь зависимости объясняет, как распространилось влияние.

Пример:

КопироватьFrontend Web -> Billing API -> PostgreSQL Prod

Если у PostgreSQL Prod есть критическая срабатывающая группа алертов, а Billing API зависит от него как hard / required, то Billing API может стать major_outage.

Если Frontend Web зависит от Billing API как soft / important, распространённая оценка снижается на множитель зависимости и может стать partial_outage вместо major_outage.

Оценка влияния алертов#

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

Копироватьexplicit incident priority -> impact score
else alert severity -> impact score

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

Оценки по умолчанию:

Оценка влияния зависимостей#

Распространение зависимости умножает эффективную оценку вышестоящего сервиса. Примеры:

Жёсткая обязательная зависимость от вышестоящего major_outage сохраняет оценку 100. Мягкая важная зависимость от оценки 100 становится оценкой 55 и отображается в partial_outage.

Радиус поражения#

Радиус поражения отвечает на обратный вопрос:

КопироватьWhich downstream services can be affected if this service is unhealthy?

Он содержит:

• количество прямых нижестоящих;
• количество транзитивных нижестоящих;
• количество критических нижестоящих;
• количество нижестоящих уровня tier 1;
• опциональные пути;
• флаги цикла/глубины.

Service Analytics v2#

Service Analytics v2 является исторической и основанной на периоде.

Она отвечает:

• у каких сервисов было больше всего сгруппированных алертов;
• какие сервисы шумны по количеству сырых алертов;
• у каких сервисов есть открытые или критические открытые группы алертов;
• какие сервисы в данный момент затронуты влиянием;
• у каких сервисов есть активность подавления обслуживанием;
• метрики реагирования, такие как MTTA/MTTR, когда доступны поля меток времени.

Аналитика использует два слоя алертов:

Влияние против аналитики#

Влияние и аналитика отвечают на разные вопросы.

Аналитика включает виджет текущего Impact v2 для каждого сервиса, но это не историческое влияние. Исторические тренды влияния требуют снимков влияния и зарезервированы под series.impact_by_day.

Детали сервиса#

Панель деталей сервиса использует агрегированный эндпоинт деталей:

КопироватьGET /api/services/{service_id}/details

Ответ спроектирован как расширяемый контракт для операторов и аналитики. Он содержит:

• метаданные и права доступа сервиса;
• сводку сгруппированных алертов на основе AlertGroup;
• текущий блок Impact v2;
• активные или предстоящие окна обслуживания;
• ссылки сервиса;
• runbook'и;
• вышестоящие и нижестоящие зависимости;
• недавнюю историю статусов сервиса;
• версионированный блок analytics.

Блок analytics намеренно версионирован. Новые виджеты, такие как MTTR, шум, задержка подтверждения, количество инцидентов, скорость выгорания SLO или объём сырых событий алертов, должны добавляться под analytics.widgets, analytics.breakdowns, analytics.series или analytics.extensions, а не изменять существующие поля.