SLI, SLO, SLA, Error Budget: Οι αριθμοί πάνω στους οποίους τρέχει το SRE

Ένα SLI είναι μια μέτρηση του τι βίωσαν οι χρήστες, ένα SLO είναι ο στόχος που θέτετε για αυτή τη μέτρηση, ένα SLA είναι ένα συμβόλαιο που λέει τι συμβαίνει όταν ο στόχος δεν πιαστεί, και το error budget είναι η διαφορά ανάμεσα στο 100 τοις εκατό και το SLO, μετρημένη σε αποτυχημένα requests που επιτρέπεται να έχετε. Ένα SLO 99,9 τοις εκατό σε 30 ημέρες, σε μια υπηρεσία που εξυπηρετεί 10 εκατομμύρια requests, είναι ένα budget 10.000 αποτυχιών. Αυτοί οι τέσσερις αριθμοί είναι ο τρόπος με τον οποίο ένας SRE απαντά στην ερώτηση που ο υπόλοιπος οργανισμός δεν μπορεί: πόσο αξιόπιστη υποτίθεται ότι είναι αυτή η υπηρεσία, και είναι ασφαλές να στείλουμε σήμερα;

Αυτό είναι το Μέρος 2 του Budget for Failure. Το Μέρος 1 περιέγραψε τον ρόλο του SRE και τελείωσε στην εξάρτησή του: τίποτα από αυτά δεν δουλεύει χωρίς έναν αριθμό. Αυτό το μέρος είναι ακόμα επιπέδου 101. Ορίζει τους όρους, διαβάζει τα SLA της AWS για το τι πραγματικά υπόσχονται, υπολογίζει ένα πρώτο SLI από μετρικές load balancer που ήδη έχετε, και μετατρέπει το αποτέλεσμα σε budget με μια πολιτική συνημμένη.

SLI: ο λόγος καλών γεγονότων προς έγκυρα γεγονότα

Ένα service level indicator είναι ένας αριθμός ανάμεσα στο 0 και το 100 τοις εκατό, που υπολογίζεται με τον ίδιο τρόπο κάθε φορά: καλά γεγονότα διά έγκυρα γεγονότα. Για μια υπηρεσία που οδηγείται από requests τα δύο πιο χρήσιμα SLI είναι:

• Διαθεσιμότητα: requests που απαντήθηκαν χωρίς σφάλμα server, διά όλα τα requests.
• Latency: requests που απαντήθηκαν γρηγορότερα από ένα κατώφλι (ας πούμε 300 ms), διά όλα τα requests.

Δύο σχεδιαστικές αποφάσεις κρύβονται σε αυτόν τον ορισμό. Πρώτη, τι μετράει ως έγκυρο. Ένα 404 για ένα URL που δεν υπάρχει είναι η υπηρεσία που λειτουργεί σωστά, ένα 429 από τον δικό σας rate limiter είναι συζητήσιμο, ένα 500 δεν είναι. Αποφασίστε μία φορά και γράψτε το, επειδή ο παρονομαστής είναι το σημείο όπου τα SLI χειραγωγούνται αθόρυβα. Δεύτερη, πού μετράτε. Όσο πιο κοντά στον χρήστη, τόσο πιο ειλικρινής ο αριθμός. Μια μετρική που λαμβάνεται στον load balancer βλέπει αστοχίες που η εφαρμογή δεν καταγράφει ποτέ, όπως ένα target που αρνήθηκε τη σύνδεση. Μια μετρική που λαμβάνεται μέσα στην εφαρμογή τις χάνει.

Οι μέσοι όροι δεν πληρούν τις προϋποθέσεις για SLI. Ένα μέσο latency 120 ms είναι συμβατό με το ένα στα είκοσι requests να παίρνει τέσσερα δευτερόλεπτα. Η μορφή λόγου ("97,2 τοις εκατό των requests κάτω από 300 ms") σας λέει πόσοι χρήστες πέρασαν άσχημα, που είναι αυτό που προσπαθείτε να περιορίσετε.

