Nachdem wir ein neues Feature für unsere Nutzer freigegeben haben, müssen wir sicherstellen, dass alles reibungslos läuft. Stabilize ist die Aktivität im SAFe DevOps Health Radar, die sich auf die Aufrechterhaltung eines hohen Niveaus an Geschäftskontinuität konzentriert, damit wir unseren Kunden kontinuierlich Mehrwert liefern können. In diesem Video erkläre ich, was Stabilize umfasst und warum es für eine stabile, widerstandsfähige Produktionsumgebung unverzichtbar ist.
Wo Stabilize in die Pipeline passt#
Der SAFe DevOps Health Radar beginnt mit guten Ideen vom Kunden oder Business. Wir extrahieren eine Hypothese, erstellen ein Epic, forschen gemeinsam nach dem echten Kundenbedürfnis, entwerfen die minimale Architektur und brechen das Epic in Features herunter. Wir entwickeln User Stories, committen Code, bauen deploybare Artefakte, testen End-to-End, deployen in die Staging-Umgebung und dann in die Produktion mit ausgeschaltetem Feature Toggle. Nach der Verifizierung in der Produktion und dem Monitoring reagieren wir auf alle Incidents. Wenn der richtige Zeitpunkt gekommen ist, schalten wir den Feature Toggle ein und geben das Feature für die Nutzer frei.
Jetzt kommt Stabilize. Das Feature ist live und wir müssen sicherstellen, dass alles weiterhin zuverlässig funktioniert.
Architektur für Betriebsfähigkeit#
Im Architecture-Schritt, den wir früher in dieser Serie behandelt haben, entwerfen wir die Architektur für Betriebsfähigkeit. All diese Entscheidungen kommen jetzt in Stabilize zusammen. Wenn wir keine ordentlichen operativen Fähigkeiten in unser System eingebaut haben, werden wir jetzt Schwierigkeiten haben.
Gute Betriebsfähigkeit bedeutet:
- Umfassendes Logging, das alle Daten erfasst, die wir während der Stabilisierung benötigen
- Telemetrie, um das Systemverhalten in Echtzeit zu beobachten
- Feature Toggles, um Features bei Bedarf ein- und auszuschalten
- Wiederherstellungsmechanismen, damit wir schnell reagieren können, wenn etwas schiefgeht
Disaster Recovery#
Ausfälle werden in der Produktion passieren. Selbst die grossen Player wie Google, Amazon und Facebook haben katastrophale Situationen erlebt. Deshalb ist eine Disaster-Recovery-Strategie unverzichtbar.
Features müssen so gestaltet sein, dass sie Disaster Recovery unterstützen. In einem Katastrophenszenario sollte man in der Lage sein, kürzlich deployte Features abzuschalten, um das Problem zu isolieren. Vor allem muss die Disaster-Recovery-Strategie regelmässig geprobt und idealerweise automatisiert und häufig getestet werden.
Proaktive Erkennung und teamübergreifende Zusammenarbeit#
Wenn wir ein ordentliches Monitoring-System haben, können wir Alerts auf gefährliche Schwellenwerte setzen. Wird ein Schwellenwert erreicht, wird das Team benachrichtigt und die teamübergreifende Zusammenarbeit beginnt. Das gesamte Team, das über den Wertstrom hinweg arbeitet, analysiert das Problem gemeinsam, nicht gegeneinander, und löst es zusammen.
Nach jedem Incident führen wir ein Incident Post-Mortem durch. Wir identifizieren, was wir tun können, um solche Incidents in Zukunft zu verhindern, und setzen entsprechende Massnahmen um.
Sicherheit in der Produktion#
Im Build-Schritt scannen wir bereits nach Sicherheitslücken in unserem Anwendungscode und in Bibliotheken. Aber nur den neu erstellten Code zu scannen reicht nicht aus. Code, der bereits in der Produktion läuft, braucht ebenfalls kontinuierliche Aufmerksamkeit.
Wir nutzen Security Information and Event Management (SIEM) Systeme, die eine Echtzeitanalyse von Sicherheitswarnungen liefern. So testen wir unsere laufenden Services kontinuierlich auf Schwachstellen, Angriffe und Eindringlinge.
Monitoring der nicht-funktionalen Anforderungen#
Im Test-End-to-End-Schritt haben wir unsere nicht-funktionalen Anforderungen definiert und automatisierte Tests dafür eingerichtet. In Stabilize überwachen wir alle diese Anforderungen kontinuierlich: Zuverlässigkeit, Leistung, Wartbarkeit, Skalierbarkeit, Benutzerfreundlichkeit und mehr.
Nicht-funktionale Anforderungen sind Einschränkungen für jedes Backlog-Element. Alles, was wir am System ändern, muss diesen entsprechen. Deshalb ist kontinuierliches Monitoring so wichtig.
SLIs, SLOs und SLAs#
Das Verständnis von Service Level Indicators, Objectives und Agreements ist entscheidend für den effektiven Betrieb eines Systems.
Service Level Indicator (SLI): Ein Prozentsatz einer wichtigen Metrik, gemessen an einem bestimmten Kriterium. Zum Beispiel: Im 95. Perzentil soll die Antwortzeit auf einer bestimmten Schnittstelle unter 400 Millisekunden liegen.
Service Level Objective (SLO): Der Prozentsatz eines SLI, den Ihr Team über einen bestimmten Zeitraum erreichen muss. Zum Beispiel: Die Antwortzeit im 95. Perzentil muss in 90% der Fälle über die nächsten 30 Tage unter 400 Millisekunden liegen.
Service Level Agreement (SLA): Die Vereinbarung mit Kunden und Nutzern, die festlegt, was passiert, wenn ein SLO verletzt wird. Zum Beispiel: Wird das SLO verletzt, fallen Strafzahlungen an oder Kunden gehen verloren.
Site Reliability Engineering#
SRE wurde um 2004 von Google eingeführt. Site Reliability Engineers sind hochqualifizierte, T-förmige Ingenieure, die sowohl in der Entwicklung als auch im Betrieb stark sind. Sie betreuen hochskalierbare und hochzuverlässige Systeme.
Die Beziehung zwischen SRE und DevOps hängt von den Verfügbarkeitszielen ab:
- Fünf Neunen (99,999%): Nur 864 Millisekunden Ausfallzeit pro Tag, 5,26 Minuten pro Jahr. SREs sind hier am besten geeignet.
- Vier Neunen (99,99%): Auch auf dieser Stufe bringen SREs erheblichen Mehrwert.
- Drei Neunen und darunter: DevOps-Praktiken sind in der Regel ausreichend.
Je höher das Verfügbarkeitsziel, desto anspruchsvoller wird das Engineering. SREs bringen die spezialisierten Fähigkeiten mit, die für diese anspruchsvollen Anforderungen nötig sind.
Die Reifegrade#
Der SAFe DevOps Health Radar bietet eine Reifegradbeurteilung für Stabilize:
- Sit: Wir erleben häufige ungeplante Ausfälle und/oder Sicherheitsverletzungen mit langen Wiederherstellungszeiten.
- Crawl: Wir erleben gelegentlich ungeplante Ausfälle, erholen uns aber innerhalb unserer Service Level Agreements.
- Walk: Wir haben sehr wenige ungeplante Ausfälle. Verfügbarkeit, Sicherheit und Disaster-Recovery-Massnahmen sind wirksam.
- Run: Wir haben keine ungeplanten Ausfälle. Wir planen und proben Ausfälle und Wiederherstellung.
- Fly: Wir maximieren die Widerstandsfähigkeit, indem wir bewusst Fehler in unsere Produktionsumgebung einschleusen und Wiederherstellungsverfahren proben.
Was Stabilize produziert#
Das Ergebnis der Stabilize-Aktivität ist eine Produktionsumgebung, die:
- Stabil und widerstandsfähig ist
- Zuverlässig und verfügbar ist
- Unterstützbar und wartbar ist
- Sicher gegen Schwachstellen und Angriffe ist
All dies unter Einhaltung der SLOs, die in den SLAs definiert sind. Mit Stabilize erreichen wir das hohe Mass an Geschäftskontinuität, das nötig ist, um unseren Kunden kontinuierlich Mehrwert zu liefern.
Wichtige Erkenntnisse#
- Früh für Betriebsfähigkeit entwerfen. Logging, Telemetrie, Feature Toggles und Wiederherstellungsmechanismen müssen von Anfang an eingebaut werden.
- Eine Disaster-Recovery-Strategie haben. Regelmässig proben und wo möglich automatisieren. Ausfälle werden passieren.
- Nicht-funktionale Anforderungen kontinuierlich überwachen. Zuverlässigkeit, Leistung und Sicherheit sind keine einmaligen Themen.
- SLIs, SLOs und SLAs verstehen. Sie definieren die operativen Erwartungen und Konsequenzen für Ihr System.
- SRE für hohe Verfügbarkeitsziele nutzen. Für fünf und vier Neunen bringt Site Reliability Engineering unverzichtbare Expertise.
- Bewusst Fehler einschleusen. Der höchste Reifegrad bedeutet, die Widerstandsfähigkeit des Systems proaktiv in der Produktion zu testen.