---
title: Шкала критичности инцидентов для небольшой веб-студии
description: Готовая шкала P1–P4 для веб-студии — критерии, примеры сбоев сайтов, время реакции, правила эскалации и копируемый шаблон регламента поддержки клиентов.
source: https://pingvera.ru/blog/shkala-kritichnosti-incidentov-dlya-veb-studii.html
---
# Шкала критичности инцидентов для небольшой веб-студии

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

Для небольшой веб-студии достаточно четырёх уровней: **P1 — критический**, **P2 — высокий**, **P3 — обычный**, **P4 — низкий**. Каждый уровень должен заранее определять время реакции, способ эскалации, частоту сообщений клиенту и критерий завершения.

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

## Коротко

- Определяйте критичность по бизнес-влиянию, масштабу, наличию обходного пути и срочности.
- Не приравнивайте единичный алерт к подтверждённому инциденту.
- Не позволяйте должности автора сообщения автоматически повышать приоритет.
- Для P1 назначайте руководителя инцидента и отдельного ответственного за коммуникацию.
- Фиксируйте время реакции в договоре только с учётом реального режима работы студии.
- Пересматривайте уровень, когда появляются новые факты или работает временное решение.

## Зачем небольшой студии собственная шкала

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

1. Нужно ли будить дежурного?
2. Следует ли остановить текущие задачи команды?
3. Когда сообщить клиенту?
4. Как часто давать обновления?
5. Можно ли перенести постоянное исправление на рабочее время?

Шкала превращает субъективное «срочно» в повторяемый процесс. Она также помогает продавать разные уровни поддержки честно: круглосуточная реакция на P1 стоит дороже, потому что требует дежурства, резервных контактов и учений, а не красивой строки в коммерческом предложении.

## Критичность и приоритет — не одно и то же

Термины часто смешивают, поэтому лучше закрепить определения в регламенте.

**Критичность** — измеренная тяжесть влияния на бизнес и пользователей.

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

Например:

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

В разговоре с клиентами можно использовать слово «критичность», а внутри команды — короткие обозначения P1–P4. Главное, чтобы значения были одинаковыми в договоре, Helpdesk и инструкциях дежурного.

## Четыре фактора оценки

Перед назначением уровня ответьте на четыре вопроса.

### 1. Какая бизнес-функция нарушена

Смотрите не только на страницу, а на результат пользователя:

- посетитель не может открыть сайт;
- покупатель не может положить товар в корзину;
- заказ оформляется, но оплата не проходит;
- заявка отправляется, но не приходит менеджеру;
- партнёр не может войти в личный кабинет;
- обмен с 1С остановился, остатки и цены устарели;
- поисковым системам случайно отдан `noindex`;
- посетители перенаправляются на посторонний домен.

Один неработающий URL может быть P3, если это старая статья, и P1, если это единственная страница оплаты.

### 2. Сколько пользователей или операций затронуто

Уточните масштаб:

- все посетители или один регион;
- все заказы или один способ оплаты;
- весь сайт или отдельная форма;
- все администраторы или одна учётная запись;
- постоянный сбой или короткие эпизоды;
- есть ли подтверждённые потерянные операции.

Не обязательно ждать точного процента. Для первого решения достаточно диапазона: «все», «значительная часть», «отдельный сегмент», «один пользователь».

### 3. Есть ли безопасный обходной путь

Временное решение снижает влияние, но не закрывает проблему.

Примеры:

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

Обходной путь считается рабочим только после проверки. Фраза «клиент, наверное, может позвонить» — не подтверждённое решение.

### 4. Насколько быстро растёт ущерб

Одинаковая поломка имеет разный приоритет:

- ночью у B2B-каталога без онлайн-заказа;
- в обед у магазина с сотнями заказов;
- в последние часы регистрации на мероприятие;
- во время рекламной рассылки;
- перед обязательной отчётной датой.

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

## Готовая матрица P1–P4

Значения времени ниже — **пример для проектирования процесса**, а не универсальное обещание клиенту. В договор переносите только те сроки и часы, которые команда реально способна обеспечить.

### P1 — критический инцидент

P1 означает, что команда переключается с плановой работы на восстановление сервиса.

Обычно должны выполняться хотя бы одно или несколько условий:

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

Для P1 назначается один руководитель инцидента. Технический специалист занимается восстановлением, а не отвечает одновременно в пяти чатах.

### P2 — высокий приоритет

P2 серьёзно мешает бизнесу, но не останавливает его полностью.

Типичные признаки:

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

P2 может стать P1, если масштаб растёт, обход перестал работать или началось пиковое окно.

### P3 — обычный инцидент

P3 требует исправления, но не аварийного переключения команды.

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

### P4 — запрос без текущего влияния

P4 удобно отделяет инциденты от изменений и консультаций. Если клиент просит добавить способ оплаты, это изменение. Если существующая оплата сломалась, это инцидент.

