zurück zum Artikel

DevOps hat sich in 10 Jahren von einer Grassroots-IT-Protestbewegung zur etablierten Enterprise-Strategie entwickelt. Unser Autor Schlomo Schapiro war von Anfang an dabei. Ein Rückblick aus persönlicher Perspektive und ein Ausblick in die Zukunft.

Getreu dem Motto, ein Thema ist dann ein Thema, wenn es eine Konferenz dazu gibt, zählt die Konferenzreihe DevOpsDays [1], die 2009 in Gent ihren Anfang nahm [2], als wichtiges Barometer zum Thema DevOps. Der Begriff, der vor 2009 nicht anzutreffen war, hat sich seitdem zum Goldstandard für den Umgang mit betrieblichen Herausforderungen in der IT-Branche gemausert. Patrick Debois, der die Konferenzreihe damals begründete, gilt daher als einer der Urväter der DevOps-Bewegung.

Die DevOpsDays-Konferenz hat sich von einem kleinen Treffen von Enthusiasten zu einem weltweiten Community-getriebenen Konferenz-Franchise entwickelt, das immer noch Akzente setzt. Während viele kommerzielle Konferenzen den DevOps-Begriff für sich übernommen haben und damit die vielen "DevOps-Tools" befeuern, unterscheiden sich die DevOpsDays-Konferenzen davon wohltuend und legen den Fokus auf die zwischenmenschlichen Seiten der Thematik. Die rasante weltweite Expansion der Konferenz – neben vielen anderen ähnlich benannten Veranstaltungen – unterstreicht nur die Relevanz des Themas. 2019 gibt es insgesamt 80 Events – fast jede Woche finden mehrere DevOpsDays-Konferenzen irgendwo auf der Welt statt.

Was war vor DevOps?

Erfreulicherweise finden sich heute, insbesondere bei jüngeren Kollegen, zunehmend mehr Leute, die die Zeit vor DevOps gar nicht mehr bewusst erlebt haben: Eine strikte Trennung des IT-Personals nach Aufgabenbereichen und damit einhergehend viele Übergabepunkte zwischen Teams oder Abteilungen: Produktmanager, Business-Analysten, Architekten, Entwickler, Tester, Release-Manager, Administratoren und Betriebsführer mussten sich abstimmen, um ein Stückchen Software zu planen, zu entwickeln, zu testen, in Betrieb zu nehmen, zu betreiben und regelmäßig zu warten.

Dabei wurde sehr viel Papier – oder Wiki-Seiten – vollgeschrieben, um die einzelnen Übergaben abzuwickeln und zu dokumentieren. Die viel zitierte Mauer zwischen Development (Dev) und Operations (Ops) bestand wirklich und war gelebte Realität. Heute lässt sich diese Arbeitsweise nur noch in wenigen Branchen live erleben, es sind vor allem streng regulierte Branchen, die erst jetzt langsam ihre Arbeitsprozesse reformieren.

Was ist eigentlich DevOps?

Die Frage nach der DevOps-Definition hat sich über die Jahre natürlich verändert. Am Anfang stand die Anwendung agiler Prinzipien – wie sie das Agile Manifesto schon 2001 definiert hat – sowohl in der Softwareentwicklung, im Projektmanagement als auch im Betrieb im Vordergrund. "Bridging the gap between projects and operations by using agile techniques both in development, project management and system administration", erklärte Debois DevOps 2010 auf den ersten DevOpsDays in Hamburg, die der Autor besuchte und für heise Developer beschrieb [3]. "DevOps" ist somit der Zusammenschluss aus Dev und Ops. Die Automation von Betriebsaufgaben als Infrastructure as Code war der Weg, um Arbeitsweisen und Herangehensweisen aus der Dev in die Ops zu bringen und um der damals allgegenwärtigen Handarbeit entgegenzutreten. Die Vortragsthemen von 2009 [4] über Kanban im Betrieb, User Stories für nichtfachliche Anforderungen, Automatisierungswerkzeuge wie Puppet oder DevOps CI/CD Pipelines [5] finden sich auch heute noch in ähnlicher Form auf jeder DevOps-Konferenz.

