{"id":8451,"date":"2026-11-15T18:10:00","date_gmt":"2026-11-15T18:10:00","guid":{"rendered":"https:\/\/www.devopsconsulting.in\/blog\/?p=8451"},"modified":"2026-11-17T13:10:00","modified_gmt":"2026-11-17T13:10:00","slug":"incidentops-rollout-steps-client-teams","status":"publish","type":"post","link":"https:\/\/www.devopsconsulting.in\/blog\/incidentops-rollout-steps-client-teams\/","title":{"rendered":"Rolling Out IncidentOps for a Client in Eight Steps"},"content":{"rendered":"

Clients rarely ask a consultant to “install IncidentOps”. They ask why the last outage took a whole afternoon, or why three managers were shouting in the same chat. The fix is a short, ordered rollout, and this guide lays it out as eight steps you can carry into an engagement. It assumes a client with a few services, an informal on-call habit and no written severity policy.<\/p>\n

Throughout, the framing comes from the Ops Atlas entry covering IncidentOps<\/a>, which treats the name as an informal alias for incident management. Take what is useful and ignore the label if it irritates the client.<\/p>\n

Step 1: size the client before you design anything<\/h2>\n

The Atlas offers a tiered view that saves you from over-engineering. Tier 0 is ticket handling only. Tier 1 adds one rota and one template. Tier 2 brings in a commander, a communications lead and a status page, and is justified when incidents regularly cross team lines or when two or more serious ones land in a month. Tier 3 adds a deputy, liaisons and sub-teams, which makes sense only when more than five responders routinely pile in.<\/p>\n

Count the client’s incidents over the last quarter, note how many teams each touched, and pick the tier. Most small clients land on Tier 1 or 2. Write that decision in the first page of your report.<\/p>\n

Step 2: write the severity policy in plain English<\/h2>\n

Use three or four levels. For each, state one observable test, such as “customers cannot pay” or “one internal tool is slow”. Add the declaration criteria that apply to everyone: another team is needed, customers notice, or the problem has survived roughly an hour of effort. The point of writing them down is that nobody should have to argue about whether to raise the alarm at two in the morning.<\/p>\n

Step 3: fix the rota maths<\/h2>\n

This is the step clients skip and later regret. The Atlas works through an example: six engineers covering a round-the-clock rota with two slots each week would carry roughly a third of their time on call, which exceeds the quarter-of-time ceiling cited from Google’s practice. Staffing that rota sustainably needs about eight people. If the client has six, the answer is fewer slots, a follow-the-sun arrangement or a smaller scope, not heroics.<\/p>\n

Define the rota in code where you can. If the client uses a paging vendor with a Terraform provider, keep the schedule in a repository so changes get reviewed. One warning from the source belongs in your handover notes: marking a variable as sensitive only hides it from plan output, and the stored state file and raw outputs still reveal the integration routing keys. Use encrypted remote state.<\/p>\n

Step 4: hand out role cards<\/h2>\n

Create one-page cards for the commander, the operations lead, the communications lead and the scribe, plus an optional deputy. State each person’s single job in a sentence. The commander coordinates and does not fix. The operations group is the only one that changes production. The communications lead posts on schedule. Make clear that these are hats worn for the duration of an incident, not job titles.<\/p>\n