DevOps: Schluss mit den Grenzen zwischen Entwicklung und Operations

Abbildung: DevOps-Schleife

Was ist DevOps?

DevOps bezeichnet eine Reihe von Praktiken, die zur Automatisierung und Integration der Prozesse zwischen Softwareentwicklungs- und IT-Teams beitragen. Ziel sind schnellere und zuverlässigere Entwicklungs-, Test- und Release-Verfahren. Der Begriff "DevOps" setzt sich aus "Development" (Entwicklung) und "Operations" (Betrieb) zusammen. DevOps bedeutet eine Veränderung der Teamkultur, die eine Brücke zwischen den früher strikt voneinander getrennten Entwicklungs- und Operations-Teams schlägt.

Atlassian-DevOps-Unendlichkeitsrad

Im Grunde ist DevOps als Unternehmenskultur, Bewegung oder Philosophie zu verstehen.

Sie führt Entwickler- und Operations-Teams näher zusammen und geht mit einer Veränderung der Denkweise, einer verbesserten Zusammenarbeit und einer engeren Integration einher. Mit Agile, Git, Continuous Delivery, Automatisierung und anderen Techniken steigert DevOps die Effizienz und Innovationskraft von Entwickler- und Operations-Teams und erhöht den Nutzen für das Unternehmen und die Kunden.


DevOps ist nicht die Sache einer Einzelperson. Alle sind gemeinsam gefragt.

Christophe Capel
Principal Product Manager, Jira Service Desk

Chef.io-Logo

Wer nutzt DevOps?

Chef ist das Unternehmen hinter der Chef Automate-Plattform für DevOps-Workflows. Zehntausende von Entwicklern nutzen Chef zum Testen, Automatisieren und Verwalten ihrer Infrastruktur. Das Unternehmen aus Seattle ist einer der Pioniere der DevOps-Bewegung und hat mit Produkten wie Chef, InSpec, Habitat und Chef Automate neue Wege der Entwicklung und Auslieferung von Software und Anwendungen vorangetrieben. Chef nutzt die Atlassian-Plattform, um mit seinen eigenen DevOps-Praktiken zu experimentieren und sie zu optimieren.

Die Geschichte von DevOps

Die DevOps-Bewegung entstand zwischen 2007 und 2008, als IT-Operations- und Softwareentwickler-Communitys zum Ausdruck brachten, dass ihrer Meinung nach in der Branche etwas gehörig im Argen lag.

Sie protestierten gegen das herkömmliche Modell zur Softwareentwicklung, bei dem die Urheber des Codes organisatorisch und funktionell völlig von den für das Deployment und den Support des Codes zuständigen Teams getrennt waren.

Die Entwickler auf der einen Seite und die IT-/Ops-Experten auf der anderen verfolgten unterschiedliche (und oft rivalisierende) Ziele, gehörten unterschiedlichen Abteilungen an, wurden nach unterschiedlichen KPIs (Key Performance Indicators) beurteilt und arbeiteten oft in unterschiedlichen Stockwerken oder gar unterschiedlichen Gebäuden. So blieben die Teams isoliert und befassten sich nur mit ihren eigenen Zuständigkeitsbereichen, Überstunden, fehlerhaften Releases und unzufriedenen Kunden. Es musste einen besseren Weg geben. Die zwei Communitys kamen allmählich miteinander ins Gespräch. Federführend bei diesem Austausch waren unter anderem Patrick Dubois, Gene Kim und John Willis.

Was in Onlineforen und bei lokalen Treffen begann, ist inzwischen ein wichtiges Zeitgeist-Thema in der Softwarebranche. Wahrscheinlich bist du deshalb auf diese Seite gestoßen. Du und dein Team haben festgestellt, welche Nachteile isolierte Teams und eine mangelnde Kommunikation im Unternehmen haben.

Ihr nutzt agile Methoden für Planung und Entwicklung, müsst jedoch immer noch zahlreiche Hindernisse überwinden, bis der Code freigegeben werden kann. Du hast von DevOps erfahren und gehört, welche scheinbar magische Wirkung es auf Teams haben kann: In einer von Atlassian durchgeführten Umfrage unter 500 DevOps-Anwendern¹ gaben fast alle (99 %) der befragten DevOps-Teams an, sich des Erfolgs ihres in der Produktionsumgebung veröffentlichten Codes sicher zu sein.