SLO: ο στόχος, και το παράθυρο στο οποίο μετριέται

Ένα service level objective είναι ένα SLI συν ένας στόχος συν ένα χρονικό παράθυρο: "το 99,9 τοις εκατό των requests επιτυγχάνει, μετρημένο σε κυλιόμενες 30 ημέρες". Και τα τρία μέρη είναι απαραίτητα. Ένας στόχος χωρίς παράθυρο είναι αδιάψευστος, αφού οποιαδήποτε κακή ώρα μπορεί να εξαφανιστεί στον μέσο όρο επιλέγοντας εκ των υστέρων μια μεγαλύτερη περίοδο.

Ο στόχος είναι εκεί που μπαίνουν τα εννιάρια, και τα εννιάρια είναι ευκολότερο να τα σκέφτεστε ως επιτρεπόμενο downtime. Για παράθυρο 30 ημερών (43.200 λεπτά):

Διαβάστε τον πίνακα από κάτω προς τα πάνω. Στο 99,99 τοις εκατό έχετε περίπου τέσσερα λεπτά τον μήνα. Ένας άνθρωπος που παίρνει page στις 03:00 χρειάζεται περισσότερο από αυτό για να βρει ένα laptop, που σημαίνει ότι ένα SLO τεσσάρων εννιαριών είναι δέσμευση σε αυτοματοποιημένη ανίχνευση και αυτοματοποιημένη ανάκαμψη, με ανθρώπους να εμπλέκονται μόνο εκ των υστέρων. Κάθε επιπλέον εννιάρι είναι περίπου δεκαπλάσια μείωση της επιτρεπόμενης αστοχίας και, στην πράξη, ένα μεγάλο βήμα σε κόστος. Το σωστό SLO είναι ο χαμηλότερος αριθμός πάνω από τον οποίο οι χρήστες σας δεν θα πρόσεχαν τη διαφορά, όχι ο υψηλότερος αριθμός που φαίνεται καλός σε ένα slide.

Το εκατό τοις εκατό δεν είναι ποτέ ο σωστός στόχος. Απαγορεύει κάθε deploy, κάθε migration, και κάθε dependency που δεν ελέγχετε, και οι χρήστες σας φτάνουν σε εσάς μέσα από οικιακό Wi-Fi και δίκτυα κινητής που είναι πολύ λιγότερο αξιόπιστα από οτιδήποτε τρέχετε εσείς.

SLA: το συμβόλαιο, και τι πραγματικά σας χρωστά η AWS

Ένα service level agreement είναι ένα SLO με συνέπειες συνημμένες, υπογεγραμμένο με έναν πελάτη. Η συνέπεια είναι συνήθως χρήματα. Αυτή είναι όλη η διαφορά, και γι' αυτό το SLA είναι πάντα πιο χαλαρό από το εσωτερικό SLO: θέλετε να το προσέξετε και να αντιδράσετε πολύ πριν μια παραβίαση γίνει επιστροφή χρημάτων.

Η AWS είναι το SLA που οι περισσότεροι από εμάς διαβάζουμε πρώτο, και αξίζει να διαβαστεί προσεκτικά επειδή η διατύπωση διδάσκει την έννοια. Τέσσερα που βρίσκονται κάτω από μια τυπική web υπηρεσία:

Τρία πράγματα σε αυτά τα έγγραφα μετράνε περισσότερο από τα ποσοστά.

Η αποζημίωση είναι ένα service credit. Αν το S3 Standard πέσει στο 99,5 τοις εκατό για έναν μήνα, δικαιούστε 10 τοις εκατό των χρεώσεων S3 εκείνου του μήνα για το επηρεασμένο Region, ως πίστωση σε μελλοντικό λογαριασμό, αφού υποβάλετε αίτημα με αποδείξεις. Τα χαμένα σας έσοδα, οι δικές σας ποινές SLA, και το Σαββατοκύριακό σας δεν είναι μέρος του υπολογισμού. Ένα SLA είναι όρος τιμολόγησης. Δεν είναι ασφαλιστήριο συμβόλαιο και δεν είναι πρόβλεψη για το πώς θα συμπεριφερθεί η υπηρεσία.

