Wie erkennt und behebt man proaktiv Produktionsprobleme, bevor sie zu einer Geschäftsunterbrechung führen? Respond ist die Aktivität im SAFe DevOps Health Radar, die genau diese Frage beantwortet. In diesem Video erkläre ich, was Respond umfasst und warum es für die Aufrechterhaltung einer stabilen Produktionsumgebung unverzichtbar ist.
Wo Respond in die Pipeline passt#
Der SAFe DevOps Health Radar beginnt beim Kunden. Gute Ideen werden in Hypothesen und Epics umgewandelt. In Collaborate and Research identifizieren wir das echte Kundenbedürfnis. Wir erstellen die minimale Architektur, brechen Epics in Features herunter, entwickeln User Stories, committen Code, bauen deploybare Artefakte, testen End-to-End, deployen in die Staging-Umgebung und dann kontinuierlich in die Produktion. Nach der Verifizierung des Produktions-Deployments und dem Monitoring der Umgebung kommen wir zu Respond.
Im Respond-Schritt wollen wir proaktiv Produktionsprobleme erkennen und beheben, bevor sie zu einer Geschäftsunterbrechung führen können.
Warum Respond wichtig ist#
Produktionsprobleme passieren. Selbst die grossen Player wie Google, Facebook und Amazon haben Ausfälle. Produktionsprobleme betreffen immer den Kunden und binden Ressourcen. Wenn etwas kaputtgeht, muss das Team Fixes erstellen, Patches bereitstellen, erneut deployen und erneut testen. All das reduziert den Fluss von zukünftigem Mehrwert in die Produktion.
Deshalb ist die proaktive Reaktion auf Incidents so entscheidend.
Proaktive Erkennung#
Im Monitoring-Schritt (früher in dieser Serie behandelt) haben wir Telemetrie- und Logging-Systeme eingerichtet. Weil wir all diese Telemetriedaten zur Verfügung haben, können wir Toleranzschwellenwerte erstellen, die uns bei gefährlichen Zuständen alarmieren.
Eine gute Benachrichtigungsstrategie ist hier unverzichtbar. Wir sollten nicht bei allem alarmieren. Die Schwellenwerte müssen sorgfältig evaluiert werden, damit wir nur bei wirklich gefährlichen Zuständen Benachrichtigungen erzeugen. Andernfalls riskieren wir eine Alert-Müdigkeit, bei der das Team aufhört aufzupassen, weil es zu viele Fehlalarme gibt.
Disaster Recovery üben#
Katastrophen werden in der Produktion immer eintreten. Deshalb müssen wir Disaster-Recovery-Verfahren regelmässig üben. Wenn ein echter Incident eintritt, muss das Team die Verfahren bereits kennen und schnell ausführen können.
Teamübergreifende Zusammenarbeit#
Was wir nicht wollen, ist das Schwarze-Peter-Spiel: Der Kunde ruft den Service Desk an, der Service Desk schickt das Problem zum Entwickler, der Entwickler zeigt auf den Product Owner, der Product Owner schickt es zum Tester, und alle zeigen mit dem Finger aufeinander.
Was wir stattdessen wollen, ist teamübergreifende Zusammenarbeit. Wenn etwas in der Produktion passiert, arbeiten alle gemeinsam daran, das Problem zu erkennen, zu analysieren und zu lösen. Nach jedem Incident führen wir ein Incident-Post-Mortem-Meeting durch, bei dem alle Beteiligten identifizieren, was verbessert werden kann, damit der Incident entweder nie wieder auftritt oder beim nächsten Mal deutlich schneller gelöst werden kann.
Immutable Infrastructure#
Eine unveränderliche Infrastruktur in der Produktion ist sehr hilfreich. Bei einer unveränderlichen Infrastruktur kann niemand direkte Änderungen an der Produktion vornehmen. Alle Änderungen müssen durch die Continuous-Delivery-Pipeline gehen.
Infrastructure as Code unterstützt diesen Ansatz, weil die gesamte Umgebungskonfiguration als Konfigurationsdateien in der Versionskontrolle gespeichert wird. Das stellt sicher, dass jede Änderung nachvollziehbar und reproduzierbar ist.
Alles unter Versionskontrolle#
Um effektiv auf Incidents reagieren zu können, muss alles unter Versionskontrolle stehen: der gesamte Code, die gesamte Infrastrukturkonfiguration, alle Tests, alle Testdaten, alle Anforderungen. Nur so können wir Incidents analysieren, sehen was sich geändert hat, wann und warum. Und nur so können wir bei Bedarf schnelle Rollbacks durchführen.
Rollback vs. Fix Forward#
Wenn ein Produktionsproblem auftritt, haben wir zwei Hauptstrategien:
- Rollback: Die vorherige funktionierende Version aus der Versionskontrolle holen und erneut in der Produktion installieren. Das ist schnell und stellt die Stabilität sofort wieder her.
- Fix Forward: Das Problem so schnell wie möglich analysieren, einen Fix erstellen und diesen Fix durch die gesamte Continuous-Delivery-Pipeline in die Produktion liefern.
Beide Strategien haben ihre Berechtigung, und die richtige Wahl hängt von der Schwere des Problems ab und davon, wie schnell ein Fix entwickelt werden kann.
Session Recording#
Systeme werden immer komplexer, und Nutzer durchlaufen viele verschiedene Workflows. Session Recording ermöglicht es, alles zu speichern, was ein Nutzer tut, damit wir die gesamte Sitzung in einer Test- oder Entwicklungsumgebung abspielen können, um Probleme nachzustellen und zu debuggen.
Bei der Nutzung von Session Recording muss man besonders auf Datensicherheit, Datenschutz und Aufbewahrungsrichtlinien achten, da man eine grosse Menge an Nutzerdaten aufzeichnet.
Die Reifegrade#
Der SAFe DevOps Health Radar bietet eine Reifegradbeurteilung für Respond:
- Sit: Kunden finden Probleme vor uns. Die Behebung von hochprioritären Problemen ist zeitaufwändig und reaktiv. Kunden haben wenig Vertrauen in unsere Fähigkeit, uns von Produktionsproblemen zu erholen.
- Crawl: Der Betrieb ist für Produktionsprobleme verantwortlich. Die Einbindung der Entwicklung erfordert erhebliche Eskalation. Teams beschuldigen sich gegenseitig in Krisenzeiten.
- Walk: Entwicklung und Betrieb tragen gemeinsam die Verantwortung für den Incident-Resolution-Prozess. Die Wiederherstellung nach grösseren Incidents ist reaktiv, aber eine Teamleistung.
- Run: Unsere Monitoring-Systeme erkennen die meisten Probleme, bevor unsere Kunden sie bemerken. Dev und Ops arbeiten proaktiv zusammen, um sich von grösseren Incidents zu erholen.
- Fly: Unsere Monitoring-Systeme warnen uns vor gefährlichen Zuständen auf Basis sorgfältig definierter Toleranzschwellenwerte. Entwickler sind verantwortlich für den Support ihres eigenen Codes und liefern proaktiv Fixes durch die Pipeline, bevor Nutzer betroffen sind.
Was Respond produziert#
Das Ergebnis des Respond-Schritts ist:
- Eine stabile Produktionsumgebung, die Geschäftskontinuität sicherstellt
- Ein Benachrichtigungs- und Alarmsystem auf Basis sorgfältig evaluierter Schwellenwerte, das das Team bei gefährlichen Zuständen warnt
- Die Fähigkeit zum Release on Demand, was im nächsten Video dieser Serie behandelt wird
Wichtige Erkenntnisse#
- Produktionsprobleme sind unvermeidlich. Selbst die grössten Unternehmen haben Ausfälle. Bereiten Sie sich darauf vor.
- Proaktive Erkennung einrichten. Nutzen Sie Telemetriedaten und sorgfältig definierte Schwellenwerte, um bei gefährlichen Zuständen zu warnen, nicht bei allem.
- Disaster Recovery üben. Warten Sie nicht auf einen echten Incident, um Ihre Wiederherstellungsverfahren zu testen.
- Teamübergreifend zusammenarbeiten. Ersetzen Sie das Schwarze-Peter-Spiel durch teamübergreifende Incident-Behebung und Post-Mortem-Meetings.
- Unveränderliche Infrastruktur nutzen. Alle Änderungen sollten durch die Continuous-Delivery-Pipeline gehen, niemals direkt in der Produktion.
- Alles in der Versionskontrolle halten. Code, Konfiguration, Tests und Anforderungen müssen alle versioniert sein, um schnelle Analyse und Rollbacks zu ermöglichen.