Κάθε σχέδιο ανάκτησης κουβαλά μια δεύτερη υπόθεση, πιο σιωπηλή από την πρώτη. Η πρώτη είναι ότι μέρος της υποδομής επιβιώνει από το συμβάν, τα Μέρη 1 και 2 αυτής της σειράς δοκίμασαν αυτήν. Η δεύτερη είναι ότι όταν έρθει το συμβάν, μπορείτε ακόμα να αναπτύξετε τη διόρθωση: το API απαντά, η κονσόλα φορτώνει, το pipeline σας μπορεί να αναλάβει έναν ρόλο, το Auto Scaling group μπορεί να ξεκινήσει μια αντικατάσταση. Στις 13 Ιουνίου 2023, ένα λανθάνον ελάττωμα στο υποσύστημα που διαχειρίζεται τη compute χωρητικότητα του Lambda υποβάθμισε τις κλήσεις function στην us-east-1, και για μέρος των επόμενων τεσσάρων ωρών το AWS Management Console σε εκείνη την περιοχή σέρβιρε σελίδες σφάλματος ενώ το STS πετούσε αυξημένα ποσοστά σφαλμάτων. Τίποτα στην υποδομή των περισσότερων πελατών δεν έσπασε εκείνη τη μέρα. Αυτό που έσπασε ήταν το επίπεδο που θα χρησιμοποιούσαν για να τη διορθώσουν. Όταν το control plane βρίσκεται μέσα στο blast radius, η διαδρομή αποκατάστασης βρίσκεται μέσα στο failure domain.

Αυτό είναι το Μέρος 3 του Nothing Fails Alone. Το Μέρος 1 πήρε το συμβάν του Μαΐου στην us-east-1 και έδειξε το όριο ζώνης να αντέχει ενώ μια αρχιτεκτονική πελάτη αστοχούσε μέσα του. Το Μέρος 2 πήρε το συμβάν του Μαρτίου στην me-central-1 και έδειξε ενάντια σε τι είναι σχεδιασμένο το όριο, βλάβες εγκαταστάσεων, και σε τι δεν είναι, μία αιτία που φτάνει σε δύο ζώνες. Και τα δύο μέρη κατέληξαν κοντά στην ίδια επιφύλαξη, που δημοσίευσε η AWS στη μέση και των δύο συμβάντων: "longer than usual provisioning times". Το Μέρος 1 υποσχέθηκε ότι αυτό το μέρος θα αφορούσε το τι μοιράζεται το σχέδιο ανάκτησής σας με το σχέδιο ανάκτησης όλων των άλλων. Να η απάντηση: μοιράζεται το control plane. Το failover σας καλεί τα ίδια περιφερειακά APIs με κάθε άλλο failover στην περιοχή, που τα χειρίζεται ο πάροχος, υποβαθμισμένα από τα ίδια συμβάντα που σας κάνουν να τα χρειάζεστε, και αυτή η εξάρτηση αξίζει τον ίδιο έλεγχο που δίνετε στα replicas σας.

Ιούνιος 2023: η διόρθωση χρειαζόταν αυτό που αστόχησε

Ο μηχανισμός είναι δημόσια καταγεγραμμένος από τότε που η AWS δημοσίευσε το post-event summary για τις 13 Ιουνίου 2023. Αξίζει να διαβαστεί με ακρίβεια, επειδή είναι η καθαρότερη τεκμηριωμένη περίπτωση ενός control plane που αστοχεί ενώ η υποδομή από κάτω του συνεχίζει να τρέχει. Στις 10:01 AM PDT, ο στόλος Lambda Frontend στην us-east-1 άρχισε να κλιμακώνεται για συνηθισμένη ημερήσια κίνηση. Στις 11:49 AM διέσχισε, με τα λόγια της AWS, "a capacity threshold that had previously never been reached within a single cell", που "triggered a latent software defect". Τα execution environments δεσμεύτηκαν αλλά δεν χρησιμοποιήθηκαν ποτέ, το υποσύστημα "responsible for managing the underlying compute capacity" δεν μπορούσε να προμηθεύσει αντικαταστάσεις που δούλευαν, και οι κλήσεις Lambda στην περιοχή άρχισαν να αστοχούν.