Η δέσμευση εξαρτάται από την αρχιτεκτονική σας. Το 99,99 τοις εκατό για το EC2 ισχύει μόνο όταν όλα τα running instances είναι deployed σε δύο ή περισσότερες Availability Zones στο Region. Τρέξτε σε μία ζώνη και βρίσκεστε στη δέσμευση 99,5 τοις εκατό σε επίπεδο instance, που επιτρέπει περίπου 3,6 ώρες downtime τον μήνα. Το SLA κωδικοποιεί τον σχεδιασμό που η AWS περιμένει από εσάς.

Το "unavailable" έχει στενό νομικό ορισμό. Κάθε SLA ορίζει τη δική του μέτρηση, ανά λεπτό ή ανά διάστημα πέντε λεπτών, και τις δικές του εξαιρέσεις. Το αργό δεν είναι μη διαθέσιμο. Αυξημένα ποσοστά σφαλμάτων σε ένα API από το οποίο εξαρτάστε μπορεί να μη μετράνε καθόλου.

Το πρώτο σας SLI, από μετρικές που ήδη έχετε

Αν η υπηρεσία σας κάθεται πίσω από έναν Application Load Balancer, το CloudWatch ήδη κρατά ένα SLI διαθεσιμότητας. Τρεις μετρικές στο namespace AWS/ApplicationELB αρκούν: RequestCount, HTTPCode_Target_5XX_Count (σφάλματα που επέστρεψε ο κώδικάς σας), και HTTPCode_ELB_5XX_Count (σφάλματα που παρήγαγε ο ίδιος ο load balancer, για παράδειγμα όταν κανένα υγιές target δεν απάντησε). Αποθηκεύστε αυτό ως sli.json:

[
  { "Id": "req", "ReturnData": false,
    "MetricStat": { "Stat": "Sum", "Period": 86400,
      "Metric": { "Namespace": "AWS/ApplicationELB", "MetricName": "RequestCount",
        "Dimensions": [{ "Name": "LoadBalancer", "Value": "app/checkout/0123456789abcdef" }] } } },
  { "Id": "t5xx", "ReturnData": false,
    "MetricStat": { "Stat": "Sum", "Period": 86400,
      "Metric": { "Namespace": "AWS/ApplicationELB", "MetricName": "HTTPCode_Target_5XX_Count",
        "Dimensions": [{ "Name": "LoadBalancer", "Value": "app/checkout/0123456789abcdef" }] } } },
  { "Id": "e5xx", "ReturnData": false,
    "MetricStat": { "Stat": "Sum", "Period": 86400,
      "Metric": { "Namespace": "AWS/ApplicationELB", "MetricName": "HTTPCode_ELB_5XX_Count",
        "Dimensions": [{ "Name": "LoadBalancer", "Value": "app/checkout/0123456789abcdef" }] } } },
  { "Id": "sli", "Label": "availability_percent",
    "Expression": "100 * (req - FILL(t5xx, 0) - FILL(e5xx, 0)) / req" }
]

aws cloudwatch get-metric-data \
  --start-time "$(date -u -v-30d +%Y-%m-%dT00:00:00Z)" \
  --end-time "$(date -u +%Y-%m-%dT00:00:00Z)" \
  --metric-data-queries file://sli.json \
  --query 'MetricDataResults[0].[Timestamps,Values]'