DevOps ist aber keine Magie und wird nicht über Nacht alles zum Besten verändern. Die gute Nachricht: Du musst nicht warten, bis sich die Führungsetage zu einer größeren Initiative durchgerungen hat. Wenn du den Nutzen von DevOps kennst und schrittweise kleine Veränderungen umsetzt, ist dein Team innerhalb kürzester Zeit auf dem richtigen Weg. Sehen wir uns die Vorteile einmal näher an.

Im Vergleich zur Führungsetage stimmen die "an vorderster Front" stehenden DevOps-Anwender mit höherer Wahrscheinlichkeit der Aussage zu, dass es schwierig ist, die Wirkung von DevOps-Fortschritten und -Erfolgen zu messen: In der Führungsetage sind es 46 %, unter den Anwendern 62 %.

Umfrage von Atlassian unter DevOps-Anwendern

Vorteile

Symbol: vernetzte Personen

Zusammenarbeit und Vertrauen

Wir haben eine Studie durchgeführt, laut der Zusammenarbeit der wichtigste Faktor für den Erfolg eines DevOps-Teams ist. Eine auf gemeinsamer Verantwortung, Transparenz und schnellem Feedback beruhende Unternehmenskultur ist die Grundlage jedes gut funktionierenden DevOps-Teams. Zusammenarbeit und Problemlösung wurden in unserer Studie als wichtigste Elemente einer erfolgreichen DevOps-Kultur eingestuft.

Isoliert arbeitende Teams denken oft nicht in Systemen, wie es bei DevOps üblich ist. Wer in Systemen denkt, weiß, dass seine Handlungen nicht nur das eigene Team beeinflussen, sondern auch alle anderen am Release-Prozess beteiligten Teams. Ein Mangel an Transparenz und gemeinsamen Zielen führt zu mangelnder Abhängigkeitsplanung, nicht abgestimmten Prioritäten, Schuldzuweisungen und fehlendem Verantwortungsgefühl. Dies bremst die Velocity und schadet der Qualität. DevOps verändert die Denkweise, indem alle Entwicklungsprozesse ganzheitlich berücksichtigt und die Grenzen zwischen Entwickler- und Operations-Teams überwunden werden.

Geschwindigkeitsmesser-Symbol

Schnellere Releases und intelligenteres Arbeiten

Geschwindigkeit ist das wichtigste Ziel. Teams, die nach DevOps vorgehen, produzieren häufigere, hochwertigere und stabilere Releases.

Wenn keine automatisierten Test- und Review-Zyklen vorhanden sind, gehen Releases nur schleppend voran, und die schlechte Incident Response bei Vorfällen beeinträchtigt die Velocity und das Vertrauen im Team. Isolierte Tools und Prozesse erhöhen die Betriebskosten, erfordern ständige Kontextwechsel und bremsen jegliche Dynamik aus. Durch Tools, die die Automatisierung und neue Prozesse vorantreiben, können Teams ihre Produktivität steigern und problemloser zu häufigeren Releases gelangen.

Symbol: Herzschlag

Kürzere Problemlösungszeit

Am erfolgreichsten sind die Teams mit dem kürzesten Feedbackkreislauf. Vollständige Transparenz und eine nahtlose Kommunikation sorgen bei DevOps-Teams für minimale Ausfallzeiten und eine beschleunigte Problemlösung.

Wenn kritische Probleme nicht schnell behoben werden, beeinträchtigen sie die Kundenzufriedenheit. Ohne eine offene Kommunikation werden wichtige Probleme jedoch leicht übersehen, was wiederum den Druck und den Frust in den Teams erhöht. Findet hingegen eine offene Kommunikation statt, können die Entwicklungs- und Operations-Teams Probleme gemeinsam lösen, Vorfälle beheben und Hindernisse in der Release-Pipeline schneller beseitigen.

Werkzeugsymbol

Besseres Management ungeplanter Aufgaben

Ungeplante Aufgaben ergeben sich in jedem Team und wirken sich meist negativ auf die Produktivität aus. Mit etablierten Prozessen und einer klaren Priorisierung können die Entwicklungs- und Operations-Teams diese ungeplanten Aufgaben besser managen und sich dabei weiterhin auf die geplanten Aufgaben konzentrieren.

Eine Weitergabe und Priorisierung von ungeplanten Aufgaben über mehrere Teams und Systeme hinweg ist ineffizient und lenkt von der eigentlichen Arbeit ab. Durch mehr Transparenz und proaktive Retrospektiven können Teams diese ungeplanten Aufgaben besser vorhersehen und untereinander verteilen.

