Hvad er en SRE? Den vigtige rolle som stedets pålidelighedsingeniør

Da verden er skiftet online, er pålideligheden af websteder, cloudapplikationer og skyinfrastruktur blevet en kritisk forretningsomfang - for alt fra e-handelsoperationer til globale banker til søgemaskiner.

Den måde, hvorpå vi styrer systemer og deres arbejdsbelastning, har ændret sig. I dag tænker vi sjældent i form af dyrebare, high-touch-servere med høj ydeevne, men i stedet rack-on-rack med vareservere samlet gennem virtualisering med distribueret softwarearkitektur, der forhindrer serverudfald i at forårsage nedetid. Fokuset er skiftet fra hardware til software-defineret infrastruktur og fra inkonsekvente og fejlbehæftede manuelle processer til ensartede, pålidelige og gentagelige automatiserede opgaver.

Websteds pålidelighedsteknik er den praksis at vedligeholde den programmerbare infrastruktur og maksimere tilgængeligheden af de arbejdsbelastninger, der kører på den. Webstedets pålidelighedsingeniør (SRE) jobtitel stammer fra Googles haller, som ved årtusindskiftet ønskede at omdefinere forholdet mellem softwareudviklere og driftspersonale - og hjælpe dem med at arbejde sammen om at opbygge robuste, fleksible systemer med konstant forbedring og automatisering som kerneprincipper.

Hvad er en SRE?

På basisniveau bringer SRE'er softwaretekniske principper til infrastruktur- og driftsproblemer med nordstjernemålet om at skabe meget skalerbare og pålidelige systemer.

"Grundlæggende er det, hvad der sker, når du beder en softwaretekniker om at designe en operationsfunktion," som Ben Treynor, VP for ingeniør hos Google og gudfar til SRE, ofte citeres for at sige.