Αυτό επιστρέφει μία τιμή διαθεσιμότητας ανά ημέρα για τις τελευταίες 30 ημέρες (η σύνταξη date -v είναι macOS, σε Linux χρησιμοποιήστε date -u -d '30 days ago'). Το FILL(…, 0) έχει σημασία: το CloudWatch δεν δημοσιεύει datapoint για μια μετρική σφαλμάτων σε μια περίοδο με μηδέν σφάλματα, και χωρίς το fill μια τέλεια ημέρα επιστρέφει ως missing data αντί για 100 τοις εκατό.

Για το latency, το ίδιο namespace έχει το TargetResponseTime, και η στατιστική percentile rank του CloudWatch το μετατρέπει απευθείας στη μορφή λόγου: το PR(:0.3) επιστρέφει το ποσοστό των requests που ολοκληρώθηκαν σε 300 ms ή λιγότερο.

Το error budget: τι σας αφήνει να ξοδέψετε το SLO

Μόλις το business συμφωνήσει ότι το 99,9 τοις εκατό είναι αρκετά καλό, το υπόλοιπο 0,1 τοις εκατό παύει να είναι ελάττωμα προς εξάλειψη και γίνεται περιθώριο προς χρήση. Αν η υπηρεσία βρίσκεται στο 99,97 τοις εκατό με δέκα ημέρες να απομένουν στο παράθυρο, υπάρχει χώρος για ρίσκο: στείλτε το migration, αναβαθμίστε το cluster, τρέξτε το failover test. Αν βρίσκεται στο 99,88 τοις εκατό, δεν υπάρχει, και κανείς δεν χρειάζεται να κερδίσει μια διαφωνία για να το αποδείξει. Μια υπηρεσία που τελειώνει κάθε παράθυρο με το budget ανέγγιχτο δεν είναι θρίαμβος ούτε αυτή: το SLO είναι πιο χαλαρό από όσο χρειάζονται οι χρήστες, ή η ομάδα πληρώνει για αξιοπιστία που κανείς δεν ζήτησε.

Το budget μπορεί να μετρηθεί σε γεγονότα ή σε χρόνο, και τα δύο συμπεριφέρονται διαφορετικά.

SLO                      99.9% over 30 days
requests in window       10,000,000
error budget             (1 - 0.999) x 10,000,000 = 10,000 failed requests

bad requests so far      6,400
budget consumed          6,400 / 10,000 = 64%
budget remaining         3,600 requests = 36%

Τα budgets βάσει γεγονότων σταθμίζουν την αστοχία με την κίνηση. Δέκα λεπτά ολικής διακοπής στην αιχμή της Τρίτης κοστίζουν πολύ περισσότερο από δέκα λεπτά στις 04:00 της Κυριακής, κάτι που ταιριάζει με αυτό που βίωσαν οι χρήστες. Αυτή είναι η μορφή που πρέπει να προτιμάτε για οτιδήποτε οδηγείται από requests.

Τα budgets βάσει χρόνου μετρούν κακά λεπτά: 99,9 τοις εκατό σε 30 ημέρες είναι 43 λεπτά και 12 δευτερόλεπτα. Εξηγούνται ευκολότερα σε κάποιον που δεν είναι μηχανικός και ταιριάζουν σε υπηρεσίες χωρίς σταθερή ροή requests, όπως ένα batch pipeline ή ένα εσωτερικό εργαλείο χαμηλής κίνησης. Το κόστος είναι ότι ένα λεπτό μετράει ως εντελώς κακό ή εντελώς καλό, οπότε χρειάζεστε έναν κανόνα για το τι κάνει ένα λεπτό κακό (για παράδειγμα, "ποσοστό σφαλμάτων πάνω από 1 τοις εκατό"), και μια μερική διακοπή είναι είτε αόρατη είτε μετρημένη πλήρως.

