Rollout Safety
Blast radius as the organising idea: version coexistence, canary analysis against a baseline, rollback that is actually safe, and when rolling forward is the only option.
Any deploy without downtime runs two versions of your code against one set of state — and rollback runs them in the other order, which is the direction nobody tests.
Deciding whether a candidate is healthy by comparing it against a concurrent baseline on errors, latency, saturation and business outcome — and never on CPU alone.
Going back to the previous version is the fastest way to end user impact — until the change made the previous version invalid, at which point what you are doing is not a rollback.
Irreversible migrations, side effects already emitted and dependencies that moved on — the situations where the fix has to go forward, and how to ship one safely under pressure.
The organising question of the whole domain — one test, one user, one tenant, one percent, one zone, one region, everyone — and why the honest answer is usually larger than the intended one.
The techniques that move a change down the ladder — exposure control, partitioning, staging, privilege limits and reversibility — and the ones that appear to contain and do not.
Small changes make cause and effect legible, review effective and rollback cheap — but diff size and blast radius are different axes, and confusing them is how one-line outages happen.
The pipeline reports success when bytes moved and a process answered a health check — which is several layers short of the system doing what it exists to do.