Το site reliability engineering είναι αυτό που προκύπτει όταν αντιμετωπίζετε το operations ως πρόβλημα λογισμικού: μια ομάδα μηχανικών που έχει την ευθύνη της αξιοπιστίας μιας υπηρεσίας σε production, τη μετρά από την πλευρά του χρήστη, και ξοδεύει τουλάχιστον τον μισό της χρόνο γράφοντας κώδικα που αφαιρεί λειτουργική δουλειά αντί να την κάνει με το χέρι. Ένας SRE δεν είναι ένας sysadmin με νέο όνομα ούτε ένας DevOps engineer με pager. Ο ρόλος έχει καθορισμένο εύρος, ένα καθορισμένο σύνολο πραγμάτων που παρακολουθεί, και μια καθορισμένη σχέση με τους developers. Αυτό το άρθρο καλύπτει και τα τρία.

Αυτό είναι το Μέρος 1 του Budget for Failure, μιας σειράς τεσσάρων μερών για το τι είναι το site reliability engineering και πώς γίνεται στην πράξη. Τα Μέρη 1 και 2 είναι επιπέδου 101: ο ρόλος, και μετά οι αριθμοί πάνω στους οποίους τρέχει (SLI, SLO, SLA, error budgets). Τα Μέρη 3 και 4 είναι επιπέδου 201: τι πρέπει να κατέχει ένας SRE μέσα στον κώδικα, και τι να ελέγχει από την πλευρά του provider, είτε αυτός είναι ένα cloud είτε το δικό σας data center. Τα παραδείγματα είναι σε AWS, η πρακτική δεν είναι AWS-specific.

Από πού προέρχεται ο ρόλος

Ο όρος προέρχεται από την Google, όπου ο Ben Treynor Sloss έστησε την πρώτη ομάδα το 2003 και αργότερα τον περιέγραψε σε μία γραμμή στο SRE book: SRE είναι αυτό που συμβαίνει όταν ζητάτε από έναν software engineer να σχεδιάσει μια ομάδα operations. Η απάντηση του μηχανικού σε μια υπηρεσία που μεγάλωνε δεν ήταν να προσλάβει operators αναλογικά με την κίνηση. Ήταν να αυτοματοποιήσει τη δουλειά του operator, και να βάλει ένα σκληρό όριο στο πόση χειρωνακτική δουλειά επιτρεπόταν να δεχτεί η ομάδα.

Η σχέση με το DevOps συνοψίζεται συνήθως, πάλι από την Google, ως "class SRE implements interface DevOps". Το DevOps είναι ένα σύνολο αρχών: κοινή ιδιοκτησία, μικρές αλλαγές, αυτοματοποίηση, μέτρηση. Το SRE είναι μία συγκεκριμένη υλοποίηση αυτών των αρχών με ενσωματωμένες απόψεις, όπως το ακριβώς πώς μετριέται η αξιοπιστία και το ακριβώς τι συμβαίνει όταν η μέτρηση λέει ότι μια υπηρεσία δεν είναι αρκετά αξιόπιστη.

Για τι είναι υπεύθυνος ένας SRE

