Chaos Monkey Tag – Geplanter Wahnsinn
- Ein Kollege rennt über den Flur
- Telefone klingeln
- Hektische / Laute Gespräche
- Es stehen mehrere Kollegen aus dem IT-Betrieb bei einem Entwickler
- …
Alles keine guten Zeichen. Irgendwas ist passiert.
- Ist der Shop noch da?
- Oje…
- Ist da wohl schon wer dran?
- Haben wir gerade deployt?
- Was zeigt denn unser Monitoring?
- Wo stehen nochmal die Logs?
- …
Klingt nach eher hektischen Reaktionen, die darauf hinweisen, dass das Handwerkzeug noch nicht 100% sitzt.
Die gute Nachricht: Auch solche Verhalten können trainiert werden! Notfälle müssen nicht erst abgewartet werden!
Bei Thalia arbeiten wir auf allen Ebenen an der Verbesserung. Dazu gehört auch der Umgang mit Störungen in unseren Produkten.
Warum? Weil wir besser werden wollen!
Inspect & Adapt in Incident-Fällen
Die Grundlage für unsere hier vorgestellte Maßnahme stammt aus einer „Retrospektive“. Dieses Format kennt ihr vielleicht bereits aus „Scrum“. Wir nutzen es bei Thalia in vielen Situationen. In den vergangenen Monaten hatten wir an der ein oder anderen Stelle Probleme bei der Bereitstellung unserer Produkte im Online-Shop. Anschließend kristallisierte sich meist ein Kreis von Hauptbetroffenen heraus, mit dem wir gemeinsam reflektiert haben, wie die Zusammenarbeit funktioniert hat.
Hierbei trat immer wieder die Wahrnehmung in den Vordergrund, dass unterschiedlich mit Störungen umgegangen wird. Die schlimmsten Anzeichen dafür waren:
- Hektik
- Ignoranz
- keine Kommunikation
- Verzweiflung
Wir beschlossen als Maßnahme, solche Situationen gezielt herbeizurufen, um den Umgang zu üben. Dabei sollte auch herauskommen, wo unsere Teams überall noch Luft zur Verbesserung haben.
Chaos-Monkey-Tag
Offiziell stand dieser Tag ausgeschrieben als „Notfallübungstag“, doch intern wurde schnell der Begriff „Chaos-Monkey-Tag“ ausgerufen. „Chaos Monkey“ ist ein Tool, das als einzige Aufgabe hat, die IT-Infrastruktur von Unternehmen zu penetrieren. Es wird dort eingesetzt, wo Schwachstellen aufgedeckt werden müssen, um die Produkte nachhaltiger zu entwickeln. In unserem Falle haben wir hier nicht die Software installiert, sondern zunächst die Arbeit manuell gemacht. Dafür haben wir Mitarbeiter gesucht, die Zugriff auf alle Systeme haben und entsprechende Kreativität mitbringen diese zu ärgern: „Die Monkeys“! Diese waren schnell gefunden und noch schneller die Maßnahmen, die zu einem „Notfall“ führen.
Das Ergebnis tracken
Für den ersten Versuch haben wir uns geeinigt die Reaktionen in den Teams zu messen. Um sicherzustellen, dass die Behebung nicht wieder von „den üblichen Verdächtigen“ getan wird, also denen, die sich sowieso immer kümmern, haben wir diese im Vorfeld gefragt, ob sie das „Tracking“ übernehmen. Auf der einen Seite wissen diese Person am besten worauf man achten muss und auf der anderen Seite konnten wir so besser sehen, was die anderen machen. Die Tracker haben an diesem Tag für ihr Team die Messung vorgenommen. Selbst sollen sie sich bei der Lösung aktiv nicht beteiligen, aber zur Lösungsfindung natürlich bereit stehen. In erster Instanz war uns wichtig die Reaktionsgeschwindigkeit festzuhalten: Wann und wie erscheint das Problem an der Oberfläche?
- Springt das Monitoring an?
- Steht ein Kollege im Büro?
- Teilt am Ende sogar der Tracker selbst mit, dass das Team aufwachen sollte?
- Ist das Team ansprechbar? Oder treiben sich alle in einem dieser wichtigen Refinements oder Retrospektiven herum? 🙂
Was waren unsere Störungen
Der Kreativität sind keine Grenzen gesetzt. Nach einem kurzen Brainstorming haben wir uns für die Vergleichbarkeit auf folgende Maßnahmen geeinigt:
- Datenbank-Instanzen in kurzen Abständen alle auf „Read-Only“ konfigurieren, bis keine mehr zur Verfügung steht.
- Herunterfahren von Application-Server Instanzen, bis keine mehr zur Verfügung steht.
- Fehlkonfigurationen der Webserver aktivieren.
Was nehmen wir mit
Die Notfälle wurden alle behoben, aber in Summe haben wir festgestellt, dass noch Luft nach oben ist. Im Vergleich waren die Reaktionszeiten der Teams sehr unterschiedlich und teilweise zu langsam.
Spätestens in den folgenden Sprint-Retrospektiven der Teams wurden Maßnahmen verabschiedet, um das Monitoring oder sogar die Produkte selbst zu verbessern.
Und als Organisator:
Auch wenn der Tag natürlich wieder vom Zeitpunkt „völlig falsch“ gewählt war 🙂 wurden die Maßnahmen sehr begrüßt und einem Folgetermin – auch in Serie – wollte keiner im Wege stehen.
