Англійська мова для DevOps: Runbooks, Post-Mortems, and Incident Calls

Інженери DevOps спілкуються під тиском: під час живих інцидентів, в пост-мортних звітах, прочитаних керівництвом, і в runbooks, використовуваних колегами о 3 годині ранку. Англійська, використана в цих документах і розмовах, є специфічною, точною і професійною, і вона значно відрізняється від загальної бізнес-англійської.

Цей посібник містить словник, фрази і шаблони документів для чотирьох основних сценаріїв комунікації DevOps: виклики інциденту, runbooks, пост- мертве і щоденні операції передачі.

---

Частина 1: Інциденти виклику мови

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

Основні слова для інциденту

Term	Meaning in incident context
incident	An unplanned interruption to a service or degradation of quality
P1 / SEV1	Severity level — P1 is the most critical (complete outage affecting all users)
blast radius	How many users or systems are affected
impact	The measurable effect: users affected, revenue loss, SLA breach
mitigation	Action taken to reduce impact while the root cause is investigated
workaround	A temporary fix that reduces impact but doesn’t address the root cause
root cause	The fundamental reason the incident occurred
rollback	Reverting to a previous known-good version
MTTR	Mean Time To Recovery — how long incidents typically take to resolve
on-call	The engineer currently responsible for responding to alerts
bridge	An incident call (voice/video channel where responders coordinate)
paging	Automatically alerting the on-call engineer via PagerDuty / OpsGenie
runbook	Step-by-step guide for handling a known problem type
escalation	Bringing in additional people or management due to severity or stalled progress
all-clear	Confirmation that the incident is resolved and service is restored

Фрази для мосту інциденту

Открытие вызова по инциденту:

“Це [ім’я], я командир аварії. Проблема в [короткий опис]. Наш поточний вплив становить [користувачі / служби, які зазнали впливу]. Давайте обійдемо — хто на цьому дзвінку?»

Опис проблеми:

“Ми бачимо підвищений рівень помилок в платіжній службі — близько 30% запитів на оформлення зазнають невдачі з 503.” “Розгортання в 14:32 UTC, здається, спричинило це — ми розслідуємо, чи це причина.” “Ми підтвердили, що база даних працює нормально — проблема, схоже, знаходиться у рівні програми.”

** Запит дій: **

• « [Ім’ я], чи можете ви перевірити журнали програм для вікна 14: 30–14: 45? » * “Давайте перенесемо розгортання 14:32, поки ми розслідуємо. [Ім’я], ви можете це розпочати?”
• « Нам потрібно збільшити обмеження на пул з’ єднань. [Назва], чи маєте ви доступ до зміни цього налаштування?» *

** Надання оновлення стану: **

• “Оновлення: ми встановили причину — витік пам’ яті у новому коді обробки з’ єднання. Rollback is in progress. *
• “Відновлення завершено. Частота помилок повертається до норми. Мониторинг протягом 10 хвилин перед оголошенням вирішеного. ”*

Завершение инцидента:

• “Рівень помилок повертається до базового. Ми оголошуємо, що це вирішено з 15:12 UTC. Тривалість удару становила приблизно 40 хвилин. Вскрытие будет назначено через 24 часа. Дякую всім»

---

Частина 2: Книга про хід

Runbook — це документована процедура для обробки певного сценарію операцій. Його читає хтось під стресом, можливо, о 3 годині ранку. Кожне слово має заслужити своє місце.

Принципи письма Runbook

1. ** Бути явним ** — припустити нульовий контекст. Не скажіть «перезапустити службу»; скажіть «запустити systemctl restart api-service на сервері додатків»
2. ** Включити очікувані виводи ** — що має побачити оператор, якщо крок буде успішним?
3. ** Включити шляхи помилок ** — що робити, якщо крок зазнає невдачі?
4. ** Використовувати дієслова з наказовим відмінком ** — Run, Check, Verify, Navigate, Execute, Copy
5. ** Уникайте жаргону без пояснень ** — не всі розуміють ваш контекст

Шаблон Runbook

# Runbook: [Descriptive Title of the Problem]

**Service:** [service name]
**Last updated:** 2026-03-01
**Owner:** [team name]
**Severity:** P1 / P2 / P3
**Estimated resolution time:** 10–20 minutes

