Was ist DevOps?

  • 3 Minuten

Die Kontraktion von "Dev" und "Ops" bezieht sich auf das Ersetzen von siloierten Entwicklungs- und Betriebsteams. Die Idee besteht darin, multidisziplinäre Teams zu erstellen, die mit gemeinsamen Praktiken, Tools und Rechenschaftspflicht für Ergebnisse zusammenarbeiten. Grundlegende DevOps-Praktiken umfassen agile Planung, kontinuierliche Integration, kontinuierliche Bereitstellung und umfassende Überwachung von Anwendungen. DevOps ist eine kontinuierliche Verbesserungsreise, nicht ein Ziel.

Der Geschäftliche Wert von DevOps

Organisationen, die DevOps-Praktiken implementieren, sehen in der Regel messbare Verbesserungen bei wichtigen operativen Metriken:

  • Bereitstellungshäufigkeit: Von seltenen Versionen auf reguläre, vorhersagbare Bereitstellungen erhöht
  • Vorlaufzeit: Reduziert von erweiterten Entwicklungszyklen bis hin zu kürzeren Lieferzeiten
  • Mittlere Zeit für die Wiederherstellung (MTTR): Schnellere Vorfallauflösung und Systemwiederherstellung
  • Änderungsfehlerrate: Weniger Produktionsprobleme aufgrund verbesserter Tests und Automatisierung

Zu den erwarteten Vorteilen gehören:

  • Verkürzte Time-to-Market für neue Funktionen
  • Verringerte bereitstellungsbezogene Vorfälle
  • Verbesserte Produktivität und Zufriedenheit von Entwicklern
  • Senken der Betriebskosten durch Automatisierung

Diagramm, das den DevOps-Zyklus mit Plan-, Build-, Integrations-, Bereitstellungs-, Betriebs- und Feedbackphasen in einer fortlaufenden Schleife zeigt.

Verstehen und Berechnen der Zykluszeit

Beginnen wir mit einem grundlegenden Konzept zur Softwareentwicklung mithilfe der OODA-Schleife (Observe, Orient, Decide, Act). Ursprünglich entworfen, um Kampfpiloten davor zu schützen, abgeschossen zu werden, ist die OODA-Schleife eine ausgezeichnete Strategie, um Ihren Konkurrenten in der Geschäftswelt voraus zu sein.

OODA-Schleife in der Praxis:

  • Beobachten: Überwachen von Geschäftsmetriken, Markttrends, Benutzerverhalten und Telemetriedaten
  • Orientierung: Analysieren Sie Optionen für das, was Sie liefern können, möglicherweise durch Experimente
  • Entscheiden: Bestimmen, was basierend auf Daten und Geschäftsprioritäten verfolgt werden soll
  • Act: Bereitstellen von funktionierender Software an echte Benutzer und Sammeln von Feedback

Übung zur Zykluszeitberechnung: Denken Sie an Ihren aktuellen Entwicklungsprozess. Wie lange dauert es, von einem Punkt zum anderen zu kommen:

  • Code-Commiten → Produktionsbereitstellung?
  • Feature-Anfrage → Kundenfeedback?
  • Fehlerbericht → Fix in der Produktion?

Beispiel: Wenn es 2 Wochen dauert, bis eine einzeilige Konfigurationsänderung bereitgestellt wird, beträgt die Zykluszeit 2 Wochen. Dies ist Ihre Geschwindigkeitsbegrenzung.

Diagramm mit dem OODA-Schleifenzyklus mit den Phasen

Daten informiert, nicht datengesteuert

Wir empfehlen die Verwendung von Daten, um Entscheidungen in Ihrem nächsten Zyklus zu informieren, aber vermeiden Sie, durch Analysen lähmt zu werden. Erfahrungen aus vielen Organisationen deuten darauf hin, dass Bereitstellungen häufig unterschiedliche Ergebnisse haben:

  • Einige Bereitstellungen haben negative Geschäftsergebnisse
  • Einige Bereitstellungen haben positive Ergebnisse
  • Einige Bereitstellungen machen keinen messbaren Unterschied

Das Schlüsselprinzip: Schnell scheitern bei Initiativen, die das Unternehmen nicht voranbringen, und verstärkt auf Ergebnisse setzen, die Geschäftsziele unterstützen. Dieser Ansatz wird häufig als "Pivot oder Durchhalten" bezeichnet.

Nutzanwendung:

  • Einrichten von A/B-Tests für neue Features
  • Definieren von Erfolgsmetriken vor der Bereitstellung
  • Einrichten von Rollbackverfahren für fehlgeschlagene Experimente
  • Erstellen von Feedbackschleifen zum schnellen Messen von Auswirkungen

Streben nach validierten Lernen

Wie schnell Sie schnell scheitern oder doppelt so viel investieren können, hängt von Ihrer Zykluszeit ab – also davon, wie lange diese Feedbackschleife dauert. Das Feedback, das Sie bei jedem Zyklus sammeln, sollte folgendes sein:

  • Fakten: Basierend auf realen Benutzerverhalten und Systemmetriken
  • Handlungsfähig: Führt zu klaren nächsten Schritten und Entscheidungen
  • Rechtzeitig verfügbar: Schnell genug verfügbar, um die nächste Iteration zu beeinflussen

Dieser evidenzbasierte Ansatz wird als validiertes Lernen bezeichnet – Entscheidungen auf der Grundlage empirischer Beweise statt annahmen oder Meinungen zu treffen.

Beispielmetriken für validiertes Lernen:

  • Benutzerbindungsraten und Featureakzeptanz
  • Systemleistung und Fehlerraten
  • Kundenzufriedenheitsbewertungen und Supporttickets
  • Geschäfts-KPIs (Umsatz, Konvertierungsraten, Aufbewahrung)

Diagramm zur Veranschaulichung des validierten Lernzyklus mit guten, gleichgültigen und schlechten Ergebnissen mit Feedbackschleifen zur kontinuierlichen Verbesserung.

Kürzen der Zykluszeit

Wenn Sie DevOps-Praktiken einführen:

  • Sie verkürzen Ihre Zykluszeit, indem Sie in kleineren Batches arbeiten.
  • Verwenden sie mehr Automatisierung.
  • Sie härten Ihre Releasepipeline.
  • Verbessern Ihrer Telemetrie.
  • Die Bereitstellung erfolgt häufiger.

Diagramm des überprüften Lernens im Vergleich zur Bereitstellungshäufigkeit. Guter, gleichgültiger und schlechter Zyklus.

Optimieren des validierten Lernens

Je häufiger Sie deployen, desto mehr können Sie experimentieren. Desto mehr Möglichkeiten haben Sie, jeden Zyklus zu pivotieren oder beharrlich zu verfolgen und validiertes Lernen zu gewinnen. Diese Beschleunigung beim validierten Lernen ist der Wert der Verbesserung. Stellen Sie sich dies als die Summe des Fortschritts vor, den Sie erreichen, und die Fehler, die Sie vermeiden.

Diagramm des überprüften Lernens im Vergleich zur Bereitstellungshäufigkeit. Guter, gleichgültiger und schlechter Zyklus. Wert der Verbesserungsmetrik.