Recording what exists and why.
WHAT TO DOCUMENT
What systems exist, and what each is for How they connect, and what depends on what Addressing and naming Where credentials are held How each service is deployed and restored Who owns each system
WHY DEPENDENCIES MATTER MOST
They determine what an outage affects, and what a change risks.
WHAT A NETWORK DIAGRAM SHOULD SHOW
Physical and logical connectivity, at a level someone can act on.
WHAT TO AVOID
Diagrams so detailed nobody maintains them Diagrams so vague they answer nothing
WHAT A RUNBOOK IS
Instructions for a specific operational task or failure.
WHAT MAKES ONE USEFUL
Written for someone under pressure, at night, who did not build the system.
WHAT THAT IMPLIES
Exact commands, no assumed knowledge, and what to do when a step fails.
WHERE TO KEEP ALL OF IT
Somewhere reachable when your systems are unavailable.
WHY
Documentation stored only inside the failing system is useless during an outage.
WHAT TO UPDATE
It, as part of the change, not afterwards.
WHY
Documentation updated later is not updated, and out-of-date documentation is worse than none because it is trusted.
WHAT TO REVIEW AFTER EVERY INCIDENT
Whether the documentation would have helped.
