Run SheetDevOpsIncident Collaboration

ChatOps

KomplexitätMedium

ZeitOngoing

Teilnehmende2-20

FormatBoth

MaturityEstablished

Vorbedingung

Was vorher fertig sein muss

Vorher abschließenRunbook

Mindestens drei automatisierungsreife Runbooks existieren, sodass ChatOps-Befehle echte Standardablaeufe ausloesen koennen.

Ohne: Ohne Runbooks werden ChatOps-Befehle zu Ad-hoc-Skripts ohne dokumentierte Wirkung.

Vorher abschließenIncident Command

Incident-Rollen und Eskalationspfade sind definiert, sodass im Chat klar ist, wer entscheidet und wer ausfuehrt.

Ohne: Ohne klare Rollen wird der Incident-Channel zur Diskussionsrunde ohne Steuerung.

Vorbereitung

Was vor Start vorliegen muss

Materialien

Team-Chat (Slack, MS Teams, Mattermost) mit Bot-Integration; Repository fuer ChatOps-Skripte (Hubot, Lita, eigene Bots); CI/CD-Hooks; Audit-Log; Berechtigungsmatrix.

Personen / Rollen

Ein ChatOps-Maintainer als Owner des Bots; SRE/DevOps mit Skript-Verantwortung; Security-Reviewer fuer privilegierte Befehle; alle Teammitglieder als Nutzer.

Vorabinfos

Liste der Automatisierungs-Kandidaten (Deploy, Restart, Status, Rollback); Tool-Endpoints und Credentials-Strategie; Audit-Anforderungen; bekannte Compliance-Constraints.

Zeitbedarf

Initialer Aufbau 1-2 Sprints, danach kontinuierliche Erweiterung

Setup

