Agile & DevOps

Kolumne: Stropek as a Service

Ready for DevOps? DevOps ist mehr als Technik, es ist ein Organisationsprinzip
Keine Kommentare

Keine IT-Konferenz kommt ohne das Schlagwort „DevOps“ aus. Man hört von Continuous Integration and Deployment, Automatisierung, Infrastructure as Code, Telemetrie und vielen anderen Tools und Technologien. DevOps auf technische Fragen zu reduzieren, ist aber ein folgenschwerer Fehler.

Melvin Conway hat es schon 1967 in dem nach ihm benannten “Conway’s Law“ auf den Punkt gebracht: „Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations“. Wenn wir also eine neue Vorgehensweise wie DevOps in der Softwareentwicklung erfolgreich einführen wollen, müssen wir parallel dazu die Kommunikations- und Organisationsstrukturen überdenken, die es in unserem Unternehmen gibt. Ansonsten erreichen wir das Gegenteil dessen, was wir anstreben: Mehr Koordinationsaufwand, weniger Innovation und instabilere Systeme. In dieser Kolumne möchte ich mich dem Thema widmen, welche organisatorischen Maßnahmen DevOps begleiten müssen, insbesondere im Bereich Cloud-basierter SaaS-Systeme.

Was ist DevOps?

Wie der Name schon sagt, bedeutet DevOps, dass Development und Operations näher zusammenrücken. Konkret heißt das, dass von jedem agil arbeitenden Entwicklungsteam beide Aufgabenbereiche abgedeckt werden müssen. Es geht nicht mehr nur darum, Software zu entwickeln, dicke Betriebshandbücher zu schreiben und alles den Administratoren zum Betrieb über den Zaun zu werfen. Bei DevOps arbeiten die Teams nach dem Prinzip „You build it, you run it.“ Sie tragen nicht nur die Verantwortung für die Software, sondern auch für nennenswerte Teile von deren Betrieb.

Schluss mit Abteilungsdenken

Wenn ich in Workshops das Grundkonzept von DevOps bei größeren Firmen präsentiere, ernte ich in der Regel Zustimmung. Teamgeist, Übernahme von Verantwortung für die eigene Arbeit, eigenverantwortliches Arbeiten, kürzere Kommunikationswege – das alles sind erstrebenswerte Ziele. Wenn es dann aber um die praktische Umsetzung geht, wird es schwierig. Plötzlich werden etablierte Organisationen infrage gestellt. Hier einige Beispiele, die regelmäßig Konfliktpotenzial haben:

  • Die Administrationsabteilung drastisch verkleinern und die betroffenen Personen in die Entwicklungsteams integrieren? Das geht doch nicht, die Mentalität ist viel zu unterschiedlich.
  • Den Entwicklungsteams erlauben, eigenständig betriebsrelevante Entscheidungen zu treffen und diese auch umzusetzen? Das führt sicher zu Chaos, schließlich haben die Entwickler keine Ahnung davon, was es heißt, ein Produktionssystem am Leben zu halten.
  • Zugriff auf Produktivsysteme durch Entwicklungsteams? Das wäre ein Datenschutzalbtraum.
  • Um drei Uhr früh durch einen Telefonanruf aus dem Schlaf gerissen werden, weil die produktive Web-App steht? Genau das will ich nicht, darum bin ich Softwareentwickler und nicht Administrator geworden.

Geht man solchen Fragen aus dem Weg, ist Frust unausweichlich. Die Entwicklungsteams möchten DevOps leben, die Systemadministration gibt ihnen aber nicht die dafür notwendigen Rechte und stellt sich organisatorisch nicht darauf ein. Die Administratoren ärgern sich, weil ihnen die Entwicklungsteams ständig in ihre angestammten Verantwortungsbereiche reinreden, ohne die volle Verantwortung für ihr Handeln zu tragen.

Aus diesem Grund muss eine DevOps-Einführung die Aufbau- und Ablauforganisation von bestehenden Unternehmen hinterfragen. Man muss bereit sein, tiefgehende Änderungen vorzunehmen.

