# Минимальный процесс работы с инцидентом

Процесс запускает не заполненный документ, а **сообщение с номером инцидента в
корпоративном канале**. Оно уведомляет команду и создаёт рабочий тред.

Когда инженер начинает разбираться с инцидентом, он ставит под корневым
сообщением `👀`. Это означает: «инцидент увидели и взяли в работу».

Сразу после сообщения человек или агент создаёт документ разбора инцидента
(PIR). Всё оперативное общение идёт в треде, а PIR параллельно пополняется
из него известными фактами и результатами расследования.

> **Не начинайте исправление незарегистрированного инцидента.** Сначала создайте
> сообщение в общем канале и документ PIR. Если восстановление нельзя
> задерживать, регистрацию одновременно выполняет другой участник или агент.
> «Тихое» исправление без следа в канале и PIR запрещено.
>
> Полная норма: [правила работы с инцидентами](https://pismenny.ru/incident-management/rules/#registration).

## Минимальный набор ролей

| Роль | Что делает |
| --- | --- |
| **Инженер поддержки** | Регистрирует сигнал с номером инцидента, создаёт корневое сообщение, зовёт нужных участников, а после исправления проверяет пользовательский сценарий и принимает решение о `✅` |
| **Ответственный за инцидент (DRI)** | Ставит `👀`, ведёт тред, координирует расследование и отвечает за следующий шаг |
| **Инженер системы** | Ищет причину, пополняет PIR, готовит RCA и выполняет текущее исправление |
| **Участники регулярного разбора** | Формируют задачи предотвращения и возвращаются к PIR до их полного выполнения |

В небольшой команде один человек может совмещать несколько ролей. Однако в
каждый момент должен быть один явно названный DRI, а выполненное исправление
перед `✅` проверяет инженер поддержки.

AI-агент здесь не является отдельной ролью. Он может выполнять работу внутри
любой из ролей: зарегистрировать сообщение, создать и пополнять PIR, вести
хронологию, готовить RCA, искать причину, предлагать исправление или проверять
статусы задач. При этом использование агента не расширяет полномочия роли:
утверждение причин, принятие production-риска и окончательная приёмка остаются
за ответственным человеком.

## Процесс по блокам

**Сообщение в канале → создан документ PIR → `👀` сбор сведений → поиск корневых причин (RCA) → задачи на текущее исправление → `🏁` исправлено → `✅` принято → задачи предотвращения → регулярные разборы → закрытие инцидента**

```mermaid
flowchart LR
    A["01 · Сообщение в канале<br/>с номером PIR-XXX"] --> B["02 · Создан документ PIR<br/>человеком или агентом"]
    B --> C["03 · Сбор сведений<br/>👀 инженер или агент"]
    C --> D["04 · Поиск корневых причин<br/>RCA"]
    D --> E["05 · Задачи на текущее<br/>исправление"]
    E --> F["06 · Исправление выполнено<br/>🏁"]
    F --> G["07 · Результат проверен<br/>✅"]
    G --> H["08 · Задачи<br/>предотвращения"]
    H --> I["09 · Регулярный<br/>разбор PIR"]
    I --> J{"Все задачи<br/>предотвращения<br/>закрыты?"}
    J -- "нет" --> I
    J -- "да" --> K["10 · Инцидент закрыт"]
```

Задачи предотвращения не обязаны появляться до текущего исправления. Их можно
формировать по ходу заполнения PIR, после восстановления и на регулярном
созвоне по инцидент-менеджменту.

## Что означает каждый блок

1. **Сообщение в канале.** Появляется корневое сообщение с номером инцидента.
   Именно это уведомление запускает процесс; вся дальнейшая коммуникация идёт в
   его треде.
2. **Создан документ PIR.** Документ по шаблону создаёт человек или агент. На
   старте достаточно номера, симптома, времени и ссылки на тред.
3. **Собраны сведения.** Инженер или агент принимает инцидент в работу; статус
   `👀` делает это видимым для команды. Затем он определяет необходимые
   источники, собирает данные и доказательства, восстанавливает хронологию и
   явно отмечает недостающие сведения.
4. **Найдены корневые причины.** Возможные причины проверяются по собранным
   сведениям. Агент может подготовить RCA, но подтверждённую причину принимает
   человек; неподтверждённая версия остаётся гипотезой.
5. **Созданы задачи на текущее исправление.** Это может быть hotfix, откат или
   другое действие, возвращающее рабочий сценарий.
6. **Текущее исправление выполнено.** Инженер ставит `🏁`: изменение сделано и
   готово к проверке.
7. **Результат принят.** После проверки ставится `✅`: инженер поддержки
   подтверждает, что текущее воздействие устранено. Инцидент ещё не закрывается.
8. **Сформированы задачи предотвращения.** Их можно добавлять по мере
   расследования, после текущего исправления или непосредственно на разборе
   PIR. Они должны устранять причины и условия повторения.
9. **Регулярные разборы.** Команда проверяет PIR, уточняет RCA и планирует
   задачи предотвращения. На следующих созвонах PIR обсуждается снова.
10. **Инцидент закрыт.** PIR завершён; закрытие возможно только после выполнения
    и проверки всех обязательных задач, предотвращающих повторение.

## Три объекта процесса

| Объект | Для чего нужен |
| --- | --- |
| **Корневое сообщение** | Запустить процесс, уведомить команду и показать текущие реакции `👀` → `🏁` → `✅` |
| **Тред** | Вести оперативное расследование, обсуждать действия и сохранять первичную хронологию |
| **PIR** | Собрать из треда проверяемый документ: факты, RCA, решения, задачи и состояние полного закрытия |

Главное различие: `✅` означает, что текущее воздействие устранено и это принято
командой; закрытый инцидент означает, что PIR завершён, а задачи по
предотвращению повторения выполнены и проверены.

Связанные материалы:

- [Все материалы об инцидент-менеджменте](https://pismenny.ru/incident-management/)
- [Кейс о внедрении агентского инцидент-менеджмента](https://pismenny.ru/articles/aaa-ai-incident-management-case.html)
- [Шаблон Post-Incident Review (PIR)](https://pismenny.ru/templates/pir/)
- [Шаблон журнала инцидентов в Google Sheets](https://docs.google.com/spreadsheets/d/1Mo3wnn34oMoXsAgH6E83NGp_UIvbzSBuIjOKICZhiO4/edit?usp=sharing)