Το παράθυρο μετράει όσο και ο στόχος. Ένα κυλιόμενο παράθυρο 30 ημερών αντανακλά πάντα το πρόσφατο παρελθόν, και μια κακή ημέρα φεύγει από τον υπολογισμό ακριβώς 30 ημέρες αργότερα, είναι η καλύτερη επιλογή για την παρακολούθηση της εμπειρίας χρήστη. Ένα ημερολογιακό παράθυρο μηδενίζεται την πρώτη του μήνα, κάτι που ευθυγραμμίζεται με το reporting και με τα περισσότερα SLA, και έχει μία κακή ιδιότητα: ένα incident στις 2 του μήνα ξοδεύει το budget για τέσσερις εβδομάδες, ενώ το ίδιο incident στις 30 συγχωρείται δύο ημέρες αργότερα.

Τι ξοδεύει το budget

Οτιδήποτε κάνει το request ενός χρήστη να αποτύχει αντλεί από τον ίδιο λογαριασμό, όποιος κι αν το προκάλεσε. Αυτό είναι το νόημα. Σε χονδρικά φθίνουσα σειρά του πόσο ξοδεύει μια τυπική ομάδα:

• Αλλαγές. Deploys, config pushes, feature flags, schema migrations. Στις περισσότερες συλλογές postmortems, η αλλαγή είναι η μεγαλύτερη μεμονωμένη αιτία incidents. Αν παρακολουθείτε το change failure rate του DORA, ήδη μετράτε τον κύριο καταναλωτή.
• Dependencies. Μια επιβράδυνση regional API, ένας τρίτος πάροχος πληρωμών, ένα πρόβλημα DNS. Είναι το δικό σας budget ακόμα κι όταν δεν φταίτε εσείς, επειδή τον χρήστη δεν τον νοιάζει ποιος φταίει.
• Χωρητικότητα και φορτίο. Throttling, κρύες caches, ένα scaling policy που αντιδρά δύο λεπτά αργά.
• Προγραμματισμένη δουλειά. Παράθυρα συντήρησης, failover tests, game days. Μια σκόπιμη άσκηση εκκένωσης ζώνης που κοστίζει 300 αποτυχημένα requests είναι budget καλά ξοδεμένο, και το να έχετε budget είναι αυτό που κάνει την άσκηση εγκρίσιμη.
• Hardware και πλατφόρμα. Instance retirements, γεγονότα ζώνης. Μικρότερα από όσο περιμένει ο κόσμος, αν η αρχιτεκτονική είναι multi-AZ.

Κρατήστε ένα καθολικό (ledger). Μετά από κάθε incident ή ριψοκίνδυνη αλλαγή, καταγράψτε πόσο budget κατανάλωσε και την αιτία του. Τρεις μήνες αυτού του ledger σάς λένε πού πρέπει να πάει ο χρόνος reliability engineering καλύτερα από οποιαδήποτε συζήτηση roadmap.

Σε αυτό το παράδειγμα ένα deploy κόστισε περισσότερο από μια διακοπή τρίτου και ένα προγραμματισμένο test μαζί. Η επενδυτική πρόταση γράφεται μόνη της: canary analysis και αυτόματο rollback πριν από οτιδήποτε άλλο.

Η πολιτική είναι το προϊόν

Ένα budget χωρίς συνέπεια είναι ένα dashboard. Αυτό που το κάνει να δουλεύει είναι μια σύντομη γραπτή πολιτική, συμφωνημένη εκ των προτέρων από την ηγεσία engineering και product, που λέει τι αλλάζει όταν το budget λιγοστεύει. Το Google SRE Workbook δημοσιεύει ένα παράδειγμα πολιτικής του οποίου η δομή αξίζει να αντιγραφεί. Μια λειτουργική πρώτη εκδοχή χωράει σε μισή σελίδα:

• Budget πάνω από 50 τοις εκατό: κανονική διαδικασία release. Οι ριψοκίνδυνες αλλαγές και τα πειράματα ενθαρρύνονται.
• Budget κάτω από 50 τοις εκατό: οι αλλαγές χρειάζονται ένα canary στάδιο και ένα δοκιμασμένο rollback. Κανένα πείραμα σε production.
• Budget εξαντλημένο: τα feature releases σταματούν μέχρι η υπηρεσία να επιστρέψει εντός SLO. Βγαίνουν μόνο διορθώσεις αξιοπιστίας, security patches, και αλλαγές που χρειάζονται για να αποκατασταθεί το budget. Η προτεραιότητα της ομάδας είναι τα κορυφαία στοιχεία από τα πρόσφατα postmortems.
• Ένα μεμονωμένο incident καταναλώνει πάνω από το 20 τοις εκατό του budget: το postmortem είναι υποχρεωτικό, με τουλάχιστον ένα action item υψηλής προτεραιότητας.
• Διαφωνία: αποφασίζει ένα κατονομασμένο στέλεχος. Η διαδρομή κλιμάκωσης είναι γραμμένη πριν χρειαστεί.

Δύο ιδιότητες κάνουν αυτό να κρατάει. Είναι συμμετρικό: το ίδιο έγγραφο που παγώνει τα releases όταν το budget έχει τελειώσει λέει στο operations να σταματήσει να τα μπλοκάρει όταν είναι υγιές. Και είναι προσυμφωνημένο: ο product owner το υπέγραψε σε μια ήρεμη εβδομάδα, οπότε η επίκλησή του σε μια κακή είναι εκτέλεση, όχι αντιπαράθεση. Αν η ηγεσία δεν υπογράφει μια πολιτική που μπορεί να σταματήσει τη δουλειά σε features, δεν έχετε ακόμα SLO. Έχετε μια μετρική.

Αφήστε το CloudWatch να κρατά το ledger

Το παραπάνω SLI υπολογίστηκε με το χέρι με get-metric-data. Για το τρέχον budget, το CloudWatch έχει ένα managed SLO feature μέσα στο Application Signals. Ορίζετε τον δείκτη, τον στόχο επίτευξης, και το διάστημα, και παρακολουθεί συνεχώς την επίτευξη και το υπόλοιπο error budget. Τρεις επιλογές στο μοντέλο του αντιστοιχούν απευθείας σε αυτό το άρθρο:

• Βάσει περιόδου ή βάσει request. Ένα SLO βάσει περιόδου χωρίζει το διάστημα σε περιόδους (ένα λεπτό, για παράδειγμα), κρίνει καθεμία ως καλή ή κακή, και αναφέρει καλές περιόδους προς συνολικές περιόδους. Ένα SLO βάσει request μετρά καλά requests προς συνολικά requests. Αυτά είναι τα budgets βάσει χρόνου και βάσει γεγονότων που περιγράφηκαν παραπάνω.
• Κυλιόμενο ή ημερολογιακό διάστημα. Υποστηρίζονται και τα δύο, με το trade-off που ήδη περιγράφηκε.
• Πάνω σε τι χτίζεται το SLI. Οι υπηρεσίες με instrumentation Application Signals παίρνουν τυπικές μετρικές latency και διαθεσιμότητας, με τις 5xx αποκρίσεις να μετρούν ως faults και τις 4xx να αντιμετωπίζονται ως επιτυχημένες. Αν δεν έχετε instrumentation, ένα SLO μπορεί να οριστεί πάνω σε οποιαδήποτε μετρική CloudWatch ή έκφραση metric math που καταλήγει σε μία χρονοσειρά, που περιλαμβάνει την παραπάνω έκφραση του load balancer.

Η κονσόλα δείχνει το αποτέλεσμα ως δύο τιμές: επίτευξη έναντι του στόχου, και υπόλοιπο budget. Για ένα SLO βάσει request το υπόλοιπο budget μπορεί να ανεβαίνει αλλά και να κατεβαίνει κατά τη διάρκεια του διαστήματος, επειδή εξαρτάται από τον λόγο καλών προς συνολικά requests μέχρι στιγμής, και μια ήσυχη εβδομάδα καθαρής κίνησης αραιώνει ένα προηγούμενο incident.

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

