Автоматизация инцидентов связывает сигнал мониторинга с записью о сбое сервиса, назначением дежурного, подтверждённым восстановлением и разбором причины. Машина помогает собрать события и контекст, а ответственный инженер определяет тяжесть и разрешает действия, способные изменить рабочую систему. Для проверки такого контура нужен маршрут одного события с ясными правами и доказательствами каждого перехода.
Сигнал и запись
Отправная точка операционного инцидента — проверяемый симптом нарушения сервиса. Сигнал мониторинга, обращение пользователя и запись об инциденте связаны, но выполняют разные роли: источник, свидетельство воздействия и общий журнал восстановления.
Сначала перечислите сервисы, владельцев и симптомы, при которых дежурному нужна реакция. Входом может служить срабатывание правила мониторинга, результат проверки доступности или сообщение от поддержки. Для каждого входа задайте идентификатор сервиса, источник, отметку времени, наблюдаемое состояние и ссылку на исходный график либо лог. Описание «сервер упал» без имени услуги и признака влияния на пользователя создаёт лишнюю работу при передаче дежурства.
В качестве конкретного механизма Prometheus Alertmanager документирует группировку, дедупликацию и маршрутизацию уведомлений. Эти функции относятся к уведомлениям; решение объединить несколько событий в один инцидент со своей историей команда проектирует отдельно. При группировке сохраняйте список исходных сигналов и показывайте расширение зоны сбоя. Для каждого инцидента назначьте один устойчивый идентификатор и связь с первичными событиями.
| Вход | Проверка при приёме | Что сохранить |
|---|---|---|
| Сигнал мониторинга | Сервис, источник и актуальность | Идентификатор события и ссылка на метрику |
| Обращение пользователя | Совпадает ли с текущим сбоем | Факт влияния и канал связи |
| Ручная запись дежурного | Есть ли подтверждающее наблюдение | Автор, время и причина открытия |
Пользовательский тикет может дополнить картину воздействия, но маршрут восстановления сервиса ведётся отдельной операционной записью. Если событие указывает на возможное нарушение безопасности, его передают в утверждённый процесс реагирования на угрозы с отдельными ролями и правилами доступа.
Группировка и тяжесть
После приёма сопоставьте новые сигналы с открытыми инцидентами по сервису, признаку сбоя и области воздействия. Дедупликация уведомлений уменьшает повторные оповещения; исходные события остаются в истории. Отдельно разберите ситуацию, когда одинаковый симптом затронул разные услуги: объединение по одному имени правила может скрыть владельца второго сервиса. В журнале фиксируйте критерий группировки и причину ручного разделения.
- Интеграционный сервер проверяет схему события и полномочия источника. Неизвестный сервис попадает в очередь разбора с сохранением исходного сигнала.
- Правило группировки предлагает связь с открытым инцидентом и показывает совпавшие признаки. Дежурный подтверждает связь либо создаёт новую запись.
- Дежурный оценивает тяжесть по фактическому влиянию: какие функции недоступны, кому это мешает, есть ли рабочий обход.
- Ответственный назначает команду восстановления и канал обновлений. Изменение тяжести сохраняет автора, основание и прежнее значение.
Модель может подготовить сводку сигналов и предположение о затронутых компонентах. Такая сводка остаётся черновиком: логи бывают неполными, а ложное объединение задерживает правильную команду. Сервер проверяет право изменить запись, тяжесть и назначенного исполнителя; человек подтверждает спорный вывод. Поля тяжести лучше связывать с локальным регламентом сервиса, учитывающим разные последствия для услуг.
Смотрите на симптомы глазами пользователя и сохраняйте технические данные как доказательство. Рекомендации Google SRE по реагированию также ставят наблюдаемое влияние и ясные роли в центр управления сбоем; конкретные пороги и маршрут утверждает ваша команда.
Дежурный и допуск
У дежурного должны быть карточка сервиса, график смены, контакты владельца и краткий runbook с безопасными диагностическими действиями. При открытии инцидента система показывает эти материалы и запрашивает подтверждение получения оповещения. Если дежурный занят или сигнал относится к чужой зоне, маршрут переводит запись следующему ответственному по заранее согласованной схеме. Передача сохраняет состояние, журнал проб и незакрытые вопросы.
| Действие | Допуск | Подтверждение |
|---|---|---|
| Чтение метрик и логов | Роль дежурного по сервису | Ссылка на наблюдение в журнале |
| Смена тяжести и адресата | Ответственный за инцидент | Причина и запись автора |
| Перезапуск или откат | Уполномоченный инженер по регламенту | Ручное разрешение и план возврата |
| Сообщение заинтересованным | Назначенный владелец коммуникаций | Согласованный текст и канал |
Команда перезапуска, переключения трафика, отката версии или изменения конфигурации может усилить сбой. Поэтому проектная схема отправляет такую команду на ручное разрешение с проверкой полномочий сервером. После разрешения исполнитель записывает выбранный шаг, ожидаемый эффект и способ возврата. Модель вправе предложить вариант по runbook и собрать ссылки на факты, однако окончательное действие выполняет ответственный человек.
Поток согласований можно связать с описанием сценариев n8n, если выбранная система поддерживает требуемый журнал и права. Сценарий оставляет серверную проверку роли и ручную отметку на границе действия. Такой контур проектируют с учётом собственных прав и регламента допуска.
Нужен маршрут допуска для ваших дежурных инженеров?
Восстановление сервиса
После выбранного действия инженер проверяет восстановление по тем же пользовательским симптомам, которые открыли инцидент. Зелёная метрика отдельного узла показывает лишь состояние этого узла; доступность услуги проверяют отдельно. Сопоставьте мониторинг с пробной операцией, сообщением поддержки и состоянием зависимых компонентов. Если обход временный, отразите это в статусе и сохраните задачу на устранение причины. Закрытие записи утверждает ответственный за сервис после просмотра доказательств.
- Зафиксируйте исходное состояние и версию конфигурации до изменения. Сохраните ссылки на графики, логи и замечания дежурного.
- Получите ручной допуск к опасному действию. Запишите исполнителя, точное изменение и способ возврата к прежнему состоянию.
- Проверьте пользовательскую функцию, затронутые зависимости и отсутствие нового сбоя. Спорный результат отправьте на повторную диагностику.
- Обновите статус для заинтересованных сторон и назначьте владельца дальнейшего наблюдения за сервисом.
При повторном сигнале после закрытия система может предложить ссылку на прошлую запись. Человек решает, открыть продолжение или новый инцидент: совпадение текста тревоги требует проверки причины. Разрешение на опасное действие повторно проверяют для нового контекста. Такой подход отделяет восстановление пользовательской функции от окончательного объяснения причины и предотвращает исчезновение незавершённых задач после формального закрытия.
Для внутренней команды полезна отдельная запись об изменениях, сделанных во время сбоя. Она позволяет следующему дежурному понять текущее состояние сервиса без догадок и сверить последствия с исходной конфигурацией.
Разбор и приёмка
Разбор проводится после восстановления. Соберите временную линию из сигналов, назначений, сообщений, команд и подтверждений состояния. Отделите наблюдавшийся симптом от доказанной причины и сопутствующих факторов. Если причина пока неизвестна, так и отметьте её вместе с планом проверки. Вместо поиска виновного назначьте владельцев изменений в мониторинге, runbook, маршруте дежурства и архитектуре сервиса. Подход к разбору и распределению ролей опирается на официальный гид Google SRE.
- Приёмка сигнала: событие сохранилось, повтор сгруппирован с указанием исходных идентификаторов, новый симптом виден отдельно.
- Приёмка эскалации: назначенный дежурный подтверждает получение, ошибочный адресат передаёт запись по маршруту без потери истории.
- Приёмка прав: пользователь без допуска получает отказ на опасное действие; разрешённый инженер оставляет журнал и план возврата.
- Приёмка закрытия: пользовательская проверка и мониторинг согласуются, ответственный сотрудник подтверждает статус.
Проведите испытание на тестовых событиях и безопасной среде, включая дубль, неизвестный сервис, смену дежурного и повторный сбой. Сверьте фактический журнал с ожидаемым маршрутом; модель может составить черновик хронологии, а спорные выводы подтверждает инженер. Общие принципы проверки автоматизированных сценариев и отката приведены в статье о тестировании ИИ-агентов. Для построения интеграций и регламента можно обсудить автоматизацию бизнес-процессов на примере своего сервиса. Особое внимание уделите сигналу о новой затронутой услуге: прежняя группировка уведомлений должна сохранить его в истории и вызвать проверку владельца второго сервиса. На приёмке покажите отдельные записи уведомления, операционного инцидента и решения дежурного.
Контур принят, когда команда воспроизводит путь от сигнала до подтверждённого восстановления, объясняет каждое назначение и отказ в доступе, а разбор сохраняет открытые задачи с владельцами.