CheckOps in Aktion
Teams können CheckOps direkt in Compass ausführen. Compass ist die zentrale Anlaufstelle für Teams, um Metriken und Ziele einzusehen und Maßnahmen schriftlich festzuhalten, die umgesetzt werden sollen.
Ein Beispiel für einen wöchentlichen CheckOps-Bericht mit Kennzahlen, Warnmeldungen und geplanten Maßnahmen.
Du kannst auch einen wöchentlichen CheckOps-Bericht in Trello erstellen.
Was du brauchst
Remote
Videokonferenztool mit Bildschirmfreigabe
Tool für die digitale Zusammenarbeit
Persönlich
CheckOps-Berichtsvorlage in Compass
Whiteboard
Filzstifte
Haftnotizzettel
Stoppuhr oder anderer Zeitmesser
Optionale Vorlagen
Atlassian-Vorlagen
Dieses Spiel funktioniert am besten mit der CheckOps-Funktion in Compass (siehe Informationen zu ersten Schritten mit CheckOps für dein Team). Falls du noch nicht mit Compass begonnen hast, kannst du die Verfolgung deines Teamzustands auch in Trello starten.
Anleitung zur Durchführung dieses Spiels
Dieses Spiel ist für Teams konzipiert, die Software entwickeln, liefern und ausführen.
1. Das Spiel vorbereiten 30 Minuten
Lege die DevOps-Teamziele fest
Das gesamte Team setzt sich gemeinsam Ziele.
- Melde dich bei Compass an und navigiere zur CheckOps-Funktion oder nutze eine alternative Methode, um deine Ziele zu verfolgen.
- Finde heraus, was du an deinen Entwicklungs- oder Betriebspraktiken ändern oder verbessern möchtest.
Du kannst deine betrieblichen Ziele an den Geschäftsanforderungen orientieren:
- Musst du deinen Kunden den schnellstmöglichen Service bieten oder musst du rund um die Uhr verfügbar sein? Setze DevOps-Ziele für Latenz, Durchsatz oder Verfügbarkeit.
Betriebliche Ziele können auch vom Team definiert werden:
- Ist dein Team es leid, mitten in der Nacht wegen Warnmeldungen und Vorfällen geweckt zu werden, gegen die es nichts tun kann? Setze dir zum Ziel, die Anzahl der Vorfälle und Warnmeldungen, für die dein Team nicht zuständig ist, zu reduzieren.
- Bist du der Meinung, dass die Überprüfung von Pull-Anfragen zu lange dauert? Lege als betriebliches Ziel fest, wie lange Pull-Anfragen offen bleiben dürfen.
Beginne mit einer kleinen Anzahl von DevOps-Zielen. Verkompliziere nichts und sorge dafür, dass du die richtigen Informationen erfasst, um den Fortschritt zu verfolgen. Wenn du kannst, beginne mit demselben Ziel oder denselben Zielen für all deine Services – das vereinfacht den Umgang mit den Daten, die dein Team in den Meetings überprüft.
Stelle sicher, dass deine DevOps-Ziele messbar sind
Definiere deine Ziele so, dass sie messbar sind. Auf diese Weise kannst du überprüfen, ob du sie erreicht hast.
- Betriebliche Metriken aus deinen Services sind ein guter Ansatzpunkt: Nutze ein Beobachtungstool (z. B. Splunk Observability, DataDog, Grafana) und beschreibe die zu untersuchende Metrik genau.
- Entwicklungsmetriken für deine Repositorys sind ebenfalls wichtig – du kannst Jira oder Compass verwenden, um diese am besten zu verfolgen.
Während du die Übung durchführst, fällt dir vielleicht auf, dass du nicht misst, was du verbessern möchtest. Das macht nichts! Eine der Aufgaben in deinem ersten CheckOps-Meeting kann es sein, geeignete DevOps-Metriken hinzuzufügen. Sobald das erledigt ist, kannst du in späteren Meetings auf die Metrik zurückgreifen.
Schreibe deine DevOps-Ziele auf
Wenn dein Team mit den von dir festgelegten betrieblichen Zielen einverstanden ist, solltest du sie aufschreiben und mit allen teilen. Richte dann ein grundlegendes Confluence-Dokument mit deinen DevOps-Zielen ein, auf das leicht zugegriffen werden kann und das gut sichtbar ist. Wenn du in Compass arbeitest, kannst du deine Ziele in Scorecards festhalten.
Deine DevOps-Ziele können (und sollten) sich im Laufe der Zeit ändern. Je mehr Informationen du sammelst, desto fundiertere Entscheidungen kannst du über deine Ziele treffen. Vielleicht stellst du auch fest, dass sich deine geschäftlichen oder betrieblichen Ziele weiterentwickeln. Achte aber darauf, nicht zu viele Ziele und DevOps-Metriken auf einmal hinzuzufügen, da das die Konzentration deines Teams ablenken und die Erreichung deiner Ziele verhindern kann. Wir empfehlen maximal drei Ziele innerhalb eines Zeitraums von drei bis sechs Monaten.
Hier einige Beispiele für Ziele, die dein Team festlegen könnte:
- Mehr Zeit für Pull-Anfragen oder Verlängerung der Gesamtdurchlaufzeit: sinnvoll, wenn dein Team Probleme hat, Deadlines einzuhalten.
- Reduzierung der wöchentlich von deinem Team zu bearbeitenden Warnmeldungen und Vorfälle: sinnvoll, wenn die Arbeit deines Teams zu oft unterbrochen wird.
- Seltenere Deployments: sinnvoll, wenn dein Team zu viele Vorfälle bearbeiten muss.
Wenn sich der Zustand deines Teams verbessert hat, musst du möglicherweise weniger Zeit mit der Vorbereitung verbringen.
TIPP: WICHTIGE DEVOPS-METRIKEN
Wir empfehlen Teams, immer die folgenden Metriken zu messen:
- Vorlaufzeit für Änderungen
- Änderungsfehlerrate
- Deployment-Häufigkeit
- Mittlere Wiederherstellungszeit
2: Daten sammeln 15 Minuten
Nachdem das Team die Ziele festgelegt hat, sammelt der Moderator Daten. Den ersten Schritt musst du nicht jede Woche durchführen, aber du solltest jede Woche Daten sammeln.
Führe ein Protokoll
Von einem CheckOps-Meeting zum nächsten kann viel passieren, das von deinen Tools nicht erfasst wird. Da sich dein Team nicht alles merken kann, ist es sinnvoll, Details aufzuschreiben, damit sie im nächsten Meeting besprochen werden können.
Wenn du mit einem Remote-Team arbeitest, erstelle für jede Woche einen neuen CheckOps-Bericht, in dem du wichtige Ereignisse hinzufügen kannst, und teile ihn dann mit den entsprechenden Teammitgliedern. Wenn du Compass (die DevEx-Plattform von Atlassian) verwendest, kannst du dein CheckOps-Verfahren schnell und einfach über die Seite Zustandsdetails starten.
- Wurde dein Bereitschaftsdienst wegen einer falsch positiven Warnmeldung kontaktiert? Solche Ereignisse haben einen negativen Einfluss auf dein Entwicklerteam. Notiere sie und teile sie mit der Gruppe, um sie in Zukunft zu verhindern.
- Gab es einen Vorfall, ein fehlgeschlagenes Deployment-Ereignis oder eine Pull-Anfrage, deren Merge zu lange gedauert hat? Mache dir die ganze Woche über kurze Notizen, damit das Team später keine Ereignisse aus dem Gedächtnis rekonstruieren muss.
Bereite die Nachbesprechung vor
Wenn die Bereitschaftsrotation endet (oder direkt danach), sollte der Moderator den CheckOps-Bericht für diese Rotation vorbereiten. Der Bericht sollte mindestens Folgendes beinhalten:
- Eine Liste der Services/Komponenten, die im Rahmen von CheckOps geprüft werden sollen
- Messungen (in Bezug auf dein Ziel) für jede dieser Komponenten
- Ein Häkchen oder ein Kreuz, je nachdem, ob das Ziel erreicht wurde oder nicht
- Ausweichmaßnahmen für alle nicht erreichten Ziele und Anmerkungen des Moderators zu den Gründen, aus denen das jeweilige Ziel nicht erreicht wurde.
- Ein Abschnitt zum Erfassen von Folgemaßnahmen
- Eine Zusammenfassung aller anderen Ereignisse oder Anomalien
Es ist wichtig, dass Folgemaßnahmen im CheckOps-Bericht erfasst werden. Andernfalls erhältst du einen Statusbericht, falls du mit Feedback-Schleifen Verbesserungen erzielen möchtest.
3: Eine CheckOps-Nachbesprechung abhalten 30 Minuten
Jeder kann sich einbringen
Sorge für Interaktion! Jedes DevOps-Teammitglied, das Bereitschaftsdienst leistet, sollte an diesem Meeting teilnehmen, und jedes sollte eine Aufgabe haben:
- Moderator: Die Person, die gerade ihren Bereitschaftsdienst beendet hat, sollte den CheckOps-Bericht und die Ergebnisse präsentieren. Wenn es in deinem Team keinen Bereitschaftsdienst gibt, wähle eine Person aus, die sich während der Woche Notizen zu den Ereignissen machen und dann beim Spiel ihre Ergebnisse präsentieren soll.
- Nächster Bereitschaftsdienst: Diese Person sollte genau auf die Äußerungen des Moderators achten, einschließlich der Probleme, die ihr aufgefallen sind, oder möglicher Risikobereiche, die bei der nächsten Bereitschaftsrotation erneut auftreten könnten.
- Leiter: Hierbei kann sich um eine Person (oder mehrere) handeln, die dem Team hilft, Maßnahmen zu priorisieren und Folgemaßnahmen zu gewährleisten. Wenn sich abzeichnet, dass eine Folgemaßnahme erforderlich ist, sollte der Leiter sicherstellen, dass sie der richtigen Person (den richtigen Personen) zugewiesen wird, damit sie erfolgreich abgeschlossen werden kann.
- Sonstige Mitglieder von Bereitschaftsteams und Besitzer von Komponenten: Das sind die Personen, die ebenfalls an der Bereitschaftsrotation teilnehmen und/oder mit den betriebenen Services oder Komponenten vertraut sind.
Ergebnisse teilen und besprechen
Der Moderator führt das Team durch die einzelnen Services/Komponenten und teilt mit, ob die Ziele erreicht wurden oder nicht und warum. Alle betrieblichen Ereignisse oder Anomalien, die während des jeweiligen Services aufgetreten sind, werden besprochen und Beobachtungen und Analysen ausgetauscht. Die Aufgabe des Teams besteht darin, Fragen zu stellen und Vorschläge für Folgeaktionen zu unterbreiten.
Gemeinsam Wege zu finden, damit alle Services/Komponenten des DevOps-Teams ihre jeweiligen Ziele erreichen, ist eine Aufgabe für das gesamte Team.
Schreibe die Aufgaben auf, die jedem Teammitglied übertragen werden, und erstelle während des Meetings Tickets in deinem Backlog.
TIPP: PROAKTIV HANDELN, NICHT REAGIEREN
Wenn dein Team für die Umsetzung von betrieblichen Zielen oder Entwicklungszielen verantwortlich ist, besteht die Gefahr, immer nur auf Ereignisse zu reagieren. Ob Zuverlässigkeit, Liefergeschwindigkeit oder Codequalität: Der von CheckOps unterstützte datenorientierte Ansatz sollte es deinem Team ermöglichen, deine DevOps-Ziele zu erreichen, das Entwicklererlebnis zu erweitern und sich kontinuierlich zu verbessern.
Nachbereitung
Iteration
Wir empfehlen eine wöchentliche Durchführung des CheckOps-Spiels und seine Anpassung an den Bereitschaftsplan deines Teams. Die Schritte 2 und 3 wiederholen sich wöchentlich, während Schritt 1 nicht zwangsläufig jede Woche ausgeführt werden muss. Je öfter du das Spiel übst, desto kürzer werden die Schritte 1 und 2. Wenn dein Team CheckOps mehrere Wochen lang durchgeführt hat, kannst du die Übung möglicherweise erweitern und weiterentwickeln, um andere Schwerpunktbereiche einzubeziehen. Beispielsweise lassen sich Qualitätsmetriken wie Codeabdeckung, Geschäftsmetriken wie wöchentliche aktive Benutzer für eine bestimmte Funktion oder beliebige andere Werte messen, die dein Team unterstützen.
Betriebliche Ziele neu bewerten
Mit der Zeit entsprechen die ursprünglichen DevOps-Ziele, die du dir gesetzt hast, möglicherweise nicht mehr den Bedürfnissen deines Teams. Vielleicht haben sich die Geschäftsanforderungen geändert oder die Ziele sind mehr oder weniger ambitioniert geworden. Wenn ja, führe Schritt 1 durch, aktualisiere deine angegebenen betrieblichen Ziele und setze deine Vorgehensweise fort. Du kannst bei Bedarf auch den Umfang deiner CheckOps-Praktik erweitern, um mehr Services oder Komponenten oder andere Aspekte deiner betrieblichen Praxis abzudecken.
Berichterstellung automatisieren
Angesichts eines größer werdenden Anwendungsbereichs solltest du mehr Zeit für Analysen und weniger Zeit für die Berichterstellung aufwenden. Suche nach Möglichkeiten, die Erfassung wichtiger Metriken und die Erstellung deiner CheckOps-Berichte zu automatisieren. Das verbessert sowohl die Produktivität als auch das Entwicklererlebnis in deinem Team, da die Erstellung von Berichten zunehmend automatisch erfolgt.
Wenn du dich für mehr Automatisierung entscheidest, solltest du dir dennoch weiter Zeit nehmen, um die Daten zu analysieren, die du sammelst und für das CheckOps-Meeting vorbereitest. Atlassian-Mitarbeiter verwenden dazu Metriken von Compass. Wir haben unsere CheckOps-Erfahrung in das Produkt integriert, um dir dabei zu helfen.
Beispiele für betriebliche Ziele
Überlegungen
Hier sind einige Beispiele für betriebliche Ziele, an denen dein Team die CheckOps-Übung je nach Aufgabe ausrichten kann:
Delivery types | Possible objectives |
|---|---|
Microservice |
|
On-call team |
|
Software delivery |
|
Mobile application |
|
Verwandte Spiele
Von unserem Team für euer Team
Bleibe mit unserem Newsletter über die neuesten Spiele, Tipps und Tricks auf dem Laufenden.