Έπειτα το γράφημα εξαρτήσεων έκανε τη δουλειά του. Το summary απαριθμεί τα Amazon STS, AWS Management Console, Amazon EKS, Amazon Connect και Amazon EventBridge ως υποβαθμισμένα "as a result of the degraded Lambda function invocations". Το STS επέστρεψε αυξημένα ποσοστά σφαλμάτων από τις 11:49 AM ως τις 2:10 PM PDT "with three distinct periods of impact". Η κονσόλα στην us-east-1 σέρβιρε, από τις 11:48 AM ως τις 2:02 PM, είτε μια σελίδα "AWS Management Console is currently unavailable" είτε ένα "504 Time-out". Και το federated sign-in υποβαθμίστηκε: "Existing IAM sessions were not impacted, but new sign-in federation via SAML was degraded." Η πλήρης αποκατάσταση ήρθε στις 3:37 PM PDT, τρεις ώρες και σαράντα οκτώ λεπτά αφότου ξεκίνησε ο αντίκτυπος.

Αντιστοιχίστε το σε ένα συνηθισμένο runbook. Βήμα ένα, συνδεθείτε στην κονσόλα: υποβαθμισμένη. Βήμα δύο, αφήστε το pipeline να αναλάβει έναν ρόλο για φρέσκα credentials: STS, υποβαθμισμένο, τρεις ξεχωριστές φορές. Βήμα τρία, καλέστε το Lambda αποκατάστασης: αυτό είναι η διακοπή. Κανένα από τα instances σας δεν αστόχησε. Η βάση δεδομένων σας δεν έκανε failover. Το συμβάν δεν άγγιξε καθόλου την υποδομή σας, και παρ' όλα αυτά πήρε τα εργαλεία που υπέθετε το σχέδιό σας. Το μάθημα είναι δομικό, όχι ιστορικό: το επίπεδο λειτουργίας και το επίπεδο που αστοχούσε ήταν το ίδιο επίπεδο, και θα είναι ξανά.

Οκτώβριος 2025: η κατάρρευση, ξαναειδωμένη από το control plane

Όταν η us-east-1 έπεσε τον Οκτώβριο του 2025, αυτός ο ιστότοπος το κάλυψε την ίδια μέρα στο When the Cloud Sneezes, the World Catches a Cold. Εκείνο το άρθρο αφορούσε το πλάτος του blast radius, τον παραλογισμό του να εξαρτάται το μισό διαδίκτυο από μία περιοχή, και κατέληγε στο τι πρέπει να αλλάξει. Αυτό το μέρος είναι η συνέχεια που υποσχέθηκε, γραμμένη με το πλεονέκτημα του επίσημου post-event summary της AWS, και το summary ανταμείβει μια πιο ψυχρή ανάγνωση από αυτήν που επέτρεπε η ίδια η μέρα: κοιτάξτε τι συνέβη στα εργαλεία, όχι στις εφαρμογές.

Η σκανδάλη ήταν το DNS: "a latent race condition in the DynamoDB DNS management system that resulted in an incorrect empty DNS record" για το dynamodb.us-east-1.amazonaws.com, μια εγγραφή που η αυτοματοποίηση "failed to repair". Το endpoint του DynamoDB αποκαταστάθηκε μέσα σε ώρες. Η ζημιά στο control plane κράτησε πολύ περισσότερο. Το EC2, σύμφωνα με το summary: "Between 11:48 PM PDT on October 19 and 1:50 PM PDT on October 20, customers experienced increased EC2 API error rates, latencies, and instance launch failures", δεκατέσσερις ώρες κατά τις οποίες η τυπική κίνηση ανάκτησης κάθε multi-AZ αρχιτεκτονικής στην περιοχή, το ξεκίνημα χωρητικότητας αντικατάστασης, ήταν η ίδια πληγμένη. Το STS επέστρεψε "API errors and latency" από τις 11:51 PM ως τις 9:59 AM. Το sign-in στην κονσόλα με έναν χρήστη IAM αστοχούσε με "increased authentication failures" μέχρι τις 1:25 AM, οι χρήστες Identity Center στην περιοχή δεν μπορούσαν καθόλου να συνδεθούν, και το sign-in με root-credential και το federated πετούσαν σφάλματα ακόμα και σε άλλες περιοχές, επειδή η ίδια η διαδρομή sign-in ζούσε στην us-east-1.

