Cloud ή on-prem: Τι ελέγχει ένας SRE κάτω από την υπηρεσία

Ο provider υποδομής είναι η μεγαλύτερη μεμονωμένη εξάρτηση που έχει οποιαδήποτε υπηρεσία, και ένας SRE τον αντιμετωπίζει όπως κάθε άλλο dependency: διαβάζει σε τι πραγματικά δεσμεύεται, χαρτογραφεί πού αστοχεί μαζικά, και ελέγχει τι συμβαίνει όταν δεν απαντά. Αυτό ισχύει είτε ο provider είναι η AWS είτε μια ομάδα platform που τρέχει racks δύο ορόφους πιο κάτω. Οι ερωτήσεις είναι πανομοιότυπες και στις δύο περιπτώσεις, αυτό που αλλάζει είναι ποιος τις απαντά. Σε ένα cloud απαντά ο provider και εσείς επαληθεύετε. On-prem απαντάτε εσείς, και δεν υπάρχει κανείς να σας επαληθεύσει. Αυτό το άρθρο είναι η λίστα ελέγχου, σε έξι περιοχές: η δέσμευση, τα failure domains, τα control planes, τα όρια, η χωρητικότητα, και η συντήρηση.

Αυτό είναι το Μέρος 4 του Budget for Failure, το δεύτερο μέρος επιπέδου 201 και το τελευταίο της σειράς. Το Μέρος 1 όρισε τον ρόλο, το Μέρος 2 του έδωσε αριθμούς, και το Μέρος 3 τον πήγε μέσα στον κώδικα εφαρμογής. Αυτό το μέρος πηγαίνει κάτω από τον κώδικα.

1. Η δέσμευση: τα dependencies σας βάζουν ταβάνι στο SLO

Το Μέρος 2 απαρίθμησε σε τι δεσμεύονται τέσσερα SLA της AWS. Τώρα κάντε την αριθμητική που οι περισσότερες αρχιτεκτονικές επισκοπήσεις παραλείπουν. Ένα request που πρέπει να περάσει από έναν load balancer, ένα επίπεδο compute, μια βάση δεδομένων, και object storage επιτυγχάνει μόνο όταν επιτυγχάνουν και τα τέσσερα. Αν οι αστοχίες είναι ανεξάρτητες, οι διαθεσιμότητες πολλαπλασιάζονται:

ALB (multi-AZ)      0.9999
EC2 (multi-AZ)      0.9999
RDS (Multi-AZ)      0.9995
S3 Standard         0.9990
------------------------------
product             0.9983   =  99.83%
allowed downtime    about 73 minutes in 30 days

Πριν ο δικός σας κώδικας πετάξει έστω μία exception, το συμβατικό δάπεδο κάτω από αυτό το stack είναι 99,83 τοις εκατό. Η AWS κανονικά τρέχει πολύ πάνω από τα δάπεδα των SLA της, οπότε η πρακτική τιμή είναι καλύτερη, αλλά το συμπέρασμα ισχύει: δεν μπορείτε να υποσχεθείτε 99,99 τοις εκατό πάνω σε ένα hard dependency που δεσμεύεται στο 99,9. Είτε χαμηλώνετε την υπόσχεση, είτε κάνετε το dependency soft με μια cache, μια ουρά, ή ένα fallback, όπως στο Μέρος 3.

On-prem δεν υπάρχει έγγραφο SLA να πολλαπλασιάσετε, οπότε χτίζετε τον ίδιο πίνακα από το δικό σας ιστορικό: μετρημένη διαθεσιμότητα του storage array, του hypervisor cluster, του core network, του ρεύματος. Αν κανείς δεν έχει αυτούς τους αριθμούς, αυτό είναι το πρώτο εύρημα της επισκόπησης.

2. Failure domains: τι πεθαίνει μαζί

Ο πολλαπλασιασμός υποθέτει ανεξαρτησία. Ένα failure domain είναι ένα σύνολο πραγμάτων που μοιράζονται μια αιτία αστοχίας, και η δουλειά του SRE είναι να τα ξέρει και να τοποθετεί replicas ανάμεσά τους.

