Runbooks: τι πρέπει να γράφει κάθε project για να μη χαθεί η γνώση

Κάθε ομάδα έχει έναν άνθρωπο που «ξέρει πώς γίνεται το deploy στο eshop». Μέχρι να πάει διακοπές. Το runbook είναι ο τρόπος να βγει αυτή η γνώση από το κεφάλι του και να μπει δίπλα στο project, εκεί που θα τη χρειαστεί ο επόμενος.

Τι είναι (και τι δεν είναι) ένα runbook

Ένα runbook είναι οδηγίες για ενέργειες: πώς κάνεις κάτι συγκεκριμένο, βήμα βήμα. Δεν είναι τεκμηρίωση αρχιτεκτονικής, δεν είναι README για developers, δεν είναι ιστορικό αποφάσεων. Αν η σελίδα δεν απαντά στο «τι πατάω τώρα;», δεν είναι runbook.

Το καλό runbook διαβάζεται από κάποιον που ξέρει τη δουλειά αλλά δεν ξέρει το project. Αυτό είναι το μέτρο.

Τα πέντε runbooks που χρειάζεται κάθε project

1. Deploy. Από πού, με ποια εντολή, πώς ελέγχεις ότι πέτυχε.
2. Rollback. Πώς γυρνάς στην προηγούμενη έκδοση, και τι γίνεται με τη βάση αν άλλαξε.
3. Backups και επαναφορά. Πού είναι, πόσο συχνά, πόσο κρατιούνται, και πότε δοκιμάστηκε τελευταία φορά η επαναφορά.
4. Το site έπεσε. Τι ελέγχεις με τη σειρά: DNS, πιστοποιητικό, server, εφαρμογή, βάση.
5. Ανανεώσεις. Ποιος πληρώνει το domain, πού γίνεται η ανανέωση, τι θέλει χειροκίνητη κίνηση.

Για ένα απλό site τα τρία πρώτα χωρούν σε μία σελίδα. Για μια εφαρμογή με πολλές υπηρεσίες, κάθε ένα αξίζει τη δική του.

Ένα πρότυπο που μπορείς να αντιγράψεις

## Deploy
1. Merge στο main.
2. Ο server τραβά και κάνει build μόνος του (~2 λεπτά).
3. Έλεγχος: https://example.gr/api/health επιστρέφει "ok".

## Rollback
1. git revert του τελευταίου merge και νέο deploy.
2. Αν άλλαξε η βάση: επαναφορά από το backup της νύχτας
   (βλ. «Backups»). Ρώτα πρώτα τον υπεύθυνο του project.

## Backups
- Καθημερινά 03:00, 30 ημέρες, στο bucket backups-prod.
- Τελευταία δοκιμή επαναφοράς: 12/9/2026.

## Πού είναι τι
- Hosting: VPS παραγωγής (βλ. πόροι του project)
- DNS: Cloudflare του πελάτη, όχι δικό μας
- Κωδικοί: συλλογή του project στο θησαυροφυλάκιο

Πού να ζει το runbook

Η απάντηση είναι απλή: δίπλα στους πόρους του project. Όχι σε ένα ξεχωριστό wiki, όχι σε ένα Google Doc με σύνδεσμο που χάνεται. Όταν ανοίγεις το project για να δεις σε ποιον server τρέχει, το runbook πρέπει να είναι μία καρτέλα δίπλα.

Το Markdown είναι η σωστή μορφή: γράφεται γρήγορα, διαβάζεται παντού, και τα βήματα με αριθμούς και τα κομμάτια κώδικα φαίνονται καθαρά.

Πώς μένει ενημερωμένο

Ένα παλιό runbook είναι χειρότερο από κανένα, γιατί σε κάνει να εμπιστεύεσαι κάτι λάθος. Τρεις συνήθειες βοηθούν:

• Ενημέρωση μετά από κάθε περιστατικό. Αν κάτι δεν ήταν γραμμένο, γράφεται στο post-mortem και μετά στο runbook.
• Ημερομηνία και όνομα. Φαίνεται ποιος άλλαξε τι και πότε. Ένα runbook που δεν έχει αγγιχτεί δύο χρόνια θέλει έλεγχο.
• Δοκιμή από άλλον. Μία φορά τον χρόνο, κάποιος που δεν ξέρει το project κάνει deploy μόνο με το runbook. Ό,τι κόλλησε, διορθώνεται.

Τα συνηθισμένα λάθη

• Πολύ μεγάλο: κανείς δεν διαβάζει δέκα σελίδες υπό πίεση.
• Γενικές οδηγίες («κάνε restart στην υπηρεσία») χωρίς την ακριβή εντολή.
• Υποθέσεις που ξέρει μόνο ο συγγραφέας («από τον γνωστό λογαριασμό»).
• Κανένα βήμα επιβεβαίωσης: πώς ξέρω ότι το deploy πέτυχε;

Συχνές ερωτήσεις

Πόσο μεγάλο πρέπει να είναι ένα runbook;

Όσο χρειάζεται για να γίνει η ενέργεια χωρίς να ρωτήσεις κάποιον. Συνήθως μία οθόνη ανά ενέργεια. Αν μεγαλώνει, χώρισέ το.

Ποιος γράφει τα runbooks;

Αυτός που στήνει το project γράφει την πρώτη εκδοχή. Μετά, όποιος βρίσκει κάτι λάθος ή κάτι που λείπει το διορθώνει εκείνη τη στιγμή.

Αξίζει runbook για ένα μικρό WordPress site;

Ναι, ένα σύντομο: πού φιλοξενείται, πού είναι το DNS, πού τα backups, ποιος πληρώνει το domain. Πέντε γραμμές σε γλιτώνουν από μία ώρα ψαξίματος.