Der Autor war damals für ImmobilienScout24 (IS24) tätig, dort fielen die Ideen auf fruchtbaren Boden und bildeten den Grundstock für die Neuentwicklung der Betriebsautomation von IS24 [6] im Rechenzentrum.

Anfang 2011 waren die Grundsätze schon entschieden, der Autor erklärte damals DevOps auf dem 1. Berliner DevOps Meetup [7] mit diesen zwei Bildern:

Während früher Dev und Ops getrennt arbeiteten, dieselben Probleme wie das Deployment in Entwicklung und Produktion unterschiedlich lösten und sich über Wiki und E-Mail abstimmten, arbeiten in der neuen Welt alle gemeinsam an der Software, die dann gleichermaßen überall deployt wird. Die Abstimmung über Wikis und E-Mails entfiel zugunsten einer technischen Abstimmung in Form von installierbarer Software: RPM-Pakete für Linux. Statt Unstimmigkeiten und Missverständnissen konnte jetzt jeder selbst die Software testen und verbessern, bis es überall perfekt lief.

Die frühen Jahre von DevOps – alles automatisieren

Über die Jahre hat sich die DevOps-Definition weiter entwickelt. Anhand der regelmäßigen Vorträge auf diversen Konferenzen lässt sich das anschaulich nachvollziehen:

2011/12 ging es in "Practical DevOps [8]" und "DevOps: Neue Arbeitsweise und Selbstverständnis in der IT [9]" um die Erkenntnis, dass es nicht um die konkreten Werkzeuge und Softwaretools, sondern um die beteiligten Menschen geht, getreu dem Motto "The Tool is You".

2013 war das Rechenzentrum-Deployment-Tool yadt von ImmobilienScout24 ein Open-Source-Projekt, das durch seine andersartige Denkweise (ohne Puppet, Chef und CFEngine, die damaligen Platzhirsche im Automatisierungsmarkt) Aufsehen erregte.

2014/15 ging es in "DevOps Risk Mitigation – Test Driven Infrastructure [10]" (Video) darum, wie sich die Risiken der neu gewonnen Freiheiten wieder einfangen lassen. Wenn alles automatisiert ist und jeder an der Automatisierung mitarbeiten kann, muss die Qualität der Software durch automatisierte Tests und einen testgetrieben Entwicklungsansatz sichergestellt werden. In dieser Zeit wurden bei IS24 sehr fortschrittliche Themen wie die ESX-Server-Installation oder die Schlüsselrotation für DKIM-Mailserver testgetrieben automatisiert [11], woran sich damals so gut wie niemand herangetraut hatte.

2015/2016 war klar, dass mit der fortschreitenden Automatisierung der Eigenbau im Rechenzentrum nicht mehr wirtschaftlich ist und sich daher die Migration auf öffentliche Cloud-Plattformen ("Hybrid Cloud – A Cloud Migration Strategy [12]") lohnt, um an dort stattfindenden Innovationen zu partizipieren. DevOps war hier kein explizites Thema mehr. Stattdessen war es die Voraussetzung, um die Cloud-Migration überhaupt erfolgreich durchzuführen. Die jahrelange Professionalisierung im Rechenzentrum und der damit einhergehende Aufbau von Entwicklungsfähigkeiten in der Produktionsabteilung erlaubte bei IS24 in relativ kurzer Zeit die Entwicklung einer Self-Service-Cloud-Plattform auf Basis von AWS und vielen Open-Source-Tools. Im Rechenzentrum hatten die Entwickler bereits gelernt, für ihre Software selbst verantwortlich zu sein, sodass der Übergang zu AWS die natürliche Weiterentwicklung der Arbeitsweise darstellte.

DevOps in der Neuzeit – selbstverständlich

