# Правила работы с инцидентами

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

## 1. Что считается инцидентом

Инцидент — заметный сбой пользовательского или бизнес-процесса, нарушение
доступности, корректности, безопасности или целостности данных. Он не обязан
быть ошибкой в коде.

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

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

## 2. Инцидент регистрируют сразу

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

Одно корневое сообщение соответствует одному инциденту. Обсуждение продолжается
в его ветке. Человек или агент создаёт документ PIR и связывает его с сообщением.

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

**Нельзя начинать исправление незарегистрированного инцидента.** Сначала
создаются сообщение в общем канале и документ PIR. Если восстановление нельзя
задерживать, регистрацию одновременно выполняет другой участник или агент.
«Тихое» исправление без следа запрещено.

## 3. Принятие в работу должно быть видно

- `👀 В работе` — инженер или агент принял следующий шаг и начал сбор сведений.
- `🏁 Выполнено` — текущее исправление или обходной путь готов к проверке.
- `✅ Принято` — проверяющий подтвердил, что пользовательский сценарий снова
  работает.

Ни одна реакция сама по себе не означает закрытие инцидента.

## 4. Причина должна быть подтверждена

Инженер или агент сначала определяет необходимые источники, затем собирает
данные и доказательства и отмечает пробелы. Факты отделяют от гипотез, а
хронологию снабжают ссылками на источники.

Анализ корневых причин (RCA) выполняют по собранным сведениям. Агент может
подготовить анализ, но подтверждённую причину принимает ответственный человек.

## 5. Полномочия остаются у людей

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

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

## 6. Чувствительные сведения отделяют от сигнала

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

## 7. Восстановление не равно закрытию

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

## 8. Правила должны быть приняты и известны

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

Изменения правил обсуждают на регулярной встрече по разбору инцидентов и доводят
до всех затронутых сотрудников.

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

- [Процесс работы с инцидентом](https://pismenny.ru/artifacts/incident-management-process/)
- [Запуск управления инцидентами в малой группе](https://pismenny.ru/incident-management/launch-small-team/)
- [Шаблон документа PIR](https://pismenny.ru/templates/pir/)