Wie lässt sich die Software-Entwicklung mit DevOps beschleunigen?

Warum DevOps?

Mit DevOps wird ein Engpassproblem gelöst, das im Zusammenhang mit der agilen Entwicklung steht. Wenn agile Entwickler mit einer höheren Taktfrequenz neue Software oder Code-Updates produzieren, dann haben die herkömmlichen Operations-Teams Schwierigkeiten, die Software zeitnah zu testen und in Betrieb zu nehmen und der Mehrwert der schnellen Entwicklung geht verloren. Der Design- und Erstellungsprozess von Software wurde durch die agile Vorgehensweise zwar iterativer und flexibler, doch dieser Ansatz erstreckte sich nicht über den gesamten Lebenszyklus der Softwareentwicklung (Software Development Lifecycle, SDLC) bis hin zur Bereitstellung.

Als kultureller bzw. philosophischer Ansatz widmet sich DevOps der kontinuierlichen Verbesserung, Zusammenarbeit und Transparenz. IT-Prozesse werden mit Blick auf die Wertschöpfung ganzheitlich betrachtet. Der Fokus von DevOps liegt nicht auf individuellen Aufgabensilos, sondern auf dem gesamten Flow – vom ersten Konzept bis hin zum verfügbaren Produkt oder der fertigen Funktion. Alle Vorgänge dazwischen werden mit dem Ziel optimiert, schneller und gewinnbringender zu arbeiten. Leistungsstarke DevOps-Teams ermöglichen nicht nur schnellere Code-Iterationen und -Bereitstellungen, sondern auch insgesamt kürzere Markteinführungszeiten für neue Konzepte, weniger Bugs und eine stabilere Infrastruktur.

Im Folgenden geben wir einen Überblick über die wichtigsten Konzepte auf dem Gebiet von DevOps und liefern Ansatzpunkte für die Einführung einer DevOps-Kultur in Ihrem eigenen Unternehmen.

DevOps – historische Entwicklung und Betrieb

Die agile Softwareentwicklung begann mit dem „Manifest für agile Softwareentwicklung“ („Manifesto for Agile Development“), einem kurzen Dokument, das 2001 von 17 renommierten Entwicklern veröffentlicht wurde und zugleich auch den Grundstein für die heute bekannten DevOps-Ansätze legen sollte. Darin wurden vier Leitsätze angeführt:

• Individuals and interactions over processes and tools – Individuen und Interaktionen sind wichtiger als Prozesse und Tools.
• Working software over comprehensive documentation – Funktionierende Software ist wichtiger als eine umfassende Dokumentation.
• Customer collaboration over contract negotiation – Die Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
• Responding to change over following a plan – Das Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.

Diese Leitsätze stellten die traditionelle Entwicklung nach der Wasserfall-Methode in Frage, die durch eine strikte Sequenzierung und umfassende Dokumentation sowie durch klar definierte Rollen, Tools und Prozesse gekennzeichnet ist. Doch während agile Entwicklungsteams begannen, Softwareprodukte schneller zu iterieren, indem sie rasch auf wechselnde Anforderungen und andere Umstände reagierten, hatten sich die IT Operations-Teams noch nicht an dieses neue Tempo gewöhnt.

2008 begannen der Belgier Patrick Debois und der Amerikaner Andrew Clay Shafer über die Herausforderungen zu diskutieren, die eine agile IT-Infrastruktur mit sich bringt. Ein Jahr später richtete Debois in Gent (Belgien) die erste Auflage der „devopsdays“ aus. Bei dieser Veranstaltung wurde der Begriff DevOps geprägt, der sich später im IT-Mainstream etablierte.

Nachfolgend werden drei DevOps-Leitsätze aufgeführt. Diese wurden zuerst von Gene Kim, Autor und Befürworter von DevOps, formuliert:

