DevOps-Retrospektive

Deployments, Incidents und Übergaben zwischen Dev und Ops auswerten.

Probieren Sie diese Retrospektive live aus

Erfolgreiche Deployments

Was lief bei den letzten Deployments gut?

Die automatisierte Test- und Deployment-Pipeline lief beim letzten Release reibungslos.
Durch die Zusammenarbeit von Dev und Ops vor dem Deployment haben wir mögliche Probleme früh entdeckt.
Dank unseres Rollback-Plans konnten wir ein fehlerhaftes Deployment schnell zurückrollen.
Verbesserungspotenziale

Vor welchen Herausforderungen standen wir, und was können wir besser machen?

Weil für einige Komponenten automatisierte Tests fehlten, gab es in Produktion unerwartete Probleme.
Kommunikationslücken zwischen Dev- und Ops-Teams haben zu Verzögerungen und Nacharbeit geführt.
Durch unzureichendes Monitoring und Alerting war es schwer, Probleme rechtzeitig zu erkennen und darauf zu reagieren.
Zusammenarbeit und Kultur

Wie verbessern wir die Teamarbeit und eine DevOps-Kultur?

Cross-Training und Job-Shadowing könnten helfen, die Lücke zwischen Dev- und Ops-Teams zu schließen.
Eine Kultur von Postmortems ohne Schuldzuweisungen würde offene Gespräche und Lernen fördern.
Regelmäßige Wissensrunden könnten das Verständnis für die Herausforderungen des jeweils anderen Teams verbessern.
Tools und Prozesse

Wie können wir Tools, Technologien und Prozesse optimieren?

Mit Infrastructure as Code könnten wir die Konsistenz verbessern und manuellen Aufwand reduzieren.
Eine Microservices-Architektur könnte Skalierbarkeit und Ausfallsicherheit verbessern.
Bessere Monitoring- und Observability-Tools würden uns tiefere Einblicke geben.

Was ist eine DevOps-Retrospektive?

DevOps (ein Kofferwort aus „Development“ und „Operations“) bezeichnet eine Reihe von Praktiken und Tools, mit denen eine Organisation Anwendungen und Services schneller ausliefern kann als mit klassischen Softwareentwicklungsprozessen. In einer DevOps-Retrospektive sitzen Entwicklung und Betrieb gemeinsam an einem Tisch und blicken auf die letzten Releases, Incidents und ihre Zusammenarbeit zurück. Das Board hat vier Spalten. Unter „Erfolgreiche Deployments“ sammelt ihr, was bei den letzten Releases gut lief. „Verbesserungspotenziale“ nimmt die Probleme auf, von Lücken bei automatisierten Tests bis zu fehlenden Runbooks. „Zusammenarbeit und Kultur“ schaut darauf, wie Dev und Ops zusammenarbeiten, etwa bei Rufbereitschaft, Übergaben und Postmortems. „Tools und Prozesse“ ist für Änderungen an Pipeline, Infrastruktur und Monitoring gedacht. Führt die Retrospektive nach einem großen Release oder Ausfall durch oder regelmäßig im Monats- oder Quartalsrhythmus. Bleibt dabei ohne Schuldzuweisungen, damit offen darüber gesprochen wird, was wirklich passiert ist, und geht mit ein paar Änderungen raus, für die jeweils jemand verantwortlich ist. Ob sie gewirkt haben, zeigt die nächste Runde Deployments.

Format der DevOps-Retrospektive

Erfolgreiche Deployments

Was lief bei den letzten Deployments gut?

Beginnt mit dem, was bei den letzten Deployments funktioniert hat, und fragt nach, warum es funktioniert hat, damit ihr es wiederholen könnt.

Verbesserungspotenziale

Vor welchen Herausforderungen standen wir, und was können wir besser machen?

Bleibt ohne Schuldzuweisungen. Fragt, was passiert ist und was es schwierig gemacht hat, und sucht hinter jedem Problem die Lücke in Prozessen oder Tools.

Zusammenarbeit und Kultur

Wie verbessern wir die Teamarbeit und eine DevOps-Kultur?

Sprecht darüber, wo Dev und Ops sich die Arbeit noch über den Zaun zuwerfen und was nötig wäre, damit der Betrieb des Service eine gemeinsame Verantwortung wird.

Tools und Prozesse

Wie können wir Tools, Technologien und Prozesse optimieren?

