Προγραμματισμός

Τι είναι το SRE; Ο ζωτικός ρόλος του μηχανικού αξιοπιστίας του ιστότοπου

Καθώς ο κόσμος έχει μετατοπιστεί στο διαδίκτυο, η αξιοπιστία των ιστότοπων, των εφαρμογών cloud και της υποδομής cloud έχει καταστεί κρίσιμη επιτακτική ανάγκη των επιχειρήσεων - για οτιδήποτε, από λειτουργίες ηλεκτρονικού εμπορίου έως παγκόσμιες τράπεζες έως μηχανές αναζήτησης.

Ο τρόπος διαχείρισης των συστημάτων και του φόρτου εργασίας τους έχει αλλάξει. Σήμερα, σπάνια σκεφτόμαστε όσον αφορά πολύτιμους διακομιστές υψηλής απόδοσης, υψηλής απόδοσης, αλλά αντ 'αυτού βασανίζουμε τους διακομιστές εμπορευμάτων που συγκεντρώνονται μέσω εικονικοποίησης, με κατανεμημένη αρχιτεκτονική λογισμικού που εμποδίζει τις διακοπές λειτουργίας του διακομιστή να προκαλούν διακοπή λειτουργίας. Η εστίαση έχει μετατοπιστεί από υλικό σε υποδομή που καθορίζεται από λογισμικό και από ασυνεπείς και επιρρεπείς σε σφάλματα χειροκίνητες διαδικασίες σε συνεπείς, αξιόπιστες και επαναλαμβανόμενες αυτοματοποιημένες εργασίες.

Η μηχανική αξιοπιστίας ιστότοπου είναι η πρακτική της διατήρησης αυτής της προγραμματιζόμενης υποδομής και της μεγιστοποίησης της διαθεσιμότητας των φόρτων εργασίας που λειτουργούν σε αυτήν. Ο τίτλος εργασίας του μηχανικού αξιοπιστίας ιστότοπου (SRE) προήλθε από τις αίθουσες της Google, οι οποίες, στα τέλη της χιλιετίας, ήθελαν να επαναπροσδιορίσουν τη σχέση μεταξύ προγραμματιστών λογισμικού και προσωπικού λειτουργίας - και να τους βοηθήσουν να συνεργαστούν για την κατασκευή ανθεκτικών, ευέλικτων συστημάτων, με συνεχή βελτίωση και αυτοματοποίηση ως βασικές αρχές.

Τι είναι το SRE;

Σε επίπεδο βάσης, οι SRE φέρνουν αρχές μηχανικής λογισμικού σε προβλήματα υποδομής και λειτουργιών, με στόχο το βορρά αστέρι να δημιουργεί εξαιρετικά επεκτάσιμα και αξιόπιστα συστήματα.

«Βασικά, είναι αυτό που συμβαίνει όταν ζητάτε από έναν μηχανικό λογισμικού να σχεδιάσει μια λειτουργία λειτουργίας», όπως αναφέρει συχνά ο Ben Treynor, αντιπρόεδρος μηχανικής της Google και ο νονός της SRE.

Επικεφαλής μεταξύ των αρμοδιοτήτων του SRE είναι η καθιέρωση ορίων επιπέδου υπηρεσίας, που συχνά εκδηλώνονται ως στόχοι επιπέδου υπηρεσίας (SLOs), τα οποία βοηθούν στην ενημέρωση για το κατά πόσο μια κυκλοφορία γίνεται πράσινη. Το ιερό grail είναι πάντα το ιερό «πέντε εννέα» ή 99,999% uptime. Όσο καλύτερη είναι η διάρκεια λειτουργίας, τόσο περισσότεροι προγραμματιστές σχοινιών θα ξεκινήσουν δροσερά νέα πράγματα και τόσο περισσότεροι ύπνοι SREs, οδηγώντας σε μια αμοιβαία επωφελής σχέση μεταξύ των λειτουργιών, πολύ μακριά από τις παλιές μέρες του προγραμματιστή και του ανταγωνισμού λειτουργίας.

Μια συνάρτηση SRE θα μετρηθεί συνήθως σε ένα σύνολο βασικών μετρήσεων αξιοπιστίας, συγκεκριμένα: απόδοση του συστήματος, διαθεσιμότητα, καθυστέρηση, αποδοτικότητα, παρακολούθηση, σχεδιασμός χωρητικότητας και απόκριση έκτακτης ανάγκης.

[Επίσης στις: Παρακολούθηση εφαρμογών: Τι μπορούν να κάνουν καλύτερα οι devops]

