Коммуникация при инцидентах

Updated Jul 2026

Говорить правильные вещи правильным людям в правильное время

Во время активного инцидента коммуникация так же важна, как и техническое исправление. Плохая коммуникация превращает 30-минутный сбой в кризис доверия. Стейкхолдеры паникуют, когда не знают, что происходит. Клиенты заваливают каналы поддержки, когда страница статуса молчит. Инженеры дублируют работу, когда нет центральной координации. Роль QA-инженера во время инцидентов уникальна: вы можете оценить масштаб, верифицировать исправления и сообщить статус качества способами, которые не может ни одна другая роль.

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

Уровни серьёзности

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

Шаблон обновления статуса (во время активного инцидента)

## Incident Update -- [Timestamp UTC]

**Status:** Investigating / Identified / Monitoring / Resolved
**Severity:** Sev-[1/2/3]
**Incident Commander:** [Name]

### Current Situation
One to two sentences: what is happening right now.

### Impact
Who is affected and how. Be specific.

### Actions Being Taken
What the team is doing right now to resolve the issue.

### Next Update
When the next update will be provided.

### What Teams Can Do
Any actions other teams should take (e.g., "Do not deploy",
"Redirect customer inquiries to [link]").

Пример:

## Incident Update -- 2026-02-09 14:30 UTC

**Status:** Identified
**Severity:** Sev-1
**Incident Commander:** Alice Chen

### Current Situation
Checkout is returning 500 errors for approximately 40% of users.
The root cause has been identified as a database connection pool
exhaustion caused by a slow query.

### Impact
Users cannot complete purchases. Approximately 3,200 users
affected. Revenue impact estimated at $500/minute.

### Actions Being Taken
- The slow query has been killed manually
- Connection pool is recovering (currently at 60% capacity)
- A database index fix is being deployed
- QA is verifying checkout functionality in staging

### Next Update
14:45 UTC or sooner if status changes.

### What Teams Can Do
- Support: Direct customers to retry in 15 minutes
- Marketing: Pause any active promotions
- Engineering: Do not deploy any changes until all-clear

Каналы коммуникации во время инцидентов

Правила коммуникации

1. Обновляйте рано и часто. Обновление статуса, которое говорит «мы расследуем», лучше молчания.
2. Обещайте меньше, делайте больше. Скажите «мы ожидаем решения в течение 2 часов», если думаете, что это займёт 1 час.
3. Будьте честны в том, чего не знаете. «Мы ещё не определили коренную причину» лучше, чем спекуляции.
4. Используйте единую терминологию. «Investigating, Identified, Monitoring, Resolved» — все знают, на каком вы этапе.
5. Отделяйте факты от предположений. «Мы подтвердили, что...» vs «Мы полагаем, что...»

Написание отчётов об инцидентах

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

Шаблон отчёта об инциденте

# Incident Report: [Title]
Date: [Date]
Duration: [Start time] -- [End time] ([total duration])
Severity: [Sev-1/2/3]
Author: [Name]

## Summary
A 2-3 sentence summary of what happened, who was impacted,
and how it was resolved.

## Impact
- **Users affected:** [number and description]
- **Duration:** [time]
- **Revenue impact:** [if applicable]
- **Data impact:** [if applicable]
- **SLA impact:** [if applicable]
- **Support tickets generated:** [number]

## Timeline

| Time (UTC) | Event | Source |
|---|---|---|
| 14:00 | Alert triggered: DB connection pool at 90% | PagerDuty |
| 14:05 | On-call engineer acknowledged | PagerDuty |
| 14:12 | Checkout failures reported by users | Zendesk |
| 14:15 | Incident declared as Sev-1 | Slack #incidents |
| 14:15 | War room opened | Slack #inc-20260209 |
| 14:25 | Root cause identified: slow query | DB monitoring |
| 14:30 | Slow query killed, pool recovering | Manual action |
| 14:35 | Checkout functionality restored | QA verification |
| 14:45 | Database index deployed | Deploy pipeline |
| 15:00 | All-clear declared | Slack #incidents |

## Resolution
What was done to resolve the incident. Both the immediate fix
and any temporary measures.

## Root Cause
Brief description (full analysis in separate RCA document).

## What Went Well
- Alert triggered within minutes of the issue starting
- Root cause identified quickly through database monitoring
- Cross-team coordination was effective
- QA verified the fix before declaring all-clear

## What Could Be Improved
- Migration failure was not detected 2 weeks ago
- Staging data does not match production volumes
- No circuit breaker on database connection pool
- Status page was updated 10 minutes late

## Action Items
Link to the RCA corrective actions.

## Related Documents
- [Root Cause Analysis](link)
- [Status page timeline](link)
- [Customer communication](link)

Внутренняя vs внешняя коммуникация

Один и тот же инцидент требует очень разной коммуникации для различных аудиторий.

Внутренняя коммуникация (инженерия)

Тон: Технический, детальный, честный относительно неизвестного. Содержание: Полные технические детали, хронология, гипотезы о коренных причинах, пункты действий.