Das CALMS-Framework für DevOps

CALMS ist ein Framework, mit dem bewertet wird, inwiefern ein Unternehmen in der Lage ist, DevOps-Prozesse einzuführen. Außerdem kann damit der Erfolg während der DevOps-Transformation gemessen werden. Das Akronym stammt von Jez Humble, Mitautor von "The DevOps Handbook". Es steht für Folgendes:


Symbol: Pullover

Unternehmenskultur

DevOps ist nicht einfach ein Prozess oder ein anderer Ansatz für die Entwicklung. Vielmehr bedeutet DevOps einen kompletten Wandel der Unternehmenskultur. Ein wichtiger Aspekt der DevOps-Kultur ist Zusammenarbeit.

Alle Tools und Automatisierungsmaßnahmen der Welt sind wertlos, wenn die Entwickler- und IT-/Ops-Teams nicht zusammenarbeiten. DevOps behebt nämlich keine Probleme bei Tools. Vielmehr löst es menschliche Probleme.

Du kannst dir DevOps als eine Weiterentwicklung von agilen Teams vorstellen. Der Unterschied besteht darin, dass bei DevOps standardmäßig auch die Operations-Abteilung berücksichtigt wird. Die Umstellung von funktionsbasierten Teams auf projekt- oder produktorientierte Teams ist ein Schritt in die richtige Richtung. In einem solchen Team sollten die Bereiche Entwicklung, Qualitätssicherung, Produktmanagement, Design, Operations, Projektmanagement und alle anderen für das Projekt erforderlichen Kompetenzen vertreten sein. Es ist allerdings nicht sinnvoll, einem Team alles zu überlassen oder gezielt "DevOps-Profis" einzustellen. Stattdessen sollten projektbasierte Teams eingerichtet werden, die nahtlos zusammenarbeiten können.

Nur wenige Dinge fördern die Zusammenarbeit so sehr wie ein gemeinsames Ziel und ein Plan, wie dieses Ziel zusammen erreicht werden kann. Manche Unternehmen sind von einer plötzlichen Umstellung auf projektbasierte Teams überfordert. Nimm dir in diesem Fall kleinere Schritte vor. Entwicklungsteams können – und sollten – relevante Mitglieder des Operations-Teams zu Sprint-Planungssitzungen, täglichen Stand-up-Meetings und Sprint-Demos einladen. Die Operations-Teams ihrerseits können die wichtigsten Entwickler in ihre Meetings einbeziehen. Mit dieser organischen, agilen Arbeitsweise bleibt ihr bei Projekten, Ideen und Schwierigkeiten der anderen immer auf dem neuesten Stand.

Herausforderungen und sogar Notfälle sind ein effektiver Test für die DevOps-Unternehmenskultur: Lösen Entwickler-, Operations- und Kundensupportteams Probleme gemeinsam und im Team? Steht bei der Post-Mortem-Analyse des Vorfalls die Korrektur von Prozessen im Mittelpunkt, oder wird in erster Linie ein Schuldiger gesucht? Wenn du diese Fragen mit "ja" beantworten kannst, ist dies ein guter Hinweis darauf, dass dein Team bereits über eine DevOps-Struktur verfügt.

Bei den erfolgreichsten Unternehmen wird die DevOps-Kultur in allen Abteilungen und auf allen Hierarchieebenen gepflegt. Die Kommunikation erfolgt dort offen und regelmäßig. Alle sind überzeugt, dass das Produktmanagement ebenso viel Einfluss auf die Kundenzufriedenheit hat wie das Entwicklerteam. Sie wissen, dass DevOps nicht von einem Team alleine bewältigt werden kann. Alle sind gemeinsam gefragt.

Abbildung: Zahnräder

Automatisierung

Durch Automatisierung entfallen manuelle Routinearbeiten. Teams profitieren von reproduzierbaren Prozessen und können zuverlässige Systeme erstellen.

Die Automatisierung von Erstellung, Tests, Deployment und Provisioning ist für Teams, die darüber noch nicht verfügen, für gewöhnlich der erste Ansatzpunkt. Gibt es einen besseren Grund für die Zusammenarbeit zwischen Entwicklern, Testern und Betreibern als die Entwicklung von Systemen, die allen nützen?

