SLA/OLA mit Anbietern

1) Begriffe und Grenzen

SLI ist ein messbarer Indikator (Verfügbarkeit, Latenz p99, erfolgreich verarbeitete Webhooks, RPO/RTO).
SLO - SLI-Sollwert pro Messfenster (z.B. 99. 9 %/30 Tage).
SLA ist ein rechtsverbindliches Dokument (SLO + Verfahren + Rückerstattung).
OLAs sind interne Ziele und Prozesse, die die Einhaltung von SLAs sicherstellen.
UC (Underpinning Contract) - „Substrat“ mit Dritten (Kanäle, Rechenzentren, CDN usw.).

Grenzen: Trennen Sie den Zuständigkeitsbereich des Anbieters (Cloud/WAF/CDN/Payment Gateway/KYC Provider) klar von Ihrem Bereich (Code, config, Client-Einstellungen).

2) Kritikalitätsmatrix und Modellauswahl

Die SLA-Tiefe, der Inspektionsumfang und die OLA/UC-Anforderungen hängen von der Matrix ab.

3) Metriken und Messfenster

Verfügbarkeit (Availability) - Ein Bruchteil der Zeit, in der ein Dienst Anforderungen gemäß Toleranzen ausführt.
Latenz: p95/p99 für Schlüsseloperationen; Der „langsame Erfolg“ wird berücksichtigt.
Datenzuverlässigkeit: RPO (maximal zulässiger Datenverlust) und RTO (Recovery Time).
Bandbreite/Limits: Garantierte Quoten (RPS/MBps).
Qualität der Integrationen: Anteil der gelieferten Webhooks ≤ X min, Anteil der 2xx-Antworten, Wiederholungen und Deduplizierung.
Messfenster: monatlich/gleitende 30 Tage, Ausnahmen (geplante Arbeiten) mit Grenzen.

• `Availability_ext = 1 − (Downtime_confirmed_outages / Total_minutes_in_window)`
• Wobei outage der bestätigte unzugängliche Zustand durch externe Überwachung ist, nicht nur durch die Statusseite des Anbieters.

4) SLA Inhalt (Abschnittsvorlage)

1. Gegenstand und Bereich (Dienste, Regionen, API-Versionen).
2. Definitionen (SLI/SLO, „Vorfall“, „geplante Arbeiten“, „höhere Gewalt“).
3. Service Objectives (SLO) nach Anforderungskategorie und Region.
4. Monitoring und Evidenzbasis: auf welche Weise, von wessen Sensoren, in welcher Häufigkeit.
5. Vorfälle und Eskalationen: Kanäle, Reaktionszeiten/Updates, Rollen.
6. Erstattungen: Credits/Strafen/Boni, Schwellenwerte, Formeln.
7. Sicherheit und Datenschutz: DPA, Verschlüsselung, Protokolle, Hinweise auf Verstöße.
8. Service-Änderungen: Deprecates, Benachrichtigungsfenster, Kompatibilität.
9. Kontinuität und DR: RPO/RTO, Wiederherstellungstests.
10. Audit und Compliance: Recht auf Audit, Reporting, Zertifizierungen.
11. Exit Plan: Datenexport, Zeitrahmen, Format, Migrationshilfe.
12. Gesetzliche Bestimmungen: Gerichtsstand, höhere Gewalt, Vertraulichkeit, Gültigkeit.

5) Formulierungsbeispiele (Fragmente)

5. 1 Verfügbarkeit und Messung

"Der Anbieter stellt 99. 95% Verfügbarkeit in jedem Kalendermonat. Die Verfügbarkeit wird durch externe synthetische Überwachung des Kunden aus ≥3 Regionen im Abstand von ≤1 Minuten gemessen. Die aufgezeichnete Nichtverfügbarkeit in ≥2 Regionen wird gleichzeitig als SEV2-Incident betrachtet und auf Downtime angerechnet"

5. 2 Latenz der Schlüssel-API

"p99 Antwortzeit 'POST/payments/authorize' ≤ 450 ms an 95% der Tage des Monats. Für den Anteil der Anfragen, die den Schwellenwert überschreiten, wird ein Bericht mit einer Begründungsanalyse vorgelegt"

