Prompt Engineering für DevOps: die C.L.E.A.R.-Checkliste und eine Prompt-Bibliothek

Prompt Engineering klingt nach Buzzword, bis eine schlampig formulierte Frage zum ersten Mal eine Stunde kostet. Wenn KI fester Bestandteil der täglichen Infrastrukturarbeit ist, bekommt man auf einen vagen Prompt eine vage Antwort. Manchmal auch eine falsche, und im DevOps-Alltag kann falsch eine kaputte Pipeline oder einen zerstörerischen kubectl-Befehl bedeuten.

Die Lösung: Prompts wie Code behandeln. Versionieren, testen, wiederverwenden. Wie das aussieht, zeigen Beispiele aus der ganz normalen Ops-Arbeit.

Warum das für Ops-Leute zählt

Gedichte will niemand vom Modell. Typische Anfragen sehen so aus:

• herausfinden, warum ein Terraform-Plan fehlschlägt
• ein Bash-Skript schreiben, das nicht die Produktion plattmacht
• 10.000 Logzeilen auf zehn Stichpunkte eindampfen
• eine kryptische Kubernetes-Fehlermeldung entschlüsseln
• YAML erzeugen, das die Validierung besteht

„Garbage in, garbage out“ gilt für Prompts genauso wie für Daten. Einen guten Prompt zu schreiben ist heute eine ebenso grundlegende Fähigkeit wie der Umgang mit grep oder awk.

Der Fehler, den fast alle machen

Der übliche Prompt lautet etwa „Behebe meinen Terraform-Fehler“. Die Antwort ist dann allgemein und nutzlos, was niemanden überraschen sollte, denn das Modell weiß nicht,

• um welchen Cloud-Anbieter es geht (AWS, GCP oder Azure)
• was genau in der Fehlermeldung steht
• welche Terraform-Version läuft
• was schon ausprobiert wurde

Ohne Kontext keine brauchbare Antwort. So einfach ist das wirklich.

Eine Checkliste, die man im Kopf behält: C.L.E.A.R.

Fünf Punkte decken fast jeden guten Prompt ab.

C wie Context, also Kontext. Nennen Sie die Umgebung, etwa einen produktiven EKS-Cluster auf AWS.

L wie Limitations, also Einschränkungen. Benennen Sie die Randbedingungen, zum Beispiel einen Stateful-Pod, der nicht neu gestartet werden darf.

E wie Expected output, also erwartetes Ergebnis. Sagen Sie, welche Form die Antwort haben soll, etwa ein Einzeiler als Fix statt einer kompletten Neufassung.

A wie Actual error or data, also echter Fehler oder echte Daten. Fügen Sie das tatsächliche Log oder den Fehlertext ein.

R wie Role, also Rolle. Bitten Sie das Modell, wie ein Senior SRE bei einem Review zu antworten.

Jeder der fünf Punkte verdient einen genaueren Blick.

1. Kontext

Schwache Variante: „Warum stürzt mein Pod ab?“

Stärkere Variante: Ein Node.js-Pod auf GKE lief drei Monate problemlos und geriet direkt nach einer ConfigMap-Änderung am Vortag in einen Crash-Loop.

Jetzt kennt das Modell die Plattform, die Art der Anwendung und den wahrscheinlichen Auslöser. Der Qualitätsunterschied zwischen diesen beiden Prompts ist enorm.

2. Einschränkungen

Ihre Randbedingungen kann ein Modell nicht erraten. Sie müssen sie ausdrücklich nennen, zum Beispiel: Schlag einen Fix vor, aber der primäre Datenbankknoten darf während der Geschäftszeiten nicht neu gestartet werden.

Fehlt das, taucht in der Antwort wahrscheinlich ein lässiges „einfach neu starten“ auf. In der Produktion ist daran gar nichts lässig.

3. Erwartetes Ergebnis

Nennen Sie das gewünschte Format. Allein diese Gewohnheit spart viel Hin und Her. Ein paar nützliche Formatwünsche:

• nur der Bash-Befehl, ohne Kommentar
• Antwort als Tabelle
• der YAML-Block und sonst nichts
• die Kurzfassung, geschrieben für jemanden, der um zwei Uhr nachts debuggt

4. Echter Fehler oder echte Daten

Diesen Punkt lassen die meisten weg. Fügen Sie das Original ein.

Schwache Variante: „Meine CI-Pipeline schlägt fehl.“

Starke Variante: die exakte Fehlerausgabe aus dem Job.

