Lakshya

Infrastructure & Reliability · Chapter 7 of 8

Running production

Change, incidents and toil. The three things that consume an operations team, and what to do about each.

3 min read0 diagramsAll 8 chapters

Most production pain reduces to three things, and each has a known treatment that organisations consistently under-apply.

Change is the dominant cause of outages

  • Stage everything. Canary, then a percentage, then the fleet, with an automatic halt condition. Global simultaneous deployment is a design choice, and the 2024 CrowdStrike and 2021 Fastly incidents are what it costs when it is the wrong one.
  • Make rollback the default response, not a decision requiring approval. If rolling back needs a meeting, it will not happen fast enough.
  • Test the rollback, because a rollback path nobody has exercised is a plan, not a control. This is especially true where a schema change is involved and the rollback is not symmetric.
  • Consistency matters as much as correctness. Knight Capital lost roughly $440m in 45 minutes in 2012 because a deployment reached seven of eight servers and an old flag meant something new on the eighth.

Incidents: the decisions are the content

Mitigate before you understand. Restoring service and diagnosing cause are different activities and the first has priority — rolling back without knowing why is usually correct. Declare early, because the cost of an unnecessary incident call is small and the cost of a late one is not. And separate roles: someone commanding, someone communicating, someone investigating. One person doing all three does none well.

Toil is the thing that quietly consumes the team

Toil is manual, repetitive work that scales with the system and produces no lasting value. Left alone it grows until there is no capacity for anything else, and it is invisible because it always looks like the urgent thing.

The treatment is to cap it — a stated fraction of time, commonly 50%, reserved for engineering — and to measure it honestly. And to notice that a runbook is a step on the way to automation, not a destination: a well-written runbook for a recurring task is a specification for the script that should replace it.

The question that finds an unhealthy operations team

“What fraction of your time last month was project work rather than reactive?”

If nobody has the number, that is the finding. If it is under about 20%, the team is not improving anything and the situation will compound — because the only route out is engineering time they no longer have.

← Debugging that transfersKubernetes, honestly →