Το SRE (Site Reliability Engineering) είναι μια προσέγγιση για να γίνουν προσβάσιμα έργα web. Θεωρείται πλαίσιο για DevOps και λέει πώς να πετύχετε στην εφαρμογή των πρακτικών DevOps. Αυτό το άρθρο μεταφράζεται βιβλία από την Google. Ετοίμασα αυτή τη μετάφραση μόνος μου και βασίστηκα στη δική μου εμπειρία στην κατανόηση των διαδικασιών παρακολούθησης. Στο κανάλι του τηλεγραφήματος и Δημοσίευσα επίσης μια μετάφραση του Κεφαλαίου 6 του ίδιου βιβλίου σχετικά με τους στόχους σε επίπεδο υπηρεσιών.
Μετάφραση από cat. Απολαύστε την ανάγνωση!
Είναι αδύνατο να διαχειριστείτε μια υπηρεσία εάν δεν υπάρχει κατανόηση του ποιοι δείκτες έχουν πραγματικά σημασία και πώς να μετρηθούν και να αξιολογηθούν. Για το σκοπό αυτό, ορίζουμε και παρέχουμε ένα ορισμένο επίπεδο υπηρεσιών στους χρήστες μας, ανεξάρτητα από το αν χρησιμοποιούν ένα από τα εσωτερικά μας API ή ένα δημόσιο προϊόν.
Χρησιμοποιούμε τη διαίσθησή μας, την εμπειρία και την κατανόησή μας σχετικά με την επιθυμία των χρηστών να κατανοήσουν τους δείκτες επιπέδου υπηρεσίας (SLI), τους στόχους επιπέδου υπηρεσίας (SLO) και τις συμφωνίες επιπέδου υπηρεσίας (SLA). Αυτές οι διαστάσεις περιγράφουν τις κύριες μετρήσεις που θέλουμε να παρακολουθούμε και στις οποίες θα αντιδράσουμε εάν δεν μπορούμε να παρέχουμε την αναμενόμενη ποιότητα υπηρεσίας. Τελικά, η επιλογή των σωστών μετρήσεων βοηθά στην καθοδήγηση των σωστών ενεργειών εάν κάτι πάει στραβά, και επίσης δίνει στην ομάδα SRE εμπιστοσύνη στην υγεία της υπηρεσίας.
Αυτό το κεφάλαιο περιγράφει την προσέγγιση που χρησιμοποιούμε για την καταπολέμηση των προβλημάτων της μετρικής μοντελοποίησης, της επιλογής μετρήσεων και της μετρικής ανάλυσης. Το μεγαλύτερο μέρος της εξήγησης θα είναι χωρίς παραδείγματα, επομένως θα χρησιμοποιήσουμε την υπηρεσία Σαίξπηρ που περιγράφεται στο παράδειγμα εφαρμογής της (αναζήτηση για τα έργα του Σαίξπηρ) για να επεξηγήσουμε τα κύρια σημεία.
Ορολογία επιπέδου υπηρεσιών
Πολλοί αναγνώστες είναι πιθανώς εξοικειωμένοι με την έννοια του SLA, αλλά οι όροι SLI και SLO αξίζουν προσεκτικό ορισμό επειδή γενικά ο όρος SLA είναι υπερφορτωμένος και έχει μια σειρά από σημασίες ανάλογα με το πλαίσιο. Για λόγους σαφήνειας, θέλουμε να διαχωρίσουμε αυτές τις τιμές.
Δείκτες
Το SLI είναι ένας δείκτης επιπέδου υπηρεσίας—ένα προσεκτικά καθορισμένο ποσοτικό μέτρο μιας πτυχής του επιπέδου της παρεχόμενης υπηρεσίας.
Για τις περισσότερες υπηρεσίες, το κλειδί SLI θεωρείται ως καθυστέρηση αιτήματος - πόσος χρόνος χρειάζεται για να επιστραφεί μια απάντηση σε ένα αίτημα. Άλλα κοινά SLI περιλαμβάνουν το ποσοστό σφάλματος, που συχνά εκφράζεται ως κλάσμα όλων των αιτημάτων που λαμβάνονται, και τη διεκπεραίωση του συστήματος, που συνήθως μετράται σε αιτήματα ανά δευτερόλεπτο. Οι μετρήσεις συχνά συγκεντρώνονται: πρώτα συλλέγονται ακατέργαστα δεδομένα και στη συνέχεια μετατρέπονται σε ρυθμό μεταβολής, μέσο όρο ή εκατοστημόριο.
Στην ιδανική περίπτωση, το SLI μετρά απευθείας το επίπεδο εξυπηρέτησης που ενδιαφέρει, αλλά μερικές φορές μόνο μια σχετική μέτρηση είναι διαθέσιμη για μέτρηση, επειδή η αρχική είναι δύσκολο να ληφθεί ή να ερμηνευτεί. Για παράδειγμα, η καθυστέρηση από την πλευρά του πελάτη είναι συχνά μια πιο κατάλληλη μέτρηση, αλλά υπάρχουν φορές που η καθυστέρηση μπορεί να μετρηθεί μόνο στον διακομιστή.
Ένας άλλος τύπος SLI που είναι σημαντικός για τα SRE είναι η διαθεσιμότητα ή το χρονικό διάστημα κατά το οποίο μπορεί να χρησιμοποιηθεί μια υπηρεσία. Συχνά ορίζεται ως το ποσοστό των επιτυχημένων αιτημάτων, που μερικές φορές ονομάζεται απόδοση. (Διάρκεια ζωής—η πιθανότητα να διατηρηθούν τα δεδομένα για εκτεταμένη χρονική περίοδο—είναι επίσης σημαντική για τα συστήματα αποθήκευσης δεδομένων.) Αν και η διαθεσιμότητα 100% δεν είναι δυνατή, η διαθεσιμότητα κοντά στο 100% είναι συχνά εφικτή· οι τιμές διαθεσιμότητας εκφράζονται ως ο αριθμός των "εννιά" » ποσοστό διαθεσιμότητας. Για παράδειγμα, η διαθεσιμότητα 99% και 99,999% μπορεί να επισημαίνεται ως "2 εννιά" και "5 εννέα". Ο τρέχων δηλωμένος στόχος διαθεσιμότητας του Google Compute Engine είναι "τρεισήμισι εννιά" ή 99,95%.
Στόχοι
Ένα SLO είναι ένας στόχος επιπέδου υπηρεσίας: μια τιμή στόχος ή εύρος τιμών για ένα επίπεδο υπηρεσίας που μετράται από το SLI. Μια κανονική τιμή για το SLO είναι "SLI ≤ Target" ή "Lower Limit ≤ SLI ≤ Upper Limit". Για παράδειγμα, μπορεί να αποφασίσουμε ότι θα επιστρέψουμε τα αποτελέσματα αναζήτησης Σαίξπηρ "γρήγορα" ορίζοντας το SLO σε μια μέση καθυστέρηση ερωτήματος αναζήτησης μικρότερη από 100 χιλιοστά του δευτερολέπτου.
Η επιλογή του σωστού SLO είναι μια πολύπλοκη διαδικασία. Πρώτον, δεν μπορείτε πάντα να επιλέξετε μια συγκεκριμένη τιμή. Για εξωτερικά εισερχόμενα αιτήματα HTTP προς την υπηρεσία σας, η μέτρηση Query Per Second (QPS) καθορίζεται κυρίως από την επιθυμία των χρηστών σας να επισκεφτούν την υπηρεσία σας και δεν μπορείτε να ορίσετε SLO για αυτό.
Από την άλλη πλευρά, μπορείτε να πείτε ότι θέλετε η μέση καθυστέρηση για κάθε αίτημα να είναι μικρότερη από 100 χιλιοστά του δευτερολέπτου. Ο καθορισμός ενός τέτοιου στόχου μπορεί να σας αναγκάσει να γράψετε το frontend σας με χαμηλό λανθάνοντα χρόνο ή να αγοράσετε εξοπλισμό που παρέχει τέτοιο λανθάνοντα χρόνο. (100 χιλιοστά του δευτερολέπτου είναι προφανώς ένας αυθαίρετος αριθμός, αλλά είναι καλύτερο να έχουμε ακόμη χαμηλότερους αριθμούς καθυστέρησης. Υπάρχουν στοιχεία που υποδηλώνουν ότι οι γρήγορες ταχύτητες είναι καλύτερες από τις αργές ταχύτητες και ότι η καθυστέρηση στην επεξεργασία των αιτημάτων των χρηστών πάνω από συγκεκριμένες τιμές στην πραγματικότητα αναγκάζει τους ανθρώπους να μείνουν μακριά από την υπηρεσία σας.)
Και πάλι, αυτό είναι πιο διφορούμενο από ό, τι μπορεί να φαίνεται με την πρώτη ματιά: δεν πρέπει να αποκλείσετε εντελώς το QPS από τον υπολογισμό. Το γεγονός είναι ότι το QPS και η καθυστέρηση συνδέονται στενά μεταξύ τους: το υψηλότερο QPS οδηγεί συχνά σε υψηλότερους λανθάνοντες χρόνους και οι υπηρεσίες συνήθως παρουσιάζουν απότομη μείωση στην απόδοση όταν φτάσουν σε ένα συγκεκριμένο όριο φόρτωσης.
Η επιλογή και η δημοσίευση ενός SLO θέτει τις προσδοκίες των χρηστών σχετικά με τον τρόπο λειτουργίας της υπηρεσίας. Αυτή η στρατηγική μπορεί να μειώσει τα αβάσιμα παράπονα κατά του κατόχου της υπηρεσίας, όπως η αργή απόδοση. Χωρίς ρητή SLO, οι χρήστες συχνά δημιουργούν τις δικές τους προσδοκίες σχετικά με την επιθυμητή απόδοση, οι οποίες μπορεί να μην έχουν καμία σχέση με τις απόψεις των ανθρώπων που σχεδιάζουν και διαχειρίζονται την υπηρεσία. Αυτή η κατάσταση μπορεί να οδηγήσει σε διογκωμένες προσδοκίες από την υπηρεσία, όταν οι χρήστες πιστεύουν λανθασμένα ότι η υπηρεσία θα είναι πιο προσιτή από ό,τι είναι στην πραγματικότητα και να προκαλέσει δυσπιστία όταν οι χρήστες πιστεύουν ότι το σύστημα είναι λιγότερο αξιόπιστο από ό,τι είναι στην πραγματικότητα.
συμφωνίες
Μια συμφωνία επιπέδου υπηρεσίας είναι μια ρητή ή σιωπηρή σύμβαση με τους χρήστες σας που περιλαμβάνει τις συνέπειες της συνάντησης (ή μη εκπλήρωσης) των SLO που περιέχουν. Οι συνέπειες αναγνωρίζονται πιο εύκολα όταν είναι οικονομικές - έκπτωση ή πρόστιμο - αλλά μπορούν να λάβουν άλλες μορφές. Ένας εύκολος τρόπος να μιλήσουμε για τη διαφορά μεταξύ των SLO και των SLA είναι να ρωτήσουμε "τι θα συμβεί εάν δεν πληρούνται οι SLO;" Εάν δεν υπάρχουν σαφείς συνέπειες, είναι σχεδόν βέβαιο ότι εξετάζετε ένα SLO.
Το SRE συνήθως δεν εμπλέκεται στη δημιουργία SLA επειδή οι SLA συνδέονται στενά με επιχειρηματικές αποφάσεις και αποφάσεις προϊόντων. Το SRE, ωστόσο, συμμετέχει στο να βοηθήσει στον μετριασμό των συνεπειών των αποτυχημένων SLO. Μπορούν επίσης να βοηθήσουν στον προσδιορισμό του SLI: Προφανώς, πρέπει να υπάρχει ένας αντικειμενικός τρόπος μέτρησης του SLO στη συμφωνία, διαφορετικά θα υπάρξει διαφωνία.
Η Αναζήτηση Google είναι ένα παράδειγμα σημαντικής υπηρεσίας που δεν διαθέτει δημόσια SLA: θέλουμε όλοι να χρησιμοποιούν την Αναζήτηση όσο το δυνατόν πιο αποτελεσματικά, αλλά δεν έχουμε υπογράψει σύμβαση με τον κόσμο. Ωστόσο, εξακολουθούν να υπάρχουν συνέπειες εάν η αναζήτηση δεν είναι διαθέσιμη - η μη διαθεσιμότητα οδηγεί σε πτώση της φήμης μας καθώς και σε μείωση των διαφημιστικών εσόδων. Πολλές άλλες υπηρεσίες της Google, όπως το Google for Work, έχουν ρητές συμφωνίες επιπέδου υπηρεσιών με τους χρήστες. Ανεξάρτητα από το αν μια συγκεκριμένη υπηρεσία έχει SLA, είναι σημαντικό να ορίσετε το SLI και το SLO και να τα χρησιμοποιήσετε για τη διαχείριση της υπηρεσίας.
Τόση πολλή θεωρία - τώρα για την εμπειρία.
Δείκτες στην πράξη
Δεδομένου ότι καταλήξαμε στο συμπέρασμα ότι είναι σημαντικό να επιλέγουμε κατάλληλες μετρήσεις για τη μέτρηση του επιπέδου υπηρεσίας, πώς γνωρίζετε τώρα ποιες μετρήσεις έχουν σημασία για μια υπηρεσία ή ένα σύστημα;
Τι ενδιαφέρεστε εσείς και οι χρήστες σας;
Δεν χρειάζεται να χρησιμοποιείτε κάθε μέτρηση ως SLI που μπορείτε να παρακολουθείτε σε ένα σύστημα παρακολούθησης. Η κατανόηση του τι θέλουν οι χρήστες από ένα σύστημα θα σας βοηθήσει να επιλέξετε διάφορες μετρήσεις. Η επιλογή πάρα πολλών δεικτών καθιστά δύσκολη την εστίαση σε σημαντικούς δείκτες, ενώ η επιλογή ενός μικρού αριθμού μπορεί να αφήσει μεγάλα κομμάτια του συστήματός σας χωρίς επίβλεψη. Συνήθως χρησιμοποιούμε πολλούς βασικούς δείκτες για να αξιολογήσουμε και να κατανοήσουμε την υγεία ενός συστήματος.
Οι υπηρεσίες μπορούν γενικά να αναλυθούν σε διάφορα μέρη όσον αφορά το SLI που σχετίζονται με αυτές:
- Προσαρμοσμένα συστήματα διεπαφής, όπως οι διεπαφές αναζήτησης για την υπηρεσία Shakespeare από το παράδειγμά μας. Πρέπει να είναι διαθέσιμα, να μην έχουν καθυστερήσεις και να έχουν επαρκές εύρος ζώνης. Συνεπώς, μπορούν να τεθούν ερωτήσεις: μπορούμε να ανταποκριθούμε στο αίτημα; Πόσος χρόνος χρειάστηκε για να ανταποκριθεί στο αίτημα; Πόσα αιτήματα μπορούν να διεκπεραιωθούν;
- Συστήματα αποθήκευσης. Εκτιμούν τη χαμηλή καθυστέρηση απόκρισης, τη διαθεσιμότητα και την ανθεκτικότητα. Σχετικές ερωτήσεις: Πόσος χρόνος χρειάζεται για την ανάγνωση ή την εγγραφή δεδομένων; Μπορούμε να έχουμε πρόσβαση στα δεδομένα κατόπιν αιτήματος; Είναι διαθέσιμα τα δεδομένα όταν τα χρειαζόμαστε; Δείτε το Κεφάλαιο 26 Ακεραιότητα δεδομένων: Ό,τι διαβάζετε είναι αυτό που γράφετε για μια λεπτομερή συζήτηση αυτών των ζητημάτων.
- Τα συστήματα μεγάλων δεδομένων, όπως οι αγωγοί επεξεργασίας δεδομένων, βασίζονται στη διεκπεραίωση και την καθυστέρηση επεξεργασίας ερωτημάτων. Σχετικές ερωτήσεις: Πόσα δεδομένα υποβάλλονται σε επεξεργασία; Πόσος χρόνος χρειάζεται για να ταξιδέψουν τα δεδομένα από τη λήψη ενός αιτήματος έως την έκδοση μιας απάντησης; (Ορισμένα μέρη του συστήματος μπορεί επίσης να έχουν καθυστερήσεις σε ορισμένα στάδια.)
Συλλογή δεικτών
Πολλοί δείκτες επιπέδου υπηρεσιών συλλέγονται πιο φυσικά από την πλευρά του διακομιστή, χρησιμοποιώντας ένα σύστημα παρακολούθησης όπως το Borgmon (δείτε παρακάτω). ) ή Prometheus, ή απλώς περιοδικά αναλύοντας τα αρχεία καταγραφής, προσδιορίζοντας απαντήσεις HTTP με κατάσταση 500. Ωστόσο, ορισμένα συστήματα θα πρέπει να είναι εξοπλισμένα με συλλογή μετρήσεων από την πλευρά του πελάτη, καθώς η έλλειψη παρακολούθησης από την πλευρά του πελάτη μπορεί να οδηγήσει σε απώλεια ορισμένων προβλημάτων που επηρεάζουν χρήστες, αλλά δεν επηρεάζουν τις μετρήσεις από την πλευρά του διακομιστή. Για παράδειγμα, η εστίαση στον λανθάνοντα χρόνο απόκρισης υποστήριξης της εφαρμογής δοκιμής αναζήτησης Shakespeare μπορεί να οδηγήσει σε λανθάνουσα κατάσταση από την πλευρά του χρήστη λόγω προβλημάτων JavaScript: σε αυτήν την περίπτωση, η μέτρηση του χρόνου που χρειάζεται το πρόγραμμα περιήγησης για να επεξεργαστεί τη σελίδα είναι καλύτερη μέτρηση.
Συσσωμάτωση
Για απλότητα και ευκολία στη χρήση, συχνά συγκεντρώνουμε ακατέργαστες μετρήσεις. Αυτό πρέπει να γίνει προσεκτικά.
Ορισμένες μετρήσεις φαίνονται απλές, όπως αιτήματα ανά δευτερόλεπτο, αλλά ακόμη και αυτή η φαινομενικά απλή μέτρηση συγκεντρώνει σιωπηρά δεδομένα με την πάροδο του χρόνου. Η μέτρηση λαμβάνεται συγκεκριμένα μία φορά ανά δευτερόλεπτο ή υπολογίζεται ο μέσος όρος της μέτρησης στον αριθμό των αιτημάτων ανά λεπτό; Η τελευταία επιλογή μπορεί να κρύψει έναν πολύ μεγαλύτερο στιγμιαίο αριθμό αιτημάτων που διαρκούν μόνο λίγα δευτερόλεπτα. Σκεφτείτε ένα σύστημα που εξυπηρετεί 200 αιτήσεις ανά δευτερόλεπτο με ζυγούς αριθμούς και 0 τον υπόλοιπο χρόνο. Μια σταθερά με τη μορφή μέσης τιμής 100 αιτημάτων ανά δευτερόλεπτο και το διπλάσιο του στιγμιαίου φορτίου δεν είναι το ίδιο πράγμα. Ομοίως, ο μέσος όρος των καθυστερήσεων ερωτημάτων μπορεί να φαίνεται ελκυστικός, αλλά κρύβει μια σημαντική λεπτομέρεια: είναι πιθανό τα περισσότερα ερωτήματα να είναι γρήγορα, αλλά θα υπάρχουν πολλά ερωτήματα που είναι αργά.
Οι περισσότεροι δείκτες θεωρούνται καλύτερα ως κατανομές παρά ως μέσοι όροι. Για παράδειγμα, για τον λανθάνοντα χρόνο SLI, ορισμένα αιτήματα θα διεκπεραιώνονται γρήγορα, ενώ ορισμένα θα διαρκούν πάντα περισσότερο, μερικές φορές πολύ περισσότερο. Ένας απλός μέσος όρος μπορεί να κρύψει αυτές τις μεγάλες καθυστερήσεις. Το σχήμα δείχνει ένα παράδειγμα: αν και ένα τυπικό αίτημα απαιτεί περίπου 50 ms για να εξυπηρετηθεί, το 5% των αιτημάτων είναι 20 φορές πιο αργά! Η παρακολούθηση και η ειδοποίηση με βάση μόνο τον μέσο λανθάνοντα χρόνο δεν εμφανίζει αλλαγές στη συμπεριφορά κατά τη διάρκεια της ημέρας, ενώ στην πραγματικότητα υπάρχουν αισθητές αλλαγές στον χρόνο επεξεργασίας ορισμένων αιτημάτων (ανώτατη γραμμή).
Καθυστέρηση συστήματος 50, 85, 95 και 99 εκατοστημορίου. Ο άξονας Υ είναι σε λογαριθμική μορφή.
Η χρήση εκατοστημόνων για δείκτες σάς επιτρέπει να δείτε το σχήμα της κατανομής και τα χαρακτηριστικά της: ένα υψηλό επίπεδο εκατοστημόριου, όπως το 99 ή το 99,9, δείχνει τη χειρότερη τιμή, ενώ το 50 εκατοστημόριο (γνωστό και ως διάμεσος) δείχνει την πιο συχνή κατάσταση η μετρική. Όσο μεγαλύτερη είναι η διασπορά του χρόνου απόκρισης, τόσο περισσότερα μακροχρόνια αιτήματα επηρεάζουν την εμπειρία του χρήστη. Το εφέ ενισχύεται υπό υψηλό φορτίο και παρουσία ουρών. Η έρευνα εμπειρίας χρήστη έχει δείξει ότι οι άνθρωποι προτιμούν γενικά ένα πιο αργό σύστημα με υψηλή διακύμανση χρόνου απόκρισης, επομένως ορισμένες ομάδες SRE επικεντρώνονται μόνο σε υψηλές βαθμολογίες εκατοστημόριου, με βάση ότι εάν η συμπεριφορά μιας μέτρησης στο 99,9 εκατοστημόριο είναι καλή, οι περισσότεροι χρήστες δεν θα αντιμετωπίσουν προβλήματα .
Σημείωση για τα στατιστικά λάθη
Γενικά προτιμούμε να εργαζόμαστε με εκατοστημόρια παρά με τον μέσο όρο (αριθμητικός μέσος όρος) ενός συνόλου τιμών. Αυτό μας επιτρέπει να εξετάσουμε πιο διασκορπισμένες τιμές, οι οποίες συχνά έχουν σημαντικά διαφορετικά (και πιο ενδιαφέροντα) χαρακτηριστικά από τον μέσο όρο. Λόγω της τεχνητής φύσης των υπολογιστικών συστημάτων, οι μετρικές τιμές είναι συχνά λοξές, για παράδειγμα, κανένα αίτημα δεν μπορεί να λάβει απάντηση σε λιγότερο από 0 ms και ένα χρονικό όριο 1000 ms σημαίνει ότι δεν μπορούν να υπάρξουν επιτυχείς απαντήσεις με τιμές μεγαλύτερες από το τάιμ άουτ. Ως αποτέλεσμα, δεν μπορούμε να δεχτούμε ότι η μέση και η διάμεσος μπορεί να είναι ίδια ή κοντά η μία στην άλλη!
Χωρίς προηγούμενη δοκιμή και εκτός εάν ισχύουν ορισμένες τυπικές υποθέσεις και προσεγγίσεις, προσέχουμε να μην συμπεράνουμε ότι τα δεδομένα μας διανέμονται κανονικά. Εάν η διανομή δεν είναι η αναμενόμενη, η διαδικασία αυτοματισμού που διορθώνει το πρόβλημα (για παράδειγμα, όταν βλέπει ακραίες τιμές, επανεκκινεί τον διακομιστή με υψηλές καθυστερήσεις επεξεργασίας αιτημάτων) μπορεί να το κάνει πολύ συχνά ή όχι αρκετά συχνά (και τα δύο δεν είναι πολύ καλά).
Τυποποίηση δεικτών
Συνιστούμε να τυποποιήσετε τα γενικά χαρακτηριστικά για το SLI, έτσι ώστε να μην χρειάζεται να κάνετε εικασίες για αυτά κάθε φορά. Οποιοδήποτε χαρακτηριστικό που ικανοποιεί τυπικά μοτίβα μπορεί να εξαιρεθεί από τις προδιαγραφές ενός μεμονωμένου SLI, για παράδειγμα:
- Διαστήματα συγκέντρωσης: "κατά μέσο όρο πάνω από 1 λεπτό"
- Περιοχές συγκέντρωσης: "Όλες οι εργασίες στο σύμπλεγμα"
- Πόσο συχνά γίνονται οι μετρήσεις: "Κάθε 10 δευτερόλεπτα"
- Ποια αιτήματα περιλαμβάνονται: "HTTP GET από εργασίες παρακολούθησης μαύρου κουτιού"
- Πώς λαμβάνονται τα δεδομένα: "Χάρη στην παρακολούθηση που μετρήθηκε στον διακομιστή"
- Καθυστέρηση πρόσβασης δεδομένων: "Χρόνος έως το τελευταίο byte"
Για να εξοικονομήσετε προσπάθεια, δημιουργήστε ένα σύνολο επαναχρησιμοποιήσιμων προτύπων SLI για κάθε κοινή μέτρηση. Καθιστούν επίσης ευκολότερο για όλους να κατανοήσουν τι σημαίνει μια συγκεκριμένη SLI.
Στόχοι στην πράξη
Ξεκινήστε σκέφτεστε (ή ανακαλύπτοντας!) τι ενδιαφέρει τους χρήστες σας, όχι τι μπορείτε να μετρήσετε. Συχνά αυτό που ενδιαφέρει τους χρήστες σας είναι δύσκολο ή αδύνατο να μετρηθεί, έτσι καταλήγετε να πλησιάζετε περισσότερο τις ανάγκες τους. Ωστόσο, αν ξεκινήσετε με ό,τι είναι εύκολο να μετρήσετε, θα καταλήξετε με λιγότερο χρήσιμα SLO. Ως αποτέλεσμα, μερικές φορές έχουμε διαπιστώσει ότι ο αρχικά προσδιορισμός των επιθυμητών στόχων και στη συνέχεια η εργασία με συγκεκριμένους δείκτες λειτουργεί καλύτερα από την επιλογή δεικτών και στη συνέχεια την επίτευξη των στόχων.
Καθορίστε τους στόχους σας
Για μέγιστη σαφήνεια, θα πρέπει να οριστεί ο τρόπος μέτρησης των SLO και οι συνθήκες υπό τις οποίες ισχύουν. Για παράδειγμα, θα μπορούσαμε να πούμε το εξής (η δεύτερη γραμμή είναι ίδια με την πρώτη, αλλά χρησιμοποιεί τις προεπιλογές SLI):
- Το 99% (κατά μέσο όρο πάνω από 1 λεπτό) των κλήσεων Get RPC θα ολοκληρωθεί σε λιγότερο από 100 ms (μετρούμενο σε όλους τους διακομιστές υποστήριξης).
- Το 99% των κλήσεων Get RPC θα ολοκληρωθεί σε λιγότερο από 100 ms.
Εάν το σχήμα των καμπυλών απόδοσης είναι σημαντικό, μπορείτε να καθορίσετε πολλά SLO:
- Το 90% των κλήσεων Get RPC ολοκληρώθηκαν σε λιγότερο από 1 ms.
- Το 99% των κλήσεων Get RPC ολοκληρώθηκαν σε λιγότερο από 10 ms.
- Το 99.9% των κλήσεων Get RPC ολοκληρώθηκαν σε λιγότερο από 100 ms.
Εάν οι χρήστες σας δημιουργούν ετερογενείς φόρτους εργασίας: μαζική επεξεργασία (για την οποία η διεκπεραίωση είναι σημαντική) και διαδραστική επεξεργασία (για την οποία είναι σημαντική η καθυστέρηση), ίσως αξίζει τον κόπο να ορίσετε ξεχωριστούς στόχους για κάθε κατηγορία φόρτωσης:
- Το 95% των αιτημάτων πελατών απαιτούν απόδοση. Ορίστε τον αριθμό των κλήσεων RPC που εκτελούνται <1 s.
- Το 99% των πελατών ενδιαφέρεται για τον λανθάνοντα χρόνο. Ορίστε τον αριθμό των κλήσεων RPC με κίνηση <1 KB και εκτέλεση <10 ms.
Δεν είναι ρεαλιστικό και ανεπιθύμητο να επιμένουμε ότι οι SLO θα πληρούνται στο 100% του χρόνου: αυτό μπορεί να μειώσει τον ρυθμό εισαγωγής νέων λειτουργιών και ανάπτυξης και να απαιτήσει ακριβές λύσεις. Αντίθετα, είναι καλύτερο να επιτρέπετε έναν προϋπολογισμό σφάλματος - το ποσοστό του επιτρεπόμενου χρόνου διακοπής λειτουργίας του συστήματος - και να παρακολουθείτε αυτήν την τιμή καθημερινά ή εβδομαδιαία. Η ανώτερη διοίκηση μπορεί να θέλει μηνιαίες ή τριμηνιαίες αξιολογήσεις. (Ο προϋπολογισμός σφάλματος είναι απλώς ένα SLO για σύγκριση με άλλο SLO.)
Το ποσοστό των παραβιάσεων SLO μπορεί να συγκριθεί με τον προϋπολογισμό σφάλματος (βλ. Κεφάλαιο 3 και ενότητα ), με την τιμή διαφοράς να χρησιμοποιείται ως είσοδος στη διαδικασία που αποφασίζει πότε θα αναπτυχθούν νέες εκδόσεις.
Επιλογή τιμών στόχου
Η επιλογή των αξιών προγραμματισμού (SLO) δεν είναι μια καθαρά τεχνική δραστηριότητα λόγω του προϊόντος και των επιχειρηματικών συμφερόντων που πρέπει να αντικατοπτρίζονται στα επιλεγμένα SLI, SLO (και πιθανώς SLA). Ομοίως, μπορεί να χρειαστεί να ανταλλάσσονται πληροφορίες σχετικά με θέματα που σχετίζονται με το προσωπικό, το χρόνο για την αγορά, τη διαθεσιμότητα εξοπλισμού και τη χρηματοδότηση. Το SRE θα πρέπει να είναι μέρος αυτής της συνομιλίας και να βοηθήσει στην κατανόηση των κινδύνων και της βιωσιμότητας των διαφορετικών επιλογών. Έχουμε καταλήξει σε μερικές ερωτήσεις που θα μπορούσαν να βοηθήσουν στη διασφάλιση μιας πιο παραγωγικής συζήτησης:
Μην επιλέγετε έναν στόχο με βάση την τρέχουσα απόδοση.
Ενώ η κατανόηση των δυνατοτήτων και των ορίων ενός συστήματος είναι σημαντική, η προσαρμογή μετρήσεων χωρίς συλλογισμό μπορεί να σας εμποδίσει να διατηρήσετε το σύστημα: θα απαιτηθούν ηρωικές προσπάθειες για την επίτευξη στόχων που δεν μπορούν να επιτευχθούν χωρίς σημαντικό επανασχεδιασμό.
Να είσαι απλός
Οι σύνθετοι υπολογισμοί SLI μπορούν να αποκρύψουν τις αλλαγές στην απόδοση του συστήματος και να κάνουν πιο δύσκολη την εύρεση της αιτίας του προβλήματος.
Αποφύγετε τα απόλυτα
Ενώ είναι δελεαστικό να έχουμε ένα σύστημα που μπορεί να χειριστεί ένα απεριόριστα αυξανόμενο φορτίο χωρίς να αυξάνει την καθυστέρηση, αυτή η απαίτηση δεν είναι ρεαλιστική. Ένα σύστημα που προσεγγίζει τέτοια ιδανικά θα απαιτήσει πιθανότατα πολύ χρόνο για να σχεδιαστεί και να κατασκευαστεί, θα είναι ακριβό στη λειτουργία του και θα είναι πολύ καλό για τις προσδοκίες των χρηστών που θα έκαναν με οτιδήποτε λιγότερο.
Χρησιμοποιήστε όσο το δυνατόν λιγότερα SLO
Επιλέξτε επαρκή αριθμό SLO για να εξασφαλίσετε καλή κάλυψη των χαρακτηριστικών του συστήματος. Προστατέψτε τις SLO που επιλέγετε: Εάν δεν μπορείτε ποτέ να κερδίσετε ένα επιχείρημα σχετικά με τις προτεραιότητες προσδιορίζοντας μια συγκεκριμένη SLO, μάλλον δεν αξίζει να λάβετε υπόψη αυτήν την SLO. Ωστόσο, δεν είναι όλα τα χαρακτηριστικά του συστήματος επιδεκτικά σε SLO: είναι δύσκολο να υπολογιστεί το επίπεδο ευχαρίστησης του χρήστη χρησιμοποιώντας SLO.
Μην κυνηγάς την τελειότητα
Μπορείτε πάντα να βελτιώσετε τους ορισμούς και τους στόχους των SLO με την πάροδο του χρόνου καθώς μαθαίνετε περισσότερα για τη συμπεριφορά του συστήματος υπό φόρτωση. Είναι καλύτερα να ξεκινήσετε με έναν κυμαινόμενο στόχο που θα βελτιώσετε με την πάροδο του χρόνου παρά να επιλέξετε έναν υπερβολικά αυστηρό στόχο που πρέπει να χαλαρώσετε όταν θεωρείτε ότι είναι ανέφικτος.
Οι SLO μπορούν και πρέπει να αποτελούν βασικό μοχλό για την ιεράρχηση της εργασίας για τις SRE και τους προγραμματιστές προϊόντων, επειδή αντικατοπτρίζουν μια ανησυχία για τους χρήστες. Ένα καλό SLO είναι ένα χρήσιμο εργαλείο επιβολής για μια ομάδα ανάπτυξης. Αλλά μια κακώς σχεδιασμένη SLO μπορεί να οδηγήσει σε σπάταλη εργασία εάν η ομάδα κάνει ηρωικές προσπάθειες για να επιτύχει μια υπερβολικά επιθετική SLO ή ένα φτωχό προϊόν εάν η SLO είναι πολύ χαμηλή. Το SLO είναι ένας ισχυρός μοχλός, χρησιμοποιήστε το με σύνεση.
Ελέγξτε τις μετρήσεις σας
Το SLI και το SLO είναι βασικά στοιχεία που χρησιμοποιούνται για τη διαχείριση συστημάτων:
- Παρακολούθηση και μέτρηση συστημάτων SLI.
- Συγκρίνετε το SLI με το SLO και αποφασίστε εάν χρειάζεται δράση.
- Εάν απαιτείται δράση, υπολογίστε τι πρέπει να συμβεί για να επιτευχθεί ο στόχος.
- Ολοκληρώστε αυτήν την ενέργεια.
Για παράδειγμα, εάν το βήμα 2 δείχνει ότι το αίτημα λήγει και θα διακόψει το SLO σε λίγες ώρες εάν δεν γίνει τίποτα, το βήμα 3 μπορεί να περιλαμβάνει τον έλεγχο της υπόθεσης ότι οι διακομιστές είναι συνδεδεμένοι με CPU και η προσθήκη περισσότερων διακομιστών θα κατανείμει το φορτίο . Χωρίς SLO, δεν θα ξέρετε αν (ή πότε) να αναλάβετε δράση.
Ορισμός SLO - τότε θα οριστούν οι προσδοκίες των χρηστών
Η δημοσίευση ενός SLO θέτει τις προσδοκίες των χρηστών για τη συμπεριφορά του συστήματος. Οι χρήστες (και οι πιθανοί χρήστες) συχνά θέλουν να ξέρουν τι να περιμένουν από μια υπηρεσία για να καταλάβουν αν είναι κατάλληλη για χρήση. Για παράδειγμα, τα άτομα που θέλουν να χρησιμοποιήσουν έναν ιστότοπο κοινής χρήσης φωτογραφιών μπορεί να θέλουν να αποφύγουν τη χρήση μιας υπηρεσίας που υπόσχεται μακροζωία και χαμηλό κόστος με αντάλλαγμα ελαφρώς μικρότερη διαθεσιμότητα, παρόλο που η ίδια υπηρεσία μπορεί να είναι ιδανική για ένα σύστημα διαχείρισης αρχείων αρχείων.
Για να ορίσετε ρεαλιστικές προσδοκίες για τους χρήστες σας, χρησιμοποιήστε μία ή και τις δύο από τις ακόλουθες τακτικές:
- Διατηρήστε ένα περιθώριο ασφαλείας. Χρησιμοποιήστε ένα αυστηρότερο εσωτερικό SLO από αυτό που διαφημίζεται στους χρήστες. Αυτό θα σας δώσει την ευκαιρία να αντιδράσετε σε προβλήματα πριν αυτά γίνουν εξωτερικά ορατά. Η προσωρινή μνήμη SLO σάς επιτρέπει επίσης να έχετε ένα περιθώριο ασφαλείας κατά την εγκατάσταση εκδόσεων που επηρεάζουν την απόδοση του συστήματος και διασφαλίζουν ότι το σύστημα είναι εύκολο στη συντήρηση χωρίς να χρειάζεται να απογοητεύετε τους χρήστες με διακοπές λειτουργίας.
- Μην υπερβαίνετε τις προσδοκίες των χρηστών. Οι χρήστες βασίζονται σε αυτά που προσφέρετε και όχι σε αυτά που λέτε. Εάν η πραγματική απόδοση της υπηρεσίας σας είναι πολύ καλύτερη από την αναφερόμενη SLO, οι χρήστες θα βασιστούν στην τρέχουσα απόδοση. Μπορείτε να αποφύγετε την υπερβολική εξάρτηση κλείνοντας σκόπιμα το σύστημα ή περιορίζοντας την απόδοση κάτω από ελαφρά φορτία.
Η κατανόηση του πόσο καλά ένα σύστημα ανταποκρίνεται στις προσδοκίες σας βοηθά να αποφασίσετε εάν θα επενδύσετε στην επιτάχυνση του συστήματος και να το κάνετε πιο προσιτό και ανθεκτικό. Εναλλακτικά, εάν μια υπηρεσία αποδίδει πολύ καλά, κάποιος χρόνος του προσωπικού θα πρέπει να αφιερωθεί σε άλλες προτεραιότητες, όπως η εξόφληση τεχνικού χρέους, η προσθήκη νέων λειτουργιών ή η εισαγωγή νέων προϊόντων.
Συμφωνίες στην πράξη
Η δημιουργία μιας SLA απαιτεί από τις επιχειρηματικές και νομικές ομάδες να καθορίσουν τις συνέπειες και τις κυρώσεις για την παραβίασή της. Ο ρόλος του SRE είναι να τους βοηθήσει να κατανοήσουν τις πιθανές προκλήσεις στην αντιμετώπιση των SLO που περιλαμβάνονται στο SLA. Οι περισσότερες από τις συστάσεις για τη δημιουργία SLO ισχύουν και για SLA. Είναι συνετό να είστε συντηρητικοί σε ό,τι υπόσχεστε στους χρήστες, επειδή όσο περισσότερα έχετε, τόσο πιο δύσκολο είναι να αλλάξετε ή να αφαιρέσετε SLA που φαίνονται παράλογα ή δύσκολο να εκπληρωθούν.
Σας ευχαριστούμε που διαβάσατε τη μετάφραση μέχρι το τέλος. Εγγραφείτε στο κανάλι μου στο τηλεγράφημα σχετικά με την παρακολούθηση и .
Πηγή: www.habr.com