• Systems Thinking – Systemdenken: Ein ganzheitlicher IT-Ansatz, der Entwickler, Tester, Infrastrukturmanager und Konsumenten von Code oder Software umfasst und „die Performance des gesamten Systems in den Vordergrund stellt, nicht die Performance eines abgeschlossenen Arbeitsbereichs oder einer Abteilung.“
• Amplify Feedback Loops – Feedbackschleifen intensivieren: Laut Kim verfolgt „fast jede Prozessoptimierungsinitiative das Ziel, Feedbackschleifen zu verkürzen und zu intensivieren, damit erforderliche Korrekturen kontinuierlich vorgenommen werden können.“
• Continual Experimentation and Learning – Kontinuierliches Experimentieren und Lernen: Während im „Agilen Manifest“ Reaktionsschnelligkeit und Zusammenarbeit besonders geschätzt werden, liegt bei DevOps der Fokus auf kontinuierlicher Verbesserung – auf dem Finden neuer und besserer Arbeitsweisen. Kim beschreibt die Notwendigkeit, „eine Kultur zu schaffen, die Folgendes fördert: kontinuierliches Experimentieren, das Eingehen von Risiken und das Lernen aus Misserfolgen sowie das Verständnis, dass Wiederholung und Übung die Voraussetzung für das Beherrschen einer Aufgabe ist.“

Was macht ein DevOps Team?

Eine DevOps-Kultur basiert auf fachübergreifenden DevOps-Teams, die kontinuierlich neue Funktionen und Services entwickeln und bereitstellen. Beim DevOps-Ansatz sind Entwickler für die Wartung des Codes verantwortlich, den sie schreiben. Folglich lösen sie Incidents effizienter und legen mehr Wert auf die Zuverlässigkeit aller von ihnen erstellten Anwendungen und Funktionen. Darüber hinaus konzentriert sich ein DevOps-Team auf den Lebenszyklus eines ganzen Produkts, nicht nur auf individuell zugewiesene Projekte wie die Erstellung einer neuen Funktion oder die Gestaltung einer Web-Komponente. Mit diesem DevOps-Ansatz bzw. dieser Produktphilosophie (manchmal auch als „Produkte statt Projekte“ / "Products not Projects" beschrieben) kann die IT-Abteilung besser auf geschäftliche Belange ausgerichtet werden und Aufgaben priorisieren, die einen Nutzen für das Geschäft oder den Endbenutzer haben. Was wiederum zu einer besseren Akzeptanz und Nutzung, einer stärkeren Kundenbindung und Umsatzsteigerungen führt.

Was ist der Unterschied zwischen DevOps und agiler Softwareentwicklung?

DevOps ist die Ausweitung der agilen Prinzipien von der Softwareentwicklung auf die Softwarebereitstellung. Während die vom „Agilen Manifest“ angestoßene Entwicklung bessere Methoden bei der Softwareerstellung propagierte, werden beim DevOps-Ansatz ähnliche Prinzipien und Philosophien auf den gesamten Lebenszyklus der Softwareentwicklung angewendet und die agile Entwicklung damit bis zum Release fortgesetzt.

Was bedeutet kontinuierliche Entwicklung in der DevOps-Kultur?

Die kontinuierliche Entwicklung einer DevOps-Kultur schließt mehrere DevOps-Konzepte mit ein: nämlich Continuous Integration und Continuous Delivery (CI/CD) sowie Continuous Deployment. Wenn IT-Teams ständig kleine Verbesserungen vornehmen, veröffentlichen und messen, anstatt sich auf einzelne große Releases (einmal pro Jahr oder noch seltener) zu beschränken, können sie ihr Angebot stetig verbessern. Unabhängig davon, ob es sich bei diesem Angebot um das Kernprodukt eines softwarebasierten Unternehmens wie Netflix oder Instagram oder um die Verbesserung einer Website oder eines IT-Services handelt, kann das Unternehmen mit dem DevOps Ansatz auf einem Markt wettbewerbsfähig bleiben, auf dem innovative Startups regelmäßig Marktführer – und ganze Märkte – aushebeln.

Was bedeutet Continuous Integration (kontinuierliche Integration) in der DevOps-Kultur?

Unter Continuous Integration versteht man die Praxis, nach dem Abschluss einzelner Aufgaben regelmäßig neuen Code in den Hauptquellcode einzufügen. Neuer Code wird in ein zentrales, gemeinsam genutztes Repository eingespeist, wo ein automatisierter Build die Änderungen testet und validiert. So werden Probleme schnell erkannt, die DevOps-Entwickler erhalten umgehend Feedback und können direkt die erforderlichen Änderungen vornehmen.