Μέσος όρος ποσοστών. Μια ημέρα με 100 requests στο 90 τοις εκατό και μια ημέρα με ένα εκατομμύριο requests στο 99,99 τοις εκατό δεν δίνουν μέσο όρο 95. Το SLI 30 ημερών είναι συνολικά καλά requests προς συνολικά έγκυρα requests. Αθροίστε τους αριθμητές και τους παρονομαστές, μετά διαιρέστε.

Ένας παρονομαστής με τρύπες. Το RequestCount μετρά μόνο requests για τα οποία ο load balancer κατάφερε να επιλέξει target, οπότε η παραπάνω έκφραση υπερεκτιμά ελαφρώς τη ζημιά σε μια ολική διακοπή. Αυτή είναι η ασφαλής κατεύθυνση για να κάνετε λάθος. Το SLI επίσης δεν μπορεί να δει requests που δεν έφτασαν ποτέ στον load balancer: μια αποτυχία DNS, ένα μπλοκάρισμα WAF, έναν client σε χαλασμένο δίκτυο.

Το SLO που κανείς δεν συμφώνησε. Ένας στόχος που επιλέχθηκε μόνο από την ομάδα platform δεν έχει καμία εξουσία όταν συγκρούεται με μια ημερομηνία launch. Ο αριθμός πρέπει να ανήκει σε όποιον κατέχει το roadmap.

Πάρα πολλά SLO. Ξεκινήστε με ένα ή δύο ανά υπηρεσία που βλέπει ο χρήστης: διαθεσιμότητα και latency στη διαδρομή request που φέρνει τα χρήματα. Είκοσι SLO παράγουν είκοσι budgets, ένα από τα οποία είναι πάντα εξαντλημένο, και η πολιτική γίνεται θόρυβος.

Ορισμός του στόχου πριν δείτε τα δεδομένα. Τρέξτε πρώτα το query για τις τελευταίες 30 ημέρες. Ένα SLO που επιλέχθηκε πριν δείτε το SLI είναι ευχή. Ένα που ορίστηκε λίγο κάτω από το μετρημένο ιστορικό, και μετά σφίχτηκε σκόπιμα, είναι στόχος που μπορείτε να υπερασπιστείτε.

Να το μαθαίνετε στο τέλος του μήνα. Ένα budget που διαβάζεται σε μηνιαία αναφορά μπορεί μόνο να εξηγήσει το παρελθόν. Το να δράσετε όσο υπάρχει ακόμα budget απαιτεί ένα alert στον ρυθμό δαπάνης, και το να κάνετε την υπηρεσία να ξοδεύει λιγότερο απαιτεί αλλαγές στον κώδικά της. Και τα δύο είναι το Μέρος 3.

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

• Το Μέρος 3 αυτής της σειράς: SRE μέσα στον κώδικα: Timeouts, retries και alerts ως κώδικας, όπου το budget συναντά το repository.
• Το Μέρος 1 αυτής της σειράς: Τι κάνει ένας SRE: Η δουλειά πίσω από τον τίτλο.
• Evals Before Agents: You Can't Ship What You Can't Score στο ercan.ai, η ίδια πειθαρχία εφαρμοσμένη σε συστήματα LLM: ορίστε τη μέτρηση πριν διαφωνήσετε για την ποιότητα.

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

Αναφορές

• Google SRE Book, Chapter 4: Service Level Objectives
• Google SRE Book, Chapter 3: Embracing Risk
• Google SRE Workbook, Appendix B: Example Error Budget Policy
• Amazon Compute Service Level Agreement
• Amazon Elastic Load Balancing Service Level Agreement
• Amazon RDS Service Level Agreement
• Amazon S3 Service Level Agreement
• CloudWatch metrics for your Application Load Balancer
• Amazon CloudWatch: Service level objectives (SLOs)