Skip to content
Is there an AI for this?

FDE ACADEMY · MODULE 05 · LESSON 04

Handover, and the documentation that survives you

The runbook, the restore somebody else performs, and the two-week test: if the deployment cannot run without you for a fortnight, it has not been handed over.

Effort
A day to write, a half-day to rehearse with the owner.
Skills
change-management · linux · postgresql

Free and self-paced. No certification is offered.

Before you startYou have an operating routine from module 03 lesson 05 and a named owner.

01What a runbook contains

Not architecture. A runbook answers operational questions under pressure: how to restart it, what to do when the model server will not come up, how to add a user, how to remove a collection, how long a reboot takes, what normal looks like, and who to call when none of that works.

Write it for the person who will be woken at three in the morning, who has not read your design document and does not care about it. Short sections, commands that can be copied, and the expected output next to each one.

  • Start, stop, restart, and what a healthy system looks like afterwards.
  • The five numbers from the operating routine, and what each should roughly be.
  • Add a user, remove a user, add a collection, delete a collection.
  • Restore from backup, with the last date somebody actually did it.
  • Escalation: who, how, and what information to have ready.

02Rehearse, do not present

A handover meeting where you demonstrate is not a handover. Sit next to the owner while they do it: restart the stack, add a user, delete a collection, restore the database. Every place they hesitate is a defect in your documentation, and you fix it while you are still there.

The restore is the one people skip and the one that matters. A backup nobody has restored from is a hypothesis.

03The two-week test

Leave. Be reachable for genuine emergencies and refuse everything else for two weeks. What breaks, and what questions arrive, are the true measure of the handover — and there is still time to fix them while the engagement is warm.

Then agree what the ongoing relationship actually is, in writing: nothing, a review each quarter, or a support arrangement with a price. Ambiguity here becomes unpaid work and a resentful customer.

04Do this

PRACTICAL TASK

Write the runbook and have somebody else restore the system

Produce a runbook the owner can use without you, then watch them perform a restart, a user change, a deletion and a restore from backup.

What you need

  • A named owner with the access they need
  • A backup you are willing to restore over a test deployment

Steps

  1. 01

    Start from the recipe’s operating-routine step and turn its checks into the runbook’s “what normal looks like” section.

    Private knowledge base — deployment steps

  2. 02

    Write the operational sections with copyable commands and the expected output beside each one.

  3. 03

    Sit with the owner while they restart the stack, add and remove a user, and delete a collection. Take notes on every hesitation.

  4. 04

    Have them restore the database from backup while you keep your hands off the keyboard. Record how long it took.

  5. 05

    Rewrite the sections they stumbled on, then agree in writing what happens after the engagement ends.

You are done when

  • The owner completed a restart, a user change, a deletion and a restore without you touching anything.
  • The runbook has a last-restore date and a measured restore time in it.
  • The post-engagement arrangement is written down, including “nothing” if that is the answer.

05Where these facts live

This lesson does not restate anything that is already recorded with its evidence elsewhere on the site. These are the pages it leans on.

Ticks are stored in your browser only. They are not sent anywhere, they are not attached to an account, and clearing your browser data removes them.