Was bedeutet Continuous Delivery (kontinuierliche Lieferung) in der DevOps-Kultur?

Unter Continuous Delivery versteht man die Praxis, neuen Code direkt bei der Integration zu testen und damit die Prozessbeschleunigung über die kontinuierliche Integration hinaus fortzusetzen. Mit Continuous Delivery wird das Testen und Staging von neuem Code automatisiert, um ihn für die Bereitstellung vorzubereiten.

Dieser DevOps-Prozess kann Unit-, Integrations-, Funktions- und Regressionstests umfassen. Wenn der Code genehmigt ist, erfolgt ein automatisches Staging. In diesem Schritt wird der geprüfte Code jedoch nicht automatisch bereitgestellt. Dies erfolgt im Rahmen der kontinuierlichen Bereitstellung.

Was bedeutet Continuous Deployment (kontinuierliche Bereitstellung) in der DevOps-Kultur?

Unter Continuous Deployment versteht man die Automatisierung der Freigabe von neuem Code, der im Rahmen der Continuous Integration und Continuous Delivery integriert und genehmigt wird. Code, der durch die automatisierten Lieferungsprozesse erfolgreich getestet wurde, wird in den Staging-Bereich übernommen und an die Produktionsumgebung freigegeben. Damit steht die neue Funktion den Endbenutzern sofort zur Verfügung.

Da der Code ohne manuelles Eingreifen vom DevOps-Entwickler an den Endbenutzer weitergegeben wird, sind mit einer kontinuierlichen Bereitstellung Risiken verbunden. Ganz allgemein eignet sich die kontinuierliche Bereitstellung am besten für risikoarme Produkte und Funktionen. Bei sensiblen Daten, hohem Sicherheitsrisiko, regulierungsbehördlichen Verpflichtungen oder großem finanziellen Risiko ist es weniger wahrscheinlich, dass DevOps-Teams das Prinzip der kontinuierlichen Bereitstellung anwenden. Abgesehen von diesen Überlegungen gilt die kontinuierliche Bereitstellung als ein wichtiges Ziel des DevOps-Ansatzes, da sie ein Maximum an Geschwindigkeit und eine kurze Time-to-Value bietet.

Continuous Deployment und Continuous Delivery, beide häufig mit „CD“ abgekürzt, werden oftmals verwechselt. Doch während Continuous Delivery Software liefert, die bereit für den Release ist, werden die Updates erst durch Continuous Deployment (oder manuelle Bereitstellung) in der Produktionsumgebung für Endbenutzer verfügbar gemacht.

Was ist die DevOps-Architektur?

Der Begriff DevOps-Architektur bezieht sich in der Regel auf die Infrastruktur zum Erreichen der mit einer DevOps-Kultur angestrebten Ziele. Es gibt keine einheitliche, verbindliche Architektur für DevOps und IT-Organisationen müssen ihre bestehenden Architekturen nicht unbedingt über Bord werfen, um die DevOps-Kultur zu ermöglichen. Allerdings gibt es wichtige Grundsätze und Best Practices für die Architektur in DevOps-Organisationen.

Das Aufkommen von DevOps fällt zeitlich mit dem Aufkommen von Cloud-Plattformen zusammen. Auch Cloud- und andere Virtualisierungstechnologien tragen wesentlich zum Erfolg von DevOps bei. Cloud-Plattformen, Virtualisierung und Microservices gehören also zu den Technologien, die DevOps-Organisationen zu Grunde liegen.

