Two valid windows, one night, and a system that went down

It happens once or twice a year, and each time it looks like an extraordinary coincidence. It is not.

One team schedules a database host for three in the morning on Wednesday. Another team, the same week and unaware, schedules the application server that reads from it. Both windows were approved. Both have owners. Both are within cadence. At ten past three the system that depends on both is down, and nobody understands why.

Why it is hard to catch

The defect is in neither window. It exists only in the combination, which makes it invisible to any check that looks at one window at a time.

Each team's planning was entirely reasonable. What both of them lacked was the same single fact: that their systems talk to each other.

Where the dependency knowledge actually lives

In three places at once, which is exactly the problem:

1. In a monitoring tool that observes traffic between machines and knows who talks to whom.
2. In two people's heads, from years of running the thing.
3. In an incident that happened once, two years ago, after which everybody "knows not to touch both together".

None of those three reaches the moment somebody picks a date in a calendar.

The best available knowledge: who talks to whom

The most practical way to build a dependency map is not to ask people but to look at traffic. A modern performance-monitoring tool can say, for each machine, which other machines it connects to. That is not quite "business dependency", but it is a very good approximation and it already exists.

From machine-level connections you can derive system-level ones: if a host belonging to system A talks to a host belonging to system B, the two systems are connected.

Three notes from the implementation

Do not take the system name from the monitoring tool. Management zones there are defined by people and rot exactly like any other field. Take the host-to-system mapping from the authoritative inventory and match on the machine's short name.

A host with no inventory match is still an edge. If a machine talks to another machine but has no inventory row, record the edge anyway with an empty system. Dropping it loses real information because of a documentation gap.

An edge that disappears is not deleted. If traffic between two machines stopped, that could be an architectural change — or a host that was powered off during the scan. Marking the edge inactive keeps the history; deleting it turns "we did not see it this month" into "it does not exist".

When the check is worth anything

At the moment the date is chosen. Not afterwards, not in a weekly report.

A warning that arrives after the invitation has gone to thirty contacts is not a warning. It is a report about something that now has to be cancelled, and cancelling an approved window costs more than the window did.

Concretely that means a check that runs while the form is being filled in: the user picked a date and time, the system looks for other planned windows overlapping in time on connected systems, and shows what it found.

Why the warning should not block

This seems counter-intuitive, but a blocking warning is a warning people learn to route around.

There are legitimate cases where you deliberately want two connected systems updated the same night — when the whole chain is coming down anyway, for instance. A hard block makes somebody move the window by ten minutes to defeat the check, and then the collision exists and the system believes it does not.

A warning that states what collides, with what, and when — and leaves the decision to a person — stays credible. It is also better evidence: the record then says they knew and decided, rather than that they did not know.

What to do without a dependency-monitoring tool

A hand-written list of twenty system pairs is worth far more than nothing, and it takes an hour in one meeting with two people who know the estate.

The question that produces the list quickly is: "which two systems must never be down on the same night?". People can answer that immediately, even when they could not draw the architecture.

The list will be incomplete. It will still catch the cases that hurt, because the cases that hurt are precisely the ones people remember.

What is worth measuring

One measure: how many times a year a dependency was discovered in real time — that is, inside a window rather than before it.

If the number falls, the map is improving. If it does not move, the map is not reaching the moment of decision, and that is a process problem rather than a knowledge one.