Як написати звіт про інцидент бази даних англійською мовою

Звіт про інцидент бази даних (також званий пост-інциденту перегляд або постмортем) є письмовим описом того, що пішло не так, чому це сталося, і як запобігти його повторенню. Написання чіткого, професійного звіту про інцидент є однією з найважливіших навичок спілкування для DBA або інженера даних. У цьому підручнику ви дізнаєтеся про повну структуру мови з словником, шаблонами і готовими до використання фразами.

---

Що таке звіт про інцидент бази даних?

Звіт про інцидент бази даних (також: перегляд після інциденту (PIR), постмортем, або аналіз кореневої причини (RCA)) є документом, написаним після відключення бази даних, зниження продуктивності або події цілісності даних.

Її цілі:

1. ** Прозорість ** — інформувати зацікавлених осіб про те, що сталося
2. Accountability — документація хронології та хто що зробив
3. ** Навчання ** — визначити основну причину
4. ** Захист ** — визначає елементи дій, які запобігають повторенню

“Ми повинні повідомити зацікавленим сторонам про це впродовж 48 годин після відключення. Звіт повинен бути фактичним, бездоганним і включати конкретні дії»

** Ключовий принцип: культура безвинності. ** Хороші звітування про інциденти зосереджені на системах, процесах і умовах — а не на звинуваченні осіб.

---

Структура звіту про інцидент

Розділ 1: Резюме події

Почніть з резюме високого рівня, яке кожен може прочитати за 30 секунд.

Шаблон:**

## Incident Summary

