Richard Kettlewell

Over on the Fediverse I indulged in some snark:

Network inventory hot and grumpy take: Yep, it's not great that sysadmins and network people don't necessarily have a hardware and network inventory, unlike modern software development where famously everyone knows exactly what their entire dependency tree is and why it's there and has full trust in it staying that way.

(That is sarcasm.)

Let's get this out of the way right at the start: inventories are hard. I don't just mean network inventories or machine inventories or software inventories or dependency inventories. I mean any and all inventories, everywhere. For example, some real businesses periodically take a day or two off from doing business in order to check and reconcile their inventory with actual physical reality. It's ordinary to have a business's website say they have something in stock at a location, but when you go to the location, the people there can only shrug and tell you they have no idea where the theoretically in-stock item is, if it even exists.

(I can also assure you that an inventory of other physical items, even very important ones like keys, can become completely hopeless. One reason lots of people like reprogrammable electronic locks is that you can make your inventory be the authoritative state of the world. Of course, this will also lead to you discovering ways in which your inventory did not reflect reality, as people turn up who should have access but aren't in your lock inventory.)

One reason that all inventories are hard is that they're an attempt to keep two (or more) things in sync with each other, those being the inventory itself and the physical or software reality. Not coincidentally, in our field the most accurate inventories tend to be the ones that are built on self-reporting. Unfortunately there is only so much information that can be accurately self-reported. For example, a machine intrinsically knows that it exists and has certain hardware and software states, but it doesn't intrinsically know why it exists. If you try to make a machine 'self report' why it exists, this is generally going to be the machine echoing back to you something that you told it earlier.

This also relies on being able to get a self report from machines or whatever else is of interest. A machine or a piece of software or whatever that doesn't generate a self report is mostly invisible. Generally self reporting is something that has to be added to machines, software, and other things of interest, and if this isn't complete, that creates gaps in a self reported inventory. You can fill these gaps in the inventory by hand, but then you're trying to keep two things in sync with each other.

The less you can trust self reporting, the harder inventories get. We see this in the perpetual struggle of default deny firewalls, which can be seen as an inventory of allowed network traffic except that we can't allow things to self-report that they should be allowed. This creates a burden of inventory maintenance in the form of firewall rule updates (which is often made more annoying by organizational structure, where you can't update the 'inventory' yourself but have to wait for other people to do it before you can do things).

Ultimately, maintaining an inventory takes work. If you want that work to happen, you must budget time for that work and you must make that work rewarded. If your organization's structure of rewards and demerits makes it clear that maintaining an inventory is not as important as other things, well, you will get what you'd expect.

(Locally, we do budget time to maintain several sorts of inventories, but at the same time many of them are imperfect. Partly there is a trade off between the amount of time spent maintaining inventories and their accuracy, and partly people make mistakes, which is another reason why things self reporting themselves is better if you can manage it.)