SOP:

Standardisierung der Betriebsabläufe

1) Warum es notwendig ist

SOP ist das „Betriebssystem“ des Unternehmens. Standardisierung beseitigt Chaos und „individuelle Stile“, reduziert MTTR, Alarmgeräusche und Störungsrisiken, beschleunigt Onboarding und macht Ergebnisse reproduzierbar.

• Reduzieren Sie die Handlungsvariabilität bei Vorfällen und Routinen.
• Beschleunigen Sie das Training und verbessern Sie die Qualität der Handler.
• Prozesse überprüfbar machen: Audit, Metriken, Datenverbesserungen.
• Sicherstellung der Einhaltung regulatorischer und interner Anforderungen.

2) Grundsätze der Standardisierung

1. Einheitliches Format und Terminologie. Eine Notation, eine Definition (SLO, ETA, Owner).
2. Actionable, keine Enzyklopädie. Nur überprüfbare Schritte, Erfolgs- und Rollback-Kriterien.
3. Minimale Verzweigung. Klare Wenn/Dann-Entscheidungen statt freier Darstellung.
4. Versionierung und Besitz. Jedes SOP hat einen Besitzer, eine Version und ein Revisionsdatum.
5. Integration mit Werkzeugen. Links zu Dashboards, Tickets, Ficheflags, CLI-Teams.
6. Barrierefreiheit im On-Call. Schnell suchen, lesen, mit einem Link ausführen.
7. Kontinuierliche Verbesserung. Postmortems → Aufgaben zur Aktualisierung von SOP.

3) SOP-Rahmen (Muster)

4) SOP classification

Incident: P1/P2 (critical), P3 (important).
Operational routines: releases, feature flags, database migrations, provider failover.
DR/BCP: disabling the region, restoring from backup, working offline.
Quality control/audit: revisions, readiness questionnaires, access.
Security/compliance: KYC/AML checks, log storage, privacy.

5) RACI: Ownership and Responsibility

Process    R (performer)    A (responsible)    C (consultant)    I (notify)
------------------------      ---------------      -----------------      ---------------      -------------
Create/Update SOP     Domain Owner       Head of Ops         SRE/Compliance      Teams
SLA Revision     Ops Enablement      Head of Ops        Domain leads     All
Use in an incident     On-call          Incident Manager      Domain Owner       Stakeholders

6) SOP lifecycle

1. Initiation: need from post-mortem/incident/audit.
2. Draft: by template, with specific artifacts and commands.
3. Review: Domain Owner + Head of Ops + specialized consultants.
4. Publishing: to portal/repository; annotations on dashboards.
5. Training: short training/screencast, knowledge test.
6. Application: recorded in ticket/incident.
7. Audit: by SLA revision or after a significant event.
8. Archiving: mark 'deprecated', indicate replacement.

7) Documentation as code (minimum standard)

We store SOP in Git (Markdown + YAML metadata), PR review, CI-lint.
Required fields are 'owner', 'version', 'last _ review', 'sla _ review'.
Link checker and structure validator in CI; auto-release portal after merge.
Significant changes - through changelog and notifications in the # ops channel.

8) SOP integrations

Incident Manager: Open SOP button when creating/escalating an incident.
Grafana/Observability: references from panels to relevant SOPs; release annotations.
Feature Flags/Release: canary step templates, SLO gates, rollback.
AI assistant: RAG search by SOP, TL; DR and proposals for action.
BCP/DR: DR-playbook automatically loaded by trigger.

9) SOP quality check (KPI and review)

KPI:
Coverage ≥ 90% of critical scenarios are closed by SOP.
Review SLA ≤ 180 days (share of overdue - 0).
Usage Rate ≥ 70% of overt SOP incidents.
DoD Pass Rate ≥ 90% of steps are closed with success criteria.
Broken Links = 0 (по CI).

Weekly monitoring:
Top 5 used and top 5 obsolete SOPs.
SOP communication ↔ postmortems: whether Preventive Actions have been performed.
Noisy SOPs (frequent rollback returns) are candidates for recycling.

10) Containment standards

Steps → specifics: commands/queries/parameters + expected effect in metric.
Time requirements: ETA for updates/next steps.
Escalation: clear matrix, contacts, backup channels.
Security: warnings, restrictions, PII/secrets - via vault/links.
Localization: in the on-call language (critical for distributed commands).

11) SOP examples (fragments)

SOP: Canary pause in SLO degradation

Triggers: error_budget_burn > 4x 10m, api_p99 > 1. 3×baseline 10m

• 1) Pause canary im Release-Tool (Link)
• 2) Überprüfen Sie die Panels „Change Safety“ und „API p99“
• 3) Erstellen Sie ein REG- Ticket, geben Sie baseline/window an
• DoD: p99 ≤ 1. 1 × baseline 15m, Fehler
• Rollback: vollständige Deaktivierung der Flagge, Postmortem ≤72ch