**Incident ID**: INC-2026-047
**Date**: 2026-04-14
**Duration**: 2h 17m (09:43 UTC – 11:58 UTCh 17 minutes
**Severity**: P1 (Critical)
**Impact**: Orders database replica lag exceeded 4 hours; reporting dashboards
            displayed stale data for ~3.5 hours; 127 business users affected
**Status**: Resolved

Словник:

** Серйозність ** — класифікація пріоритету/ впливу інциденту. Спільні рівні:

• ** P1 / Критичний ** — повна відмова, велика втрата даних, вплив на прибуток
• ** P2 / Висока ** — значний зниження якості або часткове відключення
• ** P3 / Середній ** — погіршена продуктивність, недоступні дрібні можливості
• ** P4 / Низька ** — косметичний або мінімальний вплив

** Тривалість ** — загальний час, який пройшов з моменту виявлення до розв’ язання.

** Вплив ** — хто був вражений і як. Завжди кількісно оцінюйте, де це можливо: кількість користувачів, транзакцій, рівень помилок, прибуток.

---

Розділ 2: Часова лінія

Точний хронологічний опис події. Використовувати штампи часу UTC.

Шаблон:**

## Timeline (all times UTC)

| Time  | Event |
|-------|-------|
| 09:43 | Monitoring alert fires: replica lag > 60 seconds (threshold: 30s) |
| 09:47 | On-call DBA acknowledges alert |
| 09:52 | Investigation begins; identified that replica I/O write latency spiked |
| 10:05 | Root cause identified: a long-running analytical query blocked replication |
| 10:12 | Long-running query terminated |
| 10:30 | Replica lag begins decreasing |
| 11:58 | Replica lag returns to < 5 seconds; incident resolved |
| 13:00 | Stakeholder update sent |
| 14:30 | Incident report draft completed |

** Підказки щодо мови для графіка часу: **

• Використовувати пасивний або активний голос послідовно: * « Сигнал викликано » * або * « Спостереження за сигналом викликано » *
• Будьте конкретними щодо того, що було * виявлено *, * ідентифіковано *, * реалізовано * і * вирішено * — це різні події
• Включити події зв’ язку: * “Повідомлено зацікавленим особам” *, * “Відкрито місток інциденту” *

---

Розділ 3: Аналіз кореневої причини

Це аналітична основа звіту. Поясніть, що спричинило інцидент і чому.

** Методи аналізу кореневої причини: **

** 5 Whys ** — запитуйте « Чому? » кілька разів, поки не дістанетесь до системної кореневої причини:

The orders database replica was delayed →
  Why? A long-running analytical query held a table lock →
    Why? The query ran on the primary instead of the read replica →
      Why? The ETL job was misconfigured to use the primary connection string →
        Why? The ETL job configuration wasn't reviewed during the recent
             infrastructure migration
Root cause: Missing configuration review checklist for infrastructure migrations

Шаблон:**

## Root Cause Analysis

**Immediate cause**: A long-running analytical query acquired a table lock on the
primary database, blocking replication for 2+ hours.

**Contributing factors**:
1. The ETL pipeline was misconfigured to connect to the primary instead of the
   read replica after last month's infrastructure migration.
2. There was no alerting on ETL connection endpoints — the misconfiguration
   was not detected for 3 weeks.
3. The replica lag alert threshold (30s) was too high to catch the problem early.

**Root cause**: The infrastructure migration runbook did not include a step to
validate ETL connection configurations after a primary/replica endpoint change.

---

Розділ 4: Оцінка впливу

Визначте кількісний вплив бізнесу якомога точніше.

Шаблон:**

## Impact Assessment

**Data integrity**: No data was lost or corrupted. The replica contained stale
                   data for 3.5 hours; no mutations were made during this window.

**User impact**: 127 users of the reporting dashboard received data that was
               up to 4 hours out of date.

**Business impact**: Three scheduled order fulfilment reports were generated
                    with stale data. Manual re-generation was required post-recovery.
                    Estimated additional engineering time: 3 hours.

**Customer impact**: No external customer impact detected. Internal operations
                    teams were affected.

**Revenue impact**: None identified directly; estimated indirect operational cost:
                   €2,400 in engineer time.

---

Розділ 5: Що вийшло добре

Включіть те, що працювало - системи, процеси і люди, які обмежували вплив. Це створює позитивну культуру навчання.

Шаблон:**

## What Went Well

- Monitoring detected the replica lag within 4 minutes of onset
- On-call DBA responded within 4 minutes of the alert
- Incident communication was clear — stakeholders received updates at
  T+20min, T+60min, and T+2h
- The read replica correctly isolated the impact — the primary was unaffected
  and write operations continued normally throughout

---

Розділ 6: Що можна поліпшити

Чесна оцінка прогалин у процесі, інструментах або знаннях.

Шаблон:**

## What Could Be Improved

- ETL connection configuration was not validated after migration
- No alert existed for ETL job connection endpoint changes
- The replica lag alert threshold (30s) was too low to provide early warning
  before business impact — we were alerted after impact, not before
- The on-call runbook did not include steps for diagnosing replica lag due to
  lock contention specifically

---

Розділ 7: Елементи дій

Кожен звіт про інцидент має закінчуватися конкретними, власними, обмеженими часом елементами дій.

Шаблон:**

## Action Items

| ID | Action | Owner | Priority | Due Date |
|----|--------|-------|----------|----------|
| AI-1 | Add ETL connection endpoint validation to migration runbook | Alex Chen | High | 2026-04-21 |
| AI-2 | Create alert for ETL job connection endpoint misconfigurations | Maria Lopez | High | 2026-04-21 |
| AI-3 | Reduce replica lag alert threshold from 30s to 10s for P1 escalation | Alex Chen | Medium | 2026-04-28 |
| AI-4 | Add lock contention section to on-call replica lag runbook | DBA team | Medium | 2026-05-05 |
| AI-5 | Review all ETL jobs for connection string correctness post-migration | Maria Lopez | High | 2026-04-18 |

** Мова для елементів дій: **

• Використовуйте наказову форму: “Додати…”, “Створити…”, “Зменшити…”, “Переглянути…”
• Призначати одного власника для кожного елемента, а не команду
• Встановіть конкретну дату закінчення — не « скоро » або « наступний квартал »

---

Корисні фрази

** Для резюме: **

• “Ця подія призвела до [X] хвилин погіршення обслуговування для [Y] користувачів.”
• “Не було втрати даних або пошкодження.”

** Для розділу кореневої причини: **

• “Близькою причиною було… проте, корінною причиною було…”
• “Це стан не було виявлено, тому що…”
• “Внесок фактора був відсутність…”

** Для розділу уроків: **

• “Цей інцидент виявив прогалини в нашому…”
• “Ми не очікували, що…”
• • “Тривога була викликана після того, як удар вже розпочався - нам потрібно раніше виявити.” *

---

Practice

Поглибте свій словниковий запас для обміну інформацією з адміністратором бази даних за допомогою ** Набір вправ з адміністрування баз даних. Name ** і ** ДБЯ навчальний шлях **.