Organizing & Making Documentation Findable

Chapters 1 through 8 covered producing documentation that's accurate, secure, and genuinely tested. This chapter covers the last practical problem: a technically excellent document nobody can actually find in the moment they need it fails its own purpose just as completely as a wrong one would — just through a different mechanism entirely.

Findability Is a Separate Problem From Quality

A perfectly accurate, well-tested runbook buried in the wrong folder, named inconsistently, or scattered across three slightly different copies fails a stressed reader just as thoroughly as an inaccurate one would. All the work from every prior chapter in this course is wasted if the reader simply can't locate the document at the moment it matters.

Consistent Naming and Location

A predictable naming and location scheme lets a reader guess where something likely lives, or search effectively, rather than needing to already know a specific document exists before they can find it. Consistency matters more than any particular convention — the value comes from a reader being able to predict the pattern, not from the pattern itself being perfect.

Tagging: Multiple Paths to the Same Document

Tag by system, by severity or criticality, and by document type (Chapter 2's own KB article/runbook/ticket distinction) — a reader searching under pressure might know the system name but not the specific problem, or the reverse, so more than one path to the same document genuinely helps.

Cross-Linking Related Documents

A runbook should link directly to its own supporting KB article — Chapter 2's own "split a growing background section into its own linked article" pattern — and related runbooks for the same system should reference each other, so a reader who finds one has a clear path to the others they might also need.

The Duplicate-Copy Problem: A Sneaky Variant of Decay

Chapter 7 covered a document going stale where it lives. This is a related but distinct problem: once a document is updated, old copies pasted elsewhere — a chat message, a different wiki page, a printed page left on a desk — don't get updated along with it, and can be found and followed instead of the current version. The original document can be perfectly current while an outdated copy of it, still findable somewhere else, actively misleads whoever happens to find that copy first.

Deprecate, Don't Silently Delete or Silently Leave in Place

When a document is genuinely retired — the procedure no longer applies, the system it describes was decommissioned — mark it clearly as deprecated or archived. Silently deleting it loses potentially useful historical context; silently leaving it in place looking current means someone can find and follow it by accident, the same duplicate-copy problem above, but applied to the original document itself once it's no longer accurate.

Hands-On Exercises