5. 3 Vorfälle und Eskalationen

"S1: ack ≤ 15 Minuten, Aktualisierungen alle ≤ 30 Minuten, Zielwiederherstellung ≤ 2 Stunden; S2: ack ≤ 30 min, Updates ≤ 60 min; S3: nächster Arbeitstag. Kanäle: Telefon 24 × 7, Chat-Brücke, E-Mail"

5. 4 Rückerstattungen (Kredite)

If Availability_ext <99. 95% → credit 10% monthly fee
< 99. 9% → 25%
< 99. 5% → 50%

Kredite schließen andere Wege der Wiedergutmachung bei grober Fahrlässigkeit nicht aus.

5. 5 Deprecates und Kompatibilität

"Mindestens 180 Tage Benachrichtigung für Änderungen, die die Kompatibilität beeinträchtigen. Parallele Unterstützung von vN und vN + 1 für mindestens 90 Tage"

5. 6 Ausgang (Exit)

"Innerhalb von 30 Tagen nach der Kündigung stellt der Anbieter den vollständigen Export der Daten in den Formaten Parkett/JSON + Schema kostenlos zur Verfügung; zusätzliche Migrationsdienste - nach Tarif X. Die Vernichtung von Kopien wird durch eine Urkunde bestätigt"

6) OLA: interne Unterstützung für externe SLA

• Ziele: p99 Gateway ≤ 200 ms, Fehlerrate ≤ 0. 3%, DR: RPO 0, RTO 30 min.
• Verantwortung: SRE-on-call, 24 × 7; gemeinsame Dashboards und Alerts.
• Prozesse: Chaos-Smoke in Releases, Perf-Smoke auf PR, Heuristiken von Shading.
• Tore: Deployblock bei Ausfall des SLO/xaoc-Tests; obligatorisches Runbook-Update.

7) Überwachung und Nachweis

Synthetik: Externe Tests (HTTP/TCP), Benutzerpfad, „langsamer Erfolg“.
RUM: echte Benutzerüberwachung, um die Auswirkungen zu bestätigen.
Korrelation: Labels' provider', 'region', 'api _ method',' incident _ id'.
Artefakte: Screenshots/Traces/Logs, KPI-Export, Chronologie der Eskalationen.

rego package policy. sla deny["Release blocked: provider SLO risk"] {
input. release. affects_providers[_] == p input. slo. forecast[p].breach == true
}

8) Vorfälle und Interaktionen

1. SEV-Klassifizierung, Eröffnung Kriegsraum, IC-Zuordnung.

2. Benachrichtigung des Anbieters über den „heißen Kanal“, Übertragung von Artefakten.

3. Bypass-Modi/Fitch-Flags (Stale, Shading, Rate-Cap).

4. Gemeinsame Zeitlinie, Wiederherstellung.

5. Postmortem + Aktionen: Aktualisieren Sie config Limits, Schlüssel, Backup-Routen.

6. Initiierung von SLA-Krediten, Fixierung in der Abrechnung.

9) Sicherheit und DPA

DPA/Datenschutz: Rollen des Verantwortlichen/Auftragsverarbeiters, Datenkategorien, Legalitätsbasis, Verarbeitungszeiträume/-zwecke, Unterauftragsverarbeiter und deren SLAs.
Verschlüsselung: TLS1. 2+, PFS; Ruhedaten, Schlüsselmanagement (KMS/HSM), Rotation.
Audit: Zugriffsprotokolle, Benachrichtigungen über Verstöße ≤ 72 Stunden, Pentestberichte auf Anfrage.
Lokalisierung: Lagerregion, Verbot der Ausfuhr ohne Zustimmung.

10) Supply Chain und Kompatibilität

SBOM/Schwachstellen: CVSS-Schwellenwerte Politik und patch-timing (kritisiert ≤ 7 Tage, high ≤ 14).
API-Kompatibilität: Vertragstests, „Sandboxes“ und stabile Fixtures.
Anbieterwechsel: frühe Release Notes, Previews/Beta-Fenster, Abwärtskompatibilität.

11) Multiprovider und Failover

