Schließen

DevOps: Schluss mit den Grenzen zwischen Entwicklung und Operations

Was ist DevOps?

DevOps als Wettbewerbsvorteil

"Dank DevOps können wir sehr häufig Releases veröffentlichen, wodurch wir im Wettbewerb einen Vorteil haben. Wir können nun täglich statt nur alle sechs Monate neue Produkte auf den Markt bringen und unseren Kunden Fehlerbehebungen innerhalb weniger Stunden zur Verfügung stellen."

– Hamesh Chawla, VP of Engineering bei Zephyr

DevOps bezeichnet eine Reihe von Praktiken zur Automatisierung der Prozesse zwischen Softwareentwicklern und IT-Teams, durch die Software schneller und zuverlässiger entwickelt, getestet und freigegeben werden kann. Grundlage für das DevOps-Konzept ist eine Unternehmenskultur der Zusammenarbeit zwischen Teams, die früher relativ isoliert voneinander gearbeitet haben. Zu den versprochenen Vorteilen zählen eine Vertrauensstärkung, schnellere Software-Releases, eine raschere Behebung kritischer Fehler und ein verbessertes Management ungeplanter Aufgaben.

Bei Atlassian ist "DevOps" das zweitbekannteste Kofferwort (Kunstwort aus mindestens zwei Wortsegmenten) nach "Brangelina" (Brad Pitt und Angelina Jolie). Es bringt zum Ausdruck, dass DevOps die besten Seiten von Softwareentwicklung (Development, Dev) und IT-Operations (Ops) in sich vereint. Wie bei unserem Humor sind auch hier einige Erklärungen nötig. 

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, 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.

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. Führend bei diesem Austausch waren unter anderem Patrick Debois, 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 magischen Effekte es auf Teams haben kann. Das möchtest du jetzt selbst erleben.

Hier zunächst die schlechte Nachricht: DevOps ist 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.

Dank "Infrastruktur als Code" können wir an zehnmal so vielen Builds arbeiten, ohne in unserem Team eine weitere Person zu benötigen. – Michael Knight, Build Engineer bei Atlassian

Von welchen Vorteilen kannst du profitieren?

Zusammenarbeit und Vertrauen

Die Unternehmenskultur ist bei DevOps der wichtigste Erfolgsfaktor. Eine auf gemeinsamer Verantwortung, Transparenz und schnellem Feedback beruhende Unternehmenskultur ist die Grundlage jedes erfolgreichen DevOps-Teams.

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.

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 Reaktionszeit bei Problemen 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 Automatisierung sowie standardisierte Tools und Prozesse können Teams ihre Produktivität steigern und problemloser zu häufigeren Releases gelangen.

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 stark beschleunigte Problemlösung.

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

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 Dev- und Ops-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.

Unternehmenskultur

Wenn wir die DevOps-Unternehmenskultur in einem Wort zusammenfassen müssten, wäre dies "Zusammenarbeit". Bei zwei Wörtern würden wir "funktionsübergreifende Zusammenarbeit" wählen. (Darin könnte man auch drei Wörter sehen.)

Alle Tools und Automatisierungsmaßnahmen der Welt sind wertlos, wenn bei den Entwickler- und IT/Ops-Teams kein echtes Interesse an einer Zusammenarbeit besteht. DevOps behebt nämlich keine Probleme bei Tools. Vielmehr löst es menschliche Probleme. Vor diesem Hintergrund ist es unwahrscheinlich, dass du dich eines Tages umsiehst und feststellst, dass die Teams in deinem Unternehmen von ganz allein eine DevOps-Kultur angenommen haben. Du kannst diese Kultur jedoch durch einfache Maßnahmen fördern.

DevOps ähnelt Agile, allerdings wird bei DevOps auch die Operations-Abteilung berücksichtigt. 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. Wir bei Atlassian binden sogar das Marketing in unsere Produktteams ein.

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. Entwicklerteams 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 einbeziehen. Mit dieser organischen Agile-Arbeitsweise bleibt ihr bei Projekten, Ideen und Schwierigkeiten der anderen immer auf dem neuesten Stand. Es zahlt sich aus, anderen Teams zuzuhören und Fachwissen auszutauschen: Das Release-Management und die Fehlerbehebung in Notfällen werden so deutlich effizienter.

