Bereitschaft scheitert am Dienstplan, nicht am Werkzeug
Der typische Einstieg in die Bereitschaft sieht so aus: Ein Monitoring wird eingerichtet, die Alarme laufen auf das Handy der Person, die sich am besten auskennt, und der Rest des Teams hofft, dass es gut geht. Das trägt - solange nichts passiert. Sobald der erste nächtliche Ausfall kommt, zeigt sich die Lücke: Es gibt keine Vertretung, keine dokumentierte Reaktion, keine Regel, wann eskaliert wird. Die eine Person, die alles weiß, wird zum Engpass und zum Risiko zugleich. Fällt sie aus - Urlaub, Krankheit, Kündigung - fällt die gesamte Bereitschaft mit ihr aus.
Das Google-SRE-Team beschreibt Bereitschaft ausdrücklich nicht als Nebentätigkeit, sondern als planbare Arbeit mit festem Zeitbudget. Die Vorgabe lautet dort, dass mindestens 50 Prozent der Zeit eines SRE in Engineering-Arbeit fließen und höchstens 25 Prozent auf Bereitschaft entfallen sollen (Google SRE Book, Kapitel 11). Diese Zahlen sind kein Komfortversprechen, sondern eine Kapazitätsrechnung: Wer mehr als ein Viertel seiner Zeit in Bereitschaft verbringt, hat keine Zeit mehr, die Ursachen zu beheben, die ihn nachts wecken. Die Rotation wird dann zu einem sich selbst verstärkenden Kreislauf - mehr Vorfälle, weniger Zeit für Stabilität, wieder mehr Vorfälle.
Ein zweiter Punkt aus derselben Quelle ist ebenso zentral: Drei Ressourcen senken den Stress in der Bereitschaft spürbar - klar definierte Eskalationspfade, festgelegte Verfahren im Incident-Management und eine Kultur der schuldfreien Postmortems (Google SRE Book, Kapitel 11). Fehlt eines davon, trägt die Person im Dienst nicht nur die technische Last, sondern zusätzlich die Unsicherheit darüber, ob ein Fehler ihr persönlich angelastet wird. Genau diese Unsicherheit macht aus einer anstrengenden Nacht eine belastende - und aus einem lösbaren Personalthema eine Fluktuation.
Wenn Bereitschaft nicht als eigene Position im Zeitbudget auftaucht, wird sie unsichtbar. Das Google-SRE-Modell reserviert sie explizit: höchstens 25 Prozent der Arbeitszeit für Bereitschaft, mindestens 50 Prozent für Engineering-Arbeit (Google SRE Book, Kapitel 11). Was nicht geplant ist, wird nicht begrenzt - und was nicht begrenzt ist, wächst.
Wie viele Personen eine tragfähige Rotation braucht
Die erste konkrete Frage jedes kleinen Teams lautet: Reichen wir zu dritt? Die Antwort der SRE-Literatur ist unbequem klar. Für eine Rotation rund um die Uhr an einem einzigen Standort nennt das Site Reliability Workbook eine Mindestgröße von neun Personen - acht als Basis plus eine Person als Puffer für Urlaub, Krankheit und Fluktuation (Google SRE Workbook, Kapitel 8). Das SRE Book selbst nennt für eine Single-Site-Rotation mit wochenweisen Schichten und je einer primären und einer sekundären Bereitschaft eine Mindestzahl von acht Personen (Google SRE Book, Kapitel 11). Beide Zahlen beschreiben denselben Sachverhalt aus zwei Blickwinkeln: Rund um die Uhr ist mit einer Handvoll Menschen nicht dauerhaft abzudecken.
Verteilt sich das Team über zwei Standorte in unterschiedlichen Zeitzonen, sinkt der Bedarf je Standort deutlich: Dann genügen sechs Personen pro Standort - fünf plus ein Puffer (Google SRE Workbook, Kapitel 8). Der Grund ist einfach: Ein Follow-the-Sun-Modell braucht keine Nachtschicht, weil die Nacht des einen Standorts der Arbeitstag des anderen ist. Für die meisten deutschen KMU ist das keine realistische Option, weshalb die Zahl neun der ehrliche Maßstab bleibt.
| Modell | Mindestgröße | Nachtschicht nötig | Quelle |
|---|---|---|---|
| Single-Site, rund um die Uhr | 9 Personen (8 + 1 Puffer) | Ja | Google SRE Workbook, Kapitel 8 |
| Single-Site, Wochenschichten primär und sekundär | 8 Personen | Ja | Google SRE Book, Kapitel 11 |
| Multi-Site, zwei Zeitzonen | 6 Personen je Standort (5 + 1) | Nein | Google SRE Workbook, Kapitel 8 |
| Kleines Team unter 6 Personen | Nur mit bewusst reduziertem Abdeckungsfenster | Abhängig vom Umfang | Projekterfahrung |
Was tun kleine Teams, die diese Zahlen nicht erreichen? Der ehrlichste Weg führt nicht über mehr Disziplin, sondern über weniger Anspruch. Ein Team von vier Personen kann eine belastbare Bereitschaft betreiben - aber nicht rund um die Uhr für alles. Sinnvoll ist dann, das Abdeckungsfenster bewusst zu begrenzen, etwa auf 07:00 bis 23:00, und für den Rest der Nacht nur eine sehr kleine, klar definierte Menge kundenrelevanter Ausfälle wecken zu lassen. Alles Übrige wartet bis zum Morgen. Diese Entscheidung gehört dokumentiert und mit der Geschäftsführung abgestimmt - nicht stillschweigend getroffen und dann von der Person im Dienst allein verantwortet (Projekterfahrung).
Beide Google-Modelle rechnen ausdrücklich mit einer Person mehr als dem rechnerischen Minimum: neun statt acht bei Single-Site, sechs statt fünf je Standort bei Multi-Site (Google SRE Workbook, Kapitel 8). Der Puffer fängt Urlaub, Krankheit und Kündigungen ab. Wer ohne ihn plant, hat keine Rotation, sondern eine Rotation im Ausnahmezustand - jede Abwesenheit kippt den Plan.
Zwei Incidents pro Schicht als Kapazitätsgrenze
Die wichtigste Zahl dieses Artikels ist eine Obergrenze, keine Zielgröße. Das Google-SRE-Team hat als Maximum zwei Incidents pro 12-Stunden-Bereitschaftsschicht etabliert (Google SRE Book, Kapitel 11; Google SRE Workbook, Kapitel 8). Diese Grenze ist keine Bauchentscheidung, sondern das Ergebnis einer Rechnung: Einen Incident vollständig zu bearbeiten - Ursachenanalyse, Behebung und Nacharbeit wie Postmortem und Bugfix - kostet nach dieser Schätzung rund sechs Stunden (Google SRE Book, Kapitel 11). Zwei Incidents à sechs Stunden füllen eine 12-Stunden-Schicht exakt aus. Ein dritter Vorfall passt schlicht nicht mehr hinein - er wird dann zwangsläufig oberflächlich abgearbeitet.
Wichtig ist dabei die Zähleinheit: Ein Incident ist ein Problem, unabhängig davon, wie viele Alarme dafür feuern (Google SRE Workbook, Kapitel 8). Ein Datenbankausfall, der fünfzehn Alarme über acht Dienste auslöst, ist ein Incident - nicht fünfzehn. Wer stattdessen Alarme zählt, misst die Lautstärke des Monitorings und nicht die Belastung des Teams. Umgekehrt gilt aber auch: Fünfzehn Meldungen für einen Vorfall sind ein eigenes Problem, weil die Person im Dienst zuerst das Rauschen sortieren muss, bevor sie mit der Arbeit beginnen kann.
Ebenso wichtig ist die Verteilung. Das SRE Book weist ausdrücklich darauf hin, dass die Verteilung der Pages über die Zeit sehr flach sein sollte, mit einem wahrscheinlichen Medianwert von null (Google SRE Book, Kapitel 11). Eine durchschnittliche Belastung von zwei Incidents pro Schicht klingt tragbar, bedeutet in der Realität aber häufig: sechs ruhige Schichten und eine, in der acht Vorfälle gleichzeitig eskalieren. Der Durchschnitt verdeckt genau die Nächte, an denen Menschen verschleißen. Wer die Belastung bewerten will, sollte deshalb nicht den Mittelwert betrachten, sondern die schlimmste Schicht der letzten acht Wochen.
Treten regelmäßig mehr als zwei Ereignisse pro Bereitschaftsschicht auf, können die Vorfälle nicht mehr gründlich untersucht werden, und die Ingenieure sind so überlastet, dass sie aus diesen Ereignissen nichts mehr lernen.
— Google - Site Reliability Engineering, Kapitel 11 (Being On-Call), sinngemäß übersetzt
Wird die Marke von zwei Incidents je 12-Stunden-Schicht dauerhaft überschritten, ist die naheliegende Reaktion, mehr Personen in die Rotation zu holen. Das ist meist die falsche Schlussfolgerung. Die Grenze ist eine Aussage über das System: Es alarmiert zu oft, zu unpräzise - oder es ist tatsächlich zu instabil. Mehr Menschen verteilen die Last nur breiter, sie senken sie nicht. Wie sich das Grundrauschen an der Wurzel reduzieren lässt, behandelt der Beitrag zur richtigen Konfiguration von Monitoring-Alerts.
Welcher Alarm darf nachts wecken
Die Frage, welcher Vorfall um drei Uhr morgens ein Telefon klingeln lassen darf, entscheidet über die Tragfähigkeit der gesamten Rotation. Das Prinzip dahinter formuliert das Site Reliability Workbook in einem Satz: Jeder Alarm soll unmittelbar handlungsrelevant sein - es muss eine Handlung geben, die ein Mensch sofort nach Erhalt des Alarms ausführt und die das System nicht selbst ausführen kann (Google SRE Workbook, Kapitel 8). An diesem Test scheitern die meisten nächtlichen Alarme. Ein Zertifikat, das in 20 Tagen abläuft, erfordert keine Handlung um drei Uhr morgens. Ein Checkout, der keine Bestellung mehr annimmt, sehr wohl.
In der Praxis hat sich eine dreistufige Klassifikation bewährt, wie sie das Workbook am Beispiel eines Betreibers beschreibt: P1 feuert sofort als Page, ist SLO-relevant und unmittelbar handlungsfähig; P2 geht als E-Mail zum nächsten Arbeitstag und betrifft Dinge ohne direkte Kundenwirkung oder mit begrenztem Umfang; P3 ist rein informativ und lebt auf einem Dashboard, ohne jemanden zu benachrichtigen (Google SRE Workbook, Kapitel 8). Entscheidend ist nicht die Benennung, sondern die Disziplin: Jeder Alarm bekommt genau eine Stufe, und die Stufe P1 bleibt knapp. Eine P1-Liste, die auf zwanzig Einträge anwächst, ist keine Klassifikation mehr, sondern eine Wunschliste.
| Stufe | Kanal | Beispiel | Weckt nachts |
|---|---|---|---|
| P1 - Page | Telefon, Push, Pager | Checkout nimmt keine Bestellungen an; Website von mehreren Standorten nicht erreichbar | Ja |
| P2 - Ticket | E-Mail zum nächsten Arbeitstag | Zertifikat läuft in 20 Tagen ab; Antwortzeit über Budget, aber ohne Ausfall | Nein |
| P3 - Information | Dashboard, kein Versand | Einzelner Check-Ausschlag ohne Bestätigung durch weitere Standorte | Nein |
Die Trennlinie lässt sich in einem Satz formulieren: Nachts weckt, was Kunden gerade jetzt betrifft und was ein Mensch gerade jetzt beheben kann. Alles andere wartet. Ein ablaufendes Zertifikat ist das Musterbeispiel der zweiten Kategorie - es ist wichtig, aber die Frist beträgt Wochen, nicht Stunden. Sinnvoll ist hier ein gestufter Vorlauf, der frühzeitig als Ticket auftaucht und erst dann eskaliert, wenn die Restlaufzeit tatsächlich kritisch wird. Wie sich das im Detail aufsetzen lässt, beschreibt der Beitrag zum SSL-Zertifikatsmonitoring.
- Betrifft es Kunden gerade jetzt? Wenn nein, ist es kein Page - unabhängig davon, wie dringend es sich anfühlt
- Kann ein Mensch es gerade jetzt beheben? Wartet die Handlung ohnehin bis zum Morgen, wartet der Alarm ebenfalls
- Ist der Vorfall bestätigt? Ein einzelner Ausschlag von einem Prüfpunkt genügt nicht - erst die Bestätigung durch weitere Standorte macht daraus einen Ausfall, wie der Beitrag zum Zähmen von Flapping-Alerts zeigt
- Gibt es ein Runbook? Ein Alarm ohne dokumentierte Reaktion weckt jemanden, der dann selbst improvisieren muss
- Läuft ein Wartungsfenster? Geplante Arbeiten dürfen keinen Page auslösen; wie sich das sauber trennen lässt, behandelt der Beitrag zu Wartungsfenstern und Fehlalarmen
Das Runbook: die Antwort auf die Frage um drei Uhr
Ein Runbook ist die Differenz zwischen einem Alarm, den jede Person im Team abarbeiten kann, und einem, der zwingend die eine Expertin braucht. Das Site Reliability Workbook ist an dieser Stelle eindeutig: Das Playbook soll zusammen mit dem Alarm entstehen, nicht danach (Google SRE Workbook, Kapitel 8). Ein Alarm ohne Runbook ist ein unfertiger Alarm. Diese Regel klingt streng, ist aber der wirksamste Hebel gegen die Situation, in der eine geweckte Person um drei Uhr morgens erst einmal recherchieren muss, was ihr System ihr gerade eigentlich sagen will.
Der Inhalt eines Runbooks ist im Workbook konkret umrissen: übergeordnete Anweisungen zur Reaktion auf den automatisierten Alarm, eine Erläuterung von Schweregrad und Nutzerauswirkung, Vorschläge zur Fehlersuche sowie mögliche Maßnahmen zur Eindämmung (Google SRE Workbook, Kapitel 8). Übersetzt in den Alltag eines kleinen Teams ergeben sich daraus sechs Bausteine, die auf eine Bildschirmseite passen sollten:
Klartext-Beschreibung des Alarms und der Bedingung, die ihn ausgelöst hat - keine Wiederholung des Metriknamens, sondern dessen Bedeutung.
Schweregrad und konkrete Nutzerauswirkung: Wer kann gerade was nicht tun? Diese Angabe entscheidet über das Tempo der Reaktion.
Die zwei bis drei Stellen, an denen die Ursache typischerweise sichtbar wird - Dashboard, Log, Statusseite des Dienstleisters.
Maßnahmen zur Eindämmung, die die Wirkung stoppen, bevor die Ursache verstanden ist - Rollback, Umleitung, Abschalten eines Features.
Die klare Bedingung, ab der die nächste Stufe gerufen wird - nach Zeit, nach Umfang oder nach ausbleibendem Fortschritt.
Die Nacharbeit: Postmortem, Ticket, Anpassung des Alarms. Der Vorfall ist erst zu Ende, wenn die Ursache adressiert ist.
Das Runbook ist zugleich das Werkzeug, mit dem neue Personen in die Rotation kommen. Google beschreibt für die Einarbeitung eine Liste von rund 24 Schwerpunkten, die ein neues Teammitglied vor der ersten eigenen Bereitschaft geübt haben sollte - von der Administration von Produktionsjobs über das Abziehen von Traffic und das Zurückrollen von Software bis zum Verständnis der Dienstarchitektur (Google SRE Workbook, Kapitel 8). Für ein kleines Team fällt diese Liste kürzer aus, das Prinzip bleibt aber gleich: Niemand geht in die erste Nachtschicht, ohne die häufigsten Handgriffe einmal bei Tageslicht geübt zu haben. Eine Rotation, in der die Hälfte der Beteiligten nur weiterleiten kann, ist keine Rotation, sondern eine Warteschleife.
Rufbereitschaft ist in Deutschland arbeitsrechtlich reguliert
Hier endet die Reichweite der internationalen SRE-Literatur. Die Google-Bücher beschreiben ein Kapazitäts- und Kulturmodell; zum deutschen Arbeitsrecht treffen sie keine Aussage. In Deutschland ist Rufbereitschaft aber kein rein organisatorisches Thema, sondern ein reguliertes. Wer eine Rotation aufbaut, sollte die Grundzüge kennen, bevor der Dienstplan steht. Dieser Abschnitt ordnet die Rechtslage allgemein ein und ersetzt keine Rechtsberatung im Einzelfall.
Der Europäische Gerichtshof hat die maßgebliche Linie gezogen. Im Urteil vom 9. März 2021 in der Rechtssache C-580/19 ging es um einen Feuerwehrmann der Stadt Offenbach am Main, der in Rufbereitschaft nicht an einem vom Arbeitgeber bestimmten Ort sein musste, aber erreichbar sein und binnen 20 Minuten in Einsatzkleidung mit dem Einsatzfahrzeug die Stadtgrenze erreichen können musste (EuGH, C-580/19). Der Gerichtshof entschied, dass solche Bereitschaftszeit nur dann in vollem Umfang Arbeitszeit ist, wenn die auferlegten Einschränkungen die Möglichkeit des Arbeitnehmers, seine freie Zeit zu gestalten, ganz erheblich beeinträchtigen (EuGH, C-580/19). Eine pauschale Einordnung lehnte das Gericht damit ab: Maßgeblich sind die Reaktionsfrist und die durchschnittliche Häufigkeit der tatsächlichen Einsätze.
Wie weit das reichen kann, zeigt die frühere Entscheidung C-518/15 vom 21. Februar 2018: Dort musste ein Feuerwehrmann seine Bereitschaft zu Hause verbringen und einem Ruf binnen acht Minuten folgen. Diese Frist schränkte die Möglichkeit, anderen Tätigkeiten nachzugehen, erheblich ein - der Gerichtshof stufte die Zeit als Arbeitszeit ein (EuGH, C-518/15). Für die Vergütung gilt dabei eine wichtige Trennung: Die europäische Arbeitszeitrichtlinie regelt die Bezahlung nicht; diese folgt dem nationalen Recht, dem Tarifvertrag oder dem Arbeitsvertrag (EuGH, C-518/15). Arbeitszeit im Sinne der Richtlinie und vergütete Zeit sind also zwei verschiedene Fragen.
| Fall | Auflage | Einordnung | Kriterium |
|---|---|---|---|
| EuGH C-518/15 (2018) | Bereitschaft zu Hause, Reaktion binnen 8 Minuten | Arbeitszeit | Frist schränkt die Freizeitgestaltung erheblich ein |
| EuGH C-580/19 (2021) | Freie Ortswahl, Stadtgrenze binnen 20 Minuten mit Einsatzfahrzeug | Arbeitszeit nur bei ganz erheblicher Beeinträchtigung | Reaktionsfrist und durchschnittliche Einsatzhäufigkeit |
| Typische IT-Rufbereitschaft | Erreichbarkeit, Laptop, Rückruf binnen 15-30 Minuten | Einzelfallbetrachtung nach denselben Kriterien | Wie stark die Auflagen die freie Zeit binden |
Für die Praxis der IT-Bereitschaft folgt daraus eine sehr konkrete Konsequenz: Die Reaktionsfrist ist der Stellhebel. Eine Frist von fünf Minuten, wie sie das SRE Book für nutzernahe, zeitkritische Dienste als Zielwert nennt (Google SRE Book, Kapitel 11), bindet die betroffene Person faktisch ans Gerät - Einkaufen, Sport oder ein Kinobesuch fallen damit aus. Eine Frist von 30 Minuten, die dort für weniger zeitkritische Systeme genannt wird (Google SRE Book, Kapitel 11), lässt deutlich mehr Spielraum. Wer die Frist ohne Not eng setzt, verschärft nicht nur die Belastung, sondern verschiebt die Bereitschaft nach den EuGH-Kriterien auch näher in Richtung Arbeitszeit. Die Frist sollte deshalb aus dem Verfügbarkeitsziel abgeleitet werden - nicht aus Vorsicht.
Unabhängig von der Einordnung der Bereitschaft bleiben die Vorgaben des Arbeitszeitgesetzes unberührt. § 5 ArbZG verlangt nach Beendigung der täglichen Arbeitszeit eine ununterbrochene Ruhezeit von mindestens elf Stunden (ArbZG § 5). § 3 ArbZG begrenzt die werktägliche Arbeitszeit auf acht Stunden und lässt eine Verlängerung auf zehn Stunden nur zu, wenn der Durchschnitt über sechs Kalendermonate oder 24 Wochen bei acht Stunden bleibt (ArbZG § 3). Ein nächtlicher Einsatz, der als Arbeitszeit zählt, unterbricht die Ruhezeit - der Dienstbeginn am Folgetag verschiebt sich entsprechend. Das gehört in den Dienstplan, nicht in die Improvisation am Morgen danach.
Praktisch bedeutet das: Ein Einsatz um zwei Uhr nachts, der eine Stunde dauert, hat Folgen für den Vormittag danach. Diese Folge lässt sich planen - eine Rotation, die den Folgetag nach einem nächtlichen Einsatz freihält, ist keine Großzügigkeit, sondern der geordnete Umgang mit einer gesetzlichen Vorgabe. Wer die Rotation dokumentiert, dokumentiert damit zugleich ihre Einhaltung; und Nachweispflichten sind in regulierten Kontexten ohnehin Alltag geworden, wie der Beitrag zur nachweisbaren Absicherung von Dienstleistern nach NIS2 zeigt.
Übergabe, Eskalation und Nacharbeit
Drei Vorgänge halten eine Rotation zusammen: die Übergabe zwischen zwei Schichten, die Eskalation innerhalb einer Schicht und die Nacharbeit danach. Das Site Reliability Workbook empfiehlt eine Schichtlänge von höchstens 12 Stunden und hält 24 Stunden oder mehr ohne Unterbrechung ausdrücklich für nicht durchhaltbar - Erschöpfung erhöht die Fehlerhäufigkeit (Google SRE Workbook, Kapitel 8). Damit ist die Übergabe ein wiederkehrender, planbarer Vorgang und kein Zufall.
- Übergabe mit Zustand, nicht nur mit Ereignissen - die abgehende Schicht übergibt offene Vorfälle, laufende Provisorien und bekannte Wackelkandidaten, nicht nur eine Liste geschlossener Tickets
- Eine primäre und eine sekundäre Bereitschaft - die sekundäre Stufe fängt ab, wenn die primäre nicht reagiert oder überlastet ist; das SRE Book rechnet die Rotation ausdrücklich mit beiden Rollen (Google SRE Book, Kapitel 11)
- Automatische Eskalation nach Zeit - wird ein Alarm nicht quittiert, geht er ohne manuelles Zutun an die nächste Stufe; niemand sollte sich darauf verlassen müssen, aber auch niemand daran vorbeischlafen können
- Klare Bedingung für den Ruf nach oben - ab welchem Umfang oder nach welcher Zeit ohne Fortschritt wird eskaliert? Diese Grenze gehört ins Runbook, nicht in die Nacht
- Schuldfreies Postmortem - die Nacharbeit adressiert die Ursache, nicht die Person; genau diese Kultur nennt das SRE Book als eine der drei stressmindernden Ressourcen (Google SRE Book, Kapitel 11)
- Der Alarm selbst kommt auf den Prüfstand - jeder Vorfall stellt die Frage, ob der auslösende Alarm handlungsrelevant war; war er es nicht, wird er angepasst oder abgeschaltet
Der Weg vom eingehenden Alarm bis zur behobenen Störung verdient eine eigene, geübte Struktur. Wie sich Rollen, Kommunikation und Eskalationsstufen dabei sauber trennen lassen, behandelt der Beitrag zu Incident-Management und Eskalation. Und wie viel Spielraum überhaupt bleibt, bevor ein Verfügbarkeitsziel reißt, macht die Betrachtung von Error-Budget und Burn-Rate sichtbar - sie liefert die objektive Grundlage für die Entscheidung, ob ein Vorfall nachts oder morgens bearbeitet wird. Beide Bausteine greifen ineinander: Das Budget sagt, wie dringend es ist; die Rotation sagt, wer es übernimmt.
Die Rotation an das Monitoring koppeln
Ein Dienstplan ohne technische Entsprechung bleibt ein Dokument. Die Kopplung an das Monitoring entscheidet, ob die Rotation im Ernstfall trägt: Der Alarm muss die Person erreichen, die gerade Dienst hat - nicht die, die vor drei Wochen Dienst hatte. Er muss eskalieren, wenn niemand reagiert. Und er muss zwischen einem bestätigten Ausfall und dem Ausschlag eines einzelnen Prüfpunkts unterscheiden können, denn ein Fehlalarm um drei Uhr kostet dieselbe Nacht wie ein echter Vorfall. Warum ein einzelner Prüfpunkt dafür nicht genügt, erläutert der Beitrag zum Multi-Location-Monitoring.
Getrennte Kanäle für Page und Ticket - dringende Vorfälle über einen Kanal, der weckt; alles Übrige über einen, der wartet.
Bleibt ein Alarm unquittiert, geht er automatisch an die nächste Stufe der Bereitschaft - ohne dass jemand manuell nachfassen muss.
XICTRAQ prüft von drei verteilten Knoten; ein Ausfall gilt als bestätigt, wenn mehrere Prüfpunkte ihn unabhängig melden.
Geplante Arbeiten lösen keinen Alarm aus und belasten die Verfügbarkeitsstatistik nicht.
Ablaufende Zertifikate und Domains melden sich mit Wochen Vorlauf als Ticket - nicht als nächtlicher Page.
Die lückenlose Vorfallhistorie zeigt, ob die Grenze von zwei Incidents je Schicht gehalten wird - und woher das Rauschen kommt.
Der letzte Punkt schließt den Kreis zur Kapazitätsgrenze. Ohne Historie bleibt die Frage, ob die Rotation überlastet ist, eine Gefühlsfrage - und Gefühle unterscheiden schlecht zwischen einer harten Woche und einem strukturellen Problem. Mit Historie wird sie eine Rechenfrage: Zählen Sie die Incidents je Schicht über acht Wochen, vergleichen Sie mit der Zwei, und die Antwort steht da. Ein Alerting mit Eskalationsstufen und getrennten Kanälen liefert die Datenbasis dafür gleich mit.
Wer die Rotation zusätzlich gegen externe Auslöser absichern will, sollte die Quellen im Blick behalten, aus denen ungeplante Nächte entstehen. Eine frisch veröffentlichte Schwachstelle in einer eingesetzten Komponente ist ein klassischer Grund dafür; wie sich solche Meldungen strukturiert verfolgen lassen, beschreibt der Beitrag zur Nutzung von EUVD- und CVE-Schwachstellen-Feeds. Und die Preisübersicht zeigt, ab welchem Umfang Eskalationsstufen und die Bestätigung aus mehreren Standorten zur Verfügung stehen.
Eine Bereitschaft, die Menschen über Jahre tragen
Der Aufbau einer Rotation ist keine Frage des Werkzeugs, sondern eine Reihe von Entscheidungen, die dokumentiert gehören. Wie viele Personen tragen den Plan - und welches Abdeckungsfenster ist mit dieser Zahl ehrlich darstellbar? Welche Reaktionsfrist gilt, und ist sie so großzügig gesetzt, wie sie es sein kann? Welche Alarme dürfen wecken, und hat jeder davon ein Runbook? Wie wird eskaliert, wenn niemand reagiert? Und was passiert am Tag nach einem nächtlichen Einsatz? Wer diese fünf Fragen schriftlich beantworten kann, hat eine Bereitschaft. Wer es nicht kann, hat eine Hoffnung.
Der belastbarste Prüfstein bleibt die Zahl aus dem SRE Book: höchstens zwei Incidents pro 12-Stunden-Schicht (Google SRE Book, Kapitel 11). Wird sie über mehrere Wochen überschritten, ist das keine Aufforderung, den Dienstplan zu verdichten, sondern das Signal, das System leiser zu machen - durch präzisere Schwellen, durch Bestätigung aus mehreren Standorten, durch das konsequente Abschalten von Alarmen ohne Handlungsfolge. Eine Rotation, die dieser Grenze standhält, lässt sich über Jahre betreiben. Eine, die sie ignoriert, verliert erfahrungsgemäß zuerst die Menschen und danach die Verfügbarkeit. Die Messbasis dafür liefert ein Uptime-Monitoring mit lückenloser Historie, und ein Blick in die unverbindliche Demo zeigt die Eskalationslogik im Betrieb.
Dieser Artikel basiert auf: Google - Site Reliability Engineering, Kapitel 11 (Being On-Call) - Obergrenze von zwei Incidents pro 12-Stunden-Schicht, rund sechs Stunden Aufwand je Incident einschließlich Nacharbeit, Mindestgröße von acht Personen für eine Single-Site-Rotation mit primärer und sekundärer Bereitschaft, höchstens 25 Prozent der Zeit in Bereitschaft und mindestens 50 Prozent in Engineering-Arbeit, Reaktionszeiten von 5 beziehungsweise 30 Minuten je nach Zeitkritikalität, flache Verteilung der Pages mit wahrscheinlichem Medianwert null, drei stressmindernde Ressourcen (Eskalationspfade, Incident-Management-Verfahren, schuldfreie Postmortems). Google - The Site Reliability Workbook, Kapitel 8 (On-Call) - Mindestgröße von neun Personen für eine Single-Site-Rotation rund um die Uhr (acht plus Puffer) und sechs Personen je Standort im Multi-Site-Modell (fünf plus Puffer), Schichtlänge von höchstens 12 Stunden, Zielwert von maximal zwei Incidents je Schicht, ein Incident gleich ein Problem unabhängig von der Alarmzahl, Klassifikation P1/P2/P3, Grundsatz der unmittelbaren Handlungsrelevanz jedes Alarms, Inhalt und Entstehungszeitpunkt des Playbooks, rund 24 Schwerpunkte in der Einarbeitung. EuGH, Urteil vom 09.03.2021, Rs. C-580/19 (Stadt Offenbach am Main) - Bereitschaftszeit ist nur bei ganz erheblicher Beeinträchtigung der Freizeitgestaltung in vollem Umfang Arbeitszeit; Kriterien sind Reaktionsfrist und durchschnittliche Einsatzhäufigkeit; Sachverhalt mit 20-Minuten-Frist bis zur Stadtgrenze. EuGH, Urteil vom 21.02.2018, Rs. C-518/15 (Matzak) - Bereitschaft zu Hause mit Reaktionsfrist von acht Minuten als Arbeitszeit; die Vergütung wird von der Arbeitszeitrichtlinie nicht geregelt. Arbeitszeitgesetz (ArbZG), Bundesministerium der Justiz - gesetze-im-internet.de - § 3 (werktägliche Arbeitszeit von acht Stunden, Verlängerung auf zehn Stunden bei Ausgleich über sechs Kalendermonate oder 24 Wochen) und § 5 (ununterbrochene Ruhezeit von mindestens elf Stunden nach Beendigung der täglichen Arbeitszeit). Zusätzlich fließen als (Projekterfahrung) gekennzeichnete Werte aus eigenen Monitoring-Projekten ein. Der Abschnitt zum Arbeitsrecht ordnet die Rechtslage allgemein ein und ersetzt keine Rechtsberatung im Einzelfall.