Redundancy Is a Culture, Not Just a Design Pattern

Ask a network engineer about redundancy and you get a lecture whether you asked for one or not. Two upstream providers instead of one. A second BGP session in case the first flaps, and a backup generator in the corner for when the grid does the same thing. None of it is exotic thinking in the field. Any single component will eventually fail, so no single component should be able to take the whole system down with it, and everyone in that world treats the idea as close to gospel.

I've spent enough time around network operator groups to see how deep that assumption runs. People will argue for an entire evening about diverse fiber paths for a link that's already up 99.98 percent of the time. The obsession scales with the stakes, and in this world the stakes get treated as serious even when the actual outage would cost someone a mildly annoying afternoon.

Rarely does that instinct get aimed at the people running the infrastructure instead of the infrastructure itself. The mailing list has one moderator who understands the spam filter rules. The meetup has one organizer holding the venue relationship, the sponsor contacts, and the login to the registration system. Some internal tool everyone quietly depends on got written by one person in an evening, years ago, and now only that person can touch it without breaking something. Ask who could take over tomorrow if that person disappeared, and the honest answer is usually silence.

Engineers wouldn't tolerate that shape in a router. They'd flag it as a single point of failure and redesign before shipping. Applied to a person instead of a device, the same shape reads as normal, sometimes even as a compliment. Being the only one who understands a system can feel like expertise. Most of the time that's just risk, sitting quietly in one person's head, waiting for them to get busy or move on.

Treating this as a people problem rather than a virtue means some unglamorous habits. Cross-train someone on the fiddly parts of a project before there's an emergency forcing the explanation, and write the runbook when nobody's asking for it rather than after the third midnight message because the thing broke while you were on a plane. Handing over admin access to something you built is slower than doing it yourself, and slower is part of what redundancy costs. The instinct to treat "I'm the only one who knows how this works" as a badge needs to get replaced with something closer to mild embarrassment. In a community project, indispensability is a warning sign.

This connects to a pattern most of these communities already recognize on some level: someone does the unglamorous maintenance work quietly for years, gets thanked now and then, and eventually drifts away or burns out, taking undocumented knowledge with them. That story gets retold often enough inside operator circles to count as folklore. Less common is the follow-up conclusion, that a project should stop depending on any single person continuing to show up, no matter how much everyone appreciates that person while they're still around.

I would like to say I have built this into my own projects. I have not. NOGnet runs mostly through me, and if I stepped away for a month, that would be a real problem rather than a minor inconvenience. Most of my other side projects are worse off: solo repositories, documentation that lives in my head or scattered across commit messages only I would know how to search, no second person holding keys to anything. I believe the argument I just made. Living by it is a separate matter, and on the evidence so far, one I have mostly avoided.

There's no tidy resolution to attach to that admission, and I'm suspicious of blog posts that pretend otherwise. The most honest thing I can do this month is pick one piece of NOGnet that only I could currently explain and write it down somewhere someone else could find it. Whether I get to it before the next deadline eats the week is a different question, and I wouldn't bet heavily on myself.