2016/2017 war der Autor bei Zalando tätig und DevOps war so selbstverständlich, dass niemand darüber sprach. Die Frage war jetzt eher, wie man DevOps-Gedanken jenseits der klassischen IT-Bereiche als Grundlage für eine neue Herangehensweise nutzen kann. "DevOps für Jedermann [13]" und " A Workplace Strategy for the Digital Age [14]" zeugen vom Fokuswechsel und der Selbstverständlichkeit von DevOps. Der Vortrag zeichnet einen Weg von DevOps in der IT zu einem neuen Denkansatz für den Umgang mit IT im Unternehmen. Dabei entwickeln sich Mitarbeiter von IT-Konsumenten zu beteiligten Nutzern, die den Computer als Werkzeug für sich entdecken können. Die interne IT stellt nicht nur gute Services zur Verfügung, sondern fokussiert sich auf die Produktivität und Zufriedenheit aller Mitarbeiter.

2018 – jetzt ist der Autor bei der Deutschen Bahn/DB Systel – geht es nicht mehr um die Frage, ob man DevOps macht, sondern eher darum, wann denn eine DevOps erfolgreich "fertig" sei. Seit 2016 migriert die Deutsche Bahn die Rechenzentren in die Cloud [15] und die DB Systel schafft mit ihrer agilen Transformation die klassischen Führungsrollen ab [16]. Hier spielt DevOps eine zentrale Rolle und ist mit Schlüssel zum Erfolg. "DevOps, Continuous Delivery & Cloud – Three Drivers of Enterprise Agility [17]" (AWS Summit Berlin 2018) zeigt, dass sich diese Themen gegenseitig bestärken und ein erfolgreiches Unternehmen sie alle angehen muss, um wirklich erfolgreich zu sein.