Βάλτε τα δύο άρθρα δίπλα-δίπλα και ο καταμερισμός εργασίας είναι σαφής. Το άρθρο του Οκτωβρίου ρώτησε τι κοστίζει να εξαρτάσαι από μία περιοχή. Αυτό ρωτά τη στενότερη, πιο δυσάρεστη ερώτηση μέσα του: όταν η περιοχή είχε την κακή της μέρα, γιατί καλοχτισμένες multi-AZ αρχιτεκτονικές έμειναν εκτός για ώρες; Επειδή η ανάκτησή τους ήταν μια λειτουργία control plane. Το scaling out ήταν η διόρθωση, και το scaling out ήταν αυτό που πήραν οι δεκατέσσερις ώρες πληγμένων εκκινήσεων instances. Το σχέδιο όλων συνέκλινε στο ίδιο υποβαθμισμένο API την ίδια στιγμή, που είναι ακριβώς αυτό που σημαίνει στην πράξη το "το σχέδιό σας μοιράζεται το control plane με το σχέδιο όλων των άλλων".

Φεβρουάριος 2026: Azure, ίδιο σχήμα, διαφορετικό λογότυπο

Αν αυτό ήταν μια ιδιοτροπία της AWS, θα ήταν πρόβλημα της AWS. Δεν είναι. Στις 2 Φεβρουαρίου 2026, η Microsoft κατέγραψε το συμβάν FNJ8-VQZ, και η post-incident review του ανοίγει: "Between 18:03 UTC on 02 February 2026 and approximately 00:30 UTC on 03 February 2026, a platform issue caused some customers to experience degraded performance and control plane failures, for multiple Azure services across multiple regions." Μια πολιτική αποκατάστασης ασφαλείας που προοριζόταν να απενεργοποιήσει την ανώνυμη πρόσβαση σε storage accounts διαχειριζόμενα από τη Microsoft, μέσω "a data synchronization problem in the targeting logic", εφαρμόστηκε σε λογαριασμούς "intentionally configured to allow anonymous read access for platform functionality": τους λογαριασμούς που σέρβιραν τα πακέτα VM extension. Οι virtual machines χτύπησαν "failures when deploying or scaling", το AKS χτύπησε "failures in node provisioning", και οι εργασίες GitHub Actions "queued and timed out while waiting to acquire a hosted runner".

Προσέξτε τι δεν συνέβη: οι VMs που έτρεχαν συνέχισαν να τρέχουν. Το data plane ήταν μια χαρά. Αυτό που πέθανε ήταν η δυνατότητα να δημιουργήσεις, να κλιμακώσεις ή να αλλάξεις, σε πολλές περιοχές ταυτόχρονα, επειδή το control plane είναι κοινό με έναν τρόπο που το data plane δεν είναι. Αυτή είναι η ιδιότητα που αξίζει να γενικευτεί. Ένα control plane είναι ένα λογικό σύστημα που εκτείνεται στις ζώνες, μερικές φορές στις περιοχές, που το data plane του κρατά προσεκτικά ξεχωριστές, είναι το κομμάτι υπό μέγιστο φορτίο ακριβώς όταν όλοι ανακάμπτουν, και αστοχεί με τρόπους που τα multi-region διαγράμματα δεν δείχνουν, επειδή το διάγραμμα σχεδιάζει τους πόρους σας, όχι τη μηχανή που τους μεταβάλλει. Δύο πάροχοι, με διαφορά τεσσάρων μηνών, ίδιο σχήμα.

