The reboot that reached the warehouse
A logistics company with 600 employees had an IT team of four. They kept a spreadsheet of servers: name, address, operating system, who looks after it. The spreadsheet was accurate. Nobody could remember it ever being wrong.
On a Tuesday afternoon one of the engineers restarted a server called app-07 to install an update. The spreadsheet said it was an “application server”. It did not say that app-07 printed the shipping labels for the warehouse, that the warehouse system asked it for a label every time a parcel left the dock, and that a truck was waiting at the dock at half past two. The restart took four minutes. The pile of parcels with no labels took two hours to clear.
Nothing in that story is unusual. The spreadsheet was right. What it lacked was the second half of the sentence: app-07 is an application server that the warehouse cannot work without. A list has rows. A service has people waiting on it.
Why a list is not enough
Most teams start with a list because a list is easy. You can export one from almost anywhere. It answers the question “what do we have?”, and that question deserves an answer.
The trouble is that almost every decision in IT is about connections, not rows. Can I restart this server tonight? Depends on what runs on it. Can we move this group of addresses? Depends on which services use them. Which licence stops working when we remove that program? Who should we warn before the backup system goes down for an hour? You cannot answer any of that by sorting a column.
So the answers live in people’s heads. The one engineer who set up the label service knows that app-07 matters. When she is on holiday, or has moved to another company, that knowledge leaves with her. The spreadsheet looks exactly the same as it did before.
Write down the whole chain
In AverDesk a server is one record among many. The inventory also holds the things a business actually cares about: products, the services inside them, the copies of each service that are running, the servers they run on, the hardware, addresses, programs, licences, rooms and buildings, accounts, checks and backup rules. Each one has its own fields, its own history of changes and its own links to the others. (For the IT reader: products, services, service instances, hosts, hardware, IP addresses, subnets, software, licences, locations, accounts, monitors and backup requirements.)
For the label printer the chain looks like this. A product called Warehouse operations. Inside it, a service called Label printing. That service has one working copy, and the copy runs on server app-07, which sits on a particular physical machine, in a particular rack, in a particular building. The service record also lists the ports it uses, the outside print system it talks to, and where its spare copy lives in case the main one fails.
Once the chain exists, the question “can I restart app-07?” has a visible answer. Open the server, and you see what sits above it. The dependency view walks up the chain: server, then the running copy, then the service, then the product, then the people who use it. The restart is still your call. It is just no longer a surprise.
Links with a few rules
A map like this stays useful only if it stays tidy, so AverDesk puts guardrails around links. Each organization decides which kinds of links are allowed and how many of each an object may have. Loops are refused: if someone tries to make a service depend on itself through three steps, the system rejects the link and shows the path that would have closed the circle.
Some fields are passed down the chain. A running copy can take its location or its backup rule from the service above it, so nobody types the same thing twice. When two parents disagree, nobody guesses either. AverDesk shows the conflict and a person picks the right value. Every field keeps its history, so you can see who changed the owner of a server, when, and what it said before.
We call the result living documentation. You do not write a separate page about the label service and then forget to update it. The service record, with its servers, ports, outside connections and spare site, is the documentation, and it changes when the real thing changes.
Find what nobody connected
There is a quieter problem too: things that exist in the inventory but were never linked to anything. A test server someone forgot to delete. A licence nobody attached to its program. A group of addresses that are in use, with no service claiming them.
AverDesk looks for these on purpose. The estate map highlights objects with no links and objects whose links never lead to a product, which usually means nobody knows what they are for. A daily check reports anything newly forgotten, so the pile of orphans does not quietly grow for a year before anyone notices.
What to do first
You do not need to describe your whole IT on day one. Pick one service that would hurt if it stopped: the kind of thing a warehouse, a shop floor or a sales team would notice within an hour. Write down its product, its service, its running copies and its servers. Add the people who own it. That is one afternoon of work. The next time somebody opens that server before a restart, they will see the warehouse looking back at them.
If you want to try this on your own infrastructure, start with the Free plan. One organization, one operator, no card, and a demo organization you can break without consequences.
Read next
Start with one service
The fastest way to fail at an inventory is to import everything on day one. Here is how to start with a single service and grow from something that already works.
· 5 min read
What AverDesk is and who it is for
A plain description of the product: a list of everything your company runs, a map of what depends on what, and a help desk, all in one place.
· 6 min read