Sucht nach manuellen Schritten, die sich automatisieren lassen, und nach Abläufen mit zu vielen Übergaben. Wählt die Änderung, die am meisten Zeit spart oder das größte Risiko beseitigt.

Wann sollte diese Retrospektive durchgeführt werden?

  • Nach einem großen Release oder Deployment, um auszuwerten, wie es gelaufen ist.
  • Monatlich oder quartalsweise, um laufend zu verbessern, wie ihr Software entwickelt und betreibt.
  • Wenn in eurer Build- und Deployment-Pipeline immer wieder dieselben Engpässe oder Fehler auftreten.
  • Nach der Einführung neuer Tools, Technologien oder Prozesse, um zu prüfen, ob sie helfen.
  • Nach einem schwerwiegenden Incident oder Ausfall, um Ursachen zu finden und sich auf Vorbeugung zu einigen.

Vorschläge für Fragen zum Icebreaker

  • Wenn du eine manuelle Aufgabe automatisieren könntest, welche wäre es und warum?
  • Erzähl von einem Aha-Moment oder einer Lernerfahrung, die du kürzlich mit DevOps-Praktiken hattest.

Möchten Sie eine Aufwärmübung, bei der Ihr Team aktiv mitmacht, und nicht nur laut Antworten gibt? Kostenlose Icebreakers durchsuchen →

Ideen und Tipps für Ihre Retrospektive

  • Verzichtet auf Schuldzuweisungen, damit offen erzählt wird, was bei Incidents und Deployments wirklich passiert ist.
  • Ladet Entwicklung und Betrieb ein. Jede Seite sieht Probleme, die der anderen entgehen.
  • Verwendet die meiste Zeit darauf, was ihr ändern wollt, und nur so viel auf vergangene Fehler, wie nötig ist, um sie zu verstehen.
  • Gebt jeder vereinbarten Maßnahme eine verantwortliche Person und einen Termin.
  • Nennt die Leute, die hinter reibungslosen Releases und behobenen Incidents stehen. Diese Arbeit bleibt oft unbemerkt.
  • Wechselt ab und zu das Format, damit die Retrospektive nicht eintönig wird.

Häufig gestellte Fragen

Was ist eine DevOps-Retrospektive?
Ein Meeting, in dem Entwicklung und Betrieb gemeinsam auf die letzten Deployments, Incidents und ihre Zusammenarbeit zurückblicken. Das Board umfasst erfolgreiche Deployments, Verbesserungspotenziale, Zusammenarbeit und Kultur sowie Tools und Prozesse.
Worin unterscheidet sich eine DevOps-Retrospektive von einer Sprint-Retrospektive?
Eine Sprint-Retrospektive betrachtet die Arbeit eines Teams im Sprint allgemein. Eine DevOps-Retrospektive konzentriert sich darauf, wie Software entwickelt, ausgeliefert und betrieben wird, deshalb geht es öfter um Deployments, Incidents, Pipelines und Rufbereitschaft.
Wie oft sollte ein Team eine DevOps-Retrospektive durchführen?
Viele Teams machen eine nach jedem Release-Zyklus oder monatlich bzw. quartalsweise. Hilfreich ist auch eine Retrospektive kurz nach einem größeren Incident, solange die Details noch frisch sind.
Wer sollte an einer DevOps-Retrospektive teilnehmen?
Entwickler, Mitarbeitende aus Betrieb oder SRE, QA und alle, die Rufbereitschaft haben oder für die Pipeline verantwortlich sind. Genau darum geht es: Dev und Ops an einen Tisch zu bringen.
Worin unterscheidet sie sich von einem Incident-Postmortem?
Ein Postmortem geht einem einzelnen Incident auf den Grund. Eine DevOps-Retrospektive betrachtet mehrere aktuelle Releases und Incidents, um Muster in Prozessen und Tools zu erkennen.

Verwandte Vorlagen

Produktentwicklungsprozess-Retrospektive

Tretet einen Schritt von den Sprints zurück und prüft, wie ihr Produkte entwickelt.

Bug-Fixing-Retrospektive

Verstehen, warum Bugs entstehen, und ihre Wiederkehr verhindern

Retrospektive zur Ticketlösung

Findet heraus, was die Ticketbearbeitung eures Teams bremst

Retrospektive zu Support-Tools und Ressourcen

Findet heraus, was eurem Support-Team hilft und was nicht

Sind Sie bereit, diese Retrospektive durchzuführen?Probieren Sie diese Retrospektive live aus