from experience: Im on a two-person IT team... when something breaks at night, whoevers on call often has to work things out from scratch because teh knowledge is in one persons head, weve talked about writing runbooks, but every time we try, they end up either too vague or too long to use.
for those who've made this work: what goes into a runbook that ppl actually use? and how do u keep them up to date? pls help 馃檹
Write runbooks right after an incident while it's fresh, and make it part of closing the incident. Nobody sits down to write documentation on a quiet afternoon. But a "write up what u did" step before an incident ticket can be closed works surprisingly well. worked for me anyway 馃し
@emeka_socket I'd go even simpler than a formal template to start. For a two-person team, a single shared page per service with "things that broke and what fixed them", dated, beats a polished runbook you never finish. Structure can come later once u see what's acutally useful.
Sign in or create an account to reply.