Static stability, ορισμένη σωστά

Η άμυνα έχει όνομα: static stability. Ένα στατικά σταθερό σύστημα συνεχίζει να ικανοποιεί τις απαιτήσεις του όταν μια εξάρτηση αστοχεί, χωρίς να χρειάζεται να αλλάξει τίποτα, επειδή οτιδήποτε θα ζητούσε από την εξάρτηση βρίσκεται ήδη στη θέση του. Ο ορισμός κερδίζει τη λέξη "static": μια ανάκτηση που δεν απαιτεί καμία μετάλλαξη δεν μπορεί να μπλοκαριστεί από το επίπεδο που εκτελεί τις μεταλλάξεις. Συγκεκριμένα, αυτό σημαίνει μια μικρή οικογένεια προϋπολογισμένων αποφάσεων:

  • Προ-προμηθευμένο περιθώριο. Κάθε ζώνη τρέχει αρκετή χωρητικότητα ώστε οι εναπομείνασες ζώνες να κουβαλούν όλο το φορτίο χωρίς καμία εκκίνηση. Η απώλεια ζώνης γίνεται απόφαση του load balancer, μια λειτουργία data plane, αντί για ένα συμβάν Auto Scaling, μια λειτουργία control plane.
  • Προ-δημιουργημένο, όχι δημιουργημένο-κατά-το-failover. Οι DNS εγγραφές του standby, οι συνδέσεις target group και τα standby instances υπάρχουν πριν από το συμβάν. Το failover αναστρέφει health checks και βάρη, δεν τρέχει Terraform.
  • Προ-ψημένες εικόνες. Ένα AMI που ξεκινά και σερβίρει χωρίς να χρειαστεί να φτάσει σε package mirrors, config services ή secrets endpoints κρατά μια εκκίνηση χρήσιμη ακόμα και όταν όλα γύρω από την εκκίνηση είναι υποβαθμισμένα.
  • Διαδρομές break-glass που αποφεύγουν το επίπεδο που αστόχησε. Το summary του Οκτωβρίου είναι ωμό για το sign-in: χρήστες IAM, Identity Center και federation υποβαθμίστηκαν όλα μαζί. Μια διαδρομή έκτακτης πρόσβασης είναι πραγματική μόνο αν δεν διασχίζει την περιοχή και το identity plane που προσπαθείτε να διασώσετε, και πραγματική μόνο αν εξασκείται, ένα αδοκίμαστο break-glass credential είναι μια ευχή.

Το κοινό νήμα είναι η μετακίνηση της δουλειάς από το κατά-τη-διάρκεια-του-συμβάντος στο πριν-από-το-συμβάν, από το πρόγραμμα του control plane στο δικό σας. Δεν μπορείτε να κάνετε αξιόπιστο το control plane του παρόχου. Μπορείτε να κανονίσετε να μην το χρειάζεστε για την πρώτη ώρα.

Το lab: μετρήστε τη διαφορά, μην την ισχυρίζεστε

Το lab αυτού του μέρους, το 03-static-stability, σπάει έναν κανόνα της σειράς εν γνώσει του: δεν είναι read-only. Το Terraform χτίζει ένα VPC, ένα ALB με πρόσβαση στο ίντερνετ, και έξι t3.micro instances, και κοστίζει χρήμα μέχρι να το καταστρέψετε, οπότε ανήκει σε έναν λογαριασμό sandbox και στα σκουπίδια την ίδια μέρα. Αυτό που αγοράζει με αυτό το τίμημα είναι μια μέτρηση του ακριβούς κενού που περιγράφει αυτό το άρθρο, στον δικό σας λογαριασμό, αντί για τον ισχυρισμό μου γι' αυτό. Η ίδια η τεκμηρίωση fault-injection της AWS δηλώνει την προκείμενη ξεκάθαρα: για το σενάριο διακοπής ρεύματος AZ, "EC2 API calls made by the Auto Scaling control plane to recover lost capacity in the AZ will fail". Το lab χτίζει και τις δύο απαντήσεις σε αυτή την πρόταση πίσω από έναν load balancer. Η Διαδρομή A είναι ο τυπικός σχεδιασμός: ένα Auto Scaling group με ένα instance ανά ζώνη και μια πολιτική scaling, οπότε η απώλεια μιας ζώνης σημαίνει ότι το ASG πρέπει να καλέσει ec2:RunInstances για να ανακάμψει. Η Διαδρομή B είναι ο στατικά σταθερός σχεδιασμός: το ίδιο workload προ-προμηθευμένο σε διπλή χωρητικότητα, δύο instances ανά ζώνη, ώστε οποιαδήποτε ζώνη μόνη της να κουβαλά ήδη όλο το φορτίο.

