# Передача on-call з AI: формат 3 абзаців, що працює

> Передача чергування, яка реально передає контекст — від чергового, що йде, до того, що заступає, з AI-чернеткою і людським sign-off. Формат з трьох абзаців для команд 10-50 інженерів.

- Автор: Ярослав Максимович (Founder & CEO, AI Advisory Board)
- Опубліковано: 2026-06-19
- Оновлено: 2026-10-26
- Джерело: https://aiadvisoryboard.me/uk/blog/on-call-handoff-summary-with-ai

Після того як я бачив три інженерні організації поспіль, що спалили цілу on-call зміну, бо черговий, який ішов, написав "нічого серйозного, все зелене" в передачі і пропустив flapping-інтеграцію, що почала пейджити о 2 ночі — мій висновок такий: on-call передача — це найбільш недобудований ритуал у середніх інженерних командах. AI може це полагодити, не прибираючи людину.

## TL;DR

- Хороша передача має рівно три абзаци: відкриті інциденти, watch-items, контекст. Довше — пропускають очима, коротше — губиться нитка.
- AI чернетить передачу з попередніх 24 годин алертів, таймлайнів інцидентів, деплоїв і нотаток. Черговий, що йде, редагує і підписує. Той, що заступає, читає і acknowledges.
- Рамка Plan → Fact → Gap лягає чисто: що попередня зміна очікувала, що реально сталося, де живе дельта — і ця дельта є те, що наступній зміні треба знати.

## Чому більшість передач на чергуванні провалюються?

Бо черговий, що йде, втомлений, формат ad-hoc, і єдиний контроль якості — "чи наступний ack-нув". Команда з 20 інженерів на тижневих ротаціях робить це 52 рази на рік. Більшість команд ніколи не записали, як виглядає хороша передача.

> **Definition:** On-call handoff — структурована передача операційного контексту від інженера, що завершує зміну, тому, що починає. Включає відкриті інциденти, watch-items, нещодавні деплої і будь-які незавершені розслідування.

Failure mode передбачуваний. Черговий, що йде, друкує "all quiet, no incidents" у Slack наприкінці втомливого тижня. Той, що заступає, інтерпретує це як зелене світло. Через три години flapping-черга, яку попередній помітив-але-не-згадав, починає пейджити. Новий має нуль контексту і спалює годину на rediscovery перш ніж зрозуміє, що це вже відомий issue.

## Формат 3 абзаців

Абзац 1 — **відкриті інциденти**. Усе, що зараз активне, з severity, поточним owner, очікуваною наступною дією. Без історії, без минулих інцидентів з початку тижня, якщо вони не тривають.

Абзац 2 — **watch-items**. Те, що не інцидент, але може ним стати — flapping-інтеграції, деплої ще в canary, деградація third-party провайдера, підозрілі latency-криві, batch-роботи що ще не завершились. Кожен watch-item отримує одне речення "що перевірити першим".

Абзац 3 — **контекст**. Усе, що тому, що заступає, треба знати, і що не лізе в перші два — відомі maintenance-вікна, зміни ескалації, customer-ескалації що чекають на відповідь, оновлений runbook, флаг конфігу, який хтось перемкнув.

> **Definition:** Watch-item — сигнал, що ще не перейшов у територію інциденту, але має підвищену ймовірність це зробити. Не noise-алерт; ще не page.

Три абзаци. Не три речення, не три сторінки. Кожен абзац — 60-150 слів. Весь документ — одне Slack-повідомлення або один короткий doc.

## Що AI добре чернетить — і що пропускає?

24-годинне rolling-резюме від AI чисто тягне з чотирьох джерел: alert-системи (які алерти спрацювали, коли, чи закрилися), deployment-системи (що зашипилось), on-call каналу (що обговорювалось), incident-management інструменту (активні і вирішені інциденти).

AI-чернетка правильно подає таймлайн — краще за втомлену людину о 17 в п'ятницю. Надійно підбирає кластери алертів, що виглядають незв'язано, але causally linked, коректно резюмує deploy-вікна, відмічає які інциденти resolved vs auto-resolved без пояснення.

Систематично пропускає три речі. Перше — інтуїцію "я мав відчуття щодо тієї latency-кривої", яка не з'являється в жодному лозі. Друге — customer-контекст, що живе у Slack DM чи email, а не в on-call каналі. Третє — судження про те, який watch-item реально матиме значення, а який — шум.

Тому крок людського sign-off необговорюваний. AI чернетить. Черговий, що йде, редагує — додає інтуїцію, прибирає шум, флагує watch-items. Тоді підписує. Передача тепер коректна так, як ні AI, ні втомлена людина окремо не дадуть.

## Copy/paste шаблон передачі

```
## On-call передача — [DATE TIME] → [НАСТУПНИЙ]

Хто йде: [NAME]    Хто заступає: [NAME]
Покрита зміна: [START → END]
AI-чернетка створена: [TIME]   Відредаговано: [TIME]   Підписано: [Y/N]

### Відкриті інциденти
[60-150 слів. Для кожного: severity, owner, наступна дія, ETA.
"Нічого зараз не відкрито" — валідний повний абзац.]

### Watch-items
[60-150 слів. Для кожного: сигнал, що перевірити першим, поріг
ескалації. "Без активних watch-items, останні 24г чисті" — валідно.]

### Контекст
[60-150 слів. Maintenance, ескалації що чекають, зміни runbook,
перемикання config flag, усе що наступному треба і не вліз вище.]

Plan → Fact → Gap (1-2 речення):
- План цієї зміни був: [що очікувала попередня передача]
- Факт: [що реально сталося]
- Розрив для наступної зміни: [дельта варта знання]

Ack того, що заступає: [TIME + name]
```

