Wer die Trends in den Bereichen Agile und Dev(Sec)Ops verfolgt, hört auch immer wieder inspirierende Erfolgsgeschichten mit diesen Modellen. Wie alle wertvollen Dinge ist jedoch auch der Einzug von DevOps in den Kern der Unternehmenswerte nicht immer einfach. In diesem Beitrag beleuchte ich einige wichtige Punkte und häufige Stolperfallen aus der Perspektive des Managements und der Entwickler, bevor Sie sich auf eine Reise begeben, deren Ziel Tausende tägliche Pushes to Production lautet.
Möchten Sie mehr über die drei DevOps-Prinzipien erfahren?
Dann empfehlen wir Ihnen den folgenden Blog-Artikel
«The Three Ways - die Prinzipien auf denen DevOps aufbaut».
DevOps aus Sicht der Führung
«Und für meine nächste Nummer mache ich mit einem Klassiker weiter.»
Man kann es nicht oft genug wiederholen: DevOps ist kein festgelegtes Set aus Tools und Prozessen, die Sie für garantierten Erfolg einfach einsetzen müssen. Es gibt natürlich einige gängige Muster, der Erfolg Ihrer DevOps-Transformation steht und fällt jedoch mit der Einstellung im Unternehmen. Den wertvollsten Beitrag, den die Führungsetage während der DevOps-Transformation leisten kann, besteht darin, sich zurückzunehmen und den Teams zuzutrauen, die richtigen Entscheidungen zu treffen....
Führen, nicht managen
Die technischen Teams stehen häufig hinter der Idee von DevOps. Aber in Wirklichkeit beinhaltet DevOps eine radikale Änderung der Arbeitsweise im Unternehmen. Das muss auch in der Kultur auf der Führungsebene reflektiert werden. In der Studie «2017 State of DevOps Report» [1] werden 5 Charakteristika transformationaler Führung genannt: Vision, inspirierende Kommunikation, intellektuelle Stimulation, unterstützende Führung und persönliche Anerkennung. Gartner prognostiziert zudem, dass bis 2020 «50 % der CIOs, die ihre Fähigkeiten nicht transformiert haben, aus dem Digital-Leadership-Team ausgelagert werden».[2]
Manager müssen Führungskräfte werden, dürfen nicht alle Entscheidungen alleine treffen wollen, sondern müssen ihren Mitarbeitern – den Experten – vertrauen können, dass diese die richtigen Massnahmen finden und ergreifen. Es ist nie einfach, so grosses Vertrauen aufzubauen und eine «Zero-Blame»-Kultur [3] zu schaffen, in der Fehler zugegeben werden können. Wer je in einem grossen, bürokratischen Unternehmen tätig war, weiss, wie enorm schwierig diese Änderung sein kann. Doch dies ist der allerwichtigste Beitrag, den die Führungsetage zur Förderung von DevOps leisten kann.
DevOps ist kein neues Team
Wenn Sie vorhaben, ein neues DevOps-Team zu gründen, dann machen Sie was falsch! DevOps-Einstellungen und -Vorgehensweisen sollten im gesamten Unternehmen umgesetzt werden, um maximale Erfolge zu erzielen. Die Bildung eines neuen Teams verlagert das Problem hingegen nur auf eine neue Gruppe verantwortlicher Personen. Sie sollten in jedem Team Mitarbeiter einsetzen, die DevOps-orientiert sind. So kann das Team die Fähigkeiten erlernen und verbessern, die es braucht, um unabhängig und leistungsstark zu werden. Bedenken Sie, dass «es keine DevOps-Helden gibt» [4] und dass Ihre DevOps-Spezialisten sich zum Ziel setzen sollten, Wissen zu teilen und ein Team zu fördern, das mit Herausforderungen umgeht, statt sich alles selbst aufzuschultern.
Akzeptieren Sie keine Auftraggeber, die nicht Ihre Werte teilen
Natürlich müssen wir alle von etwas leben. Wenn Sie jedoch heute eine neue DevOps- oder Agile-Transformation ankündigen und morgen ein klassisches Wasserfallprojekt mit langen Feedback-Schleifen vorstellen, verschafft Ihnen das bei Ihren Teams weder Vertrauen noch Respekt. Steve Parks von Convivio brachte es 2016 bei seiner Drupalcon-Präsentation [5] auf den Punkt, als er gefragt wurde, wie er mit Kunden umgeht, die nicht auf agile Weise mit ihm zusammenarbeiten möchten: «Ich suche mir einen anderen Kunden!» Mit zunehmender Erfahrung in den DevOps-Flows können Sie möglicherweise Unternehmen in Ihre Methodologie und Kadenz integrieren, doch bei der Einführung von DevOps sollten Sie sich Kunden suchen, die Ihre Werte und Praktiken reflektieren und verstärken.
Interne Verbesserungen schaffen indirekten Wert
Es ist bekannt, dass die Transformation zu DevOps erst mal zu einer scheinbaren Verlangsamung führt. Das liegt häufig daran, dass Ihre Teams zu Beginn der DevOps-Reise die echten Knackpunkte im Workflow und die verbesserungsbedürftigen Tools und Prozesse zum Vorschein bringen [6]. Dieser «Berg technischer Schulden» [7] muss zurückgezahlt werden, damit das Team zu Höchstleistung auflaufen kann. Die Unterstützung des Managements ist dabei extrem wichtig.
Versuchen Sie, sich auch dann auf das Ganze zu konzentrieren, selbst wenn die Teams heute noch nicht direkt Mehrwert generieren. Ein Beispiel: Zeit, die heute in den Aufbau der richtigen Monitoring- und Alarmsysteme investiert wird, kann zukünftig Hunderte von Mannstunden einsparen und vielleicht sogar den Burnout von Entwicklern verhindern. Die Führung und die Teams müssen das Kaizen-Prinzip [8] verinnerlichen und Tools sowie Prozesse laufend verbessern, um Probleme schlank und angemessen zu lösen. Das sorgt nicht nur für eine angenehmere Arbeitsumgebung im Alltag, Ihr Team kann selber Roadmaps definieren, seine Problemlösungskompetenzen erweitern und das Gefühl erleben, einen echten Beitrag zum Unternehmen zu leisten.
DevOps aus Sicht der Entwickler
Für einen Entwickler bedeutet die DevOps-Transformation den Aufbau neuer Tools und Prozesse, das Zerbrechen von Silos, engere Zusammenarbeit mit Menschen aus anderen Disziplinen und eigenverantwortliches Arbeiten. Wenn Sie das in Sie gesetzte Vertrauen erwidern, laufend Ihre Arbeitsumgebung verbessern und die Feedback-Schleife zwischen Ihnen und dem Kunden verkürzen, können Sie den Flow erreichen und aufrechterhalten, mit dem Qualität rasch produziert werden kann.
Gewöhnen Sie sich an Interaktion mit dem Kunden
«Unser Ziel ist es, dass alle Unternehmensmetriken umsetzbar werden. Diese Top-Metriken sollen Informationen geben, wie unser Produkt geändert werden sollte, und sich für Experimente sowie A/B-Tests eignen.» [9]
Die Verkürzung der Wertschöpfungskette bedeutet, dass Sie wirklich verstehen müssen, was der Kunde wünscht, und wie sein Feedback in umsetzbare Arbeit verwandelt wird. Sie müssen sich also an die Kommunikation mit dem Kunden (egal ob extern oder intern) gewöhnen. Ich habe Teams von hervorragenden Programmierern an dieser Hürde scheitern sehen, da sie ihre Arbeit nicht mit dem Kunden besprechen wollten, das Feedback ablehnten oder einfach nicht zuhören konnten. Diese Einstellung muss im Kern ausgemerzt werden. Das Hauptziel jedes Teams ist es, dem Kunden einen Mehrwert zu bieten. Ihr Code kann noch so schön und sauber und gut getestet sein, wenn er nicht das macht, was der Kunde möchte, nützt er höchstens Ihrem Ego.
Gestalten Sie Software-Releases langweilig
Wer je seinem Kunden eine Applikation im Rahmen eines traditionellen Entwicklungsprozesses geliefert hat, kennt die Angst vor dem nächsten Release. Wie lange braucht das Change Board für die Genehmigung? Sind alle Entwicklungsschritte erfolgreich? Welche Entwicklungsschritte sind eigentlich nötig? Hat das Ops-Team alles Nötige für ein erfolgreiches Deployment vorbereitet? Hat das Development-Team dem Ops-Team alle nötigen Änderungen erfolgreich mitgeteilt? Wie viel Zeit müssen wir einplanen, falls etwas schief geht? Wie viel müssen wir für Pizza und Bier ausgeben, damit das Team in einer Nachtschicht alles hinbiegt?
Diese Art von Releases führt in jedem Unternehmen zu gefährlichen Situationen: Der Ruf des Kunden steht genauso auf dem Spiel wie die Beziehungen zwischen den Teams, weil jeder dem anderen die Schuld in die Schuhe schiebt. Ihre Mitarbeiter zweifeln an den eigenen Fähigkeiten, und letztlich entsteht eine Situation, in der weder der Kunde noch die Entwickler wirklich möchten, dass der Code live geht. Das ist ein Teufelskreis, da es Ziel des Softwareentwicklungsprozesses ist, Mehrwert für die Stakeholder zu schaffen. Und das können Sie nur mit einem Release. Sie sollten sich also darauf konzentrieren, diesen Prozess möglichst langweilig, automatisiert und unaufgeregt zu gestalten.
Qualität geht schneller live
Ein paar Erkenntnisse aus dem Bericht «2017 State of DevOps» von Puppet:
“In 2017 (...) hatten High-Performer:
- 46 Mal häufigere Code-Implementierungen
- 440 Mal kürzere Lead-Zeiten vom Commit bis zur Implementierung
- 96 Mal schnellere durchschnittliche Wiederherstellung nach Ausfall
- eine 5 Mal geringere Fehlerrate bei Änderungen (Änderungen scheitern 5 Mal weniger häufig)“
All das ist nur möglich, wenn Sie dafür sorgen, dass der Code schnell und sicher live geht. Dafür benötigen wir Implementierungspraktiken, die eine unkomplizierte Implementierung, und bei Problemen auch Rollbacks, unterstützen. In der Praxis bedeutet das:
- Unveränderliche Infrastruktur/atomare Änderungen – Nach der Implementierung sind Änderungen ausschliesslich im Rahmen eines weiteren Implementierungszyklus möglich. So werden Konfigurationsabweichungen und manuelle Veränderungen verhindert, die ansonsten vielleicht vergessen oder beim nächsten Push überschrieben werden.
- Infrastruktur als Code – Änderungen an Ihren Umgebungen sollten über ein automatisiertes System erfolgen und via Versionskontrolle erfasst werden.
- Gründlicher QA-Prozess – Das Vier-Augen-Prinzip [10] in Kombination mit automatisierten CI Pipelines kann die Qualität Ihrer Anwendungen erhöhen und bei Releases als letzte Instanz eingesetzt werden.
- Regelmässig für Fehlschläge üben – Sorgen Sie dafür, dass ein einfacher Rollback Ihres Codes möglich ist, dass neue Fixes problemlos gepusht werden können und dass die Rückkehr zu einem bekannten guten Zustand unproblematisch ist. Gibt es klare, einfache und (bestenfalls) automatisierte Wege zurück zu einem funktionsfähigen Zustand, wird das Risiko, das mit schnellen Pushes to Production einhergeht, abgefedert.
Live testen (mit guten Metriken)
Bevor Sie vollständig in einen DevOps-Workflow eintauchen, brauchen Sie unbedingt gute Instrumente, Protokollierung und Metriken für Ihre Anwendung. Während Sie den Weg zur Markteinführung verkürzen, müssen Sie sicherstellten, dass alle Fehler sichtbar werden und dass das Team über die Zeit verfügt, sie zu beheben. Das ist in einigen Unternehmen, besonders Web-Agenturen, wahrscheinlich schwierig. Im traditionellen Modell wird eine Funktion oder ein Projekt nach der Übergabe an den Kunden nicht mehr betrachtet, das Team schaut nach vorne.
Das ist leichtsinnig, da es praktisch unmöglich ist, die Anwendung vor der Produktion mit Sicherheit auszutesten. Wilde Requests aus den Tiefen des Netzes und die Anwendung durch echte Nutzer führen garantiert zu unvorhergesehenen Fehlern (wenn Sie das nicht glauben, erinnern Sie sich, wie viele kleine und grosse Fehler Sie auf den Webseiten der grössten und finanzstärksten Tech-Unternehmen schon gesehen haben). Natürlich bleiben Modul- und Integrationstests wichtig, doch sollten Sie über eine zusätzliche Monitoring-Ebene nachdenken, um sicherzustellen, dass Ihre Anwendungen in der freien Natur überleben [11].
Allerdings ist dabei auch zu beachten, dass niemand gerne um 2 Uhr morgens aus dem Bett geklingelt wird. Sie freuen sich wohl kaum darüber, wenn Ihr Monitoringsystem Sie weckt, um Sie über eine Banalität zu informieren, oder? Bauen Sie deshalb in Ihrem Monitoringsystem nützliche, umsetzbare Alarme ein. Diesen Bedarf können inzwischen zahllose Unternehmen erfüllen, die Kurzzeitspeicherung von Events und Alarmen [12] mit hoher Kardinalität bieten oder mittels ML die falsch positiven Werte ausfiltern [13].
Zeit in Verbesserungen investieren
Wer wie Sie an vorderster Front in der Entwicklung arbeitet, sieht und erlebt die schmerzlichen Schwachstellen im täglichen Workflow hautnah. Sie sollten sicherstellen, dass Sie genug Zeit einplanen, um diese Probleme anzugehen, egal ob es sich um technische Altlasten, kleine Fixes oder Greenfield-Projekte handelt. Fällt Ihnen etwas auf, dass Sie – und alle anderen – beeinträchtigt, beheben Sie es! Finden Sie sich nicht mit «funktioniert doch» oder gar «gut genug» ab. Drängen Sie darauf, Ihre Prozesse so automatisiert, einfach und idiotensicher wie möglich zu gestalten, weil am Ende jeder davon profitiert.
Fazit
Natürlich kann ich nicht alle Fragen und Sonderfälle, die beim Übergang zu einem DevOps-Modell auftauchen können, in einem einzigen Artikel beleuchten. Doch ich hoffe, die erwähnten, generellen Punkte haben verdeutlicht, dass DevOps mehr als bloss ein Satz von anwendbaren Regeln ist. Sie müssen bereit sein, tief in Ihre Tools, Methoden und Kultur einzutauchen und sich die Zeit für Verbesserungen und Feinabstimmungen zu nehmen, um ein erfolgreiches, leistungsstarkes Unternehmen zu werden. Der Vorteil der DevOps-Methode ist erwiesen, der Weg zur richtigen Implementierung ist jedoch schwierig, zeitaufwendig und anstrengend für das gesamte Unternehmen.
Sind Sie auf der Suche nach einem Ansatz für die effektivere und effizientere Zusammenarbeit zwischen Entwicklung und Betrieb? Wir unterstützen Sie mit unserem DevOps Readiness Assessment gerne dabei. Erhalten Sie hier weitere Informationen.
[1] https://puppet.com/system/files/2017-10/2017-state-of-DevOps-report-puppet-dora.pdf
[2] https://www.gartner.com/binaries/content/assets/events/keywords/infrastructure-operations-management/iome5/gartner-predicts-for-it-infrastructure-and-operations.pdf
[3] https://codeascraft.com/2012/05/22/blameless-postmortems/
[4] https://www.nwcadence.com/blog/devops-culture-not-team
[5] https://www.youtube.com/watch?v=_FsZoez6U_M&index=45&list=PLpeDXSh4nHjQAM63-KW_8x_qEB-dio1tA&t=0s
[6] https://puppet.com/system/files/2017-10/2017-state-of-devops-report-puppet-dora.pdf page 28
[7] http://samuelmullen.com/articles/the-high-cost-of-technical-debt/
[8] https://en.wikipedia.org/wiki/Kaizen
[9] DevOps Handbook
[10] https://blog.titansoft.com.sg/2015/07/08/two-man-four-eyes-principle/
[11] I would strongly recommend this article for more insight in to this https://opensource.com/article/17/8/testing-production
[12] https://honeycomb.io
[13] https://unomaly.com
