1.4.2. Blast Radius and Change Management
💡 First Principle: Every change to a production system carries risk. The "blast radius" is how many systems, services, or users would be affected if the change goes wrong. Reducing blast radius and planning rollbacks isn't pessimism—it's professional discipline.
Changes that go wrong in production cause outages. The discipline of change management exists to minimize blast radius through:
- Pre-change documentation: What is being changed, why, and what the rollback procedure is
- Testing in non-production first: Every change should be tested where failure has no user impact
- Change windows: Scheduling disruptive changes for low-traffic periods
- One change at a time: When you make multiple simultaneous changes and something breaks, you don't know which change caused the problem
- Rollback plans: Know exactly how to undo every change before you make it
The Change Control Board (CCB) or similar governance body reviews proposed changes and assesses risk before approving them. This isn't bureaucracy—it's a sanity check that catches overlooked dependencies and conflicting changes.
A critical practical rule: always back up before making changes. If you're patching a server, resizing a partition, or updating firmware, a backup means that a failed change doesn't mean data loss.
⚠️ Exam Trap: CompTIA's troubleshooting methodology explicitly requires you to "perform backups before making changes" when possible. This step is tested—don't skip it in scenario questions even when time seems limited.
Reflection Question: Why is "make one change at a time and test" a mandatory rule in professional change management, rather than an efficiency preference?
