Uptime — das Bereitschafts-Triage-Spiel
Du hast Bereitschaft. Zwölf Alarme, vier mögliche Antworten, ein Fehlerbudget. Kostenlos, ohne Anmeldung.
- ⏱ Fehlerbudget43/43 Min
- 🫂 Team▮▮▮▮▮5/5
- 🟢 Uptime100.000%
Zwölf Alarme. Fakten lesen, eine Antwort wählen. Nicht alles ist ein Notfall.
So wird gespielt
- Keine Auswirkung auf Kundschaft? Verschieben. Nichts Internes ist es wert, jemanden zu wecken.
- Auswirkung und ein Deploy in den letzten 30 Minuten? Zurückrollen — rückgängig machen schlägt diagnostizieren.
- Auswirkung, kein frischer Deploy, aber ein aktuelles Runbook? Neu starten und dem Runbook folgen.
- Auswirkung, aber weder das eine noch das andere? Die verantwortliche Person anrufen. Achte auf alte Deploys und veraltete Runbooks — die zählen nicht.
So funktioniert es
Du hast Bereitschaft, und das Einzige, worüber du bestimmst, ist deine Reaktion auf jeden Alarm. Eine Schicht teilt zwölf davon aus, einen nach dem anderen, und jede Karte nennt ihre Fakten: ob Kundschaft es sieht, wann zuletzt deployt wurde und ob ein Runbook das Symptom abdeckt. Aus diesen drei Fakten folgt genau eine der vier Antworten. Die Regel steht ab der ersten Karte auf dem Schirm und ändert sich nie — was sich ändert, ist, wie genau du lesen musst, denn ein Deploy von vor sechs Stunden ist nicht der Verdächtige, und ein Runbook für die alte Architektur ist kein Runbook. Zwei Anzeigen können die Schicht vorzeitig beenden: das Fehlerbudget, das ein verschlafener kundensichtbarer Vorfall im Eiltempo verbrennt, und die Geduld deines Teams, von der jeder unnötige Anruf um drei Uhr nachts etwas abzieht. Läuft auf deinem Gerät, es wird nichts verschickt, und es gibt nichts anzumelden.
Ein Spiel über Urteilsvermögen bei Vorfällen, kein Betriebshandbuch. Echte Bereitschaft hat mehr als vier Optionen und deutlich schlechtere Zeiten.
Häufig gestellte Fragen
Wie lautet die Regel genau?
Sieht die Kundschaft es nicht, verschieb es auf die Geschäftszeiten. Sieht sie es doch: zurückrollen, wenn in den letzten dreißig Minuten deployt wurde; neu starten, wenn ein aktuelles Runbook das Symptom abdeckt; und die verantwortliche Person anrufen, wenn beides nicht zutrifft. Die Reihenfolge zählt: eine frische Änderung rückgängig zu machen geht schneller, als sie zu diagnostizieren — deshalb schlägt ein frischer Deploy das Runbook.
Warum wird Verschieben so viel härter bestraft als Anrufen?
Weil die Fehler nicht gleich schwer wiegen. Etwas zu verschlafen, das Kundschaft sieht, verbrennt Fehlerbudget die ganze Zeit, in der du schläfst. Jemanden für etwas zu wecken, das ein Runbook abdeckt, kostet Wohlwollen und sonst nichts: ärgerlich, wieder gutzumachen, und kein Ausfall. Die Wertung ist die Lektion.
Sind die Alarme zufällig?
Das Deck entsteht aus einem Seed, eine Schicht ist also reproduzierbar — aber die Mischung ist Absicht: keine Antwort ist häufiger als etwa ein Drittel der Fälle richtig, also schlägt keine Gewohnheit das Lesen. Die feinen Karten — ein alter Deploy, ein veraltetes Runbook — kommen später in der Schicht, und genau das ist die Schwierigkeitskurve.
Was bedeutet die Verfügbarkeitszahl?
Ein Monat mit 99,9% erlaubt rund 43 Minuten Ausfall, und das ist dein Fehlerbudget zu Beginn. Jede falsche Entscheidung gibt davon etwas aus, und der angezeigte Prozentsatz ist das, was dein SLO-Dashboard am Monatsende zeigen würde. Drei Nachkommastellen, weil ein 99,9%-Ziel genau dort lebt.