Bot in Chat einbinden. Channel-Strategie (z. B. #ops, #incidents, #deploys). Berechtigungsmatrix pro Befehl. Audit-Log in zentrale Logging-Pipeline. Alle Befehle hinter Confirmation fuer destruktive Aktionen.

Kernfrage

Die eine Frage, die diese Methode beantwortet

Welche wiederkehrenden operativen Aktionen lassen sich sicher, nachvollziehbar und teamweit im Chat ausloesen statt in verstreuten Tools?

Ablauf

Marker: Phase

Schritt	Dauer	Aktion	Hinweis
1Phase 1: Use Cases auswaehlen	60 min	Top-10 wiederkehrender Operationen sammeln (Deploy, Restart, DB-Backup, Log-Abruf, Status-Check). Pro Use Case Frequenz, aktuelles Tooling, Risiko bewerten. Auswahl der ersten 3-5 Befehle.	Hochriskante Operationen (DB-Drop, Prod-Reset) kommen nicht in die erste Welle. ChatOps faengt mit Read-Only und Low-Risk an.
2Phase 2: Bot-Setup und Berechtigungen	2-3 Tage	Bot-Framework auswaehlen, im Chat installieren. Berechtigungs-Schema definieren (Channel- oder Role-basiert). Credentials sicher hinterlegen (Vault, Secret Manager). Audit-Log konfigurieren.	Wenn der Bot mit Admin-Tokens laeuft und jeder ihn ansprechen kann, ist das eine Backdoor. Least Privilege auch fuer Bots.
3Phase 3: Befehle implementieren	1-2 Wochen	Pro Befehl Skript schreiben, Idempotenz pruefen, Confirmation-Prompt fuer destruktive Aktionen. Help-Befehl mit Selbstdokumentation. Dry-Run-Option wo sinnvoll.	Ohne Help-Befehl wird der Bot Tribal Knowledge. Help-Texte sind erste Doku. Idempotenz verhindert, dass doppeltes Triggern Schaden anrichtet.
4Phase 4: Rollout und Schulung	1 Woche	Dry-Run mit Team. Channel-Konvention: Befehle nur in dafuer vorgesehenen Channels. Onboarding-Kurzanleitung. Audit-Channel mit allen ausgefuehrten Befehlen.	Wenn Befehle in beliebigen Channels laufen, verliert man Audit-Kontext. Strikte Channel-Bindung erleichtert spaetere Forensik.
5Phase 5: Monitoring und Erweiterung	fortlaufend	Nutzungs-Metriken: welche Befehle wie oft, Fehlerquote. Quartals-Review fuer neue Use Cases. Befehle mit hohem Risiko durch zusaetzliche Approval-Flows absichern.	Bot ohne Telemetrie ist eine Blackbox. Ohne Nutzungsdaten weiss niemand, ob Befehle wirklich genutzt oder nur dekorativ sind.

Artefakt

Was am Ende rauskommt

Form

ChatOps-Doku mit Befehlsliste, Berechtigungen, Audit-Strategie, Onboarding-Anleitung und Erweiterungsroadmap. Ergaenzt um Bot-Repository, Help-Texte und Audit-Log-Pipeline.

Tool-Alternativen

Hubot (klassisch), Lita oder Errbot
Slack-native Workflow Builder mit serverloser Funktion
Microsoft Teams Bot Framework
Mattermost-Plugins oder Rocket.Chat-Hooks
PagerDuty Rundeck oder Opsgenie Actions als Schnittstelle

Versionierung / Ownership

Bot-Code im Git mit Pull-Request-Reviews. Befehlsaenderungen erfordern Code-Review und Audit-Notiz. Berechtigungsaenderungen mit Datum und Begruendung in der Doku festhalten.

markdown

ChatOps Arbeitsvorlage

Kompakte Arbeitsvorlage für ChatOps mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

# ChatOps Arbeitsvorlage

## Ziel

Nutzt Chat als gemeinsames Interface für operative Zusammenarbeit.

## Kontext

Wann und wofür nutzen wir diese Methode?

## Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

## Durchführung

Kurze Notizen entlang des Run Sheets.

## Ergebnisartefakte
- Chat Transcript:
- Action Log:
- Automations:

## Annahmen und offene Fragen

- ...

## Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

Beispielausgabe

Konkret gefülltes Szenario

chatops-beispiel.md

markdown

## ChatOps-Setup - Plattform-Team Workspot, Mai 2026

**Bot**: Hubot, deployed in Slack-Workspace, Repo `ops/chatbot`.

**Channels**
- #ops-prod: produktive Befehle, alle Engineers + SRE.
- #ops-staging: alle Engineers, Self-Service.
- #incidents: nur waehrend aktivem Incident.

**Befehle (Welle 1)**
| Befehl | Beschreibung | Berechtigung |
|---|---|---|
| `hubot status <service>` | Health-Check eines Services | alle |
| `hubot logs <service> [--lines N]` | Letzte Logs abrufen | alle |
| `hubot deploy <service> <version>` | Production-Deploy starten | SRE + Eng-Lead |
| `hubot rollback <service>` | Rollback auf vorherige Version | SRE + Eng-Lead |
| `hubot scale <service> <replicas>` | Replicas anpassen | SRE |

**Audit**: jede Ausfuehrung wird mit User, Befehl, Argumente, Zeitstempel und Exit-Code in DataDog Logs gespeichert. Retention 1 Jahr.

**Welle 2 (geplant Q3)**: Datenbank-Snapshots, Feature-Flag-Toggles, Incident-Bridge-Bot.

**Erste Metriken (KW 18-20)**: 1.842 Befehle, davon 67% status/logs, 22% deploy, 8% scale, 3% rollback. Fehlerquote 1.4%.

Was tun

Quartals-Review aller Befehle. Ungenutzte oder unklare Befehle entfernen. Berechtigungen nachpruefen. ChatOps braucht Pflege wie Code.

Abbruchkriterien

Done-Signale, in unter einer Minute prüfbar

Keine Audit-Anbindung verfuegbar, Compliance-Vorgaben werden verletzt.

Berechtigungsmodell nicht definierbar (z. B. Bot kann keine User-Rollen abfragen).

Bot-Owner nicht benannt, Wartung diffundiert.

Use Cases sind ausschliesslich hochkritisch (Prod-Drop), kein sicherer Einstieg moeglich.

Chat-Plattform wird in 6 Monaten gewechselt, Investment laeuft ins Leere.

Team weigert sich, Channels und Konventionen einzuhalten, Audit unmoeglich.

Run Sheet durchgearbeitet?

Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.

Zum Steckbrief Weitere Methoden