Kein Spiel im System

đ€ 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
- Scott Alexander (2020) â 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
- Google SRE Book â Eliminating Toil (50-Prozent-Deckel fĂŒr Betriebsarbeit) https://sre.google/sre-book/eliminating-toil/
- Google SRE Book â Introduction (Deckel und RĂŒckgabe an die Entwicklungsteams) https://sre.google/sre-book/introduction/


