Ορίστε ασφαλή όρια για το self-healing

Αντιμετωπίστε μια γνωστή κατάσταση αστοχίας

Το self-healing εντοπίζει αυτόματα μια καθορισμένη αστοχία και επιχειρεί μια εξουσιοδοτημένη ενέργεια ανάκτησης. Παραδείγματα μπορεί να είναι η επανεκκίνηση μιας διεργασίας που απέτυχε ή η αντικατάσταση ενός instance που δεν λειτουργεί σωστά. Η ενέργεια πρέπει να ταιριάζει στην αστοχία και στο μοντέλο κατάστασης της υπηρεσίας.

Το Kubernetes μπορεί να αντικαθιστά instances φόρτου εργασίας που απέτυχαν και να επαναφέρει το σύστημα στη δηλωμένη κατάσταση. Αυτό δεν διορθώνει ελαττωματική λογική εφαρμογής ή κάθε αστοχία αποθήκευσης. Η ανάκτηση υποδομής και η ορθότητα λογισμικού χρειάζονται διαφορετικούς ελέγχους. Self-healing στο Kubernetes.

Ορίστε τον στόχο πριν από τον μηχανισμό. Η αποκατάσταση μιας εξαγωγής σημαίνει ότι οι εργασίες που πληρούν τις προϋποθέσεις ολοκληρώνονται σωστά. Ένα container που εκτελείται είναι μόνο μία προϋπόθεση.

Διαχωρίστε τρία είδη αλλαγής

Ένας agent μπορεί να προτείνει διόρθωση μετά την ανάκτηση. Αυτή η πρόταση είναι νέα αλλαγή λογισμικού. Δεν πρέπει να κληρονομεί απεριόριστη εξουσία από τον controller ανάκτησης.

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

Γράψτε την πολιτική ανάκτησης πριν την ενεργοποιήσετε

Η ακόλουθη πολιτική είναι υποθετική. Οι αριθμοί της δείχνουν επιλογές σχεδιασμού· δεν αποτελούν συνιστώμενες προεπιλογές.

Χρησιμοποιήστε ταυτότητα με τα ελάχιστα αναγκαία προνόμια. Καταγράψτε την έκδοση πολιτικής, τα στοιχεία ενεργοποίησης, την ενέργεια, τον πόρο και το αποτέλεσμα. Παρέχετε ανεξάρτητο τρόπο απενεργοποίησης του controller. Ορίστε τον άνθρωπο που είναι υπεύθυνος να λαμβάνει την κλιμάκωση.

Δοκιμάστε τις διαδρομές αστοχίας και την επιτυχημένη ανάκτηση

Μια επαναπροσπάθεια μπορεί να επαναλάβει μια παρενέργεια. Ένας worker μπορεί να αποθηκεύσει ένα αρχείο και να σταματήσει πριν επιβεβαιώσει την ολοκλήρωση της εργασίας. Επαληθεύστε την idempotency πριν επιτρέψετε άλλη εκτέλεση. Δείτε το παράδειγμα αστοχίας cloud native.

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

Δοκιμάστε την υποθετική πολιτική σε τρεις περιπτώσεις. Ένας μεμονωμένος worker που σταμάτησε πρέπει να ανακάμψει. Μια διακοπή της βάσης δεδομένων πρέπει να εμποδίσει την επαναλαμβανόμενη αντικατάσταση. Μια αβέβαιη αστοχία ακεραιότητας πρέπει να σταματήσει τον αυτοματισμό και να ζητήσει απόφαση απόκρισης.

Ελέγξτε επίσης την τηλεμετρία που λείπει. Η απουσία heartbeat μπορεί να σημαίνει αστοχία του worker ή της διαδρομής συλλογής. Ο controller χρειάζεται επαρκή στοιχεία για την ενέργειά του, όχι εμπιστοσύνη σε μια εξήγηση AI.

Μετρήστε αν βοηθά η πολιτική

Καταγράψτε επαληθευμένες ανακτήσεις, αποτυχημένες προσπάθειες, κλιμακώσεις, διπλή εκτέλεση εργασιών και διάρκεια αντικτύπου στους χρήστες. Συγκρίνετέ τα με την προηγούμενη μέθοδο λειτουργίας υπό παρόμοιες συνθήκες.

Κρατήστε το υποκείμενο ελάττωμα ως εργασία μηχανικής λογισμικού. Η επαναλαμβανόμενη επανεκκίνηση μιας διεργασίας με διαρροή μνήμης μπορεί να μειώνει τον άμεσο αντίκτυπο ενώ η διαρροή συνεχίζεται. Συνεχίστε με τη συνεχή βελτίωση για να συνδέσετε την παρατήρηση με μια διαρκή διόρθωση.