Ende November war ich mit meinem Kollegen Daniel Bürck auf den DevOps Days Berlin 2019. Bei den DevOps Days handelt es sich um eine internationale Konferenzreihe (schwerpunktmäßig Nordamerika, aber auch Europa, Asien, Afrika, usw…), die von Freiwilligen aus der ganzen Welt organisiert und durchgeführt wird. Aufgrund des sehr internationalen Publikums ist die Konferenzsprache Englisch.
DevOps
Thematisch geht es sowohl um die technischen als auch um die organisatorischen und kulturellen Aspekte der DevOps-Bewegung, die für die Verschmelzung von Dev (Entwicklung) und Ops (Operations, Betrieb) wirbt. Durch das Einreißen der Mauern zwischen Softwareentwicklung und Softwarebetrieb lässt sich eine deutlich höhere Releasekadenz erreichen, da es keine Übergabe oder dedizierte Testphase (wegen TDD und vollständiger Automatisierung aller Teststufen und auch des Deployments selbst) mehr gibt. Damit einher geht somit eine deutlich geringere time-to-market. Fehlerhafte oder gar gescheiterte Deployments werden deutlich seltener, da der gesamte Prozess vollkommen automatisiert ist und durch die hohe Frequenz (mehrfach am Tag und nicht etwa einmal alle drei Monate) kein besonderes Ereignis mehr ist. Und schließlich sind auch schnellere Reaktionszeiten bei Incidents zu erwarten, da immer auch „Entwickler“ beteiligt sind, die tieferes anwendungsspezifisches Wissen haben als ein bloßer Anwendungsbetrieb.
Leadership ohne Authorität
In einem der ersten Beiträge von Daniel Löffelholz (ThoughtWorks) ging es um die Frage der Leadership in DevOps-Teams, die in aller Regel in agile Strukturen eingebettet sind, bei denen es keine Bereichs- und Abteilungsleiter mehr gibt. Daniel hat unter anderem die verschiedenen Typen von Leadern vorgestellt und insbesondere darauf hingewiesen, dass Leadership keine Einbahnstraße ist. Leader erfahren im Umgang mit ihren Peers immer auch Dinge über sich selbst und sollten die Bereitschaft mitbringen, ihr Denken und ihr Handeln bei Bedarf umzustellen und insbesondere kontinuierlich zu verbessern. Dies erfordert natürlich regelmäßige Retrospektive und vor allem Introspektion also die (kritische) Beobachtung von sich selbst und seinem Handeln. Dazu hat man im stressigen Alltag nicht immer die Zeit und so hat es auch eine Weile gebraucht, bis mir die Botschaft von Daniels Beitrag wirklich bewusst wurde.
Hört auf, DevOps Engineers einzustellen!
Stevan Cvetkovic (Endava) hat einen sogenannten „Ignite Talk“ gehalten, ein Vortragsformat das dem „PechaKucha“ sehr ähnlich ist. Es handelt sich um einen Folien-gestützten Vortrag mit insgesamt 20 Folien, wobei jede Folie exakt 15 Sekunden lang gezeigt wird und dann automatisch zur nächsten Folie weiterspringt. In dieser Kürze der Zeit einen fundierten und durchdachten Beitrag zu einem nicht-trivialen Thema oder Problem an sein Publikum zu transportieren, ist wirklich keine leichte Aufgabe. Dennoch sind mir Stevans Ausführungen vielleicht sogar wegen des außergewöhnlichen Formats gut in Erinnerung geblieben.
So ist der Titel „DevOps Engineer“ laut einer Untersuchung von LinkedIn derzeit die am meisten nachgefragte Position bei IT-Recruitern. Mit der gezielten Suche nach sogenannten DevOps Engineers erweist man der DevOps-Bewegung jedoch allzu oft einen Bärendienst. Denn die Vorstellung, neben die Kolleginnen und Kollegen aus Dev (Entwicklung) und Ops (Betrieb) nun die neuen DevOps Engineers zu setzen führt im schlechtesten Fall dazu, dass man zusätzlich zu den beiden bisherigen Silos nun ein weiteres, drittes Silo (DevOps) geschaffen und damit die Abstimmungs- und Koordinationsaufwände noch zusätzlich erhöht hat. Solange ein DevOps Engineer nur als Facilitator für ein Umdenken in der Belegschaft dient, mag dies funktionieren, doch allzu oft wird außer Acht gelassen, dass es darum geht, das Bewusstsein und die Wahrnehmung der bisher getrennt agierenden Organisationseinheiten zu schärfen, einen kulturellen Wandel anzustoßen und eine Verschmelzung herbeizuführen. Die Versuchung, dieses Problem durch das Schaffen von neuen Stellen mit einem coolen, angesagten Titel zu bekämpfen ist groß und erfreut sich offenbar leider bei vielen IT-Managern großer Beliebtheit.
We failed hard at adopting DevOps and continuous deployment so you don’t have to!
Falls Sie meinen eigenen Vortrag verpasst haben sollten, möchte ich an dieser Stelle noch eine kurze Zusammfassung geben.
DevOps und Continuous Integration/Continuous Deployment (CI/CD) sind unaufhaltsame Hype-Themen und werden nach wie vor als Heilsbringer und Lösung für fast alle Probleme angepriesen. In diesem Vortrag beleuchten wir dagegen die andere Seite der Medaille und berichten aus einem großen IT-Projekt, bei dem der Wandel zu einer DevOps-Kultur und die Einführung von Continuous Deployment trotz bester Absichten und hehrer Ziele gründlich daneben gegangen sind.
Die vorab gesteckten Ziele (unabhängige Teams, hohe Releasekadenz, 10 Deployments pro Tag, …) wurden in diesem Fall deutlich verfehlt. Dennoch lassen sich aus dem Scheitern wertvolle Lehren ziehen, was bei DevOps und CI/CD alles schief gehen kann und wie sich die damit verbundenen Probleme und Herausforderungen besser meistern lassen. Die wesentlichen Ursachen liegen nämlich nicht etwa in der Auswahl von Tools, technischem Know-How oder Infrastruktur, sondern in der Organisation, der Kultur und den Prozessen. Dieser Vortrag handelt von der gescheiterten Einführung von DevOps und Continuous Deployment und ist gleichzeitig eine Organisationsanalyse von Konzernen, die sich schwer tun mit der Anpassung an eine digitale Welt.
Fazit
Die freiwillige Umfrage unter den Teilnehmern der Konferenz zeichnet ein vielfältiges und buntes Bild: Interessierte aus unterschiedlichsten Bereichen, Rollen und Ländern haben teilgenommen, die alle eine einzigartige Perspektive und ihre eigenen Erfahrungen mitgebracht und beigetragen haben. Der Austausch mit Menschen, die einen vollkommen anderen Hintergrund oder eine gänzlich andere Herangehensweise haben, war für mich besonders bereichernd. Gerade die Internationalität der DevOps Days trägt viel zu ihrem Charme bei. Ich kann diese Veranstaltungsreihe wärmstens empfehlen und hoffe, dem ein oder anderen unter Ihnen dort einmal zu begegnen.
