Prozessdokumentation und SOPs
Stell dir vor: 3 Uhr nachts klingelt das Telefon des Bereitschafts-Operators – das ERP ist down. Er schaut auf das Monitoring, sieht Disk-Voll auf dem DB-Server. Was jetzt? Wenn er ein Runbook hat, das die Schritte für genau diese Situation Schritt für Schritt aufführt, kann er es lösen – auch wenn er bei diesem Server zum ersten Mal eingreift. Ohne Runbook ruft er den nächsten Spezialisten aus dem Schlaf, hofft auf Wissen und macht Stress. Genau hier kommen SOPs (Standard Operating Procedures) und Runbooks ins Spiel: Schritt-für-Schritt-Anleitungen für wiederkehrende Aufgaben. Diese Lektion zeigt dir die Anatomie einer SOP, ein vollständiges Runbook-Beispiel (Disk-Voll-Behebung), die RACI-Matrix für klare Rollen-Zuordnung, kurze BPMN-Grundlagen für komplexere Prozesse und die typischen Fehler. Wer Prozesse sauber dokumentiert, gewinnt vor allem in einer Sache: Wiederholbarkeit unabhängig von der Person.
1) SOP vs. Runbook vs. Prozess – die Begriffe
Die Begriffe werden oft vermischt, gemeint ist Ähnliches:
| Begriff | Bedeutung | Beispiel |
|---|---|---|
| SOP (Standard Operating Procedure) | Standardisierte Anleitung für wiederkehrende Aufgaben. Oft mit Verantwortlichkeiten. | „Neuen Mitarbeiter onboarden" |
| Runbook | Operatives „Was-tun-bei-X"-Dokument. Fokus auf Störungen und Reaktion. | „Mail-Queue läuft voll" |
| Prozess | Ablauf-Definition auf höherer Ebene, organisations-übergreifend. | „Change-Management-Prozess" |
| Workflow | Technische Umsetzung eines Prozesses in einem Tool. | „Ticket-Workflow in JIRA" |
| Checkliste | Vereinfachte SOP, nur die Punkte ohne ausführliche Erklärung. | „Pre-Deployment-Check" |
2) Anatomie eines Runbooks – Beispiel „Disk voll"
Realistisches Runbook für eine häufige Operations-Aufgabe:
ssh ops-user@<hostname>Hostname aus Alert übernehmen. Bei Verbindungsproblem: RB-OPS-001 (Connectivity-Check) abarbeiten.
df -hIdentifiziere das volle Filesystem. Häufige Kandidaten:
/, /var, /home, /data.du -h --max-depth=1 /var | sort -h | tail -10Tiefer durchgehen:
du -h --max-depth=1 /var/log• Log-Files überproportional groß → Schritt 5
• Anwendungsdaten/DB voll → Schritt 7
• Tmp-Files (
/tmp, /var/tmp) voll → Schritt 6ls -lh /var/log/*.log*sudo journalctl --vacuum-time=7dsudo find /var/log -name "*.gz" -mtime +30 -deleteVorsicht: keine aktiven Logs löschen (immer mit
-mtime +X filtern).sudo find /tmp -type f -atime +14 -deleteSchritt nur ausführen, wenn klar ist, dass Tmp-Daten nicht aktiv genutzt werden.
Eigenmächtiges Löschen von Anwendungsdaten verboten. Service-Owner per On-Call-Kette informieren. Bis dahin: Quota-Limits oder Throttling prüfen.
df -hBelegung sollte unter Schwellwert sein. Wenn nicht: Schritte wiederholen oder Disk vergrößern (Schritt 9).
Erfordert L2-Genehmigung und ggf. Change Request. Verfahren: RB-OPS-022 (Disk-Resize).
Im Ticket festhalten: Ursache, Lösung, ausgeführte Schritte, Verbrauchsstand vorher/nachher.
Bei wiederkehrendem Problem: Problem-Ticket erstellen, nicht nur Incident.
NIE in Anwendungs-Daten-Verzeichnissen Dateien löschen. NIE
rm -rf ohne ausdrückliche Bestätigung. Bei Unklarheit immer L2 fragen.3) Pflichtfelder einer SOP
Egal ob Runbook oder Prozess-SOP, diese Felder gehören rein:
| Feld | Inhalt |
|---|---|
| ID + Titel | Eindeutige Kennung (z. B. RB-OPS-014) und sprechender Titel. |
| Version + Datum | Versionsnummer und letztes Aktualisierungs-Datum. |
| Trigger / Auslöser | Wann wird die SOP angewendet? Alert? Anfrage? |
| Verantwortliche Rolle | Wer macht's? (L1, L2, Service Desk, ...). |
| Voraussetzungen | Zugriffsrechte, Tools, Wissen, das vor Beginn vorhanden sein muss. |
| Schritte (nummeriert) | Klar formulierte Aktionen, mit Tool/Befehl/Eingabe. |
| Erwartetes Ergebnis | Wie sieht „Erfolg" aus? Was ist zu prüfen? |
| Eskalation | Was tun, wenn die SOP nicht zum Ziel führt? Wer ist Next Level? |
| Risiken / Warnungen | Gefährliche Punkte (Daten-Verlust, Service-Stop). |
| Related Documents | Verlinkte SOPs, Runbooks, Service-Steckbriefe. |
4) RACI-Matrix – wer ist für was verantwortlich?
Bei komplexeren Prozessen mit mehreren Beteiligten braucht es Klarheit. Die RACI-Matrix definiert pro Aufgabe vier Rollen: Responsible (macht's), Accountable (verantwortet's), Consulted (wird gefragt), Informed (wird informiert).
5) BPMN-Grundlagen für komplexere Prozesse
BPMN (Business Process Model and Notation) ist der Standard zur Modellierung von Geschäftsprozessen. Ein BPMN-Diagramm zeigt grafisch, wer was wann macht. Wichtigste Elemente:
6) Wo SOPs leben sollten
Die beste SOP nützt nichts, wenn man sie nicht findet. Aufbewahrungs-Strategien:
- Im Wiki, am Service verlinkt: der Service-Steckbrief verlinkt zu „Standard-Aufgaben" mit jeweils SOP-Link. Mehr in Wiki-Systeme.
- Aus dem Alert heraus: Monitoring-System (z. B. Zabbix/Prometheus) verlinkt im Alert auf das passende Runbook. Direkt klickbar.
- Aus dem Ticket heraus: JIRA/ServiceNow zeigt bei einem Ticket-Typ vorgeschlagene Runbooks. Operator-Tool-Integration.
- Print-Backup: kritische Notfall-SOPs ausgedruckt im Serverraum – wenn die IT komplett down ist, hat man wenigstens Papier.
7) Pflege und Lebenszyklus
SOPs verschimmeln, wenn niemand sie aktuell hält:
- Owner pro SOP: klare Verantwortlichkeit für Aktualität.
- Review-Intervall: jährlich oder bei Änderung des unterliegenden Systems.
- Test-Ausführung: kritische SOPs (DR, Backup-Restore) regelmäßig in Drills üben – wenn Realität abweicht, SOP nachziehen.
- Verfalldatum: wenn 12 Monate nicht angepasst, automatisch markieren „Review fällig".
- Feedback-Loop: Operator, die SOP nutzen, melden Unstimmigkeiten direkt zurück.
8) Tools für Prozess-Doku
| Tool | Fokus |
|---|---|
| Confluence / Wiki.js / BookStack | SOPs als Wiki-Seiten mit Templates |
| JIRA / ServiceNow Workflows | Prozesse als ausführbare Workflows mit Genehmigungs-Schritten |
| Camunda / Activiti | BPMN-Engine, echte Prozess-Ausführung mit Tool-Integration |
| draw.io / Lucidchart / bpmn.io | BPMN-Diagramme zeichnen |
| Ansible-Playbooks | Automatisierungs-SOP als Code (selbst-dokumentierend) |
| Runbook in Markdown + Git | Versioniert, reviewbar, ausführbar mit AnsibleRunner / Rundeck |
9) Antipatterns
- SOP-Friedhof. Hunderte SOPs angelegt, keine wird aktuell gehalten. Lösung: weniger, dafür gepflegte.
- SOP zu allgemein. „Server prüfen und beheben" – kein Schritt-für-Schritt-Wert. Lösung: konkrete Befehle, konkrete Erwartung.
- SOP zu detailliert. Jeder Mausklick dokumentiert – wartungsaufwändig, veraltet schnell. Lösung: nur kritische/nicht-intuitive Schritte detaillieren.
- SOP ohne Owner. Niemand fühlt sich verantwortlich, niemand aktualisiert. Lösung: Single Person als Owner.
- RACI mit mehreren A. Niemand entscheidet, alle blockieren sich gegenseitig. Lösung: pro Aufgabe genau ein A.
- RACI mit keinem A. Aufgabe fällt durchs Raster. Lösung: pro Aufgabe genau ein A.
- BPMN-Notation falsch. Rechtecke statt Rauten für Entscheidungen, Pfeile ohne Bedeutung – Diagramm wird unleserlich. Lösung: BPMN-Standard befolgen.
- SOP nicht verlinkt im Alert. Operator weiß nicht, dass sie existiert. Lösung: Runbook-URL ins Alert-Template.
- SOP nie getestet. Bei erstem Ernstfall stellt sich heraus, dass Schritt 4 nicht funktioniert. Lösung: DR-Drills mit Test-Ausführung.
- SOP in Word. Nicht durchsuchbar, kein Versions-Hub. Lösung: Wiki oder Markdown in Git.
Zusammenfassung
SOPs und Runbooks sind Schritt-für-Schritt-Anleitungen für wiederkehrende Aufgaben – Schlüssel zur Wiederholbarkeit unabhängig von der ausführenden Person. Pflichtfelder: ID, Trigger, verantwortliche Rolle, nummerierte Schritte, erwartetes Ergebnis, Eskalation, Risiken. Bei mehreren Beteiligten regelt eine RACI-Matrix die Verantwortlichkeiten – genau ein A pro Aufgabe, sonst entscheidet niemand. BPMN modelliert komplexere Prozesse mit Standardsymbolen. Runbooks sollten direkt aus Alert/Ticket verlinkt und regelmäßig getestet sein – ungeprüfte SOPs sind im Ernstfall wertlos.
Verwandte Lektionen: Betriebshandbuch · Wiki-Systeme · Incident Management · und mehrWeitere relevante LektionenÜbergabeprotokollVeränderungsprozesseLeistungserbringung abstimmenTicketsystemeChange ManagementAnsibleMonitoring-Konzept