Kolumne: DevOps Stories

Sind wir schon fertig? Was Teams beim Produktivbetrieb beachten sollten
Keine Kommentare

Lukas hat sich mit seinem Freund Arne abends zum Kino verabredet. Gegen Mittag rief Arne ihn an und sagte, dass er erst später Zeit hat und sie sich stattdessen zum Abendessen treffen könnten. Auch zu diesem Abendessen kommt er eine Viertelstunde zu spät.

  • Arne: „Hi Lukas. Sorry, dass ich zu spät bin. Aber wie haben wir im Studium gesagt? Eine Viertelstunde geht immer, oder?“
  • Lukas: „Kein Problem! Du scheinst ja ganz schön unter Strom zu stehen. Mit dem Kino hat es heute ja leider nicht geklappt.“
  • Arne: „Ja, das stimmt. Im Büro ist in letzter Zeit super viel los – vor allem Ärger. Und dann habe ich heute noch meinem Bruder geholfen. Der hat gerade mit seiner Familie ein Haus gebaut und zieht im Moment ein. Das ist ein Zirkus mit dem Bauträger, kann ich dir sagen.“
  • Lukas: „Wieso?“
  • Arne: „Na, eigentlich ist alles fertig. Tatsächlich fehlen aber so viele Details, dass du eigentlich nicht sinnvoll drin wohnen kannst.“
  • Lukas: „Zum Beispiel?“
  • Arne: „An der Terrassentür fehlt auf der einen Seite eine Klinke, im Bad lässt sich die Temperatur nicht richtig regeln, sie haben keine Bedienungsanleitung für die komplexe Geothermieanlage und die Handwerker können ihnen auch nicht sagen, wie sie zu bedienen ist. Außerdem funktioniert die ganze Home-Automation immer noch nicht richtig. Zusätzlich gibt es natürlich noch eine ganze Menge kleiner Baumängel.“
  • Lukas: „Du hast aber beim Einziehen und nicht bei diesen Problemen geholfen, oder?“
  • Arne: „Ja, klar. Das muss der Bauträger regeln.“
  • Lukas: „Und auf der Arbeit?“
  • Arne: „Wir haben gerade ein großes Release ausgeliefert und das knirscht an allen Ecken und Enden.“
  • Lukas: „Der Produktionsbetrieb läuft nicht rund?“
  • Arne: „Ja, die Jungs vom Betrieb des Kunden bekommen es nicht stabil und können während ihrer Bereitschaft nicht selbstständig Probleme beheben. Die stehen dann ständig bei uns auf der Matte, wollen noch dies und brauchen noch das.“
  • Lukas: „Fehlen an eurem Release auch noch Klinken und die Home-Automation arbeitet nicht richtig?“
  • Arne: „He, wie meinst du das?“
  • Lukas: (schmunzelt) „Na, ich sehe da durchaus einige Parallelen …“
Abb. 1: Lukas und Arne unterhalten sich beim Abendessen über die Probleme beim Hausbau

Abb. 1: Lukas und Arne unterhalten sich beim Abendessen über die Probleme beim Hausbau

Eine Software in Produktion zu betreiben, ist etwas Besonderes

Arne berichtet von den vielen kleinen Details, die im neuen Haus seines Bruders noch nicht funktionieren, und Lukas sieht Parallelen zu dem noch nicht sinnvoll verwendbaren Produkt, das Arne mit seinem Team ausgeliefert hat.

