Diagnosis Up, Actions Down: The Thinking Behind PNOMA

PNOMA is a troubleshooting sheet for vSAN, and the first thing to understand about it is what it refuses to do. It diagnoses. It never tells you to fix anything. That is not a missing feature. It is the design.

The problem it solves is one every support engineer knows. A vSAN problem sprawls across layers: a disk, a network path, an object, a policy, a service. A novice engineer opens a case, gets bounced between seniors, and each senior starts over from scratch because nobody wrote down the path that was already walked. PNOMA is that path, written down once, in order.

The order is the framework: P for physical, N for network, O for object, M for management, A for application. You diagnose upward from the physical layer. You do not start at the object that looks sick; you start at the disk and the wire underneath it, because most of the time the object is sick for a reason that lives below it. In practice, about 98 percent of issues are diagnosed in P and N. That is not a slogan. It is what happens when you work enough cases: the disk was already warning, the NIC was already dropping, the unicast table was already wrong, and the object at the top was just the first place the damage showed up.

Each layer is a set of numbered checks with commands, sample output, and what to look for. The links to Broadcom KBs sit at the leap points, where a reading turns into a direction, and at the spots that teach a pattern. They are never a list in the middle of a paragraph, because a list in the middle of a paragraph is a wall of links nobody reads. The sheet teaches the pattern and points at the reference, in that order.

Diagnosis-only is where the sheet stops, and the stop is deliberate. Five STOP fences mark the places where the sheet ends and a senior takes over, with Stop-escalate rows that hand off the evidence gathered so far. A guide that tells a novice to unmount a disk, change an advanced setting, or rebuild a unicast table by hand is a loaded gun with a friendly cover page. The sheet's job is to get the right evidence to the right person, fast, with the reasoning visible. What happens past the fence is senior judgment, sometimes with a linked KB, never a sheet prescription.

Two more rules shape everything in it. First, provenance: every fact in the sheet is either public documentation or something I wrote myself. Nothing internal, nothing from a case, nothing a customer would recognize. Second, locality: the whole thing is one self-contained HTML file that runs in a browser on your own computer. No backend, no account, no telemetry. A troubleshooting guide for customer environments has no business phoning home.

The sheet is tested the way it is used. Scenario packs run it against constructed cases, and novice engineers test-drive it on live cases, with seniors revisiting the handoffs to check that the evidence actually carried across the fence. When a novice finds a gap, for example a device missing its NAA and no clear path to identify it, that gap goes on the roadmap as a future build item, not as a quiet edit. The sheet only changes through that loop.

Attribution belongs here too, because it is part of the story. Framework: Brad Mott. Expansion: Daniel Barnes. Brad built the original structure; I expanded it, verified it, and kept it diagnosis-only. The sheet is the map, not the mechanic, and it works best when everyone using it understands which one they are holding.