Το script μέτρησης αξίζει μια σημείωση, επειδή το πρώτο του προσχέδιο ήταν λάθος με έναν διδακτικό τρόπο. Η απλή αφαίρεση του subnet της ζώνης που αστόχησε από ένα ASG δεν είναι απώλεια ζώνης: πυροδοτεί rebalancing, και το rebalancing ξεκινά αντικαταστάσεις πριν τερματίσει οτιδήποτε, οπότε η υγιής χωρητικότητα δεν πέφτει ποτέ και δεν υπάρχει τίποτα να μετρηθεί. Η πραγματική απώλεια ζώνης σκοτώνει τα instances. Έτσι το measure.py αφαιρεί το subnet και μετά τερματίζει τα εν λειτουργία instances εκείνης της ζώνης μέσω TerminateInstanceInAutoScalingGroup με ShouldDecrementDesiredCapacity=False, αφήνοντας κάθε group με λιγότερη πραγματική χωρητικότητα που πρέπει να ανακτήσει αλλού. Για τη Διαδρομή A χρονομετρά μετά το διάστημα από τη βλάβη μέχρι τον πλήρη υγιή αριθμό στον load balancer, ένα διάστημα που είναι καθαρά control plane: κλήση εκκίνησης, boot, health checks. Για τη Διαδρομή B παρακολουθεί τον υγιή αριθμό μέσα από ένα παράθυρο σταθεροποίησης και καταγράφει το ελάχιστο, που πέφτει από τέσσερα σε δύο, το δύο είναι ακριβώς η απαίτηση μετά την αστοχία, οπότε η συνθήκη επιτυχίας δοκιμάζεται απέναντι σε μια πραγματική πτώση αντί να ισχύει τετριμμένα. Αυτό είναι το σχήμα του πίνακα που τυπώνει το script, όχι ένα αποτέλεσμα που πήρα, δεν το έχω τρέξει απέναντι σε έναν ζωντανό λογαριασμό για αυτό το άρθρο, και οι αριθμοί που παίρνει ένας αναγνώστης είναι δικοί του:

PATH                    | TIME TO RECOVER               | API CALLS REQUIRED                | SURVIVES CONTROL PLANE LOSS
path-a (control plane)  | measured on your run          | yes: ec2:RunInstances via the ASG | no
path-b (static)         | 0s, capacity already in place | none                              | yes

Όποιον αριθμό κι αν τυπώσει για εσάς η Διαδρομή A, διαβάστε τον ως καλύτερη περίπτωση: μετρήθηκε απέναντι σε ένα υγιές, συνεργάσιμο control plane μια ήσυχη μέρα. Το control plane του Οκτωβρίου δεν ήταν κανένα από τα δύο. Το Lab 04 υπάρχει για να κλείσει αυτό το κενό, εισάγοντας τα σφάλματα ανεπαρκούς χωρητικότητας που μετατρέπουν τον αριθμό της Διαδρομής A σε αυτό που θα ήταν εκείνο το βράδυ.

Το ειλικρινές κόστος, και πού παύει να αξίζει