Не называйте любое пожелание «аварией» ради скорости. Иначе срочный канал быстро превратится в обычную очередь, а настоящий P1 затеряется.

## Алгоритм классификации за две минуты

Используйте последовательность, которую можно держать рядом с рабочим местом:

1. **Подтвердите симптом.** Повторите проверку другим способом или из другой точки.
2. **Назовите нарушенную функцию.** Не «сервер отвечает 500», а «покупатель не может оформить заказ».
3. **Оцените масштаб.** Все, часть аудитории или единичный пользователь.
4. **Проверьте обход.** Он существует, доступен пользователю и безопасен?
5. **Уточните срочность.** Идёт ли рекламная кампания, пик продаж или отчётное окно?
6. **Проверьте признаки безопасности.** Утечка, подмена, вредоносный код и потеря данных требуют отдельной эскалации.
7. **Назначьте предварительный уровень.** Не ждите полной первопричины.
8. **Запишите основание.** Одной строки достаточно: «P1: оформление заказа недоступно всем пользователям, обхода нет».

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

## Дерево решения

Есть подозрение на утечку, взлом, подмену реквизитов или потерю данных?
├── Да → отдельная эскалация безопасности; предварительно P1
└── Нет
 └── Основная бизнес-функция недоступна?
 ├── Да
 │ └── Есть проверенный безопасный обход?
 │ ├── Нет → P1
 │ └── Да → P2, контролировать обход и масштаб
 └── Нет
 └── Есть заметное влияние на часть пользователей?
 ├── Да → P2
 └── Нет
 └── Есть текущий сбой?
 ├── Да → P3
 └── Нет → P4 / запрос на изменение

Это дерево не заменяет контекст. Например, сбой одной формы может быть P1, если через неё приходит весь поток заявок.

## Как связать сигналы мониторинга с уровнями

Мониторинг обнаруживает отклонение, но окончательный уровень назначает человек по бизнес-контексту.

В Pingvera для разных проверок можно настроить подходящие каналы уведомления. Но канал не должен единолично определять критичность: красный алерт — повод проверить факты, а не автоматически объявить катастрофу.

## Особые правила для инцидентов безопасности

Обычная матрица влияния недостаточна, если есть признаки:

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

В таком случае:

1. не продолжайте хаотично менять систему;
2. сохраните доступные журналы и временную шкалу;
3. ограничьте ущерб безопасным способом;
4. подключите заранее назначенного специалиста по безопасности;
5. сообщайте только подтверждённые факты;
6. действуйте по отдельному плану реагирования и применимым требованиям.

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

## Что делать, если клиент требует повысить приоритет

Не спорьте фразой «по нашему регламенту это P3». Повторно соберите факты:

- какая операция невозможна;
- сколько пользователей затронуто;
- какой ущерб уже возник;
- есть ли крайний срок;
- работает ли обходной путь;
- изменился ли масштаб после первой оценки.

Если появились новые данные, повысьте уровень. Если бизнес-влияние не изменилось, можно повысить очерёдность как коммерческое решение, но сохранить фактическую критичность. Так отчётность не будет показывать десять «критических аварий», которые на деле были правками текста.

## Как понижать уровень после временного решения

P1 не обязан оставаться P1 до полного исправления первопричины.

Пример:

1. онлайн-оплата полностью недоступна — P1;
2. студия отключила проблемный шлюз и включила работающий резервный способ — влияние ограничено;
3. контрольный заказ успешно оплачен — уровень можно понизить до P2;
4. постоянное исправление и разбор выполняются без аварийного режима.

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

## Примеры для российских проектов

### Интернет-магазин на 1С-Битрикс

**Симптом:** каталог открывается, но кнопка оформления возвращает ошибку всем посетителям.

**Оценка:** основная бизнес-функция недоступна, обхода нет, продажи остановлены.

**Уровень:** P1.

### Корпоративный сайт производителя

**Симптом:** одна PDF-инструкция отдаёт `404`, документ доступен менеджерам для отправки вручную.

**Оценка:** ограниченное влияние, рабочий обход существует.

**Уровень:** P3.

### B2B-портал

**Симптом:** часть клиентов не видит актуальные остатки после остановки обмена с 1С. Данные устаревают уже четыре часа.

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

**Уровень:** P2 с заданным временем повышения до P1, если обмен не восстановлен к началу рабочего дня.

### Лендинг с рекламным трафиком

**Симптом:** страница открывается, форма показывает «успешно», но письмо не приходит в отдел продаж. Другого канала на странице нет.

**Оценка:** основная конверсия не работает, рекламный бюджет продолжает расходоваться.

**Уровень:** P1 или P2 по согласованной матрице и масштабу кампании.

