CheckOps in Aktion
Teams can run CheckOps directly in Compass. Compass offers teams a single place where they can easily see metrics and goals and write down actions they plan to take.
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 (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
The entire team will set goals together.
- 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 ausgehen:
- 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 Kennzahlen aus deinen Services sind ein guter Ansatzpunkt: Nutze ein Beobachtungstool (z. B. Splunk Observability, DataDog, Grafana) und beschreibe die zu untersuchende Kennzahl genau.
- Entwicklungskennzahlen für deine Repositorys sind ebenfalls wichtig – du kannst Jira Software 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-Kennzahlen hinzuzufügen. Sobald das erledigt ist, kannst du in späteren Meetings auf die Kennzahl zurückgreifen.
Schreib 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 festlegen.
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-Kennzahlen auf einmal hinzuzufügen, da das die Konzentration deines Teams verwässern 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, Fristen 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-KENNZAHLEN
Wir empfehlen Teams, immer die folgenden Kennzahlen zu messen:
- Vorlaufzeit für Änderungen
- Änderungsfehlerrate
- Deployment-Häufigkeit
- Mittlere Wiederherstellungszeit
2: Daten sammeln 15 Minuten
After the team sets goals, the presenter will need to gather data. Keep in mind, though you may not need to run step one every week, you will need to gather data each week.
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 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
As the on-call rotation ends (or right afterwards), the presenter should prepare the CheckOps report for that rotation. At its simplest, the report should include:
- 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
- A mitigation plan for any unmet goals, as well as notes from the presenter about why the goal wasn't met.
- Ein Abschnitt zum Erfassen von Folgemaßnahmen
- Eine Zusammenfassung aller anderen Ereignisse oder Abweichungen
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
Keep it interactive! Everyone on your DevOps team who takes a turn being on-call should attend this meeting, and everyone should have a job:
- 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.
- Leader: The leader is the person (or people) who can help the team prioritize actions and ensure followup. When an action requiring follow up arises, the leader should help make sure the right person (or people) owns the action and will be able to see it through to resolution.
- Other on-call team members and component owners: These are the people who are also in the on-call rotation and/or are intimately familiar with the services or components that are being operated.
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.
Schreib 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 reiner Reaktivität. 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
Over time, the original DevOps goals you set may no longer meet your team's needs. Maybe the business needs changed, or the targets became more or less aggressive. If so, run step one, update your stated operational objectives, and continue your practice. You can also expand the scope of your CheckOps practice, if necessary, to cover more services or components or other aspects of your operations practice.
Automatisierte Berichterstellung
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 monatlichen Newsletter über die neuesten Spiele, Tipps und Tricks auf dem Laufenden.