Βασικές αρμοδιότητες εργασίας ενός SRE

Οποιοδήποτε καλό SRE θα είναι εμμονή με ένα πράγμα ειδικότερα: αυτοματοποίηση.

Όπως δηλώνει ο Jason Qualman, ένας SRE στον προμηθευτή λογισμικού New Relic, σε μια ανάρτηση ιστολογίου: «Πολύς από αυτόν τον ρόλο σκέφτεται για αναποτελεσματικά και χρονοβόρα πράγματα που κάνουν οι άνθρωποι και να τους σταματήσουν το συντομότερο δυνατό. Αντί να κλωτσάτε ένα κουτάκι στο δρόμο για χειροκίνητη εργασία, λέτε: «Θα αφιερώσω χρόνο για να αυτοματοποιήσω αυτήν τη στιγμή και να σταματήσω κανέναν άλλο να κάνει αυτό το οδυνηρό».

Ένα άλλο βασικό στοιχείο του ρόλου του SRE είναι κάτι που ονομάζεται «έκδοση μηχανικών», το οποίο περιλαμβάνει τον καθορισμό βέλτιστων πρακτικών για να διασφαλιστεί ότι οι εκδόσεις λογισμικού είναι συνεπείς και επαναλαμβανόμενες.

«Οι μηχανικοί έκδοσης έχουν μια σταθερή (αν όχι ειδική) κατανόηση της διαχείρισης του πηγαίου κώδικα, των μεταγλωττιστών, των γλωσσών διαμόρφωσης build, των αυτοματοποιημένων εργαλείων κατασκευής, των διαχειριστών πακέτων και των εγκαταστατών. Το σετ δεξιοτήτων τους περιλαμβάνει βαθιά γνώση πολλαπλών τομέων: ανάπτυξη, διαχείριση διαμόρφωσης, ενσωμάτωση δοκιμών, διαχείριση συστήματος και υποστήριξη πελατών », έγραψε ο Dinah McNutt, τεχνικός υπεύθυνος προγράμματος της Google, για το σεμινάριο Μηχανική αξιοπιστίας ιστότοπου (δημοσιεύθηκε από τον O'Reilly το 2016 και συγγραφέας από τους Googlers Jennifer Petoff, Niall Richard Murphy, Chris Jones και Betsy Beyer).

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

Ουσιαστικά, είναι σημαντικό οι SRE να γνωρίζουν πώς να παρακολουθούν καλύτερα τα συστήματα και να αντιδρούν όταν τα πράγματα πάνε στραβά, να γράφουν συνεχώς και να ξαναγράφουν βιβλία απόκρισης για να μειώσουν το χρόνο για να διορθώσουν οποιαδήποτε βλάβη που μπορεί να συμβεί. Στην Google, αυτό περιλαμβάνει την τεκμηρίωση ενός περιστατικού, την κατανόηση όλων των βασικών αιτίων που συμβάλλουν και την εφαρμογή μελλοντικών προληπτικών ενεργειών.

«Το να γράφεις μια μεταθανάτια δεν είναι τιμωρία - είναι μια ευκαιρία μάθησης για ολόκληρη την εταιρεία», γράφουν οι Googlers John Lunney και Sue Lueder σε ένα κεφάλαιο Μηχανική αξιοπιστίας ιστότοπου Βιβλίο.

[Επίσης σε: 3 βήματα για την εφαρμογή ευέλικτων μεθοδολογιών σε λειτουργίες πληροφορικής]

SREs έναντι devops μηχανικών

Ξέρω τι σκέφτεστε. Όλα αυτά μοιάζουν πολύ με τους devops, αλλά όταν πρόκειται για την ορολογία, ο τίτλος εργασίας του SRE προ-χρονολογεί τον μηχανικό devops κατά περίπου πέντε χρόνια.

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

Η βασική διαφορά είναι ότι οι devops μηχανικοί τείνουν να επικεντρώνονται στην υποστήριξη της συνεχούς παράδοσης και της ταχύτητας προγραμματιστή, ενώ οι SRE αναλαμβάνουν την ευθύνη για την αξιοπιστία και τον αυτοματισμό καθ 'όλη τη διάρκεια του κύκλου ζωής του λογισμικού, με έμφαση στην επιτυχή ανάπτυξη και παρακολούθηση των κυκλοφοριών και τη διατήρηση της προγραμματισμένης υποδομής. Το SRE έχει αναπόσπαστη λειτουργία στην ευρύτερη ομάδα μηχανικών: διασφαλίζοντας ότι υπάρχει μια θέση ειδικού στο τραπέζι επικεντρωμένη στην κατασκευή σταθερών συστημάτων.

Όπως το λέει η Jayne Groll στο The Devops Institute: «Το Devops επικεντρώνεται στη μηχανική συνεχή παράδοση στο σημείο ανάπτυξης. Η SRE επικεντρώνεται στη συνεχή λειτουργία μηχανικών στο σημείο της κατανάλωσης των πελατών. "

Η ιστορία του SRE στο Google

Ο εντοπισμός των αρχών του SRE στην προέλευσή τους στο Google στις αρχές της δεκαετίας του 2000 παρέχει ένα βασικό μάθημα αντικειμένου στην πειθαρχία.

«Όταν ήρθα στο Google, ήμουν αρκετά τυχερός που ήμουν σε μια ομάδα που αποτελούταν εν μέρει από άτομα που ήταν μηχανικοί λογισμικού και είχαν την τάση να χρησιμοποιούν το λογισμικό ως τρόπο επίλυσης προβλημάτων που ιστορικά είχαν επιλυθεί με το χέρι. Έτσι, όταν ήρθε η ώρα να δημιουργήσετε μια επίσημη ομάδα για να κάνετε αυτό το επιχειρησιακό έργο, ήταν φυσικό να ακολουθήσετε την προσέγγιση «όλα μπορούν να αντιμετωπίζονται ως πρόβλημα λογισμικού» και να την εκτελέσετε », δήλωσε ο Ben Treynor σε συνέντευξή του στο εσωτερικό ιστολόγιο της Google.

«Έτσι, η SRE κάνει ουσιαστικά δουλειά που έχει ιστορικά γίνει από μια ομάδα επιχειρήσεων, αλλά χρησιμοποιεί μηχανικούς με εξειδίκευση λογισμικού, και βασίζεται στο γεγονός ότι αυτοί οι μηχανικοί είναι εγγενώς προδιάθετοι και έχουν τη δυνατότητα να αντικαταστήσουν τον αυτοματισμό για την ανθρώπινη εργασία, Προσθέτει ο Treynor.

Η Google σκέφτεται επίσης αρκετά άκαμπτα για το πώς να δημιουργήσει μια ομάδα SRE. Όλα τα Google SRE πρέπει είτε να είναι Google Software Engineers είτε "υποψήφιοι που είναι πολύ κοντά στα προσόντα Google Software Engineering." Πρέπει επίσης να έχουν δεξιότητες διαχείρισης υποδομής, συνήθως «Εσωτερικά συστήματος Unix και τεχνογνωσία δικτύωσης (Layer 1 έως Layer 3)».

Τα προσόντα SRE τείνουν να ποικίλλουν από εταιρεία σε εταιρεία, αλλά όσον αφορά τις βασικές αρχές, η προσέγγιση της Google είναι ένα σταθερό σημείο εκκίνησης. Οι λεπτομέρειες θα εξαρτηθούν από τις επιχειρηματικές ανάγκες, τις καθιερωμένες διαδικασίες και την τεχνολογική στοίβα που έχουν ήδη υιοθετηθεί από τον οργανισμό.

Περιγραφή εργασίας και μισθός SRE

Οι SRE συνήθως περνούν περίπου το 50 τοις εκατό του χρόνου τους εκτελώντας παραδοσιακές λειτουργίες, όπως είναι σε ετοιμότητα και άλματα για την επίλυση προβλημάτων. Το άλλο 50% επικεντρώνεται στην ανάπτυξη λογισμικού για να κάνει τα υποκείμενα συστήματα πιο ανθεκτικά, αυτοματοποιημένα και αυτοθεραπευόμενα με την πάροδο του χρόνου. Αυτός είναι ο λόγος για τον οποίο ο ρόλος απαιτεί ένα σταθερό συνδυασμό τεχνικών λογισμικού και δεξιοτήτων λειτουργίας. Ένα καλό SRE θα οργανωθεί, θα κρυώσει υπό πίεση και θα λυθεί το πρόβλημα. Οι διαχειριστές SRE είναι υπεύθυνοι για την απόδοση, τη στρατηγική και τη βελτιστοποίηση της ομάδας.

Τι γίνεται όμως με οργανισμούς όπου ο ρόλος SRE δεν υπάρχει; Στην έκθεση O'Reilly "Τι είναι το SRE;" Ο Kurt Andersen από το LinkedIn και ο Craig Sebenik από το Split (ένας προμηθευτής λογισμικού διαχείρισης κυκλοφορίας) προτείνουν να ακολουθήσουν μια προσέγγιση «βάσης». Συνιστούν να βρείτε «μια ομάδα ανάπτυξης που έχει κίνητρο να αλλάξει και να εφαρμόσει μια μικρή ομάδα SRE (ή άτομο) εκεί. Με την πάροδο του χρόνου, μπορείτε να χρησιμοποιήσετε αυτήν την επιτυχία ως θετικό παράδειγμα για άλλες ομάδες. "

Ο μέσος ετήσιος μισθός για ένα SRE είναι περίπου 130.000 $ στις ΗΠΑ και 76.000 £ στο Ηνωμένο Βασίλειο, σύμφωνα με την τοποθεσία εργασίας.

Πόροι SRE

Οι πόροι αφθονούν για τη δημιουργία δεξιοτήτων SRE, από πιστοποιήσεις από το DevOps Institute έως βιβλία και διαδικτυακούς πόρους από O'Reilly, Microsoft και Google. Ο προαναφερθείς μεγαλοπρεπής 550 σελίδωνΜηχανική αξιοπιστίας ιστότοπου από τους Jennifer Petoff, Niall Richard Murphy, Chris Jones και Betsy Beyer είναι ο στόχος του θέματος, που δημοσιεύθηκε το 2016. Το βιβλίο διατίθεται επίσης δωρεάν στο διαδίκτυο από την Google.

Άλλα πιο πρόσφατα βιβλία για το θέμα περιλαμβάνουνΜηχανικοί αξιοπιστίας εκπαιδευτικού χώρου των Jennifer Petoff, JC van Winkel και Preston Yoshioka.Τι είναι το SRE; από τους Kurt Andersen και Craig Sebenik;Αναζητώντας SREαπό τον David N. Blank-Edelman, καιΤο βιβλίο εργασίας αξιοπιστίας ιστότοπου των Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara και Stephen Thorne.

Το O'Reilly διαθέτει επίσης μια ολοκληρωμένη βιβλιοθήκη στοιχείων διαδικτύου, βίντεο και ebook σχετικά με το θέμα, επιμελημένα σε αυτήν τη λίστα αναπαραγωγής SRE Essentials από την πρώην μηχανική αξιοπιστίας ιστότοπων της Google, Liz Fong-Jones.

Η διαδικτυακή μάθηση juggernaut Coursera προσφέρει διάφορα μαθήματα, όπως το δημοφιλές Μηχανικό Αξιοπιστίας Ιστοτόπου: Μέτρηση και Διαχείριση Αξιοπιστίας από το Google Cloud Training. Αυτό το μάθημα είναι επίσης διαθέσιμο από το Pluralsight, όπως και το αρχικό μάθημα Site Reliability Engineering (SRE): The Big Picture του Elton Stoneman. Το Linux Foundation προσφέρει ένα αυτοκατευθυνόμενο μάθημα με τίτλο DevOps and SRE Fundamentals: Implementing Continuous Delivery.

Το Jellyfish Training με έδρα το Ηνωμένο Βασίλειο προσφέρει διάφορες διήμερες ιδιωτικές επιλογές μαθημάτων κατάρτισης για το SRE Foundation (SREF).

Διαβάστε περισσότερα για τους devops

  • Τι είναι οι devops; Μετασχηματισμός ανάπτυξης λογισμικού
  • 3 τρόποι για να ξεκινήσετε ένα πρόγραμμα devops
  • Διαθέτει βέλτιστες πρακτικές: Οι 5 μέθοδοι που πρέπει να ακολουθήσετε
  • 15 KPI για παρακολούθηση του μετασχηματισμού devops
  • Παρακολούθηση εφαρμογών: Τι μπορούν να κάνουν καλύτερα οι devops
  • Όπου η τεχνική αξιοπιστίας ιστότοπου συναντά τους υπολογιστές
  • 5 αρχές για να γίνετε μια συνεργατική ομάδα ευέλικτων devops
  • 3 βήματα για την εφαρμογή ευέλικτων μεθοδολογιών σε λειτουργίες πληροφορικής
  • Πώς οι ευέλικτες ομάδες μπορούν να υποστηρίξουν τη διαχείριση συμβάντων
  • Πώς τα dataops βελτιώνουν τα δεδομένα, τα analytics και τη μηχανική μάθηση
  • Εφαρμογή devops στην επιστήμη δεδομένων και τη μηχανική μάθηση
  • 7 ερωτήσεις για να δώσετε προτεραιότητα στο καθυστερημένο αρχείο των devops σας
$config[zx-auto] not found$config[zx-overlay] not found