Τρεις έλεγχοι ισχύουν και στις δύο πλευρές. Είναι τα replicas κάθε stateful συστήματος πραγματικά σε διαφορετικά domains, ή κάθονται τρεις κόμβοι ενός quorum σε μία ζώνη ή ένα rack; Κάθεται κάτι single-homed στη διαδρομή κάποιου multi-homed, όπως ένα NAT gateway που εξυπηρετεί τρεις ζώνες, ή δύο "πλεονάζοντα" switches στην ίδια τροφοδοσία; Και αφού χαθεί το μεγαλύτερο domain που σχεδιάζετε να επιβιώσετε, είναι η υπόλοιπη χωρητικότητα αρκετή για να σηκώσει το πλήρες φορτίο; Το να επιβιώσετε την απώλεια μιας ζώνης με τρεις ζώνες σημαίνει να τρέχετε καθεμία σε όχι περισσότερο από τα δύο τρίτα.

Η σειρά Nothing Fails Alone είναι τέσσερα αναλυμένα incidents ακριβώς αυτού του είδους, μαζί με ένα read-only script που βρίσκει συγκεντρώσεις σε μία ζώνη μέσα σε έναν λογαριασμό AWS.

3. Control plane και data plane

Κάθε πλατφόρμα έχει δύο μισά. Το data plane κάνει τη δουλειά: τα instances τρέχουν, οι load balancers προωθούν, το DNS απαντά. Το control plane αλλάζει πράγματα: εκκινεί ένα instance, τροποποιεί μια διαδρομή, κλιμακώνει ένα group. Τα control planes είναι πιο σύνθετα και αστοχούν συχνότερα, και τείνουν να αστοχούν κατά τη διάρκεια μεγάλων incidents, που είναι ακριβώς η στιγμή που ένα σχέδιο ανάκαμψης θέλει να τα χρησιμοποιήσει.

Έτσι η ερώτηση για κάθε διαδικασία ανάκαμψης είναι αν χρειάζεται μια κλήση control plane για να επιτύχει. Ένας σχεδιασμός που επιβιώνει μια απώλεια ζώνης επειδή η χωρητικότητα ήδη τρέχει αλλού είναι στατικά σταθερός. Ένας που επιβιώνει επειδή το autoscaling θα εκκινήσει αντικαταστάτες εξαρτάται από το control plane του EC2 τη στιγμή που κάθε άλλος πελάτης το καλεί. Το άρθρο του Amazon Builders' Library για το static stability είναι η αναφορά.

On-prem ο ίδιος διαχωρισμός υπάρχει με άλλα ονόματα: ο Kubernetes API server, το vCenter, ο αυτοματισμός IPAM και DNS, ο identity provider από τον οποίο εξαρτάται κάθε login και κάθε service token. Ρωτήστε τι συνεχίζει να δουλεύει όταν καθένα είναι κάτω, και αν τα εργαλεία που χρησιμοποιούνται για να διορθωθεί μια διακοπή (το VPN, το bastion, το deploy pipeline, το σύστημα chat) τρέχουν πάνω στην υποδομή που υποτίθεται ότι επισκευάζουν.

4. Όρια: η διακοπή που μοιάζει με quota

Ο κορεσμός, από τα golden signals του Μέρους 1, έχει μια μορφή από την πλευρά του provider που οι μετρικές host δεν δείχνουν ποτέ. Στο AWS, τα όρια που καταλήγουν σε postmortems σπάνια είναι η CPU:

• Service quotas. Running On-Demand vCPUs ανά οικογένεια instance, Lambda concurrent executions ανά λογαριασμό, Elastic IPs, κανόνες ανά security group. Ένα scale-out που χτυπά ένα quota αποτυγχάνει τη χειρότερη στιγμή.
• API rate limits. Τα APIs του control plane κάνουν throttle ανά λογαριασμό και Region. Ένα deploy tool, ένας autoscaler, και ένας monitoring agent που όλοι καλούν Describe* μπορούν να κάνουν throttle ο ένας τον άλλον.
• Χώρος διευθύνσεων. Ένα subnet που έχει εξαντλήσει τις ελεύθερες IPs σταματά νέα pods, νέα Lambda network interfaces, και νέα instances, με ένα σφάλμα που δεν αναφέρει τίποτα από αυτά.
• Ταβάνια ανά πόρο. IOPS και throughput σε ένα EBS volume, συνδέσεις σε μια κλάση instance RDS, ports σε ένα NAT gateway.

Αντιμετωπίστε καθένα ως SLI κορεσμού με alarm πολύ πριν το 100 τοις εκατό. Για πολλά quotas το CloudWatch δημοσιεύει τη χρήση στο namespace AWS/Usage, και η συνάρτηση metric math SERVICE_QUOTA() επιστρέφει το τρέχον όριο, οπότε μία έκφραση δίνει το ποσοστό του quota που χρησιμοποιείται. Για τα υπόλοιπα, ένα inventory script σε χρονοδιάγραμμα αρκεί.