Το SRE book απαριθμεί το εύρος σε μία πρόταση: μια ομάδα SRE είναι υπεύθυνη για τη διαθεσιμότητα, το latency, την απόδοση, την αποδοτικότητα, το change management, το monitoring, την απόκριση σε έκτακτα περιστατικά, και το capacity planning των υπηρεσιών της. Αναλυμένο σε αυτό που σημαίνει μέσα σε μια εργάσιμη εβδομάδα:

  • Διαθεσιμότητα και latency. Να ορίζει τι σημαίνει "λειτουργεί" για τους χρήστες ως αριθμό, να το μετρά, και να το υπερασπίζεται. Το Μέρος 2 αφορά εξ ολοκλήρου αυτό.
  • Change management. Οι περισσότερες διακοπές προκαλούνται από μια αλλαγή. Ο SRE κατέχει τον μηχανισμό που κάνει την αλλαγή ασφαλή: σταδιακά rollouts, αυτόματο rollback, και τα στοιχεία που δείχνουν ότι ένα release είναι υγιές.
  • Monitoring και alerting. Να αποφασίζει ποια σήματα αξίζουν έναν άνθρωπο στις 03:00 και ποια ανήκουν σε ένα dashboard. Ένα page που δεν χρειάζεται καμία ενέργεια είναι ελάττωμα του alerting, και ο SRE το διορθώνει όπως κάθε άλλο ελάττωμα.
  • Απόκριση σε έκτακτα περιστατικά. Να είναι on-call, να τρέχει τα incidents με σαφή δομή διοίκησης, και να αποκαθιστά πρώτα την υπηρεσία και να διαγιγνώσκει μετά.
  • Postmortems. Μετά από ένα incident, μια γραπτή, blameless ανάλυση του τι συνέβη και ποια συστημική διόρθωση αποτρέπει αυτή την κατηγορία αστοχίας. Το blameless είναι τεχνική απαίτηση: οι άνθρωποι που περιμένουν τιμωρία σταματούν να αναφέρουν τι είδαν.
  • Capacity planning. Να ξέρει πόσο περιθώριο υπάρχει, πώς μεγαλώνει η ζήτηση, και πόσο χρόνο παίρνει να φτάσει νέα χωρητικότητα: λεπτά σε ένα cloud, μήνες on-prem.
  • Αποδοτικότητα και απόδοση. Αξιοπιστία αγορασμένη με απεριόριστη εφεδρική χωρητικότητα δεν είναι engineering. Το κόστος ανά request είναι επίσης αριθμός του SRE.
  • Εξάλειψη του toil. Καλύπτεται παρακάτω, επειδή είναι το κομμάτι που κάνει τα υπόλοιπα εφικτά.

Τι κοιτάζει ένας SRE

Ένας DevOps engineer που έρχεται από το infrastructure τείνει να παρακολουθεί πόρους: CPU, μνήμη, δίσκο, αριθμό nodes. Ένας SRE ξεκινά ένα επίπεδο πιο πάνω, από αυτό που βίωσε ο χρήστης, και χρησιμοποιεί τις μετρικές πόρων μόνο για να το εξηγήσει. Το τυπικό αρχικό σύνολο είναι τα τέσσερα golden signals από το κεφάλαιο για το monitoring του SRE book:

ΣήμαΣε ποια ερώτηση απαντάΠού ζει στο AWS
LatencyΠόσο διαρκούν τα requests, χωριστά για επιτυχίες και αποτυχίες;ALB TargetResponseTime percentiles, API Gateway Latency, application traces
ΚίνησηΠόση ζήτηση δέχεται το σύστημα;ALB RequestCount, μηνύματα SQS που στάλθηκαν, Lambda Invocations
ΣφάλματαΤι ποσοστό των requests αποτυγχάνει;ALB HTTPCode_Target_5XX_Count και HTTPCode_ELB_5XX_Count, Lambda Errors
ΚορεσμόςΠόσο γεμάτος είναι ο πιο περιορισμένος πόρος;Συνδέσεις RDS έναντι max_connections, ηλικία ουράς, ECS CPU reservation, χρήση service quota

Δύο λεπτομέρειες ξεχωρίζουν μια ανάγνωση SRE αυτών των σημάτων από μια πρόχειρη. Το latency διαβάζεται ως κατανομή, ποτέ ως μέσος όρος: το 99ο percentile είναι εκεί που βρίσκονται οι δυσαρεστημένοι χρήστες. Και ο κορεσμός διαβάζεται έναντι του ορίου που πραγματικά θα χτυπήσει πρώτο, το οποίο σπάνια είναι η CPU. Είναι το connection pool της βάσης δεδομένων, η κατανομή ports του NAT gateway, το Lambda concurrency σε επίπεδο λογαριασμού, ή ο προϋπολογισμός IOPS του EBS volume.

Πέρα από τα τέσσερα σήματα, ένας SRE παρακολουθεί τα πράγματα που προβλέπουν το incident του επόμενου μήνα: τον ρυθμό και το ποσοστό αποτυχίας των αλλαγών, την ηλικία του παλαιότερου dependency χωρίς patch, πόσο από την περασμένη εβδομάδα πήγε σε χειρωνακτική δουλειά, και πόσα pages έλαβε ο on-call μηχανικός.

Ο κανόνας του 50 τοις εκατό και το toil

