Το διαδικτυακό σεμινάριο έχει κακό ήχο, επομένως το μεταγράψαμε.
Με λένε Medvedev Eduard. Σήμερα θα μιλήσω για το τι είναι το SRE, πώς εμφανίστηκε το SRE, ποια είναι τα κριτήρια εργασίας για τους μηχανικούς SRE, λίγο για τα κριτήρια αξιοπιστίας, λίγο για την παρακολούθησή του. Θα περπατήσουμε στις κορυφές, γιατί δεν μπορείτε να πείτε πολλά σε μια ώρα, αλλά θα δώσω υλικά για πρόσθετη αναθεώρηση και σας περιμένουμε όλους . στη Μόσχα στα τέλη Ιανουαρίου.
Αρχικά, ας μιλήσουμε για το τι είναι το SRE - Site Reliability Engineering. Και πώς εμφανίστηκε ως ξεχωριστή θέση, ως ξεχωριστή σκηνοθεσία. Όλα ξεκίνησαν από το γεγονός ότι στους παραδοσιακούς κύκλους ανάπτυξης, οι Dev και οι Ops είναι δύο εντελώς διαφορετικές ομάδες, συνήθως με δύο εντελώς διαφορετικούς στόχους. Στόχος της ομάδας ανάπτυξης είναι να αναπτύξει νέες δυνατότητες και να καλύψει τις ανάγκες της επιχείρησης. Ο στόχος της ομάδας Ops είναι να βεβαιωθεί ότι όλα λειτουργούν και τίποτα δεν χαλάει. Προφανώς, αυτοί οι στόχοι έρχονται σε άμεση αντίθεση μεταξύ τους: για να λειτουργούν όλα και τίποτα να μην χαλάει, είναι προτιμότερο να διαθέτετε νέες δυνατότητες όσο το δυνατόν λιγότερο. Εξαιτίας αυτού, υπάρχουν πολλές εσωτερικές διενέξεις που προσπαθεί να λύσει η μεθοδολογία που τώρα ονομάζεται DevOps.
Το πρόβλημα είναι ότι δεν έχουμε σαφή ορισμό του DevOps και σαφή υλοποίηση του DevOps. Μίλησα σε ένα συνέδριο στο Yekaterinburg πριν από 2 χρόνια και μέχρι τώρα η ενότητα DevOps ξεκινούσε με την αναφορά "Τι είναι το DevOps". Το 2017, ο Devops είναι σχεδόν 10 ετών, αλλά εξακολουθούμε να μαλώνουμε τι είναι. Και αυτή είναι μια πολύ περίεργη κατάσταση που προσπάθησε να λύσει η Google πριν από μερικά χρόνια.
Το 2016, η Google κυκλοφόρησε ένα βιβλίο με τίτλο Site Reliability Engineering. Και στην πραγματικότητα, με αυτό το βιβλίο ξεκίνησε το κίνημα του SRE. Το SRE είναι μια συγκεκριμένη υλοποίηση του παραδείγματος DevOps σε μια συγκεκριμένη εταιρεία. Οι μηχανικοί SRE δεσμεύονται να διασφαλίζουν ότι τα συστήματα λειτουργούν αξιόπιστα. Προέρχονται κυρίως από προγραμματιστές, μερικές φορές από διαχειριστές με ισχυρό υπόβαθρο ανάπτυξης. Και κάνουν ό,τι έκαναν οι διαχειριστές συστημάτων, αλλά ένα ισχυρό υπόβαθρο στην ανάπτυξη και τη γνώση του συστήματος από την άποψη του κώδικα οδηγεί στο γεγονός ότι αυτοί οι άνθρωποι δεν έχουν την τάση να κάνουν διοικητικές εργασίες ρουτίνας, αλλά έχουν την τάση να αυτοματοποιούνται.
Αποδεικνύεται ότι το παράδειγμα DevOps στις ομάδες SRE υλοποιείται από το γεγονός ότι υπάρχουν μηχανικοί SRE που επιλύουν δομικά προβλήματα. Εδώ είναι, η ίδια σύνδεση μεταξύ Dev και Ops για την οποία ο κόσμος μιλούσε εδώ και 8 χρόνια. Ο ρόλος ενός SRE είναι παρόμοιος με αυτόν ενός αρχιτέκτονα στο ότι οι νεοφερμένοι δεν γίνονται SRE. Οι άνθρωποι στην αρχή της καριέρας τους δεν έχουν ακόμη καμία εμπειρία, δεν έχουν το απαραίτητο εύρος γνώσεων. Επειδή το SRE απαιτεί μια πολύ λεπτή γνώση του τι ακριβώς και πότε ακριβώς μπορεί να πάει στραβά. Ως εκ τούτου, χρειάζεται κάποια εμπειρία εδώ, κατά κανόνα, τόσο εντός της εταιρείας όσο και εκτός.
Ρωτούν αν θα περιγραφεί η διαφορά μεταξύ SRE και devops. Μόλις την περιέγραψαν. Μπορούμε να μιλήσουμε για τη θέση του SRE στον οργανισμό. Σε αντίθεση με αυτήν την κλασική προσέγγιση DevOps, όπου το Ops εξακολουθεί να είναι ξεχωριστό τμήμα, το SRE αποτελεί μέρος της ομάδας ανάπτυξης. Συμμετέχουν στην ανάπτυξη προϊόντων. Υπάρχει ακόμη και μια προσέγγιση όπου το SRE είναι ένας ρόλος που περνά από τον έναν προγραμματιστή στον άλλο. Συμμετέχουν σε κριτικές κώδικα με τον ίδιο τρόπο όπως, για παράδειγμα, οι σχεδιαστές UX, οι ίδιοι οι προγραμματιστές, μερικές φορές οι διαχειριστές προϊόντων. Οι SRE λειτουργούν στο ίδιο επίπεδο. Πρέπει να τα εγκρίνουμε, πρέπει να τα αναθεωρήσουμε, ώστε για κάθε ανάπτυξη η SRE να λέει: «Εντάξει, αυτή η ανάπτυξη, αυτό το προϊόν δεν θα επηρεάσει αρνητικά την αξιοπιστία. Και αν το κάνει, τότε μέσα σε κάποια αποδεκτά όρια. Θα μιλήσουμε και για αυτό.
Κατά συνέπεια, η SRE έχει δικαίωμα αρνησικυρίας για την αλλαγή του κώδικα. Και γενικά, αυτό οδηγεί επίσης σε κάποιο είδος μικρής σύγκρουσης εάν το SRE εφαρμοστεί λανθασμένα. Στο ίδιο βιβλίο για το Site Reliability Engineering, πολλά μέρη, ούτε καν ένα, λένε πώς να αποφύγετε αυτές τις συγκρούσεις.
Ρωτούν πώς σχετίζεται το SRE με την ασφάλεια των πληροφοριών. Η SRE δεν εμπλέκεται άμεσα στην ασφάλεια των πληροφοριών. Βασικά στις μεγάλες εταιρείες αυτό το κάνουν ιδιώτες, δοκιμαστές, αναλυτές. Αλλά το SRE αλληλεπιδρά επίσης μαζί τους με την έννοια ότι ορισμένες λειτουργίες, ορισμένες δεσμεύσεις, ορισμένες αναπτύξεις που επηρεάζουν την ασφάλεια μπορούν επίσης να επηρεάσουν τη διαθεσιμότητα του προϊόντος. Επομένως, η SRE στο σύνολό της έχει αλληλεπίδραση με οποιεσδήποτε ομάδες, συμπεριλαμβανομένων των ομάδων ασφαλείας, συμπεριλαμβανομένων των αναλυτών. Επομένως, τα SRE χρειάζονται κυρίως όταν προσπαθούν να εφαρμόσουν DevOps, αλλά ταυτόχρονα, η επιβάρυνση για τους προγραμματιστές γίνεται πολύ μεγάλο. Δηλαδή, η ίδια η ομάδα ανάπτυξης δεν μπορεί πλέον να αντιμετωπίσει το γεγονός ότι τώρα πρέπει να είναι και υπεύθυνοι για το Ops. Και υπάρχει ένας ξεχωριστός ρόλος. Αυτός ο ρόλος προβλέπεται στον προϋπολογισμό. Μερικές φορές αυτός ο ρόλος καθορίζεται στο μέγεθος της ομάδας, εμφανίζεται ένα ξεχωριστό άτομο, μερικές φορές γίνεται ένας από τους προγραμματιστές. Έτσι εμφανίζεται το πρώτο SRE στην ομάδα.
Η πολυπλοκότητα του συστήματος που επηρεάζεται από το SRE, η πολυπλοκότητα που επηρεάζει την αξιοπιστία της λειτουργίας, είναι απαραίτητη και τυχαία. Απαραίτητη πολυπλοκότητα είναι όταν η πολυπλοκότητα ενός προϊόντος αυξάνεται στο βαθμό που απαιτείται από τα νέα χαρακτηριστικά του προϊόντος. Η τυχαία πολυπλοκότητα είναι όταν η πολυπλοκότητα του συστήματος αυξάνεται, αλλά τα χαρακτηριστικά του προϊόντος και οι επιχειρηματικές απαιτήσεις δεν επηρεάζουν άμεσα αυτό. Αποδεικνύεται ότι είτε ο προγραμματιστής έκανε ένα λάθος κάπου, είτε ο αλγόριθμος δεν είναι βέλτιστος, είτε εισάγονται κάποια πρόσθετα ενδιαφέροντα που αυξάνουν την πολυπλοκότητα του προϊόντος χωρίς ιδιαίτερη ανάγκη. Ένα καλό SRE θα πρέπει πάντα να μειώνει αυτήν την κατάσταση. Δηλαδή, οποιαδήποτε δέσμευση, οποιαδήποτε ανάπτυξη, οποιοδήποτε αίτημα έλξης, όπου η δυσκολία αυξάνεται λόγω τυχαίας προσθήκης, θα πρέπει να αποκλειστεί.
Το ερώτημα είναι γιατί να μην προσλάβετε απλώς έναν μηχανικό, έναν διαχειριστή συστήματος με πολλές γνώσεις στην ομάδα. Ένας προγραμματιστής σε ρόλο μηχανικού, μας λένε, δεν είναι η καλύτερη λύση στελέχωσης. Ένας προγραμματιστής σε ρόλο μηχανικού δεν είναι πάντα η καλύτερη λύση στελέχωσης, αλλά το θέμα εδώ είναι ότι ένας προγραμματιστής που ασχολείται με το Ops έχει λίγο περισσότερη επιθυμία για αυτοματισμό, έχει λίγο περισσότερες γνώσεις και ένα σύνολο δεξιοτήτων για να εφαρμόσει αυτόν τον αυτοματισμό. Και κατά συνέπεια, μειώνουμε όχι μόνο τον χρόνο για ορισμένες συγκεκριμένες λειτουργίες, όχι μόνο τη ρουτίνα, αλλά και σημαντικές επιχειρηματικές παραμέτρους όπως το MTTR (Mean Time To Recovery, Recovery time). Έτσι, και θα μιλήσουμε επίσης για αυτό λίγο αργότερα, εξοικονομούμε χρήματα για τον οργανισμό.
Ας μιλήσουμε τώρα για τα κριτήρια λειτουργίας του SRE. Και πρώτα από όλα για την αξιοπιστία. Σε μικρές εταιρείες, startups, συμβαίνει συχνά οι άνθρωποι να υποθέτουν ότι αν η υπηρεσία είναι γραμμένη καλά, αν το προϊόν είναι γραμμένο καλά και σωστά, θα λειτουργήσει, δεν θα χαλάσει. Αυτό είναι όλο, γράφουμε καλό κώδικα, οπότε δεν υπάρχει τίποτα να σπάσει. Ο κώδικας είναι πολύ απλός, δεν υπάρχει τίποτα να σπάσει. Πρόκειται για τους ίδιους ανθρώπους που λένε ότι δεν χρειαζόμαστε δοκιμές, γιατί, κοίτα, αυτές είναι οι τρεις μέθοδοι VPI, γιατί να σπάσει εδώ.
Όλα αυτά είναι λάθος, φυσικά. Και αυτοί οι άνθρωποι πολύ συχνά δαγκώνονται από τέτοιους κώδικα στην πράξη, γιατί τα πράγματα σπάνε. Τα πράγματα σπάνε μερικές φορές με τον πιο απρόβλεπτο τρόπο. Μερικές φορές οι άνθρωποι λένε όχι, δεν θα συμβεί ποτέ. Και συμβαίνει συνέχεια. Συμβαίνει αρκετά συχνά. Και γι' αυτό κανείς δεν προσπαθεί ποτέ για 100% διαθεσιμότητα, γιατί 100% διαθεσιμότητα δεν συμβαίνει ποτέ. Αυτό είναι ο κανόνας. Και επομένως, όταν μιλάμε για διαθεσιμότητα μιας υπηρεσίας, μιλάμε πάντα για εννιά. 2 εννιάρια, 3 εννιάρια, 4 εννιάρια, 5 εννιάρια. Εάν το μεταφράσουμε σε χρόνο διακοπής λειτουργίας, τότε, για παράδειγμα, 5 εννέα, τότε αυτό είναι λίγο περισσότερο από 5 λεπτά διακοπής λειτουργίας ετησίως, 2 εννιάρια είναι 3,5 ημέρες διακοπής λειτουργίας.
Είναι όμως προφανές ότι κάποια στιγμή υπάρχει μείωση των POI, απόδοση επένδυσης. Η μετάβαση από δύο εννιάρια σε τρία εννιάρια σημαίνει λιγότερο χρόνο διακοπής λειτουργίας για περισσότερες από 3 ημέρες. Η μετάβαση από τέσσερα εννιά σε πέντε μειώνει τον χρόνο διακοπής κατά 47 λεπτά ετησίως. Και αποδεικνύεται ότι για τις επιχειρήσεις μπορεί να μην είναι κρίσιμο. Και γενικά η απαιτούμενη αξιοπιστία δεν είναι τεχνικό θέμα, πρώτα απ' όλα είναι επαγγελματικό, είναι θέμα προϊόντος. Ποιο επίπεδο χρόνου διακοπής είναι αποδεκτό για τους χρήστες του προϊόντος, τι περιμένουν, πόσα πληρώνουν, για παράδειγμα, πόσα χρήματα χάνουν, πόσα χρήματα χάνει το σύστημα.
Ένα σημαντικό ερώτημα εδώ είναι ποια είναι η αξιοπιστία των υπόλοιπων εξαρτημάτων. Επειδή η διαφορά μεταξύ 4 και 5 εννέα δεν θα είναι ορατή σε ένα smartphone με 2 εννιάρια αξιοπιστίας. Σε γενικές γραμμές, εάν κάτι χαλάσει σε ένα smartphone στην υπηρεσία σας 10 φορές το χρόνο, πιθανότατα 8 φορές η βλάβη συνέβη στην πλευρά του λειτουργικού συστήματος. Ο χρήστης είναι συνηθισμένος σε αυτό και δεν θα δώσει σημασία άλλη μία φορά το χρόνο. Είναι απαραίτητο να συσχετιστεί η τιμή της αύξησης της αξιοπιστίας και της αύξησης των κερδών.
Απλώς στο βιβλίο για το SRE υπάρχει ένα καλό παράδειγμα αύξησης σε 4 εννιάρια από 3 εννιάρια. Αποδεικνύεται ότι η αύξηση της διαθεσιμότητας είναι λίγο μικρότερη από 0,1%. Και αν τα έσοδα της υπηρεσίας είναι 1 εκατομμύριο δολάρια το χρόνο, τότε η αύξηση των εσόδων είναι 900 δολάρια. Εάν μας κοστίζει λιγότερο από 900 $ ετησίως για να αυξήσουμε την οικονομική προσιτότητα κατά ένα εννέα, η αύξηση έχει οικονομική λογική. Αν κοστίζει περισσότερα από 900 δολάρια το χρόνο, δεν έχει πλέον νόημα, γιατί η αύξηση των εσόδων απλά δεν αντισταθμίζει το κόστος εργασίας, το κόστος των πόρων. Και 3 εννιάρια θα μας αρκούν.
Αυτό είναι φυσικά ένα απλοποιημένο παράδειγμα όπου όλα τα αιτήματα είναι ίσα. Και η μετάβαση από τα 3 εννιά στα 4 εννιάρια είναι αρκετά εύκολη, αλλά ταυτόχρονα, για παράδειγμα, πηγαίνοντας από τα 2 εννιά στα 3, αυτό είναι ήδη μια εξοικονόμηση 9 χιλιάδων δολαρίων, μπορεί να έχει οικονομικό νόημα. Φυσικά, στην πραγματικότητα, η αποτυχία του αιτήματος εγγραφής είναι χειρότερη από την αποτυχία εμφάνισης της σελίδας, τα αιτήματα έχουν διαφορετικό βάρος. Μπορεί να έχουν τελείως διαφορετικό κριτήριο από επιχειρηματική άποψη, αλλά ούτως ή άλλως, κατά κανόνα, αν δεν μιλάμε για κάποιες συγκεκριμένες υπηρεσίες, αυτή είναι μια αρκετά αξιόπιστη προσέγγιση.
Λάβαμε μια ερώτηση εάν η SRE είναι ένας από τους συντονιστές κατά την επιλογή μιας αρχιτεκτονικής λύσης για την υπηρεσία. Ας πούμε σε επίπεδο ενσωμάτωσης στις υπάρχουσες υποδομές, για να μην υπάρξει απώλεια στη σταθερότητά της. Ναι, τα SRE, με τον ίδιο τρόπο που τα αιτήματα έλξης, δεσμεύσεις, εκδόσεις επηρεάζουν την αρχιτεκτονική, την εισαγωγή νέων υπηρεσιών, τις μικροϋπηρεσίες, την εφαρμογή νέων λύσεων. Γιατί έλεγα πριν ότι χρειάζεται εμπειρία, χρειάζονται προσόντα. Στην πραγματικότητα, το SRE είναι μια από τις μπλοκαρισμένες φωνές σε οποιαδήποτε αρχιτεκτονική λύση και λύση λογισμικού. Συνεπώς, ένας SRE ως μηχανικός πρέπει πρώτα απ' όλα όχι μόνο να κατανοήσει, αλλά και να κατανοήσει πώς ορισμένες συγκεκριμένες αποφάσεις θα επηρεάσουν την αξιοπιστία, τη σταθερότητα και να κατανοήσει πώς αυτό σχετίζεται με τις επιχειρηματικές ανάγκες και από ποια άποψη μπορεί να είναι αποδεκτό και που όχι.
Επομένως, τώρα μπορούμε απλώς να μιλήσουμε για κριτήρια αξιοπιστίας, τα οποία παραδοσιακά ορίζονται στο SRE ως SLA (Service Level Agreement). Πιθανότατα γνωστός όρος. SLI (Δείκτης επιπέδου υπηρεσίας). SLO (Στόχος επιπέδου υπηρεσίας). Το Service Level Agreement είναι ίσως ένας συμβολικός όρος, ειδικά αν έχετε συνεργαστεί με δίκτυα, με παρόχους, με φιλοξενία. Αυτή είναι μια γενική συμφωνία που περιγράφει την απόδοση ολόκληρης της υπηρεσίας σας, ποινές, ορισμένες ποινές για σφάλματα, μετρήσεις, κριτήρια. Και το SLI είναι η ίδια η μέτρηση διαθεσιμότητας. Δηλαδή, τι μπορεί να είναι το SLI: χρόνος απόκρισης από την υπηρεσία, ο αριθμός των σφαλμάτων ως ποσοστό. Θα μπορούσε να είναι εύρος ζώνης εάν πρόκειται για κάποιο είδος φιλοξενίας αρχείων. Όταν πρόκειται για αλγόριθμους αναγνώρισης, ο δείκτης μπορεί να είναι, για παράδειγμα, ακόμη και η ορθότητα της απάντησης. Το SLO (Service Level Objective) είναι, αντίστοιχα, ένας συνδυασμός του δείκτη SLI, της τιμής και της περιόδου του.
Ας πούμε ότι το SLA θα μπορούσε να είναι έτσι. Η υπηρεσία είναι διαθέσιμη στο 99,95% του χρόνου καθ' όλη τη διάρκεια του έτους. Ή 99 εισιτήρια κρίσιμης υποστήριξης θα κλείνουν εντός 3 ωρών ανά τρίμηνο. Ή το 85% των αιτημάτων θα απαντηθεί εντός 1,5 δευτερολέπτου κάθε μήνα. Δηλαδή, σταδιακά καταλαβαίνουμε ότι τα λάθη και οι αστοχίες είναι αρκετά φυσιολογικά. Αυτή είναι μια αποδεκτή κατάσταση, την σχεδιάζουμε, την υπολογίζουμε ακόμη και σε κάποιο βαθμό. Δηλαδή, η SRE κατασκευάζει συστήματα που μπορούν να κάνουν λάθη, τα οποία πρέπει να ανταποκρίνονται κανονικά σε σφάλματα, τα οποία πρέπει να τα λαμβάνουν υπόψη. Και όποτε είναι δυνατόν, θα πρέπει να χειρίζονται τα σφάλματα με τέτοιο τρόπο ώστε ο χρήστης είτε να μην τα παρατηρεί, είτε να παρατηρεί, αλλά υπάρχει κάποιο είδος λύσης, χάρη στην οποία δεν θα πέσει τα πάντα εντελώς.
Για παράδειγμα, εάν ανεβάσετε ένα βίντεο στο YouTube και το YouTube δεν μπορεί να το μετατρέψει αμέσως, εάν το βίντεο είναι πολύ μεγάλο, εάν η μορφή δεν είναι η βέλτιστη, τότε το αίτημα φυσικά δεν θα αποτύχει με ένα χρονικό όριο, το YouTube δεν θα δώσει σφάλμα 502 , το YouTube θα πει: «Έχουμε δημιουργήσει τα πάντα, το βίντεό σας υποβάλλεται σε επεξεργασία. Θα είναι έτοιμο σε περίπου 10 λεπτά». Αυτή είναι η αρχή της χαριτωμένης υποβάθμισης, η οποία είναι γνωστή, για παράδειγμα, από την ανάπτυξη front-end, εάν το έχετε κάνει ποτέ αυτό.
Οι επόμενοι όροι για τους οποίους θα μιλήσουμε, οι οποίοι είναι πολύ σημαντικοί για την εργασία με αξιοπιστία, με λάθη, με προσδοκίες, είναι MTBF και MTTR. Το MTBF είναι ο μέσος χρόνος μεταξύ των αστοχιών. MTTR Mean Time To Recovery, μέσος χρόνος για την αποκατάσταση. Δηλαδή, πόσος χρόνος έχει περάσει από τη στιγμή που ανακαλύφθηκε το σφάλμα, από τη στιγμή που εμφανίστηκε το σφάλμα μέχρι τη στιγμή που η υπηρεσία επανήλθε στην πλήρη κανονική λειτουργία. Το MTBF διορθώνεται κυρίως με εργασίες για την ποιότητα του κώδικα. Δηλαδή το γεγονός ότι οι SRE μπορούν να πουν «όχι». Και χρειάζεσαι κατανόηση όλης της ομάδας ότι όταν ο SRE λέει "όχι", το λέει όχι επειδή είναι επιβλαβής, όχι επειδή είναι κακός, αλλά επειδή διαφορετικά θα υποφέρουν όλοι.
Και πάλι, υπάρχουν πολλά άρθρα, πολλές μέθοδοι, πολλοί τρόποι ακόμη και στο ίδιο το βιβλίο στο οποίο αναφέρομαι τόσο συχνά, πώς να βεβαιωθώ ότι οι άλλοι προγραμματιστές δεν αρχίσουν να μισούν το SRE. Το MTTR, από την άλλη πλευρά, αφορά την εργασία στα SLO σας (Στόχος επιπέδου υπηρεσίας). Και είναι κυρίως αυτοματισμός. Επειδή, για παράδειγμα, το SLO μας είναι χρόνος λειτουργίας 4 εννέα ανά τρίμηνο. Αυτό σημαίνει ότι σε 3 μήνες μπορούμε να επιτρέψουμε 13 λεπτά διακοπής λειτουργίας. Και αποδεικνύεται ότι το MTTR δεν μπορεί να είναι περισσότερο από 13 λεπτά. Εάν ανταποκριθούμε σε τουλάχιστον 13 χρόνο διακοπής λειτουργίας σε 1 λεπτά, αυτό σημαίνει ότι έχουμε ήδη εξαντλήσει ολόκληρο τον προϋπολογισμό για το τρίμηνο. Σπάμε το SLO. 13 λεπτά για να αντιδράσετε και να διορθώσετε μια σύγκρουση είναι πολλά για μια μηχανή, αλλά πολύ λίγα για έναν άνθρωπο. Γιατί μέχρι να λάβει κάποιος ειδοποίηση, μέχρι να αντιδράσει, μέχρι να καταλάβει το λάθος, είναι ήδη αρκετά λεπτά. Μέχρι να καταλάβει κάποιος πώς να το διορθώσει, τι ακριβώς να διορθώσει, τι να κάνει, τότε αυτό είναι μερικά λεπτά ακόμα. Και στην πραγματικότητα, ακόμα κι αν χρειάζεται απλώς να επανεκκινήσετε τον διακομιστή, όπως αποδεικνύεται, ή να δημιουργήσετε έναν νέο κόμβο, τότε το μη αυτόματο MTTR είναι ήδη περίπου 7-8 λεπτά. Κατά την αυτοματοποίηση της διαδικασίας, το MTTR πολύ συχνά φτάνει σε ένα δευτερόλεπτο, μερικές φορές σε χιλιοστά του δευτερολέπτου. Η Google συνήθως μιλάει για χιλιοστά του δευτερολέπτου, αλλά στην πραγματικότητα, φυσικά, δεν είναι όλα τόσο καλά.
Στην ιδανική περίπτωση, το SRE θα πρέπει να αυτοματοποιεί σχεδόν πλήρως την εργασία του, επειδή αυτό επηρεάζει άμεσα το MTTR, τις μετρήσεις του, το SLO ολόκληρης της υπηρεσίας και, κατά συνέπεια, το επιχειρηματικό κέρδος. Σε περίπτωση υπέρβασης του χρόνου, ερωτούμαστε αν φταίει το SRE. Ευτυχώς δεν φταίει κανείς. Και αυτή είναι μια ξεχωριστή κουλτούρα που ονομάζεται balmeless postmortem, για την οποία δεν θα μιλήσουμε σήμερα, αλλά θα την αναλύσουμε στο Slurm. Αυτό είναι ένα πολύ ενδιαφέρον θέμα για το οποίο μπορεί να συζητηθεί πολύ. Σε γενικές γραμμές, αν ξεπεραστεί ο χρόνος ανά τρίμηνο, τότε φταίει λίγος ο καθένας, που σημαίνει ότι το να κατηγορούμε όλους δεν είναι παραγωγικό, ας μην κατηγορήσουμε κανέναν, αλλά διορθώνουμε την κατάσταση και δουλεύουμε με αυτά που έχουμε. Από την εμπειρία μου, αυτή η προσέγγιση είναι λίγο ξένη για τις περισσότερες ομάδες, ειδικά στη Ρωσία, αλλά είναι λογικό και λειτουργεί πολύ καλά. Ως εκ τούτου, θα προτείνω στο τέλος του άρθρου και της βιβλιογραφίας που μπορείτε να διαβάσετε σχετικά με αυτό το θέμα. Ή ελάτε στο Slurm SRE.
ΑΣΕ με να εξηγήσω. Εάν ξεπεραστεί ο χρόνος SLO ανά τρίμηνο, εάν ο χρόνος διακοπής δεν ήταν 13 λεπτά, αλλά 15, ποιος μπορεί να φταίει για αυτό; Φυσικά, μπορεί να φταίει ο SRE, γιατί προφανώς έκανε κάποιου είδους κακή δέσμευση ή ανάπτυξη. Για αυτό μπορεί να φταίει ο διαχειριστής του κέντρου δεδομένων, γιατί μπορεί να έχει κάνει κάποιου είδους απρογραμμάτιστη συντήρηση. Αν για αυτό φταίει ο διαχειριστής του data center, τότε φταίει ο άνθρωπος από το Ops που δεν υπολόγισε τη συντήρηση όταν συντόνιζε το SLO. Για αυτό φταίει ο διευθυντής, ο τεχνικός διευθυντής ή κάποιος που υπέγραψε τη σύμβαση του κέντρου δεδομένων και δεν έδωσε σημασία στο γεγονός ότι το SLA του κέντρου δεδομένων δεν έχει σχεδιαστεί για τον απαιτούμενο χρόνο διακοπής λειτουργίας. Κατά συνέπεια, όλοι σιγά σιγά φταίνε σε αυτή την κατάσταση. Και σημαίνει ότι δεν έχει νόημα να ρίχνουμε την ευθύνη σε κανέναν σε αυτήν την κατάσταση. Αλλά φυσικά πρέπει να διορθωθεί. Γι' αυτό υπάρχουν νεκροτομές. Και αν διαβάζετε, για παράδειγμα, μεταθανάτιες εκθέσεις του GitHub, και αυτό είναι πάντα μια πολύ ενδιαφέρουσα, μικρή και απροσδόκητη ιστορία σε κάθε περίπτωση, μπορείτε να αντικαταστήσετε ότι κανείς δεν λέει ποτέ ότι αυτό το συγκεκριμένο άτομο έφταιγε. Το φταίξιμο επιρρίπτεται πάντα σε συγκεκριμένες ατελείς διαδικασίες.
Ας προχωρήσουμε στην επόμενη ερώτηση. Αυτοματοποίηση. Όταν μιλάω για αυτοματοποίηση σε άλλα πλαίσια, συχνά αναφέρομαι σε έναν πίνακα που σας λέει πόσο χρόνο μπορείτε να εργαστείτε για την αυτοματοποίηση μιας εργασίας χωρίς να αφιερώσετε περισσότερο χρόνο για να την αυτοματοποιήσετε από ό,τι εξοικονομείτε πραγματικά. Υπάρχει ένα εμπόδιο. Το αλίευμα είναι ότι όταν οι SRE αυτοματοποιούν μια εργασία, όχι μόνο εξοικονομούν χρόνο, αλλά εξοικονομούν χρήματα, επειδή ο αυτοματισμός επηρεάζει άμεσα το MTTR. Εξοικονομούν, ας πούμε, το ηθικό των εργαζομένων και των προγραμματιστών, που είναι επίσης ένας εξαντλητικός πόρος. Μειώνουν τη ρουτίνα. Και όλα αυτά έχουν θετική επίδραση στην εργασία και, κατά συνέπεια, στις επιχειρήσεις, ακόμα κι αν φαίνεται ότι η αυτοματοποίηση δεν έχει νόημα από άποψη χρόνου κόστους.
Στην πραγματικότητα, έχει σχεδόν πάντα, και υπάρχουν πολύ λίγες περιπτώσεις όπου κάτι δεν πρέπει να αυτοματοποιηθεί στο ρόλο του SRE. Στη συνέχεια θα μιλήσουμε για αυτό που ονομάζεται προϋπολογισμός σφάλματος, προϋπολογισμός για σφάλματα. Στην πραγματικότητα, αποδεικνύεται ότι αν όλα είναι πολύ καλύτερα για εσάς από το SLO που έχετε ορίσει για τον εαυτό σας, αυτό δεν είναι επίσης πολύ καλό. Αυτό είναι μάλλον κακό, γιατί το SLO λειτουργεί όχι μόνο ως κατώτερο, αλλά και ως κατά προσέγγιση άνω όριο. Όταν ορίζετε στον εαυτό σας SLO 99% διαθεσιμότητας, και στην πραγματικότητα έχετε 99,99%, αποδεικνύεται ότι έχετε χώρο για πειράματα που δεν θα βλάψουν καθόλου την επιχείρηση, επειδή εσείς οι ίδιοι το έχετε καθορίσει όλα μαζί και είστε αυτός ο χώρος δεν χρησιμοποιείται. Έχετε προϋπολογισμό για λάθη, που στην περίπτωσή σας δεν εξαντλείται.
Τι κάνουμε με αυτό. Το χρησιμοποιούμε κυριολεκτικά για τα πάντα. Για δοκιμές σε συνθήκες παραγωγής, για διάθεση νέων χαρακτηριστικών που μπορεί να επηρεάσουν την απόδοση, για εκδόσεις, για συντήρηση, για προγραμματισμένους χρόνους διακοπής λειτουργίας. Ισχύει και ο αντίστροφος κανόνας: αν εξαντληθεί ο προϋπολογισμός, δεν μπορούμε να κυκλοφορήσουμε κάτι νέο, γιατί διαφορετικά θα υπερβούμε το SLO. Ο προϋπολογισμός έχει ήδη εξαντληθεί, έχουμε κυκλοφορήσει κάτι εάν επηρεάζει αρνητικά την απόδοση, δηλαδή εάν αυτό δεν είναι κάποιο είδος επιδιόρθωσης που από μόνο του αυξάνει άμεσα το SLO, τότε υπερβαίνουμε τον προϋπολογισμό, και αυτή είναι μια κακή κατάσταση , πρέπει να αναλυθεί, να γίνει μεταθανάτια και ενδεχομένως κάποιες επιδιορθώσεις της διαδικασίας.
Δηλαδή, αποδεικνύεται ότι εάν η ίδια η υπηρεσία δεν λειτουργεί καλά, και δαπανηθεί το SLO και ο προϋπολογισμός δαπανηθεί όχι σε πειράματα, όχι σε ορισμένες εκδόσεις, αλλά από μόνος του, τότε αντί για κάποιες ενδιαφέρουσες επιδιορθώσεις, αντί για ενδιαφέρουσες λειτουργίες, αντί για ενδιαφέρουσες εκδόσεις. Αντί για οποιαδήποτε δημιουργική εργασία, θα πρέπει να αντιμετωπίσετε ανόητες διορθώσεις για να επαναφέρετε τον προϋπολογισμό σε τάξη ή να επεξεργαστείτε το SLO, και αυτή είναι επίσης μια διαδικασία που δεν πρέπει να συμβαίνει πολύ συχνά.
Επομένως, αποδεικνύεται ότι σε μια κατάσταση όπου έχουμε περισσότερο προϋπολογισμό για σφάλματα, όλοι ενδιαφέρονται: τόσο η SRE όσο και οι προγραμματιστές. Για τους προγραμματιστές, ένας μεγάλος προϋπολογισμός για σφάλματα σημαίνει ότι μπορείτε να αντιμετωπίσετε εκδόσεις, δοκιμές, πειράματα. Για τις SRE, ένας προϋπολογισμός για σφάλματα και η εισαγωγή αυτού του προϋπολογισμού σημαίνει ότι κάνουν άμεσα τη δουλειά τους καλά. Και αυτό επηρεάζει τα κίνητρα κάποιου είδους κοινής εργασίας. Αν ακούτε τα SRE σας ως προγραμματιστές, θα έχετε περισσότερο χώρο για καλή δουλειά και πολύ λιγότερο ρουτίνα.
Αποδεικνύεται ότι τα πειράματα στην παραγωγή είναι αρκετά σημαντικό και σχεδόν αναπόσπαστο μέρος του SRE σε μεγάλες ομάδες. Και συνήθως ονομάζεται χάος μηχανική, που προέρχεται από την ομάδα του Netflix που κυκλοφόρησε ένα βοηθητικό πρόγραμμα που ονομάζεται Chaos Monkey.
Το Chaos Monkey συνδέεται με τον αγωγό CI/CD και τυχαία διακόπτει τη λειτουργία του διακομιστή κατά την παραγωγή. Και πάλι, στη δομή SRE, μιλάμε για το γεγονός ότι ένας κατεστραμμένος διακομιστής δεν είναι κακός από μόνος του, είναι αναμενόμενο. Και αν είναι εντός του προϋπολογισμού, είναι αποδεκτό και δεν βλάπτει την επιχείρηση. Φυσικά, το Netflix έχει αρκετούς περιττούς διακομιστές, αρκετή αναπαραγωγή, ώστε όλα αυτά να μπορούν να διορθωθούν και έτσι ώστε ο χρήστης στο σύνολό του να μην το προσέχει και ακόμη περισσότερο κανείς να μην αφήνει έναν διακομιστή για οποιοδήποτε προϋπολογισμό.
Το Netflix είχε μια ολόκληρη σειρά τέτοιων βοηθητικών προγραμμάτων για λίγο, ένα από τα οποία, το Chaos Gorilla, κλείνει εντελώς μια από τις Ζώνες Διαθεσιμότητας του Amazon. Και τέτοια πράγματα βοηθούν να αποκαλυφθούν, πρώτον, κρυφές εξαρτήσεις, όταν δεν είναι απολύτως σαφές τι επηρεάζει τι, τι εξαρτάται από τι. Και αυτό, εάν εργάζεστε με μια microservice και η τεκμηρίωση δεν είναι τέλεια, μπορεί να σας είναι οικείο. Και πάλι, αυτό βοηθά πολύ στο να συλλάβετε σφάλματα στον κώδικα που δεν μπορείτε να πιάσετε κατά τη σταδιοποίηση, επειδή οποιαδήποτε σταδιοποίηση δεν είναι ακριβώς μια ακριβής προσομοίωση, λόγω του γεγονότος ότι η κλίμακα φόρτωσης είναι διαφορετική, το σχέδιο φόρτωσης είναι διαφορετικό, ο εξοπλισμός είναι επίσης, πιθανότατα, άλλα. Τα φορτία αιχμής μπορεί επίσης να είναι απροσδόκητα και απρόβλεπτα. Και τέτοιες δοκιμές, οι οποίες και πάλι δεν ξεπερνούν τον προϋπολογισμό, βοηθούν πολύ καλά στο να συλληφθούν λάθη στην υποδομή που δεν θα πιάσουν ποτέ το σταδιοποίηση, οι αυτόματες δοκιμές, οι αγωγοί CI / CD. Και εφόσον περιλαμβάνονται όλα στον προϋπολογισμό σας, δεν έχει σημασία ότι η υπηρεσία σας κατέβηκε εκεί, αν και θα φαινόταν πολύ τρομακτικό, ο διακομιστής έπεσε, τι εφιάλτης. Όχι, αυτό είναι φυσιολογικό, αυτό είναι καλό, που βοηθά να πιάσουμε σφάλματα. Εάν έχετε έναν προϋπολογισμό, τότε μπορείτε να τον ξοδέψετε.
Ε: Ποια βιβλιογραφία μπορώ να προτείνω; Λίστα στο τέλος. Υπάρχει πολλή βιβλιογραφία, θα συμβουλεύσω μερικές αναφορές. Πώς λειτουργεί και λειτουργεί η SRE σε εταιρείες χωρίς δικό τους προϊόν λογισμικού ή με ελάχιστη ανάπτυξη. Για παράδειγμα, σε μια επιχείρηση όπου η κύρια δραστηριότητα δεν είναι λογισμικό. Σε μια επιχείρηση, όπου η κύρια δραστηριότητα δεν είναι λογισμικό, η SRE λειτουργεί ακριβώς όπως παντού αλλού, επειδή σε μια επιχείρηση πρέπει επίσης να χρησιμοποιήσετε, ακόμα και αν δεν έχουν αναπτυχθεί, προϊόντα λογισμικού, πρέπει να κυκλοφορήσετε ενημερώσεις, πρέπει να αλλάξετε την υποδομή, πρέπει να αναπτυχθείς, πρέπει να κλιμακώσεις. Και οι SRE βοηθούν στον εντοπισμό και την πρόβλεψη πιθανών προβλημάτων σε αυτές τις διαδικασίες και τον έλεγχό τους αφού ξεκινήσει κάποια ανάπτυξη και αλλάξουν οι επιχειρηματικές ανάγκες. Επειδή δεν είναι απολύτως απαραίτητο να συμμετέχετε στην ανάπτυξη λογισμικού για να έχετε SRE εάν έχετε τουλάχιστον λίγους διακομιστές και αναμένεται να έχετε τουλάχιστον κάποια ανάπτυξη.
Το ίδιο ισχύει και για τα μικρά έργα, τους μικρούς οργανισμούς, γιατί οι μεγάλες εταιρείες έχουν τον προϋπολογισμό και τον χώρο να πειραματιστούν. Αλλά ταυτόχρονα, όλοι αυτοί οι καρποί των πειραμάτων μπορούν να χρησιμοποιηθούν οπουδήποτε, δηλαδή το SRE, φυσικά, εμφανίστηκε στο Google, στο Netflix, στο Dropbox. Αλλά την ίδια στιγμή, οι μικρές εταιρείες και οι νεοφυείς επιχειρήσεις μπορούν ήδη να διαβάζουν συμπυκνωμένο υλικό, να διαβάζουν βιβλία, να παρακολουθούν αναφορές. Αρχίζουν να το ακούν πιο συχνά, κοιτάζουν συγκεκριμένα παραδείγματα, νομίζω ότι δεν πειράζει, μπορεί πραγματικά να είναι χρήσιμο, το χρειαζόμαστε και αυτό, είναι υπέροχο.
Δηλαδή, όλη η κύρια εργασία για την τυποποίηση αυτών των διαδικασιών έχει ήδη γίνει για εσάς. Απομένει σε εσάς να καθορίσετε τον ρόλο της SRE ειδικά στην εταιρεία σας και να αρχίσετε να εφαρμόζετε ουσιαστικά όλες αυτές τις πρακτικές, οι οποίες, και πάλι, έχουν ήδη περιγραφεί. Δηλαδή, από χρήσιμες αρχές για μικρές εταιρείες, αυτός είναι πάντα ο ορισμός των SLA, SLI, SLO. Εάν δεν ασχολείστε με λογισμικό, τότε αυτά θα είναι εσωτερικά SLA και εσωτερικά SLO, ένας εσωτερικός προϋπολογισμός για σφάλματα. Αυτό σχεδόν πάντα οδηγεί σε μερικές ενδιαφέρουσες συζητήσεις εντός της ομάδας και εντός της επιχείρησης, επειδή μπορεί να αποδειχθεί ότι ξοδεύετε σε υποδομές, σε κάποιο είδος οργάνωσης ιδανικών διαδικασιών, ο ιδανικός αγωγός είναι πολύ περισσότερο από απαραίτητος. Και αυτά τα 4 εννιά που έχετε στο τμήμα πληροφορικής, δεν τα χρειάζεστε πραγματικά τώρα. Αλλά ταυτόχρονα, θα μπορούσατε να ξοδέψετε χρόνο, να ξοδέψετε τον προϋπολογισμό για λάθη σε κάτι άλλο.
Κατά συνέπεια, η παρακολούθηση και η οργάνωση της παρακολούθησης είναι χρήσιμη για μια εταιρεία οποιουδήποτε μεγέθους. Και γενικά αυτός ο τρόπος σκέψης, όπου τα λάθη είναι κάτι αποδεκτό, όπου υπάρχει προϋπολογισμός, όπου υπάρχουν Στόχοι, είναι και πάλι χρήσιμος για μια εταιρεία οποιουδήποτε μεγέθους, ξεκινώντας από startups για 3 άτομα.
Η τελευταία από τις τεχνικές αποχρώσεις που πρέπει να μιλήσουμε είναι η παρακολούθηση. Διότι αν μιλάμε για SLA, SLI, SLO, δεν μπορούμε να καταλάβουμε χωρίς να παρακολουθούμε αν ταιριάζουμε στον προϋπολογισμό, αν συμμορφωνόμαστε με τους Στόχους μας και πώς επηρεάζουμε την τελική SLA. Έχω δει τόσες φορές ότι η παρακολούθηση συμβαίνει ως εξής: υπάρχει κάποια τιμή, για παράδειγμα, ο χρόνος ενός αιτήματος στον διακομιστή, ο μέσος χρόνος ή ο αριθμός των αιτημάτων στη βάση δεδομένων. Έχει ένα πρότυπο που καθορίζεται από έναν μηχανικό. Εάν η μέτρηση αποκλίνει από τον κανόνα, τότε έρχεται ένα e-mail. Όλα αυτά είναι απολύτως άχρηστα, κατά κανόνα, επειδή οδηγούν σε τέτοιο πλεόνασμα ειδοποιήσεων, πληθώρα μηνυμάτων από την παρακολούθηση, όταν ένα άτομο, πρώτον, πρέπει να τα ερμηνεύει κάθε φορά, δηλαδή να προσδιορίζει αν η τιμή της μετρικής σημαίνει την ανάγκη για κάποια δράση. Και δεύτερον, απλώς σταματά να παρατηρεί όλες αυτές τις ειδοποιήσεις, όταν ουσιαστικά δεν απαιτείται καμία ενέργεια από αυτόν. Αυτός είναι ένας καλός κανόνας παρακολούθησης και ο πρώτος κανόνας κατά την εφαρμογή του SRE είναι ότι η ειδοποίηση πρέπει να γίνεται μόνο όταν απαιτείται δράση.
Στην τυπική περίπτωση, υπάρχουν 3 επίπεδα συμβάντων. Υπάρχουν ειδοποιήσεις, υπάρχουν εισιτήρια, υπάρχουν αρχεία καταγραφής. Οι ειδοποιήσεις είναι οτιδήποτε απαιτεί από εσάς να λάβετε άμεση δράση. Δηλαδή, όλα είναι χαλασμένα, πρέπει να τα φτιάξετε αμέσως. Τα εισιτήρια είναι αυτά που απαιτούν καθυστερημένη ενέργεια. Ναι, πρέπει να κάνετε κάτι, πρέπει να κάνετε κάτι χειροκίνητα, ο αυτοματισμός απέτυχε, αλλά δεν χρειάζεται να το κάνετε για τα επόμενα λεπτά. Τα αρχεία καταγραφής είναι οτιδήποτε δεν απαιτεί δράση και γενικά, αν τα πράγματα πάνε καλά, κανείς δεν θα τα διαβάσει ποτέ. Θα χρειαστεί να διαβάσετε τα αρχεία καταγραφής μόνο όταν, εκ των υστέρων, αποδείχθηκε ότι κάτι έσπασε για κάποιο χρονικό διάστημα, δεν το γνωρίζαμε. Ή πρέπει να κάνετε κάποια έρευνα. Αλλά γενικά, όλα όσα δεν απαιτούν καμία ενέργεια πηγαίνουν στα αρχεία καταγραφής.
Ως παρενέργεια όλων αυτών, εάν έχουμε ορίσει ποια γεγονότα απαιτούν ενέργειες και έχουμε περιγράψει καλά ποιες πρέπει να είναι αυτές οι ενέργειες, αυτό σημαίνει ότι η δράση μπορεί να αυτοματοποιηθεί. Δηλαδή τι γίνεται. Πηγαίνουμε από συναγερμό. Πάμε στη δράση. Πηγαίνουμε στην περιγραφή αυτής της ενέργειας. Και μετά περνάμε στον αυτοματισμό. Δηλαδή, κάθε αυτοματισμός ξεκινά με μια αντίδραση σε ένα γεγονός.
Από την παρακολούθηση, περνάμε σε έναν όρο που ονομάζεται Παρατηρησιμότητα. Υπήρξε επίσης λίγη διαφημιστική εκστρατεία γύρω από αυτή τη λέξη τα τελευταία χρόνια. Και λίγοι καταλαβαίνουν τι σημαίνει εκτός πλαισίου. Αλλά το κύριο σημείο είναι ότι η παρατηρησιμότητα είναι μια μέτρηση για τη διαφάνεια του συστήματος. Εάν κάτι πήγε στραβά, πόσο γρήγορα μπορείτε να προσδιορίσετε τι ακριβώς πήγε στραβά και ποια ήταν η κατάσταση του συστήματος εκείνη τη στιγμή. Όσον αφορά τον κώδικα: ποια λειτουργία απέτυχε, ποια υπηρεσία απέτυχε. Ποια ήταν η κατάσταση, για παράδειγμα, εσωτερικών μεταβλητών, διαμόρφωσης. Όσον αφορά την υποδομή, αυτή είναι σε ποια ζώνη διαθεσιμότητας παρουσιάστηκε η αποτυχία και εάν έχετε εγκαταστήσει οποιοδήποτε Kubernetes, τότε σε ποιο pod συνέβη η αποτυχία, ποια ήταν η κατάσταση του pod. Και κατά συνέπεια, το Observability έχει άμεση σχέση με το MTTR. Όσο υψηλότερη είναι η παρατηρησιμότητα της υπηρεσίας, τόσο πιο εύκολο είναι να εντοπιστεί το σφάλμα, τόσο πιο εύκολο είναι να διορθωθεί το σφάλμα, τόσο πιο εύκολο είναι να αυτοματοποιηθεί το σφάλμα, τόσο χαμηλότερο είναι το MTTR.
Προχωρώντας ξανά σε μικρές εταιρείες, είναι πολύ συνηθισμένο να ρωτάμε, ακόμη και τώρα, πώς να αντιμετωπίσετε το μέγεθος της ομάδας και εάν μια μικρή ομάδα χρειάζεται να προσλάβει μια ξεχωριστή SRE. Μιλήσαμε ήδη για αυτό λίγο νωρίτερα. Στα πρώτα στάδια ανάπτυξης μιας startup ή, για παράδειγμα, μιας ομάδας, αυτό δεν είναι καθόλου απαραίτητο, επειδή η SRE μπορεί να γίνει μεταβατικός ρόλος. Και αυτό θα αναζωογονήσει λίγο την ομάδα, γιατί υπάρχει τουλάχιστον μια διαφορετικότητα. Και συν ότι θα προετοιμάσει τους ανθρώπους για το γεγονός ότι με την ανάπτυξη, γενικά, οι ευθύνες της SRE θα αλλάξουν πολύ σημαντικά. Εάν προσλάβετε ένα άτομο, τότε, φυσικά, έχει κάποιες προσδοκίες. Και αυτές οι προσδοκίες δεν θα αλλάξουν με την πάροδο του χρόνου, αλλά οι απαιτήσεις θα αλλάξουν πολύ. Επομένως, ο τρόπος πρόσληψης ενός SRE είναι αρκετά δύσκολος στα αρχικά στάδια. Το να μεγαλώσεις το δικό σου είναι πολύ πιο εύκολο. Αξίζει όμως να το σκεφτούμε.
Η μόνη εξαίρεση, ίσως, είναι όταν υπάρχουν πολύ αυστηρές και καλά καθορισμένες απαιτήσεις ανάπτυξης. Δηλαδή, στην περίπτωση μιας startup, αυτό μπορεί να είναι κάποιου είδους πίεση από τους επενδυτές, κάποιου είδους πρόβλεψη ανάπτυξης πολλές φορές ταυτόχρονα. Τότε η πρόσληψη ενός SRE είναι βασικά δικαιολογημένη επειδή μπορεί να δικαιολογηθεί. Έχουμε απαιτήσεις για ανάπτυξη, χρειαζόμαστε έναν άνθρωπο που θα είναι υπεύθυνος για το γεγονός ότι με τέτοια ανάπτυξη τίποτα δεν θα σπάσει.
Μία ακόμα ερώτηση. Τι να κάνετε όταν πολλές φορές οι προγραμματιστές κόβουν ένα χαρακτηριστικό που περνά τις δοκιμές, αλλά σπάει την παραγωγή, φορτώνει τη βάση, σπάει άλλες δυνατότητες, ποια διαδικασία να εφαρμόσει. Αντίστοιχα, σε αυτήν την περίπτωση, εισάγεται ο προϋπολογισμός για σφάλματα. Και μερικές από τις υπηρεσίες, ορισμένα από τα χαρακτηριστικά δοκιμάζονται ήδη στην παραγωγή. Μπορεί να είναι καναρίνι, όταν μόνο ένας μικρός αριθμός χρηστών, αλλά ήδη στην παραγωγή, έχει αναπτυχθεί μια δυνατότητα, αλλά ήδη με την προσδοκία ότι αν κάτι σπάσει, για παράδειγμα, για το μισό τοις εκατό όλων των χρηστών, θα εξακολουθεί να πληροί τις προϋπολογισμός για λάθη. Κατά συνέπεια, ναι, θα υπάρξει σφάλμα, για ορισμένους χρήστες όλα θα σπάσουν, αλλά έχουμε ήδη πει ότι αυτό είναι φυσιολογικό.
Υπήρχε μια ερώτηση σχετικά με τα εργαλεία SRE. Δηλαδή, υπάρχει κάτι συγκεκριμένο που θα χρησιμοποιούσαν οι SRE που δεν θα το έκαναν όλοι οι άλλοι. Στην πραγματικότητα, υπάρχουν ορισμένα εξαιρετικά εξειδικευμένα βοηθητικά προγράμματα, υπάρχει κάποιο είδος λογισμικού που, για παράδειγμα, προσομοιώνει φορτία ή ασχολείται με τη δοκιμή καναρινιών A / B. Αλλά βασικά η εργαλειοθήκη SRE είναι αυτό που χρησιμοποιούν ήδη οι προγραμματιστές σας. Επειδή η SRE αλληλεπιδρά άμεσα με την ομάδα ανάπτυξης. Και αν έχετε διαφορετικά εργαλεία, θα αποδειχθεί ότι χρειάζεται χρόνος για να συγχρονίσετε. Ειδικά αν οι SRE λειτουργούν σε μεγάλες ομάδες, σε μεγάλες εταιρείες όπου μπορεί να υπάρχουν πολλές ομάδες, είναι η τυποποίηση σε επίπεδο εταιρείας που θα βοηθήσει πολύ εδώ, γιατί εάν χρησιμοποιούνται 50 διαφορετικά βοηθητικά προγράμματα σε 50 ομάδες, αυτό σημαίνει ότι η SRE πρέπει να τα γνωρίζει όλα. Και φυσικά αυτό δεν θα γίνει ποτέ. Και η ποιότητα της δουλειάς, η ποιότητα του ελέγχου τουλάχιστον ορισμένων από τις ομάδες θα μειωθεί σημαντικά.
Το διαδικτυακό μας σεμινάριο φτάνει στο τέλος του. Κατάφερα να πω κάποια βασικά πράγματα. Φυσικά, τίποτα για το SRE δεν μπορεί να ειπωθεί και να κατανοηθεί σε μια ώρα. Ελπίζω όμως ότι κατάφερα να μεταφέρω αυτόν τον τρόπο σκέψης, τα βασικά σημεία-κλειδιά. Και τότε θα είναι δυνατό, εάν ενδιαφέρεστε, να εμβαθύνετε στο θέμα, να μάθετε μόνοι σας, να δείτε πώς εφαρμόζεται από άλλους ανθρώπους, σε άλλες εταιρείες. Και κατά συνέπεια, στις αρχές Φεβρουαρίου, ελάτε σε εμάς στο Slurm SRE.
Το Slurm SRE είναι ένα τριήμερο εντατικό μάθημα που θα μιλήσει για αυτό για το οποίο μιλάω τώρα, αλλά με πολύ μεγαλύτερο βάθος, με πραγματικές περιπτώσεις, με πρακτική, όλη η εντατική στοχεύει στην πρακτική εργασία. Οι άνθρωποι θα χωριστούν σε ομάδες. Όλοι θα εργάζεστε σε πραγματικές υποθέσεις. Αντίστοιχα, έχουμε τους εκπαιδευτές της Booking.com, Ivan Kruglov και Ben Tyler. Έχουμε έναν υπέροχο Eugene Barabbas από την Google, από το Σαν Φρανσίσκο. Και θα σου πω και κάτι. Οπότε φροντίστε να μας επισκεφτείτε.
Λοιπόν, η βιβλιογραφία. Υπάρχουν αναφορές στο SRE. στο ίδιο βιβλίο, ή μάλλον σε 2 βιβλία για το SRE, γραμμένα από την Google. Αλλο ένα , όπου οι όροι και η εφαρμογή τους είναι λίγο πιο αναλυτικοί. Οι επόμενες 3 είναι αναφορές για SRE σε διαφορετικές εταιρείες. Πρώτα - , αυτή είναι μια βασική ομιλία από τον Ben Trainer της Google. Δεύτερο - . Το τρίτο είναι πάλι . Τέταρτη αναφορά από , η οποία έχει μόνο 5 βασικούς υπαλλήλους της SRE σε 190 χώρες. Είναι πολύ ενδιαφέρον να τα δούμε όλα αυτά, γιατί ακριβώς όπως το DevOps σημαίνει πολύ διαφορετικά πράγματα για διαφορετικές εταιρείες και ακόμη και διαφορετικές ομάδες, η SRE έχει πολύ διαφορετικές αρμοδιότητες, ακόμη και σε εταιρείες παρόμοιου μεγέθους.
2 ακόμη σύνδεσμοι σχετικά με τις αρχές της μηχανικής χάους: , . Και στο τέλος υπάρχουν 3 λίστες από τη σειρά Awesome Lists about , σχετικά με και περίπου . Ο κατάλογος στο SRE είναι απίστευτα τεράστιος, δεν είναι απαραίτητο να το διαβάσετε όλο, υπάρχουν περίπου 200 άρθρα. Συνιστώ ανεπιφύλακτα άρθρα από εκεί σχετικά με τον προγραμματισμό χωρητικότητας και για την άψογη μεταθανάτια.
Ενδιαφέρον άρθρο:
Σας ευχαριστώ που με ακούτε όλο αυτό το διάστημα. Ελπίζω να έμαθες κάτι. Ελπίζω να έχετε αρκετό υλικό για να μάθετε περισσότερα. Και τα λέμε. Ας ελπίσουμε τον Φεβρουάριο.
Το webinar διοργανώθηκε από τον Eduard Medvedev.
ΥΓ: για όσους τους αρέσει να διαβάζουν, ο Eduard έδωσε μια λίστα με αναφορές. Όσοι προτιμούν να κατανοήσουν στην πράξη είναι ευπρόσδεκτοι .
Πηγή: www.habr.com