On-prem τα όρια είναι φυσικά και πιο αργά να ανέβουν: rack units, ρεύμα και ψύξη ανά rack, switch ports, licensed cores, throughput του storage controller, το μέγεθος του σχεδίου διευθύνσεων που φτιάχτηκε πριν από πέντε χρόνια.

5. Χωρητικότητα: ελαστικό δεν σημαίνει άπειρο

Η υπόσχεση του cloud είναι ότι η χωρητικότητα φτάνει σε λεπτά. Συνήθως φτάνει, και ένας SRE σχεδιάζει για τις φορές που δεν φτάνει. Ένας συγκεκριμένος τύπος instance σε μια συγκεκριμένη ζώνη μπορεί να επιστρέψει InsufficientInstanceCapacity, πιο συχνά κατά τη διάρκεια ενός γεγονότος ζώνης όταν όλοι κάνουν failover στις ίδιες επιζώσες ζώνες. Οι άμυνες είναι η ποικιλομορφία (αρκετοί τύποι instance και όλες οι ζώνες στο Auto Scaling group), η προ-παροχή για την περίπτωση failover, και τα On-Demand Capacity Reservations για τα workloads που δεν μπορούν να περιμένουν.

On-prem ο χρόνος παράδοσης είναι εβδομάδες έως μήνες, οπότε το capacity planning είναι πειθαρχία πρόβλεψης: μετρημένη ανάπτυξη, ένα ημερολόγιο προμηθειών, και περιθώριο διαστασιολογημένο ως N+1 ή N+2 έναντι των παραπάνω failure domains. Η απόφαση που επηρεάζει περισσότερο την αξιοπιστία λαμβάνεται τη στιγμή της αγοράς, πολύ πριν το incident που τη δοκιμάζει.

Και στους δύο κόσμους, κάντε load test για να βρείτε το πρώτο όριο αντί να το εκτιμήσετε. Ο αριθμός που μετράει είναι το επίπεδο κίνησης στο οποίο το SLI από το Μέρος 2 αρχίζει να υποβαθμίζεται, και ποιος πόρος το προκάλεσε.

6. Συντήρηση: τα incidents με ημερομηνία πάνω τους

Ένα μεγάλο μερίδιο των incidents είναι προγραμματισμένα εκ των προτέρων από κάποιον και μετά ξεχασμένα. Σε ένα cloud: ειδοποιήσεις instance retirement, παράθυρα συντήρησης βάσης δεδομένων, εκδόσεις engine και Kubernetes που φτάνουν στο τέλος του standard support, λήξη πιστοποιητικών, deprecated runtimes. Η AWS δημοσιεύει τα περισσότερα από αυτά ανά λογαριασμό μέσω του AWS Health, που μπορεί να δρομολογηθεί μέσω EventBridge στην ίδια ουρά με την υπόλοιπη λειτουργική σας δουλειά. Αδιάβαστα, γίνονται αιφνιδιαστικά reboots.

On-prem η λίστα είναι μεγαλύτερη και εξ ολοκλήρου δική σας: firmware, patching hypervisor και λειτουργικού συστήματος, αντικατάσταση δίσκων και μπαταριών, κύκλοι ανανέωσης hardware, συμβόλαια υποστήριξης vendor, ανταλλακτικά επί τόπου. Καθένα χρειάζεται έναν υπεύθυνο και ένα ημερολόγιο. Μια πλατφόρμα που είναι τρεις major εκδόσεις πίσω ξοδεύει error budget προκαταβολικά.

Ο τελευταίος έλεγχος σε αυτή την περιοχή είναι πώς μαθαίνετε ότι ο provider έχει μια κακή μέρα. Μια status page γράφεται από ανθρώπους κατά τη διάρκεια ενός incident και υστερεί σε σχέση με αυτό. Μετρήστε τον provider μόνοι σας, απ' έξω: ένα synthetic canary που ασκεί την πραγματική διαδρομή χρήστη από άλλο δίκτυο σάς λέει για ένα regional πρόβλημα πριν το dashboard, και κρατά ζωντανό τον παρονομαστή του SLI όταν η πραγματική κίνηση δεν μπορεί να σας φτάσει.

