Possibly unavailable resources

Your lack of planning is not my crisis

Let’s consider a distributed computer system that uses some specific resource R. This will turn out to be relevant to some thoughts about social interactions, but let’s approach it impersonally first.

The system’s design needs to take account of whether resource R might be unavailable some of the time. Notwithstanding efforts to build highly resilient systems, pretty much every conceivable resource has some circumstance in which it’s unavailable. Even if the resource itself has lots of redundancy and is “always up,” the network that reaches it almost certainly has failure modes in which it won’t be possible to reach the resource. That’s part of the reason why I specified that this is a distributed system, involving elements that are communicating via networks. In a choice between distributed systems and centralized systems, distributed systems are the more general case. (Indeed, one of my occasional observations is that the universe itself is a distributed system, with substantial distances separating many of its elements.)

If resource R were “close enough” that we aren’t dealing with a distributed system, then we might be able to avoid concerns about the possible unavailability of R. That doesn’t mean that we could somehow make R so that it would magically work at every possible instant, but its fate and “ours” might be tied closely enough so that we couldn’t tell that it was unavailable.

Anticipating unavailability in computer systems

Let’s now explore the available design space when R isn’t available. The choices are typically:

1. find some alternative resource, R’, or

2. wait for the currently-unavailable resource R to return, or

3. switch to a different approach that doesn’t require the unavailable resource. One common kind of “different approach” is to enter some failure mode for the larger system, since there may not be any available alternative to R.

It’s unusual, but possible, for there to be a fourth choice in which the system that wants to use the resource can itself take some action to re-enable it: for example, in a scenario where the resource is unavailable because some bill hasn’t been paid, paying that bill will bring the resource back.

Working through the alternatives to get to the right choice is usually straightforward and typically doesn’t require a lot of thought. It’s not always as simple as looking up a recipe in a cookbook, but it’s close – especially for people who’ve built more than one of these systems.

Sometimes people operating one of these systems are caught out when some resource is unavailable. I have some sympathy for people who are encountering genuinely unusual situations for the first time. It’s hard to anticipate every contingency, and it’s easy to misjudge probabilities, especially of relatively rare situations. It’s tough to strike the right balance between having enough redundancy to cover common failures vs. overbuilding the system and causing other kinds of problems (like excessive cost).

However, I’m much less sympathetic in any situation where the potential unavailability was obvious, and especially in situations where the resource publicly advertises its potential unavailability – perhaps even providing a model for its likely unavailability. For example, any situation in which the resource is just a single server sitting on the internet, with no defense or redundancy strategy, is trouble waiting to happen.

I would find it baffling if a system operator responded to one of these unavailability situations by screaming at the unavailable resource. Likewise, it would be bizarre if they loudly bemoaned their miserable lot in life, with these damnable unavailable resources. Those would clearly be dysfunctional reactions to their planning failure(s).

Anticipating unavailability in social systems

In the same way that any resource in a distributed system might be unavailable, any person in an organization might be unavailable: think of sleep, vacations, illness, death, or conflicting demands on their time. And yet, if we swap out the computers of a distributed system and we swap in people, there’s a lot more weird and hard-to-justify framing of what’s happening. It’s surprisingly common in interpersonal situations to encounter screaming or complaining behaviors that would be bizarre as a reaction to a computer system failure.

Suppose someone needs a response faster than the advertised turnaround time, or doesn’t have enough money in their budget to pay for what they need. Those situations may well lead to highly predictable availability problems, in which the key resource is unavailable. Occasionally, I am in a surprising situation where someone treats me poorly and then turns around to ask me to do something on their behalf. Even stranger is if they get angry at me for connecting their previous problematic behavior to my unavailability or their low priority for me. Sometimes, but not always, these situations are examples of what I’ve previously written about as noble selfishness, in which a person is a jerk in service of a good cause.

In general, for smooth functioning, it’s a good idea to plan ahead and invest in whatever is needed to secure resources when they are needed. All too often, people think that they are part of a centralized system in which they control availability of all resources.

Some people who well understand the need for mechanical maintenance will completely miss the need for forms of interpersonal maintenance. (I sometimes make that same mistake myself, but I am working on doing better.) The reality is that most interpersonal interactions, whether at work or in a family relationship, are more like the communications in a distributed system: asking is no guarantee you’ll get the answer you need.