Γράφοντας ένα runbook cutover μεταφοράς με ρολόι σε κάθε βήμα

Η διαφορά ανάμεσα σε μια μεταφορά που παίρνει πέντε λεπτά ορατού downtime και μια που τρώει ένα Σαββατοκύριακο σπάνια είναι το hardware. Είναι το αν το cutover γράφτηκε ως ακολουθία χρονομετρημένων, ελέγξιμων, αναστρέψιμων βημάτων πριν από τη νύχτα, και αν έγινε πρόβα μέχρι οι χρόνοι να είναι γνωστοί. Έτσι γράφουμε εμείς αυτό το έγγραφο.

Το πρόβλημα: η νύχτα είναι η χειρότερη ώρα για σκέψη

Κάθε απόφαση που παίρνεται μέσα στο παράθυρο (ποιος συγχρονισμός πάει πρώτος, πόσο να περιμένουμε ένα replica, πότε να τα παρατήσουμε και να κάνουμε rollback) παίρνεται από κουρασμένους ανθρώπους υπό πίεση, συνήθως με τον ιδιοκτήτη του site στο τηλέφωνο. Ο στόχος ενός runbook είναι να μην χρειαστεί κανείς να αποφασίσει τίποτα μέσα στο παράθυρο που θα μπορούσε να έχει αποφασιστεί την προηγούμενη εβδομάδα.

Μια λίστα εργασιών δεν είναι runbook. Ένα runbook έχει πέντε στήλες.

Οι πέντε στήλες

Βήμα	Όριο	Υπεύθυνος	Επαλήθευση	Δρόμος επιστροφής
Πάγωμα των writes στην πηγή	2 λεπτά	app	η είσοδος διαχειριστή απορρίπτεται, η ουρά παραγγελιών άδεια	άρση του παγώματος
Τελικός συγχρονισμός αρχείων	3 λεπτά	ops	το rsync δεν αναφέρει άλλες αλλαγές	δεν χρειάζεται, η πηγή ανέγγιχτη
Τελικό catch-up και promotion της βάσης	3 λεπτά	db	GTID ίσο και στις δύο πλευρές, προορισμός σε read write	demotion του προορισμού, ξεπάγωμα της πηγής
Αλλαγή DNS και load balancer	2 λεπτά	net	το νέο origin απαντά μέσω του δημόσιου ονόματος	επαναφορά της εγγραφής
Smoke tests	5 λεπτά	app	λίστα σελίδων, είσοδος, checkout, αναζήτηση	επαναφορά DNS

Όριο είναι ο χρόνος που πήρε το βήμα στην πρόβα, συν ένα περιθώριο. Υπεύθυνος είναι ένα πρόσωπο, όχι μια ομάδα. Επαλήθευση είναι ένα παρατηρήσιμο γεγονός, όχι «φαίνεται εντάξει». Δρόμος επιστροφής είναι η ακριβής ενέργεια που αναιρεί το βήμα, και αν ένα βήμα δεν έχει δρόμο επιστροφής, είναι το σημείο χωρίς επιστροφή και πρέπει να σημειωθεί ως τέτοιο.

Πριν από το παράθυρο: μετακινήστε σχεδόν τα πάντα νωρίς

Το cutover πρέπει να μετακινεί μόνο ό,τι άλλαξε από τον τελευταίο συγχρονισμό. Όλα τα άλλα γίνονται μέρες πριν, ενώ η πηγή συνεχίζει να εξυπηρετεί:

• Χτίστε τον προορισμό από την αρχή σε μετρημένες προδιαγραφές, αντί να επαναφέρετε images των παλιών servers.
• Σπείρετε τη βάση δεδομένων από φυσικό backup και κρατήστε τη ενήμερη με replication. Τη νύχτα, το catch-up είναι θέμα δευτερολέπτων διαφοράς.
• Προσυγχρονίστε τα αρχεία επανειλημμένα, ώστε το τελευταίο πέρασμα να είναι μικρό. Κάντε ένα dry run την προηγούμενη μέρα για να δείτε τι θα μετακινήσει το τελικό πέρασμα:

rsync -aHAX --numeric-ids --delete --itemize-changes --dry-run \
      source:/var/www/ /var/www/ | wc -l

• Αντιγράψτε τα ευρετήρια αναζήτησης με το remote reindex της ίδιας της μηχανής αντί να ξαναπεράσετε το περιεχόμενο μέσα από την εφαρμογή.
• Χαμηλώστε τα TTL του DNS σε λίγα λεπτά τουλάχιστον δύο παλιά TTL πριν από το παράθυρο, ώστε οι resolvers να έχουν ξεχάσει τη μεγάλη τιμή μέχρι να αλλάξετε. Ελέγξτε τι βλέπει πραγματικά ο κόσμος:

dig +noall +answer www.example.com @<public-resolver-1>
dig +noall +answer www.example.com @<public-resolver-2>

Κάντε πρόβα σε αντίγραφο, με χρονόμετρο

Τρέξτε ολόκληρο το cutover σε ένα αντίγραφο του προορισμού τουλάχιστον μία φορά, με τις ίδιες εντολές, με τη σειρά, χρονομετρώντας κάθε βήμα. Η πρόβα παράγει τη στήλη του ορίου. Παράγει και τις εκπλήξεις: τον συγχρονισμό αρχείων που περπατά εκατομμύρια αμετάβλητα αρχεία αργά λόγω ενός flag που λείπει, τον χρήστη replication που δεν έχει ένα προνόμιο, το health check που δείχνει σε λάθος διαδρομή.

