Change classes and blast radius - sizing the process to the change

Change processes fail in two directions. Too heavy, and everyone routes around it: changes get relabelled, batched into one enormous window, or performed as “just a config tweak” that nobody records. Too light, and a two-character edit takes the fleet offline on a Friday afternoon.

The fix is not a better form. It is classification: deciding, up front and by explicit criteria, how much process this particular change has earned.

The three classes

Almost every change management framework in use converges on the same three, and the names matter less than the criteria.

Standard. Pre-approved, pre-authorised, and executed without a new review each time. A change qualifies as standard only when it is repeated often, has a documented and rehearsed procedure, has a proven rollback, and has a history of going well. Rotating a log, extending an LVM volume that has free extents behind it, adding a monitoring target, restarting a stateless worker.

The value of the class is that it removes friction from the changes that were never the problem, which is what buys the organisation’s patience for the ones that are.

Normal. Reviewed and scheduled before execution. This is the default and most changes live here: package upgrades, configuration changes, adding a node, a firewall rule, a certificate rotation.

Emergency. Executed before the full review because the cost of waiting exceeds the risk of proceeding. A live incident, an actively exploited vulnerability, an imminent certificate expiry that will cause an outage.

Emergency is a statement about the clock, not about difficulty or importance. “This is urgent because the project is late” is a normal change with a bad schedule.

Blast radius is not diff size

The instinct is to size risk by how much changed. It is a poor predictor. The largest outages in most organisations come from one-line changes, because a one-line change is what people approve without reading.

Blast radius has four dimensions, and you estimate each one before deciding how much process the change needs.

1. Reach: how many hosts, services or tenants the change touches at once
2. Dependents: what else fails if this fails, including things that merely start slower
3. Reversibility: how long it takes to get back, and whether the path back has been tested
4. Detectability: how long before you would know it went wrong

Reversibility dominates. A change that reaches the whole fleet but can be reverted in ninety seconds is often safer than a change to one host that cannot be reverted at all.

The properties that make a small change dangerous

Score a change high regardless of its size if it has any of these.

The fstab row deserves its place. A bad line does nothing until the host reboots, and by then the change is old and nobody’s first hypothesis. Validate it while you still have a running system.

$ sudo findmnt --verify --verbose

0 parse errors, 1 error, 2 warnings
/srv
 [ ] target exists
 [E] unreachable source: /dev/mapper/vg0-srv: No such file or directory
 [W] cannot detect on-disk filesystem type

Scoring, briefly

You do not need a numeric model, and elaborate ones stop being filled in. Two questions decide the class in practice:

1. If this goes wrong, how many users notice?
      one host / one team / one service / everyone

2. How long until it is back the way it was?
      seconds / minutes / hours / it cannot be undone

Plot the answers. Anything in the bottom-right - wide reach and slow or impossible reversal - needs the full process regardless of how trivial the diff looks. Anything in the top-left is a candidate for the standard list.

The second question is the one that changes behaviour. Asking “how long to get back” out loud, before the change, is what surfaces the fact that nobody has ever tested the rollback.

Reducing the class instead of accepting it

Classification is not only triage. Once you can see which dimension makes a change risky, you can often attack that dimension and make the change genuinely safer rather than merely better documented.

• Reach: apply to one host first, then a cohort. Staged rollout turns a fleet-wide change into a series of small ones.
• Reversibility: capture the artefact before you replace it, take an LVM or filesystem snapshot, keep the previous configuration in version control, rehearse the reversal in staging.
• Detectability: add the alert before the change, not in the follow-up. A change whose failure is invisible should not proceed until it is visible.
• Dependents: sequence the change so the shared dependency moves alone, in its own window, with nothing else competing for attention.

Knowledge check