Prompt writing basics for IT ops engineers: clear instructions, context, examples and output formats

A good prompt reads like a good ticket: what you need, the context, the constraints, and what "done" looks like. The model cannot ask you clarifying questions unless you invite it to.

#The five parts of a useful prompt

#Before and after

Weak:

why is my server slow

Better:

You are helping an on-call engineer. A RHEL 9 VM running PostgreSQL 16 became slow 20 minutes ago.
Nothing was deployed. Output of top and iostat is below.
1. List the two most likely causes, with the evidence from the output for each.
2. Give up to 5 read-only commands to confirm, in order.
Do not suggest restarts yet.

<top output>
...
</top output>
<iostat output>
...
</iostat output>

Wrapping pasted material in tags (or triple backticks) shows the model where context starts and ends.

#Ask for structure

Return JSON only, with this shape:
{"severity": "sev1|sev2|sev3", "component": "string", "summary": "max 20 words", "next_steps": ["..."]}

Many APIs also offer a structured output or JSON mode that enforces a schema; use it in automation.

#Give examples (few-shot)

Classify each alert as NOISE, INVESTIGATE or PAGE.

Example: "CPU 82% for 2 minutes on build agent" -> NOISE
Example: "Replication lag 900 s on orders-db replica" -> INVESTIGATE
Example: "Primary database unreachable from all app servers" -> PAGE

Alert: "Disk 96% on /var/lib/mysql on db-prod-02"

Two to five good examples usually beat a long list of rules.

#Let it think, then answer

For multi-step reasoning, ask for the steps before the conclusion:

Work through the timeline step by step, then give your conclusion on the last line starting with "Root cause:".

Reasoning-focused models do this internally; for them, a clear task and constraints matter more than "think step by step".

#Useful prompts for ops work

Log triage

Below are application logs from the 10 minutes before an outage. Group errors by type, count them,
and identify the first error that appears before the others. Quote the exact log lines you rely on.

Runbook draft

Write a runbook for "Azure VM disk full". Sections: Symptoms, Checks (read-only first), Fix, Rollback,
Prevent it next time. Use az CLI and bash commands. Mark any command that deletes data with WARNING.

Change summary for a CAB

Summarise this pull request for a change advisory board in under 120 words: what changes, risk,
rollback plan, and how we will verify success. Plain language, no marketing tone.

Explain an unfamiliar config

Explain this nginx config block line by line for someone new to nginx. Flag anything insecure.

Turn notes into a post-incident timeline

Turn these chat messages into a timeline table with columns Time (UTC), Event, Who. Keep facts only;
do not guess missing times.

#Safety rules for ops prompts

Caution

Never paste passwords, keys, tokens, connection strings or customer personal data into an assistant your organisation has not approved for that data. Redact first: password=****, 10.x.x.x, customer-123.

• Treat suggested commands as a draft. Read every command before running it, especially rm, DROP, DELETE, kubectl delete, terraform destroy.
• Ask for read-only diagnostics first, changes second.
• If an answer cites a flag or setting you do not recognise, check the vendor documentation; models can invent plausible-looking options.
• Keep a human decision on anything that changes production.

#When results are poor

#Save what works

Keep good prompts in a shared, versioned file (or your team's prompt library) with an example input and output. Reuse beats rewriting from memory during an incident.

#Prevent it next time

• Build a small library of team prompts for common tasks.
• Agree which assistants are approved for which data classifications.
• Review AI-drafted runbooks like any other change before publishing.