Logo GH

High Availability und SLA

High Availability und SLA

1) Begriffe und Verbindung zum Geschäft

SLI (Service Level Indicator) ist ein messbarer Indikator für den Service (z. B. Anteil erfolgreicher 2xx/3xx ≤ T-ms-Anfragen).
SLO (Service Level Objective) - SLI-Zielwert (z.B. "99. 95% der Anfragen ≤ 300 ms).
SLA (Service Level Agreement) - vertragliche Verpflichtung gegenüber dem Kunden (Strafen/Gutschriften bei Verstoß).
HA (High Availability) - architektonische und operative Maßnahmen, die die Durchführung von SLO/SLA ermöglichen.

Das Prinzip: SLA setzt auf SLO und SLO auf die beobachteten SLI. Man kann im SLA nicht versprechen, was man nicht misst.

2) „Neun“ und die Mathematik der Zugänglichkeit

Periodenverfügbarkeit = 'Betriebszeit/Gesamtzeit'. Richtlinien (pro Jahr):
FassbarkeitMax. einfach/Jahr
99. 0%≈ 3 Tage 15 h
99. 5%≈ 1 Tag 20 h
99. 9%≈ 8 h 45 m
99. 95%≈ 4 h 23 m
99. 99%≈ 52 m 34 s
99. 999%≈ 5 m 15 s

Zusammensetzung der Zugänglichkeit

Sequentielle Kette (Abhängigkeiten entlang des „roten Pfades“):'A_total = Π A_i' (jede Komponente reduziert die Summe).
Parallele Asset-Asset-Knoten:'A_total = 1 − Π (1 − A_i)'(Reserve erhöht die Summe).

3) Was genau gemessen wird (richtiger SLI)

Benutzeransicht: Erfolgreiche Abschlüsse von Schlüsseloperationen (Login, Einzahlung, Check-out) und deren Latenz p99.
Stundenkorridor: Aggregieren nach Schiebefenstern (5/30/60 min) und nach Regionen.
Ausnahmen: „Geplante Fenster“ zählen im SLO und im SLA nur, wenn es im Vertrag so steht.

Arten von SLI:
  • Verfügbarkeit: Anteil der erfolgreichen Antworten ≤ T.
  • Qualität: p95/p99 latency.
  • Composite: „Anteil der erfolgreichen Einlagen ≤ 5 Sekunden“.

4) Fehlerbudget und Verbrennungsgeschwindigkeit

Error Budget = `1 − SLO`. Für 99. 95% Monatsfenster ergibt 0. 05% Fehler/Ausfallzeiten.
Burn-Rate: Die Geschwindigkeit des Budgets (z. B. 4 × bedeutet, dass Sie in 6 Stunden das Tageslimit essen).
Richtlinie: bei schneller Verbrennung - Stop-Releases, Fokus auf Stabilisierung, Feature-Freeze.

5) HA-Architektur: vom Knoten zur Region

5. 1 Knoten/Service

N + 1: Mindestens ein redundantes Replikat (Deployment ≥ 2, PDB, Anti-Affinity).
Ressourcenisolierung: CPU/RAM/IO Grenzen, Prioritäten (PriorityClass).
Graceful shutdown/drain: Kein Abfragebruch beim Neustart.

5. 2 Zone/Region

Multi-AZ: Replikate in verschiedenen Zonen, zonenübergreifendes Balancing, unabhängige Stromversorgung/Netzwerk.
Multi-Region: Asset-Asset (schwieriger: Daten/Konsistenz) oder Asset-Liability (einfacher: über RPO).
Daten: CP für Geld/Aufträge (Quorum/RAFT), EC/AP für Caches/Schaufenster.

5. 3 Netzwerkschicht und Perimeter

L7-LB mit health-checks, retry/timeout/circuit-breaking.
GSLB/DNS/Anycast für globalen Datenverkehr, kurze TTLs.
Egress-Steuerung und ausfallsichere Kanäle zu externen PSPs/Providern.

6) Degradierung statt Sturz

Feature Kill-Switch (Feature-Flags): Nicht-kritisch ausschalten, „roter Weg“ beibehalten.
Umschalten auf vereinfachte Pfade: Synchron → Asynchron/Warteschlange, „in Bearbeitung genommen“.
Rate-Limit/Quoten: Es ist besser, den Verkehr einzuschränken, als alle fallen zu lassen.
Stale-Modi: Cache/statische Daten geben, wenn Herkunft nicht verfügbar ist.

7) Verwaltung von Abhängigkeiten

Abhängigkeitskarte (Service Map): direkt/transitiv, Kritikalität, jeweils SLO.
Anfällige Links: externer Anbieter ohne SLA - Umhüllung in Cache/Queue/Duplikat.
Bulkhead-Isolation: Verschiedene Verbindungspools/Quoten für langsame Routen.
Timeouts> Retries: Kurze Timeouts, maximal 1 Retrait für idempotente Operationen.

8) Operationen und Änderungen

Change Management: Releases über Kanarienvögel/blau-grün, SLO-Gates, automatisches Rollback.
Geplante Fenster: standardisieren - Länge, Häufigkeit, Kommunikation.
Incidents: Rollen (IC/Comms/Tech/DB), runbook 'und, Postmortems mit Korrekturmaßnahmen.
Security-Events: Bei Kompromittierung - „Panik-Modus“ (nur lesen/Token/Rotation/Sperre).

9) Beobachtbarkeit und Alarmierung

RED-Modell (Rate, Errors, Duration) für jede Route.
SLI-Dashboards: Verfügbarkeit/Latenz nach Region und Kundensegment.
Burn-rate alert: schnell (1h, 14. 4 ×), langsam (6h, 2 ×) - Signal bis zum Zusammenbruch des SLO.
Instanzen (Exemplars) - Wechselt von Metriken zu Tracks entlang der trace_id.
Synthetik: Proben von externen Punkten (Perimeter, Payment Flow).

10) Fehlertoleranztests

Spieltage: Szenarien zum Abschalten von AZ/Regionen, Degradation von DB/Caches, Ausfall externer Anbieter.
Chaos-Tools: Netzwerk-Fols (Latenz/Verlust), Kill-Pods, CPU/IO-Überlastung.
DR-Drills: Entwicklung von RTO/RPO für Tier-0 Systeme (siehe „Backups und DR“).

11) SLA-Design

Definition von „Verfügbarkeit“: Was gilt als Incident (5xx, Zeit> T, Domain-Fehler).
Berechnungsfenster: Monat/Quartal; Aufnahme/Ausschluss geplanter Arbeiten.
Kredite/Strafen: Skala (z.B. 99. 9–99. 99% - X%, darunter - Y%).
Pflichten des Kunden: Integration, Rückzüge in vertretbaren Grenzen, Grenzen.
Notifizierungen und Clim-Verfahren: Timing, Format, Evidenzbasis (Protokolle/Metriken).
Höhere Gewalt: rechtliche Formulierung und Grenzen.

Beispiel (Skizze):
  • "API-Verfügbarkeit durch SLI "erfolgreich ≤ 500 ms" nicht weniger als 99. 95% pro Kalendermonat. Geplante Fenster (bis zu 60 min/Monat, angekündigt für 48 h) sind ausgeschlossen. Bei 99. 90–99. 95% - 5% Kredit; 99. 80–99. 90% — 10%; <99. 80% — 25%.»

12) Wirtschaft der Neunen

Jede zusätzliche „Neun“ erhöht die Kosten nicht linear (Doppelregionen, Quoren, doppelte Anbieter, 24 × 7). Tiering SLO anwenden:
  • Tier-0 (Geld/Bestellungen): 99. 95–99. 99%, Multi-AZ, DR bereit.
  • Tier-1 (Hauptmerkmale): 99. 9–99. 95%, Multi-AZ.
  • Tier-2 (unkritisch): 99. 5–99. 9%, Degradation/Stopp bei Zwischenfällen erlaubt.

13) HA-Muster nach Schichten

Umfang: CDN/Kante, Multi-CDN oder GSLB, WAF, Rate-Limit.
Balancing: L7 mit outlier-ejection, timeouts/retries, sticky/consistent-hash.
Anwendungen: Horizontal Scale, Readiness/Liveness, PDB, Topology Spread.
Daten: leader + replicas, quorum für CP, L2-Cache, idempotency, PITR.
Warteschlangen: Spiegelung/Multicluster, Dedup, DLQ.
Geheimnisse/Configs: GitOps, atomare Schnappschüsse, Rollback.