«В 14:12 UTC пул соединений PostgreSQL на prod-db-01 был исчерпан из-за запроса к таблице orders, выполнявшего полный скан (50M строк, отсутствует индекс на created_at). Запрос был введён в v2.4.0 (PR #3847). Пул соединений восстановился после ручного завершения запроса в 14:30 UTC. Индекс развёрнут в 14:45 UTC.»

Внешняя коммуникация (клиенты)

Тон: Эмпатичный, ясный, нетехнический. Фокус на влиянии и решении, а не на технических деталях.

«Ранее сегодня некоторые клиенты столкнулись с ошибками при попытке завершить покупки. Проблема длилась примерно 23 минуты и полностью устранена. Все заказы, размещённые в это время, были проверены, и никакие данные не были потеряны. Мы приносим извинения за неудобства и предприняли меры для предотвращения повторения.»

Внешняя коммуникация (партнёры и регуляторы)

Тон: Формальный, точный, полный. Может потребовать включения конкретных данных о влиянии, коренной причине и корректирующих действиях.

«9 февраля 2026 года, между 14:12 и 14:35 UTC, сервис оформления заказа испытал сбой, затронувший примерно 3,200 пользователей. Коренная причина: отсутствующий индекс базы данных вызвал таймауты запросов, исчерпавшие пул соединений. Данные клиентов не были скомпрометированы. Корректирующие действия включают алертинг сбоев миграций, тестирование производительности запросов и circuit breakers пула соединений. Полный отчёт RCA прилагается.»

Обновления страницы статуса

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

Частота обновлений по серьёзности:

Примеры обновлений страницы статуса:

Investigating:

«Мы расследуем сообщения об ошибках при оформлении заказа. Некоторые клиенты могут столкнуться с проблемами при завершении покупок. Наша команда активно работает над этим. Мы предоставим обновление в течение 15 минут.»

Identified:

«Мы определили причину ошибок оформления заказа и внедряем исправление. Покупки всё ещё могут не проходить у некоторых клиентов. Мы ожидаем решения в течение 30 минут.»

Monitoring:

«Исправление развёрнуто, и оформление заказа работает. Мы мониторим для подтверждения стабильности. Если у вас была неуспешная покупка, пожалуйста, попробуйте ещё раз.»

Resolved:

«Проблема с оформлением заказа полностью решена. Все сервисы работают в штатном режиме. Мы приносим извинения за перебои и предприняли меры для предотвращения повторения.»

Роль QA-инженера во время инцидентов

QA-инженеры привносят в реагирование на инциденты специфические навыки, которых нет у других ролей.

Во время инцидента

После инцидента

Чек-лист реагирования QA на инциденты

## QA Incident Response

### Immediate (during incident)
- [ ] Join the war room
- [ ] Reproduce the issue and document exact reproduction steps
- [ ] Assess scope: what features are affected beyond the reported issue?
- [ ] When a fix is ready, verify in staging before production deployment
- [ ] Verify the fix in production after deployment
- [ ] Run smoke tests on adjacent functionality

### Short-term (24-48 hours)
- [ ] Run full regression suite against production
- [ ] Write test cases that would have caught this issue
- [ ] Review and update deployment verification checklist
- [ ] Contribute to the incident report with testing perspective

### Medium-term (1-2 weeks)
- [ ] Automate the new test cases and add to CI
- [ ] Participate in the RCA / post-mortem meeting
- [ ] Update monitoring alerts based on lessons learned
- [ ] Review test strategy: does it need adjustment?

Тестирование после инцидента

Регрессионная верификация

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

Стратегия регрессионного тестирования после инцидента:

1. Smoke-тест самого исправления (повторяется ли заявленная проблема?)
2. Тестирование смежной функциональности (на что исправление могло повлиять?)
3. Запуск полного автоматизированного регрессионного набора
4. Целенаправленное исследовательское тестирование в затронутой области
5. Мониторинг продакшен-метрик в течение 24-48 часов после исправления

Настройка мониторинга

Каждый инцидент должен приводить к улучшению мониторинга. Работайте с DevOps, чтобы обеспечить:

• Конкретный режим отказа, вызвавший этот инцидент, имеет алерт
• Связанные режимы отказа имеют алерты
• Дашборды показывают релевантные метрики (использование пула соединений, задержка запросов, частота ошибок)
• Пороги алертов установлены достаточно низко, чтобы поймать проблему до того, как она станет видимой клиентам

Построение шаблонов и runbooks коммуникации при инцидентах

Библиотека шаблонов

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

Runbook коммуникации при инцидентах

# Incident Communication Runbook

## Step 1: Assess Severity
Use the severity matrix to classify the incident.
Severity determines communication cadence and audience.

## Step 2: Open Communication Channels
- Create a dedicated Slack channel: #inc-YYYYMMDD-brief-description
- Start a war room video call for Sev-1
- Designate an incident commander and a communication lead

## Step 3: First Status Update (within SLA)
- Post internal update using the status update template
- Update status page using the appropriate template
- Notify affected stakeholders via email (Sev-1 and Sev-2)

## Step 4: Ongoing Updates
- Follow the cadence for the severity level
- Each update includes: current status, impact, actions being taken, next update time
- Keep the Slack channel as the single source of truth

## Step 5: Resolution Communication
- Post final status update (internal and external)
- Update status page to "Resolved"
- Send resolution email to stakeholders
- Schedule post-mortem within 48 hours

## Step 6: Post-Incident
- Write incident report within 24 hours
- Conduct post-mortem within 1 week
- Complete RCA and track corrective actions
- Send customer communication if required

Практическое упражнение

1. Напишите последовательность обновлений страницы статуса (investigating, identified, monitoring, resolved) для недавнего инцидента в вашей компании
2. Создайте матрицу серьёзности, адаптированную к вашему продукту и организации
3. Напишите отчёт об инциденте для недавней продакшен-проблемы, используя шаблон выше
4. Подготовьте как внутреннюю, так и клиентскую коммуникацию для одного и того же инцидента. Обратите внимание на различия в детализации, тоне и техническом содержании.
5. Постройте runbook коммуникации при инцидентах для вашей команды, включая шаблоны, каналы и процедуры эскалации.