Aptime-Tracking

1) Warum Aptime überwachen

Aptime - Anteil der Zeit, in der der Dienst für den Benutzer verfügbar ist. Dies ist die „erste Linie“ der Beobachtbarkeit: Sofortige Erkennung von Nichtverfügbarkeit, Netzwerkdegradierung, DNS/TLS-Ausfall, Routing- oder CDN-Problemen. Bei hochbelasteten und regulierten Systemen (Fintech, iGaming) wirkt sich das Aptime direkt auf den Umsatz, die SLA-Ausführung und das Strafrisiko aus.

2) Begriffe und Formeln

Verfügbarkeit SLI: „SLI = (erfolgreiche Prüfungen/alle Prüfungen) × 100%“.
SLO: Zielverfügbarkeit pro Fenster (in der Regel 28-30 Tage), z. B. 99. 9%.
SLA: externe Verpflichtung; immer ≤ internen SLO.
MTBF/MTTR: mittlere Zeit zwischen Ausfällen/mittlere Erholungszeit.

99. 0% → ~ 432 min nicht verfügbar

99. 9% → ~ 43 min

99. 99% → ~4. 3 min

99. 999% → ~ 26 Sekunden

3) Welche Kontrollen sind erforderlich (Black Box)

Von externen Punkten (verschiedene Regionen/Anbieter) gestartet, um den Service „mit den Augen des Kunden“ zu sehen.

1. ICMP (ping) - Grundlegendes Netzwerk/Knotenverfügbarkeit. Schnell, spiegelt aber nicht den Geschäftserfolg wider.
2. TCP connect - hört der Port zu? Nützlich für Broker/DB/SMTP.
3. HTTP/HTTPS - Status-Code, Header, Größe, Umleitungen, Zeit bis zum ersten Byte.
4. TLS/Zertifikate - Ablaufdatum, Kette, Algorithmen, SNI, Protokolle.
5. DNS - A/AAAA/CNAME, NS-Gesundheit, Verteilung, DNSSEC.
6. gRPC - Anrufstatus, Deadline, Metadaten.
7. WebSocket/SSE - Handshake, Aufrechterhaltung der Verbindung, Nachricht-Echo.
8. Proxy/Routing/CDN - verschiedene PoP, Cache-Hash-Test, Geo-Varianten.
9. Transaktionale synthetische Szenarien (Klicks/Formulare): „Login → Suche → Einzahlung (Sandbox)“.
10. Heartbeat/Cron-Monitoring - der Dienst muss „pulsieren“ (Haken alle N Minuten); Kein Signal - Alarm.

• Stellen Sie die Timeouts näher an die tatsächliche UX (z. B. TTFB ≤ 300 ms, total ≤ 2 s).
• Überprüfen Sie die Content Assert (Keyword/JSON-Feld), damit „200 OK“ mit dem Fehler nicht als Erfolg gewertet wird.
• Duplizieren Sie Überprüfungen über unabhängige Anbieter und Netzwerke (Multi-Hop, verschiedene ASNs).

4) White Box und Gesundheit Service

Liveness/Readiness-Proben für den Orchestrator (Prozesse lebendig? Sind Sie bereit, Verkehr zu empfangen?).
Gesundheit Abhängigkeiten: DB, Cache, Event-Broker, externe APIs (Zahlungen/KYC/AML).
Ficha-Flaggen/Degradierung: Bei Problemen deaktivieren wir sanft nicht-kritische Pfade.

Weiße Proben ersetzen keine externen Überprüfungen: Der Dienst kann intern „gesund“ sein, steht dem Benutzer jedoch aufgrund von DNS/TLS/Route nicht zur Verfügung.

5) Geographie und Multiregionalität

Führen Sie Synthetik aus wichtigen Verkehrsregionen und in der Nähe von Anbietern kritischer Abhängigkeiten aus.
Quorum: Ein Vorfall wird aufgezeichnet, wenn ein Fehler in ≥ N Regionen (z. B. 2 von 3) auftritt, um lokale Anomalien abzuschneiden.
Schwelle nach Kohorten: separate SLI/SLOs für wichtige Segmente (Länder, VIPs, Carrier).

6) Alert-Politik (Geräuschminimum)

Multi-Region + Multi-Test: Pager nur bei vereinbartem Ausfall (z. B. HTTP und TLS gleichzeitig, ≥ 2 Regionen).
Debounce: N aufeinanderfolgende Ausfälle oder Fenster 2-3 Minuten vor dem Paging.

• L1: On-Call (Produktionsdienste).
• L2: Netzwerk/Plattform/Sicherheit in Abhängigkeit von der Fehlersignatur.
• Auto-Closing: Nach stabilen M erfolgreichen Kontrollen.
• Stille Stunden/Zugeständnisse: Für nicht-kritische Eigenleistungen - nur Tickets, kein Pager.

7) Status-Seite und Kommunikation

Öffentliche (Client) und private (interne) Statusseiten.
Automatische Vorfälle von Synthetik + manuelle Anmerkungen.
Meldungsmuster: entdeckt - identifiziert - Exposition - Workaround - ETA - gelöst - Post-Mordem.
Geplante Fenster: im Voraus ankündigen, Ausnahmen getrennt vom SLO berücksichtigen.

8) Berücksichtigung externer Abhängigkeiten

Für jeden Anbieter (Zahlungen, KYC, Mailings, CDN, Clouds) - eigene Checks aus mehreren Regionen.
Failover-Routen: Auto-Wechsel zu einem alternativen Anbieter durch Synthetik-Signal.
Separate SLOs auf Anbieterebene und integraler e2e-SLO.
SLAs mit den Anbietern aushandeln (Status-Webhooks, Support-Priorität).

9) Dashboards und Schlüssel-Widgets

Weltkarte mit Prüfstatus (nach Typ: HTTP, DNS, TLS).
Zeitlinie der Vorfälle mit Anmerkungen zu Releases/Flags.
P50/P95/P99 TTFB/TTL/Latency nach Region.
Verfügbarkeit nach Kohorten (Land/Anbieter/Gerät).
MTTR/MTBF, die Trends „Ausfallminuten“ und „Burn-Down“ des Verfügbarkeitsbudgets für den Monat.
Top Ursachen für Ausfälle (TLS-Expiry, DNS-Resolving, 5xx, Timeouts).

10) Incident-Prozess (flüchtiges Szenario)

1. Multi-Region/Multi-Type alert wird ausgelöst.
2. Der diensthabende Beamte bestätigt, schaltet den Freigabestopp ein, benachrichtigt die Eigentümer.
3. Schnelle Diagnose: DNS/TLS/CDN-Status, neueste Versionen, Fehlergraphik.
4. Bypass: Routenwechsel, Folback Content/Provider, Aktivierung des Degradierungsmodus.
5. Wiederherstellung: Überprüfung, ob Synthetik/echter Verkehr grün ist.
6. Kommunikation auf der Status-Seite; Schließung des Vorfalls.
7. RCA und Aktionselemente: Korrekturen, Tests, Alerts, Playbooks.

11) SLA/SLO Berichterstattung

Monatliche Berichte: Aptime nach Service/Region, Ausfallminuten, MTTR, Ursachen.
Vergleich mit SLA: ggf. Gutschriften/Entschädigungen.
Vierteljährliche Revue: Aktualisierung der Schwellenwerte, Verteilung von Kunststoffen, Liste der Abhängigkeiten.

12) Prüfvorlagen (Beispiel)

• Methode: „GET/healthz/public“ (ohne Geheimnisse).
• Timeout: 2 s, Retry: 1.
• Erfolg: '2xx', Überschrift 'X-App-Version' vorhanden, JSON-Feld 'Status': 'ok'.

• Laufzeit> 14 Tage, valide Kette, Protokolle' TLS 1. 2 +', korrekte SNI.

• Reaktionszeit ≤ 100ms, A/AAAA-Einträge entsprechen dem Plan, keine SERVFAIL/REFUSED.

• Webhook '/beat/{ service} 'alle 5 Minuten; keine 2 Signale hintereinander - alert L2 (Hintergrundaufgaben/ETL).

13) Checkliste Umsetzung

• Multiregionale externe Prüfungen (HTTP/TCP/DNS/TLS/Deep Scripts).
• Weiße Probe readiness/liveness für den Orchestrator.
• Trennung kritischer/unkritischer Pfade, Ficha-Fahnen der Degradation.
• Quorum und Debunce in Alerts, Eskalation und Auto-Close.
• Öffentliche und interne Statusseiten, Meldungsvorlagen.
• Separate Prüfungen und SLOs für externe Anbieter + automatischer Failover.
• Dashboards: Karte, Timeline, Perzentile, Minuten Ausfallzeit, MTTR/MTBF.
• Regelmäßige SLA/SLO-Berichte und Post-Incident-RCAs.

14) Häufige Fehler

Nur Ping/Port ohne NTTR/Inhalt - „grün“ bei tatsächlicher Nichtverfügbarkeit.
Ein Punkt der Überwachung sind falsch positive/negative Schlussfolgerungen.
Fehlende TLS/DNS-Kontrolle - plötzliche Ausfallzeiten aufgrund von Verspätungen/Fehlzeiten.
Extra Noise: Alerts für einzelne Ausfälle aus derselben Region/Überprüfungsart.
Kein Zusammenhang mit Änderungen - Anmerkungen zu Releases und Flags in Dashboards fehlen.
Nicht gemeldete Abhängigkeiten - Der Zahlungsanbieter ist gefallen und der Gesamtstatus ist „grün“.

15) Das Ergebnis

Beim Tracking eines Aptimes geht es nicht nur darum, „URLs zu picken“. Es handelt sich um ein synthetisches Inspektionssystem aus realen Regionen, vernünftige Alerts ohne Lärm, transparente Kommunikation über Statusseiten, Berücksichtigung externer Abhängigkeiten und striktes Reporting. Ein richtig aufgebautes Aptime-Monitoring reduziert die MTTR, schützt die SLA und hält die Benutzererfahrung vorhersehbar.