SOP: PSP Provider Feilover

Triggers: quota_usage>0. 9 OR outbound_error_rate>2×baseline 5m

• 1) PSP-Y Routing aktivieren (config/Button)
• 2) Überprüfen Sie die Umwandlung von Einlagen und p95 PSP-Y
• 3) Anmerkungen zu Grafiken, Aktualisierung in # incident-channel
• DoD: success_rate ≥ 99. 5%, p95 ≤ 300ms 10m
• Rollback: Teilweise 20% Verkehrserholung bei Stabilisierung der PSP-X

12) Checklisten

SOP Readiness Checkliste:
[] Ziel und Auslöser sind klar und messbar.
[] Es gibt Schritt-für-Schritt-Aktionen mit Befehlen/Links.
[] DoD/Rollback formuliert.
[] Eskalationen und Kontakte sind relevant.
[] Die Metadaten sind vollständig (Eigentümer, Version, last_review).
[] Link-Checker und CI-Validator durchlaufen.

Checkliste für die Anwendung des SOP (im Incident):
[] SOP wird aus dem Incident Manager/Link im Panel geöffnet.
[] Die Schritte sind abgeschlossen und die Ergebnisse stehen fest.
[] DoD erreicht/nicht - markiert.
[] Aktivitäten/Inkonsistenzen werden im Ticket erfasst.
[] SOP-Updates/-Verbesserungen werden von Aufgaben erstellt (falls erforderlich).

13) Training und Onboarding

Mini-Kurse zu wichtigen SOPs (Payments/Bets/Games/KYC).
Schattendienst mit obligatorischer Anwendung von SOP im Training.
Wöchentliche „SOP-Kliniken“: 30 Minuten Analysen/Verbesserungen.
Simulationen (Spieltage): Üben von DR- und Incident-SOPs.

14) SOP Änderungsmanagement

RFC über PR, Tags' minor/major/breaking'.
Breaking-Change - mit verpflichtendem Training und Ankündigung.
Auto-Benachrichtigungen an Domain-Besitzer und es-Coll.
Separate „SOP-Release Notes“ am Ende jeder Woche.

15) Anti-Muster

Freie Form „wie es geht“ und verschiedene Vorlagen pro Team.
SOP ohne Besitzer/Version/Revisionsdatum.
„Enzyklopädische“ Texte statt Schritt-für-Schritt-Aktionen.
Kein Rollback/DoD - nichts, um den Erfolg zu überprüfen.
Zerbrochene Links, Befehle „manuell aus dem Chat“, private „geheime“ Schritte.
Unsichtbare SOP-Änderungen ohne Aufzeichnung und Training.

16) 30/60/90 - Umsetzungsplan

30 Tage:
Genehmigen Sie die SOP-Vorlage und die Mindeststandards.
Erstellen Sie ein Repository 'ops-sop/' (docs-as-code), aktivieren Sie CI-Linter.
Digitalisierung von 10-15 kritischen SOPs (Incidents/Releases/Provider).
Verbinden Sie den Incident Manager und die Observability Panels mit SOP-Links.

60 Tage:
Erreichen Sie Coverage ≥ 70% in kritischen Szenarien.
Starten Sie wöchentliche „SOP-Kliniken“ und On-Call-Trainings.
Fügen Sie eine KI-Suche (RAG) nach SOP und TL hinzu; DR-Karten.
Geben Sie die SLA-Überprüfung (180 Tage) und die Berichterstattung über überfällige SOPs ein.

90 Tage:
Coverage ≥ 90%, Usage Rate ≥ 70% der Vorfälle.
DoD/Rollback in alle SOPs einbetten, defekte Links schließen (0).
Binden Sie SOP-KPIs an OKRs von Befehlen (MTTR, Change Failure Rate).
Halten Sie retro und notieren Sie die Verbesserungen des nächsten Quartals.

17) FAQ

F: Wie unterscheidet sich SOP von Runbook?
A: SOP ist ein standardisiertes Verfahren („wie richtig“ -Regelung). Runbook - detaillierte Anweisungen für einen bestimmten Fall/Service. Oft bezieht sich ein SOP auf ein oder mehrere Runbooks.

F: Wie viele Teile sollten in SOP sein?
A: Gerade genug, dass der Bediener in der Lage ist, Aktionen durchzuführen, ohne den Chat zu „graben“. Alles, was die Aktion nicht beeinflusst, ist in den einzelnen Referenzmaterialien.

F: Wie kann ich relevant bleiben?
A: SLA-Revisionen (≤180 Tage), automatische Erinnerungen, CI-Linter und Usage/DoD-Metrik. Jeder Abweichungsvorfall → eine Aufgabe zur Aktualisierung des SOP.