Ακόμη και κατά τη διάρκεια μιας καταστροφής, υπάρχει πάντα χρόνος για ένα φλιτζάνι τσάι.
DRP (σχέδιο αποκατάστασης από καταστροφή) είναι κάτι που ιδανικά δεν θα χρειαστεί ποτέ. Αλλά αν ξαφνικά οι κάστορες που μεταναστεύουν κατά τη διάρκεια της περιόδου ζευγαρώματος ροκανίσουν την κύρια οπτική ίνα ή ο κατώτερος διαχειριστής ρίξει την παραγωγική βάση, σίγουρα θέλετε να είστε σίγουροι ότι θα έχετε ένα προκατασκευασμένο σχέδιο για το τι να κάνετε με όλη αυτή την ατιμία.
Ενώ πανικόβλητοι πελάτες αρχίζουν να καλούν την τεχνική υποστήριξη, ένας νεότερος ψάχνει για κυάνιο, ανοίγεις σοφά τον κόκκινο φάκελο και αρχίζεις να τακτοποιείς τα πάντα.
Σε αυτήν την ανάρτηση, θέλω να μοιραστώ συστάσεις για το πώς να γράψετε ένα DRP και τι πρέπει να περιέχει. Θα δούμε επίσης τα εξής:
- Μάθε να σκέφτεσαι σαν κακός.
- Ας αναλύσουμε τα οφέλη ενός φλιτζανιού τσαγιού κατά τη διάρκεια της αποκάλυψης.
- Σκεφτείτε μια βολική δομή DRP
- Ας δούμε πώς να το δοκιμάσουμε
Ποιες εταιρείες θα μπορούσαν να ωφεληθούν από αυτό;
Είναι πολύ δύσκολο να τραβήξετε μια γραμμή όταν το τμήμα πληροφορικής αρχίζει να χρειάζεται αυτά τα πράγματα. Θα έλεγα ότι είναι σίγουρο ότι χρειάζεστε DRP εάν:
- Η διακοπή ενός διακομιστή, μιας εφαρμογής ή η απώλεια κάποιας βάσης δεδομένων θα οδηγήσει σε σημαντικές απώλειες για την επιχείρηση στο σύνολό της.
- Έχετε ένα πλήρες τμήμα πληροφορικής. Εννοώ, ένα τμήμα ως πλήρης μονάδα της εταιρείας, με δικό του προϋπολογισμό, και όχι μόνο μερικούς κουρασμένους υπαλλήλους που στρώνουν δίκτυο, καθαρίζουν ιούς και ξαναγεμίζουν εκτυπωτές.
- Έχετε έναν ρεαλιστικό προϋπολογισμό για τουλάχιστον μερική απόλυση σε περίπτωση έκτακτης ανάγκης.
Όταν το τμήμα IT ζητάει τουλάχιστον μερικούς σκληρούς δίσκους για έναν παλιό διακομιστή για αντίγραφα ασφαλείας για μήνες, είναι απίθανο να μπορέσετε να οργανώσετε μια πλήρη μετεγκατάσταση της πεσμένης υπηρεσίας σε πλεονάζουσες δυνατότητες. Αν και η τεκμηρίωση δεν θα είναι περιττή και εδώ.
Η τεκμηρίωση είναι σημαντική
Ξεκινήστε με την τεκμηρίωση. Ας πούμε ότι η υπηρεσία σας εκτελείται σε ένα σενάριο Perl που γράφτηκε πριν από τρεις γενιές διαχειριστών και κανείς δεν ξέρει πώς λειτουργεί. Το συσσωρευμένο τεχνικό χρέος και η έλλειψη τεκμηρίωσης αναπόφευκτα θα σας πυροβολήσουν όχι μόνο στο γόνατο, αλλά και σε άλλα άκρα, είναι μάλλον θέμα χρόνου.
Μόλις έχετε μια καλή περιγραφή των στοιχείων της υπηρεσίας, αυξήστε τα στατιστικά στοιχεία σφαλμάτων. Σχεδόν σίγουρα θα είναι εντελώς τυπικά. Για παράδειγμα, έχετε έναν δίσκο γεμάτο από καιρό σε καιρό, γεγονός που προκαλεί την αποτυχία του κόμβου μέχρι να καθαριστεί χειροκίνητα. Ή η υπηρεσία πελάτη δεν είναι διαθέσιμη λόγω του γεγονότος ότι κάποιος ξέχασε ξανά να ανανεώσει το πιστοποιητικό, αλλά δεν μπορούσε ή δεν ήθελε να ρυθμίσει το Let's Encrypt.
Σκέψεις σαν σαμποτέρ
Το πιο δύσκολο κομμάτι είναι να προβλέψετε εκείνα τα ατυχήματα που δεν έχουν συμβεί ποτέ στο παρελθόν, αλλά που θα μπορούσαν ενδεχομένως να καταστρέψουν την υπηρεσία σας εντελώς. Εδώ συνήθως παίζουμε κακούς με συναδέλφους. Πάρτε πολύ καφέ και κάτι νόστιμο και κλείστε τον εαυτό σας στην αίθουσα συσκέψεων. Απλώς βεβαιωθείτε ότι στην ίδια συνάντηση κλειδώσατε αυτούς τους μηχανικούς που οι ίδιοι ανέβασαν την υπηρεσία-στόχο ή συνεργάζονται τακτικά μαζί της. Στη συνέχεια, είτε στον πίνακα είτε στο χαρτί, αρχίζετε να σχεδιάζετε όλες τις πιθανές φρίκη που μπορεί να συμβούν στην υπηρεσία σας. Δεν είναι απαραίτητο να αναφερθούμε λεπτομερώς σε μια συγκεκριμένη καθαρίστρια και να τραβήξουμε καλώδια, αρκεί να εξετάσουμε το σενάριο «Παραβίαση της ακεραιότητας του τοπικού δικτύου».
Συνήθως, οι περισσότερες τυπικές καταστάσεις έκτακτης ανάγκης ταιριάζουν στους ακόλουθους τύπους:
- Αποτυχία δικτύου
- Αποτυχία υπηρεσίας λειτουργικού συστήματος
- Αποτυχία εφαρμογής
- αστοχία σιδήρου
- Αποτυχία εικονικοποίησης
Απλώς περάστε από κάθε προβολή και δείτε τι ισχύει για την υπηρεσία σας. Για παράδειγμα, ο δαίμονας Nginx μπορεί να πέσει και να μην ανέβει - αυτό είναι μια αποτυχία από την πλευρά του λειτουργικού συστήματος. Μια σπάνια κατάσταση που οδηγεί την εφαρμογή web σας σε κατάσταση μη λειτουργίας είναι μια αποτυχία λογισμικού. Κατά την ανάπτυξη αυτού του σταδίου, είναι σημαντικό να διερευνηθεί η διάγνωση του προβλήματος. Πώς να διακρίνετε μια κολλημένη διεπαφή σε εικονικοποίηση από μια πτώση του Cisco και μια κατάρρευση δικτύου, για παράδειγμα. Αυτό είναι σημαντικό για να βρείτε γρήγορα τους υπεύθυνους και να αρχίσετε να τραβάτε την ουρά τους μέχρι να διορθωθεί το ατύχημα.
Αφού καταγραφούν τα τυπικά προβλήματα, ρίχνουμε περισσότερο καφέ και αρχίζουμε να εξετάζουμε τα πιο περίεργα σενάρια, όταν κάποιες παράμετροι αρχίζουν να ξεπερνούν τον κανόνα. Για παράδειγμα:
- Τι συμβαίνει εάν ο χρόνος στον ενεργό κόμβο μετακινηθεί ένα λεπτό πίσω σε σχέση με άλλους στο σύμπλεγμα;
- Και αν ο χρόνος προχωρήσει, και αν κατά 10 χρόνια;
- Τι συμβαίνει εάν ένας κόμβος συμπλέγματος χάσει ξαφνικά το δίκτυο κατά τη διάρκεια του συγχρονισμού;
- Και τι συμβαίνει εάν δύο κόμβοι δεν μοιράζονται την ηγεσία λόγω προσωρινής απομόνωσης μεταξύ τους στο δίκτυο;
Σε αυτό το στάδιο, η αντίστροφη προσέγγιση βοηθάει πολύ. Πάρτε το πιο πεισματάρικο μέλος της ομάδας με αρρωστημένη φαντασία και δώστε του το καθήκον να κανονίσει μια εκτροπή στο συντομότερο δυνατό χρόνο, η οποία θα καταβάλει την υπηρεσία. Αν είναι δύσκολο να διαγνωστεί, ακόμα καλύτερα. Δεν θα πιστεύετε τις περίεργες και ωραίες ιδέες που σκέφτονται οι μηχανικοί όταν τους δίνεται η ιδέα να σπάσουν κάτι. Και αν τους υποσχεθείτε μια δοκιμαστική βάση για αυτό, είναι πολύ καλό.
Τι είναι αυτό το DRP σου;!
Έτσι έχετε ορίσει το μοντέλο απειλής σας. Έλαβαν επίσης υπόψη τους κατοίκους της περιοχής που έκοψαν καλώδια οπτικών ινών αναζητώντας χαλκό και ένα στρατιωτικό ραντάρ που ρίχνει μια γραμμή ραδιοφωνικού ρελέ αυστηρά την Παρασκευή στις 16:46. Τώρα πρέπει να καταλάβουμε τι να κάνουμε με όλα αυτά.
Το καθήκον σας είναι να γράψετε τους ίδιους κόκκινους φακέλους που θα ανοίξουν σε περίπτωση έκτακτης ανάγκης. Αμέσως να περιμένεις ότι όταν (όχι αν!) τα πάντα είναι στραβά, κοντά θα είναι μόνο ο πιο άπειρος ασκούμενος, του οποίου τα χέρια θα τρέμουν βίαια από τη φρίκη αυτού που συμβαίνει. Δείτε πώς εφαρμόζονται τα σήματα έκτακτης ανάγκης στα ιατρεία. Για παράδειγμα, τι να κάνετε με το αναφυλακτικό σοκ. Το ιατρικό προσωπικό γνωρίζει όλα τα πρωτόκολλα απέξω, αλλά όταν ένα άτομο που βρίσκεται κοντά αρχίζει να πεθαίνει, πολύ συχνά όλοι αρπάζουν αβοήθητοι τα πάντα. Για να γίνει αυτό, μια σαφής οδηγία κρέμεται στον τοίχο με αντικείμενα όπως «άνοιξε τη συσκευασία του τάδε» και «ενέσε τόσες πολλές μονάδες του φαρμάκου ενδοφλεβίως».
Είναι δύσκολο να σκεφτείς σε περίπτωση έκτακτης ανάγκης! Θα πρέπει να υπάρχουν απλές οδηγίες για την ανάλυση της σπονδυλικής στήλης.
Ένα καλό DRP αποτελείται από μερικά απλά μπλοκ:
- Ποιον να ειδοποιήσουμε για την έναρξη του ατυχήματος. Αυτό είναι σημαντικό προκειμένου να παραλληλιστεί όσο το δυνατόν περισσότερο η διαδικασία εξάλειψης.
- Πώς να κάνετε σωστά τη διάγνωση - ανιχνεύουμε, αναζητούμε στο όνομα υπηρεσίας κατάστασης systemctl και ούτω καθεξής.
- Πόσος χρόνος μπορεί να αφιερωθεί σε κάθε στάδιο. Εάν δεν έχετε χρόνο να το διορθώσετε με τα χέρια σας κατά τη διάρκεια του χρόνου SLA, η εικονική μηχανή σκοτώνεται και τυλίσσεται από το χθεσινό αντίγραφο ασφαλείας.
- Πώς να βεβαιωθείτε ότι η συντριβή έχει τελειώσει.
Να θυμάστε ότι το DRP ξεκινά όταν η υπηρεσία έχει αποτύχει εντελώς και ολοκληρώνεται με ανάκτηση, ακόμη και με μειωμένη απόδοση. Η απλή απώλεια μιας κράτησης δεν πρέπει να ενεργοποιεί το DRP. Μπορείτε επίσης να συνταγογραφήσετε ένα φλιτζάνι τσάι σε DRP. Σοβαρά. Σύμφωνα με στατιστικά στοιχεία, πολλά ατυχήματα γίνονται από δυσάρεστα σε καταστροφικά λόγω του γεγονότος ότι το προσωπικό σε πανικό σπεύδει να διορθώσει κάτι, σκοτώνοντας ταυτόχρονα τον μοναδικό ζωντανό κόμβο με δεδομένα ή τελικά τελειώνοντας το σύμπλεγμα. Κατά κανόνα, 5 λεπτά για ένα φλιτζάνι τσάι θα σας δώσουν λίγο χρόνο για να ηρεμήσετε και να αναλύσετε τι συμβαίνει.
Μην συγχέετε DRP και διαβατήριο συστήματος! Μην το υπερφορτώνετε με περιττά δεδομένα. Απλώς δώστε την ευκαιρία να μεταβείτε γρήγορα και εύκολα στην απαιτούμενη ενότητα της τεκμηρίωσης μέσω υπερσυνδέσμων και να διαβάσετε σε εκτεταμένη μορφή σχετικά με τις απαραίτητες ενότητες της αρχιτεκτονικής υπηρεσίας. Και στο ίδιο το DRP, υπάρχουν μόνο άμεσες οδηγίες για το πού και πώς να συνδεθείτε με συγκεκριμένες εντολές για αντιγραφή-επικόλληση.
Πώς να δοκιμάσετε σωστά
Βεβαιωθείτε ότι οποιοσδήποτε υπεύθυνος υπάλληλος είναι σε θέση να ολοκληρώσει όλα τα στοιχεία. Την πιο κρίσιμη στιγμή, μπορεί να αποδειχθεί ότι ο μηχανικός δεν έχει δικαιώματα πρόσβασης στο απαιτούμενο σύστημα, δεν υπάρχουν κωδικοί πρόσβασης για τον απαιτούμενο λογαριασμό ή δεν έχει ιδέα τι "Σύνδεση με την κονσόλα διαχείρισης υπηρεσιών μέσω διακομιστή μεσολάβησης στο έδρα» σημαίνει. Κάθε στοιχείο πρέπει να είναι όσο το δυνατόν πιο απλό.
Λάθος - "Μετάβαση στην εικονικοποίηση και επανεκκίνηση του νεκρού κόμβου"
Σωστά - "Συνδεθείτε μέσω της διεπαφής ιστού στο virt.example.com, στην ενότητα κόμβων, φορτώστε ξανά τον κόμβο που προκαλεί το σφάλμα."
Αποφύγετε την ασάφεια. Θυμηθείτε τον φοβισμένο οικότροφο.
Βεβαιωθείτε ότι έχετε δοκιμάσει το DRP. Αυτό δεν είναι απλώς ένα σχέδιο επίδειξης - είναι κάτι που θα επιτρέψει σε εσάς και τους πελάτες σας να βγείτε γρήγορα από μια κρίσιμη κατάσταση. Είναι καλύτερο να το κάνετε αυτό πολλές φορές:
- Ένας ειδικός και αρκετοί ασκούμενοι εργάζονται σε έναν πάγκο δοκιμών που μιμείται όσο το δυνατόν περισσότερο μια πραγματική υπηρεσία. Ο ειδικός σπάει την υπηρεσία με διάφορους τρόπους και δίνει τη δυνατότητα στους εκπαιδευόμενους να την αποκαταστήσουν σύμφωνα με το DRP. Όλα τα προβλήματα, οι ασάφειες στην τεκμηρίωση και τα λάθη καταγράφονται. Μετά την εκπαίδευση των εκπαιδευομένων, το DRP συμπληρώνεται και απλοποιείται σε σκοτεινά σημεία.
- Δοκιμή σε πραγματική υπηρεσία. Στην πραγματικότητα, δεν μπορείτε ποτέ να δημιουργήσετε ένα τέλειο αντίγραφο μιας πραγματικής υπηρεσίας. Επομένως, μερικές φορές το χρόνο είναι απαραίτητο να απενεργοποιήσετε μέρος των διακομιστών σε προγραμματισμένη βάση, να διακόψετε τις συνδέσεις και να κανονίσετε άλλα ατυχήματα από τη λίστα απειλών, προκειμένου να αξιολογηθεί η εντολή ανάκτησης. Είναι καλύτερο να έχετε μια προγραμματισμένη διακοπή λειτουργίας 10 λεπτών στη μέση της νύχτας παρά μια ξαφνική αστοχία για αρκετές ώρες σε αιχμή φορτίου με απώλεια δεδομένων.
- Πραγματική εξάλειψη του ατυχήματος. Ναι, είναι και αυτό μέρος της δοκιμής. Εάν συμβεί ένα ατύχημα που δεν ήταν στη λίστα των απειλών, είναι απαραίτητο να συμπληρωθεί και να οριστικοποιηθεί το DRP με βάση τα αποτελέσματα της έρευνάς του.
Βασικά σημεία
- Αν μπορούν να γίνουν μαλακίες, δεν θα συμβεί απλώς, αλλά θα το κάνει στο πιο καταστροφικό σενάριο.
- Βεβαιωθείτε ότι έχετε τους πόρους για failover.
- Βεβαιωθείτε ότι έχετε αντίγραφα ασφαλείας, δημιουργούνται αυτόματα και ελέγχονται τακτικά για συνέπεια.
- Εξετάστε τυπικά σενάρια απειλής.
- Δώστε στους μηχανικούς την ευκαιρία να βρουν μη τυπικές επιλογές για την παροχή της υπηρεσίας.
- Το DRP πρέπει να είναι απλές και χαζές οδηγίες. Όλα τα πολύπλοκα διαγνωστικά γίνονται μόνο αφού οι πελάτες έχουν αποκαταστήσει την υπηρεσία. Ακόμα κι αν είναι σε αναμονή.
- Καταχωρίστε βασικούς αριθμούς τηλεφώνου και επαφές στο DRP.
- Ελέγχετε τακτικά τους υπαλλήλους για την κατανόηση του DRP.
- Τακτοποιήστε τα προγραμματισμένα ατυχήματα στο προϊόν. Τα περίπτερα δεν μπορούν να αντικαταστήσουν τα πάντα.
Πηγή: www.habr.com