Aktiv/Aktiv: schwieriger und teurer, aber höhere Verfügbarkeit (Konsistenz beachten).
Aktiv/Passiv: Kalt-/Warmreserve, regelmäßiges DR-Training.
Abstraktionen/Adapter: Einzelvertrag, Gesundheits-/Kosten-/Kohlenstofffaktor-Routing (falls relevant).
Lizenz-/Geschäftsbedingungen: Portabilität, Einschränkung der Datenausgabe, egress-Kosten.

12) Exit-Plan und regelmäßige Proben

Daten-/Diagrammkatalog und Volumen.
SDK/API Portabilitätsszenario (mindestens second source).
Trockenausgangstest: Export/Import, Rückgewinnung, Überprüfung von Invarianten.
Gesetzliche Aufbewahrungs-/Löschfristen nach Widerruf.

13) Vertrags- und Konformitätstests

API-Proben: Positiv/Negativ, Grenzen, Fehler und Retrays.
Lieferung von Veranstaltungen/Webhooks: Signatur/Zeit/Dedup/Wiederholungen.
Perf-Bazline: p99, Durchsatz; Rücksetztests auf Release Notes des Anbieters.
Cross-Region: Die Degradierung einer Region darf das SLO nicht global stören.

14) Anti-Muster

SLA „auf der Status-Seite“ ohne externe Messungen.
Gleiche Ziele für alle Regionen/Endpunkte.
Keine Prüfungsrechte und detaillierte Ereignisprotokolle.
Es gibt kein OLA/UC → es gibt niemanden, der die externen Verpflichtungen intern erfüllt.
Ein unbestimmter Exit-Plan → die Geisel des Lieferanten.
„Bußgelder nur mit Krediten“ ohne Kündigungsrecht bei systematischen Verstößen.
Deprecates ohne Übergangsfenster.

15) Checkliste des Architekten

1. SLI/SLO für Key Flows und Regionen definiert?
2. Externe Überwachungsmethode und Evidenzbasis gewählt?
3. Hat der SLA Vorfälle, Eskalationen, geplante Arbeitsfenster und eine Ausschlussgrenze vorgeschrieben?
4. Gibt es eine Bonitätsskala/Strafen und ein Kündigungsrecht bei N Verstößen?
5. DPA/Sicherheit: Verschlüsselung, Logs, Benachrichtigungen, Subprozessoren, Lokalisierung?
6. Vertragstests und Sandkästen in der Pipeline?
7. Stellen interne OLA/UCs sicher, dass externe SLOs ausgeführt werden?
8. DR: RPO/RTOs angegeben, Training durchgeführt, Berichte?
9. Exit-Plan: Exportformate, Fristen, Praxis des „trockenen Ausgangs“?
10. Blockieren Gates in CI/CD Releases, die das Risiko einer SLA-Verletzung erhöhen?

16) Mini-Beispiele (Skizzen)

16. 1 Deploy-Gate-Richtlinie für Anbieterrisiko

yaml gate: provider-slo-risk checks:
- name: forecasted-slo-breach input: slo_forecast/providers. json deny_if: any(.providers[].breach == true)
action_on_deny: "block-release"

16. 2 Export von „Incident Evidence“

bash curl -s https://probe. example. com/export? from=2025-10-01&to=2025-10-31 \
jq '.      {region, endpoint, status, latency_ms, trace_id, ts}' > evidence. jsonl

16. 3 Webhook-Vertragstest (Pseudocode)

python evt = sign(make_event(id=uuid4(), ts=now()))
res = post(provider_url, evt)
assert res. status in (200, 202)
assert replay(provider_url, evt). status = = 200 # idempotency

Schlussfolgerung

SLA/OLA ist nicht nur ein „legales Papier“, sondern ein architektonischer Mechanismus für das Risiko- und Qualitätsmanagement. Die richtigen Metriken und Fenster, externe Überwachung, klare Incident- und Rückerstattungsverfahren, interne OLA/UCs, Gates in Pipelines, Multi-Anbieter und ein echter Exit-Plan machen die Abhängigkeit von Anbietern zu einem kontrollierten, messbaren und wirtschaftlich vorhersehbaren Teil Ihrer Plattform.