Der Weg zu stabilen DevOps-Strukturen und Strategie: Feierabend statt Feueralarm

Kennst du das? Das Popcorn ist noch warm, der Vorspann deines Freitagabendfilms läuft gerade an – deine Partnerin oder dein Partner neben dir. Perfekt. Dann das Summen. Diese allzu vertraute Vibration in deiner Hosentasche. Als IT-Manager im Bereitschaftsdienst eines Unternehmens, das kritische Infrastruktur betreibt, ist dein Telefon eine Lebensader – oder manchmal eine Leine. Dreißig Minuten. So viel Zeit hast du, um an deinem Arbeitsplatz zu sein, das Team zu mobilisieren. Ein weiterer Notfalleinsatz am Wochenende beginnt.

Das wäre dann der dritte Freitag in Folge. Ein kritischer Produkt-Release, der in zwei Wochen live gehen soll, fordert offensichtlich seinen Tribut. Mit einem Seufzer, der das Gewicht unterbrochener Familienzeit und steigenden Drucks trägt, schaltest du deinen Laptop ein – das Klackern der Tastatur wie ein Vorbote dafür, dass bald die halbe Operations-Abteilung geweckt wird. In so einer Umgebung wird es zur Gewohnheit, nicht einmal mehr über Zeitzonen nachzudenken und Leute um 1 Uhr morgens aus dem Bett zu holen.

Und im Hinterkopf kreisen die Fragen:

Wie durchbrechen wir diesen Kreislauf?

Wie können wir Änderungen während der Arbeitszeit ausrollen und Vorfälle automatisiert, oder zumindest ohne Vollalarm bewältigen?

Unser Team landet oft mitten in solchen Feueralarm-Situationen. Die erste Maßnahme ist dann nicht, eine 100-seitige PowerPoint über ideales DevOps zu präsentieren. Sondern: zum virtuellen Feuerwehrschlauch greifen und helfen, die dringendsten Brände zu identifizieren und zu löschen. Dabei geht es nicht nur um Soforthilfe, sondern darum, wertvolle Zeit zurückzugewinnen. Zeit zum Atmen, Nachdenken und zur gemeinsamen Entwicklung eines echten Fahrplans, um das System langfristig zu stabilisieren. Bei XALT glauben wir daran, alle auf diese Reise mitzunehmen. Das Team soll nicht nur das „Warum“ verstehen, sondern auch aktiv am „Wie“ mitarbeiten.

Authentifizierungsplattform im Active/Active-Betrieb

Nehmen wir zum Beispiel eine zentrale Plattform für Authentifizierung und Autorisierung bei einem kritischen Institut. Sie war im Falle unseres Kunden eine ständige Quelle jener vorfallreichen Wochenenden.

Eine nicht verhandelbare Anforderung war: Die Plattform musste im Active/Active-Modus über zwei Regionen hinweg betrieben werden. Ohne das weigerten sich andere zentrale Dienste, auf sie umzuziehen. Diese Anforderung wurde in jeder erdenklichen internen Besprechung erwähnt. Diese Strategie der Verstärkung, basierend auf Prinzipien erfolgreicher Organisationen (wie sie zum Beispiel Gene Kim in seinen Büchern beschreibt), erwies sich hier als entscheidend.

Unsere Erfahrung zeigt: Dieses konsequente Kommunizieren hilft enorm dabei, überhaupt erst das Budget für die Behebung solcher Kernprobleme zu sichern. Sobald die Mittel bewilligt waren, lag es an uns, die Lage zu verbessern. Unter Berücksichtigung der einzigartigen Umgebung und Rahmenbedingungen entwarfen und implementierten wir eine maßgeschneiderte Lösung für den robusten Active/Active-Betrieb und beseitigten damit endlich den Blocker für die abhängigen Teams.

SRE-Kultur und strukturierte Betriebsprozesse

Doch Technologie ist nur ein Teil der Gleichung. Während des komplexen Umstiegs von Active/Standby auf Active/Active arbeiteten wir eng mit dem Operations-Team zusammen, um dessen SRE-Kultur (Site Reliability Engineering) weiterzuentwickeln.

Zunächst erstellten wir klare Anleitungen für alle täglichen Aufgaben. Dabei war es uns sehr wichtig, dass diese Anleitungen nicht einfach verstreut in Einzelnotizen enden. Wir sorgten dafür, dass sie alle an einem zentralen Ort in Confluence zusammengeführt wurden. So wurde Confluence zur einzigen zuverlässigen Anlaufstelle für alle Informationen.

Als Atlassian Platinum Partner wissen wir, wie viel besser Teams Wissen teilen, wenn Confluence strukturiert genutzt wird. Und ja, wir helfen auch gerne bei der Migration von Jira und Confluence in die Cloud!

Parallel dazu etablierten wir eine Kultur von Post-Mortems ohne Schuldzuweisungen. Es ist beeindruckend, wie viel man lernen kann, wenn der Fokus auf Systemverbesserung statt auf Schuld liegt. Damit diese Kultur wirklich verankert wird und Teams auf alle Eventualitäten vorbereiten kann, gehen wir bewusst über die übliche Praxis hinaus, diese Reviews nur bei großen, umsatzkritischen Incidents durchzuführen, wie es in einigen Finanzunternehmen Standard ist.

Wir haben übrigens eine Lieblingsvorlage für Post-Incident-Berichte, die wir gerne als Ausgangspunkt nutzen – du kannst sie hier kostenlos ansehen und für dein Team anpassen.

Zur weiteren Verbesserung der Plattformstabilität und um dem Team schnelle Rollbacks sowie sichere Releases zu ermöglichen, setzten wir auf eine Blue/Green-Deployment-Strategie. Das ist oft unser bevorzugter Ansatz, um schnelle, sichere Rollbacks zu gewährleisten. Natürlich wirken Canary Releases für Progressive Delivery noch besser, aber manchmal sind Anwendungen einfach nicht dafür geeignet, vor allem wenn zum Beispiel eine zentrale Datenbank im Spiel ist, die Teildeployments erschwert.

Für das Blue/Green-Setup nutzten wir separate GKE-Cluster innerhalb ihrer GCP-Umgebung. Das war ein echter Game-Changer. Es verschaffte dem Team immense Sicherheit. Das Ende von stressigen Freitags- und Sonntags-Releases war gekommen. Das Schlimmste, was jetzt noch passieren konnte, war eine verzögerte Veröffentlichung. Ein gewaltiger Fortschritt gegenüber vorherigen Notfällen mit „Fix Forward“-Zwang.