• Cloud: Cloud-Plattformen ermöglichen der IT-Abteilung die Bereitstellung von Ressourcen in virtuellen Umgebungen (der Cloud) anstelle von lokalen Umgebungen. Diese Plattformen bieten Benutzern einen schnellen Zugriff auf Ressourcen und eine hohe Flexibilität. (Siehe auch „Welche Rolle spielt die Cloud in DevOps“ weiter unten.)
• Virtualisierung: Bevor es Virtualisierungsmöglichkeiten gab, war ein Server ein echtes Stück Hardware und wer einen zweiten Server brauchte, musste sich einen kaufen. Virtualisierung ermöglicht die Erstellung virtueller Server (oder Desktops etc.), sodass Softwareteams keine neue Hardware mehr bereitstellen müssen, sondern auf bestehenden lokalen oder Cloud-Servern virtuelle Umgebungen erstellen können. Damit wird für agile Teams ein beträchtlicher Engpass beseitigt. Darüber hinaus steigert die automatisierte Bereitstellung das Tempo in einem Maße, dass DevOps-Entwickler innerhalb von Minuten auf die erforderlichen Ressourcen zugreifen können.
• Microservices: Eine Microservice-Architektur besteht aus lose gekoppelten Einheiten endlicher Funktionalität, die sich zu einem Gesamtsystem zusammenfügen. Größere Systeme und Anwendungen lassen sich leichter aufbauen und modifizieren, wenn sie aus diesen wiederverwendbaren Modulen mit einer einzigen Funktion bestehen. Dieser Ansatz mit unabhängigen Komponenten ermöglicht es den einzelnen DevOps-Teams, Updates mit weniger Abhängigkeiten zu implementieren, sodass sie schneller vorankommen und weniger Gefahr laufen, durch eine Änderung eine Unterbrechung zu verursachen. In ihrem Buch „DevOps: A Software Architect’s Perspective“ stellen die Autoren Len Bass, Ingo Weber und Liming Zhu fest, dass „die Microservice-Architektur dafür gemacht ist, viele der Probleme zu lösen, die zur Schaffung von DevOps geführt haben.“

Die Architektur für eine DevOps-Organisation beinhaltet Cloud-Plattformen, Virtualisierung und Microservices. Darüber hinaus ist das Ziel, Testautomatisierungs-, Monitoring- und Sicherheitspraktiken zu optimieren, um DevOps-Workflows zu unterstützen. Im Allgemeinen ist Automatisierung ein wichtiges Element von DevOps und neben einem klaren Trend zu einem Cloud-First-Ansatz gibt es auch einen Trend zur Automatisierung innerhalb von DevOps-Kulturen. Diese Trends oder Best Practices prägen die Architektur der DevOps-Organisation.

Welche Rolle spielt die Cloud in DevOps?

Cloud-Computing ist ein wesentlicher Faktor der DevOps-Kultur. Die Geschwindigkeit, Größe und Effizienz der Cloud ermöglicht es agilen und DevOps-Teams, ihr Arbeitstempo und die Qualität ihrer Arbeit zu erhöhen. SaaS-Tools (Software-as-a-Service) sorgen dafür, dass Software-Teams effizienter und wirtschaftlicher arbeiten – und die SaaS-Software selbst ist ein Beispiel für ein stetig iteriertes Produkt, dass praktisch einen DevOps-Ansatz erfordert.

Auch wenn Sie vielleicht nicht jede Anwendung in die Cloud migrieren, empfiehlt es sich in der DevOps-Praxis, bei jeder neuen Anwendung nach der „Cloud-First“-Methode vorzugehen. Bei der Planung einer neuen Anwendung oder eines neuen Services sollten sich DevOps-Entwickler nicht etwa fragen: „Sollen wir hierfür die Cloud nutzen?“, sondern vielmehr: „Gibt es einen Grund, hierfür die Cloud nicht zu verwenden?“ Manchmal wird es Gründe geben, beispielsweise Sicherheitsaspekte, Anforderungen von Regulierungsbehörden oder Faktoren in Ihrer Gesamtinfrastruktur, doch die Cloud sollte für eine DevOps-Organisation der Standard sein, nicht eine zweite Option.

Was ist DevSecOps?

DevSecOps integriert Sicherheitspraktiken in den DevOps-Prozess. Anstatt am Ende des Prozesses Code an ein separates Security-Team weiterzugeben, ist bei diesem Ansatz jeder für die Sicherheit verantwortlich. DevSecOps zielt darauf ab, schneller sichere Software zu liefern, und zwar mit weniger Defekten in späten Prozessphasen und weniger Nachbearbeitung.

Warum DevSecOps?

Es gibt drei grundlegende DevSecOps-Leitsätze:

• Introduce security thinking early in the development process – Sicherheitsdenken mithilfe von DevSecOps bereits in einer frühen Phase des Entwicklungsprozesses einbinden
• Introduce security thinking as a core development responsibility, not a separate team’s concern – Sicherheitsdenken als Kernaufgabe der Softwareentwicklung betrachten, nicht als Aufgabe eines separaten DevOps-Teams, das DevSecOps erst nachgelagert integriert
• Automate security processes to maintain the efficient flow of DevOps – Sicherheitsprozesse zur Aufrechterhaltung effizienter DevOps-Abläufe auf Basis von DevSecOps automatisieren

In einem 2012 veröffentlichten DevSecOps-Manifest werden die Grundsätze von DevSecOps detaillierter ausgeführt.

Wer braucht DevOps?

Die Best Practices für DevOps beruhen auf einer bestimmten DevOps-Kultur und propagieren einen flexiblen, zusammenarbeitsorientierten DevOps-Ansatz mit einem Fokus auf Effizienz, Agilität und der Lieferung eines Endwertes. Es gibt jedoch kein einheitliches Regelwerk oder festgelegte Best Practices für DevOps, um diese weit gefasste Philosophie in die Tat umzusetzen. Bewährte Vorgehensweisen und der Nutzen von DevOps variieren von Branche zu Branche und die Bedürfnisse eines DevOps-Entwicklers der Softwarebranche unterscheiden sich beispielsweise von den Bedürfnissen der DevOps-Entwickler im Einzelhandel, in der Industrie, im Gesundheitswesen oder im Finanzdienstleistungssektor.

Damon Edwards und John Willis, frühe Verfechter von DevOps, haben das Akronym CAMS eingeführt, das wichtige Entwicklungsgrundsätze umfasst. Es steht für steht für DevOps-Kultur, Automatisierung, Messen und Teilen (Culture, Automation, Measurement, Sharing).

Wann DevOps? Best Practice Beispiele:

Darüber hinaus benennt die DevOps Agile Skills Association (DASA) die sechs nachfolgend zusammengefassten DevOps-Grundsätze :

• Customer-centric action – Kundenorientiertes Handeln: Kurze Feedbackschleifen, um die Perspektive der Kunden zu verstehen und einzubinden.
• Create with the end in mind – Schon zu Beginn an das Ergebnis denken: Abkehr von der traditionellen Herangehensweise mit genau vorgegebenen individuellen Rollen und stattdessen verstärkte Konzentration darauf, wie die DevOps-Gesamtorganisation IT-Produkte für interne oder externe Kunden entwickelt.
• End-to-end responsibility – End-to-End-Verantwortung: Abkehr von dem Prinzip, dass jedes Teammitglied nur für die eigene Funktion verantwortlich ist (sodass Entwickler nichts mit Infrastrukturfehlern zu tun haben und Operations-Teams sich nicht für fehlerhaften Code verantwortlich fühlen). Stattdessen strebt DevOps nach der Auflösung dieses Silodenkens und rückt gute Ergebnisse in den Mittelpunkt, für deren Erzielung das gesamte DevOps-Team verantwortlich ist.
• Cross-functional autonomous teams – Funktionsübergreifende, autonome Teams:Für jedes IT-„Produkt“ ist ein DevOps-Team erforderlich, dass mit allen Qualifikationen und Kompetenzen ausgestattet ist, um das Produkt von der Konzeption und bis zur Verfügbarkeit und durch Verbesserungszyklen bis zum Ende seines Lebenszyklus zu begleiten.
• Continuous improvement – Kontinuierliche Verbesserung: DevOps-Teams streben immer danach, die Geschwindigkeit und Qualität zu erhöhen und Verschwendung einzudämmen.
• Automate everything you can – Automatisiere so viel du kannst: Eine möglichst umfangreiche IT-Automatisierung ist entscheidend, um schneller, effizienter und erfolgreicher zu arbeiten. So können die Teammitglieder von DevOps sich gewinnbringenderen Aufgaben widmen und die Möglichkeiten für menschliches Versagen werden reduziert.

Was sind DevOps-Tools?

