Kolumne: EnterpriseTales

DevOps Stories: Wenn einer eine (DevOps-)Reise tut…

Konstantin Diener

In der Stadt, in der Lukas arbeitet, gibt es seit Kurzem ein DevOps-Meetup. Lukas ist der Gruppe beigetreten, weil ihn das Themengebiet grundsätzlich interessiert. Der erste Termin hat kein konkretes Thema, sondern soll dem Erfahrungsaustausch und der Positionsbestimmung dienen. Carlos, der Organisator des Meetups, begrüßt die Teilnehmer und spricht einige einleitende Worte.

  • Carlos: „Hallo, schön, dass ihr alle gekommen seid. An unserem ersten Termin möchte ich gerne mit euch darüber sprechen, was ihr unter DevOps versteht, auf welchem Stand ihr heute seid und natürlich auch, welche Erwartungen ihr an das DevOps-Meetup habt.“
  • Tim: „Hi, ich fange einfach mal an. Ich bin Tim und arbeite bei der Müller GmbH. Für mich steht DevOps für Infrastrukturautomatisierung. Wir haben auch in der Firma damit angefangen, aber irgendwie lässt sich das Thema nicht so richtig ins Rollen bringen. Meine Erwartung an das Meetup ist, dass ich von den anderen vielleicht ein paar Best Practices und Toolempfehlungen mitnehmen kann.“
  • René: „Hallo, ich bin René und arbeite für die Meier KG. Ich wäre froh, wenn ich so weit wäre wie Tim. Ich weiß nämlich gar nicht, wo ich mit einer Automatisierung anfangen soll. Wir haben so viele verschiedene Arten von Infrastrukturkomponenten. Server laufen bei uns unter Windows, verschiedenen Linux-Distributionen, Solaris und noch ein paar Exoten. Wir haben verschiedene Virtualisierungstechnologien, Storages etc. Da wir gerade ein weiteres Unternehmen kaufen, werden wir wahrscheinlich von der anderen Firma weitere Sonderlocken erben. Ich möchte hier Tipps mitnehmen, wie ich DevOps bei uns am besten einsetze.“
  • Lukas: „Ich arbeite am Produkt MusicStore, das ihr vielleicht kennt. Unser Produktteam besteht aus Backend- und Frontend-Entwicklern sowie Scrum Master, Product Owner und einer Supportkollegin. Die Anwendung wird von uns selbst in der Cloud deployt und betrieben. Einen expliziten Betrieb, also Ops, gibt es für mein Team nicht mehr. Andere Teams in der Firma haben historisch bedingt noch Betriebskollegen. Wir sind jetzt schon länger auf dem DevOps-Weg und mich würden die Erfahrungen der anderen in diesem Bereich interessieren.“
  • Tim: „Das ist ja cool! Habt ihr da ein Self-Service-Angebot, aus dem ihr euch bedient? Das wäre auch mein Ziel, aber wir kommen da einfach nicht von der Stelle.“
  • Lukas: „Nein, im Moment bauen sich die Teams da noch vieles selbst. Aber gerade überlegen wir in unserer Community, ob wir nicht Self-Service-Angebote schaffen.“
  • Wolfgang: „Hallo, ich bin Wolfgang und seit etlichen Jahren im Anwendungsbetrieb bei der Schulze AG. Ich musste gerade schmunzeln, als du von eurer Systemlandschaft erzählt hast, René. Genauso sieht es bei uns auch aus. Ich bin eher aus privatem Interesse hier, DevOps ist bei uns noch kein Thema. Wir haben eine Abteilung für Softwareentwicklung und eine für den Betrieb. Im Optimalfall lerne ich hier, wie ich mein Management überzeugen kann, dass wir auch DevOps machen sollten. Lukas, wieso habt ihr eine Supportkollegin in eurem Team?“
  • Lukas: „Das hilft uns, noch besser zu verstehen, wie sich unsere Anwendung in Produktion verhält. Wir bekommen sehr direktes Feedback zu unseren Softwareänderungen.“
Abb. 1: Beim DevOps-Meetup diskutieren die Teilnehmer über ihren Stand auf der DevOps-Reise

Abb. 1: Beim DevOps-Meetup diskutieren die Teilnehmer über ihren Stand auf der DevOps-Reise

Eine erfolgreiche DevOps-Reise verläuft meist in bestimmten Schritten

