Kennst du das? Das Popcorn ist noch warm, der Vorspann deines Freitagabendfilms lauft gerade an – deine Partnerin oder dein Partner neben dir. Perfekt. Dann das Summen. Diese allzu vertraute Vibration in deiner Hosentasche. Als IT-Manager:in 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?
Wenn dir diese Szene unangenehm vertraut vorkommt, bist du nicht allein. Wir beobachten das in vielen Branchen – besonders bei großen Finanzinstituten, wo Systemverfügbarkeit nicht nur wichtig, sondern grundlegend ist. Der Druck ist enorm, und der „Feuerwehrmodus“ wird zum erschöpfenden Dauerzustand. Wir sehen unsere Kunden immer mit den selben fünf Herausforderungen konfrontiert.
Ohne eine klare DevOps-Strategie gehören nächtliche Anrufe und Wochenend-Einsätze häufig zum Alltag technischer Teams. Wenn kritische Systeme regelmäßig außerhalb der Geschäftszeiten Probleme verursachen, entsteht ein reaktiver Betrieb im ständigen Alarmzustand.
Das Risiko:
Wenn Änderungen nur unter hohem manuellem Aufwand und mit großem Koordinationsbedarf ausgerollt werden können, sind Fehler vorprogrammiert. In Unternehmen ohne automatisierte Deployment-Prozesse steigt das Risiko für:
In vielen Organisationen ist essenzielles Wissen über Systeme, Prozesse oder Konfigurationen nicht zentral dokumentiert, sondern verteilt auf persönliche Notizen, Einzelpersonen oder Chatverläufe.
Das Risiko:
Teams, die im Dauerstress der Fehlerbehebung gefangen sind, haben kaum Kapazitäten, um ihre Systeme nachhaltig weiterzuentwickeln. Ohne DevOps-Strategie verkommt IT zur reinen Feuerwehrtruppe.
Das Risiko:
Wenn nach Systemausfällen keine strukturierte Ursachenanalyse erfolgt, bleibt der Lerneffekt aus.
Das Risiko:
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.
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 z. B. 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.
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 führen Post-Incident-Analysen bewusst schon in UAT- und DEV-Umgebungen durch, nicht erst in der Produktion. So trainieren wir das Denken in Ursachen und Systemverbesserung dort, wo der Druck noch niedrig ist. Teams bauen dadurch Sicherheit auf und reagieren bei echten Incidents mit mehr Ruhe und Fokus.
Ivan Ermilov
Senior DevOps Engineer – XALT
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 z. B. 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.
Das Ergebnis?
Und das Beste? Diese Freitagabend-Feueralarme? Sie sind nur noch eine Erinnerung. Entwickler:innen und Manager:innen können endlich und wirklich abschalten am Freitagabend. Filmabende laufen ungestört. Wochenenden sind wieder heilige Familienzeit. Der Fokus in der IT hat sich vom permanenten, reaktiven Krisenmodus hin zu proaktiver Verbesserung, Innovation und strategischer Planung verschoben.
Wenn deine Wochenenden durch System-Notfälle geraubt werden und „Feuerwehrmodus“ der Normalzustand deines Teams ist, sei dir sicher: Es gibt einen klaren Weg zu Stabilität hin zu dauerhafter Ruhe und Kontrolle. Er beginnt mit dem Bekämpfen des akuten Feuers, führt aber schnell zum Aufbau robuster Systeme und praktikabler Prozesse.
Bereit, die nächtlichen Alarme gegen eine vorhersehbare, stabile und strategisch wachsende DevOps-Umgebung einzutauschen?
Dann sprich mit uns über deinen schnellsten Weg dorthin. Unsere container8-Lösung mit ihrem Set aus schnell implementierbaren Best Practices ist genau darauf ausgelegt, diese DevOps-Probleme direkt anzugehen.
Your project co-pilot