DevOps-Tools erleichtern die Verwaltung von Code-Entwicklung, Tests und Infrastruktur. DevOps-Tools unterstützen Unternehmen außerdem daher bei der Umsetzung der DevOps-Grundsätze. Dabei bezieht sich DevOps vor allem auf die Entwicklung und Bereitstellung von Software-Produkten (siehe auch „Erste Schritte“ weiter unten). Um diese kulturelle Entwicklung voranzutreiben, spielen Automatisierungstools und andere Produkte jedoch eine wichtige Rolle.

Es gibt zahlreiche Software-Lösungen, die eigens entwickelt wurden, um die DevOps-Kultur in die Praxis umzusetzen. Dies sind unter anderem DevOps-Tools für Versionsverwaltung, Konfiguration, Release Management und Monitoring.

Welche DevOps-Tools sind die besten?

Die besten DevOps-Tools sind diejenigen, die die DevOps-Prozesse und Mitarbeiter unterstützen, welche wiederum Ihre DevOps-Kultur formen. DevOps ist kein Produkt, dass Sie einfach kaufen und implementieren – nach dem Motto: „So, jetzt haben wir DevOps“. In den frühen DevOps-Tagen veröffentlichte DevOps-Technologe Alex Honor einen Beitrag mit dem Titel „People Over Process Over Tools“ in dem er noch einmal betonte, dass die DevOps-Kultur bei dieser Bewegung eine wichtigere Rolle spielt als die Ausstattung mit DevOps-Tools.

Welche bekannten DevOps-Tools sind besonders hilfreich?

Dennoch gibt es eine Reihe bemerkenswerter Produkte, die für DevOps-Teams sehr hilfreich sind. Nachfolgend eine nicht vollständige Auflistung einiger bekannter DevOps-Tools (Open-Source und proprietär):

• Quellcodeverwaltung: Git (GitLab, GitHub), Bitbucket
• Konfigurationsverwaltung: Puppet, Chef, Ansible, CFEngine
• Release-Management: Jenkins, Travis, CircleCl, TeamCity, Gradle, Bamboo
• Orchestrierung: Mesos, Zookeeper, Kubernetes
• Monitoring, Virtualisierung, Containerisierung: Nagios, Icignia, Monit, OpenStack, Vagrant, AWS, Docker, Kubernetes
• Log- und Anwendungs-Lebenszyklus-Analyse: Splunk ist ein führendes DevOps-Tool für das Log-Management und ideal für DevOps.

Was sind die ersten Schritte zum Einstieg in DevOps?

Beim Einstieg in DevOps sollten Sie zuerst Ihre bestehende Kultur analysieren. Ermitteln Sie die Silos und Engpässe, die einer raschen Entwicklung, Bereitstellung, Rückmeldung und stetigen Iteration von DevOps-Prozessen im Wege stehen, um zu verstehen, wo es Verbesserungspotenzial gibt.

Andi Mann, Autor und Chief Technology Advocate bei Splunk, rät DevOps-Neulingen Folgendes: „Planen Sie basierend auf der Einzigartigkeit Ihres Unternehmens Ihre eigene Route zu DevOps. Achten Sie jedoch bei der Routenplanung darauf, die Wegpunkte einzubinden, die wichtige Erfolgsindikatoren für DevOps darstellen.“ Einige Leitlinien: Beseitigen Sie Reibungsverluste und Engpässe. Nehmen Sie Fehlschläge in Kauf (und lernen Sie daraus). Messen Sie und sorgen Sie für eine kontinuierliche Weiterentwicklung von DevOps.

5 grundlegende DevOps-Praktiken:

In dem von Puppet, einem führenden DevOps-Softwarehersteller, und Splunk erstellten Bericht über den Stand von DevOps 2018 wird die DevOps-Evolution in fünf Phasen unterteilt. Der Fortschritt wird nach dem CAMS-Modell in den Bereichen DevOps-Kultur, Automatisierung, Messen und Teilen bewertet. In dem Bericht werden fünf grundlegende Praktiken im Bereich DevOps genannt, die für die Einführung und den Erfolg von DevOps eine entscheidende Rolle spielen:

1. Monitoring- und Benachrichtigungsprozesse sind durch das DevOps-Team konfigurierbar, das den Service betreibt.
2. Bereitstellungsmuster für die Erstellung von Anwendungen oder Services werden wiederverwendet.
3. Testmuster für die Erstellung von Anwendungen oder Services werden wiederverwendet.
4. DevOps-Teams tragen zur Verbesserung der von anderen Teams bereitgestellten Tools bei.
5. Konfigurationen werden mit einem Konfigurationsmanagement-Tool verwaltet.