Ein Softwareprodukt zu entwickeln, ist das eine, es in Produktion zu betreiben, eine ganz andere Sache. Verschiedene Untersuchungen haben gezeigt, dass die initiale Entwicklung nur ca. 30 Prozent der Gesamtkosten eines Produkts ausmacht. Wie sieht die Zeit nach dem initialen Release in der Regel aus? Das Team tastet sich durch Ausprobieren sukzessive an einen stabilen Zustand heran. Das ist im Grunde auch nicht verwerflich – arbeiten wir doch mit Inspect und Adapt und inkrementellen Verbesserungsprozessen. Auf der anderen Seite machen die Teams in diesem Zusammenhang oft die gleichen Fehler. Einige Beispiele dafür sind:

  • Die Anwendung hat ein unzureichendes Monitoring. Das Team weiß also gar nicht, ob alles in Ordnung ist.
  • Wie gehen wir mit Updates im System um? Wie werden potenzielle Datenmigrationen durchgeführt? Wie landen Fixes für kritische Bugs in Produktion?
  • Wie soll die Verfügbarkeit der Anwendung sein? Gibt es irgendwelche SLAs? Müssen Bereitschaftsdienste organisiert werden?
  • Oft wird zum Releasetermin die bisherige Staging-Umgebung zur Produktionsumgebung befördert. Daraus folgt, dass es oft keinen einstudierten Staging-Prozess gibt.
  • Gibt es Anzeichen für das Wachstum der Anwendung? Sind dann genügend Kapazitäten vorhanden? Wie werden diese Kapazitäten freigeschaltet?
  • Wie wird die Anwendung konfiguriert?
  • Von welchen externen Komponenten hängt die Anwendung ab und wie reagieren wir auf Ausfälle oder sonstige Störungen bei diesen Komponenten?

In Arnes Fall sind einige dieser Punkte mit der Übergabe des Softwareprodukts an den Betrieb des Kunden akut geworden. Aber stop: Übergabe an den Betrieb des Kunden? Ist die Erklärung vielleicht ganz einfach? Haben Arnes Kollegen und ihre Kunden einfach die Idee hinter DevOps nicht richtig verstanden? Wir wissen nicht genau, wie das Kollaborationsmodell zwischen Dev (Arne und seine Kollegen) und Ops (Betrieb des Kunden) wirklich ist. Tatsache aber ist, dass es mehr als ein Kollaborationsmodell zwischen Dev und Ops gibt. Lukas Team arbeitet mit einem Cloudprovider. Sie nutzen Services des Providers per API. Das Ops-Team bleibt hinter diesem API verborgen – Lukas und seine Kollegen kennen das Team namentlich nicht. In Arnes Firma findet im Optimalfall eine enge Kollaboration zwischen Dev und Ops statt. Da es hier ein explizites Handover gibt, werden die Probleme mit der Produktionseinführung nur deutlicher sichtbar als es in Lukas‘ Team der Fall wäre. Auftreten werden sie aber in beiden Konstellationen.

Aus Google’s SRE-Modell kommt die Idee einer Produktreifeprüfung …

Site Reliability Engineering (SRE) ist ein weiteres Kollaborationsmodell zwischen Dev und Ops, das stark durch Google geprägt wurde [1]. In diesem Modell gibt es auch ein explizites Handover von Services des Produkt- oder Entwicklungsteams an ein SRE-Team. Damit dabei nicht immer wieder die gleichen Dinge schiefgehen, gibt es bei Google die sogenannten Production Readiness Reviews (PRR). Dieser Reviewprozess findet in den folgenden Fällen statt:

  • Ein neuer Service wird gestartet.
  • Ein produktiver Service wird an ein anderes Team wie SRE übergeben.
  • Ein produktiver Service wird an andere Personen übergeben.
  • Bereitschaftsdienste werden vorbereitet.

Der erste Punkt in dieser Liste zeigt auch, warum sich Google’s Modell von anderen Modellen der Produktionsübergabe unterscheidet: Schon bei der Konzeption eines neuen Service denkt man über den späteren Produktivbetrieb nach. Damit lassen sich einige der weiter oben genannten Probleme umgehen und müssen nicht zum Zeitpunkt der Produktionseinführung mit der heißen Nadel per Trial and Error behoben werden. Es macht beispielsweise bereits sehr früh Sinn, über die Verfügbarkeitsanforderungen an den neuen Service nachzudenken und entsprechende SLAs abzuleiten.

Die Reviews können laut Google als Checklisten oder Fragebögen umgesetzt sein, manuell, automatisiert oder in einer Mischung aus beidem durchgeführt werden und haben den folgenden Zweck [1]:

  • Verify that a service meets accepted standards of production setup and operational readiness, and that service owners are prepared to work with SRE and take advantage of SRE expertise.
  • Improve the reliability of the service in production, and minimize the number and severity of incidents that might be expected. A PRR targets all aspects of production that SRE cares about.

