Standard Operating Procedures

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

Ein SOP (Standard Operating Procedure) ist eine formalisierte, genehmigte Schrittfolge für wiederholbare Operationen mit nachvollziehbaren Inputs/Outputs, Rollen und Qualitätskriterien.

• Reduzierung von Ausführungsvariabilität und Risiken.
• Reduzierung von MTTA/MTTR durch vorgefertigte Aktionen.
• Compliance und Audit: Reproduzierbarkeit, Rückverfolgbarkeit.
• Onboarding: Lernbeschleunigung und „shadow → solo“.

SOP ≠ Playbook: Playbook ist ein Entscheidungsbaum mit Gabeln, SOP ist eine lineare Regelung für ein bestimmtes Szenario (oder einen Zweig des Playbooks).

2) Die Prinzipien eines „guten“ SOP

Outcome-Driven: Fokus auf das Ergebnis (SLO/Business Criteria), nicht nur auf die Schritte.
Eindeutigkeit: Befehle, Parameter, erwartete Effekte und Kontrollpunkte.
Standard-Sicherheit: Gates, Limits, Backout/Rollback sind vorgeschrieben.
Minimaler Kontext: kurze Notizen + Links zu detaillierten Runbooks/Diagnosen.
Relevanz: Revue-Datum, Besitzer, Version, Gültigkeit.
Durchsetzbarkeit: JIT/JEA-Zugriffe, Vorbedingungsprüfungen, Artefaktmuster.

3) SOP-Standardstruktur (Skelett)

ID/Version/Review Date
Name and short purpose (what and why)
Scope (Services/Regions/Tenants, SEV/Risk)
Roles and Responsibilities (RACI: R/A/C/I)
Preconditions (accesses, windows, stage, reserve, artifacts)
Materials/tools (dashboards, feature flags, repos, keys)
Quality gates (SLO-gardrails, quorum of probes, alerts)
Step-by-step instruction (step → command → expected result → verification)
Branches (if X - perform Y) [minimum]
Backout/Rollback (start conditions, steps, verification)
Communications (who, when, where; message templates)
Evidence (what to save: screenshots, logs, chexums, links)
Completion (success criteria, watching who closes the ticket)
Change History (What, By Whom, and Why)

4) SOP-Katalog und Besitz

Ein einziges Repository (Docs-as-Code) mit den Tags: 'domain/ops', 'service/checkout', 'risk/high', 'provider/psp-a'.
Besitzerkarte: Team, diensthabende Kontaktpersonen, Reservebesitzer.
Relevanz SLA (z. B. Überprüfung alle ≤90 Tage oder nach einem Vorfall/Release).
Linter/SOP Validator (CI): Struktur, Referenzen, Besitzer, Revue-Zeitraum überprüfen.

5) SOP-Lebenszyklus

1. Initiierung (nach Vorfall/Übung/neuem Prozess).
2. Entwurf (Autor = Besitzer des Dienstes/Prozesses).
3. Revue (SRE/Security/Legal/Comms - pro Domain).
4. Pilot (Tabletop/Spieltag): Wir messen Zeit, Funde → Bearbeitungen.
5. Veröffentlichung (Version, Datum, Nummer, Vorlagen im CMDB/Servicekatalog).
6. Operative Anwendung (Anmerkungen in Tickets/Chats, Sammlung von Evidence).
7. Aktualisierung (nach RCA/CAPA, nach Revue-Datum, nach Architekturänderungen).
8. Archivierung/Deprection (ersetzt durch neues SOP/Playbook).

6) Verbindungen zu benachbarten Artefakten

Playbooks: SOP - der „lineare Zweig“ innerhalb des Playbooks; Link aus den Schritten.
Runbook ™ und: technische Details/Skripte im Runbook übernommen, SOP referenziert.
Richtlinien (Policy-as-Code): Zulassungstore, Retentionen, RBAC - obligatorische Links.
SLO/SLI: Erfolgskriterien und Garde-Schienen.
Eskalationsmatrix: Rollen/Timings bei fehlgeschlagener SOP-Ausführung.
Wartungsfenster: Slot/Commos Anforderungen für High-Risk SOP.

7) SOP-Leistungsmetriken

Time-to-Execute (Median/p95) - Wie lange dauert das Verfahren?
Erfolgsquote - Anteil erfolgreicher Ausführungen ohne Eskalation/Rollback.
Evidence Completeness - Fülle von Artefakten.
SLO Impact - gibt es eine Degradation während/nach dem Schritt (Burn-Minuten).
Defect Density - Bemerkungen bei Revue/Übungen für 10 SOP.
Freshness ist der Anteil von SOP mit einer Revue von ≤90 Tagen.
Adoption - Wie viele Alert/Ocon sind tatsächlich an SOP gebunden?

8) Checkliste des SOP-Autors

• Zweck und Anwendungsgrenzen sind definiert.
• Rollen, Zugriffe und Fenster - beschrieben.
• Quality Gates und SLOs - messbar, es gibt Signalquellen.
• Die Schritte sind durchsetzbar: Befehle/Skripte, erwartete Ergebnisse, Verifikation.
• Backout/Rollback und Startkriterien - übersichtlich.
• Com-Muster sind beigefügt.
• Die Evidence-Liste ist strukturiert.
• Version/Datum/Besitzer/Revue angegeben.

9) Checkliste SOP Performer