Die Teilnehmer des Meetups haben alle unterschiedliche Rahmenbedingungen, in denen sie arbeiten, und bringen demnach auch unterschiedliche Erfahrungen mit. Eins kann man mit Sicherheit sagen: Tims Erwartung, dass er durch das Meetup einfache Kochrezepte in Form von Best Practices bekommt, die er nur in seinem Unternehmen anzuwenden braucht, um im Thema DevOps voranzukommen, wird enttäuscht werden. So verschieden die Unternehmen der Meetup-Teilnehmer sind, so unterschiedlich wird auch ihre DevOps-Reise sein. Veränderungen in diesem Kontext können nur erfolgreich sein, wenn sie sich am gegebenen Kontext orientieren. Musterlösungen gibt es nicht.

Die Autoren des „2018 State of DevOps Report“ haben allerdings beobachtet, dass erfolgreiche DevOps Journeys in der Regel in bestimmten Stufen ablaufen:

  1. Build the foundation
  2. Normalize the technology stack
  3. Standardize and reduce variability
  4. Expand DevOps practice
  5. Automate infrastructure delivery
  6. Provide self-serving capabilities

Diese Schritte wollen wir uns in den folgenden Abschnitten jeweils etwas genauer ansehen.

Grundlegende Praktiken, die während der gesamten DevOps-Reise wichtig sind

Wie sollte es bei einem IT-Thema anders sein: Neben den eigentlichen Schritten der Reise gibt es einen Schritt 0. Die Autoren haben hier alle Themen zusammengefasst, die sie für die gesamte Reise für unabdingbar halten und orientieren sich dabei am sogenannten CAMS-Modell. Die Abkürzung steht für die Begriffe Culture, Automation, Measurement und Sharing.

Für die gesamte Reise ist es von Vorteil, wenn die jeweilige Organisation:

  • eine Kultur der Verantwortungsübernahme hat,
  • Veränderungen nach dem Kaizen-Prinzip durchführt,
  • versucht, funktionale Silos aufzulösen und
  • bestrebt ist, Dinge im Value Stream „weiter nach links zu schieben“.

Idealerweise baut die Kultur der Organisation auf den agilen Werten auf, arbeitet nach agilen Prinzipien und verwendet insbesondere Werkzeuge wie Retrospektiven zum Lernen und zur Veränderung.

Zu Beginn und während der Reise ist es außerdem wichtig, dass die Teams konsequent auf Automatisierung setzen – beginnend bei der Automatisierung von Tests bis hin zu konsequenter Continuous Integration. Das Thema Infrastrukturautomatisierung, das Tim anspricht, ist hiermit für den Moment noch nicht explizit gemeint.

Kontinuierliche Verbesserung (Kaizen) ist das DevOps-Herzstück. Verbesserung erfolgt in der Regel in Form von Experimenten. Wenn die Organisation nicht messen kann, ob ihre Experimente wirklich zu Verbesserungen führen, handelt es sich allerdings um pures Stochern im Nebel. An dieser Stelle helfen beispielsweise sinnvolle Businessmetriken.

Zu guter Letzt lebt eine DevOps-Kultur vom Teilen („Sharing is caring“). Alle Informationen wie der Status von Veränderungsinitiativen sind öffentlich zugänglich. Allen in der Organisation ist bewusst, was die übergeordneten Ziele sind. Zudem gibt es keine Wissensinseln, sondern Wissen wird im Normalfall den Kollegen zugänglich gemacht.

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? As a follow-up to our previous cheat sheet featuring the most important commands and functions, DevOpsCon speaker Michael Hofmann has put together the 8 best practices you should keep in mind when using Istio.

Einige Teilnehmer des Meetups erwarten Tipps, wie sie einfach auf ihrer DevOps-Reise vorankommen. Wolfgang erhofft sich z. B., dass er Argumente bekommt, um bei seinem Management Lobbyarbeit für das Thema zu machen. Um die Reise seines Unternehmens sinnvoll aufzusetzen, müsste er zunächst einmal Lobbyarbeit für die in diesem Abschnitt genannten Themen machen.

1. Alle weiteren Schritte erfordern einen normalisierten Technologiestack: Viele lassen diesen Schritt 0 außer Acht und versuchen, wie Tim, direkt mit dem vierten Schritt der Reise, der Infrastrukturautomatisierung, zu beginnen. Tim hat allerdings die gleichen Erfahrungen gemacht, die auch die Autoren im Report beschreiben: DevOps-Reisen, die direkt mit dem vierten Schritt beginnen, sind in der Regel nicht erfolgreich.

