Шаблон incident retro, який AI заповнює з логів і Slack

Якщо ви інженерний лід, який бодай раз сидів увечері в п'ятницю над Slack-каналом, намагаючись реконструювати timeline інциденту до понеділкового retro — ви вже знаєте суть: timeline-реконструкція — це найдорожча малоцінна робота у вашому тижні. AI робить її краще і швидше за вас.

Чому підготовка до retro займає так багато часу?

Бо дані живуть у п'яти місцях, і людина, що пише retro, має перемикатися між ними. Slack — що люди казали, alert-система — що спрацювало, deploy log — що зашипилось, status page — що бачили клієнти, incident-management — що було declared. Кожне має свій формат часу і свій filtering UI.

Definition: Incident retro — структуроване рев'ю production-інциденту після resolution, з метою витягти уроки і призначити follow-up дії. Також post-mortem чи post-incident review.

Рамка Plan → Fact → Gap лягає чисто: система мала очікувану поведінку (Plan), видала несподівану (Fact), і розрив — там, де живе learning. Але побачити розрив чітко неможливо, поки timeline не реконструйований акуратно — а реконструкція з'їдає вашу п'ятницю.

Що AI заповнює добре — а що не чіпає

AI чисто тягне з чотирьох структурованих джерел: alert-система (що спрацювало, коли), deploy-система (що зашипилось, ким), incident-канал (Slack-повідомлення з timestamp + автором), status-сторінка (публічний timeline customer-видимого state). Реконструює timeline хронологічно, дедупає near-simultaneous події, відмічає прогалини, де нічого не залогувалось.

Чого AI не може — і не має пробувати — це вирішити, що інцидент означає. "Чому" живе на шар глибше за timeline. Query latency spike о 14:32 — це факт; "у нас не було SLO на tail latency для цього route, і canary не впав, бо canary перевіряє лише median" — це урок. Тільки люди бачать другу частину.

Definition: Blameless retro — рамка retro, що трактує людську помилку як симптом системної умови, що дозволила цю помилку, а не як персональний фейл. Обов'язкова культура для команд, що вчаться повторно.

Інше, що AI не має писати: action items. Модель може запропонувати follow-ups, але ownership і пріоритизація — від людей у кімнаті. AI-згенеровані action items мають разючий патерн бути технічно правильними і операційно безхазяйними — ніхто не володіє, ніхто не планує, гниють у Jira-беклозі.

Шаблон

Три секції AI заповнює, три секції — люди. Одна сторінка.

## Incident Retro — [INCIDENT ID + TITLE]

**Дата:** [INCIDENT DATE]   **Дата retro:** [DATE]
**Severity:** [SEV1 / SEV2 / SEV3]
**Customer impact:** [DESCRIBE]
**Detection:** [Monitor / customer / on-call inspection]

---

### AI-FILLED — Timeline (хронологічно, UTC)
[Авто з alerts + deploys + Slack incident channel + status-page.
Кожен рядок: timestamp, джерело, summary, лінк. Редагується
автором retro на коректність перед meeting.]

### AI-FILLED — Метрики detection + response
- Time-to-detect (TTD): [N min]
- Time-to-acknowledge (TTA): [N min]
- Time-to-mitigate (TTM): [N min]
- Time-to-resolve (TTR): [N hr/min]

### AI-FILLED — Surrounding context
[Що задеплоєно за попередні 24г, які алерти спрацювали за
попередні 72г на суміжних сервісах, що флагувала попередня
on-call передача.]

---

### HUMAN — Plan → Fact → Gap
- **Plan**: що система мала зробити
- **Fact**: що вона зробила насправді
- **Gap**: де живе урок

### HUMAN — Root cause + contributing factors
[Multi-cause аналіз. Не "root cause = інженер X". Blameless.]

### HUMAN — Action items
| # | Action | Owner | Due | Status |
[Кожна дія: явний owner (людина, не команда), реалістична дата,
ticket linked. Жодного action item без названої людини.]

### HUMAN — Що ми навчилися і хочемо зберегти
[1-3 речення. Compounding-knowledge шар.]

Поділ на дві секції — AI-filled, human-filled — це те, що захищає retro від дрифту в "хай AI напише все". Поділ enforce-нутий шаблоном, не надією.

Tool tip (AIAdvisoryBoard.me): Причина, чому більшість retro action items гниють — це що шар Plan → Fact → Gap не записаний чітко настільки, щоб хтось побачив той самий розрив через два місяці. Наша OS для щоденного управління піднімає розриви через всю компанію на одній сторінці щодня — інженерія, ops, sales, фінанси — і incident learning ллється в операційну реальність замість вмирати в Confluence. 7-денна діагностика показує патерн розривів у ваших даних, перш ніж ви на щось підписуєтеся. https://aiadvisoryboard.me/?lang=en.

