Blast radius measures the impact of a failed change: the number of affected components and the criticality of what they support. Unknown dependencies make even a single manual command risky. section 1.2.1
Infrastructure as code reduces blast radius by recording configuration, testing intended behavior, exposing dependencies, and making changes reproducible. Modular designs go further by isolating resources so teams can deploy, test, and debug smaller units. section 1.2.1 section 3.6
Reduce the blast radius of infrastructure changes by:
- Writing modules with as few resources as practical, aligned with business domains, environments, teams, or functions. section 3.6
- Testing changes in virtual or representative environments before promoting them to production. section 1.2.1
- Applying incremental fixes, rolling upgrades, or blue-green deployment when changes or tool upgrades could fail. section 11.4 section 13.2.2
- Checking drift, unexpected dependencies, and environment differences before reproducing a failed change. section 11.4
A miscopied network command
A network engineer pasted shutdown instead of no shutdown onto a switch interface. The interface appeared to be a local change, but it disconnected a critical application and affected customer requests. Source-controlled configuration, a virtual switch, and an interface-health test would have exposed the error before production. section 1.2.1
Figure 13.8 You can use a rolling update pattern to minimize the blast radius of a failed tool upgrade and roll forward if the change fails.
A rolling-update diagram makes progressive rollout and failure containment concrete for tool upgrades. section 13.2.2
