Σημείωση. μετάφρ.: Αυτό το άρθρο συνεχίζει μια μεγάλη σειρά άρθρων από τον ευαγγελιστή της τεχνολογίας AWS Adrian Hornsby, ο οποίος σκοπεύει να εξηγήσει με απλό και ξεκάθαρο τρόπο τη σημασία του πειραματισμού για τον μετριασμό των συνεπειών των αστοχιών στα συστήματα πληροφορικής.
«Αν αποτύχεις να ετοιμάσεις ένα σχέδιο, τότε σκοπεύεις να αποτύχεις». - Βενιαμίν Φραγκλίνος
В Σε αυτήν τη σειρά άρθρων, εισήγαγα την έννοια της μηχανικής χάους και εξήγησα πώς βοηθάει να βρεθούν και να διορθωθούν ελαττώματα στο σύστημα προτού οδηγήσουν σε αστοχίες παραγωγής. Συζήτησε επίσης πώς η μηχανική χάους προάγει τη θετική πολιτιστική αλλαγή εντός των οργανισμών.
Στο τέλος του πρώτου μέρους, υποσχέθηκα να μιλήσω για «εργαλεία και μεθόδους για την εισαγωγή αστοχιών σε συστήματα». Δυστυχώς, το κεφάλι μου είχε τα δικά του σχέδια από αυτή την άποψη και σε αυτό το άρθρο θα προσπαθήσω να απαντήσω στην πιο δημοφιλή ερώτηση που προκύπτει μεταξύ των ανθρώπων που θέλουν να μπουν στη μηχανική του χάους: Τι να πρωτο σπάσει;
Μεγάλη ερώτηση! Ωστόσο, δεν φαίνεται να τον ενοχλεί ιδιαίτερα αυτό το πάντα...
Μην τα βάζετε με το χάος panda!
Σύντομη απάντηση: Στοχεύστε κρίσιμες υπηρεσίες κατά μήκος της διαδρομής αιτήματος.
Μεγαλύτερη αλλά πιο ξεκάθαρη απάντηση: Για να καταλάβετε από πού να αρχίσετε να πειραματίζεστε με το χάος, δώστε προσοχή σε τρεις τομείς:
- Κοιτάξτε ιστορικό συντριβής και να προσδιορίσει μοτίβα?
- Αποφασίζω για κρίσιμες εξαρτήσεις;
- Χρησιμοποιήστε το λεγόμενο αποτέλεσμα υπερβολικής αυτοπεποίθησης.
Είναι αστείο, αλλά αυτό το κομμάτι θα μπορούσε να ονομαστεί εξίσου εύκολα "Ένα ταξίδι στην ανακάλυψη του εαυτού και τη φώτιση". Σε αυτό θα αρχίσουμε να «παίζουμε» με μερικά ωραία όργανα.
1. Η απάντηση βρίσκεται στο παρελθόν
Αν θυμάστε, στο πρώτο μέρος εισήγαγα την έννοια της διόρθωσης σφαλμάτων (COE) - μια μέθοδο με την οποία αναλύουμε τα λάθη μας - λάθη στην τεχνολογία, τη διαδικασία ή τον οργανισμό - προκειμένου να κατανοήσουμε την αιτία τους και να αποτρέψουμε επανάληψη στο μέλλον. Σε γενικές γραμμές, από αυτό πρέπει να ξεκινήσετε.
«Για να καταλάβεις το παρόν, πρέπει να ξέρεις το παρελθόν». — Καρλ Σάγκαν
Κοιτάξτε το ιστορικό των αποτυχιών, επισημάνετε τις σε COE ή μεταθανάτιες εξετάσεις και ταξινομήστε τις. Προσδιορίστε κοινά πρότυπα που συχνά οδηγούν σε προβλήματα και για κάθε COE, κάντε την ακόλουθη ερώτηση:
«Θα μπορούσε αυτό να είχε προβλεφθεί και επομένως να αποφευχθεί με την έγχυση σφάλματος;»
Θυμάμαι μια αποτυχία στην αρχή της καριέρας μου. Θα μπορούσε να είχε αποφευχθεί εύκολα αν είχαμε πραγματοποιήσει μερικά απλά πειράματα χάους:
Υπό κανονικές συνθήκες, οι περιπτώσεις υποστήριξης ανταποκρίνονται σε ελέγχους υγείας από ). Η ELB χρησιμοποιεί αυτούς τους ελέγχους για να ανακατευθύνει αιτήματα σε υγιείς περιπτώσεις. Όταν αποδεικνύεται ότι μια περίπτωση είναι «ανθυγιεινή», η ELB σταματά να της στέλνει αιτήματα. Μια μέρα, μετά από μια επιτυχημένη εκστρατεία μάρκετινγκ, ο όγκος της επισκεψιμότητας αυξήθηκε και τα backends άρχισαν να ανταποκρίνονται στους υγειονομικούς ελέγχους πιο αργά από το συνηθισμένο. Πρέπει να πούμε ότι αυτοί οι υγειονομικοί έλεγχοι ήταν , δηλαδή ελέγχθηκε η κατάσταση των εξαρτήσεων.
Ωστόσο, όλα ήταν καλά για λίγο.
Στη συνέχεια, ήδη κάτω από μάλλον αγχωτικές συνθήκες, μια από τις περιπτώσεις άρχισε να εκτελεί μια μη κρίσιμη, τακτική εργασία cron ETL. Ο συνδυασμός υψηλής επισκεψιμότητας και cronjob ώθησε τη χρήση της CPU σχεδόν στο 100%. Η υπερφόρτωση της CPU επιβράδυνε περαιτέρω τις αποκρίσεις σε ελέγχους υγείας, τόσο πολύ που η ELB αποφάσισε ότι η παρουσία αντιμετώπιζε προβλήματα απόδοσης. Όπως ήταν αναμενόμενο, ο εξισορροπητής σταμάτησε να διανέμει κίνηση σε αυτόν, γεγονός που, με τη σειρά του, οδήγησε σε αύξηση του φόρτου στις υπόλοιπες περιπτώσεις του ομίλου.
Ξαφνικά, όλες οι άλλες περιπτώσεις άρχισαν επίσης να αποτυγχάνουν στον έλεγχο υγείας.
Η έναρξη μιας νέας παρουσίας απαιτούσε λήψη και εγκατάσταση πακέτων και χρειάστηκε πολύ περισσότερος χρόνος από ό,τι χρειάστηκε η ELB για να τα απενεργοποιήσει - ένα προς ένα - στην ομάδα αυτόματης κλιμάκωσης. Είναι ξεκάθαρο ότι σύντομα η όλη διαδικασία έφτασε σε κρίσιμο σημείο και η εφαρμογή ναυάγησε.
Τότε καταλάβαμε για πάντα τα ακόλουθα σημεία:
- Η εγκατάσταση λογισμικού κατά τη δημιουργία μιας νέας παρουσίας διαρκεί πολύ· είναι προτιμότερο να προτιμάτε την αμετάβλητη προσέγγιση και .
- Σε περίπλοκες καταστάσεις, οι απαντήσεις σε ελέγχους υγείας και ELB θα πρέπει να έχουν προτεραιότητα - το τελευταίο πράγμα που θέλετε είναι να περιπλέκετε τη ζωή για τις υπόλοιπες περιπτώσεις.
- Η τοπική αποθήκευση στην κρυφή μνήμη των ελέγχων υγείας βοηθά πολύ (ακόμα και για λίγα δευτερόλεπτα).
- Σε μια δύσκολη κατάσταση, μην εκτελείτε εργασίες cron και άλλες μη κρίσιμες διαδικασίες - εξοικονομήστε πόρους για τις πιο σημαντικές εργασίες.
- Κατά την αυτόματη κλιμάκωση, χρησιμοποιήστε μικρότερες παρουσίες. Μια ομάδα 10 μικρών δειγμάτων είναι καλύτερη από μια ομάδα 4 μεγάλων δειγμάτων. Εάν ένα παράδειγμα αποτύχει, στην πρώτη περίπτωση το 10% της κίνησης θα κατανεμηθεί σε 9 σημεία, στη δεύτερη - το 25% της κίνησης σε τρία σημεία.
Ετσι, θα μπορούσε αυτό να είχε προβλεφθεί και επομένως να αποφευχθεί με την εισαγωγή του προβλήματος;
Ναί, και με διάφορους τρόπους.
Πρώτον, προσομοιώνοντας υψηλή χρήση CPU χρησιμοποιώντας εργαλεία όπως π.χ ή :
❯ stress-ng --matrix 1 -t 60s
άγχος
Δεύτερον, υπερφορτώνοντας την παρουσία με και άλλα παρόμοια βοηθητικά προγράμματα:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Τα πειράματα είναι σχετικά απλά, αλλά μπορούν να προσφέρουν κάποια καλή τροφή για σκέψη χωρίς να χρειάζεται να περάσετε από το άγχος μιας πραγματικής αποτυχίας.
Αλλά μην σταματάς εκεί. Προσπαθήστε να αναπαράγετε τη συντριβή σε ένα δοκιμαστικό περιβάλλον και ελέγξτε την απάντησή σας στην ερώτηση "Θα μπορούσε αυτό να είχε προβλεφθεί και επομένως να αποφευχθεί με την εισαγωγή ενός σφάλματος;" Αυτό είναι ένα μίνι πείραμα χάους μέσα σε ένα πείραμα χάους για να ελέγξει τις υποθέσεις, αλλά ξεκινά με μια αποτυχία.
Ήταν όνειρο ή όντως συνέβη;
Μελετήστε λοιπόν την ιστορία των αποτυχιών, αναλύστε EOC, προσθέστε ετικέτα και ταξινομήστε τους με βάση την "ακτίνα επιτυχίας"—ή ακριβέστερα, τον αριθμό των πελατών που επηρεάζονται—και, στη συνέχεια, αναζητήστε μοτίβα. Ρωτήστε τον εαυτό σας εάν αυτό θα μπορούσε να είχε προβλεφθεί και αποφευχθεί με την εισαγωγή του προβλήματος. Ελεγξε την απάντησή σου.
Στη συνέχεια, μεταβείτε στα πιο κοινά μοτίβα με το μεγαλύτερο εύρος.
2. Δημιουργήστε έναν χάρτη εξάρτησης
Αφιερώστε λίγο χρόνο για να σκεφτείτε την αίτησή σας. Υπάρχει ξεκάθαρος χάρτης των εξαρτήσεών του; Ξέρετε τι αντίκτυπο θα έχουν αν υπάρξει αποτυχία;
Εάν δεν είστε πολύ εξοικειωμένοι με τον κώδικα της εφαρμογής σας ή έχει γίνει πολύ μεγάλος, μπορεί να είναι δύσκολο να κατανοήσετε τι κάνει ο κώδικας και ποιες είναι οι εξαρτήσεις του. Η κατανόηση αυτών των εξαρτήσεων και της πιθανής επίδρασής τους στην εφαρμογή και στους χρήστες είναι κρίσιμη για να γνωρίζουμε από πού να ξεκινήσουμε με τη μηχανική χάους: το σημείο εκκίνησης είναι το στοιχείο με τη μεγαλύτερη ακτίνα κρούσης.
Ο εντοπισμός και η τεκμηρίωση εξαρτήσεων ονομάζεται "δημιουργία χάρτη εξάρτησης» (χαρτογράφηση εξάρτησης). Αυτό γίνεται συνήθως για εφαρμογές με μεγάλη βάση κώδικα που χρησιμοποιούν εργαλεία δημιουργίας προφίλ κώδικα. (προφίλ κώδικα) και όργανα (ενοργάνιση). Μπορείτε επίσης να δημιουργήσετε έναν χάρτη παρακολουθώντας την κυκλοφορία του δικτύου.
Ωστόσο, δεν είναι όλες οι εξαρτήσεις ίδιες (πράγμα που περιπλέκει περαιτέρω τη διαδικασία). Μερικοί κρίσιμος, άλλα - δευτερεύων (τουλάχιστον θεωρητικά, καθώς τα σφάλματα συμβαίνουν συχνά λόγω προβλημάτων με εξαρτήσεις που θεωρήθηκαν μη κρίσιμες).
Χωρίς κρίσιμες εξαρτήσεις, η υπηρεσία δεν μπορεί να λειτουργήσει. Μη κρίσιμες εξαρτήσεις "δεν θα έπρεπε» να επηρεάσει το σέρβις σε περίπτωση πτώσης. Για να κατανοήσετε τις εξαρτήσεις, πρέπει να έχετε σαφή κατανόηση των API που χρησιμοποιούνται από την εφαρμογή σας. Αυτό μπορεί να είναι πολύ πιο δύσκολο από όσο φαίνεται - τουλάχιστον για μεγάλες εφαρμογές.
Ξεκινήστε περνώντας από όλα τα API. Επισημάνετε τα περισσότερα σημαντική και κρίσιμη. Παίρνω зависимости από το αποθετήριο κώδικα, ελέγξτε το αρχεία καταγραφής σύνδεσης, μετά προβολή τεκμηρίωση (φυσικά, αν υπάρχει - διαφορετικά έχετε ακόμαоμεγαλύτερα προβλήματα). Χρησιμοποιήστε τα εργαλεία για να δημιουργία προφίλ και ανίχνευση, φιλτράρετε τις εξωτερικές κλήσεις.
Μπορείτε να χρησιμοποιήσετε προγράμματα όπως netstat - ένα βοηθητικό πρόγραμμα γραμμής εντολών που εμφανίζει μια λίστα με όλες τις συνδέσεις δικτύου (ενεργές υποδοχές) στο σύστημα. Για παράδειγμα, για να παραθέσετε όλες τις τρέχουσες συνδέσεις, πληκτρολογήστε:
❯ netstat -a | more
Στο AWS μπορείτε να χρησιμοποιήσετε (αρχεία καταγραφής ροής) Το VPC είναι μια μέθοδος που σας επιτρέπει να συλλέγετε πληροφορίες σχετικά με την κίνηση IP που πηγαίνει προς ή από τις διεπαφές δικτύου σε ένα VPC. Τέτοια αρχεία καταγραφής μπορούν επίσης να βοηθήσουν με άλλες εργασίες - για παράδειγμα, την εύρεση απάντησης στο ερώτημα γιατί συγκεκριμένη επισκεψιμότητα δεν φτάνει στην παρουσία.
Μπορείτε επίσης να χρησιμοποιήσετε . Η ακτινογραφία σάς επιτρέπει να αποκτήσετε λεπτομερή, "απόλυτο" (από άκρη σε άκρη) επισκόπηση των αιτημάτων καθώς κινούνται στην εφαρμογή και δημιουργεί επίσης έναν χάρτη των υποκείμενων στοιχείων της εφαρμογής. Πολύ βολικό εάν χρειάζεται να προσδιορίσετε εξαρτήσεις.
Κονσόλα ακτίνων X AWS
Ένας χάρτης εξάρτησης δικτύου είναι μόνο μια μερική λύση. Ναι, δείχνει ποια εφαρμογή επικοινωνεί με ποια, αλλά υπάρχουν και άλλες εξαρτήσεις.
Πολλές εφαρμογές χρησιμοποιούν DNS για σύνδεση σε εξαρτήσεις, ενώ άλλες μπορεί να χρησιμοποιούν εντοπισμό υπηρεσίας ή ακόμα και διευθύνσεις IP με σκληρό κώδικα σε αρχεία διαμόρφωσης (π. /etc/hosts).
Για παράδειγμα, μπορείτε να δημιουργήσετε μέσω iptables και δες τι χαλάει. Για να το κάνετε αυτό, πληκτρολογήστε την ακόλουθη εντολή:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS μαύρη τρύπα
Αν βρίσκεστε στο /etc/hosts ή άλλα αρχεία διαμόρφωσης, θα βρείτε διευθύνσεις IP για τις οποίες δεν γνωρίζετε τίποτα (ναι, δυστυχώς, συμβαίνει και αυτό), μπορείτε να έρθετε ξανά στη διάσωση iptables. Ας πούμε ότι ανακάλυψες 8.8.8.8 και δεν ξέρω ότι αυτή είναι η δημόσια διεύθυνση διακομιστή DNS της Google. Με τη χρήση iptables Μπορείτε να αποκλείσετε την εισερχόμενη και την εξερχόμενη κίνηση σε αυτήν τη διεύθυνση χρησιμοποιώντας τις ακόλουθες εντολές:
❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
Κλείσιμο πρόσβασης
Ο πρώτος κανόνας απορρίπτει όλα τα πακέτα από το δημόσιο DNS της Google: ping λειτουργεί, αλλά τα πακέτα δεν επιστρέφονται. Ο δεύτερος κανόνας απορρίπτει όλα τα πακέτα που προέρχονται από το σύστημά σας στο δημόσιο DNS της Google - ως απόκριση σε ping παίρνουμε Η λειτουργία δεν επιτρέπεται.
Σημείωση: στη συγκεκριμένη περίπτωση θα ήταν καλύτερο να το χρησιμοποιήσετε whois 8.8.8.8, αλλά αυτό είναι απλώς ένα παράδειγμα.
Μπορούμε να πάμε ακόμα βαθύτερα στην τρύπα του κουνελιού, γιατί όλα όσα χρησιμοποιούν TCP και UDP εξαρτώνται στην πραγματικότητα και από την IP. Στις περισσότερες περιπτώσεις, η IP συνδέεται με το ARP. Μην ξεχνάτε τα τείχη προστασίας...
Αν πάρεις το κόκκινο χάπι, θα μείνεις στη Χώρα των Θαυμάτων και θα σου δείξω πόσο βαθιά πάει η τρύπα του κουνελιού».
Μια πιο ριζοσπαστική προσέγγιση είναι να σβήνω αυτοκίνητα ένα ένα και δείτε τι χάλασε... γίνετε «μαϊμού χάος». Φυσικά, πολλά συστήματα παραγωγής δεν έχουν σχεδιαστεί για μια τέτοια επίθεση ωμής βίας, αλλά τουλάχιστον μπορεί να δοκιμαστεί σε περιβάλλον δοκιμής.
Η δημιουργία ενός χάρτη εξάρτησης είναι συχνά μια πολύ χρονοβόρα επιχείρηση. Μίλησα πρόσφατα με έναν πελάτη που πέρασε σχεδόν 2 χρόνια αναπτύσσοντας ένα εργαλείο που δημιουργεί ημιαυτόματα χάρτες εξαρτήσεων για εκατοντάδες μικροϋπηρεσίες και εντολές.
Το αποτέλεσμα όμως είναι εξαιρετικά ενδιαφέρον και χρήσιμο. Θα μάθετε πολλά για το σύστημά σας, τις εξαρτήσεις και τις λειτουργίες του. Και πάλι, να είστε υπομονετικοί: είναι το ίδιο το ταξίδι που έχει τη μεγαλύτερη σημασία.
3. Προσοχή στην υπερβολική αυτοπεποίθηση
«Όποιος ονειρεύεται τι, πιστεύει σε αυτό». — Δημοσθένης
Έχετε ακούσει ποτέ για αποτέλεσμα υπερβολικής αυτοπεποίθησης?
Σύμφωνα με τη Wikipedia, το φαινόμενο υπερβολικής αυτοπεποίθησης είναι «μια γνωστική προκατάληψη στην οποία η εμπιστοσύνη ενός ατόμου στις πράξεις και τις αποφάσεις του είναι σημαντικά μεγαλύτερη από την αντικειμενική ακρίβεια αυτών των κρίσεων, ειδικά όταν το επίπεδο εμπιστοσύνης είναι σχετικά υψηλό».
Με βάση το ένστικτο και την εμπειρία...
Από την εμπειρία μου, αυτή η παραμόρφωση είναι μια μεγάλη υπόδειξη για το πού να ξεκινήσετε με τη μηχανική χάους.
Προσοχή στον χειριστή με υπερβολική αυτοπεποίθηση:
Τσάρλι: «Αυτό το πράγμα δεν έχει πέσει εδώ και πέντε χρόνια, όλα είναι καλά!»
Crash: "Περίμενε... Θα είμαι εκεί σύντομα!"
Η προκατάληψη ως συνέπεια της υπερβολικής αυτοπεποίθησης είναι κάτι ύπουλο και μάλιστα επικίνδυνο λόγω των διαφόρων παραγόντων που την επηρεάζουν. Αυτό ισχύει ιδιαίτερα όταν τα μέλη της ομάδας έχουν χύνει την καρδιά τους σε μια τεχνολογία ή έχουν αφιερώσει πολύ χρόνο για να την «διορθώσουν».
Ανακεφαλαίωση
Η αναζήτηση για ένα σημείο εκκίνησης για τη μηχανική χάους φέρνει πάντα περισσότερα αποτελέσματα από τα αναμενόμενα και οι ομάδες που αρχίζουν να σπάνε τα πράγματα πολύ γρήγορα χάνουν τα μάτια τους την πιο παγκόσμια και ενδιαφέρουσα ουσία του (χάος-)μηχανική - δημιουργική εφαρμογή επιστημονικές μεθόδους и εμπειρική απόδειξη για το σχεδιασμό, την ανάπτυξη, τη λειτουργία, τη συντήρηση και τη βελτίωση συστημάτων (λογισμικού).
Αυτό ολοκληρώνει το δεύτερο μέρος. Γράψτε κριτικές, μοιραστείτε απόψεις ή απλά χτυπήστε τα χέρια σας . Στο επόμενο μέρος Ι πραγματικά Θα εξετάσω εργαλεία και μεθόδους για την εισαγωγή αστοχιών σε συστήματα. Μέχρι!
ΥΓ από τον μεταφραστή
Διαβάστε επίσης στο blog μας:
- «"?
- «"?
- «"?
- «».
Πηγή: www.habr.com