Το χαρακτηριστικό που κάνει το SRE διαφορετικό από μια ομάδα operations με καλύτερο τίτλο είναι ένα όριο. Στο μοντέλο της Google ένας SRE ξοδεύει τουλάχιστον το 50 τοις εκατό του χρόνου του σε δουλειά engineering, κατά μέσο όρο σε μερικά τρίμηνα. Το υπόλοιπο μπορεί να πάει σε λειτουργική δουλειά: tickets, on-call, χειρωνακτικές εργασίες.

Το χειρωνακτικό κομμάτι έχει όνομα, toil, και ακριβή ορισμό: δουλειά συνδεδεμένη με τη λειτουργία μιας υπηρεσίας σε production που τείνει να είναι χειρωνακτική, επαναλαμβανόμενη, αυτοματοποιήσιμη, τακτική, χωρίς διαρκή αξία, και που κλιμακώνεται γραμμικά καθώς μεγαλώνει η υπηρεσία. Επανεκκίνηση ενός κολλημένου worker, χειροκίνητη ανανέωση ενός πιστοποιητικού, έγκριση ενός αιτήματος quota, αντιγραφή μιας βάσης δεδομένων για έναν developer. Το καθένα είναι μικρό. Όλα μαζί είναι ο λόγος που μια ομάδα πέντε ατόμων δεν μπορεί να κάνει καθόλου engineering.

Το όριο είναι αυτό που δίνει στον SRE το δικαίωμα να πει όχι. Όταν το toil ξεπερνά τον μισό χρόνο της ομάδας, η απάντηση δεν είναι ηρωισμοί. Είναι να αυτοματοποιηθεί η μεγαλύτερη πηγή, ή να επιστραφεί το λειτουργικό φορτίο στην ομάδα που το παράγει μέχρι να μικρύνει. Το on-call ακολουθεί την ίδια λογική: το SRE book τοποθετεί ένα βιώσιμο φορτίο στα περίπου δύο incidents ανά βάρδια on-call, επειδή κάθε incident χρειάζεται follow-up και ένα postmortem, και ένας άνθρωπος που παίρνει πέντε pages τη νύχτα δεν κάνει κανένα από τα δύο.

Πώς ένας SRE βοηθά τους developers

Η χειρότερη εκδοχή αυτού του ρόλου είναι μια πύλη: οι developers πετούν ένα release πάνω από έναν τοίχο και μια ομάδα αξιοπιστίας αποφασίζει αν επιτρέπεται να περάσει. Η χρήσιμη εκδοχή αντιμετωπίζει τους developers ως τον πελάτη και την αξιοπιστία ως προϊόν που ο SRE χτίζει για αυτούς. Τέσσερις συγκεκριμένες μορφές:

Ο στρωμένος δρόμος (paved road). Ένα service template που έρχεται με structured logging, metrics, tracing, health checks, ένα deployment pipeline με canary και rollback, και λογικά alarms ήδη συνδεδεμένα. Ένας developer που παίρνει το default αποκτά μια αξιόπιστη υπηρεσία χωρίς να διαβάσει runbook. Αυτό είναι το πιο πολύτιμο πράγμα που παραδίδει μια ομάδα SRE.

Το production readiness review. Πριν μια νέα υπηρεσία δεχτεί πραγματική κίνηση, ο SRE την περνά μαζί με τους developers: από τι εξαρτάται, τι συμβαίνει όταν κάθε dependency είναι αργό, ποια είναι τα timeouts, πώς γίνεται rollback, ποιος παίρνει page. Είναι μια επισκόπηση σχεδιασμού, που γίνεται αρκετά νωρίς ώστε να αλλάξει τον σχεδιασμό. Το Μέρος 3 περνά από το τι να ψάξετε.

Το error budget. Ένας κοινός, προσυμφωνημένος αριθμός που λέει και στις δύο πλευρές πότε είναι ασφαλές να στέλνουν γρήγορα και πότε να επιβραδύνουν. Αντικαθιστά τη διαφωνία για το αν ένα release είναι "πολύ ριψοκίνδυνο" με μια ένδειξη. Το Μέρος 2 το χτίζει.