Die wichtigsten DevOps-KPIs:

Wichtige KPIs von DevOps sind unter anderem:

• Bereitstellungshäufigkeit: Das Ziel sind häufigere, kleinere Bereitstellungen.
• Häufigkeit fehlgeschlagener Bereitstellungen: Das Ziel ist eine Reduzierung.
• Pro Quartal veröffentlichte Funktionen: Die Messung muss nicht quartalsweise erfolgen, für die meisten Führungskräfte aus dem Business-Bereich ist dies jedoch der maßgebliche Zeitraum.
• MTTD (Mean-Time-To-Discovery): Wenn etwas schief läuft, wie lange dauert es dann, bis Sie es bemerken?
• MTTR (Mean-Time-To-Recovery): Wenn etwas schief läuft, wie lange dauert es dann, bis der Fehler behoben ist?
• MLT (Mean Lead Time): Wie groß ist der Zeitraum von Anforderung von Code bis zu seiner Implementierung.
• Uptime: Nachverfolgen der Verfügbarkeit, wobei sowohl geplante Ausfallzeiten aufgrund von Wartungsroutinen als auch ungeplante Ausfälle gemessen werden.
• Defect Escape Rates: Anzahl der Fehler, die es in die Produktion schaffen, im Vergleich zu der Anzahl der Fehler, die von Ihren QS-Teams herausgefiltert werden.
• Anwendungs-Performance: Wie leistungsfähig ist eine Anwendung nach einer Änderung im Vergleich zu vorher?

Sobald Sie Ihre Herausforderungen ermittelt haben und wissen, wie Sie Fortschritte messen wollen, können Sie Ihre Unternehmenskultur anpassen. Brechen Sie die Silos auf, in denen Entwickler, Tester, Operations-Teams und Sicherheitsanalysten abgeschottet sind. Binden Sie Geschäftsanalysten in die Gespräche ein. Klären Sie alle Beteiligten darüber auf, dass ihr Ziel fortan nicht mehr darin besteht, Aufgabenlisten abzuarbeiten, sondern gemeinsam Verantwortung für eine schnellere und qualitativ hochwertigere Softwareentwicklung und -lieferung zu übernehmen. Kombinieren Sie Fortbildungsmöglichkeiten, die Vorbehalte gegenüber DevOps abbauen, mit Änderungen an Prozessen und Infrastruktur.

Zu guter Letzt ist es wichtig, sich noch einmal bewusst zu machen, dass sich DevOps nicht innerhalb von sechs oder zwölf Monaten perfektionieren lässt. Um es mit den Worten des DevOps-Verfechters Jez Humble auszudrücken: „DevOps ist kein Ziel, sondern ein nie endender Prozess kontinuierlicher Verbesserung.“

DevOps ist keine Modeerscheinung oder eine bloße Option. Das kristallisiert sich immer stärker heraus. Die Idee hinter DevOps, also „die IT-Abteilung auf geschäftliche Belange hin auszurichten“, wird seit mehr als einem Jahrzehnt bis in die Vorstandsetagen hinein thematisiert. Die DevOps-Philosophie und die damit verbundenen Praktiken haben sich als gute Möglichkeit etabliert, bessere IT-Produkte schneller bereitzustellen. Berühmte „Unicorn“-Unternehmen wie Netflix, LinkedIn, Facebook, Amazon und Google feiern mit DevOps spektakuläre Erfolge, doch der DevOps-Ansatz wird auch bei traditionelleren Unternehmen immer populärer.

Es gibt heute kein Unternehmen mehr, das nicht versucht, auf dem Markt reaktionsfähiger zu werden. Es gibt keine Organisation des öffentlichen Sektors, die nicht versucht, ihr Serviceangebot mithilfe von DevOps zu verbessern. Angesichts steigender Kundenerwartungen und einer wahren Datenflut kann die IT nicht stillstehen. Und derzeit bringt nichts so viel Bewegung ins Spiel wie DevOps.