Hoved blandt SRE-ansvar er at etablere serviceniveau-tærskler, ofte manifesteret som serviceniveau-mål (SLO'er), som hjælper med at informere, om en frigivelse bliver grønt lys eller ej. Den hellige gral er altid den hellige 'fem ni' eller 99,999% oppetid. Jo bedre oppetid, jo flere rebudviklere får lanceret seje nye ting, og jo flere søvn-SRE'er får, hvilket fører til et gensidigt fordelagtigt forhold mellem funktionerne, langt fra de gamle dage med udvikler- og operationsantagonisme.

En SRE-funktion måles typisk på et sæt nøglepålidelighedsmålinger, nemlig: systemydelse, tilgængelighed, ventetid, effektivitet, overvågning, kapacitetsplanlægning og beredskab.

[Også på: Applikationsovervågning: Hvad devops kan gøre bedre]

Nøglejobansvar for en SRE

Enhver god SRE vil være besat af en ting især: automatisering.

Som Jason Qualman, en SRE hos overvågningssoftwareleverandøren New Relic, udtaler i et blogindlæg: ”Meget af denne rolle tænker på ineffektive og tidskrævende ting, folk gør og sætter en stopper for dem så hurtigt som muligt. I stedet for at sparke en dåse ned ad vejen ved manuelt arbejde, siger du: 'Jeg tager mig tid til at automatisere dette lige nu og forhindrer andre i at skulle gøre denne smertefulde ting.' "

Et andet nøgleelement i SRE-rollen er noget, der kaldes "frigivelsesteknik", hvilket indebærer at definere bedste praksis for at sikre, at softwareudgivelser er konsistente og gentagelige.

”Udgivelsesingeniører har en solid (hvis ikke ekspert) forståelse af kildekodestyring, compilers, build-konfigurationssprog, automatiserede build-værktøjer, pakkehåndtering og installatører. Deres dygtighedssæt inkluderer dyb kendskab til flere domæner: udvikling, konfigurationsstyring, testintegration, systemadministration og kundesupport, ”skrev Dinah McNutt, teknisk programleder hos Google, til den sædvanlige bog. Webstedets pålidelighedsteknik (udgivet af O'Reilly i 2016 og forfatter af Googlers Jennifer Petoff, Niall Richard Murphy, Chris Jones og Betsy Beyer).

Derefter er der reaktionsdelen af rollen, som involverer alarmering, tilkaldevalg og fejlfinding sammen med nød- og hændelsesrespons og dødsfald.

I det væsentlige er det vigtigt, at SRE'er ved, hvordan man bedst kan overvåge systemer og reagere, når ting går galt, konstant skrive og omskrive svarbøger for at reducere tiden til at rette op på eventuelle sammenbrud. Hos Google indebærer dette at dokumentere en hændelse, forstå alle medvirkende årsager og implementere fremtidige forebyggende handlinger.

"At skrive et dødsfald er ikke straf - det er en læringsmulighed for hele virksomheden," skriver Googlers John Lunney og Sue Lueder i et bidraget kapitel af Site Reliability Engineering Bestil.

[Også om: 3 trin til anvendelse af smidige metoder i it-drift]

SRE'er vs devops ingeniører

Jeg ved hvad du tænker. Det lyder alt sammen som devops, men når det kommer til terminologi, går SRE-jobtitlen faktisk forud for devops engineer med omkring fem år.

Begge er baseret på lignende principper, men forskellen er både subtil og vigtig. Begge måder at arbejde indebærer at nedbryde barrierer mellem udviklere og driftspersonale, og begge sigter mod at øge hastigheden på udviklerhold, samtidig med at disse tjenester opretholder kernenes fleksibilitet.

Hovedforskellen er, at devops-ingeniører har tendens til at fokusere på at understøtte kontinuerlig levering og udviklerhastighed, mens SRE'er tager ansvar for pålidelighed og automatisering gennem softwarelevecyklussen med vægt på succesfuld implementering og overvågning af udgivelser og opretholdelse af softwaredefineret infrastruktur. SRE har en integreret funktion inden for det bredere tekniske team: at sikre, at der er en specialistplads ved bordet med fokus på at opbygge stabile systemer.

Som Jayne Groll fra The Devops Institute udtrykker det: ”Devops fokuserer på konstruktion af kontinuerlig levering til implementeringsstedet; SRE fokuserer på at konstruere kontinuerlig drift på det sted, hvor kunderne forbruger.

Historien om SRE hos Google

At spore SRE-principper tilbage til deres oprindelse hos Google i begyndelsen af 2000'erne giver en vigtig objektlektion i disciplinen.

”Da jeg kom til Google, var jeg så heldig at være en del af et team, der delvist var sammensat af folk, der var softwareingeniører, og som var tilbøjelige til at bruge software som en måde at løse problemer, der historisk var blevet løst manuelt. Så da det var tid til at oprette et formelt team til at udføre dette operationelle arbejde, var det naturligt at tage tilgangen til 'alt kan behandles som et softwareproblem' og køre med det, "sagde Ben Treynor i et interview på Googles interne blog.

”Så SRE arbejder grundlæggende på arbejde, der historisk er udført af et operationsteam, men bruger ingeniører med softwareekspertise og banker på det faktum, at disse ingeniører iboende både er disponeret for og har evnen til at erstatte automatisering af menneskeligt arbejde, ”Tilføjer Treynor.

Google tænker også ret stift på, hvordan man sammensætter et SRE-team. Alle Google SRE'er skal enten være Google Software Engineers eller "kandidater, der er meget tæt på Google Software Engineering-kvalifikationer." De skal også have infrastrukturadministrationsevner, mest almindeligt "Unix-systeminterne og netværksekspertise (lag 1 til lag 3)."

SRE-kvalifikationer har stadig en tendens til at variere fra virksomhed til virksomhed, men hvad grundlæggende principper angår, er Google-tilgangen et solidt udgangspunkt. Detaljerne afhænger af forretningsbehovet, etablerede processer og tech stack, der allerede er vedtaget af organisationen.

SRE jobbeskrivelse og løn

SRE'er bruger typisk omkring 50 procent af deres tid på at udføre traditionelle funktionsfunktioner, såsom at være på vagt og hoppe ind for at løse problemer. De øvrige 50 procent er fokuseret på at udvikle software til at gøre underliggende systemer mere modstandsdygtige, automatiserede og selvhelende over tid. Derfor kræver rollen en solid blanding af softwaretekniske koteletter og driftsfærdigheder. En god SRE vil blive organiseret, køligt under pres og en problemløser. SRE-ledere er ansvarlige for holdets ydeevne, strategi og optimering.

Men hvad med organisationer, hvor SRE-rollen ikke findes? I O'Reilly-rapporten "Hvad er SRE?" Kurt Andersen fra LinkedIn og Craig Sebenik fra Split (en leverandør af frigivelsesstyringssoftware) anbefaler, at man tager en ”græsrods” tilgang. De anbefaler at finde ”et udviklingsteam, der er motiveret til at ændre og implementere et lille SRE-team (eller individ) der. Over tid kan du bruge den succes som et positivt eksempel for andre hold. ”

Den gennemsnitlige årsløn for en SRE er cirka $ 130.000 i USA og £ 76.000 i Storbritannien, ifølge jobwebstedet Indeed.

SRE ressourcer

Der er mange ressourcer til at opbygge SRE-færdigheder, fra certificeringer fra DevOps Institute til bøger og online ressourcer fra O'Reilly, Microsoft og Google. Den førnævnte 550 sider lange behemothWebstedets pålidelighedsteknik af Jennifer Petoff, Niall Richard Murphy, Chris Jones og Betsy Beyer er go-to-tome om emnet, udgivet i 2016. Bogen er også tilgængelig gratis online fra Google.

Andre nyere bøger om emnet inkludererUddannelsesstedets pålidelighedsingeniører af Jennifer Petoff, JC van Winkel og Preston Yoshioka;Hvad er SRE? af Kurt Andersen og Craig Sebenik;Søger SREaf David N. Blank-Edelman ogWebsteds pålidelighedsarbejdsbog af Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara og Stephen Thorne.

O'Reilly har også et omfattende bibliotek med onlineaktiver, videoer og e-bøger om emnet, der er kurateret i denne SRE Essentials-playliste af den tidligere Google-site-pålidelighedsingeniør Liz Fong-Jones.

Online læring juggernaut Coursera tilbyder flere kurser, herunder den populære Site Reliability Engineering: Måling og styring af pålidelighed fra Google Cloud Training. Dette kursus er også tilgængeligt fra Pluralsight, ligesom begynderkurset Site Reliability Engineering (SRE): The Big Picture af Elton Stoneman. Linux Foundation tilbyder et selvstyret kursus med titlen DevOps og SRE Fundamentals: Implementing Continuous Delivery.

UK-baserede vandmændstræning tilbyder forskellige to-dages private kursusindstillinger for SRE Foundation (SREF).