Teams, die gerade erst mit der Automatisierung beginnen, befassen sich in der Regel zunächst mit Continuous Delivery. Dabei durchläuft jede Codeänderung eine Reihe automatisierter Tests – oft auf der Grundlage einer Cloud-basierten Infrastruktur. Builds, die diese Tests bestanden haben, werden zu Paketen zusammengestellt und über automatisierte Deployments bis zur Produktion befördert.

Warum? Computer führen Tests rigoroser und zuverlässiger durch als Menschen. Mit diesen Tests werden Bugs und Sicherheitslücken schneller erkannt. Außerdem wird dank der automatisierten Deployments das IT-/Ops-Team bei Server-"Abweichungen" zwischen Umgebungen gewarnt, damit es beim Release weniger bis keine Überraschungen gibt.

Ein weiterer wichtiger Aspekt von DevOps ist die Idee, Konfigurationen als Code zu begreifen. Entwickler setzen vermehrt auf modulare, zusammenstellbare Anwendungen, weil diese zuverlässiger funktionieren und leichter zu warten sind. Diese Denkweise lässt sich auch auf die zugrunde liegende Infrastruktur übertragen. Dabei spielt es keine Rolle, ob diese sich in der Cloud oder im unternehmenseigenen Netzwerk befindet.

"Konfiguration als Code" und "Continuous Delivery" sind nicht die einzigen Automatisierungsarten bei DevOps, aber sie sind eine gesonderte Erwähnung wert, weil sie den Graben zwischen Entwickler- und Operations-Teams überbrücken. Wenn bei DevOps sorgfältig getesteter Code über automatisierte Deployments an identisch bereitgestellte Umgebungen übermittelt wird, muss er auch nicht mehr auf unterschiedlichen Systemen getestet werden.

Symbol: Lean DevOps

Lean

Beim Stichwort "Lean" denken wir im Zusammenhang mit Software in der Regel an den Wegfall geringwertiger Aktivitäten und an schnelle Reaktionen – also an spontane, agile Arbeitsweisen. Noch wichtiger für DevOps sind das Konzept der kontinuierlichen Verbesserung und die positive Einstellung gegenüber Fehlern. Sie schaffen die Grundlage für Offenheit gegenüber Experimenten.

Wer sich mit DevOps beschäftigt, entdeckt überall Möglichkeiten zur kontinuierlichen Verbesserung. Manche sind offensichtlich, beispielsweise das Abhalten regelmäßiger Retrospektiven zur Verbesserung der Teamprozesse. Andere sind subtiler, wie A/B-Tests unterschiedlicher Onboarding-Ansätze für neue Benutzer deines Produkts.

Dank der Agile-Entwicklung ist die kontinuierliche Verbesserung inzwischen in aller Munde. Frühe Verfechter der Agile-Methodik haben bewiesen, dass es besser ist, wenn Kunden schon heute ein einfaches Produkt nutzen können, als wenn ihnen in sechs Monaten ein rundum perfektes Produkt zur Verfügung steht. Wenn das Produkt ständig weiter verbessert wird, bleiben die Kunden ihm auch treu.

Dabei sind Fehler unvermeidlich. Du kannst deinem Team also gleich vermitteln, dass es Fehler annehmen, sie beheben und daraus lernen soll (manche bezeichnen dies als "Unempfindlichkeit"). Wir bei Atlassian betrachten gelegentliche Fehler als ein Zeichen echten Engagements.

Aus DevOps-Sicht sind Fehler keine zu ahndenden Vergehen. Die Teams rechnen mit gelegentlichem Scheitern und sind daher auf eine schnelle Erkennung und Behebung von Fehlern ausgerichtet. Bei der Post-Mortem-Analyse wird ermittelt, wo Schwachstellen in Prozessen liegen und wie diese behoben werden können. Es geht nicht darum, einem Teammitglied die Schuld in die Schuhe zu schieben. Warum? Weil kontinuierliche Verbesserung und Fehler Hand in Hand gehen.

Abbildung: Lineal

Messung

Ohne Daten ist es schwer zu beweisen, dass deine Bemühungen um kontinuierliche Verbesserung tatsächlich Früchte tragen. Zum Glück gibt es zahlreiche Tools und Technologien zum Messen der Performance. Sie zeigen beispielsweise, wie viel Zeit Benutzer mit deinem Produkt verbringen, ob ein bestimmter Blogpost den Umsatz gesteigert hat oder wie oft kritische Warnungen protokolliert werden.