Stichwort "Notfälle": Diese sind ein effektiver Test für die DevOps-Unternehmenskultur. Bewältigen Entwickler-, Operations- und Kundensupportteams Probleme gemeinsam und im Team? Gehen alle zunächst davon aus, dass ihre Teamkollegen mit den ihnen zu diesem Zeitpunkt zur Verfügung stehenden Informationen und Ressourcen die bestmögliche Entscheidung getroffen haben? Steht bei der Nachbereitung des Zwischenfalls die Korrektur von Prozessen im Mittelpunkt oder wird in erster Linie ein Schuldiger gesucht? Wenn du alle diese Fragen mit "ja" beantworten kannst, ist dies ein guter Hinweis darauf, dass dein Team die DevOps-Unternehmenskultur bereits verinnerlicht hat.

Bei den erfolgreichsten Unternehmen wird die DevOps-Kultur in allen Abteilungen und auf allen Hierarchieebenen gepflegt. Die Kommunikation erfolgt dort offen und regelmäßig. Es wird auf die Abstimmung der Ziele aller Beteiligten geachtet und bei Bedarf werden Anpassungen vorgenommen. 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.

Automatisierung

Durch eine Investition in Automatisierung wird manuelle Routinearbeit eliminiert, 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. Die Einrichtung von Continuous Delivery ist natürlich eine Herausforderung, aber es lohnt sich.

Warum? Computer führen Tests rigoroser und zuverlässiger durch als Menschen. Mit diesen Tests werden Bugs und Sicherheitslücken schneller erkannt, sodass die Entwickler sie leichter beheben können. Außerdem wird dank der automatisierten Deployments das IT/Ops-Team bei Server-"Abweichungen" von 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.

Es ist wahr, dass Systeme sich ständig verändern. Wir können jedoch eine scheinbare Unveränderlichkeit erreichen, indem wir Code für das Provisioning nutzen. So beansprucht das erneute Provisioning eines beschädigten Servers weniger Zeit als eine Fehlerkorrektur – und ist außerdem zuverlässiger. Risiken werden ebenfalls reduziert. Das Entwickler- und das Operations-Team können über den Provisioning-Code neue Sprachen oder Technologien implementieren und die Updates miteinander teilen. Kompatibilitätsprobleme werden sofort sichtbar, statt sich erst mitten im Release zu zeigen.

"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 DevOps-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.

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, flexible Arbeitsweisen. Noch wichtiger für DevOps sind das Konzept der kontinuierlichen Verbesserung und die positive Einstellung gegenüber Fehlern.

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.

Wir fordern unsere Teams mit großen, haarigen, gewagten Zielen heraus und sorgen dafür, dass sie die nötige Eigenständigkeit und die passenden Ressourcen zum Erreichen dieser Ziele haben. Wir stellen intelligente, ehrgeizige Mitarbeiter ein und gehen davon aus, dass sie gelegentlich Fehler machen.

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. (Ein gutes Beispiel dafür ist Chaos Monkey von Netflix.) Bei der Projektnachbereitung 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.

DevOps hat sich weiterentwickelt, sodass die Entwickle jetzt für mehr Vorgänge zuständig sind. Nach diesem Prinzip funktioniert Chef. Wir können die Verantwortung nicht mehr abwälzen. Auf dem Weg zur Auslieferung an die Kunden müssen sich unsere Entwickler selbst um die Qualitätssicherung, die Dokumentation und ihre eigenen Tests kümmern. – Julian Dunn, Product Manager bei Chef

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 detaillierterer 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.

DevOps ist nicht die Sache einer Einzelperson. Alle sind gemeinsam gefragt. – Christophe Capel, Principal Product Manager, Jira Service Desk

Teilen

Die langjährigen Spannungen zwischen Entwickler- 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 Lieferung und Ausführung 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.

Wer gemeinsam große Hürden überwindet, genießt den Erfolg umso mehr. Wenn das Entwicklerteam dem Operations-Team am Release-Tag Kuchen mitbringt, ist das der schlagende Beweis dafür, dass sich die DevOps-Kultur im Unternehmen etabliert hat.

Positives Feedback von Kollegen kann so motivierend sein wie ein Gehaltsscheck oder hohe Karriereziele. Öffentliche Anerkennung für einen Teamkollegen, der einen fiesen Bug noch vor dem Release erkannt hat, ist eine großartige Geste. Nutze also das freie Budget deiner Abteilung sinnvoll und verwende es für Mitarbeiter-Kudos.

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

Beschreite deinen Weg