Подробнее о такой поломке: [почему сайт работает, а заявки не приходят](https://pingvera.ru/blog/ne-prihodyat-zayavki-s-sayta.html).

## Копируемый регламент критичности

# Шкала критичности инцидентов

## Область действия

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

## P1 — критический

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

Реакция: [срок] в период [часы покрытия].
Канал эскалации: [телефон / Telegram / дежурная система].
Первое сообщение клиенту: после подтверждения, не позднее [срок].
Обновления: каждые [интервал] до локализации.
Ответственный: [роль].

## P2 — высокий

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

Реакция: [срок] в период [часы покрытия].
Канал: [Helpdesk + уведомление ответственного].
Обновления: [интервал или контрольные точки].

## P3 — обычный

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

Реакция: [срок в рабочих часах].
Канал: [Helpdesk].

## P4 — низкий / запрос

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

Реакция: [срок].
Канал: [Helpdesk / план работ].

## Правила пересмотра

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

Как проверить шкалу до настоящей аварии
Проведите 45-минутное упражнение:

1. Возьмите пять реальных событий за последние полгода.
2. Дайте каждому сотруднику классифицировать их отдельно.
3. Сравните уровни и основания.
4. Найдите формулировки, которые сотрудники поняли по-разному.
5. Добавьте в матрицу примеры именно ваших клиентов.
6. Разыграйте один P1 с уведомлением и сообщением заказчику.
7. Проверьте, что резервный контакт отвечает.

Если три человека дают одному событию три разных уровня, проблема не в людях — критерии требуют уточнения.

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

### Любой красный мониторинг считается P1

Алерт может быть кратким сетевым сбоем, плановой работой или ошибкой одной точки. Подтверждайте пользовательское влияние.

### Приоритет зависит от эмоций

Громкое сообщение не меняет фактический масштаб. Собирайте бизнес-контекст и фиксируйте решение.

### В матрице есть только технические симптомы

`CPU 95 %` сам по себе не объясняет влияние. Важнее, проходят ли пользовательские операции и растёт ли очередь.

### P1 обещан круглосуточно без дежурства

Если ночью никто не обязан принять сигнал, это не SLA 24/7. Укажите реальное сервисное окно или создайте оплачиваемую схему дежурств.

### Уровень никогда не пересматривается

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

### Инциденты смешаны с изменениями

Восстановление сломанного — инцидент. Добавление нового — запрос на изменение. Для них нужны разные очереди и ожидания.

## Как помогает Pingvera

Pingvera даёт факты для первичной оценки:

- подтверждает доступность из нескольких точек;
- фиксирует начало и окончание нарушения;
- проверяет не только URL, но и формы, доставку заявки, SSL, домен, CMS и серверные сигналы;
- отправляет уведомления в Telegram, email, MAX или webhook;
- помогает показать состояние на статус-странице;
- сохраняет историю для отчёта и разбора.

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

> **Первый практический шаг:** выберите по одному сайту каждого типа, перечислите его критические функции и привяжите проверки к P1–P3. Затем [создайте проверки в Pingvera](https://app.pingvera.ru/).

## Часто задаваемые вопросы

### Чем P1 отличается от P2?

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

### Может ли один неработающий URL быть P1?

Да. Если URL обслуживает оплату, оформление заказа или единственную форму заявки, количество страниц не имеет значения. Оценивается функция, а не число ошибок.

### Должен ли мониторинг автоматически назначать P1?

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

### Как классифицировать медленный сайт?

По влиянию. Если страницы стали чуть медленнее, но операции проходят, это может быть P3. Если покупатели массово не завершают оплату из-за тайм-аутов, событие становится P1 или P2.

### Что делать, если уровень неясен?

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

### Сколько уровней нужно маленькой студии?

Обычно хватает четырёх. Если сотрудники регулярно путают соседние уровни, сначала упростите критерии и добавьте примеры, а не создавайте P2.1 и P2.2.

## Главное

Хорошая шкала критичности отвечает не на вопрос «насколько красный алерт», а на вопрос «что сейчас не может сделать бизнес клиента».

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

## Источники и дополнительное чтение

- [Atlassian: уровни серьёзности инцидентов](https://www.atlassian.com/ru/incident-management/kpis/severity-levels)
- [Atlassian: процесс управления крупным инцидентом](https://www.atlassian.com/incident-management/itsm/major-incident-management)
- [Atlassian: роли и ответственность при инциденте](https://www.atlassian.com/incident-management/incident-response/roles-responsibilities)
- [Google SRE Workbook: Monitoring](https://sre.google/workbook/monitoring/)
- [Cloud.ru: время реагирования и решения обращений](https://cloud.ru/docs/overview/support/topics/concepts__sla)
- [Pingvera: регламент действий при падении сайта](https://pingvera.ru/blog/reglament-incidenta-dlya-veb-studii.html)
- [Pingvera: регламент мониторинга сайтов клиентов](https://pingvera.ru/blog/reglament-monitoringa-saytov-klientov.html)

Следующий материал курса: **«Что написать клиенту в первые десять минут сбоя: готовые шаблоны»**.