Короткий ответ
Приоритет инцидента Contoso ставится по влиянию на бизнес и срочности, не по громкости чата. Шкала P1–P4 должна быть на одной странице с примерами из ваших сервисов: AD, 1С, почта, файлы, VPN, печать. P1 — массовый простой критичного сервиса или ИБ-авария. P4 — единичный косметический сбой.
Связка: приоритет задаёт SLA. Без шкалы SLA не к чему привязать. Назначает дежурный, спорит owner сервиса, не случайный пользователь.
Симптомы и как отличить
Типичная картина:
- 30 открытых «критичных»;
- падение контроллера и замена картриджа в одной куче;
- мониторинг не умеет выставить P1 автоматически даже на ping DC;
- директорский Excel помечают P1 постоянно.
Отличия:
| Ситуация | Не приоритезация | Куда |
|---|---|---|
| Нет очереди, всё в личке | канал | мессенджеры |
| Нет цифр времени | SLA | SLA |
| Плановый патч назвали инцидентом | изменения | CHG |
| Не видели падение | мониторинг | мониторинг |
Возможные причины
- Шкалу не написали, в тикетах дефолт «high».
- Боязнь обидеть пользователя низкой буквой.
- Нет каталога сервисов и критичности.
- ИБ и эксплуатация в одной куче без типа «инцидент ИБ».
- Подрядчик ставит P1, чтобы уложиться в свой KPI.
- Редко: матрица 5×5 из ITIL, которую никто не понял — забросили.
Диагностика
Выгрузите месяц тикетов: распределение приоритетов. Если P1 > 20% — шкала сломана или инфраструктура в огне (тогда чините инфраструктуру, но цифры всё равно врут о нагрузке дежурного).
Сверьте с фактом AD/сети:
# жив ли DC — факт для калибровки «что такое P1»
Test-NetConnection DC01.contoso.example -Port 389
Get-ADDomainController -Filter * | Select-Object Name, IPv4AddressЕсли LDAP мёртв, а в очереди нет P1 — канал слепой. Если LDAP жив, а P1 пять штук про шрифты — калибровка врёт.
Спросите дежурного: «что возьмёшь первым — 1С у 40 человек или почту у одного?» Нет правила — нет приоритезации.
Решение
Определение шкалы Contoso (адаптируйте цифры)
| P | Влияние | Примеры |
|---|---|---|
| P1 | Критичный сервис недоступен многим или ИБ | AD/DNS нет, 1С стоит у всех, файлы HQ лежат, утечка, ransomware |
| P2 | Сильная деградация или простой отдела | VPN не пускает филиал, почта не ходит, 1С у смены склада |
| P3 | Один пользователь / обход есть | не печатает один ПК, сброс пароля, медленный файл |
| P4 | Косметика, вопрос, низкий риск | подпись в Outlook, фон рабочего стола, идея |
Матрица влияние × срочность, если любите две оси: высокое влияние + нужно сейчас = P1. Высокое влияние + можно завтра (есть обход) = P2.
Кто ставит и кто меняет
- Первично: дежурный по симптомам.
- Повысить до P1: дежурный или owner.
- Понизить: только с комментарием и согласием заявителя или owner, если заявитель требует P1 на картридж.
P1 — отдельный ритуал
Не «тикет как все». Звонок, мост, журнал действий, эскалация по SLA. После стабилизации — не забыть запись и разбор.
ИБ-инциденты
Могут быть P1 при малом «влиянии на печать»: компрометация DA, вымогатель. Тип security + приоритет, не прячьте в P3 «странная программа».
Калибровка на реальных сервисах Contoso
Сядьте с owner 1С и файлов на 30 минут и разметьте: полное падение = какой P, деградация «медленно» = какой P, один пользователь = какой P. Запишите в каталог сервисов. Без этого дежурный будет гадать.
Примеры, которые спорят чаще всего: «нет интернета у директора» при живом AD — обычно P2/P3 (рабочие системы внутри живы), если 1С облачная — может быть P1, и это должно быть в каталоге заранее. «Не работает Wi‑Fi гостей» — P4/P3. «Не пускает VPN бухгалтера в отчётный день» — P2, не потому что человек громкий, а потому что отчёт.
Запретите пользователю самоназначать P1 в форме, если форма это умеет. Поле «как много людей затронуто» заполняет заявитель, приоритет ставит IT. Иначе все ставят максимум.
Как проверить, что проблема устранена
- Документ со шкалой и примерами опубликован для IT и руководителей.
- Доля P1 за месяц правдоподобна (единицы, не десятки, если нет катастрофы).
- Учебный сценарий: «упал FILE01» → P1; «не сканирует один МФУ» → P3.
- Пользователь видит приоритет и не удивляется, что картридж не ночью.
Сверьте мониторинг: ping DC → создаётся/должен создаваться P1, не info.
Раз в месяц смотрите топ «повышено до P1 заявителем/директором». Если повторяется одна тема (печать склада, касса) — внесите её в каталог как P2/P1 официально. Иначе шкала снова будет договором с самым громким.
Если не помогло
- Директор всегда P1: оформите политику «executive request» отдельно, прозрачно.
- Всё реально горит: приоритезация не лечит отсутствие второго DC. Чините устойчивость.
- Подрядчик накручивает P1: привяжите оплату к вашей шкале, не к его.
Профилактика
- Каталог сервисов с дефолтным приоритетом при полном падении.
- Разбор ложных P1 раз в месяц.
- Онбординг дежурных: 10 примеров.
- Запрет дефолта «critical» в тикет-системе.
FAQ
P1 может быть у одного человека?
Да: директор на кассе, единственный операционист, врач у аппарата — если бизнес так решил заранее в каталоге, не по крику.
Чем P2 отличается от P1 на практике?
P1 бросаем всё (кроме другого P1). P2 можно вести параллельно с окончанием P3, если P1 нет.
Сброс пароля — какой P?
Обычно P3. Если из-за этого стоит смена на проходной — P2 по влиянию.
Нужно ли P0?
Не обязательно. P1 достаточно, если не плодите космос. «P0 ядерный» без процедуры не нужен.
Кто прав, если owner говорит P2, директор P1?
Письменный каталог. Разово можно повысить с именем директора в тикете — и потом обновить каталог или отказать в следующий раз.
Приоритет изменения и инцидента?
Разные сущности. Срочный CHG не становится P1-инцидентом сам по себе. Авария после CHG — инцидент, плюс разбор изменения.