Προσθέστε κάθε μάθημα στο πρότυπο runbook, όχι μόνο στο αντίγραφο αυτής της μεταφοράς. Έτσι η δέκατη μεταφορά γίνεται ευκολότερη από την πρώτη.

Γράψτε τα κριτήρια go ή no go εκ των προτέρων

Συμφωνήστε, πριν από το παράθυρο και με τον ιδιοκτήτη του site, τι πρέπει να ισχύει για να ξεκινήσετε, και τι θα προκαλέσει rollback:

• Go: replication lag στον προορισμό κάτω από συμφωνημένο όριο, τελευταίος dry run συγχρονισμός εντός ορίου, monitoring στον προορισμό πράσινο, τα πρόσωπα της στήλης υπευθύνων παρόντα.
• Ενεργοποίηση rollback: οποιοδήποτε βήμα ξεπερνά το διπλάσιο του ορίου του, ή τα smoke tests δεν περνούν μέχρι μια καθορισμένη ώρα μετά την αλλαγή.

Το να γράψετε τον κανόνα αφαιρεί το πιο επικίνδυνο ένστικτο κάθε νύχτας cutover: «δώστε του δέκα λεπτά ακόμη». Αν το ρολόι λέει rollback, κάνετε rollback, και ξαναδοκιμάζετε άλλη νύχτα με καλύτερο runbook.

Κάντε τον δρόμο επιστροφής φθηνό

Ένα rollback που απαιτεί επαναφορά από backup δεν είναι rollback που θα επιλέξει κανείς να χρησιμοποιήσει. Σχεδιάστε κάθε βήμα ώστε η αναίρεσή του να είναι γρήγορη:

• Η πηγή μένει ανέγγιχτη και σε λειτουργία μέχρι ο προορισμός να αποδειχτεί. Τα δεδομένα της δεν διαγράφονται ποτέ μέσα στο παράθυρο.
• Στον προορισμό, ό,τι αντικαθίσταται μετονομάζεται, δεν αφαιρείται ποτέ. Η επιστροφή είναι μια μετονομασία και μια αλλαγή DNS.
• Το promotion της βάσης γίνεται μόνο αφού και οι δύο πλευρές αναφέρουν το ίδιο GTID, ώστε ένα demotion να σας επιστρέφει σε γνωστή θέση.
• Οι αλλαγές διαμόρφωσης εφαρμόζονται ως αρχεία που μπορείτε να εναλλάξετε, όχι ως επεξεργασίες που πρέπει να θυμάστε.

mv /var/www/site /var/www/site.pre-cutover-$(date +%F)
mv /var/www/site.new /var/www/site

Τρέξτε το παράθυρο, μετά ελέγξτε

Μέσα στο παράθυρο, ένα άτομο διαβάζει το runbook δυνατά και καταγράφει τον πραγματικό χρόνο απέναντι σε κάθε όριο. Κανείς δεν αυτοσχεδιάζει. Όταν περάσει το τελευταίο smoke test, κρατήστε την πηγή σε λειτουργία και παρακολουθήστε και τις δύο πλευρές: η κίνηση πρέπει να στραγγίζει από το παλιό origin καθώς λήγουν τα caches. Ό,τι συνεχίζει να φτάνει στην πηγή αφού περάσει το παλιό TTL είναι μια εξάρτηση που κανείς δεν κατέγραψε, όπως ένα cron job, ένας client API ή μια σκληρά κωδικοποιημένη διεύθυνση, και πρέπει να βρεθεί πριν σβήσει η πηγή.

Μετά, συγκρίνετε τη νέα πλατφόρμα με την παλιά βάση αναφοράς: εξωτερική έκθεση, χρόνοι απόκρισης, ποσοστό cache hit, ποσοστά σφαλμάτων. Μόνο τότε αποσύρετε την πηγή, και κρατήστε τα δεδομένα της μέχρι ο ιδιοκτήτης να υπογράψει.

Η λίστα ελέγχου σας

• Κάθε βήμα έχει όριο, υπεύθυνο, έλεγχο και δρόμο επιστροφής.
• Τα δεδομένα σπέρνονται και τα αρχεία προσυγχρονίζονται μέρες πριν. Το παράθυρο μετακινεί μόνο τη διαφορά.
• Τα TTL χαμηλωμένα νωρίς και επαληθευμένα από έξω.
• Μια χρονομετρημένη πρόβα σε αντίγραφο, με τα μαθήματα ενσωματωμένα στο πρότυπο.
• Κριτήρια go και rollback συμφωνημένα γραπτώς πριν από τη νύχτα.
• Η πηγή διατηρημένη ανέπαφη μέχρι να γίνει ο έλεγχος και να υπογράψει ο ιδιοκτήτης.

Αν μια μετακόμιση είναι στον ορίζοντά σας, ευχαρίστως να βοηθήσουμε να γραφτεί το runbook.

Μιλήστε με έναν μηχανικό

Related (rows[1])

Σχετικά: Μεταφορές datacenter με διαχείριση, με πρόβα · Replication βάσεων δεδομένων και offsite replicas · Live migration και έξοδος από hypervisor