Chaos Engineering (III)
 |
| Bild: Pixabay / GlauchauCity - Lizenz |
Dem regelmässigen Leser dieser Seite dürfte es aufgefallen sein, dass ich ein Fan von Chaos Engineering bin. Als technische Praktik kann es entscheidend dafür sorgen, dass die in den methodischen Frameworks vorgesehehene kontinuierliche Liefer- und Reaktionsfähigkeit tatsächlich auch stattfinden kann. Darüber hinaus lässt sich Chaos Engineering aber auch von der Technik lösen und selbst als methodischer Ansatz einsetzen.
Noch einmal kurz zur Erinnerung: Chaos Engineering stellt die Resilienz (und damit auch die Liefer- und Reaktionsfähigkeit) eines Systems sicher indem auf Produktion nach Zufallsprinzip wichtige Ressourcen temporär abgeschaltet werden (Server, Übertragungskapazitäten, etc.). Übersteht das System diesen Stresstest ist alles gut, übersteht es ihn nicht, wird klar, an welcher Stelle an Kompensations-Automatismen gearbeitet werden muss.
Auf dieser Abstraktionsebene beschrieben lässt sich die Idee problemlos auf soziele Systeme übertragen, also auf Teams, Abteilungen oder Projekte. Auch hier lassen sich einzelne Ressourcen (→ Personen) temporär aus den Arbeitsabläufen herausnehmen, um festzustellen ob die anderen diesen Ausfall kompensieren können. Ist das nicht der Fall, ist ein Problem identifiziert, das beim nächsten Urlaub oder Krankheitsfall für Störungen oder Stillstand sorgen würde.
Die Problembehebung ist dann relativ einfach, denn in fast allen Fällen liegt einer von zwei Root Causes vor: entweder fehlen den anderen Mitarbeitern die Kenntnisse, um die Tätigkeiten des ausfallenden Kollegen zu übernehmen. Das kann kompensiert werden, indem sie sich in Richtung T-Shape oder Full Stack entwickeln. Oder ihnen fehlen Zugriffsberechtigungen auf die vom ausfallenden Kollegen verantworteten Systeme, was sich lösen lässt, in dem diese erteilt werden.
Ein zum Glück seltener werdender dritter Root Cause liegt vor, wenn der ausfallende Kollege Code Ownership in Teilen der Anwendung hat, also vereinbart wurde, dass er als Einziger dort Änderungen vornehmen darf. Eine andere Variante dieses Problems ist es, wenn nur eine Person für bestimmte Bereiche Pull Requests annehmen, also Änderungen genehmigen darf. Die Lösung ist in beiden Fällen einfach - man muss nur diese limitierenden Regeln abschaffen.
Die Ergebnisse von "sozialem Chaos Engineering" sind häufig überraschend, da Wissensmonopole, Berechtigungs-Engpässe und Code Ownership nicht immer explizit gemacht werden. Oft sind sie eher unbemerkt entstanden und werden selbst von den Beteiligten in ihrer Tragweite unterschätzt. Um so wichtiger ist es herauszufinden, ob sie vorliegen. Und einen netten Nebeneffekt gibt es auch noch: die temporär abwesenden Kollegen haben Zeit für Weiterbildung oder Überstunden-Abbau.