Manager scan (приклад 2-хвилинного digest)

• План: ~4 години підготовки до retro на SEV2, ~8 годин на SEV1
• Факт: AI-filled timeline скорочує підготовку до ~1.5 год на SEV2, ~3 на SEV1
• Розрив: рівень завершення action items не зрушив — owner-дисципліна вузьке місце, не час підготовки
• Точність AI-filled секцій: ~92% по timeline (sample-check 1 retro/місяць)
• Action items з названим людським owner: ціль 100%, поточно ~70% — коучити до 100%
• Action items завершені до due date: ~60% — піднімати команді щотижня
• "Repeat incidents за 90 днів" — єдина метрика результату retro, що має значення
• Retros проведені протягом 5 робочих днів інциденту: ціль ~95%
• Retros із принаймні одним пунктом "що ми хочемо зберегти": ціль 100%
• Score blameless-тону (self-assessed учасниками): відстежувати тренд

Micro-case (що змінюється за 7-14 днів)

110-інженерний fintech з вісьмома сервісами і рівнем SEV2-або-вище ~3 на місяць мав підготовку retro 4-8 годин на інцидент, і інженер, якому випадала коротка соломинка, часто відкладав на 2-3 тижні. Половина retro була stale на момент проведення. Команда підключила AI-filled шаблон у тижні один — timeline з PagerDuty + GitHub Actions деплоїв + #inc Slack каналу + Statuspage — і встановила правило: підготовка може відбуватися тільки в AI-filled секціях; human-секції заповнюються наживо на мітингу. За два тижні підготовка впала до ~90 хвилин на SEV2, retros відбувалися протягом 5 робочих днів інциденту у ~95% випадків, і рівень "repeat incident за 90 днів" впав з ~двох на квартал до ~нуля в наступному кварталі. Compounding-ефект був не у збереженому часі — а у тому, що крок іменування розриву почав відбуватися, поки контекст ще свіжий.

Note on this case: Цей приклад ілюстративний — на основі типових патернів у компаніях 30-500 співробітників, не один названий клієнт. Конкретні числа — округлені наближення поширених діапазонів, не гарантії.

Tool tip (AIAdvisoryBoard.me): Патерн retro — це один зріз тієї самої картини, яку ми піднімаємо через всю компанію — Plan → Fact → Gap, щодня, на одній сторінці, для кожної функції. Коли incident learning, sales handoff, ops bottleneck і finance variance видно в одному view — засновники перестають читати п'ять status-апдейтів на день і починають бачити один. 7-денна діагностика показує, як це виглядає у ваших даних. https://aiadvisoryboard.me/?lang=en.

FAQ

Чи буде AI-filled timeline колись помилковим? Так — зазвичай через неповне джерело даних. Status-page лагає, Slack-повідомлення редагуються, деплої одного сервісу виглядають як деплої іншого. Sample-check одне retro на місяць — failure modes будуть малі і консистентні.

Що якщо інцидент не залогований у Slack? Тоді human-filled секція буде довшою. AI заповнює, що може зі структурованих даних; відсутня історія каналу = більше реконструкції від тих, хто був. Це також процесний gap варто полагодити — логувати інциденти в відомому каналі як правило.

Як це масштабується до 500-інженерної організації? Той самий шаблон, але треба per-service чи per-domain retros замість org-wide. AI-filled частина масштабується лінійно з джерелами даних; human-filled залишається на одній годині, бо саме стільки уваги люди мають.

Чи це замінює retro-meeting? Ні. Retro-meeting — це де Plan → Fact → Gap, root cause і action items дебатуються. Шаблон лише прибирає податок "дай скопіюю timestamps годину" заздалегідь. Час meeting падає з 90 хвилин до 45, бо timeline вже там.

А action item follow-through? Інша проблема. Швидше заповнення шаблонів не змусить owner-ів робити action items. Трекайте completion rate щотижня, піднімайте на ревʼю інженерного менеджера, прикріплюйте definition-of-done до кожного. Частина цього — проблема щоденного управління, не retro.

Висновок

Підготовка retro — неправильне місце витрачати п'ятничний вечір. AI заповнює timeline акуратно, люди володіють Plan → Fact → Gap і діями, retro-meeting стає коротшим і гострішим. Compounding-перемога — у називанні розриву, не в timeline.

Підключіть AI-filled секцію до alert + deploy + Slack + status-page цього тижня. Передайте ownership action items названим людям, не командам. Трекайте rate повторних інцидентів як єдину outcome-метрику.

Якщо хочете систему, що виводить Plan → Fact → Gap автоматично — щодня, через інженерію і решту компанії — подивіться 7-денну діагностику на https://aiadvisoryboard.me/?lang=en.