Jaana B. Dogan, die als Software Engineer bei Google arbeitet, hat in einem Blogpost eine beispielhafte Checkliste für ein PRR zusammengestellt. Sie besteht aus den folgenden Elementen:

  • Design and Development
  • Configuration
  • Release Management
  • Observability
  • Security
  • Capacity Planning

Diese Checkliste ist laut ihres Blogposts eher für Kunden gedacht, die ihre Produkte in der Google-Cloud betreiben, als für Google selbst. Deswegen fängt sie bei „Design and Development“ auch mit einem eher grundlegenden Punkt an und macht Builds mit reproduzierbaren Ergebnissen zur Voraussetzung für eine Lösung, die sinnvoll in Produktion betrieben werden kann. In diesem Zusammenhang ist es wichtig, die Abhängigkeit des Build-Prozesses und des Service zu externen Komponenten zu dokumentieren. GitHub ist ein Beispiel für eine solche externe Abhängigkeit. Wenn GitHub nicht erreichbar ist, können viele Organisationen keine Änderungen oder Bugfixes in Produktion pushen, weil der Build-Prozess auf GitHub oder zumindest auf dort gehosteten Repositories basiert. Das ist erst einmal nicht schlimm. Meiner Erfahrung nach sind sich allerdings die wenigsten Organisationen dieser Abhängigkeit bewusst: „Naja, wenn GitHub nicht erreichbar ist, dann pushen wir den Code halt später!“ Dogan setzt sich dafür ein, schon beim Entwurf eines neuen Service über die später angestrebte Verfügbarkeit und entsprechende SLAs nachzudenken.

Unter dem Punkt „Configuration“ beschreibt sie unter anderem, welche Arten von Konfigurationen wo gespeichert werden sollten und dass die Konfigurationen von Test- und Produktionsumgebung unabhängig voneinander sein sollten.

Oft machen sich die Teams erst beim zweiten Release Gedanken darüber, wie Rollouts ablaufen sollen – und über Rollbacks noch viel später. Dogan schlägt vor, sich mit diesen Aspekten aus dem Bereich „Release Management“ bereits sehr viel früher auseinanderzusetzen.

Wenn in der Entwicklung ein Problem mit der Anwendung auftritt, lässt sich dieses Problem verhältnismäßig einfach mit dem Debugger lokalisieren. Bei einem produktiven Service basiert die Fehlersuche dagegen auf Protokoll- und Monitoringdaten (Punkt „Observability“). Diese Daten unterstützen auch dabei, die Einhaltung der SLAs zu bestimmen.

Mit DevSecOps verliert das Thema „Security“ seinen Status als Schmuddelkind. Für einen produktiven Service bedeutet das z. B. verschlüsselte Kommunikation, getrennte Subnetze und den Einsatz von Rollen und Rechten auf der Infrastruktur.

Was passiert mit dem Service unter Last? Wie skaliert er? Welche Anforderungen an die Infrastruktur hat die Skalierung? Mit diesen Fragestellungen beschäftigt sich der letzte Punkt „Capacity Planning“ der beispielhaften PRR-Checkliste.

… um damit schneller zu werden

Manch einen erinnert die Checkliste an lineare Prozesse in klassischen Wasserfallprojekten. Werden wir durch diese vielen Prüfpunkte nicht viel langsamer in der Produktentwicklung und können weniger schnell auf Änderungen reagieren? Dogan meint, dass das Gegenteil der Fall sei. Dadurch, dass ein Team nicht ständig die Fehler anderer Teams wiederholen und durch Trail and Error herausfinden muss, wie sich ein Service stabil in Produktion betreiben lässt, können die Teams sehr viel schneller und effektiver an ihren Services arbeiten. Sie kommen zu schnelleren Designentscheidungen und Fehlersuchen und können neue Mitglieder besser onboarden.

Arne hat sich durch diese Checklisten inspirieren lassen und möchte damit die Übergabe an das Betriebsteam in Zukunft sinnvoller gestalten.

Links & Literatur

[1] Beyer, Betsy et al.: „Site Reliability Engineering. How Google Runs Production Systems”, O’Reilly, 2016

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 -