Warum das so ist, zeigt das Beispiel von René. Er hat so viele verschiedene Infrastrukturkomponenten, dass er gar nicht weiß, wo er anfangen soll. Der erste Schritt auf der DevOps-Reise ist das Ausdünnen des Technologiestacks seines Unternehmens – besonders im Hinblick auf eine Vielzahl von Betriebssystemen und Virtualisierungstechnologien. Für einen weiteren sinnvollen Verlauf der Reise müsste sich Renés Unternehmen im Idealfall auf ein Betriebssystem beschränken (z. B. Linux) und alle Applikationen dorthin migrieren.

Zu diesem Schritt gehört laut den Autoren auch, dass die Softwareentwicklungsteams flächendeckend mit Versionierungssystemen wie Git arbeitet und dort auch die Konfiguration der Anwendung hinterlegt. Das führt dazu, dass Anwendungsversionen direkt aus Git heraus vollständig gebaut und deployt werden können und keine Laufzeitkonfiguration nötig ist.

2. Je mehr standardisierte Bausteine verwendet werden, desto einfacher wird die weitere Reise: Betriebssysteme und Virtualisierungstechnologien sind in der Regel nicht die einzigen Punkte, an denen es in einer gewachsenen IT-Landschaft Standardisierungsbedarf gibt. Gerade in einer Firma wie der von René, die offenbar stark durch Zukäufe wächst, ist die Wahrscheinlichkeit noch größer, dass es z. B. verschiedene Komponenten mit überlappenden Verantwortlichkeiten gibt. In der Regel existiert auch eine Reihe von proprietären Eigenentwicklungen, die sich durch entsprechende Standard-Open-Source-Komponenten ersetzen lassen.

Das zentrale Ziel des zweiten Schritts ist, zunehmend mehr wiederverwendbare Technologien und Architekturmuster in die Organisation einzuführen.

3. Je autonomer die einzelnen Teams arbeiten können, desto schneller werden ihre Lieferungen: Die Standardisierung der Infrastruktur und der Build- und Deployment-Prozesse führt dazu, dass die Teams in der Organisation zunehmend autonomer werden. Sie brauchen keinerlei Freigaben mehr und können die Deployments ihrer Software direkt aus ihrer CI Pipeline anstoßen.

In Lukas‘ Team haben sie genau diese Autonomie. Sie brauchen niemanden um eine Freigabe zu bitten, wenn sie Veränderungen auf einem Test- oder dem Produktivsystem deployen müssen. Einen Teil der Infrastrukturstandardisierung bringt in diesem Fall der Cloudanbieter mit, den das Team verwendet.

In diesem Stadium beginnen die DevOps-Praktiken auch aus der engeren IT-Organisation „herauszustrahlen“. Lukas erzählt, dass beispielsweise eine Supportkollegin Teil ihres Teams ist, um eine bessere Kollaboration zu erreichen.

4., 5. Mit Infrastrukturautomatisierung werden die Teams noch autonomer: Durch die Standardisierung der Infrastrukturkomponenten in den vorherigen Schritten wird es jetzt möglich, die Provisionierung von Infrastruktur zu automatisieren. Tim hat in seiner Firma festgestellt, dass es ohne diese vorherigen Schritte nicht besonders gut funktioniert.

War es bis zum dritten Schritt noch so, dass die Entwicklungsteams mit festen Test- oder Produktivumgebungen arbeiten, können sie nun einfach nach Belieben produktionsgleiche Umgebungen provisionieren, starten und auch wieder verwerfen.
Die Teams, die sich mit der Bereitstellung von Infrastruktur beschäftigen, benutzen spätestens ab Schritt vier, genau wie die Entwicklungsteams, ein Versionierungssystem, um ihre Infrastrukturbeschreibungen abzulegen und zu versionieren.

Der letzte Schritt ist, dass die Infrastrukturthemen so automatisiert sind, dass die Entwicklungsteams sich einfach selbst aus einem Baukasten bedienen können, um z. B. neue Set-ups aufzusetzen – etwas, an dem Lukas‘ Unternehmen offenbar gerade arbeitet.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: