Зміна чергувань і передача завдань

1) Навіщо формалізувати зміну чергувань

Зміна чергувань - критичний момент ризику: втрачається контекст, зростає час реакції, дублюються дії. Формалізований процес знижує MTTA/MTTR, виключає «забуті хвости» і забезпечує комплаєнс (хто і коли прийняв відповідальність).

2) Ролі та модель покриття

Primary on-call (P1) - перша відповідь, тріаж, координація до приходу IC.
Secondary on-call (P2) - бекап, підключається при перевантаженні/ескалації.
Duty Manager/IC-of-the-day - лідер інциденту для SEV-1 +.
Follow-the-sun (мульти-таймзона) або Follow-the-moon (нічне покриття в інших регіонах).
Тимчасові вікна: уникати релізів/ризикових робіт ± 30 хв від зміни.

3) Графіки ротацій (приклади)

24/7, 8-годинні зміни: ранок/день/ніч, 3 бригади, P1 + P2.
24/7, 12-годинні зміни: менше перемикань, вище ризик втоми - потрібні «компенсаційні вікна».
5 × 8 (робочі дні) + Weekend Pool: денне первинне покриття командою продукту, вихідні - платформа/SRE.
Гібрид: будні «в офісний час», ночами/вихідні - Follow-the-sun.

Правила справедливості: ротація за календарем, облік свят/відпусток, максимум N нічних змін за період.

4) Картка зміни (Shift Handover Card)

• Коли і хто: 'Дата/час (UTC і локаль)', передає → приймає; Контакти P1/P2.
• Статус систем: зведення SLO/SLA, активні алерти, відомі деградації.
• Відкриті інциденти: ID, SEV, поточний крок, хто власник, наступна дія/ЕТА.
• Ризики на вікно зміни: планові роботи, релізи, міграції, лімітні стани (квоти провайдерів).
• Критичні тікети/завдання: пріоритет, блокери, крайні терміни.
• Комунікації зовні: активні пости на статус-сторінці/клієнтські апдейти.
• Відомі обхідні шляхи: включені фіч-прапори деградації, тимчасові ліміти.
• Доменіка: провайдери платежів/KYC/CDN - їх статуси і маршрутизація.
• Housekeeping: хто on-call завтра, вікна недоступності людей (мітинги/перельоти).

5) Чек-лист «Передаю зміну» (віддаюча сторона)

• Оновив картку зміни (всі поля) і закріпив посилання в каналі «#oncall -handover».
• Перевів «усні знання» в тікети/нотатки; немає завдань «в голові».
• Всі інциденти мають: SEV, власника, наступний крок, час наступного апдейта.
• Статус-сторінка і клієнтські апдейти відповідають фактичному стану.
• Відключив галасливі/помилкові алерти (за процедурою) або зазначив у картці.
• Перевірив квоти/ліміти зовнішніх провайдерів на вікно наступної зміни.
• Синхронізувався голосом/відеозв'язком 5-10 хвилин (якщо SEV-1 + активний).
• Зафіксував факт передачі (бот/тікет), вказав приймача.

6) Чек-лист «Приймаю зміну» (приймаюча сторона)

• Прочитав картку, уточнив відкриті питання.
• Перевірив дашборди SLO/алерти за останні 2-4 години.
• Підтвердив роль P1/P2 в боті (assign) і звук/канали пейджера.
• Прийняв володіння активними інцидентами і оновив таймери апдейтів.
• Звірив планові роботи/релізи, скасував ризиковані операції на перші 30 хв.
• Зробив «ехо-повідомлення» в канал: "Зміну прийняв, активні інциденти: ..., сл. апдейт в "....

7) Стандарти комунікацій

Канали: `#oncall`, `#incident-warroom-<ID>`, `#statuspage`.
Інтервали апдейтів: SEV-0: 15 хв, SEV-1: 30 хв, SEV-2 +: 60 хв.
Формат апдейту: Імпакт - Діагностика - Дії - Наступний апдейт (час).
Ескалація: немає прогресу за N хвилин → підключити TL/Platform/DB/Sec по матриці.
Ясність володіння: кожна дія має виконавця і ETA.

8) Передача завдань (не інцидентних)

Критерії передачі: завдання блокує SLO/реліз/комплаєнс або закінчується термін.
Оформлення: тікет з «definition of next step» і очікуваним результатом, всі артефакти (логи/знімки/графіки) прикладені.
Пріоритетизація: Kanban- swimlane “On-call Handover”.
Терміни: у передач є due-date; прострочення ескалуються власнику сервісу.

9) Автоматизація та інтеграції

Календар ротацій: синхронізація з пейджером; бот публікує «хто черговий» на початку зміни.
ChatOps: '/handover start', автозбір картки з джерел (статуси SLO, відкриті інциденти, релізи).
Тікетинг: автоматичне призначення власника за P1/P2; теги «handover».
Статус-сторінка: бридж до публічних апдейтів з шаблонами.
Аудит: журнал передачі (хто/коли прийняв), зв'язок з SEV і звітами.

10) Управління втомою і стійкість (Fatigue Management)

Ліміти: максимум X пейджів/годину і Y поспіль вночі - перехід до Р2/ескалація.
Quiet hours для некритичних алертів (тікети замість пейджингу).
After-hours компенсація і post-incident rest.
Тренування і shadowing для нових on-call інженерів.
Ретроспективи галасливих змін → тюнінг алертів і плейбуків.

11) Метрики якості змін і передач

Handover Defect Rate: частка інцидентів з втратою контексту при зміні.
MTTA навколо зміни: медіана/піки за ± 30 хв від перемикання.
Missed/late updates: прострочені апдейти по SEV.
Alert Hygiene: % помилкових пейджів; алерти без runbook/власника.
Load per shift: пейджі/год, середня тривалість активної роботи.
Satisfaction: NPS зміни (опитування on-call), втома за шкалою.

12) Зв'язок з інцидент-менеджментом і RCA

Активні інциденти не закриваються в момент зміни; відповідальність явно передається і фіксується.
У RCA обов'язковий розділ «Вплив зміни»: чи був дрейф контексту, запізнення апдейта, дубль дій.
CAPA: поліпшення картки, чек-листів, автоматизації, навчання.

13) Безпека, комплаєнс і конфіденційність

PII/секрети заборонені у вільному тексті карток; посилання на безпечні сховища.
Доступи тимчасові: on-call-права видаються на вікно зміни (JIT/JEA), ротація ключів.
Аудит-слід: immutable-лог хто читав/змінював картку і статус-сторінку.
Регуляторика: терміни клієнтських повідомлень контролюються в картці зміни.

14) Анти-патерни

«Передам усно» без картки/тікетів.
Реліз рівно в момент зміни без IC і бекапа.
Пейджер у людини «в літаку/метро» без P2.
Картка як «простирадло» без next step/ETA.
Тріаж на особистих чатах - інформація втрачається, аудит неможливий.
Немає фіксації факту передачі - суперечки «хто відповідав».

15) Шаблони

Шаблон картки зміни (стиснутий)

Shift: 2025-11-01 18: 00-02: 00 UTC (local: Europe/Kyiv 20: 00-04: 00)
P1: @duty-alex      P2: @duty-olga      IC: @ic-of-day
SLO Summary: API ok, Payments p95↑ by 12% (observation)
Active Incidents:
- INC-3421 (SEV-2): KYC's success is falling in the TR region. Owner: @ p1. Trail. step: switch 20% of traffic to provider B, update at 20:30 UTC.
Risks/jobs: 22:00 UTC - index migration to ClickHouse (read-only), owner @ data-ivan.
Providers: PSP-A green, KYC-A partially degrades TR.
Status page: post from 17:50 UTC; next update 20:30 UTC.
Next steps P1: 1) Check KYC switching effect; 2) Prepare canary 5% for v2 payments. 14.

Шаблон єхо-повідомлення при прийомі

[Took over shift] 18:02 UTC. Active: INC-3421 (SEV-2). Trail. update 18:30 UTC.
Checked alerts in 2h - no new P1s. Status page availability approx.

16) Вбудовування в щоденну практику

Дейлі-ритуал зміни: 5-10 хвилин синхронізація голосом при активних інцидентах.
Щотижневий аудит карток: вибірково перевіряємо повноту/актуальність.
Game-days: симуляція змін з безліччю паралельних подій.
Док-каталог: шаблони карток/чек-листів в репозиторії, рев'ю як коду.

17) Підсумок

Добре організовані зміни і передачі - це «мастило» всієї операційної машини. Картка зміни, короткі синхронізації, строгі чек-листи, автоматизація і турбота про стійкість команди перетворюють ризиковані моменти в рутину без втрати якості: контекст зберігається, час реакції стабільно, а користувачі не помічають зміни чергових зовсім.