Η Διαδρομή B τρέχει διπλή σταθερή χωρητικότητα για να σερβίρει την ίδια κίνηση. Αυτό δεν είναι υποσημείωση, είναι η συμφωνία: η static stability αγοράζει ασφάλεια με αδρανές compute, κάθε ώρα, ενάντια σε ένα συμβάν μετρημένο σε ώρες ανά έτος. Με δύο ζώνες το ασφάλιστρο είναι 100 τοις εκατό, με τρεις ζώνες καθεμία διαστασιολογημένη ώστε να απορροφά μία χαμένη, πέφτει στο 50, με περισσότερες ζώνες ή διαστασιολόγηση που λαμβάνει υπόψη το overprovisioning, λιγότερο. Πληρώστε το για τη διαδρομή σερβιρίσματος της οποίας ο χρόνος εκτός μετριέται σε έσοδα ή ασφάλεια, για μικρούς στόλους όπου ο διπλασιασμός είναι φθηνός σε απόλυτους όρους, και για οτιδήποτε του οποίου η ανάκτηση θα εξαρτιόταν διαφορετικά από το να δουλεύει το control plane στη μέση του συμβάντος.

Σταματήστε να το πληρώνετε εκεί που τα μαθηματικά παύουν να δουλεύουν. Η batch και ασύγχρονη δουλειά πρέπει να μπαίνει σε ουρά μέσα από μια απώλεια ζώνης, όχι να προ-προμηθεύεται ενάντια σε αυτήν. Το dev και το staging δεν το χρειάζονται. Οι πολύ μεγάλοι στόλοι πληρώνουν πραγματικά χρήματα για περιθώριο, και εκεί η ειλικρινής κίνηση είναι να χωρίσετε το tier: static stability για την κρίσιμη φέτα, ανάκτηση μέσω control plane αποδεκτή, με ανοιχτά μάτια, για τα υπόλοιπα. Και μάθετε τι δεν καλύπτει η τεχνική. Δεν θα είχε σώσει την Coinbase στο Μέρος 1, επειδή η αστοχία τους ήταν στο δικό τους data plane, ένα quorum που μοιραζόταν ένα κτίριο. Δεν απαντά στην απώλεια περιοχής του Μέρους 2, αφού το περιθώριο μέσα σε μια καταδικασμένη περιοχή είναι καταδικασμένο περιθώριο. Προστατεύει τις πρώτες ώρες, με το στοίχημα ότι το control plane επιστρέφει πριν η εφεδρική σας χωρητικότητα πάψει να είναι αρκετή. Αυτό το στοίχημα άντεξε τον Ιούνιο του 2023 και τον Οκτώβριο του 2025. Το αν αντέχει η δική σας εκδοχή του είναι κάτι που δοκιμάζετε, και εκεί πάει στη συνέχεια αυτή η σειρά.

Διαβάστε στη συνέχεια

  • Το Μέρος 2 αυτής της σειράς: Two Zones, Eighteen Hours, One Cause, το συμβάν της me-central-1 και οι αιτίες που η απομόνωση ζωνών δεν μπορεί να δει.
  • Το Μέρος 4 αυτής της σειράς: Testing the Assumption, όπου το lab 04 τρέχει το game day και εισάγει την αστοχία control plane που αυτό το μέρος μπόρεσε μόνο να περιγράψει.
  • Agents on Call, Part 2. The Foundation: Terraform Before Tokens στο ercan.ai: η ίδια πειθαρχία σε άλλον τομέα, κάθε όριο λογαριασμού και ρόλος IAM προμηθευμένος πριν από το πρώτο συμβάν, επειδή η μέση του συμβάντος είναι πολύ αργά για να χτίσεις.
  • Το συνοδευτικό repo: nothing-fails-alone, όλα τα labs αυτής της σειράς, αυτό είναι εκείνο που δεν είναι read-only, και το δηλώνει.

Για συμβουλευτική σε AWS, cloud αρχιτεκτονική, επισκοπήσεις ανθεκτικότητας, και platform δουλειά, ξεκινήστε από το ercanermis.com.

Αναφορές