Γράψτε πρώτα το rollback: ένα πρότυπο για αναβαθμίσεις ρουτίνας

Οι πλατφόρμες μένουν πίσω για έναν απλό λόγο: κάθε αναβάθμιση μοιάζει επικίνδυνη, οπότε αναβάλλεται, και κάθε αναβολή κάνει την επόμενη αναβάθμιση μεγαλύτερη και ακόμη πιο επικίνδυνη. Η διέξοδος είναι να κάνετε τις αναβαθμίσεις βαρετές. Αυτό σημαίνει ένα πρότυπο που ακολουθείτε κάθε φορά, και η πιο σημαντική γραμμή του είναι εκείνη που οι περισσότερες ομάδες γράφουν τελευταία: πώς γυρίζετε πίσω.

Μάθετε ότι υπάρχει μια έκδοση πριν τη χρειαστείτε

Δημοσιεύουμε κάθε νέο build, με το changelog του, στο chat λειτουργιών μας τη μέρα που κυκλοφορεί.

Μία βελτίωση αξίζει να αντιγραφεί. Πολλά έργα δημοσιεύουν διορθώσεις για παλιότερους κλάδους δίπλα στον τρέχοντα. Ένας watcher που ανακοινώνει τυφλά «νέα έκδοση» μπορεί να βάλει κάποιον στον πειρασμό να εγκαταστήσει ένα back-port παλιότερο από αυτό που ήδη τρέχει. Εμείς τα επισημαίνουμε αυτόματα ως «μην γίνει deploy», ώστε κανείς να μην κάνει βήμα πίσω κατά λάθος.

Προετοιμάστε την αλλαγή

Διαβάστε το changelog σαν συμβόλαιο

Στις σημειώσεις έκδοσης, τα migrations μετράνε περισσότερο: οτιδήποτε τρέχει μία φορά και δεν αναιρείται εύκολα, όπως μια αλλαγή σχήματος, καθορίζει τι πρέπει να περιλαμβάνει το rollback σας.

Προέλεγχος σε κάθε server

Μετά ελέγξτε κάθε server που θα αγγίξετε, όχι τον στόλο γενικά, και καταγράψτε τα plugins, τις επεκτάσεις και τις ενσωματώσεις του απέναντι στη νέα έκδοση.

Ένα plugin που κανείς δεν θυμόταν είναι ο πιο συνηθισμένος λόγος που μια κατά τα άλλα καθαρή αναβάθμιση αποτυγχάνει. Η καταγραφή τους ανά server παίρνει λεπτά και αφαιρεί την έκπληξη.

Πάρτε ένα backup που έχετε πράγματι κοιτάξει

«Η εργασία backup έτρεξε» δεν είναι το ίδιο με «έχουμε backup». Πριν από την αλλαγή, πάρτε ένα συνεπές dump και δοκιμάστε το:

mysqldump --single-transaction --routines --triggers --events <db> \
  | gzip > <db>-pre-upgrade-$(date +%F-%H%M).sql.gz
gzip -t <db>-pre-upgrade-*.sql.gz && ls -lh <db>-pre-upgrade-*.sql.gz

Γράψτε το rollback πριν από την αλλαγή

Αυτό είναι το βήμα που μετατρέπει μια επικίνδυνη αναβάθμιση σε ρουτίνα. Πριν ξεκινήσετε, γράψτε, με τη σειρά, τα ακριβή βήματα που θα επέστρεφαν το σύστημα εκεί όπου βρίσκεται τώρα. Σε συστήματα βασισμένα σε RPM η πλευρά των πακέτων είναι συνήθως σύντομη:

dnf history list | head
dnf history undo <transaction-id>

Και για να μην μετακινηθεί ένα γνωστό καλό πακέτο ενώ δοκιμάζετε, το plugin versionlock το καρφώνει:

dnf versionlock add <package>

Αλλά τα πακέτα σπάνια είναι όλη η ιστορία. Αν η έκδοση τρέχει migration σχήματος, το rollback μόνο των πακέτων σας αφήνει με παλιό κώδικα σε νέο σχήμα. Το rollback σας πρέπει τότε να περιλαμβάνει την επαναφορά του dump που μόλις πήρατε, και πρέπει να ξέρετε πόσο παίρνει αυτή η επαναφορά. Γράψτε τα όλα, και όπου μπορείτε, κάντε πρόβα πρώτα σε αντίγραφο. Ένα rollback που υπάρχει μόνο στο κεφάλι σας τη στιγμή που τα πράγματα πάνε στραβά δεν είναι rollback.

Αλλάξτε ένα μηχάνημα τη φορά

Σε πλεονάζουσες πλατφόρμες, έναν κόμβο τη φορά. Οι μεγάλες εκδόσεις πηγαίνουν πρώτα στα δικά μας instances και τρέχουν εκεί πριν τις λάβει οποιοδήποτε instance πελάτη.

Μετρήστε και επαληθεύστε

Μετρήστε το downtime αντί να το εκτιμάτε

«Περίπου ένα λεπτό» είναι εικασία. Ένα probe που τρέχει καθ' όλη τη διάρκεια της αλλαγής σας δίνει τον πραγματικό αριθμό. Ξεκινήστε το πριν αρχίσετε και σταματήστε το όταν τελειώσετε:

while true; do
  printf '%s %s\n' "$(date +%T.%3N)" \
    "$(curl -s -o /dev/null -m 2 -w '%{http_code}' https://<service>/health)"
  sleep 0.5
done | tee upgrade-probe-$(date +%F).log

Μετά, η πρώτη και η τελευταία γραμμή που δεν είναι 200 στο log οριοθετούν τη διακοπή με ακρίβεια μισού δευτερολέπτου. Αυτός είναι ο αριθμός που αναφέρετε στους ανθρώπους που εξαρτώνται από την υπηρεσία, και ο αριθμός με τον οποίο συγκρίνετε την επόμενη φορά. Σε ένα τρίμηνο, αυτές οι μετρήσεις είναι η καλύτερη απόδειξη που έχετε ότι οι αναβαθμίσεις γίνονται πιο ασφαλείς αντί πιο επικίνδυνες.

Επαληθεύστε από έξω, μετά φέρτε και το λειτουργικό

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

Το πρότυπο

1. Έκδοση εντοπισμένη και ανακοινωμένη, back-ports επισημασμένα.
2. Changelog διαβασμένο για διορθώσεις ασφαλείας, breaking changes και migrations.
3. Κάθε server με προέλεγχο, μαζί με κάθε plugin.
4. Φρέσκο backup ληφθέν και ελεγμένο.
5. Rollback γραμμένο, βήμα προς βήμα, πριν από την αλλαγή.
6. Ένας κόμβος τη φορά, οι μεγάλες εκδόσεις πρώτα στα δικά σας συστήματα.
7. Downtime μετρημένο από probe, αναφερόμενο σε δευτερόλεπτα.
8. Επαληθευμένο από έξω, λειτουργικό ενημερωμένο στο ίδιο παράθυρο.

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

Related (rows[1])

Σχετικά: Επικαιρότητα πλατφορμών και πειθαρχία αναβαθμίσεων · Άμεση απόκριση σε ευπάθειες την ίδια μέρα · Παρακολούθηση στόλου και δρομολόγηση συναγερμών