Dienstwechsel und Aufgabenübergabe

1) Warum Dienstwechsel formalisieren

Dienstwechsel sind ein kritischer Risikomoment: Der Kontext geht verloren, die Reaktionszeit steigt, Aktionen werden dupliziert. Der formalisierte Prozess reduziert MTTA/MTTR, eliminiert „vergessene Schwänze“ und sorgt für Compliance (wer wann Verantwortung übernommen hat).

2) Rollen und Abdeckungsmodell

Primary on-call (P1) - erste Antwort, Triage, Koordination bis IC kommt.
Secondary on-call (P2) ist ein Backup, das bei Überlastung/Eskalation angeschlossen wird.
Duty Manager/IC-of-the-day ist der Incident Leader für SEV-1 +.
Folge-der-Sonne (Multi-Zeitzone) oder Folge-dem-Mond (nächtliche Abdeckung in anderen Regionen).
Zeitfenster: Vermeiden Sie Freigaben/Risikoarbeit ± 30 Minuten nach der Schicht.

3) Rotationspläne (Beispiele)

24/7, 8-Stunden-Schichten: Morgen/Tag/Nacht, 3 Teams, P1 + P2.
24/7, 12-Stunden-Schichten: Weniger Schaltungen, höhere Ermüdungsgefahr - wir brauchen „Ausgleichsfenster“.
5 × 8 (Werktage) + Weekend Pool: tägliche primäre Abdeckung durch das Produktteam, Wochenende - Plattform/SRE.
Hybrid: Alltag „zur Bürozeit“, nachts/am Wochenende - Follow-the-sun.

Fairness-Regeln: Kalenderrotation, Urlaubs-/Urlaubsbuchhaltung, maximal N Nachtschichten pro Zeitraum.

4) Wechselkarte (Shift Handover Card)

• Wann und wer: 'Datum/Uhrzeit (UTC und Ort)', sendet → empfängt; Kontakte P1/P2.
• Status der Systeme: SLO/SLA Zusammenfassung, aktive Alerts, bekannte Degradationen.
• Offene Vorfälle: ID, SEV, aktueller Schritt, wer ist der Besitzer, nächste Aktion/ETA.
• Risiken pro Schichtfenster: geplante Arbeiten, Releases, Migrationen, Grenzzustände (Anbieterquoten).
• Kritische Tickets/Aufgaben: Priorität, Blocker, Deadlines.
• Kommunikation nach außen: aktive Beiträge auf der Status-Seite/Client-Updates.
• Bekannte Workarounds: mitgelieferte Degradationsflaggen, Zeitlimits.
• Domenica: Payment Provider/KYC/CDN - deren Status und Routing.
• Housekeeping: Wer morgen on-call, Fenster der Unzugänglichkeit von Menschen (Kundgebungen/Flüge).

5) Checkliste „Ich übergebe die Schicht“ (übergebende Seite)

• Aktualisierte Schaltkarte (alle Felder) und verankerte den Link im Kanal'# oncall-handover'.
• Übersetzt „mündliches Wissen“ in Tickets/Notizen; Keine Aufgaben „im Kopf“.
• Alle Vorfälle haben: SEV, Besitzer, nächster Schritt, Zeit für das nächste Update.
• Status-Seite und Client-Updates entsprechen dem Ist-Zustand.
• Deaktivierte laute/falsche Alerts (nach dem Verfahren) oder in der Karte markiert.
• Überprüfte die Quoten/Limits der externen Anbieter für das nächste Schichtfenster.
• Synchronisiert per Sprache/Video für 5-10 Minuten (wenn SEV-1 + aktiv ist).
• Ich habe die Tatsache der Übertragung (Bot/Ticket) aufgezeichnet, den Empfänger angegeben.

6) Checkliste „Ich akzeptiere die Schicht“ (Gastgeber)

• Ich habe die Karte gelesen und die offenen Fragen geklärt.
• Checked SLO/alerta dashboards in den letzten 2-4 Stunden.
• Bestätigte die Rolle der P1/P2 im Bot (Assign) und Pager-Sound/Kanäle.
• Übernahm den Besitz von aktiven Vorfällen und aktualisierte die Aktualisierungszeitgeber.
• Überprüfte geplante Arbeiten/Freigaben, stornierte riskante Operationen für die ersten 30 Minuten.
• Machte eine "Echobotschaft" an den Kanal: "Schicht angenommen, aktive Vorfälle:..., sl. Update in "....

7) Kommunikationsstandards

Каналы: `#oncall`, `#incident-warroom-<ID>`, `#statuspage`.
Update-Intervalle: SEV-0: 15 min, SEV-1: 30 min, SEV-2 +: 60 min.
Update-Format: Impact - Diagnose - Aktionen - Nächstes Update (Zeit).
Eskalation: Kein Fortschritt in N Minuten → TL/Plattform/DB/Sec über Matrix verbinden.
Klarheit des Besitzes: Jede Aktion hat einen Ausführenden und eine ETA.