Exit-Code 137 bedeutet meist, dass der Prozess wegen Speichermangels beendet wurde. Das erkennt das Modell nur, wenn der echte Fehler vor ihm liegt.

5. Rolle

Eine Rolle verändert Ton und Tiefe der Antwort. Vergleichen Sie die Bitte um eine Antwort von einem Senior SRE mit zehn Jahren Kubernetes-Erfahrung mit der Bitte um eine Erklärung für Einsteiger. Die Frage bleibt gleich, die Antworten unterscheiden sich stark, und je nach Tag kann jede davon genau die richtige sein.

Prompts, die in die Snippet-Datei gehören

Manche Prompts sollte man aufheben, sobald sie funktionieren.

Terraform-Debugging. Geben Sie die Rolle eines Senior DevOps Engineers vor, fügen Sie den Plan-Fehler ein, nennen Sie Provider (AWS) und Terraform-Version (1.7) und bitten Sie um die Ursache in einer Zeile, gefolgt vom Fix.

Sichere Automatisierungsskripte. Bitten Sie um ein Bash-Skript, das Docker-Images löscht, die älter als sieben Tage sind. Verlangen Sie einen Dry-Run-Modus als Standard und verbieten Sie jedes Löschen ohne Bestätigung.

Log-Zusammenfassungen. Übergeben Sie die Nginx-Logs und fragen Sie nach den fünf häufigsten Fehlercodes, den meistgenutzten Endpunkten und auffälligen IP-Mustern, alles in weniger als 100 Wörtern.

Incident-Postmortems. Liefern Sie rohe Notizen zum Vorfall und bitten Sie um ein sauberes Dokument mit den Abschnitten Summary, Timeline, Root Cause und Action Items.

Gewohnheiten, die nach hinten losgehen

Einige Muster führen immer wieder zu schlechten Ergebnissen:

• fünf unzusammenhängende Probleme in eine einzige Frage packen
• den Tech-Stack weglassen, obwohl Terraform, CloudFormation und Pulumi sehr unterschiedliche Antworten liefern
• die erste Antwort für bare Münze nehmen, statt mindestens einmal „warum“ zu fragen
• vergessen zu erwähnen, dass es sich um Produktion handelt, wenn es so ist
• Modellausgaben ungeprüft direkt in die Produktion übernehmen

Die letzte Gewohnheit verdient ein eigenes Warnschild. Die KI ist Co-Pilot, der Pilot bleibt ein Mensch.

Eine Prompt-Bibliothek pflegen

Teams pflegen ohnehin Skriptsammlungen und Runbooks, und eine Prompt-Bibliothek passt gut daneben. Ein einfacher Aufbau:

/prompts
  ├── terraform-debug.md
  ├── log-summary.md
  ├── incident-postmortem.md
  ├── yaml-validator.md
  └── cost-report-summary.md

Jede Datei enthält die wiederverwendbare Vorlage, Platzhalterfelder wie [ERROR], [STACK] und [ENV] und eine kurze Notiz, wann sie zum Einsatz kommt. So wird aus dem Prompt-Schreiben statt planlosem Tippen die Wahl des passenden Werkzeugs, genau wie beim Griff zum richtigen Skript aus einem Ordner.

Schwach und stark im direkten Vergleich

CI-Fehler

• Schwach: „CI ist kaputt, Hilfe“
• Stark: „GitHub Actions schlägt beim docker build-Schritt mit Exit-Code 137 fehl, vermutlich Speichermangel. Schlag einen Speicher-Fix für den Runner vor.“

Kubernetes-Problem

• Schwach: „Pod stürzt ständig ab“
• Stark: „Ein Node.js-Pod auf GKE hängt seit der gestrigen ConfigMap-Änderung im Crash-Loop. Die Logs zeigen OOMKilled. Schlag einen Fix für die Ressourcenlimits vor.“

Skript-Anfrage

• Schwach: „Schreib ein Aufräumskript“
• Stark: „Schreib ein Bash-Skript, das Docker-Images löscht, die älter als sieben Tage sind, ein Dry-Run-Flag hat und niemals automatisch löscht.“

Wo man anfängt

Prompt Engineering ist keine Magie. Es ist dieselbe Präzision, die in ein gutes Ticket oder ein klares Runbook gehört. Fangen Sie klein an, heben Sie funktionierende Prompts auf und verwenden Sie sie wieder. Behandeln Sie sie wie Code, denn inzwischen sind sie im Grunde genau das.