Zuverlässigkeitstechnik

1) Was ist SRE und warum wird es benötigt

Zuverlässigkeitstechnik (Site Reliability Engineering, SRE) ist eine Disziplin an der Schnittstelle von Entwicklung und Betrieb, die Zuverlässigkeit in ein messbares Produktattribut verwandelt. SRE verbindet User Experience Metrics (SLI), Quality Objectives (SLO), Error Budgets, Automatisierung und Managed Change, um schneller Werte zu liefern, ohne an Nachhaltigkeit zu verlieren.

Die Hauptziele sind: vorhersehbare UX, schnelle Releases, minimale Ausfallzeiten und kontrollierte Betriebskosten.

2) Grundsätze der SRE

Zuverlässigkeit als Fich. Priorisiert bis zu den Grenzen, die durch SLOs und Geschäftsziele festgelegt werden.
Das Fehlerbudget steuert die Änderungsrate. Wenn das Budget verbrannt wird, liegt der Fokus auf Stabilität.
Automatisierung> Manuelle Operationen. Jede wiederholbare Aufgabe ist ein Skript/Operator/Pipeline.
Messbarkeit. Nur was gemessen wird (SLI/SLO), kann verbessert werden.
Just Culture. Post-Mortems ohne Vorwürfe, Fokus auf systemische Ursachen.
Shift-left. Qualität, Sicherheit, Tests und Beobachtbarkeit gehören zum Entwicklungszyklus.

3) Organisation und Rollen

SRE-Team der Plattform: allgemeine Tools, Richtlinien, Pipelines, GitOps, Dienstverzeichnisse.
Embedded SRE (embedded): Arbeiten Sie neben dem Produktteam, gemeinsame Ziele für SLO.
Bereitschaftsdienst (On-Call): Rotation, Belastungsgrenzen, Ausgleich, Training.
RACI: Service Owner, SLO Owner, IC bei Vorfällen, Comms Lead, Scribe.

4) SLI/SLO und Fehlerbudget (Produktverknüpfung)

SLI: Verfügbarkeit, Latenz, Erfolg des Geschäftsbetriebs, Relevanz der Daten.
SLO: Ziele für Fenster 28-30 Tage + Ausnahmen.
Error Budget = 1 − SLO. Richtlinien: Veröffentlichungen, Experimente, Kanarienvögel und Fichi werden durch die tatsächliche Burn-Rate geregelt.
Gestaltung nach Kohorten: Regionen, Anbieter, VIP-Segmente - individuelle SLOs, um keine Auffälligkeiten zu verlieren.

5) Standardbeobachtbarkeit

Metriken: Erfolg/Fehler, Perzentile p50/p95/p99, Sättigung (CPU/mem/IO/conn).
Logs: strukturiert, mit Korrelation von Anfragen/Releases/Flags.
Tracing: End-to-End-Karte von Verzögerungen und Fehlern, Hot-Pfade.
Synthetics + RUM: externe Tests und echte Kundentelemetrie.
SLO Dashboards: Budget Burn-Down, Release Annotationen, Kanarienvogel, Anbieter.

6) Änderungs- und Freigabemanagement

CI/CD Pipeline: deterministische Assemblies, Signatur von Artefakten, Sicherheitsscans, Vertragstests.
Progressive Strategien: canary/blue-green/shadow; Ficha-Flaggen mit Lebenszyklus.
Gate's Qualitäten: Policy-as-Code, SLO-Guardrails, Auto-Rollback bei Degradation.
GitOps: Konfigurationen/Richtlinien als Code, Promotion am Mittwoch, Audit.

7) Vorfälle und Post-Mortems

SEV/P-Level Deklaration, IC wird sofort zugewiesen, Release-Freeze bei SEV-1 +.
Burn-Rate-Alerts: kurze und lange Fenster, Quorum nach Region und Probentyp.
Playbooks: Pullbacks, Degradierungen, Failover der Anbieter, Limits/Retrays.
RCA und CAPA: Fakten, Kausalität, messbare Handlungen, Kontrollpunkte (D + 14/D + 30).
Wissenskatalog: Wir nutzen Vorlagen und Lektionen neu.

8) Zuverlässigkeitsprüfung

Vertragstests und verbrauchergetriebene Verträge für Microservices.
Die nagrusotschnyje Profile nach den realen Mustern, die Prüfung der r99/Pause die GC/Schwänze der Reihen.
Chaos/Resilienz-Fälle: Abschaltung von Abhängigkeiten, Netzwerk, Latenz; Spieltage und DR-Übungen.
DB-Migrationen: expand→migrate→contract, Reversibilität, Kompatibilitätstests der beiden Versionen.