8) Übergabe von Aufgaben (nicht Incident)

Übergabekriterien: Aufgabe blockiert SLO/Freigabe/Compliance oder läuft ab.
Gestaltung: Ticket mit „Definition des nächsten Schrittes“ und erwartetem Ergebnis, alle Artefakte (Protokolle/Bilder/Grafiken) sind beigefügt.
Priorisierung: Kanban-Swimlane „On-call Handover“.
Timing: Getriebe haben Due-Date; Verzögerungen werden dem Servicebesitzer eskaliert.

9) Automatisierung und Integration

Rotationskalender: Synchronisation mit Pager; bot veröffentlicht zu Beginn der Schicht ein „Wer ist der Diensthabende“.
ChatOps: '/handover start', autosampling Karten aus Quellen (SLO-Status, offene Vorfälle, Freigaben).
Ticketing: automatische Zuordnung des Eigentümers zum P1/P2; Tags „handover“.
Status-Seite: Brücke zu öffentlichen Updates mit Vorlagen.
Audit: Übertragungsprotokoll (wer/wann akzeptiert), Kommunikation mit SEV und Berichten.

10) Ermüdungsmanagement und Resilienz (Fatigue Management)

Grenzen: maximal X Pages/Stunde und Y in Folge in der Nacht - Übergang zu P2/Eskalation.
Quiet hours für unkritische Alerts (Tickets statt Paging).
Nachstunden Entschädigung und Post-Incident Rest.
Training und Shadowing für neue On-Call-Ingenieure.
Retrospektiven von lauten Schichten → Tuning von Alert und Playbooks.

11) Messgrößen Schalt- und Getriebequalität

Handover Defect Rate: Anteil der Vorfälle mit Kontextverlust beim Wechsel.
MTTA um die Schicht: Median/Spitzen ± 30 Minuten nach der Schaltung.
Fehlende/späte Updates: überfällige Updates durch SEV.
Alert Hygiene:% falsche Pages; Alerts ohne Runbook/Besitzer.
Load per shift: Pages/Stunde, durchschnittliche Dauer der aktiven Arbeit.
Zufriedenheit: NPS-Schicht (On-Call-Umfrage), Müdigkeit auf der Skala.

12) Verknüpfung mit Incident Management und RCA

Aktive Vorfälle werden zum Zeitpunkt des Wechsels nicht geschlossen; Verantwortung wird explizit übertragen und erfasst.
Im RCA ist der Abschnitt „Shift Impact“ obligatorisch: Gab es eine Kontextdrift, ein verspätetes Upgrade, eine doppelte Aktion?
CAPA: Verbesserung der Karte, Checklisten, Automatisierung, Schulung.

13) Sicherheit, Compliance und Datenschutz

PII/Geheimnisse sind im freien Text der Karten verboten; Links zu sicheren Speichern.
Die Zugriffe sind temporär: On-Call-Rechte werden an das Schichtfenster (JIT/JEA), Schlüsselrotation vergeben.
Audit-Trail: immutable-log wer hat die Karte und die Status-Seite gelesen/geändert.
Regulatorisch: Der Zeitpunkt der Kundenmeldungen wird in der Schichtkarte gesteuert.

14) Anti-Muster

„Ich werde es mündlich weitergeben“ ohne Karte/Tickets.
Freigabe genau zum Zeitpunkt des Wechsels ohne IC und Backup.
Pager bei einer Person „im Flugzeug/U-Bahn“ ohne P2.
Karte als „Laken“ ohne nächsten Schritt/ETA.
Triage auf persönlichen Chats - Informationen gehen verloren, ein Audit ist nicht möglich.
Es gibt keine Fixierung auf die Tatsache der Übertragung - Streitigkeiten „wer hat geantwortet“.

15) Vorlagen

Schichtkartenvorlage (komprimiert)

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.

Vorlage für Echobotschaften beim Empfang

[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) Einbettung in die tägliche Praxis

Daly-Shift-Ritual: 5-10 Minuten Synchronisation mit der Stimme bei aktiven Vorfällen.
Wöchentliches Karten-Audit: Stichprobenartig prüfen wir die Vollständigkeit/Aktualität.
Spieltage: Simulation von Schichten mit vielen parallelen Ereignissen.
Dock-Verzeichnis: Kartenvorlagen/Checklisten im Repository, Revue als Code.

17) Das Ergebnis

Gut organisierte Schaltungen und Getriebe sind die „Schmierung“ der gesamten Betriebsmaschine. Die Schichtkarte, die kurzen Synchronisationen, die strengen Checklisten, die Automatisierung und die Sorge um die Nachhaltigkeit des Teams machen riskante Momente zu einer Routine ohne Qualitätsverlust: Der Kontext bleibt erhalten, die Reaktionszeiten sind stabil und die Nutzer bemerken den Wechsel der Pflicht überhaupt nicht.