Last spring I finally got approval for something I had been asking about for two years. I unplugged the network on purpose, in the middle of a working day, with people at their desks. Not a tabletop, not a slide with arrows on it, an actual physical disconnect. I thought I was ready for it. I was ready for the outage, not for how quiet the building got.
The silence was the strange part. Phones still worked, so people called each other asking whether the internet was down for them too. It took about four minutes before someone walked to my desk to check on me personally.
What a real disconnect shows you
The first thing you learn is how much of your environment you have never actually touched. I had a diagram, I had a CMDB export, and neither of them mentioned the small switch in a closet behind the copier that half of finance quietly depended on. It was not in any document because nobody had ever needed to document it. It just worked, for six years, unattended.
The second thing is that people rebuild connectivity faster than you can watch. Within twenty minutes someone had plugged a laptop into a spare wall port in the conference room and started tethering off a phone. I had not planned for that, and honestly it was a good reminder that users are more resourceful than any runbook assumes.
The third thing is the noise. Half the alerts that fired were things I expected, and the other half were systems complaining about each other in ways nobody had described to me. Two internal services had been retrying so hard for so long that their failure only became visible when everything else stopped. That was the most useful five minutes of the whole exercise.
The fourth thing, and this one surprised me, is how quickly people adapt to being cut off. Teams started writing things down on paper again. One group ran their morning standup in the hallway with no laptop open. There is something slightly uncomfortable about watching an office function fine without the thing you spend most of your budget maintaining, and it is worth sitting with that feeling for a while.
Why so few teams ever do this
I don’t think it’s laziness. It’s that the drill has no owner until something breaks, and by then you are too busy to schedule it. Contingency planning gets written during an audit and then filed, and the file is what satisfies the requirement, not the practice.
There’s also a career angle nobody says out loud. If you unplug things and something does not come back, that is on you. If you never unplug anything, nothing bad happens to your record. The incentive quietly points at doing nothing, and most of us follow incentives more than we admit.
And there is a cost that’s easy to underestimate. A real disconnect interrupts actual revenue work, so it needs cover from someone senior, a narrow window, and a rollback plan you can execute in minutes. That’s a lot of coordination for something that produces no visible output.
Where this fits in the bigger picture
I’ve also seen unified platforms such as Ping64 used to cut down the overhead of juggling many separate security tools. That line stuck with me because a drill exposes the same thing from the other direction. When your controls are spread across nine consoles, you find out during an outage which ones you can actually reach.
Things I would do differently next time
Label the patch panel first, in a different color, before you schedule anything. Half my drill time went into figuring out which cable was which, and that is a pure waste. Labels are boring and they pay for themselves in the first ten minutes.
Announce the window to the whole company, not just IT. We told managers, managers told some people, and the rest found out when their mail client froze. A single all-hands message would have saved a dozen confused phone calls.
Keep one laptop on a cellular hotspot and watch what it can and cannot reach. That tells you more about your dependency graph than most architecture reviews, and it costs nothing.
Write down what broke while it is still broken. I took notes forty minutes later and had already lost two details. The mess is the data, and it evaporates fast.
Pick a boring day with no month-end close and no payroll run. We chose a Tuesday in a quiet week, and even then two people had a deadline. There is never a good day, so choose the least bad one on purpose instead of waiting for an ideal one.
Closing, loosely
I would do it again, and I’d schedule it earlier in the year. It was uncomfortable, a bit embarrassing in places, and it made every later conversation about resilience concrete instead of theoretical. If you have been meaning to try it, the cable is right there, and the silence is survivable.
Top comments (0)