Auditing your own infrastructure has traps of its own
- date
- 20260920
- what happened
- While building the first full as-built capture, three methodology bugs were made and caught in the same evening. A greedy punctuation-normalising pass mangled command-line flags in code examples. A read-only verification command list assumed systemctl worked fleet-wide and did not account for the Slackware-based Unraid host. A finding that two inventory loader scripts had never run was based on a file's modification time, which was the time of the git checkout that produced the file rather than the time the export ran.
- what it cost
- No production impact. The cost was wasted analysis and one false finding that would have sent the next reader hunting a bug that did not exist, had it not been caught in the same pass.
- what changed
- The first two were corrected in the document before publication. The third was reclassified from the loaders never ran to wait for the next nightly export to confirm, with the resolution assigned to the next real data point rather than to a guess.
- the check now
- The plan for the next capture carries three explicit notes: check command availability before assuming it, verify any automated text transform against real code samples, and never treat a file's modification time as the time of the event it describes without checking what wrote or copied it.
This one is worth including precisely because it is small. A team building automated documentation or inventory capture over its own infrastructure will make the same class of mistakes the infrastructure tooling makes. It is built the same way, often quickly, by the same kind of process, and usually in one sitting.
All three are generic tooling mistakes rather than infrastructure mistakes. Assuming a command works everywhere because it works on most hosts breaks the moment one member of the fleet runs a different init system, and a heterogeneous fleet always has one. A text transform applied across a whole document without checking it against real samples will happily rewrite the inside of a code block, where the characters it is normalising are syntax rather than prose.
The third is the one most likely to produce a confident false finding. A file’s modification time is the time of the most recent write to that path on that filesystem. That write may be a checkout, a copy, or a redeploy long after or before the event the file’s contents describe. Here the export actually runs nightly at 00:40, eleven hours before the loaders were committed that day, so the timestamps said something entirely different from what they appeared to say. When timing matters, find the field that records the event itself, and if no such field exists, say so and wait for the next real data point rather than inferring one.
Source: node0 lessons v0.1, lesson 6.17. Sanitized: checklist v0.1, 20260921; audit document file name; voice pass 20260921. Part of oznog.com/node0.