---

## Symptoms

What does this look like when it's happening?

- Alert: [exact alert name from PagerDuty / Grafana]
- Users report: [description of user-facing impact]
- You might also see: [related symptoms in logs or dashboards]

---

## Diagnosis

### Step 1: Verify the alert is genuine

Run the following command to check current error rates:

\`\`\`bash
kubectl logs -l app=api-service --since=5m | grep ERROR | wc -l
\`\`\`

**If output > 50**: Service is actively failing. Continue to Step 2.  
**If output < 10**: Alert may be a false positive. Check [dashboard link] and 
continue monitoring.

### Step 2: Identify the failing component

Navigate to [Grafana dashboard link] and check:
- `api_response_errors_total` — is the spike limited to one endpoint?
- `db_connection_pool_usage` — is the pool exhausted?

---

## Resolution

### Option A: Database connection pool exhausted

1. Navigate to [AWS Console → RDS → Parameter Groups]
2. Increase `max_connections` from 100 to 150
3. Apply immediately (no reboot required for this parameter)
4. Verify in the database: `SELECT count(*) FROM pg_stat_activity;`
   — should drop below 80 connections within 2 minutes

**Expected outcome:** Error rate returns to baseline within 3 minutes.

### Option B: Memory leak — restart required

1. Scale down the deployment to 0 replicas:
   `kubectl scale deployment api-service --replicas=0`
2. Wait 30 seconds for connections to drain
3. Scale back up: `kubectl scale deployment api-service --replicas=3`
4. Verify pods are running: `kubectl get pods -l app=api-service`

**Expected outcome:** All 3 pods show STATUS "Running" within 2 minutes.

---

## Escalation

If neither option resolves the issue within 10 minutes:

- Page the backend team lead: [PagerDuty escalation policy]
- Join the #incidents Slack channel and post current status
- Create an incident in [incident management tool] and link this runbook

---

## Related runbooks

- [Database failover procedure]
- [Rollback procedure for app deployments]

## Post-incident actions

After resolving:
1. Update the MTTR metric in the [incident tracking spreadsheet]
2. Schedule a post-mortem if severity was P1 or P2
3. Consider whether this runbook needs updating

---

Частина 3: Пост-мортем письмо

Post-mortem (також називається переглядом інциденту або ретроспективою) є письмовим аналізом того, що сталося під час інциденту, чому і як запобігти повторенню. Безвинні пост-мортальні дослідження зосереджені на системах і процесах, а не на окремих помилках.

Невідома мова

Мова в пост-мортному визначає, чи відчувають люди себе психологічно безпечно бути чесними.

❌ Blame language	✅ Blameless language
”John pushed without running tests"	"A code change was merged without automated test coverage"
"The team failed to monitor the alert"	"The alert threshold was misconfigured and did not fire"
"Sarah caused the outage"	"A configuration change introduced a regression"
"We should have known better"	"The system did not provide adequate feedback to detect this before deployment”

Post-mortem шаблон

# Post-Mortem: [Service] [Type of Incident] — [Date]

**Status:** Draft / Final
**Severity:** P1 / P2
**Duration:** [start time UTC] → [end time UTC] ([N] minutes)
**Impact:** [number of users affected] / [% of traffic affected] / [revenue impact if known]
**Author:** [name]
**Reviewers:** [team lead, other relevant teams]

---

## Summary

A 2–3 sentence summary of what happened, the impact, and the resolution.
Written for an audience that includes non-technical leadership.

> *"On March 15 at 14:32 UTC, a deployment of the payment service introduced 
> a connection pool misconfiguration that caused 32% of payment requests to 
> fail. The incident lasted 41 minutes. Affected users were unable to complete 
> checkout; estimated revenue impact was $18,000. The issue was resolved by 
> rolling back to the previous deployment."*

---

## Timeline

All times in UTC.

| Time  | Event |
|-------|-------|
| 14:32 | Deployment of version 2.4.1 completed |
| 14:35 | Monitoring alert fired: payment error rate > 5% |
| 14:38 | On-call engineer [name] acknowledged the alert |
| 14:42 | Incident bridge opened; impact confirmed at ~30% error rate |
| 14:55 | Root cause identified: connection pool limit set to 10 (was 100) |
| 15:01 | Rollback initiated |
| 15:08 | Rollback complete; error rates returning to baseline |
| 15:13 | Service confirmed healthy; incident declared resolved |

---

## Root Cause

Describe the technical root cause and the contributing factors.

> *"A configuration change in the Helm chart for version 2.4.1 incorrectly 
> set the database connection pool limit to 10 instead of 100. Under 
> production load, the pool was exhausted within 3 minutes of deployment, 
> causing new requests to fail immediately with a connection timeout."*

---

## Contributing Factors

What conditions allowed this to happen?

- The misconfiguration was not caught in code review because the connection 
  pool limit is defined in a values.yaml file that is not typically reviewed.
- The staging environment uses a separate lower-traffic configuration that 
  masked the issue — the pool limit of 10 was sufficient for staging load 
  but not production load.
- No automated validation exists for connection pool parameters.

---

## What Went Well

Recognise things that worked correctly or helped recovery.

- The monitoring alert fired within 3 minutes of the issue occurring.
- The on-call engineer had the runbook for this failure mode and followed 
  it correctly.
- The rollback procedure completed successfully in under 8 minutes.

---

## What Went Poorly

Honest assessment of what should have prevented or shortened this.

- The staging configuration differs from production in ways that mask 
  configuration errors.
- The release process does not include a validation step for infrastructure 
  configuration parameters.
- Time-to-detect (3 minutes) was acceptable; time-to-acknowledge (3 minutes) 
  was acceptable; but time-to-identify root cause (17 minutes) was longer 
  than expected due to initially investigating application code rather than 
  configuration.

---

## Action Items

| Action | Owner | Due date | Priority |
|--------|-------|----------|----------|
| Add automated validation for critical config parameters in CI | [name] | 2026-04-01 | P1 |
| Align staging connection pool to match production defaults | [name] | 2026-03-22 | P1 |
| Add runbook for connection pool exhaustion detection | [name] | 2026-03-25 | P2 |
| Review all Helm chart values annotated with CHANGEME | [team] | 2026-04-15 | P2 |

---

Частина 4: Передача і операційне спілкування

Щоденне повідомлення Handoff (On-Call Rotation)

Під час передачі відповідальності за чергу між змінами або часовими поясами:

**On-Call Handoff — [Date] [Time] UTC**

Handing to: [name]
Current status: ✅ All services healthy / ⚠️ See below

**Active issues:**
- Minor elevated latency on the search service (P3, tracking in #ops)
  — not alerting but worth monitoring. Runbook: [link]

**Completed during shift:**
- Resolved P2 disk space alert on db-replica-02: expanded volume to 500GB
- Deployed version 3.2.1 to production at 10:45 UTC — healthy

**Upcoming:**
- Scheduled maintenance window tonight 23:00–01:00 UTC for database patching
  — [name] from DB team will lead; your role is to monitor application health

**Notes:**
- The staging environment is intentionally down until tomorrow
- PagerDuty on-call schedule updated: you're on until Friday 09:00 UTC

Повідомлення про ескалацію (Slack/Teams)

При ескаляції триваючого інциденту до більшої аудиторії:

:red_circle: **[P1 INCIDENT] Payment Service Degradation**

**Status:** Active (41 min)
**Impact:** ~30% of checkout requests failing
**Current action:** Rollback in progress (ETA: 5 min)

Responders: @on-call-engineer, @backend-team-lead
Bridge: [Zoom link]
Incident doc: [Confluence/Notion link]

Will update every 15 minutes or on status change.

---

Словник скорочених назв

** Рівні тяжкості: ** P1 (критична відмова) → P2 (значне погіршення) → P3 (незначна проблема) → P4 (косметичний / низький вплив)

Дієслова на часовій шкалі: запускати, підвищувати, знижувати, відновлювати, відкидати, підтверджувати, ескалювати, вирішувати, оголошувати

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

** Дієслова Runbook: ** * Запустити, Виконати, Навігувати, Перевірити, Перевірити, Застосувати, Моніторити, Ескаляція, Підтвердити *

---

Зв’язані ресурси

• Англійська для інженерів SRE
• Як писати пост-морт англійською
• Писання документації API англійською
• Словник: DevOps & Cloud