Dass du heutzutage fast alles messen kannst, bedeutet nicht, dass du es auch musst (oder sollst). Nimm dir eine Seite der Agile-Entwicklung vor und beginne mit den Grundlagen:

  • Wie viel Zeit lag zwischen der Entwicklung und dem Deployment?
  • Wie oft treten wiederkehrende Bugs oder Fehler auf?
  • Wie lange dauert die Wiederherstellung nach einem Systemausfall?
  • Wie viele Benutzer hat dein Produkt jetzt gerade?
  • Wie viele Benutzer habt ihr diese Woche gewonnen bzw. verloren?

Eine solide Grundlage erleichtert die Erfassung detaillierter Metriken rund um Feature-Nutzung, Customer Journeys und Service Level Agreements (SLAs). Diese Informationen sind hilfreich, wenn du die Roadmap und die Spezifikationen für dein nächstes großes Projekt erstellst.

Alle diese Daten unterstützen dein Team bei der Entscheidungsfindung. Noch wertvoller werden sie aber, wenn ihr sie mit anderen Teams – insbesondere in anderen Abteilungen – teilt. Ein Beispiel: Das Marketingteam fordert attraktive neue Features, die es verkaufen kann. Dein Team kämpft jedoch gerade mit einer hohen Kundenabwanderung, weil das Produkt noch mit einem Berg an technischen Schulden belastet ist. Durch Benutzerdaten für deine Roadmap kannst du die Konsensfindung erleichtern und dir einfacher die Unterstützung von Stakeholdern sichern. Dies gilt auch, wenn sich deine Roadmap weniger auf Features und mehr auf die Fehlerbehebung konzentriert.

Abbildung: Nachrichten-Sprechblasen

Teilen

Die langjährigen Spannungen zwischen Entwicklungs- und Operations-Teams sind überwiegend auf fehlende Gemeinsamkeiten zurückzuführen. Wir sind überzeugt, dass sich dieser Graben überwinden lässt, wenn beide Teams die Verantwortung und den Erfolg miteinander teilen. Entwickler machen sich bei Operations-Team-Mitarbeitern direkt beliebt, wenn sie ihnen die größte Last abnehmen: den Pager. Ein zentraler Punkt von DevOps ist es, alle Personen, die eine Anwendung erstellen, auch an der Auslieferung und am Betrieb zu beteiligen.

Das bedeutet nicht, dass ein Unternehmen Entwickler einstellt und einfach davon ausgeht, dass sie auch als Operator herausragende Arbeit leisten. Vielmehr bedeutet es, in allen Phasen des Anwendungslebenszyklus für eine Zusammenarbeit zwischen Entwickler- und Operations-Mitarbeitern zu sorgen.

Nach dem DevOps-Prinzip arbeitende Teams haben oft eine rotierende Rolle: Ein Entwickler kümmert sich um von den Endbenutzern gemeldete Probleme und arbeitet gleichzeitig an der Behebung von produktionsbedingten Problemen. Diese Person reagiert auf dringende Kundenprobleme, erstellt bei Bedarf Patches und arbeitet sich durch das Backlog an von Kunden gemeldeten Fehlern. Der für den Support zuständige Entwickler lernt auf diese Weise viel über die tatsächliche Nutzung der Anwendung. Dass er für das Operations-Team stets verfügbar ist, stärkt zudem das Vertrauen und den gegenseitigen Respekt.

Natürlich wünschen wir uns, es gäbe einen Zauberstab, mit dem sich alle Teams einfach in leistungsstarke DevOps-Teams verwandeln ließen. Ganz so leicht ist es aber leider nicht. DevOps-Transformationen erfordern die richtige Kombination aus Praktiken, Philosophien und Tools. Wie bereits erwähnt, lohnt es sich durchaus, die Grenzen zwischen den Entwicklungs- und Operations-Teams einzureißen. Mehr Vertrauen, schnellere Software-Releases, zuverlässigere Deployments und ein verbesserter Feedbackkreislauf zwischen Teams und Kunden sind nur einige der Vorteile, von denen Unternehmen profitieren können.

Die Implementierung von DevOps ist keine kleine Aufgabe. Mit dem passenden Framework, den richtigen Tools und angemessenem Einsatz kann ein Unternehmen jedoch eine DevOps-Transformation realisieren und so von erheblichen Vorteilen profitieren.

Weitere Informationen über die in Zusammenarbeit mit Cite Research durchgeführte Umfrage erhältst du unter press@atlassian.com.

Bist du bereit für deinen eigenen Weg zu DevOps?