Κοινό on-call. Οι developers που κρατούν το pager για τη δική τους υπηρεσία γράφουν διαφορετικό κώδικα. Πολλοί οργανισμοί ξεκινούν μια υπηρεσία στη rotation των developers και τη μεταφέρουν στο SRE μόνο όταν πιάσει έναν πήχη αξιοπιστίας, και την επιστρέφουν αν πέσει κάτω από αυτόν. Η δουλειά του SRE είναι να κάνει αυτή τη rotation ανθρώπινη, με καλά alerts και καλά runbooks, όχι να απορροφά τον πόνο ώστε να μην τον νιώθει κανείς πιο πάνω.

SRE και DevOps: πού διαφέρει η δουλειά

Αν βιοπορίζεστε τρέχοντας pipelines, Terraform και Kubernetes, το μεγαλύτερο μέρος των εργαλείων μεταφέρεται. Αυτό που αλλάζει είναι η ερώτηση στην οποία απαντά κάθε εργαλείο.

Ως DevOps engineerΩς SRE επιπλέον
Χτίζετε το CI/CD pipelineΑποφασίζετε ποια στοιχεία σταματούν ένα rollout αυτόματα, και μετράτε πόση αξιοπιστία κοστίζει κάθε release
Βάζετε alarms σε CPU, μνήμη και δίσκοΚάνετε page μόνο για συμπτώματα ορατά στον χρήστη, και κρατάτε τις μετρικές πόρων για τη διάγνωση
Παρέχετε infrastructure as codeΞέρετε τα failure domains του, τα quotas, και τι συμβαίνει όταν το control plane του provider είναι κάτω
Διορθώνετε το incidentΤρέχετε το incident, γράφετε το postmortem, και παραδίδετε τη διόρθωση που αφαιρεί την κατηγορία αστοχίας
Αυτοματοποιείτε μια εργασία όταν σας ζητηθείΠαρακολουθείτε το toil ως αριθμό και αρνείστε να το αφήσετε να ξεπεράσει τον μισό χρόνο της ομάδας
Αντιμετωπίζετε τον κώδικα εφαρμογής ως περιοχή των developersΤον διαβάζετε, ελέγχετε τα timeouts και τα retries του, και του στέλνετε pull requests

Η τελευταία γραμμή είναι αυτή που οι περισσότεροι infrastructure engineers υποτιμούν. Ένας SRE που δεν μπορεί να διαβάσει τον κώδικα της υπηρεσίας μπορεί μόνο να παρατηρεί τις αστοχίες απ' έξω. Η αξιοπιστία κρίνεται στο πώς μια συνάρτηση χειρίζεται ένα αργό dependency, και αυτό βρίσκεται στο repository, όχι στο cluster.

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

Η μετονομασία. Μια ομάδα operations που πήρε τον τίτλο SRE και την ίδια ουρά tickets δεν έχει αλλάξει τίποτα. Χωρίς το όριο στο toil και την εξουσία που το συνοδεύει, δεν υπάρχει χρόνος για engineering, και ο τίτλος περιγράφει μια φιλοδοξία.

Ο θυρωρός. Μια ομάδα αξιοπιστίας που εγκρίνει releases γίνεται το bottleneck που ο οργανισμός παρακάμπτει. Η επιρροή έρχεται από τον paved road και από τα δεδομένα, όχι από ένα βέτο.

Ο ήρωας. Ένας μηχανικός που ξέρει κάθε σύστημα και διορθώνει κάθε διακοπή είναι ένα single point of failure με μισθό. Τα incidents που τελειώνουν με το "ο Sam το έλυσε σε είκοσι λεπτά" χρειάζονται runbook, όχι χειροκρότημα.

Αξιοπιστία χωρίς αριθμό. Το "όσο πιο αξιόπιστο γίνεται" δεν μπορεί να προγραμματιστεί, να στελεχωθεί, ούτε να ανταλλαχθεί με features. Όλα σε αυτό το άρθρο εξαρτώνται από το να μπορείτε να πείτε πόσο αξιόπιστη πρέπει να είναι μια υπηρεσία και αν είναι αυτή τη στιγμή. Αυτό είναι το λεξιλόγιο των SLI, SLO και error budgets, και είναι το Μέρος 2.

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

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

Αναφορές