Ротація команд і змін

1) Цілі ротації

• рівномірний розподіл пейджів і нічних годин;
• гарантована заміна при форс-мажорі;
• прозорість графіків, відпусток і обмежень;
• дотримання вимог SLA/комплаєнсу та збереження аудиту.

2) Ролі та покриття

P1 (Primary on-call): перша відповідь, тріаж, синхронізація з IC.
P2 (Secondary on-call): бекап для перевантаження/ескалацій.
IC-of-the-day / Duty Manager: лідер при SEV-1 +, координація рішень.
Observer/Shadow: навчання в режимі «тінь» без пейджів.

• уникати релізів ± 30 хвилин від зміни;
• для складних вікон тримати два активних слота (P1 + P2);
• IC має виділену зміну, не поєднує P1.

3) Моделі ротацій

24/7 з 8-годинними змінами: ранок/день/ніч (3 бригади). Мінімум втоми, більше перемикань.
24/7 з 12-годинними змінами: менше перемикань, потрібна компенсація і суворі ліміти.
Follow-the-sun: регіони передають покриття за часовими поясами; менше нічних пейджів.
Follow-the-moon: нічне покриття переноситься в «далекий» регіон для навантаження поза локальним прайм-таймом.
Week-on / Week-off: один тиждень on-call, потім тиждень без пейджів (для зрілих команд і низького шуму).

4) Правила справедливості і стійкості

Квоти ночей/вихідних: не більше N ночей і M вихідних змін на людину за період.
Баланс пейджів: якщо на інженера припадає> цільового порогу за період - перерозподіл/ремедіейшн.
Заборона одинаків: нічні вікна тільки P1 + P2.
Вікна недоступності: плануються заздалегідь (відпустка/хвороба/навчання), графік перераховується автоматично.
Shadow-періоди: кожен новий on-call проходить ≥ 2 змін у тіні.

5) Планування та публікація графіка

Горизонт планування: 6-8 тижнів, перегляд - кожні 2 тижні.
Загальний календар ротацій (загальнодоступний read-only), в кожному слоті - P1/P2/IC/Shadow, контакти.
Заміни (swap) оформляються тікетом/заявкою і підтверджуються бридж-ботом.
Публікація: за T-14 днів мінімум, зміни - з повідомленням команди.

6) Процедури передачі (handover)

Картка зміни (обов'язкові поля): активні інциденти (ID/SEV/власник), наступний крок/ЕТА, ризики вікна (релізи/міграції/квоти), стан SLO, включені фіч-прапори деградації, статус-сторінка/коммс.
Чек-лист «передаю»: картка оновлена, всі усні знання → тікети, таймери апдейтів виставлені, підтверджений контакт P2.
Чек-лист «приймаю»: прочитав картку, перевірив дашборди за 2-4 години, прийняв володіння інцидентами, зробив відлуння в канал.

7) Управління втомою (fatigue)

Ліміти пейджів/год і/або зміну, авто-ескалація на P2 при перевищенні.
Quiet Hours для P2/P3 сигналів (страждають тільки Page-критичні).
Post-incident rest: обов'язкові відгули після важких ночей (SEV-1 +).
Щотижневий alert review → зниження шуму, правка правил.
Моніторинг навантаження: графік «пейджі/чол» і настрій команди (NPS змін).

8) Безпека та комплаєнс

JIT/JEA-доступи: права on-call видаються тільки на вікно зміни.
Аудит-слід: хто чергував, хто прийняв, які дії виконувалися; незмінне зберігання.
Чергування з чутливими операціями (PII/платежі): окремий клас змін і допусків; заборона особистих пристроїв, SSO + mTLS.
Точки контакту з Legal/PR/Privacy відзначені в картці зміни.

9) Автоматизація

Календар ↔ пейджер ↔ ChatOps: бот публікує «хто on-call», дозволяє '/swap', створює картку handover з джерел (дашборди, тікети, релізи).
Перевірка готовності на початку зміни: звук пейджера, VPN/SSO, доступи, зв'язок.
Шаблони документів: SOP/Runbook для рутин і інцидентів; Автоспорти в алертах.
Інтеграція з релізами: реліз-анотації → тимчасові придушення неключових алертів на перші 30 хвилин.

10) Метрики якості ротацій

MTTA/MTTR навколо зміни (± 30 хвилин від перемикань).
Handover Defect Rate - частка інцидентів з втратою контексту в зміну.
Alerts per on-call hour (медіана/95-й перцентиль),% actionable.
Load per person - пейджі/чол/тиждень; дисперсія між учасниками.
Missed/Late Updates - прострочення по Comms SLA.
Swap rate і причини (втома/відпустка/конфлікти).
NPS зміни (за коротким опитуванням) і тренд.

11) Шаблони розкладів

А. 24/7, 8-годинні (3 бригади)

Brigade A: 08: 00-16: 00
Brigade B: 16: 00-00: 00
Brigade C: 00: 00-08: 00
Each team: P1 + P2, IC on a separate schedule (day slot)
Rotation: A→B→C every week; weekend moves in a circle

Б. follow-the-sun (3 регіони)

EU: 07:00–15:00      AMER: 15:00–23:00      APAC: 23:00–07:00 (UTC)
Each region: P1 local, P2 neighboring
IC: coincides with active region; transfer 15 minutes before shift

В. week-on/Week-off (низький шум)

Week 1: Team X (P1/P2) Week 2: Team Y
Daily IC common to both
Limit: no more than 2 consecutive weeks for one person

12) Чек-листи

Перед публікацією графіка

• Покриття 24/7 без «дірок», P1 + P2 в кожному слоті.
• Враховані відпустки/навчання/обмеження доступності.
• Баланс ночей/вихідних справедливий.
• Призначені IC і Shadow.
• Авто-синхронізація з пейджером/календарем включена.

Зміна почалася

• P1/P2/IC підтвердили присутність (бот/чат).
• Перевірені доступи, зв'язок, дашборди.
• Прийнята картка handover, відправлено відлуння.

Зміна завершена

• Картка handover оновлена і закрита.
• Інциденти передані з next step/ETA.
• Виконаний короткий AAR, зафіксовані поліпшення (якщо були збої).

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

Самотній P1 вночі без бекапа.
Публікація графіка на тиждень вперед без горизонту і заміни.
Релізи в момент зміни без IC і гейтів.
«Усні» передачі без картки і тікетів.
Нульова компенсація/відгули після важких ночей.
Відсутність аудиту swap'ів і причин замін.
Ротація без навчання: новий on-call відразу «в бій».

14) Дорожня карта впровадження (4-6 тижнів)

1. Нед. 1: інвентаризація покриття, вибір моделі (24/7 або follow-the-sun), призначення ролей.
2. Нед. 2: запуск календаря + пейджера + бота, шаблони handover/SOP.
3. Нед. 3: пілот 2-3 тижневих циклу, збір метрик (alerts/hour, MTTA навколо змін).
4. Нед. 4: alert review, тюнінг шумів і квот, введення Shadow-змін.
5. Нед. 5–6: формалізація компенсації/quiet hours, звіти для менеджменту, автоматизація swap'ів.

15) Підсумок

Ротація - це процес, а не Excel: прозорі графіки, ролі та handover-картки; автоматизація календаря і пейджера; справедливі правила і ліміти втоми; метрики якості та регулярні огляди. При такому підході зміни стають передбачуваними, люди - стійкими, а користувачі і партнери не помічають, що команда змінюється по годинах.