Verantwortung übernehmen und abgeben

DevOps bedeutet, dass der Verantwortungsbereich von Entwicklungsteams größer wird. Die Aufgaben enden nicht, wenn der Code geschrieben und die „Definition-of-Done“-Checkliste für die im Backlog geforderten Features abgearbeitet ist. Das Team arbeitet nach dem Production-first-Prinzip. Egal was entwickelt oder geplant wird, entscheidend ist, dass das Produktionssystem für die Benutzer optimal funktioniert. Reaktionen auf gemeldete Bugs wie „Aber bei uns in der Testumgebung geht das“ sind ein No-Go.

Diese Änderung in der Aufgabenverteilung hat weitreichende Konsequenzen. Hier einige Beispiele:

  • Die Entwicklungsteams werden bei jeder Entscheidung in Sachen Softwarearchitektur hinterfragen, ob sie gut für die Stabilität des Produktivsystems ist. Ist sie es nicht, wären die Konsequenzen im eigenen Team direkt spürbar.
  • Arbeitszeiten, Bereitschaftszeiten und Urlaube in Entwicklungsteams müssen an den Produktionsbetrieb angepasst werden.
  • Die Entwicklungsteams brauchen Zugriff auf die Produktionssysteme. In Zusammenarbeit mit spezialisierten Personen müssen Richtlinien, Abläufe und Tools geschaffen werden, die eine gute Balance aus zeitlich und funktional eingeschränkten Zugriffsmöglichkeiten, Datenschutz und Datensicherheit bieten.
  • In größeren Organisationen gibt es viele Entwicklungsteams. Das heißt, dass DevOps dezentralisiert ist und die Vorgehensweisen wahrscheinlich von Team zu Team abweichen. Diese Vielfalt muss zugelassen, durch nicht zu enge Enterprise Alignment Policies in Bahnen gelenkt und durch spezialisierte Teams begutachtet werden (siehe auch nächster Punkt).
  • Die spezialisierten Administrationsteams geben Verantwortung ab. Sie kümmern sich um die Basisinfrastruktur (z. B. Strom, physisches Netzwerk, Serverbeschaffung, Verwaltung von VM- und Containerclusterlösungen, Verwaltung der Cloud-Computing-Basisinfrastruktur). Außerdem haben sie eine teamübergreifende, beratende und steuernde Rolle, insbesondere bei sicherheitsrelevanten Themen.

Die richtigen Werkzeuge

Damit Entwicklungsteams DevOps machen können, brauchen sie Zugang zu entsprechenden Werkzeugen. Es reicht allerdings nicht, die Tools anzuschaffen: Die DevOps-Teams müssen sie auch nutzen dürfen. Was hilft ein Testautomatisierungstool, wenn die Beantragung (!) einer zusätzlichen Testumgebung Wochen in Anspruch nimmt? Welchen Sinn hat ein System für Continuous Deployment, wenn die Entwicklungsteams keine Berechtigungen zum Ausrollen neuer Softwareversionen haben? Diese Fragen sind keine theoretischen. In meiner Praxis als Berater sehe ich regelmäßig Organisationen, die eine Abkürzung gehen wollen: Sie lizenzieren DevOps-Plattformen, vergessen dabei aber, die organisatorischen Rahmenbedingungen für ihre Nutzung zu schaffen.

