Schriftliche DevOps-Schulung

Wie fördern Sie kontinuierliches Lernen bei DevOps?

Aus Ihren Projekten wissen Sie, dass trotz Checklisten, Peer-Reviews, Kontrollen, Audits und Compliance weiterhin Probleme auftreten. Das lässt sich nicht vermeiden. Entwickeln Sie eine Kultur, in der Ihr Team und Ihre Organisation selbst Probleme erkennen, daraus lernen und sich verbessern. Ihre Kultur akzeptiert, dass Probleme auftreten, und bereitet Teams darauf vor. Problemlösung gehört zur täglichen Arbeit und trägt zum kontinuierlichen Lernen und zur Verbesserung bei. Lösungen wirken über das eigene Team hinaus, wenn Sie sie in der ganzen Organisation sichtbar und leicht zugänglich machen.

Netflix hat als führende DevOps-Organisation eine eigene Software namens Chaos Monkey entwickelt, um schwerwiegende Ereignisse in seinen cloudbasierten Rechenzentren zu simulieren. Chaos Monkey legt zufällig Server in Produktionssystemen still. So kann das Team zusätzlich prüfen, ob der Betrieb widerstandsfähig und stabil ist und die Kunden ohne Unterbrechung gute Dienste erhalten. Aus jedem Ausfall zieht Netflix Lehren, die seine Systeme stabiler und robuster machen.

Warum eine Lernkultur wichtig ist

Wenn sich nach Vorfällen alle gegenseitig die Schuld geben, entsteht unter den Ingenieuren eine Kultur der Angst. Die Organisation wird langsam, bürokratisch und von Machtspielen geprägt. Statt aus Fehlern zu lernen, widerstandsfähiger zu werden und Fehler durch Aufmerksamkeit und Sorgfalt zu vermeiden, schützen sich alle selbst. Arbeit, Probleme und sogar Lösungen bleiben teilweise verborgen.

Because problems are inevitable in complex systems, instead of finger-pointing, blaming and shaming the ones who cause problems, your organization should value actions to make problems visible in your daily work. It should encourage organizational learnings from errors and inefficiencies, so everyone in your DevOps organization can also learn and profit from these problems, solutions and knowledge.When engineers in your DevOps organization feel safe about giving details about mistakes, they voluntarily go extra mile and spend a lot of energy to make sure that a similar problem will not happen again in their own work center and in other work centers in your organizational value stream. If engineers are punished or even if they feel that they are punished when they do mistakes, then they will be afraid of making mistakes, so

1. Sie leisten weniger Arbeit, um weniger Fehler zu machen.
2. Sie legen Arbeit, Probleme und Lösungen nicht offen.
3. Sie haben keinen Anreiz, Problemlösungen in organisationsweites Wissen zu überführen.
4. Dasselbe oder ein sehr ähnliches Problem wird sich mit Sicherheit wiederholen. Niemand investiert dann Zeit und Energie, um aus Problemen zu lernen, Lösungen zu teilen, andere zu schulen und die Arbeit sichtbar zu machen.

Besprechen Sie Vorfälle sofort nach, solange die Erinnerung an die Ursachen noch frisch ist

Die Ziele einer Nachbesprechung sind einfach:

• Herausfinden, was Sie richtig gemacht haben, damit Sie es in ähnlichen Situationen erneut versuchen können.
• Festhalten, was anders hätte laufen sollen, damit Sie Ihre Methoden verbessern können.
• Festhalten, was Sie falsch gemacht haben, und alternative Ansätze oder Schutzmaßnahmen für ein ähnliches Problem vorschlagen.
• Herausfinden, warum es sinnvoll erschien, die Maßnahme, die zu dem Vorfall führte, zu ergreifen oder zu unterlassen.

Eigene Fehler zu untersuchen kann Angst machen und ist in manchen Organisationen sogar gefährlich. Wer für ein Eingeständnis Kritik oder Disziplinarmaßnahmen befürchten muss, wird Fehler kaum zugeben. Das schadet auf Dauer: Wer einen Fehler nicht versteht, wird ihn wahrscheinlich wiederholen. Organisationen, die es mit Verbesserungen ernst meinen, schaffen Verfahren und eine Kultur, in denen man Fehler gefahrlos untersuchen kann.