Die Definition von DevOps hat sich jetzt spürbar gewandelt: Statt wolkigen Formulierungen rund um die agilen Prinzipien und eine tolle Zusammenarbeit auf Augenhöhe geht es jetzt um harte und messbare Zahlen, die den Fortschritt belegen. Die "Fünf Grundsätze, mit denen sich der Erfolg von DevOps messen lässt" (iX 12/2018 S. 104 [18]) sind eher konkret formuliert und lassen sich genau messen (Quelle: https://bit.ly/5pdops [19]):

• Jeder Mensch benutzt für dieselbe Tätigkeit dasselbe Werkzeug.
• Kodifiziertes Wissen – alle tragen ihren Teil zu einer gemeinsamen Automation bei.
• Fehler machen ist erlaubt – für Dev und Ops gleichermaßen.
• Menschliche Schnittstellen werden durch automatisierte Entscheidungen und Prozesse ersetzt.
• Alle Beteiligten haben gegenüber den von ihnen genutzten Systemen die gleichen Rechte und Berechtigungen.

Die grundlegende Erkenntnis ist dabei, dass DevOps sich als Ergebnis aller Bemühungen einstellt und sich diese fünf Prinzipien nutzen lassen, um den Weg dahin transparent zu machen.

Heute liegt der Fokus vor allem darauf, wie das Unternehmen mit der allgegenwärtigen DevOps-Arbeitsweise zurechtkommt und wie sich alte Prozesse neu gestalten lassen. Während sich die Arbeitsweise verändert, bleiben die grundlegenden Anforderungen und Rahmenbedingungen in einem Unternehmen unverändert: Die Risiken für das Unternehmen müssen so gut, wie es geht, gemanagt und reduziert werden, die vollständige Nachvollziehbarkeit von Änderungen – die früher durch die manuellen Prozesse abgebildet wurde – ist weiterhin essenziell und die Dokumentationspflichten sind unverändert. Mit DevOps kommen jedoch neue Lösungsansätze ins Spiel: Governance und Compliance sind heute ein Automationsproblem, das sich im Sinne von Infrastructure as Code lösen lässt.

Schon 2009 genannte Mittel wie CI/CD Pipelines sind daher auch heute noch die Grundlage für die Lösungen. Im Rahmen der Pipelines werden zunehmend mehr Aufgaben mitgelöst, sodass am Ende eine "Compliant by Default [20]"-Arbeitsumgebung (Continuous Lifecycle 2018 [21]) entsteht, in der die Produktion als "zertifizierter Raum" fungiert und sich nur erlaubte Änderungen deployen lassen.

Die "Automatisierte Governance [22]" (Continuous Lifecycle 2019) garantiert dabei die Einhaltung der Regeln, während die Entwickler, die ja auch Betrieb machen, eigenständig und ohne auf andere warten zu müssen, arbeiten können:

DevOps ist normal

In der Realität vieler Unternehmen ist DevOps anscheinend noch nicht ganz normal, zumindest lässt sich das aus den Reaktionen des Publikums auf den Vortrag "DevOps ist normal [23]" (DevOps Essentials 2019) schließen. Der Weg zu DevOps lässt sich mit dem Weg zum Führerschein vergleichen: Am Anfang lernt man die theoretischen Grundlagen und übt dann auf der Straße das Fahren, bis man es kann. Ein Fahrlehrer unterstützt dabei und verhindert das Schlimmste. So führen auch unterschiedliche Unternehmen derzeit DevOps in großem Stil ein: DevOps-Coaches unterstützen Teams in einer Transitionsphase und helfen den Entwicklungsteams, mit den neuen Verantwortlichkeiten im produktiven Betrieb klarzukommen.

Warum ist DevOps erfolgreich?

Es gibt sicherlich viele Faktoren, die DevOps zur Erfolgsgeschichte verholfen haben. In der Erfahrung des Autors hebt sich ein Thema von allen anderen Aspekten ab: DevOps ist ein Ansatz, bei dem nicht ein bestimmtes Werkzeug im Vordergrund steht, sondern die Art und Weise der Zusammenarbeit. Dabei befördert die Zusammenlegung der Verantwortlichkeiten von Dev und Ops eine ganzheitliche und durchgehende Automation der bisher manuellen Tätigkeiten. Diese Automation führt sehr schnell zu einem Abbau der technischen und organisatorischen Schulden und erlaubt es allen Beteiligten, viel mehr Zeit mit der Weiterentwicklung nachhaltiger Lösungen zu verbringen.

Für die Mitarbeiter, die den Weg mitgehen, bringt DevOps meistens auch andere Vorteile mit sich: Der Wert einer zuverlässig laufenden Software wird massiv angehoben, die Gehälter von "DevOps-Experten", die ihre Aufgabe in der Automation statt im Handbetrieb sehen, sind meistens deutlich höher als die Gehälter klassischer Administratoren. Der damit einhergehende Skillaufbau und die Investition in die Fähigkeiten der Mitarbeiter machen sich für den Arbeitgeber idealerweise in Form einer besseren Qualität der gelieferten Ergebnisse bemerkbar. Im besten Fall bringt DevOps damit nicht nur einen Kulturwandel, sondern vor allem auch eine andere Art, mit IT zu arbeiten: Die Automation trägt die Hauptlast des Produktivbetriebs und die Mitarbeiter können sich auf die Weiterentwicklung und Verbesserung der Automation fokussieren, statt mit manuellen Tätigkeiten die Produktion stabil zu halten.

DevOps ist daher im Kern ein praktischer und praxisorientierter Weg, um das eingesetzte “Humankapital optimal mit IT zu verbinden”, sagt John Willis, einer der Urväter der DevOps-Bewegung in seinem aktuellen Vortrag "DevOps' Seven Deadly Diseases" (Yalla DevOps 2019).

Die sieben Sünden beziehen sich auf typisches Managementverhalten, das dem nachhaltigen Erfolg von DevOps im Weg steht. DevOps ist und bleibt eben vorrangig ein Thema für die zwischenmenschlichen Beziehungen und ist nur nachgelagert ein Thema für Technik und Automation.

DevOps morgen und übermorgen

Solange sich Unternehmen nicht grundsätzlich reformieren und ihre Wertschöpfungsketten auf Automation statt Handarbeit ausrichten, wird uns DevOps als Thema begleiten und dabei helfen, den richtigen Weg einzuschlagen. Die fünf DevOps-Prinzipien helfen dabei, die Herausforderungen sichtbar zu machen und für sich konkrete Meilensteine in der Umsetzung zu finden.

Irgendwann wird hoffentlich DevOps so normal sein, dass niemand mehr darüber spricht und man sich höchstens am Stammtisch noch daran erinnert, wie es damals so war, als die DevOps-Revolution in den Firmen ausgefochten wurde. Als objektiver Indikator können auch hierfür wieder Konferenzen dienen: Wenn es irgendwann keine DevOps-Konferenzen mehr gibt, dann ist DevOps wohl wirklich normal geworden.

Schlomo Schapiro
ist ein agiler IT- und Open-Source-Enthusiast, der sich für ein agiles Mindset und DevOps-orientierte Kultur in der IT engagiert. Er arbeitet als Chefarchitekt im CTO-Bereich der DB Systel in Berlin, ist Autor diverser Open-Source-Projekte [24] und veröffentlicht regelmäßig Blog [25]- und Magazinartikel. (ane [26])

URL dieses Artikels:
https://www.heise.de/-4595829

Links in diesem Artikel:
[1] https://devopsdays.org/
[2] https://legacy.devopsdays.org/events/2009-ghent/
[3] https://www.heise.de/hintergrund/devopsdays-2010-in-Hamburg-1132687.html
[4] https://legacy.devopsdays.org/events/2009-ghent/program/
[5] https://devops.com/how-to-implement-an-effective-ci-cd-pipeline/
[6] https://www.slideshare.net/schlomo/slac-2013-betriebsautomation-immobilien-scout24
[7] https://www.slideshare.net/schlomo/package-deployment-building-bridges-between-dev-and-ops
[8] https://www.slideshare.net/schlomo/telekom-techtalk-practical-devops
[9] https://www.heinlein-support.de/slac/2011/vortrag/devops-neue-arbeitsweise-und-selbstverstaendnis-in-der-it
[10] https://www.slideshare.net/schlomo/se-2015-devops-risk-mitigation-test-driven-infrastructure
[11] http://www.linuxtag.org/2014/fileadmin/docs/slides/Stefan_Neben_-_Automatische_Rotation_von_DKIM-Schluesseln.e3132.pdf
[12] https://www.slideshare.net/schlomo/osdc-2016-hybrid-cloud-a-cloud-migration-strategy
[13] https://www.heinlein-support.de/slac/2017/vortrag/devops
[14] https://www.heinlein-support.de/sites/default/files/slac2017_Proposal-Workplace-Strategy-for-the-Digital-Age.pdf
[15] https://www.heise.de/select/ix/2017/5/1492957360068532
[16] https://www.cio.de/a/deutsche-bahn-it-schafft-fuehrungskraefte-ab,3602696
[17] https://www.slideshare.net/schlomo/devops-continuous-delivery-cloud-the-three-drivers-of-enterprise-agility-aws-summit-07062018-schlomo-schapiro
[18] https://www.heise.de/select/ix/2018/12/1543307275832791
[19] https://docs.google.com/document/d/e/2PACX-1vSCptWfeM9ROdlZv5PmkanYCUJVm6eUJTaciLmYDphAl0-8TUgW9PRA0yPqUx4D_TwC7pcl5zdmQl4e/pub
[20] https://www.slideshare.net/schlomo/compliant-by-default-continuous-delivery-at-db-systel-16102018-schlomo-schapiro-and-hendrik-pahl
[21] https://www.continuouslifecycle.de/
[22] https://www.slideshare.net/schlomo/automated-governance-continous-lifecycle-2019-schlomo-schapiro
[23] https://www.slideshare.net/schlomo/devops-is-normal-devops-essentials-2019-schlomo-schapiro
[24] https://github.com/schlomo
[25] https://blog.schlomo.schapiro.org/
[26] mailto:ane@heise.de

Copyright © 2019 Heise Medien