14) Anti-Muster

SLA ohne Messwerkzeuge und externe Kunststoffe.
Einzelne Zone/Cluster als SPOF.
Unkontrollierte Retries → „Selbst-DDoS“.
Lange Transaktionen/Mutexen auf der heißen Spur.
„Schwere“ Migrationen/Releases ohne Kanarienvögel und Rollback-Plan.
Mangel an Runbook und Kommunikation mit Stakeholdern bei einem Vorfall.

15) Implementierung Checkliste (0-60 Tage)

0-15 Tage

Identifizieren Sie kritische benutzerdefinierte SLIs, setzen Sie SLOs nach Tier-0/1/2.
Aktivieren Sie Burn-Rate-Alerts, SLO-Dashboards und synthetische Perimeter-Inspektionen.
SPOF entfernen: ≥2 Repliken, PDB, Multi-AZ für Fronten und kritische Datenbanken.

16-40 Tage

Einführung von kanarischen Releases mit SLO-Gating und Auto-Rollback.
Abhängigkeitskarte + Quoten/Pools/Timeouts/SV für jeden „roten Weg“.
Regeln für geplante Fenster und Kommunikation, Vorlagen für Störmeldungen.

41-60 Tage

Spieletag: AZ-Ausfall, Ausfall eines externen Anbieters, „Burst“ des Verkehrs.
Neuberechnung von SLAs und tatsächlichen Credits, Veröffentlichung von Berichten an Kunden.
Überarbeitung der „Kosten der ↔ Neun“ und Verschiebung auf dem Schießstand.

16) Reifegradkennzahlen

≥ 95% der kritischen Routen haben SLI/SLO und Burn-Rate Alerts.
SLO-Fehler werden von einem Auto-Freeze-Release (Policy) begleitet.
Multi-AZ-Abdeckung Tier-0 = 100%, erfolgreiche DR-Drills ≥ 1/Quartal.
Zeit „Detektion → Mitigation“ p50 <5 min, p95 <15 min.
Die Korrelation „Release ↔ Incidents“ wird gepflegt und verkürzt (Rollback rate↓).
Öffentliche Meldung von Vorfällen/Gutschriften - innerhalb von N Werktagen.

17) Beispiele und Snippets

Burn-rate alert (Idee der Regeln):
  • Schnell: "SLO 99. 95%, Fenster 1 h, Burn ≥ 14. 4× → page on-call».
  • Langsam: „Fenster 6 h, Burn ≥ 2 × → Ticket & Überwachung“.
Envoy — circuit breaking/outlier:
yaml circuit_breakers:
thresholds:
- max_connections: 200 max_pending_requests: 100 max_requests: 1000 max_retries: 1 outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50
Kanarienvogel mit SLO-Analyse (Argo Rollouts, Idee):
yaml analysis:
templates:
- name: slo-burn metrics:
- name: error-rate successCondition: result < 0. 005 provider: prometheus
Beispielformulierung SLI:

SLI: fraction_of_good_requests = good(HTTP 2xx/3xx ≤ 500ms) / all(requests)
SLO: ≥ 99. 95% per calendar month, per region

18) Schlussfolgerung

Bei High Availability geht es nicht nur um Cluster und Repliken, sondern um eine kohärente Reihe von Architekturen, Prozessen und Metriken: klare SLI/SLOs, realistische SLAs, Neunen mit Wirtschaft, Degradation statt Fall, Zeit-/Quotendisziplin, kanarische Releases, regelmäßige Übungen und transparente Kommunikation. Machen Sie die Verfügbarkeit messbar und überschaubar - und sie wird zum Wettbewerbsvorteil, nicht zur Lotterie.

Contact

Kontakt aufnehmen

Kontaktieren Sie uns bei Fragen oder Support.Wir helfen Ihnen jederzeit gerne!

Telegram
@Gamble_GC
Integration starten

Email ist erforderlich. Telegram oder WhatsApp – optional.

Ihr Name optional
Email optional
Betreff optional
Nachricht optional
Telegram optional
@
Wenn Sie Telegram angeben – antworten wir zusätzlich dort.
WhatsApp optional
Format: +Ländercode und Nummer (z. B. +49XXXXXXXXX).

Mit dem Klicken des Buttons stimmen Sie der Datenverarbeitung zu.