Um den Einstieg in DevOps zu erleichtern, bekommen Sie an dieser Stelle eine Liste von Tools, die aus meiner Sicht eine Mindestausstattung für erfolgreiches DevOps ist. Natürlich sollte man sie von Projekt zu Projekt anpassen.

  • Testautomatisierung (inkl. Integrations- und End-to-end-Tests)
  • System für Continuous Integration and Deployment (inkl. Release- und Configuration-Management)
  • Tools für Monitoring und die Sammlung von Telemetriedaten im Produktivsystem (aka Application-Performance-Management)
  • Tools für Test in Production (z. B. Canary Releases, Staging Environments mit Hot Swapping, Feature Flags)
  • Tools für die Automatisierung von Infrastrukturwartung („Infrastructure as Code“-Prinzip)
  • Services für die sichere Verwaltung von Zugangsdaten zu Produktivsystemen (z. B. Passwörter, API Keys, Zertifikate etc., inkl. automatisierter Prozesse für Key Rollover)
  • Zusätzlich zu diesen Werkzeugen für die Entwicklungsteams braucht es zentrale Werkzeuge für die Umsetzung und Kontrolle von Richtlinien: Teamübergreifende, automatisierte Kontrolle insbesondere von sicherheitsrelevanten Systemmerkmalen (z. B. statische Codeanalyse zur Erkennung von Sicherheitslücken wie SQL Injection oder Passwörtern im Code, Kontrolle von Vorgaben bzgl. Vorhandensein von Sicherheitssystemen wie z. B. Firewalls, API-Gateways, DDoS Protection)
  • Vorlagen für Systemkomponenten, die den Organisationsrichtlinien entsprechen. Sie erhöhen die Produktivität insbesondere beim Start neuer Projekte.
  • Komponenten für Kostenkontrolle.

DevOps bei Cloud und SaaS

Wenn man sich die Grundprinzipien von DevOps ansieht, wird schnell klar, dass das gesamte Potenzial von DevOps nur in Zusammenhang mit Cloud-Computing und SaaS genutzt werden kann. Wie können Entwicklungsteams die Gesamtverantwortung vom Code bis hin zur Produktionsumgebung übernehmen, wenn die Software beim Kunden läuft und der Zugriff auf dessen Systeme unmöglich ist? Wie sollen sie frühzeitig technische Schwächen erkennen, die bei Endbenutzern zu schlechter Performance oder sogar Fehlern führen, wenn die Logs und Telemetriedaten beim Kunden versauern?

Hinzu kommt, dass ohne Cloud-Computing fast alle IT-Organisationen, die ich kenne, mit den technischen Voraussetzungen (siehe z. B. Liste an notwendigen Tools oben) für DevOps überfordert sind. Eine professionelle Private Cloud aufzubauen, die es einer nennenswert großen Anzahl an Teams erlaubt, eine SaaS-Lösung nach dem DevOps-Prinzip aufzubauen und zu betreiben, ist ein riesiges Projekt. Sogar die meisten spezialisierten SaaS-Anbieter sind damit überfordert, kleine bis mittelgroße Kunden sowieso.

Die gute Nachricht ist, dass Public-Cloud-Anbieter wie Microsoft ihre eigenen Cloud-Dienste für ihre SaaS-Produkte nutzen und dabei ebenfalls auf DevOps setzen. Aus diesem Grund bekommt man bei ihnen eine qualitativ hochwertige Basis zu einem überraschend niedrigen Preis. Aus meiner Sicht sollte man auf diesen Wettbewerbsvorteil nicht verzichten und ihn zumindest für jene Systeme nutzen, für die ein Betrieb in der Cloud aus strategischen oder rechtlichen Gründen nicht ausgeschlossen ist.

Fazit

Wer mit DevOps beginnt oder mit DevOps in der Praxis noch kämpft, sollte einen kritischen Blick auf seine Organisation werfen, bevor noch mehr Tools oder Services lizenziert werden. Heilige Kühe wie alteingesessene Abteilungsstrukturen, etablierte Machtbereiche, jahrelang übliche Berichts- und Kontrollstrukturen und die eingefahrene Arbeitsteilung müssen geändert werden. Man muss ehrlich hinterfragen, ob man in der Lage und willens ist, im eigenen Haus die für DevOps notwendigen Werkzeuge aufzubauen und zu betreiben oder nicht doch die Cloud der bessere Weg ist. Nur so profitiert man von den Vorteilen, die der DevOps-Ansatz mit sich bringt.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -