# Процесс: управление инцидентом

Учебный пример для команды с общим каналом инцидентов и мониторингом.
Послеинцидентный разбор: PIR — документ и этап процесса,
а не название всего управления инцидентом.

## Зачем

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

## Точка входа

- Что запускает процесс: сигнал мониторинга, поддержки или участника команды о возможном влиянии на пользователей.
- Кто может запустить: ответственный за инцидент или дежурный инженер.
- Где это происходит: выделенный канал инцидента, мониторинг и система задач.
- Как понять, что входные данные готовы: есть время сигнала, его источник и предполагаемое влияние.

## Участники и ответственность

- Владелец процесса: ответственный за инцидент.
- Кто готовит входные данные: источник сигнала и дежурный инженер.
- Кто принимает результат: ответственный за инцидент и владелец затронутого сервиса.
- Кто обновляет шаблоны, промпты или скиллы: SRE, DevOps или Tech Lead.

## Входные данные

- Сигнал и сообщения из выделенного канала инцидента.
- Разрешённые данные мониторинга и журналов.
- Карта сервиса и актуальная инструкция восстановления.

## Выходные артефакты

- Подтверждённое влияние и хронология фактов.
- Подтверждение восстановления и журнал принятых решений.
- Решение о необходимости PIR и назначенные действия.

## Шаги процесса

| Шаг | Вход | Выход | Критерий качества |
| --- | --- | --- | --- |
| 1. Собрать сигналы | Первичный сигнал, разрешённые журналы и метрики | Черновик фактов и гипотез | Каждый факт связан с источником; гипотезы явно помечены |
| 2. Подтвердить влияние | Черновик фактов и данные о пользователях | Приоритет, влияние и состав участников | Решение подтвердил ответственный за инцидент |
| 3. Выполнить восстановление | Подтверждённое влияние и актуальная инструкция | Выполненное действие и его результат | Действие выбрал и выполнил уполномоченный человек |
| 4. Обновить хронологию и сообщения | Факты, решения и результат действия | Актуальная хронология и черновики сообщений | Время и источник указаны; неподтверждённые причины не выданы за факт |
| 5. Подтвердить восстановление | Состояние сервиса после действия | Записанное подтверждение восстановления | Пользовательские и технические сигналы вернулись в допустимые границы |
| 6. Закрыть запуск или назначить PIR | Хронология, подтверждение восстановления и остаточные риски | Решение о PIR, задачи и строка журнала | Есть владелец решения, источники метрик и назначенные последующие действия |

## Промпты, скиллы и инструменты

- Канал инцидента, мониторинг, журналы и система задач.
- Версионируемый шаблон инцидента и инструкции агента.
- Шаблон PIR для случаев, где после восстановления нужен отдельный разбор.

## Контрольные точки с человеком

- Где человек обязан проверить результат: при подтверждении влияния, перед действием восстановления, перед внешним сообщением и при формулировке причины.
- Какие решения нельзя отдавать агенту: приоритет, опасное действие, публичная коммуникация и утверждение корневой причины.
- Что делать, если результат сомнительный: пометить его как гипотезу и вернуть ответственному за инцидент.

## Данные и доступы

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

## Метрики

- Основная метрика результата: время от сигнала до подтверждения влияния и время до восстановления; источник — журнал инцидента.
- Метрика качества или внедрённости: доля инцидентов с подтверждённой хронологией и назначенными действиями.
- Негативный сигнал: опасное действие, неподтверждённая причина или повтор инцидента по той же причине.
- Исходный уровень: отдельно измерить на симуляциях и на доступной выборке реальных инцидентов.

## Ресурсы и срок

- Срок первого этапа: 6 недель, потому что частота реальных инцидентов непредсказуема.
- Время команды: около 10 часов на настройку, две симуляции, 6 часов на разбор и фактическое время участников реальных событий.
- Лимит на инструменты и инфраструктуру: определить до запуска и не расширять доступ без решения владельца.
- Стоимость одного запуска: стоимость инструментов плюс время ответственного и участников; считать отдельно для симуляции и инцидента.
- Полная стоимость этапа: настройка, две симуляции, разборы и фактические расходы на реальные запуски.

## Критерий внедрённости

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

## Журнал запусков

| Дата | Вход | Результат | Проверка человеком | Метрики | Что изменить |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |