Operative Analysen

1) Was ist Operating Analytics und warum wird es benötigt?

Operating Analytics (Ops Analytics) ist die systemische Zusammenstellung von Signalen aus Beobachtbarkeit (Metriken/Logs/Trails), ITSM (Incidents/Challenges/Changes), CI/CD (Releases/Configs), Providern (PSP/KYC/CDN/Cloud), FinOps (Costs) und Business SLL I (Erfolg von Zahlungen, Registrierungen), verwandelt in einheitliche Schaufenster und Dashboards für die Entscheidungsfindung.

• Verringerung der MTTD/MTTR durch frühzeitige Erkennung und korrekte Zuordnung der Ursachen;
• das SLO und das Fehlerbudget unter Kontrolle zu halten;
• Verknüpfung von Änderungen → Impact (Releases/Configs → SLI/SLO/Reklamationen/Kosten);
• geben Self-Service-Analysen an Teams und Management.

2) Quellen und kanonische Datenschicht

Telemetrie: Metriken (SLI/Ressourcen), Protokolle (Sampling/PII-Revision), Traces (trace_id/span_id, Release-Tags).
ITSM/Incident Module: SEV, T0/Detected/Ack/Declared/Mitigated/Recovered Zeitstempel, RCA/CAPA.
CI/CD & Config: Versionen, Commits, Canarica/Blue-Green, Flag State, Target Configs.
Anbieter: Status/SLAs, Verzögerungen, Fehlercodes, Streckengewichte.
FinOps: Kosten nach Tags/Konten/Tenanten, $/Einheit (1k Opern.) .
DataOps: Frische der Schaufenster, DQ-Fehler, Lineage.

Das Schlüsselprinzip ist eine einheitliche Korrelation über die Bezeichner: 'service', 'region', 'tenant', 'release _ id', 'change _ id', 'incident _ id', 'provider', 'trace _ id'.

3) Einheitliches Datenmodell (vereinfachtes Framework)

dim_service(service_id, owner, tier, slo_targets…)
dim_time(ts, date, hour, tz)
dim_region(region_id, country, cloud)
dim_provider(provider_id, type, sla)
fact_sli(ts, service_id, region_id, tenant, metric, value, target, window)
fact_incident(incident_id, service_id, sev, t0, t_detected, t_ack, t_declared, t_mitigated, t_recovered, root_cause, trigger_id, burn_minutes)
fact_change(change_id, type(code    config    infra), service_id, region_id, started_at, finished_at, canary_pct, outcome(ok    rollback), annotations)
fact_cost(ts, service_id, region_id, tenant, cost_total, cost_per_1k)
fact_provider(ts, provider_id, region_id, metric(latency    error    status), value)
fact_dq(ts, dataset, freshness_min, dq_errors)

4) SLI/SLO und Geschäftsmetriken

Бизнес-SLI: `payment_success_ratio`, `signup_completion`, `deposit_latency`.
Тех-SLI: `availability`, `http_p95`, `error_rate`, `queue_depth`.
SLO-Ebene: Ziele + Burn-Rate (kurzes/langes Fenster), automatische Anmerkungen zu Verstößen.
Normalisierung: Indikatoren für 1k erfolgreiche Operationen/Benutzer/Verkehr.

5) Korrelationen und Zuschreibungen von Ursachen

Releases/Configs ↔ SLI/SLO: Anmerkungen auf Graphen; Kausalberichte (Anteil an Änderungsvorfällen; MTTR-Change-Incidents).
Anbieter ↔ Business SLI: Gewichte der Routen vs Latenz/Fehler, Beitrag jedes Anbieters zum SLO-Fehler.
Kapazität/Ressourcen ↔ Latenz: Überhitzung von Pools → Wachstum von p95 → Auswirkungen auf die Konvertierung.

6) Anomalien und Prognose

Anomalie-Detail: Saisonalität + Perzentilschwellen + Änderung der Suchfunktion (vor/nach der Veröffentlichung).
Prognose: wöchentliche/saisonale Lastmuster, Burn-Out-Prognose des Fehlerbudgets, Kostenprädiktion ($/Einheit) .
Gardrails: Alerts nur bei Quorum-Quellen (synthetic + RUM + business SLI).

7) Vitrinen und Dashboards (Referenz)

1. Executive 28d: SEV-Mix, Median MTTR/MTTD, SLO-Adherence, $/Einheit, Top-Gründe.
2. SRE Ops: SLI/SLO + burn-rate, Page Storm, Actionable %, Change Failure Rate.
3. Change Impact: Releases/Configs ↔ SLI/SLO/Reklamationen, Pullbacks und deren Wirkung.
4. Anbieter: PSP/KYC/CDN Status Linien, Auswirkungen auf Business SLI, Antwortzeiten.
5. FinOps: cost per 1k txn, logs/egress, cost anomals, recommendations (sampling, storage).
6. DataOps: Schaufensterfrische, DQ-Fehler, SLA-Pipelines, Backfill-Erfolg.

8) Datenqualität und Governance

Veranstaltungsverträge: Klare Schemata für Incidents/Releases/SLIs (Pflichtfelder, einheitliche Zeitzonen).
DQ-Checker: Vollständigkeit, Einzigartigkeit der Schlüssel, Konsistenz der Zeitlinie (t0≤detected≤ack...).
Linie: Vom Dashboard zur Quelle (traceable).
PII/Secrets: Bearbeiten/Maskieren durch Politik; WORM für evidence.
SLA Frische: Schaufenster Ops ≤ 5 min Verzögerung.

9) Betriebsanalytische Reifegradmetriken

Coverage:% der kritischen Dienste in Schaufenstern und SLO-Bordellen (Ziel ≥ 95%).
Freshness: Anteil der Widgets mit Frische ≤ 5 min (Ziel ≥ 95%).
Actionability:% der Übergänge von Dashboard zu Action (Playbook/SOP/Ticket) ≥ 90%.
Detection Coverage: ≥ 85% der Vorfälle werden durch Automatisierung erkannt.
Attributionsrate: Der Anteil der Vorfälle mit bestätigter Ursache und Auslöser ≥ 90%.
Change Impact Share: Anteil der Änderungsvorfälle (Kontrolle des Trends).
Datenqualität: DQ-Fehler/Woche → ↓ QoQ.

10) Prozess: von Daten zu Aktionen

1. Sammlung → Reinigung → Normalisierung der → Vitrine (ETL/ELT, Feature Layer für ML).
2. Erkennung/Prognose → Matrixeskalation (IC/P1/P2/Comms).
3. Aktion: Playbook/SOP, Release-Gate, Ficha-Flag, Anbieterumschaltung.
4. Evidence und AAR/RCA: Timeline, Grafiken, Release-/Log-/Trace-Links.
5. CAPA- und Produktlösungen: Priorisierung nach Burn-Minuten und $ -Impact.

11) Beispiele für Anfragen (Idee)

11. 1 Auswirkungen von Releases auf SLO (24h)

sql
SELECT r. change_id,
COUNT(i. incident_id) AS incidents,
SUM(i. burn_minutes) AS burn_total_min,
AVG(CASE WHEN i.root_cause='code' THEN 1 ELSE 0 END) AS code_ratio
FROM fact_change r
LEFT JOIN fact_incident i
ON i.trigger_id = r. change_id
WHERE r. started_at >= NOW() - INTERVAL '24 hours'
GROUP BY 1
ORDER BY burn_total_min DESC;

11. 2 Anteil der Probleme von Anbietern nach Regionen

sql
SELECT region_id, provider_id,
SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END) AS prov_inc,
COUNT() AS all_inc,
100. 0SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END)/COUNT() AS pct
FROM fact_incident
WHERE t0 >= DATE_TRUNC('month', NOW())
GROUP BY 1,2
ORDER BY pct DESC;

11. 3 Kosten pro 1k erfolgreiche Zahlungen

sql
SELECT date(ts) d,
SUM(cost_total)/NULLIF(SUM(success_payments)/1000. 0,0) AS cost_per_1k
FROM fact_cost c
JOIN biz_payments b USING (ts, service_id, region_id, tenant)
GROUP BY d ORDER BY d DESC;

12) Artefaktmuster

12. 1 Ereignisdiagramm (JSON, Fragment)

json
{
"incident_id": "2025-11-01-042",
"service": "payments-api",
"region": "eu",
"sev": "SEV-1",
"t0": "2025-11-01T12:04:00Z",
"detected": "2025-11-01T12:07:00Z",
"ack": "2025-11-01T12:09:00Z",
"declared": "2025-11-01T12:11:00Z",
"mitigated": "2025-11-01T12:24:00Z",
"recovered": "2025-11-01T12:48:00Z",
"root_cause": "provider",
"trigger_id": "chg-7842",
"burn_minutes": 18
}

12. 2 Metrikkatalog (YAML, Fragment)

yaml metric: biz. payment_success_ratio owner: team-payments type: sli target: 99. 5 windows: ["5m","1h","6h","28d"]
tags: [tier0, region:eu]
pii: false

12. 3 Executive Report Card (Abschnitte)

1) SEV mix and MTTR/MTTD trends
2) SLO adherence and burn-out risks
3) Change Impact (CFR)
4) Providers: Degradation and switchover
5) FinOps: $/unit, log anomalies/egress
6) CAPAs: Status and Deadlines

13) Werkzeuge und Architekturmuster

Data Lake + DWH: „rohe“ Schicht für Telemetrie, Schaufenster für Lösungen.
Stream-Verarbeitung: Near-Real-Time SLI/Burn-Rate, Online-Fiches für Anomalien.
Feature Store: Wiederverwendung von Fitch (Canarica, Saisonalität, Provider-Signale).
Semantic Layer/Metric Store: einheitliche Definitionen der Metriken (SLO, MTTR...).
Zugangskontrolle: RBAC/ABAC, Reihensicherheit für Tenanten/Regionen.
Katalog/Lineage: Suche, Beschreibungen, Abhängigkeiten, Besitzer.

14) Checklisten

14. 1 Ausführen der Betriebsanalyse

• Genehmigte Wörterbücher SLI/SLO, SEV, Ursachen, Änderungstypen.
• Ereignismuster und einheitliche Zeitzonen.
• Telemetrie-Konnektoren, ITSM, CI/CD, Anbieter, Abrechnung.
• Showcases: SLI/SLO, Incidents, Changes, Providers, FinOps.
• Executive/SRE/Change/Providers Dashboards sind verfügbar.
• Quorum-Alerts und Suppression für Wartungsfenster konfiguriert.

14. 2 Wöchentliche Ops-Überprüfung

• SEV-Trends, MTTR/MTTD, SLO-Fehler, Burn-Minuten.
• Change Impact und CFR, Status der Rollbacks.
• Provider-Vorfälle und Reaktionszeiten.
• FinOps: $/Einheiten, Log-/Egress-Anomalien.
• CAPA-Status, Verspätungen, Prioritäten.

15) Anti-Muster

Eine „Chart Wall“ ohne zum Handeln überzugehen.
Die Befehle haben unterschiedliche Definitionen von Metriken (keine semantische Ebene).
Fehlende Release/Window Annotationen - schwache Zuordnung der Ursachen.
Fokus auf Mittel statt p95/p99.
Keine Normalisierung pro Volumen - große Dienste „scheinen schlechter zu sein“.
PII in Logs/Vitrinen, Retentionsstörung.
Daten „stagnieren“ (> 5-10 min für Echtzeit-Widgets).

16) Umsetzungsfahrplan (4-8 Wochen)

1. Ned. 1: Vereinbarungen über das Wörterbuch der Metriken, Ereignisschemata, ID-Korrelation; Anschluss von SLI/SLO und ITSM.
2. Ned. 2: Incidents/Changes/Providers Vitrinen, Anmerkungen zu Veröffentlichungen; Executive & SRE Dashboards.
3. Ned. 3: FinOps-Ebene ($/Einheit) , Verknüpfung mit SLI; Anomalie-Objekt mit Quorum.
4. Ned. 4: Self-Service (semantische Schicht/metrischer Speicher), Katalog und Lineage.
5. Ned. 5-6: Last-/Kostenprognose, Berichte an Anbieter, CAPA-Schaufenster.
6. Ned. 7-8: Abdeckung von ≥95% Tier-0/1, SLA Frische ≤5 min, regelmäßige Ops-Bewertungen.

17) Das Ergebnis

Operating Analytics ist eine Entscheidungsmaschine: einheitliche Metrikdefinitionen, frische Vitrinen, korrekte Zuordnung der Ursachen und direkte Übergänge zu Playbooks und SOPs. In einem solchen System erkennt und erklärt das Team schnell Abweichungen, bewertet die Auswirkungen von Releases und Anbietern genau, verwaltet die Kosten und reduziert das Risiko systematisch - und die Nutzer erhalten einen stabilen Service.