Ποιος κατέχει τι

Καμία από τις δύο στήλες δεν είναι μικρότερη επειδή η δουλειά εξαφανίστηκε. Ένα cloud μετακινεί τις κάτω γραμμές σε έναν provider με περισσότερη εξάσκηση σε αυτές από σχεδόν οποιαδήποτε μεμονωμένη εταιρεία, και σε αντάλλαγμα αναλαμβάνετε ένα dependency που δεν μπορείτε να επιθεωρήσετε. Αυτή η ανταλλαγή είναι συνήθως σωστή. Παραμένει όμως ανταλλαγή, και ο SRE είναι ο άνθρωπος που μπορεί να διατυπώσει και τις δύο πλευρές της.

Τρόποι αστοχίας και τι να προσέχετε

Αντιμετώπιση του SLA ως πρόβλεψης. Είναι όρος τιμολόγησης με μια πίστωση συνημμένη. Σχεδιάστε με βάση τη μετρημένη συμπεριφορά και τα failure domains, όχι το ποσοστό στη σελίδα.

Multi-zone μόνο στο διάγραμμα. Τρεις ζώνες στη λίστα subnet και μία στην κατάσταση running, ή ένα failover που δεν έχει ασκηθεί ποτέ. Δοκιμάστε το σκόπιμα, μέσα στο error budget.

Ανάκαμψη που χρειάζεται αυτό που είναι χαλασμένο. Runbooks των οποίων το πρώτο βήμα είναι ένα login στην κονσόλα ή μια εκτέλεση pipeline στο επηρεασμένο Region.

Όρια που ανακαλύπτονται σε production. Κάθε quota και ταβάνι στην ενότητα 4 είναι φθηνό να βρεθεί σε ένα load test και ακριβό να βρεθεί κατά τη διάρκεια ενός launch.

Πού σας αφήνει αυτό

Η διαδρομή της σειράς, σε ένα πέρασμα. Κατέχετε την αξιοπιστία ως πρόβλημα engineering και βάζετε όριο στη χειρωνακτική δουλειά ώστε να υπάρχει χρόνος να το λύσετε (Μέρος 1). Δηλώνετε πόσο αξιόπιστη πρέπει να είναι η υπηρεσία ως SLO, και ξοδεύετε το κενό σκόπιμα ως error budget με υπογεγραμμένη πολιτική (Μέρος 2). Μπαίνετε στο repository και διορθώνετε τα timeouts, τα retries, και τα rollouts που κρίνουν τον αριθμό, και κάνετε page με βάση το burn rate αντί για τη CPU (Μέρος 3). Και ξέρετε τι υπόσχεται η πλατφόρμα από κάτω σας, πού αστοχεί μαζικά, και τι θα κάνετε όταν αστοχήσει (Μέρος 4). Τα εργαλεία και για τα τέσσερα τα χρησιμοποιούν ήδη οι περισσότεροι engineers. Αυτό που κάνει τη δουλειά SRE είναι ότι καθένα από αυτά απαντά πλέον σε μία μόνο ερώτηση: παίρνουν οι χρήστες την αξιοπιστία που συμφωνήσαμε, και ποιος είναι ο φθηνότερος τρόπος να το κρατήσουμε έτσι;

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

• Το Μέρος 3 αυτής της σειράς: SRE μέσα στον κώδικα: Timeouts, retries και alerts ως κώδικας.
• The Fix Shares Fate With the Outage: τρία incidents όπου η διαδρομή ανάκαμψης εξαρτιόταν από το control plane που ήταν κάτω.
• Your LLM Bill Is an Observability Problem στο ercan.ai: η ίδια σκέψη περί εξάρτησης από provider εφαρμοσμένη σε model APIs, όπου τα quotas και το κόστος είναι τα σήματα κορεσμού.

Για συμβουλευτική σε AWS, cloud αρχιτεκτονική, πρακτική SRE, CI/CD pipelines, Linux, και άλλα, ξεκινήστε από το ercanermis.com.

Αναφορές

• Amazon Builders' Library: Static stability using Availability Zones
• AWS whitepaper: AWS Fault Isolation Boundaries
• Amazon CloudWatch: Visualizing your service quotas and setting alarms
• Amazon EC2: On-Demand Capacity Reservations
• AWS Health: Monitoring events with Amazon EventBridge
• Amazon Compute Service Level Agreement
• Google SRE Book, Chapter 18: Software Engineering in SRE (capacity planning)