Three questions before touching a production network

Most outages caused by engineers are not caused by ignorance. They are caused by a correct change applied with an incomplete picture. Three questions, asked honestly, prevent most of them.

1. What else uses this?

The interface you are about to shut carries the thing you are working on. What else does it carry? The VLAN you are about to prune, the route you are about to remove, the ACL line you are about to edit — each may be load-bearing for something you have not thought about.

show interface status | include Gi0/5
show mac address-table interface Gi0/5
show ip route | include 10.20.

Five minutes of looking beats an hour of explaining.

2. How do I get back in if this goes wrong?

If the change cuts your own access, how will you recover? Console access, an out-of-band path, someone on site, or a timed rollback. Answer it before, not after.

The timed rollback is the most underused tool in networking. Schedule the undo first, make the change, and if you lose access the device restores itself:

reload in 10                  # Cisco: reboots to saved config
# commit confirmed 10         # Junos: rolls back unless confirmed

3. What will tell me it worked?

Decide the success test in advance, and make it specific. Not “it should be fine” but “this host will reach that port, and this counter will stop incrementing”. Write it down. A test chosen after a change tends to be one the change happens to pass.

The habit

These take a couple of minutes. They are not bureaucracy; they are the difference between a change and a gamble. The engineers who rarely cause outages are not more careful by temperament. They have internalised these three questions and ask them every single time, including on changes that look trivial — especially on those, because that is when the picture is most often incomplete.