Zmiana obowiązków i przeniesienie zadań

1) Dlaczego formalizować zmiany obowiązków

Zmiana obowiązku jest krytycznym momentem ryzyka: kontekst jest tracony, czas reakcji rośnie, działania są powielane. Sformalizowany proces zmniejsza MTTA/MTTR, eliminuje „zapomniane ogony” i zapewnia zgodność (kto przyjął odpowiedzialność i kiedy).

2) Role i model pokrycia

Podstawowy dyżur (P1) - pierwsza odpowiedź, triage, koordynacja przed przybyciem IC.
Wtórny dyżur (P2) - kopia zapasowa, łączy się podczas przeciążenia/eskalacji.
Duty Manager/IC-of-the-day jest liderem incydentu dla SEV-1 +.
Follow-the-sun (strefa wielorazowa) lub Follow-the-moon (zasięg nocny w innych regionach).
Okna czasowe: unikaj zwolnień/ryzykownej pracy ± 30 minut od zmiany.

3) Harmonogram rotacji (przykłady)

24/7, 8-godzinne zmiany: rano/dzień/noc, 3 brygady, P1 + P2.
24/7, 12-godzinne zmiany: mniej przełączników, większe ryzyko zmęczenia - potrzeba „okien kompensacyjnych”.
5 × 8 (dni robocze) + Weekend Pool: podstawowy zasięg dnia według zespołu produktów, weekend - platforma/SRE.
Hybryda: tygodnie „w biurze”, noce/weekendy - Follow-the-sun.

Zasady uczciwości: rotacja kalendarza, księgowość wakacyjna/wakacyjna, maksymalne nocne zmiany na okres.

4) Shift Handover Card

• Kiedy i kto: „Data/czas (UTC i lokalne)”, przekazuje → akceptuje; P1/P2 kontakty.
• Stan systemów: streszczenie SLO/SLA, aktywne wpisy, znana degradacja.
• Otwarte incydenty: ID, SEV, aktualny krok, kto jest właścicielem, następna akcja/ETA.
• Ryzyko dla okna zmiany: planowane prace, zwolnienia, migracje, stany graniczne (kwoty dostawcy).
• Bilety/zadania krytyczne: priorytet, blokery, terminy.
• Komunikacja na zewnątrz: aktywne posty na stronie stanu/aktualizacji klienta.
• Znane obroty pracy: w tym flagi funkcji degradacji, terminy.
• Domenica: dostawcy płatności/KYC/CDN - ich statusy i routing.
• Sprzątanie: kto jest jutro dyżurny, ludzie niedostępne okna (wiece/loty).

5) Lista kontrolna „Hand over shift” (strona wydająca)

• Zaktualizowano kartę zmiany (wszystkie pola) i naprawiono link w kanale „# oncall-handover”.
• Przetłumaczone „wiedza ustna” na bilety/notatki; żadnych zadań „w głowie”.
• Wszystkie incydenty mają: SEV, właściciel, następny krok, następny czas aktualizacji.
• Strona stanu i aktualizacje klienta odpowiadają faktycznemu statusowi.
• Wyłączony hałas/fałszywe wpisy (zgodnie z procedurą) lub oznaczone na karcie.
• Sprawdzono kwoty/limity dostawców zewnętrznych dla następnego okna zmiany.
• Zsynchronizowany przez głos/wideo przez 5-10 minut (jeśli SEV-1 + jest aktywny).
• Zarejestrowano fakt przeniesienia (bot/bilet), wskazał odbiorcę.

6) Lista kontrolna „Akceptuję zmianę” (strona przyjmująca)

• Przeczytaj kartę, wyjaśnione otwarte pytania.
• Sprawdzone tablice SLO/alarmowe w ciągu ostatnich 2-4 godzin.
• Potwierdziła rolę P1/P2 w bot (przypisać) i dźwięk/kanały pager.
• Przejęty odpowiedzialność za aktywne incydenty i zaktualizowane timery aktualizacji.
• Sprawdzone planowane prace/wydania, odwołane ryzykowne operacje na pierwsze 30 minut.
• Zrobił "echo wiadomości" do kanału: "Wziąłem zmianę, aktywne incydenty:..., słowa. aktualizacja w języku angielskim "...

7) Normy komunikacyjne

Канала: '# oncall', '# incident-warroom- <ID>', '# statuspage'.
Przedziały aktualizacji: SEV-0: 15 min, SEV-1: 30 min, SEV-2 +: 60 min.
Format aktualizacji: Impact - Diagnostyka - Działania - Następna aktualizacja (czas).
Eskalacja: brak postępu w N minut → podłączyć TL/Platform/DB/Sec przez matrycę.
Przejrzystość własności: Każda akcja ma wykonawcę i ETA.