• JIT/JEA-Vorbedingungen und -Zugänge bestätigt.
• Ticket/Kriegsraum geöffnet und Anmerkungen enthalten.
• Beobachtbarkeit: Die gewünschten Dashboards/Alerts sind offen.
• Ich führe die Schritte in der Reihenfolge aus; Nach jeder Prüfung.
• Bei Verletzung der Gardrails - sofortiges Backout und Eskalation.
• Evidence ist vollständig; Abschlussprüfung SLO/Business SLI.
• Ticket geschlossen, Status-Seite/comms aktualisiert.

10) SOP-Beispiele (Fragmente)

10. 1 SOP: Canary Release Rollback (REL-ROLLBACK-01)

The goal: to return the stable version when the burn-rate is exceeded or the p99 grows.
Scope: checkout-api service (prod, EU).
Roles: Release (R), IC (A in SEV-1), P1 (R), Comms (I).
Preconditions: feature flags are ready; JEA accesses; release-annotations included.
Gates: slo. payment_success, http_p99; quorum synthetic EU/US + RUM.
Steps:
1) Freeze unrelated depleys.
2) rollback to tag v2. 3. 7 (command...) → waiting 5 minutes.
I expect: p99↓, error_rate↓, burn-rate <threshold.
3) Business SLI check (payment success, conversion) 10 min.
4) Remove the suppression of alerts; update release annotation.
Backout: if rollback does not help - escalate to IC, enable degrade-UX, consider failover.
Comms: "Rolled back; metrics stabilize; next update in 15 minutes."
Evidence: before/after screenshots, link to dashboards, command and output.
Completion: 30 min green SLOs; close the ticket; assign an RCA (if SEV-1).
Version: 1. 6 (2025-10-28)

10. 2 SOP: Geplantes DB-Upgrade (MW-DB-UPGRADE-02)

Purpose: update PostgreSQL minor without data loss.
Area: payments-db (prod EU), 02: 00-04: 00 Europe/Kyiv.
Roles: DB Lead (R), SRE (C), Service Owner (A), Comms (R clients).
Preconditions: OK backups; replica in sync; Test upgrade passed.
Gates: lag≤30s, error_rate<0. 5%, p99 <400ms, SLO green 30m.
Steps:
1) Transfer traffic to canary replica 1%→5%→25%; SLI monitoring.
2) Consistently upgrade secondary nodes → switch over → upgrade of the former primary.
3) Restore replication, check consistency.
Backout: promote stable replica; return writer; rolling back packets.
Comms: T-7/-2 days and T-60/-15 min alert; updates q = 30m during the window.
Evidence: migration logs, checksums, p95/p99 graphs.
Completion: observation 60m without burn; MW report with evidence.
Version: 2. 1 (2025-09-12)

10. 3 SOP: PSP-Anbieterwechsel (PROV-PSP-SWITCH-01)

Objective: to maintain payment success_ratio in case of PSP-A degradation.
Trigger: PSP-A red/partial status + success_ratio% ≥2 drop.
Steps:
1) Install weights: PSP-A 30%, PSP-B 70%.
2) Turn on the degrade_payments_ux; enhance retrays (within SLA).
3) Monitor fraud_rate/chargeback-risk 30m.
Backout: Regain weights at green SLI 60m.
Comms: status page (first ≤15m, cadence 30m).

10. 4 SOP: Überprüfen der Wiederherstellung eines Backups (DATA-BACKUP-RESTORE-CHECK-03)

Objective: weekly verification of recoverability.
Steps: lift from backup in isolation → hash control → consistency requests → report.
Success criterion: time-to-restore ≤ 45 min; 100% integrity.

11) Automatisierung rund um SOP

SOP Templater: Generierung eines Skeletts mit RACI/Gates/Kommoblock.
Bot-Performer: Schritte mit Checkboxen, Timer, Erinnerungen an cadence, Auto-Auswahl evidence.
Integration mit CMDB/Katalog: Der Service verfügt über eine Liste relevanter SOPs.
Telemetrie-Anmerkungen: „SOP-RUN: <ID> step N“ → schnelle Analyse.
Zulassungspolitik: Deploy/Fenster startet nur bei grünen SOP-Gates.

12) Anti-Muster

SOP ohne Besitzer/Datum Revue ist ein „totes“ Dokument.
Aufgeblähte Anleitungen ohne Erfolgskriterien und Backout.
Inkonsistente Befehle/Schlüssel - Gefahr von Fehlern und Lecks.
Verschiedene Versionen im Wiki und im Repository - die Diskrepanz der Wahrheitsquellen.
Keine Evidence - keine Bestätigung für Qualität/Compliance.
„Ein SOP für alle Fälle“ - die Durchsetzbarkeit geht verloren.

13) Roadmap für die Umsetzung (4-6 Wochen)

1. Ned. 1: Genehmigen Sie die SOP-Vorlage, den Linter und den Katalog; Wählen Sie die Top-10-Szenarien.
2. Ned. 2: Schreiben Sie SOP für Releases/Rollback/Provider/Backups; Tabletop-Piloten.
3. Ned. 3: ChatOps-Bot und Telemetrieanmerkungen verbinden; Alerts mit SOP verknüpfen.
4. Ned. 4: vierteljährlicher Revue-Zeitplan; Geben Sie Freshness/Success Rate-Metriken ein.
5. Ned. 5-6: 90% der kritischen Operationen abdecken; DR/Security-SOP; die Erfassung von evidence zu automatisieren.

14) Das Ergebnis

SOP macht Operationen vorhersehbar und überprüfbar: einheitliche Qualitätstore, detaillierte Schritte, explizite Rollen und Reversibilität. In Verbindung mit Playbooks, Politikern, SLOs und Automatisierung wird daraus eine zuverlässige Produktionslinie - schnelle Reaktionen, minimales Risiko und nachvollziehbare Verantwortung.