CALMS-Framework

Herausforderungen und sogar Notfälle sind ein effektiver Test für die DevOps-Kultur. Lösen Entwickler-, Operations- und Kundensupportteams Probleme gemeinsam und als Team? Steht bei der Post-Mortem-Analyse von Vorfällen die Verbesserung der Ergebnisse im Mittelpunkt, nicht die Suche nach einem Schuldigen? Wenn du diese Fragen mit "ja" beantworten kannst, ist dies ein guter Hinweis darauf, dass dein Team bereits über eine DevOps-Kultur verfügt.

Bei den erfolgreichsten Unternehmen wird die DevOps-Kultur in allen Abteilungen und auf allen Hierarchieebenen gepflegt. In einem so breiten Maßstab ist der Begriff "DevOps" allerdings oft zu eng gefasst und wird nicht mehr benötigt. In solchen Unternehmen wird offen und regelmäßig miteinander kommuniziert. Alle sind der Ansicht, dass das Produktmanagement ebenso sehr für die Kundenzufriedenheit verantwortlich ist wie das Entwicklerteam. Sie wissen, dass DevOps nicht die Aufgabe eines einzigen Teams sein kann, sondern dass hierbei alle gefordert sind.

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, die oft durch eine cloudbasierte Infrastruktur erleichtert werden. Danach werden Builds zu Paketen zusammengestellt und über automatisierte Deployments an mehrere Umgebungen freigegeben.

Und warum? Weil Computer Tests rigoroser und zuverlässiger durchführen als Menschen. Mit diesen Tests werden Bugs und Sicherheitslücken schneller erkannt. Außerdem wird dank der automatisierten Deployments das IT/Ops-Team bei Abweichungen zwischen Umgebungen gewarnt, damit es beim Release weniger Ü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.

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 Akzeptanz von Fehlern. Beides begünstigt eine verstärkte Experimentierfreude.

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. Und warum? Weil kontinuierliche Verbesserung und Fehler Hand in Hand gehen.

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 interessanten Daten unterstützen dein Team bei der Entscheidungsfindung. Noch wertvoller werden sie aber, wenn ihr sie mit anderen Teams teilt, insbesondere solchen aus anderen Abteilungen. 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 zu hohe technische Schulden aufweist. 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.

Natürlich wünschen wir uns, alle Teams einfach durch Wedeln eines Zauberstabs in leistungsstarke DevOps-Teams verwandeln zu können. So leicht geht das aber nicht, weil für DevOps-Transformationen die richtige Kombination aus Praktiken, kulturellen Philosophien und Tools erforderlich ist. Wie bereits erwähnt, lohnt es sich durchaus, die Trennlinien zwischen den Entwicklungs- und Operations-Teams aufzubrechen. Mehr Vertrauen, schnellere Software-Releases, zuverlässigere Deployments und ein verbesserter Feedbackkreislauf zwischen Teams und Kunden sind nur einige der potenziellen Vorteile.

Die Implementierung von DevOps ist kein leichtes Unterfangen. Mit der passenden Einstellung, mit Engagement und den richtigen Tools kann ein Unternehmen jedoch eine DevOps-Transformation realisieren und damit von erheblichen Vorteilen profitieren.

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 können sich bei Operations-Teammitgliedern direkt beliebt machen, wenn sie ihnen die größte Last abnehmen, nämlich den Pager (der heutzutage eher Symbolcharakter hat). Ein zentraler Punkt von DevOps ist es, alle Personen, die eine Anwendung erstellen, auch an der Auslieferung und am Betrieb zu beteiligen.

Aus dieser Idee entstand das "You-built-it-you-run-it-Konzept", das einen praktischen Ansatz für Teams fördert. Dieser heißt aber nicht, dass du Entwickler einstellen und von ihnen erwarten kannst, dass sie auch hervorragende Operator sind. Er bedeutet, dass Entwickler und Operator während des gesamten Anwendungslebenszyklus zusammenarbeiten. Berichte haben außerdem gezeigt, dass von Fachkollegen begutachtete Codes und Produkte die einzige Form der Überprüfung sind, die zu einer besseren Lieferung und Leistung führt. Tatsächlich waren externe Reviewer kaum effektiver, als wenn man überhaupt keine Überprüfung durchgeführt hätte.

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.

Atlassian hat Open DevOps für Teams erstellt, die genau die Toolchain zusammenstellen möchten, die sie brauchen. Dank Integrationen mit führenden Anbietern und Marketplace-Apps auch mit den Tools, die sie lieben. Jetzt testen.