Смена дежурств и передача задач

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, текущий шаг, кто владелец, следующее действие/ETA.
• Риски на окно смены: плановые работы, релизы, миграции, лимитные состояния (квоты провайдеров).
• Критичные тикеты/задачи: приоритет, блокеры, крайние сроки.
• Коммуникации вовне: активные посты на статус-странице/клиентские апдейты.
• Известные обходные пути: включенные фич-флаги деградации, временные лимиты.
• Доменика: провайдеры платежей/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 подряд ночью — переход к P2/эскалация.
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) Итог

Хорошо организованные смены и передачи — это “смазка” всей операционной машины. Карточка смены, короткие синхронизации, строгие чек-листы, автоматизация и забота об устойчивости команды превращают рискованные моменты в рутину без потери качества: контекст сохраняется, время реакции стабильно, а пользователи не замечают смены дежурных вовсе.