Disaster recovery, backup, RTO/RPO, failover και πάνω απ’ όλα το ερώτημα που πολλές εταιρείες θέτουν στον εαυτό τους μόνο μετά από μια βλάβη: μπορούμε πραγματικά να αποκαταστήσουμε το σύστημα και να επιστρέψουμε στη δουλειά;
Βλάβη διακομιστή. Κατεστραμμένη βάση δεδομένων. Σφάλμα μετά από ανάπτυξη. Ransomware. Προβλήματα με τον πάροχο υποδομής. Τυχαία διαγραφή δεδομένων. Βλάβη ολόκληρης περιοχής.
Τα σενάρια είναι πολλά. Το πρόβλημα είναι ότι οι περισσότερες εταιρείες προετοιμάζονται κυρίως για να μην συμβεί η βλάβη.
Και πολύ πιο σπάνια προετοιμάζονται για την περίπτωση που τελικά συμβεί.
Αυτό ακριβώς είναι το πεδίο του disaster recovery.
Και εδώ προκύπτει το βασικό ερώτημα: αν η εφαρμογή σας σταματήσει να λειτουργεί σήμερα στις 14:00, πόσος χρόνος χρειάζεται για να την επανεκκινήσετε και πόσα δεδομένα μπορείτε να χάσετε;
Αν η απάντηση είναι «έχουμε backup», αυτό δεν είναι ακόμα απάντηση σε αυτό το ερώτημα.
Το backup δεν είναι disaster recovery
Το backup είναι αντίγραφο δεδομένων. Το disaster recovery είναι η διαδικασία αποκατάστασης της λειτουργίας του συστήματος.
Αυτή είναι μια πολύ σημαντική διάκριση.
Μπορεί να δημιουργούνται καθημερινά αντίγραφα της βάσης δεδομένων σας και παρ’ όλα αυτά να μην ξέρετε:
-
αν το τελευταίο αντίγραφο είναι σωστό,
-
αν μπορεί να αποκατασταθεί,
-
πόσο θα διαρκέσει η αποκατάσταση,
-
αν μετά την αποκατάσταση η βάση θα συνεργάζεται με την τρέχουσα έκδοση της εφαρμογής,
-
αν θα αποκαταστήσετε επίσης τη διαμόρφωση του συστήματος,
-
αν διαθέτετε όλα τα κλειδιά, τα πιστοποιητικά και τα μυστικά που απαιτούνται για την εκκίνηση του περιβάλλοντος,
-
αν η υποδομή που απαιτείται για την εκκίνηση της εφαρμογής είναι ακόμη διαθέσιμη,
-
ποιος πρέπει να εκτελέσει τα επιμέρους βήματα,
-
αν όλη η διαδικασία χωρά μέσα στον χρόνο που είναι αποδεκτός για την επιχείρηση.
Το NIST επισημαίνει ρητά την ανάγκη δοκιμής της επαναφοράς αντιγράφων ασφαλείας, ενώ οι τρέχουσες οδηγίες της AWS αντιμετωπίζουν επίσης τις περιοδικές δοκιμές recovery ως τρόπο ελέγχου αν το backup επιτρέπει πραγματικά την επίτευξη των καθορισμένων RTO και RPO.
Γι’ αυτό το backup είναι στοιχείο της στρατηγικής recovery και όχι το πλήρες ισοδύναμό της.
Το πιο σημαντικό ερώτημα: τι θα συμβεί μετά τη βλάβη;
Ας φανταστούμε ένα ηλεκτρονικό κατάστημα.
Στις 10:17 η βάση δεδομένων σταματά να ανταποκρίνεται.
Ο διακομιστής της εφαρμογής εξακολουθεί να λειτουργεί, αλλά οι χρήστες δεν μπορούν να συνδεθούν. Οι παραγγελίες δεν λειτουργούν. Ο πίνακας διαχείρισης σταματά να ανταποκρίνεται. Το σύστημα πληρωμών δεν λαμβάνει σωστές πληροφορίες.
Η ομάδα ελέγχει την κατάσταση.
Αποδεικνύεται ότι το τελευταίο backup της βάσης έγινε στις 8:00.
Θεωρητικά, τα δεδομένα μπορούν να ανακτηθούν.
Αλλά τότε προκύπτουν νέα ερωτήματα;
- Γνωρίζουμε πού βρίσκεται το αντίγραφο;
- Γνωρίζουμε πώς να το επαναφέρουμε;
- Είναι διαθέσιμο το άτομο που ξέρει να το κάνει;
- Είναι το backup πλήρες;
- Η διαμόρφωση της εφαρμογής αντιστοιχεί στην έκδοση που είναι αποθηκευμένη στο αντίγραφο;
- Θα λειτουργεί η βάση μετά την αποκατάσταση με την τρέχουσα εφαρμογή;
- Και το πιο σημαντικό: πόσος χρόνος θα χρειαστεί για να επανέλθει η λειτουργία του καταστήματος;
Αν κανείς δεν το έχει ελέγξει νωρίτερα, η απάντηση μπορεί να είναι έκπληξη.
RTO - πόση διακοπή λειτουργίας μπορούμε να αποδεχτούμε;
Το RTO, δηλαδή Recovery Time Objective, καθορίζει τον μέγιστο αποδεκτό χρόνο αποκατάστασης του συστήματος μετά από βλάβη.
Για παράδειγμα: RTO = 4 ώρες σημαίνει ότι ο οργανισμός θεωρεί αποδεκτό να αποκαταστήσει τη λειτουργία του συστήματος μέσα σε το πολύ τέσσερις ώρες.
Αυτό όμως δεν σημαίνει ότι κάθε εφαρμογή πρέπει να έχει RTO τεσσάρων ωρών.
Για ένα εσωτερικό σύστημα που χρησιμοποιείται λίγες φορές την ημέρα, ένας τέτοιος χρόνος μπορεί να είναι αποδεκτός. Για μια πλατφόρμα πωλήσεων που λειτουργεί 24/7 μπορεί να σημαίνει πολύ σοβαρές απώλειες.
Το RTO πρέπει λοιπόν να προκύπτει από την επιχείρηση και όχι από αυτό που προσφέρει αυτή τη στιγμή η υποδομή.
Το NIST ορίζει το RTO ως τον χρόνο κατά τον οποίο το σύστημα μπορεί να παραμένει στη φάση ανάκτησης πριν αυτό επηρεάσει αρνητικά τη λειτουργία του οργανισμού.
RPO - πόσα δεδομένα μπορούμε να χάσουμε;
Η δεύτερη βασική παράμετρος είναι το RPO, δηλαδή το Recovery Point Objective.
Το RPO απαντά στο ερώτημα: πόσο πίσω μπορούμε να επιστρέψουμε με τα δεδομένα μετά από μια βλάβη;
Παράδειγμα: RPO = 1 ώρα σημαίνει ότι ο οργανισμός αποδέχεται πιθανή απώλεια το πολύ περίπου μίας ώρας δεδομένων.
Αν το σύστημα υποστεί βλάβη στις 15:00 και το τελευταίο αντίγραφο που μπορεί να χρησιμοποιηθεί προέρχεται από τις 14:00, τότε ακριβώς αυτό το σενάριο εμπίπτει στο καθορισμένο RPO. Αλλά αν το backup εκτελείται μία φορά την ημέρα, δύσκολα μπορεί να αναμένεται RPO στο επίπεδο της μίας ώρας.
Το RPO επηρεάζει λοιπόν άμεσα τον τρόπο λήψης αντιγράφων, την αναπαραγωγή δεδομένων και τον σχεδιασμό της υποδομής.
Το RTO μας λέει κυρίως για πόσο χρόνο μπορούμε να είμαστε μη διαθέσιμοι.
Το RPO λέει πόσα δεδομένα μπορούμε να χάσουμε.
Αυτές οι δύο παράμετροι θα πρέπει να καθορίζονται μαζί με την επιχείρηση, επειδή η επίτευξή τους συνδέεται με κόστος και τεχνικές λύσεις. Η Microsoft επίσης υπογραμμίζει ότι τα RTO και RPO θα πρέπει να προκύπτουν από πραγματικές επιχειρησιακές απαιτήσεις και όχι από την αφηρημένη υπόθεση «μηδενική διακοπή και μηδενική απώλεια δεδομένων».
Το backup μπορεί να υπάρχει και παρ’ όλα αυτά να είναι άχρηστο
Αυτός είναι ένας από τους πιο επικίνδυνους μύθους στην IT.
Το «το backup εκτελείται σωστά» δεν σημαίνει αυτόματα: «το σύστημα μπορεί να αποκατασταθεί από αυτό».
Το αντίγραφο μπορεί να είναι ελλιπές. Μπορεί να είναι κατεστραμμένο. Μπορεί να περιέχει δεδομένα που δεν μπορούν να χρησιμοποιηθούν σωστά. Μπορεί να έχει δημιουργηθεί με τρόπο που δεν επιτρέπει την επαναφορά ολόκληρου του περιβάλλοντος.
Γι’ αυτό το backup πρέπει να δοκιμάζεται μέσω πραγματικής επαναφοράς.
Δεν αρκεί να ελέγξετε αν το αρχείο υπάρχει.
Πρέπει να το επαναφέρετε.
Να εκκινήσετε το σύστημα.
Να ελέγξετε τα δεδομένα.
Να επαληθεύσετε τις εξαρτήσεις.
Να ελέγξετε τη διαμόρφωση.
Να μετρήσετε τον χρόνο.
Και να απαντήσετε στο ερώτημα αν το αποτέλεσμα ανταποκρίνεται στις παραδοχές του RTO και του RPO.
Η AWS, ως τυπικό σφάλμα, επισημαίνει ακριβώς την επαναφορά backup χωρίς έλεγχο αν ο αποκατεστημένος πόρος λειτουργεί πραγματικά και αν μπορούν να χρησιμοποιηθούν τα ανακτημένα δεδομένα.
Failover - όταν δεν θέλουμε να περιμένουμε την αποκατάσταση
Δεν μπορεί κάθε εφαρμογή να αντέξει μερικές ώρες αναμονής για επαναφορά. Σε τέτοιες περιπτώσεις χρησιμοποιούνται, μεταξύ άλλων, μηχανισμοί failover.
Το failover σημαίνει μετάβαση της λειτουργίας από το κύριο περιβάλλον σε ένα προετοιμασμένο εφεδρικό περιβάλλον.
Μπορεί να είναι:
-
εφεδρικός διακομιστής,
-
δεύτερη ζώνη διαθεσιμότητας,
-
δεύτερη περιοχή,
-
αντίγραφο βάσης δεδομένων,
-
περιβάλλον standby,
-
εναλλακτική υποδομή έτοιμη για εκκίνηση.
Στο απλούστερο μοντέλο η εφαρμογή λειτουργεί σε ένα σημείο και, σε περίπτωση βλάβης, ενεργοποιούμε το εφεδρικό περιβάλλον. Σε πιο προχωρημένες λύσεις, μέρος της υποδομής λειτουργεί παράλληλα και είναι έτοιμο να αναλάβει την κίνηση.
Ωστόσο, δεν υπάρχει μία και μοναδική στρατηγική κατάλληλη για όλους.
Τα backup και το restore είναι συνήθως φθηνότερα, αλλά μπορεί να σημαίνουν μεγαλύτερο χρόνο αποκατάστασης. Λύσεις τύπου warm standby ή ενεργή πλεονάζουσα υποδομή μπορούν να μειώσουν σημαντικά το recovery, αλλά απαιτούν μεγαλύτερη επένδυση και πιο σύνθετη υποδομή.
Το failover πρέπει επίσης να δοκιμάζεται
Εδώ προκύπτει ένα ακόμη πρόβλημα.
Μια εταιρεία μπορεί να έχει εφεδρικό περιβάλλον, αλλά να μην το έχει χρησιμοποιήσει εδώ και δύο χρόνια;
- Λειτουργεί ακόμα;
- Η διαμόρφωση αντιστοιχεί στην παραγωγή;
- Έχει επαρκή απόδοση;
- Είναι διαθέσιμες όλες οι υπηρεσίες;
- Τα πιστοποιητικά είναι ενημερωμένα;
- Θα γίνει σωστά η εναλλαγή DNS;
- Θα συνδεθεί η εφαρμογή στη βάση δεδομένων;
- Θα λειτουργήσει ο μηχανισμός εξουσιοδότησης;
- Ξέρει η ομάδα ακριβώς τι πρέπει να κάνει;
Μόνο το τεστ απαντά σε αυτά τα ερωτήματα.
Η AWS συνιστά τακτικό testing του failover ακριβώς για να επαληθεύεται η λειτουργία της διαδρομής αποκατάστασης και να ελέγχεται αν τα πραγματικά RTO και RPO ανταποκρίνονται στις παραδοχές.
Ένα περιβάλλον disaster recovery που δεν έχει ποτέ δοκιμαστεί είναι μόνο εν μέρει μια παραδοχή.
Το disaster recovery δεν είναι μόνο υποδομή
Είναι εύκολο να βλέπουμε το DR μόνο μέσα από το πρίσμα των διακομιστών.
Αυτό είναι λάθος.
Η αποκατάσταση περιλαμβάνει επίσης:
- Δεδομένα
Καλύπτονται όλα τα σημαντικά δεδομένα από προστασία; - Εφαρμογή
Έχουμε τη σωστή έκδοση του κώδικα και τη δυνατότητα να τη διαθέσουμε; - Ρυθμίσεις
Ξέρουμε ποιες παραμέτρους χρειάζονται για την εκκίνηση του συστήματος; - Μυστικά και πιστοποιητικά
Έχουμε ασφαλή πρόσβαση σε κλειδιά, tokens και πιστοποιητικά; - Εξωτερικές εξαρτήσεις
Τι θα συμβεί αν δεν είναι διαθέσιμο ένα εξωτερικό σύστημα πληρωμών, ένα API, ο πάροχος ταυτότητας ή μια υπηρεσία SaaS; - Υποδομή
Έχουμε μέρος όπου μπορεί να εκτελεστεί η εφαρμογή; - Άνθρωποι
Είναι γνωστό ποιος παίρνει την απόφαση για την ενεργοποίηση της διαδικασίας; - Διαδικασίες
Υπάρχει συγκεκριμένο runbook ή το recovery βασίζεται στη γνώση ενός μόνο ατόμου;
Αυτό το τελευταίο είναι ιδιαίτερα σημαντικό.
Αν μόνο ένας διαχειριστής ξέρει πώς να επαναφέρει το σύστημα, δεν έχουμε ακόμη ανθεκτική διαδικασία. Έχουμε εξάρτηση από ένα συγκεκριμένο άτομο.
Η χειρότερη στιγμή για να γράψεις διαδικασία recovery
Είναι η στιγμή που το σύστημα δεν λειτουργεί πια.
Τότε εμφανίζεται η πίεση χρόνου, το άγχος, τα τηλεφωνήματα από πελάτες και οι ερωτήσεις της διοίκησης.
Γι’ αυτό η διαδικασία πρέπει να έχει προετοιμαστεί νωρίτερα.
Θα πρέπει να ορίζει, μεταξύ άλλων:
-
πότε ενεργοποιούμε το disaster recovery,
-
ποιος παίρνει την απόφαση,
-
ποια συστήματα έχουν την υψηλότερη προτεραιότητα,
-
πού βρίσκονται τα backups,
-
πώς να τα επαναφέρουμε,
-
ποιες εξαρτήσεις πρέπει να εκκινήσουν,
-
πώς φαίνεται το failover,
-
πώς να επαληθεύσουμε τη σωστή λειτουργία,
-
πώς να επικοινωνήσουμε τη βλάβη,
-
πότε μπορεί να ξεκινήσει το failback,
-
ποιος εγκρίνει την επιστροφή στο βασικό περιβάλλον.
Σε περίπτωση σοβαρής βλάβης δεν θα πρέπει να υπάρχει χώρος για την ερώτηση: «Τι κάνουμε τώρα;»
Η διαδικασία πρέπει να έχει απαντήσει σε αυτό εκ των προτέρων.
Το DR πρέπει να δοκιμάζεται όπως η λειτουργία μιας εφαρμογής
Μια καλή προσέγγιση είναι να αντιμετωπίζουμε το recovery παρόμοια με τα tests λογισμικού. Δεν αρκεί να ετοιμάσουμε μία φορά τη διαδικασία.
Το σύστημα αλλάζει.
Η βάση δεδομένων μεγαλώνει.
Οι εξαρτήσεις αλλάζουν.
Προστίθεται νέα υποδομή.
Αλλάζουν οι εκδόσεις της εφαρμογής.
Εμφανίζονται νέες ολοκληρώσεις.
Αλλάζουν τα δικαιώματα.
Γι’ αυτό η στρατηγική recovery χρειάζεται επίσης συνεχή έλεγχο.
Το τεστ μπορεί να ξεκινήσει από ένα απλό σενάριο: «Η βάση δεδομένων χάθηκε. Ας την επαναφέρουμε από το τελευταίο αντίγραφο.»
Στη συνέχεια μπορεί να περάσει σε πιο σύνθετα σενάρια:
- «Ο διακομιστής εφαρμογής δεν λειτουργεί.»
- «Ολόκληρο το περιβάλλον παραγωγής δεν είναι διαθέσιμο.»
- «Τα δεδομένα κρυπτογραφήθηκαν.»
- «Δεν λειτουργεί η βασική περιοχή της υποδομής.»
- «Δεν έχουμε πρόσβαση στον κύριο διαχειριστή.»
Κάθε τέτοιο τεστ μπορεί να αποκαλύψει προβλήματα που δεν φαίνονται κατά τη συνήθη λειτουργία του συστήματος.
Χρειάζεται κάθε εφαρμογή προχωρημένο disaster recovery;
Όχι.
Και αυτό επίσης είναι σημαντικό.
Ο σχεδιασμός μιας υποδομής ανθεκτικής σε κάθε πιθανό σενάριο μπορεί να είναι δυσανάλογα ακριβός.
Αν η βλάβη μιας εσωτερικής εφαρμογής μπορεί να σημαίνει μία ώρα ταλαιπωρίας, δεν χρειαζόμαστε απαραίτητα υποδομή active-active σε πολλές περιοχές. Αν όμως η βλάβη ενός συστήματος σημαίνει διακοπή των πωλήσεων, της παραγωγής, της εξυπηρέτησης πελατών ή μιας κρίσιμης επιχειρηματικής διαδικασίας, η κατάσταση είναι εντελώς διαφορετική.
Πρώτα πρέπει να καθοριστεί ο αντίκτυπος της βλάβης στην επιχείρηση.
Μόνο μετά να επιλεγεί η τεχνολογία.
Αυτό μπορεί να οδηγήσει σε διαφορετικές λύσεις:
Backup + restore
Πιο απλή και φθηνή λύση για συστήματα μικρότερης κρισιμότητας.
Warm standby
Το εφεδρικό περιβάλλον είναι εν μέρει έτοιμο και μπορεί να τεθεί γρήγορα σε λειτουργία.
Hot standby
Το εφεδρικό περιβάλλον λειτουργεί σε μεγαλύτερο βαθμό παράλληλα και είναι έτοιμο να αναλάβει το φορτίο.
Active-active
Δύο περιβάλλοντα μπορούν να εξυπηρετούν ταυτόχρονα την κίνηση, περιορίζοντας την εξάρτηση από ένα μοναδικό σημείο βλάβης.
Η επιλογή της λύσης θα πρέπει να προκύπτει από το RTO, το RPO, την κρισιμότητα του συστήματος, το κόστος της διακοπής και τις τεχνικές δυνατότητες.
Checklist: είναι η εφαρμογή σου έτοιμη για βλάβη;
Αξίζει να απαντήσεις σε μερικές απλές ερωτήσεις.
1. Έχουμε backup;
Αυτό είναι μόνο η αρχή.
2. Το backup αποθηκεύεται με τρόπο που το προστατεύει και από βλάβη του περιβάλλοντος παραγωγής;
3. Έχουμε κάνει ποτέ πλήρη επαναφορά;
4. Πόσο διαρκεί πραγματικά το restore;
5. Γνωρίζουμε το RTO;
6. Γνωρίζουμε το RPO;
7. Μπορούμε να επαναφέρουμε όχι μόνο τα δεδομένα, αλλά και την εφαρμογή και τη διαμόρφωσή της;
8. Έχουμε διαδικασία recovery;
9. Περισσότεροι από ένας μπορούν να την εκτελέσουν;
10. Δοκιμάσαμε το failover;
11. Είναι το εφεδρικό περιβάλλον ενημερωμένο;
12. Μετά τις τελευταίες αλλαγές στο σύστημα δοκιμάσαμε ξανά το recovery;
Αν σε μερικές ερωτήσεις απαντάμε «δεν ξέρω», τότε είναι πολύ καλή στιγμή να εξετάσουμε τη στρατηγική disaster recovery.
Το πιο σημαντικό τεστ λέει: «Δείξε»
Στην πληροφορική είναι πολύ εύκολο να πεις:
- «Έχουμε backup.»
- «Έχουμε εφεδρικό διακομιστή.»
- «Έχουμε διαδικασία.»
- «Έχουμε disaster recovery.»
- Αλλά η ασφάλεια του συστήματος δεν πρέπει να βασίζεται αποκλειστικά σε δηλώσεις.
Το πιο σημαντικό ερώτημα είναι: Δείξε ότι μπορείς να το επαναφέρεις.
- Εκτέλεσε restore.
- Μέτρησε τον χρόνο.
- Έλεγξε τα δεδομένα.
- Δοκίμασε την εφαρμογή.
- Πραγματοποίησε failover.
- Έλεγξε τη διαδικασία.
- Επανάλαβε το τεστ μετά από σημαντικές αλλαγές.
Μόνο τότε μπορεί κανείς να πει ότι η στρατηγική recovery έχει ελεγχθεί στην πράξη.
Το backup προστατεύει τα δεδομένα. Το recovery αποκαθιστά την επιχείρηση
Αυτή είναι μάλλον η πιο σημαντική διαφορά.
Το backup απαντά στο ερώτημα: «Έχουμε αντίγραφο;»
Το disaster recovery απαντά σε ένα πολύ πιο δύσκολο ερώτημα: «Μετά από μια βλάβη μπορούμε να επιστρέψουμε στη λειτουργία;»
Και ανάμεσα στο ένα και στο άλλο βρίσκεται ολόκληρη η αρχιτεκτονική ανάκτησης: RPO, RTO, αναπαραγωγή, backups, restore, failover, ρυθμίσεις, διαδικασίες, ευθύνη και τακτικά τεστ.
Ένα καλά σχεδιασμένο σύστημα δεν υποθέτει ότι η βλάβη δεν θα συμβεί. Υποθέτει ότι κάποτε η βλάβη θα συμβεί και θα πρέπει να ξέρεις τι να κάνεις.
Γιατί η πραγματική ανθεκτικότητα μιας εφαρμογής δεν σημαίνει ότι δεν χαλά ποτέ. Σημαίνει ότι όταν κάτι πάει στραβά, η οργάνωση μπορεί να επιστρέψει στη λειτουργία της με προβλέψιμο, ελεγχόμενο τρόπο και σύμφωνα με τις επιχειρησιακές απαιτήσεις.
Γλωσσάρι
Disaster Recovery (DR) - στρατηγική και διαδικασίες που επιτρέπουν την αποκατάσταση της λειτουργίας των συστημάτων μετά από σοβαρή βλάβη.
Backup - αντίγραφο δεδομένων προορισμένο για μελλοντική επαναφορά τους.
Restore - διαδικασία επαναφοράς δεδομένων ή συστήματος από αντίγραφο.
RTO (Recovery Time Objective) - ο μέγιστος αποδεκτός χρόνος αποκατάστασης του συστήματος.
RPO (Recovery Point Objective) - η μέγιστη αποδεκτή απώλεια δεδομένων εκφρασμένη σε χρόνο.
Failover - η μεταφορά της λειτουργίας του συστήματος από το κύριο περιβάλλον στο εφεδρικό.
Failback - η επιστροφή της λειτουργίας στο κύριο περιβάλλον μετά την устранση της αιτίας της βλάβης.
Recovery test - τεστ που έχει στόχο να επιβεβαιώσει ότι το σύστημα μπορεί πράγματι να αποκατασταθεί σύμφωνα με τις υιοθετημένες παραδοχές.
Runbook - λεπτομερής οδηγός ενεργειών για ένα συγκεκριμένο σενάριο βλάβης.
