--- title: "Kein Spiel im System" date: 2026-11-02T00:05:00Z draft: false image: "2026-11-02-kein-spiel-im-system.jpg" formate: ["montagspost"] themen: ["resilienz-vorfall"] tags: ["incident-response", "wiederanlauf"] keywords: ["Slack", "Zvi Mowshowitz", "Scott Alexander", "Kingmans Formel", "Warteschlangentheorie", "Google SRE", "Toil", "Business Continuity"] description: "Der Notfallplan bezieht seine Ressourcen aus einem Konto, das im Regelbetrieb längst leer ist." --- ## 🤝 Das starke Gegenargument Reserve vorzuhalten heißt, Leerlauf zu bezahlen. Wer eine halbe Stelle dafür einplant, dass irgendwann etwas passiert, bekommt sie nicht bewilligt, und der Grund dafür ist nachvollziehbar. Teams werden nach Aufgaben bemessen, nicht nach Möglichkeiten. Eine Kostenstelle rechtfertigt sich über das, was sie erledigt, nicht über das, was sie erledigen könnte. In zwanzig Jahren bin ich einem Muster immer wieder begegnet: Ist die IT nicht überlastet, gilt sie als nicht kosteneffizient. Wer in dieser Logik nach Spielraum fragt, klingt wie jemand, der zu wenig zu tun hat. Das Gegenargument ist damit kein Zynismus der Geschäftsführung, sondern die Regel, nach der Personalplanung überall funktioniert. ## ⚖️ Was daran stimmt Solange nichts passiert, sieht Reserve genau aus wie Leerlauf. Von außen ist der Unterschied nicht zu erkennen, von innen oft auch nicht. Dazu kommt ein Mechanismus, den Google im SRE-Buch für Betriebsarbeit beschreibt: Bleibt sie unbeaufsichtigt, wächst sie, bis sie die ganze Zeit ausfüllt. Ein Puffer, den niemand verteidigt, ist nach einem Quartal verschwunden. Nicht durch eine Entscheidung, sondern durch Zulauf. Wer also mehr Luft fordert und sonst nichts ändert, hat nichts gewonnen. Insofern hat der Einwand recht: Unverteidigte Reserve wird tatsächlich zu Leerlauf. ## 🔍 Wo es brüchig wird Brüchig wird der Einwand dort, wo die Organisation ihre Notfallpläne schreibt. Jedes Incident-Response-Playbook, jeder Wiederanlaufplan benennt Rollen: wer meldet, wer entscheidet, wer analysiert, wer kommuniziert. Was kein Plan benennt, ist die Zeit, aus der diese Arbeit kommen soll. Sie ist im Regelbetrieb bereits vergeben. Bei voller Auslastung bedeutet Vorfallbearbeitung deshalb immer, etwas anderes fallen zu lassen. Nur wird das nicht entschieden, es passiert: Die Zugriffsüberprüfung verschiebt sich, das Review bleibt liegen, der Patch wartet. Der Plan funktioniert auf dem Papier und bezieht seine Ressourcen aus einem Konto, das leer ist. Dasselbe gilt für die Übung, die den Plan erst belastbar macht. Sie fällt zuerst aus, weil sie als Einzige keinen Termin von außen hat. ## 🧪 Was die Zahlen sagen Schwerer wiegt ein Fehler, den das Gegenargument nicht ausspricht: Es rechnet, als wüchse die Wartezeit linear mit der Auslastung. Die Warteschlangentheorie sagt etwas anderes. In Kingmans Näherung für die mittlere Wartezeit steht ein Auslastungsterm ρ/(1−ρ). Bei 80 Prozent hat er den Wert 4, bei 90 Prozent 9, bei 95 Prozent 19. Die letzten zehn Prozentpunkte kosten mehr als die ersten achtzig. Ein zweiter Term erfasst die Schwankung, und hier steht Sicherheitsarbeit besonders schlecht da. Vorfälle treffen nicht gleichmäßig ein. Eine Woche bringt drei Phishing-Meldungen, die nächste eine kompromittierte Kennung im Verzeichnisdienst. Hohe Auslastung und hohe Schwankung multiplizieren sich. Genau diese Kombination macht aus einem Team, das seine Arbeit schafft, eines, das nur noch Rückstände verwaltet. Google zieht daraus eine feste Regel: höchstens die Hälfte der Zeit für Betriebsarbeit. Wer darüber liegt, gibt Arbeit an die Entwicklungsteams zurück. Über die Zahl lässt sich streiten. Der Mechanismus dahinter (eine Obergrenze mit hinterlegtem Eskalationsweg) ist das, was Reserve von Wunschdenken unterscheidet. ## 💡 Die unbequeme Schlussfolgerung Zvi Mowshowitz hat für das, was hier fehlt, den Begriff Slack bestimmt: die Abwesenheit bindender Beschränkungen. Scott Alexander hat ihn weitergedacht, und sein Argument ist das unbequemere. Wo kein Spiel ist, setzt sich nur durch, was sich sofort rechnet. Jede Verbesserung, die zuerst kostet und sich erst später auszahlt, fällt aus, bevor sie beginnt. Das alte Verfahren bleibt, weil die Ablösung ein Quartal Mehrarbeit bedeutet. Die Protokollierung bleibt lückenhaft, weil das Aufräumen in diesem Monat niemandem nützt. Ein Team ohne Spiel scheitert also nicht erst im Vorfall. Es scheitert vorher, leise und dauerhaft: Es hält das erreichte Niveau, und mehr ist nicht drin. Das ist der Posten, den die Kennzahl unter „Auslastung“ nicht ausweist – und der einzige, bei dem hundert Prozent kein gutes Ergebnis sind. ## 📚🔍 - Zvi Mowshowitz (2017) – Slack [https://www.lesswrong.com/posts/yLLkWMDbC9ZNKbjDG/slack](https://www.lesswrong.com/posts/yLLkWMDbC9ZNKbjDG/slack) - Scott Alexander (2020) – Studies on Slack [https://www.lesswrong.com/posts/GZSzMqr8hAB2dR8pk/studies-on-slack](https://www.lesswrong.com/posts/GZSzMqr8hAB2dR8pk/studies-on-slack) - Kingmans Formel – Wartezeit in der G/G/1-Warteschlange [https://en.wikipedia.org/wiki/Kingman%27s_formula](https://en.wikipedia.org/wiki/Kingman%27s_formula) - Google SRE Book – Eliminating Toil (50-Prozent-Deckel für Betriebsarbeit) [https://sre.google/sre-book/eliminating-toil/](https://sre.google/sre-book/eliminating-toil/) - Google SRE Book – Introduction (Deckel und Rückgabe an die Entwicklungsteams) [https://sre.google/sre-book/introduction/](https://sre.google/sre-book/introduction/)