8) Przeniesienie zadań (nie incydent)

Kryteria transferu: bloki zadań SLO/release/compliance lub wygasa.
Projekt: bilet z „definicją następnego kroku” i oczekiwanym wynikiem, wszystkie artefakty (dzienniki/zdjęcia/wykresy) są dołączone.
Priorytet: Kanban - pływak „Dyżurne przekazanie”.
Terminy: Transmisje mają termin zapadalności; opóźnienia są zwiększane do właściciela usługi.

9) Automatyzacja i integracja

Kalendarz rotacyjny: synchronizacja z pagerem; bot publikuje „który jest na służbie” na początku zmiany.
ChatOps: '/handover start ', automatyczna kolekcja kart ze źródeł (statusy SLO, otwarte incydenty, wydania).
Bilety: automatyczne przypisanie właściciela przez P1/P2; „przekazać” znaczniki.
Strona statusu: most do publicznych aktualizacji z szablonami.
Audyt: dziennik transmisji (kto/kiedy został przyjęty), komunikacja z SEV i sprawozdania.

10) Zarządzanie zmęczeniem

Limity: maksymalnie X stron/godzinę i Y z rzędu w nocy - przejdź do P2/escalation.
Ciche godziny dla niepodważalnych wpisów (bilety zamiast przywoływania).
Odszkodowanie po godzinach i odpoczynek po incydencie.
Szkolenie i cień dla nowych dyżurnych inżynierów.
Retrospektywy hałaśliwych przesunięć → dostrajanie wpisów i playbooks.

11) Wskaźniki jakości zmian i przepustek

Wskaźnik wad przekazania: odsetek incydentów z utratą kontekstu podczas zmiany.
MTTA wokół zmiany: mediana/piki ± 30 min od przełącznika.
Nieaktualne/późne aktualizacje: aktualizacje SEV wygasły.
Higiena alarmu:% fałszywe strony; wpisy bez runbooka/właściciela.
Obciążenie na zmianę: strony/godzinę, średni czas aktywnej pracy.
Satysfakcja: zmiany NPS (ankieta dyżurna), zmęczenie na skalę.

12) Komunikacja z zarządzaniem incydentami i RCA

Aktywne incydenty nie są zamknięte w czasie zmiany; odpowiedzialność jest wyraźnie przekazywana i ustalana.
W RCA wymagana jest sekcja „Shift Impact”: czy istnieje dryf kontekstowy, późna aktualizacja, podwójna akcja.
CAPA: usprawnienie kart, listy kontrolne, automatyzacja, szkolenie.

13) Bezpieczeństwo, zgodność i poufność

PII/tajemnice są zabronione w wolnym tekście kart; linki do bezpiecznych repozytoriów.
Tymczasowe dostęp: prawa dyżuru są wydawane dla okna zmiany (JIT/JEA), rotacja klucza.
Ścieżka audytu: niezmienny dziennik, który przeczytał/zmienił kartę i stronę stanu.
Regulacja: warunki powiadomień klienta są kontrolowane w karcie zmiany.

14) Anty-wzory

„Dam to ustnie” bez karty/biletu.
Zwolnić dokładnie w momencie zmiany bez IC i kopii zapasowej.
Pager w osobie „w samolocie/metrze” bez P2.
Karta jako „arkusz” bez kolejnego kroku/ETA.
Triage na osobistych czatach - informacje są utracone, audyt jest niemożliwy.
Nie ma zapisu o fakcie przeniesienia - „kto odpowiedział” spory.

15) Szablony

Szablon karty shift (sprężony)

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.

Odbierz szablon Echo

[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) Wbudowanie w codzienną praktykę

Codzienny rytuał zmiany: 5-10 minut synchronizacji głosu w aktywnych incydentach.
Cotygodniowy audyt kart: selektywnie sprawdzić kompletność/trafność.
Dni gry: symulacja zmian z wieloma równoległymi zdarzeniami.
Katalog Dock: szablony kart/list kontrolnych w repozytorium, sprawdź jako kod.

17) Sedno sprawy

Dobrze zorganizowane zmiany i transfery są „smarowaniem” całej maszyny operacyjnej. Karta zmiany, krótkie synchronizacje, ścisłe listy kontrolne, automatyzacja i troska o stabilność zespołu zmieniają ryzykowne momenty w rutynowe bez utraty jakości: kontekst jest zachowany, czas reakcji jest stabilny, a użytkownicy w ogóle nie zauważają zmiany obowiązków.