Документация

История влияния на сервис

Версия v2.3.1 · Обновлено

История влияния на сервис#

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

Найти её можно в:

Services → Impact → History

Вкладка Current показывает актуальный расчёт влияния на сервис. Вкладка History показывает сохранённые снимки этого расчёта.

Что такое снимок#

Снимок — это сохранённая копия представления влияния на сервис на определённый момент времени. Он фиксирует текущий расчёт Impact v2 и сохраняет одновременно:

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

Снимки не являются новыми алертами и не изменяют статус сервиса. Это исторические записи, используемые для аналитики и расследования.

Как создаются снимки#

Снимки можно создавать двумя способами:

  • автоматически планировщиком;
  • вручную с помощью Capture snapshot на вкладке History.

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

Какие данные используются для построения снимка#

Снимок строится на основе тех же данных, что и Services → Impact → Current.

Расчёт читает:

  • сервисы, видимые в выбранной области;
  • собственный статус каждого сервиса, например operational, degraded, partial_outage, major_outage, maintenance, disabled или unknown;
  • включённые зависимости сервиса, включая тип зависимости и критичность;
  • открытые группы алертов, связанные с сервисами;
  • серьёзность и статус группы алертов;
  • метаданные сервиса, используемые Impact, такие как команда, уровень (tier) и критичность;
  • выбранные параметры Impact, такие как максимальная глубина, включение операционных сервисов, включение отключённых сервисов, первопричины, пути и радиус поражения.

Для влияния алертов учитываются только открытые группы алертов. В текущей реализации «открытый» означает:

firing or acknowledged

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

Что хранится в снимке#

Заголовок снимка хранит общие счётчики, например:

  • всего сервисов в расчёте;
  • затронутые сервисы;
  • счётчики major outage, partial outage, degraded, maintenance и unknown;
  • сервисы, затронутые собственным статусом;
  • сервисы, затронутые вышестоящими зависимостями;
  • сервисы, затронутые группами алертов;
  • всего открытых групп алертов;
  • всего критических открытых групп алертов;
  • всего вышестоящих проблем;
  • счётчики циклов и ограничения глубины;
  • выбранные фильтры и параметры расчёта.

Каждая строка сервиса хранит результат уровня сервиса, например:

  • имя сервиса, slug и команда;
  • уровень (tier) и критичность сервиса;
  • собственный статус;
  • статус влияния алертов;
  • статус влияния зависимостей;
  • эффективный статус;
  • основная причина;
  • счётчики открытых групп алертов;
  • количество вышестоящих проблем;
  • первопричины;
  • пояснение;
  • радиус поражения;
  • исходный payload строки Impact.

Имена хранятся вместе с идентификаторами, поэтому старые снимки остаются читаемыми, даже если сервис или команда позже переименованы.

Как читать вкладку History#

Вкладка History содержит три основные области.

Исторически затронутые сервисы#

Этот график показывает, сколько сервисов было затронуто в каждом временном интервале. Используйте его, чтобы увидеть, когда влияние началось, когда достигло пика и когда вернулось к норме.

Исторические причины влияния#

Этот график показывает, почему сервисы были затронуты. Распространённые причины:

  • own status — сам сервис был деградирован, в аварии, на обслуживании или в неизвестном состоянии;
  • alert group — открытые группы алертов на сервисе изменили его влияние;
  • upstream dependency — сервис был затронут зависимостью;
  • disabled — сервис был отключён.

Исторически затронутые сервисы#

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

Выбор временного диапазона#

Используйте селектор периода для выбора окна анализа:

  • последние 7 дней;
  • последние 30 дней;
  • последние 90 дней;
  • последние 365 дней.

Более короткое окно лучше подходит для расследования инцидентов. Более длинное окно лучше для анализа трендов и обзоров качества сервисов.

Как работает доступ#

История следует тем же правилам видимости сервисов, что и текущее представление Impact. Пользователи видят данные снимков только для команд и сервисов, которые им разрешено читать.

Глобальный снимок всё же может быть виден частично: если он содержит 100 сервисов, но пользователь может читать только одну команду, вкладка History показывает только строки, видимые этому пользователю.

Хранение#

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

Рекомендуемые значения по умолчанию:

[services]
impact_snapshot_enabled = true
impact_snapshot_interval_seconds = 300
impact_snapshot_retention_days = 365

С этими настройками IncidentRelay сохраняет снимок каждые пять минут и хранит год истории.

Типичные сценарии использования#

Используйте историю влияния на сервис, чтобы отвечать на вопросы вроде:

  • Какие сервисы были затронуты во время вчерашнего инцидента?
  • Пришло ли влияние от алертов, собственного статуса сервиса или зависимостей?
  • Какой сервис был вероятным вышестоящим источником повторяющегося влияния?
  • Как часто этот сервис затрагивается зависимостями?
  • Улучшилась ли модель зависимостей после того, как мы её изменили?
  • Какие команды владеют наиболее часто затрагиваемыми сервисами?

Ограничения#

Снимок настолько точен, насколько точен каталог сервисов на момент его захвата. Если у сервисов отсутствуют зависимости или группы алертов не связаны с сервисами, история не покажет полной картины влияния.

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