GH GambleHub

High Availability и SLA

High Availability и 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).
Politik: 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 с 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 (Ficha-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/retrays, 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 Retrays → „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.