Регламент управления инцидентами: образец

Кратко

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

Актуально на 23 сентября 2026 года.

Чем это отличается от регламента поддержки и от постмортема

Три документа рядом, и их путают чаще всего:

Не каждое обращение — инцидент: разница между инцидентом (что-то работало и перестало) и запросом на обслуживание (плановая просьба) разобрана отдельно в статье Инцидент или запрос на обслуживание: в чём разница. Этот регламент касается только первого.

Готовый образец

РЕГЛАМЕНТ УПРАВЛЕНИЯ ИНЦИДЕНТАМИ

Утверждён: <должность, ФИО>

Дата введения: <ДД.ММ.ГГГГ>

Область действия: <системы и сервисы, на которые распространяется регламент>

1. Термины

2. Классификация серьёзности

2.1. Серьёзность назначает тот, кто первым зафиксировал инцидент, по признаку из таблицы — не по числу жалоб и не по должности того, кто сообщил.

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

3. Роли

3.1. Одно лицо может совмещать роли при SEV3. При SEV1 роли владельца инцидента и исполнителя разделяются обязательно.

4. Порядок обработки

5. Эскалация

5.1. Эскалация до крупного инцидента обязательна, если SEV1 не восстановлен за половину целевого срока раздела 2 либо серьёзность повышена по ходу разбора.

5.2. При объявлении крупного инцидента: собирается группа реагирования, назначается коммуникатор, <должность руководителя> уведомляется немедленно.

5.3. Порядок передачи: дежурный → владелец инцидента → <руководитель службы> → <руководитель организации> — без пропуска уровней и без снятия ответственности с владельца инцидента до момента явной передачи.

6. Коммуникация во время инцидента

6.1. Для SEV1 и SEV2 — обновление статуса не реже чем каждые <30 минут>, даже если сказать нечего кроме «работаем, следующее обновление в …».

6.2. Формулировка обновления: что известно, что делается, когда следующее обновление. Не «скоро починим» без времени.

6.3. Закрывающее сообщение обязательно и отправляется даже при коротком инциденте.

7. Постинцидентный разбор

7.1. Обязателен для SEV1, по решению владельца — для SEV2.

7.2. Срок: не позднее <5 рабочих дней> после закрытия, пока детали не забылись.

7.3. Форма разбора — готовый образец: Разбор массового сбоя: образец отчёта (постмортем).

7.4. Меры по итогам разбора попадают в отдельный список с ответственными и сроками, а не остаются текстом в документе.

8. Хранение и аудит

8.1. Каждый инцидент и каждая смена его статуса фиксируются в системе учёта с указанием времени и исполнителя.

8.2. Записи хранятся не менее <срок, зависит от внутренних требований компании> и доступны для разбора повторных случаев.

Как проверить, что регламент работает

Возьмите последний инцидент серьёзности SEV1 или SEV2 и сверьте по факту три вещи: был ли назначен персональный владелец инцидента (не «дежурная линия», а фамилия), выдерживались ли интервалы обновлений из раздела 6, состоялся ли постинцидентный разбор в срок раздела 7.2. Если хотя бы один пункт не выполнен — регламент существует на бумаге, а не в работе, и следующий крупный инцидент пройдёт так же.

Второй способ — посмотреть время до эскалации по журналу изменений статуса. Эскалация, случившаяся позже половины срока восстановления из раздела 2, показывает, что порог раздела 5.1 либо не соблюдается, либо назначен нереалистично.

Частые ошибки

Один регламент на инциденты и на обычные обращения. Правило эскалации и порог 30-минутного обновления, применённые ко всему потоку, за неделю превращаются в шум и перестают выполняться даже там, где действительно нужны — в SEV1.

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

Серьёзность назначается задним числом. Если признак из раздела 2 не проверяется в момент регистрации, серьёзность получает тот инцидент, о котором громче всего спросили, а не тот, что реально критичен.

Постинцидентный разбор без срока. Разбор «как будет время» не происходит почти никогда: без раздела 7.2 первопричина остаётся неизвестной, и тот же класс инцидентов повторяется.

Регламент без раздела о хранении. Без записей о времени статусов раздел «Как проверить» выше выполнить нечем — проверка держится на памяти участников, а не на данных.

Частые вопросы

Чем регламент управления инцидентами отличается от общего регламента поддержки?

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

Что такое крупный инцидент (major incident)?

Инцидент высшей серьёзности, при котором обязательно собирается группа реагирования и назначается отдельный коммуникатор — в отличие от обычного инцидента, который ведёт один владелец. Порог объявления крупным инцидентом закрепляется в разделе 5 документа.

Нужен ли отдельный регламент, если есть только общий регламент поддержки?

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

Кто должен быть владельцем инцидента?

Не обязательно тот, кто технически устраняет причину. Владелец инцидента — координатор: он держит статус, назначает исполнителя и коммуникатора, принимает решение о закрытии. При SEV1 это разные люди намеренно, чтобы починка не отвлекалась на переписку.

Как часто пересматривать регламент управления инцидентами?

После каждого крупного инцидента — пунктом постинцидентного разбора (раздел 7.4): что в регламенте не сработало. Плановый пересмотр без повода — не реже раза в год, как у соседнего регламента поддержки.

Как это устроено в TehProf.kz Support

Отдельного типа записи «инцидент» в системе нет: инцидент — это заявка с приоритетом «Срочный» или «Высокий» (два верхних уровня из четырёх: Низкий, Обычный, Высокий, Срочный). Жизненный цикл ведётся тем же конечным автоматом статусов, что и у обычной заявки: «Новая» → «В работе» → «Выполнена», с возвратом через «Возобновлена» при повторном проявлении — полный список статусов и переходов в статье Статусы заявок. Приоритет заявки задаёт SLA-таймеры реакции и решения, которые останавливаются только статусом «Ждём клиента» — это и есть числа для разделов 2 и 5 готового образца, только назначенные не вручную по угловым скобкам, а автоматически по правилу приоритета.

Каждая смена статуса записывается в аудит с указанием времени и исполнителя (таблица ticket_status_log) и видна в ленте заявки как системное сообщение; для проверки за пределами одной заявки административный журнал «История» показывает те же действия по компании целиком с фильтром по пользователю, действию и датам — раздел 8 готового образца выполняется этим журналом без дополнительной настройки. Срок хранения записей аудита зависит от тарифа компании — подробности в статье История / Аудит.

Связанные статьи

• Приоритет заявки: как его определяют через влияние и срочность