9) Kapazitäts- und Kostenmanagement (FinOps)

Capacity Units und Headroom auf kritischen Pfaden.
HPA/VPA/KEDA nach benutzerdefinierten Metriken und Warteschlangenverzögerungen.
Multi-Anbieter: Quoten, SLO/Latenz-Routing, Auto-Failover.
Unit-economics: $/1k Anfragen, $/erfolgreiche Transaktion; Optimierung von Caches, Logs, egress.

10) Sicherheit als Teil der Zuverlässigkeit

SAST/DAST/SCA, Suche nach Geheimnissen, SBOM, Signieren von Bildern.
mTLS und Zugriffsrichtlinien (OPA/ABAC); Mindestprivilegien.
Schlüssel-/Zertifikatsrotation, Terminkontrolle, Ablauftestszenarien.
Sicherheitsvorfälle - separate Playbooks, Forensics, Hinweise von Aufsichtsbehörden.

11) Kultur und Prozesse

SLO-Bewertungen: wöchentlich/monatlich, Schuldenpriorisierung über „lila Fich“.
Training und Simulationen: On-Call-Trainings, Incident-Proben, Chaos-Tage.
Einheitliche Standards: Checklisten für die Bereitschaft zur Prod, SLA-Kommunikation, Post-Mortem-Format.
Alert-Ermüdungsindikatoren: Lärm ≤ Zielschwelle, regelmäßiges Tuning.

12) Reifegradmetriken der SRE-Funktion

DORA-Metriken: Deployrate, Lead Time, MTTR, Change-Failure-Rate.
SLO-Ausführung: Anteil der Dienste im grünen Bereich, Burn-Rate-Trend.
Alert-Hygiene:% der Paging-Aktivitäten, Median der Alert/Schicht, Anteil der falschen.
RCA/CAPA: termingerechte Ausführung, Anteil systemischer (nicht persönlicher) Ursachen, Reopen-Rate.
Kosten: $/SLO-Punkt, $/1k Anfragen, Auto-Scale-Effizienz.

13) Checkliste „Servicebereitschaft für Prod“

• SLI/SLO, SLO-Besitzer und Beobachtungsfenster sind definiert.
• Dashboards und Burn-Rate-Alerts sind eingerichtet, es gibt externe Kunststoffe.
• Pipeline: Signaturen/Scans, Vertrags-/Integrationstests, Kanarienvogel/Flaggen, Auto-Rollback.
• OBD-Migrationen sind reversibel, Lastprofile decken Spitzen ab.
• Playbooks der Vorfälle und Kontakte der Anbieter; Status-Seite.
• Kapazität Hauptraum bestätigt; HPA/KEDA und Anbieterquoten geprüft.
• Confighi und Politiker - in Git, mittwochs Promotion, Audit inklusive.
• Sicherheit: Geheimnisse außerhalb des Codes, mTLS/Rotation, TLS Timing unter Kontrolle.

14) Anti-Muster

«99. 999% oder nichts" - unerreichbare Ziele → ewige rote Burn-Rate.
Releases ohne Kanarienvögel und Fitch-Flaggen → große Explosionen.
Ein Überwachungspunkt → Fehlalarme und Auslassungen.
Manuelle Config-Wechsel in der Produktion → Drift und Ungeprüftheit.
Post-Mortems ohne CAPA → wiederkehrende Vorfälle.
SRE als „Feuerwehrleute“ ohne das Recht, die Architektur zu ändern → die Schulden werden nicht geschlossen.

15) SRE Implementation Roadmap (Beispiel für 3-6 Monate)

1. Monat 1: Bestandsaufnahme der Dienste und kritischen Pfade; SLI/SLO-Entwürfe; Basis Dashboards und Burn-Rate Alerts; Start on-call.
2. Monat 2: Kanarienvögel/Fähnchen-Flaggen, Auto-Rollbacks; GitOps von Config; Playbook-Verzeichnis der Vorfälle; Status-Seite.
3. Monat 3: Vertragstests, Lastprofile, DB-Migrationen nach dem Expand/Contract-Schema; die ersten Spieltage.
4. Monat 4-6: Multi-Provider-Routen, DR-Übungen, Kostenoptimierung, Reifegradmetriken, KPIs für Teams.

16) Das Ergebnis

SRE ist das Betriebssystem der Entwicklung: transparente Qualitätsziele (SLO), beherrschbare Änderungsrate (Fehlerbudget), Automatisierung und Disziplin von Vorfällen, Nachhaltigkeitstests und bewusste Kosten. Mit diesem Ansatz werden Releases zur Routine und Zuverlässigkeit zum Wettbewerbsvorteil.