Plan → Fact → Gap footer — це частина, яку більшість команд пропускає, і та, що робить передачу compound через зміни. Без неї кожна зміна починає з нуля. З нею — інженер третьої зміни бачить патерн, який помітив інженер першої.

> **Tool tip (AIAdvisoryBoard.me):** On-call передача — одне з найчистіших місць, де видно патерн Plan → Fact → Gap. Попередня зміна мала імпліцитний план ("цей canary має закінчитися вночі, без алертів"), наступна бачить факт ("canary закінчився, але tail latency на одному route подвоївся"), і розрив — це те, що треба розслідувати. Наша OS для щоденного управління піднімає такі розриви автоматично — через всю інженерію, не лише on-call — так що передачі в будь-якій функції слідують тому самому ритму. Подивіться, як працює 7-денна діагностика, на https://aiadvisoryboard.me/?lang=en.

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

- **План**: тижнева ротація, очікувано ~3 page на зміну за 4-тижневим baseline
- **Факт**: остання зміна мала 7 page, два з flapping-інтеграції поза SLO
- **Розрив**: owner інтеграції не пінганий; правило ескалації watch-item відсутнє
- Покриття AI-чернеткою передач: ~95% змін (ціль: 100% за 60 днів)
- Рівень людського sign-off: ~85% (15% надсилаються непідписаними — міряти і коучити вниз)
- Медіана часу на передачу: ~8 хвилин з AI-чернеткою vs ~25 хвилин без
- Ack рівень того, хто заступає: ~90% протягом 30 хв початку зміни
- Три watch-items з минулої зміни стали інцидентами цієї — рев'ю з командою в понеділок
- Два з тих трьох були помічені AI, але приглушені тим, що йшов — coaching-сигнал
- Жодних silent-змін (зеро передачі) за останні 4 тижні — це floor

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

90-інженерна SaaS-компанія з вісьмома on-call ротаціями втрачала приблизно одну зміну на місяць через "ми не знали про це". Медіана передачі була 40 слів і складалася з "тиха зміна, без інцидентів" або "дивись incident-канал". Увімкнули AI-чернеткові передачі у тижні один, зробили формат трьох абзаців єдиним прийнятним output-ом, додали Plan → Fact → Gap footer у тижні два. До тижня три середня довжина передачі стабілізувалася на ~280 словах через три абзаци. Час на написання передач упав з ~25 хвилин до ~8 на зміну, бо AI-чернетка була на 80% готова. Інциденти "ми не знали про це" впали з приблизно одного на місяць до приблизно одного на квартал, причому більшість тих, що лишилися, були справді нові сигнали, які ні людина, ні AI не могли передбачити. Командний ефект: менше п'ятничного жаху, швидше відновлення контексту в понеділок.

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

> **Tool tip (AIAdvisoryBoard.me):** Причина, чому on-call передача живе чи вмирає на Plan → Fact → Gap footer — та сама, чому щоденне управління живе чи вмирає на ньому. "План" чергового що йде — це очікування попередньої передачі; "факт" — те, що сталося; "розрив" — те, що наступному треба. Наша система виводить цей патерн автоматично через інженерію, ops, sales і фінанси — щодня, на одну сторінку. Дивіться 7-денну діагностику на https://aiadvisoryboard.me/?lang=en.

## FAQ

**Передача має бути Slack-повідомленням чи doc?**
Slack-повідомлення, якщо команда живе в Slack; doc, якщо в docs. Не борися з існуючою поверхнею. Важливо, щоб було пошуковано пізніше — і Slack, і Google Docs працюють; Confluence теж, якщо команда його реально читає.

**Що якщо черговий не згоден з AI-чернеткою?**
Це і є суть кроку sign-off. Інженер редагує. Прибирає, додає, переформульовує. Тоді підписує. Якщо інженер не згоден з чернеткою 80% разів — джерела даних AI неправильні. Фіксь це, не формат.

**Чи потрібно це команді з 5 інженерів?**
Ймовірно ні. Формат трьох абзаців допомагає, коли у вас 8+ інженерів або 3+ ротації, бо саме тоді контекст перестає вміщатися в голові однієї людини. Для 5 інженерів — Slack-тред і ранковий понеділковий standup покриють.

**Як це взаємодіє з incident retros?**
Чисто. Передача фіксує state момент-у-часі; retro покриває lifecycle конкретного інциденту. Watch-items, що стали інцидентами, годують retros; action items з retro повертаються в абзац контексту наступної передачі.

**Чи AI-чернеткам почнуть надмірно довіряти з часом?**
Так, якщо не міряти. Трекайте edit-rate sign-off щотижня — якщо людина редагує менше 20% чернетки, або AI справді хороший, або людина rubber-stamping. Sample-check кілька щомісяця, щоб зрозуміти, що з двох.

## Висновок

On-call передача — мала, часта, недобудована. AI прибирає податок на написання; людина додає судження; формат трьох абзаців робить результат читабельним за 90 секунд. Plan → Fact → Gap перетворює кожну передачу на накопичений контекст замість fresh start.

Встановіть формат трьох абзаців цього тижня. Підключіть AI-чернетку з alert + deploy + on-call джерел до п'ятниці. Вимагайте людський sign-off на кожну передачу, перш ніж наступна зміна може її ack-нути.

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

---

Цитуючи, посилайтесь на https://aiadvisoryboard.me/uk/blog/on-call-handoff-summary-with-ai. Більше статей: https://aiadvisoryboard.me/uk/blog