Für eine Nachbesprechung gelten einige Grundannahmen:

• Alle geben nach bestem Wissen ihr Bestes.
• Unter Druck entscheiden Sie mit unvollständigen Informationen.
• Sie müssen oft Aufgaben übernehmen, für die Sie nicht geschult wurden, und mit den gerade verfügbaren Werkzeugen und Ressourcen auskommen.
• Fehler sind unter solchen Umständen unvermeidbar.
• Ziel ist es, den Ablauf zu verstehen und daraus zu lernen. Es geht nicht darum, Einzelnen die Schuld für ihr Handeln zu geben.
• Das Ergebnis ist eine Beurteilung der Prozesse und ihrer Verbesserungsmöglichkeiten. Personen oder Gruppen werden dabei nicht bewertet.

Alle Beteiligten müssen diesen Grundsatz vollständig akzeptieren: „Keine Schuldzuweisungen, wir sind hier, um zu lernen“. Viele Organisationen bemühen sich sehr um ein solches sicheres Umfeld. Die FAA betreibt beispielsweise das Aviation Safety Reporting System. Piloten, die „Fehler“ machen, können unter diesem System von Disziplinarmaßnahmen der Aufsichtsbehörde verschont bleiben, wenn sie diese Vorfälle melden.

Nachbesprechungen müssen konkrete Maßnahmen festlegen, um eine Wiederholung zu verhindern. Beispiele sind neue Telemetriemetriken und automatisierte Testfälle, zusätzliche Code-Reviews für bestimmte Änderungen, Refactoring oder das Entkoppeln komplexer Komponenten, die häufig Probleme verursachen.

Veröffentlichen Sie Protokolle und Erkenntnisse aus Nachbesprechungen in der gesamten Organisation. So werden Erkenntnisse aus einem Arbeitsbereich des Wertstroms für die ganze Organisation nutzbar. Das signalisiert, dass Transparenz, Offenheit und Lernen einen hohen Stellenwert haben.

Verbessern Sie Ihre Systeme mit Game Days

Ein Game Day ist keine übliche langweilige Teamveranstaltung, bei der Extrovertierte sich amüsieren und Introvertierte aufs Handy schauen, damit die Zeit schneller vergeht.

An einem Game Day simulieren Sie schwerwiegende Ausfälle in Testsystemen. Die DevOps-Teams beheben sie und lernen daraus.

Sie können beispielsweise einen kritischen Server abschalten, um zu prüfen, ob das Failover ohne Dienstunterbrechung funktioniert. Anschließend prüft das Team, ob und wie die Wiederherstellung aus Sicherungen oder Ihrer Infrastructure as Code (IaC) gelingt. Die entdeckten Probleme helfen dem Team, widerstandsfähige, fehlertolerante Systeme zu entwickeln und neue Erkenntnisse zu gewinnen.

Bei der Problemlösung baut Ihr Team Beziehungen zu anderen Abteilungen auf, während alle Ausfälle ohne den Druck eines echten Vorfalls proben. Sie können die Kommunikation und Fehlerbehebung in der gesamten Organisation erproben und gezielt verbessern.

Sie können außerdem schwache Signale für größere künftige Probleme erkennen. Häufige Vorfälle niedriger Priorität während solcher Übungen oder kleine Nebenwirkungen, die beinahe eine weitere kritische Komponente zum Absturz gebracht hätten, sind wichtige Warnsignale. Gehen Sie ihnen nach, um Ihre Systeme zu verbessern.

FAZIT

Ermutigen Sie Ihr Team zu kalkulierten Risiken. Leistungsstarke DevOps-Organisationen machen häufiger Fehler. Das ist in Ordnung und hilft Ihrer Organisation, dazuzulernen und besser zu werden.

Leistungsstarke Teams haben gegenüber typischen Organisationen 80 % weniger kritische Produktionsausfälle, also nur ein Fünftel so viele Vorfälle mit Folgen für Kunden. Deshalb müssen Ihre Ingenieure Fehler machen und daraus lernen dürfen.