DevOps & Deployment

DevOps wird häufig auf Werkzeuge verkürzt, ist aber zuerst eine Frage der Zusammenarbeit. Klassisch trennten Organisationen Entwicklung und Betrieb: Die einen wollten Neues ausliefern, die anderen Stabilität sichern — mit gegenläufigen Zielen und einer Übergabe als Bruchstelle. Der Kerngedanke von DevOps ist, diese Verantwortung zu teilen: Wer etwas baut, ist auch dafür zuständig, dass es im Betrieb funktioniert.

Daraus folgt fast alles Weitere. Kleine, häufige Änderungen sind sicherer als große seltene, weil sich der Fehlerraum verkleinert und Ursachen leichter zuzuordnen sind. Automatisierung ist notwendig, weil Handarbeit bei hoher Frequenz nicht mehr trägt und Menschen bei Wiederholungen Fehler machen. Und Rückmeldung aus dem Betrieb muss zurück in die Entwicklung fließen, sonst wiederholen sich dieselben Probleme.

Die Werkzeuge sind austauschbar; die Prinzipien nicht. Ein Team, das täglich ausliefert, aber niemanden hat, der sich für Ausfälle zuständig fühlt, hat DevOps nicht eingeführt, sondern nur beschleunigt.

Eine ausgereifte Kette folgt einem festen Ablauf. Eine Änderung wird eingereicht und überprüft, dann automatisch gebaut und getestet. Aus dem Ergebnis entsteht ein unveränderliches Artefakt — häufig ein Container-Abbild —, das anschließend genau so in Test-, Vorschau- und Produktionsumgebungen läuft. Dass überall dasselbe Artefakt eingesetzt wird, ist der entscheidende Punkt: Was in der Testumgebung funktioniert hat, ist bitweise dasselbe wie im Betrieb.

Die Umgebungen selbst beschreibt man idealerweise ebenfalls als Code, damit sie reproduzierbar entstehen und Unterschiede zwischen Servern nicht schleichend anwachsen. Geheimnisse wie Zugangsdaten gehören dabei nie ins Repository, sondern in eine dafür vorgesehene Verwaltung.

Besonders wichtig, aber oft vernachlässigt: der Rückweg. Jede Auslieferung braucht einen geplanten Weg zurück — sei es durch Umschalten auf die vorherige Version, durch schrittweises Ausrollen an einen kleinen Teil der Nutzer oder durch Funktionsschalter, mit denen sich Neues abschalten lässt, ohne neu auszuliefern. Datenbankänderungen verdienen dabei besondere Sorgfalt, weil sie sich nicht einfach zurücknehmen lassen.

Nach der Auslieferung beginnt die eigentliche Bewährungsprobe. Drei Informationsquellen ergänzen sich: Kennzahlen zeigen Trends wie Antwortzeiten, Fehlerquoten und Auslastung; Protokolle liefern den detaillierten Hergang eines einzelnen Vorgangs; verteilte Ablaufverfolgung verbindet beides über Dienstgrenzen hinweg zu einer nachvollziehbaren Kette.

Alarme sollten sich an dem orientieren, was Nutzer merken, nicht an jedem technischen Ausschlag. Eine Meldung, die nachts weckt, muss eine Handlung erfordern; Alarme, die regelmäßig ohne Konsequenz auflaufen, werden zuverlässig ignoriert und richten damit mehr Schaden an als keine.

Nach Störungen lohnt eine nüchterne Nachbetrachtung ohne Schuldzuweisung. Die produktive Frage lautet nicht, wer den Fehler gemacht hat, sondern warum das System diesen Fehler zugelassen hat und welche Absicherung gefehlt hat. Teams, die so arbeiten, werden mit jeder Störung ein Stück robuster.

Wer bei null beginnt, sollte nicht mit der aufwendigsten Stufe einsteigen. Die wirksame Reihenfolge ist unspektakulär: Zuerst liegt der gesamte Code samt Konfigurationsvorlagen in einer Versionsverwaltung. Dann lässt sich das Projekt auf einem frischen Rechner mit wenigen dokumentierten Befehlen starten — allein dieser Schritt deckt erstaunlich viele unausgesprochene Annahmen auf. Danach folgen automatisierte Prüfungen bei jeder Änderung, und erst anschließend eine Auslieferung, die ohne Handarbeit auskommt.

Erst wenn das steht, lohnen Container, mehrere Umgebungen und Orchestrierung. In umgekehrter Reihenfolge entsteht regelmäßig das Gegenteil des Gewollten: eine anspruchsvolle Plattform, die niemand vollständig versteht, während der Weg vom Entwicklungsrechner in den Betrieb weiterhin aus manuellen Schritten und mündlich weitergegebenem Wissen besteht.

Ein guter Prüfstein ist die Frage, wie lange es dauert, eine einzeilige Korrektur in den Produktivbetrieb zu bringen — und wie viele Personen dafür verfügbar sein müssen. Beide Werte zu senken, ist praktisch immer die lohnendste Investition.