What does good change control look like, and why does it matter to a network engineer?
Show the answer
Say this first
Most outages follow a change, so change control is how changes stay safe and traceable. A good change has a clear reason, the exact commands, an impact and risk statement, pre-checks and post-checks, a rollback plan with a trigger, a maintenance window, a peer review, and a communication plan. Afterwards the record says what was done and what was seen. When something breaks, the change log is the first place I look.
Go deeper
What a change record contains
| Part | Example |
|---|---|
| Reason | add VLAN 30 for new cameras |
| Scope and impact | DSW1, DSW2, ASW1 to ASW4; no outage expected |
| Exact steps | the commands, per device, in order |
| Pre-checks | show interfaces trunk, show spanning-tree root, saved to a file |
| Post-checks | the same commands compared, plus a test from a camera |
| Rollback | the exact undo commands and the trigger, such as any uplink down for 2 minutes |
| Window and approval | Saturday 22:00 to 23:00, approved, peer reviewed |
| Communication | service desk and stakeholders told before and after |
Practices that prevent outages
- Peer review of the actual commands, not a summary.
- Change types: standard (pre-approved, low risk, repeatable), normal (reviewed), emergency (reviewed afterwards).
- Safety nets for remote work:
reload in, an archived config withconfigure replace, Junoscommit confirmed. - One change per window where possible, so cause and effect stay clear.
- Automatic config backups and a diff after every change.
Emergency changes
During an outage you may change things without prior approval. You still record them, review them afterwards, and bring the documented state back in line with the running config.
They will ask next
How does
reload inprotect a remote change?It schedules a reload, for example in 15 minutes. If the change cuts you off, the device reboots into the saved startup config, which does not contain your unsaved change. If the change works, you run
reload canceland then save. It costs a full reboot if it fires, soconfigure replacewith an archived config is gentler where the platform supports it.What makes a good rollback plan?
Exact commands, tested where possible, a clear trigger that says when to use it, and a deadline for the decision, so nobody is still debugging at 2 a.m. after the window has closed.
Traps
- Treating change control as paperwork. Its value is in the pre-checks, the rollback and the record you use when something breaks.