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

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

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

Бо черговий, що йде, втомлений, формат 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.