Без классификации инцидентов по уровню серьёзности все проблемы кажутся одинаково критичными. Сервер упал на 30 секунд? P1. CSS не загружается? P1. Обе проблемы требуют немедленного ответа—и вот ваша команда выгорает через месяц. Правильная классификация P1-P4 позволяет распределить ресурсы умно: быстро реагировать на реальные кризисы и обрабатывать рутинные проблемы эффективно.
Эта статья определит чёткие границы между уровнями, покажет, как принимать решение в серых зонах, и объяснит связь между severity и response time. Цель: ваша команда тратит часы на то, что действительно важно, а не гасит ложные тревоги.
Зачем вообще нужна классификация
Представьте, что в вашей компании нет классификации, только тревоги (alerts). Произойдёт что-то необычное — все получают SMS. Потом разбираются, что это было, и вот уже:
- On-call инженер не спит по ночам (даже мелкие проблемы будят его)
- Команда перестаёт верить тревогам (alert fatigue)
- Real critical incident в 3 часа ночи остаётся незамеченным, потому что звонки потеряны в шуме
- Burnout и текучесть кадров
Классификация создаёт договор: «P1 — это когда нужно звонить, P2 — отправить сообщение, P3 — через день посмотреть». Ясные правила снижают стресс и повышают эффективность.
P1: Critical (Критичный)
Определение
Сервис полностью недоступен для значительной части пользователей, происходит потеря данных, или есть угроза безопасности. Бизнес теряет деньги каждую минуту.
Примеры P1
- Полный outage: все три региона недоступны одновременно
- Потеря данных: база данных повреждена, транзакции теряются
- Security breach: обнаружена уязвимость, хакер имеет доступ
- Payment processing down: платежи не проходят, доход потерян
- Authentication broken: никто не может залогиниться, приложение бесполезно
Response time
Первый ответ: 5 минут (от момента срабатывания alert)
Обновления: каждые 15 минут
Эскалация: немедленно CEO, CTO, старший инженер
Действия при P1
- Вызовите on-call инженера по телефону (не Slack)
- Созовите incident commander и начните видеоконференцию
- Запустите communication channel (обновляйте статус каждые 15 минут)
- Все руководители в зуме наблюдают и помогают принимать решения
- Параллельно: разбор причины (RCA) может подождать, сейчас нужна стабилизация
P2: Major (Основной)
Определение
Значительное снижение функциональности или partial outage. Часть пользователей затронута, но есть workaround или система частично работает.
Примеры P2
- Один регион вышел: пользователи в EU могут работать через US, но с задержкой
- Деградация: API работает, но отвечает за 5+ секунд вместо 200ms
- Partial feature down: экспорт данных сломан, но остальное работает
- Database connection pool exhausted: новые запросы зависают, старые работают
- Memory leak в worker: процессы падают каждый час, но перезагружаются автоматически
Response time
Первый ответ: 15 минут
Обновления: каждые 30 минут
Эскалация: на-call инженер + team lead
Действия при P2
- Отправьте сообщение in-call инженеру (SMS будет)
- Создайте incident в Slack и пригласите команду
- Не требуется вызов CEO, но team lead должен знать
- Обновляйте status page (если он публичный) каждые 30 минут
- Параллельно собирайте информацию для RCA
P3: Minor (Незначительный)
Определение
Небольшая проблема с ограниченным влиянием на пользователей. Есть простой workaround или проблема затрагивает очень мало людей.
Примеры P3
- CSS broken на странице настроек: кнопки не видны, но функция работает через API
- Email notifications delayed: уведомления приходят на час позже, но приходят
- One user cannot log in: это у одного конкретного человека (может быть браузер)
- Timezone conversion bug: у пользователей из одной страны неверный timezone
- Documentation page 404: docs недоступны, но функция работает
Response time
Первый ответ: 1 час (в рабочие часы)
Обновления: один раз в день
Эскалация: инженер посмотрит в течение дня
Действия при P3
- Создайте issue в bagtracker
- Отправьте в Slack (текст, без @here)
- На-call инженер посмотрит в течение дня, когда будет time-block для bug fixes
- Не требуется emergency response
- Может закончиться в next sprint
P4: Low (Низкий)
Определение
Косметическая проблема, пожелание по улучшению, или очень редкое edge case. Нет влияния на функциональность или пользовательский опыт.
Примеры P4
- Typo в документации: написано «montioring» вместо «monitoring»
- Button color slightly off: кнопка серого оттенка вместо тёмного серого
- Exception message unclear: ошибка показывает «Internal Error 500» вместо конкретной причины
- Performance could be better: API отвечает за 100ms, идеально было бы 50ms
- Feature request: пользователи просят экспорт в Excel (когда уже есть CSV)
Response time
Первый ответ: next sprint или вообще не срочно
Обновления: когда будет тайм
Эскалация: нет
Действия при P4
- Создайте issue в backlog
- Отправьте в общий канал (без urgency)
- Инженер посмотрит, когда будет свободное время
- Это не блокирует никого
Таблица Response Time
| Severity | First Response | Updates | Escalation | Notification Method |
|---|---|---|---|---|
| P1 | 5 minutes | Every 15 min | CEO, CTO, IR lead | Phone call + SMS |
| P2 | 15 minutes | Every 30 min | Team lead, on-call | SMS + Slack |
| P3 | 1 hour | Daily summary | On-call engineer | Email + Slack |
| P4 | Next sprint | As needed | None | Backlog issue |
Серые зоны: Как принимать решение
Не все проблемы чётко укладываются в одну категорию. Вот как думать о пограничных случаях.
Случай: один API endpoint работает медленно
Вопросы: Какой endpoint? Сколько пользователей это затрагивает? Есть ли workaround?
- Если это checkout API и затрагивает 10% платежей → P1 (потеря доходов)
- Если это analytics API и затрагивает 50% аналитики → P2 (функция работает, но медленно)
- Если это notifications API и письма приходят на 2 часа позже → P3 (люди получат, но позже)
Случай: Error spike в логах
Вопросы: Логируется ли это действительное падение функции? Видят ли это пользователи?
- Если это exception при обработке платежа → P1 (платежи падают)
- Если это warning при обновлении cache → P3 (система восстанавливает себя сама)
- Если это debug log, который случайно оказался на level ERROR → P4 (false alarm)
Правило большого пальца
Спросите себя: «Потеряет ли пользователь деньги, данные или будет разочарован в течение часа?»
- Да, критично: P1
- Да, но есть workaround: P2
- Может быть, но маловероятно: P3
- Нет, не беспокойтесь: P4
Severity vs Priority: Важное различие
Severity = как плохо ситуация (количество потерь). Priority = как быстро отвечать (urgency).
| Scenario | Severity | Priority | Response |
|---|---|---|---|
| Database down | P1 | Critical | Page on-call immediately |
| Typo on landing page at 3 AM | P4 | Critical | Fix before morning (high priority, low severity) |
| Deprecated API removed from docs | P4 | Low | Fix in next sprint |
| One region slow, 1% users affected | P3 | High | Investigate soon if pattern continues |
Ключевой вывод: prioritize severity и priority независимо, потом скомбинируйте. P4 может быть urgent, P2 может быть deferred.
Правила эскалации
P1 escalation chain
1. Alert fired → on-call engineer notified (phone + SMS)
2. Within 5 min: engineer confirms, creates incident bridge
3. Within 10 min: team lead + incident commander join
4. Within 15 min: CTO + VP Ops informed (they may join)
5. Every 15 min: status update to all stakeholders
P2 escalation chain
1. Alert fired → on-call engineer notified (SMS)
2. Within 15 min: engineer investigates, creates incident
3. Within 30 min: team lead informed (Slack mention)
4. Update status every 30 min (internal Slack thread)
P3 + P4: No escalation
Engineer picks up during business hours or next shift. Document in issue tracker.
Распространённые ошибки
Ошибка 1: Severity inflation (всё P1)
Команда классифицирует routine issues как P1, чтобы быстрее их починить. Результат: on-call инженер не спит, alert fatigue,真の P1 incidents пропускаются. Решение: auditing классификаций. Каждый месяц смотрите на все P1, спросите «это действительно был P1?» Если нет—обучайте команду.
Ошибка 2: Нет четких определений
Каждый инженер по-своему интерпретирует P2 vs P3. Один думает, что «API slow» это P2, другой считает P3. Результат: chaos. Решение: документируйте четкие критерии. Покажите примеры. Обновляйте по-мере опыта. Make it part of на-call playbook.
Ошибка 3: Severity не меняется
Классифицировали как P1, потом выяснилось, что это P3, но никто не downgrade. Команда тратит часы на низкоприоритетную работу. Решение: переоценивайте severity по мере информации. Скажите stakeholders: «Мы think это P3, а не P1, потому что...»
Ошибка 4: Severity == priority
Думают, что высокий severity означает высокий priority. Но P4 bug у CEO может быть критичнее, чем P2 bug у одного пользователя. Решение: отделите severity от priority. Классифицируйте оба.
Severity и мониторинг: Практическое применение
Правильная классификация в monitoring напрямую связана с severity levels. AtomPing позволяет настроить alert policies таким образом, чтобы разные инциденты срабатывали в разных каналах.
Пример конфигурации AtomPing alert policy
Target: API Server (eu-fra1, us-east-1, ap-sin1)
Rule 1 - P1 (Critical):
Trigger: 3+ regions DOWN in same cycle
Channels: PagerDuty + SMS + call
Rule 2 - P2 (Major):
Trigger: 1 region DOWN or DEGRADED for 2+ cycles
Channels: Slack #incidents + email
Rule 3 - P3 (Minor):
Trigger: 1 region slow (TTFB >2s) for 3+ cycles
Channels: Email onlyИспользуя такую конфигурацию, вы гарантируете, что P1 сразу получит attention, P2 будет обработана чётко, а P3 не будет шуметь в каналах общения.
Чек-лист: Готова ли ваша команда
- ☐У вас есть письменные определения P1-P4 с примерами
- ☐На-call playbook содержит response times для каждого уровня
- ☐Все инженеры прошли обучение и согласны с определениями
- ☐Alert policies в monitoring системе соответствуют severity levels
- ☐Вы регулярно (ежемесячно) auditing инцидентов, чтобы поймать inflation
- ☐Есть процесс для переклассификации severity по мере информации
- ☐Severity и priority определяются отдельно
Резюме
Severity classification P1-P4 — это не формальность, это инструмент для sane incident response. Ясные определения уменьшают стресс, снижают burnout, и гарантируют, что критичные инциденты получают внимание, которое они заслуживают.
Помните: сегодня ваша команда перегружена, потому что всё классифицируется как urgent. Правильная severity classification освобождает capacity для того, что действительно важно.
Связанные материалы
- → Incident Management Guide — полный процесс управления инцидентами от alert до RCA
- → On-Call Rotation Best Practices — как организовать на-call график, чтобы не выгорели
- → Incident Communication Templates — готовые шаблоны сообщений для разных severity уровней
- → Post-Incident Review Guide — как провести blameless RCA и не повторить ошибку
FAQ
What is the difference between incident severity and priority?
Severity describes the business impact of an incident (how bad it is). Priority describes the urgency of response (how fast we must react). A P2 incident might have high priority (respond in 15 min) but actually be cosmetic in nature. A P4 issue might be high priority if it affects a key stakeholder but has low severity. Never confuse the two: define both separately in your incident response process.
Can an incident change severity during its lifecycle?
Yes, frequently. An incident might start as P3 (single region down) but escalate to P1 if it spreads to multiple regions. Conversely, a P1 incident might de-escalate to P2 once the main issue is mitigated and only cleanup remains. Always re-evaluate severity as new information arrives. Update stakeholders when severity changes: 'We initially classified this as P1, but it's now P2 because the primary database recovered.'
How do you decide if an incident is P1 or P2 when multiple regions are affected?
Look at user impact, not region count. P1 = complete outage or critical data loss, regardless of region count. P2 = significant degradation affecting a region subset. If 2 regions are down but users can route to a 3rd region with acceptable latency, it might be P2 (not P1). If 1 region is down but it's your primary revenue source, it's P1. Severity = impact, not topology.
Should we have different response times for different teams (frontend vs backend vs ops)?
Yes. A P1 incident requires all teams to respond within 5 minutes total (including alerting/escalation overhead). This doesn't mean every team member must be at their keyboard in 5 min—it means the on-call rotation must have someone ready. Backend on-call might respond in 2 min, frontend in 3 min, ops in 1 min. Each team's SLA is part of the overall incident response SLA.
What does 'severity inflation' mean and why is it a problem?
Severity inflation happens when teams classify routine issues as P1 or P2 to get faster response. Over time, P1 means nothing—every issue is P1, so nothing gets proper investigation. This burns out on-call teams, causes alert fatigue, and delays actual critical incidents. Prevent it by enforcing definitions, auditing classifications, and training teams on the cost of false alarms.
How does AtomPing's alert system connect to incident severity?
AtomPing detects outages and sends alerts based on your configured thresholds. Use alert policy rules to trigger escalation at different severity levels: configure a critical alert (P1) to trigger when 3 regions fail, a major alert (P2) when 1 region fails, minor alert (P3) for degradation. Link alert policies to specific notification channels: P1 → PagerDuty + SMS + call, P2 → Slack + email, P3 → email only. This maps monitoring directly to severity response.