Hva er en SRE? Den viktige rollen til nettstedets pålitelighetsingeniør

Etter hvert som verden har endret seg på nettet, har påliteligheten til nettsteder, skyapplikasjoner og skyinfrastruktur blitt en viktig forretningsvirksomhet - for alt fra e-handelsdrift til globale banker til søkemotorer.

Måten vi administrerer systemer på og deres arbeidsmengder har endret seg. I dag tenker vi sjelden på dyrebare høytytende servere med høy ytelse, men i stedet rack på rack med vareservere samlet sammen gjennom virtualisering, med distribuert programvarearkitektur som forhindrer serverbrudd fra å forårsake nedetid. Fokuset har skiftet fra maskinvare til programvaredefinert infrastruktur og fra inkonsekvente og feilutsatte manuelle prosesser til konsistente, pålitelige og repeterbare automatiserte oppgaver.

Site reliability engineering er praksis for å opprettholde den programmerbare infrastrukturen og maksimere tilgjengeligheten av arbeidsbelastningene som kjøres på den. Nettstedets pålitelighetsingeniør (SRE) -tittel har sitt utspring i salene til Google, som ved årtusenskiftet ønsket å omdefinere forholdet mellom programvareutviklere og driftspersonell - og hjelpe dem å samarbeide om å bygge robuste, fleksible systemer med konstant forbedring og automatisering som kjerneprinsipper.

Hva er en SRE?

På basenivå bringer SRE-er programvareteknikkprinsipper til infrastruktur- og driftsproblemer, med nordstjernemålet å skape svært skalerbare og pålitelige systemer.

"Det er grunnleggende hva som skjer når du ber en programvareingeniør om å designe en operasjonsfunksjon," som Ben Treynor, teknisk direktør hos Google og gudfaren til SRE, ofte blir sitert.

Sjef blant SRE-ansvar er å etablere terskler for servicenivå, ofte manifestert som SLO-er (service-level goals), som hjelper til med å informere om en utgivelse blir grønt lys eller ikke. Den hellige gral er alltid den hellige 'fem ni' eller 99.999% oppetid. Jo bedre oppetid, jo flere tauutviklere får lansere kule nye ting og jo mer søvn-SRE-er får, noe som fører til et gjensidig fordelaktig forhold mellom funksjonene, langt fra de gamle dagene av utvikler- og operasjonsantagonisme.

En SRE-funksjon vil vanligvis bli målt på et sett med viktige pålitelighetsmålinger, nemlig: systemytelse, tilgjengelighet, ventetid, effektivitet, overvåking, kapasitetsplanlegging og beredskap.

[Også på: Søknadsovervåking: Hva devops kan gjøre bedre]

Nøkkelansvar for en SRE

Enhver god SRE vil være besatt av en ting spesielt: automatisering.

Som Jason Qualman, en SRE for overvåking av programvareleverandøren New Relic, uttaler i et blogginnlegg: “Mye av denne rollen er å tenke på ineffektive og tidkrevende ting folk gjør og stoppe dem så snart som mulig. I stedet for å sparke en boks nedover veien på manuelt arbeid, sier du: 'Jeg kommer til å ta meg tid til å automatisere dette akkurat nå og stoppe noen andre fra å måtte gjøre denne smertefulle tingen.' "

Et annet sentralt element i SRE-rollen er noe som kalles "release engineering", som innebærer å definere beste praksis for å sikre at programvareutgivelser er konsistente og repeterbare.

“Utgivelsesingeniører har en solid (om ikke ekspert) forståelse av kildekodeadministrasjon, kompilatorer, byggekonfigurasjonsspråk, automatiserte byggeverktøy, pakkeforvaltere og installatører. Deres ferdighetssett inkluderer dyp kunnskap om flere domener: utvikling, konfigurasjonsadministrasjon, testintegrasjon, systemadministrasjon og kundesupport, ”skrev Dinah McNutt, teknisk programleder hos Google, for den grunnleggende boken. Site Reliability Engineering (utgitt av O'Reilly i 2016 og forfattet av Googlers Jennifer Petoff, Niall Richard Murphy, Chris Jones og Betsy Beyer).

Så er det responsdelen av rollen, som innebærer å varsle, være på vakt og feilsøke, sammen med nød- og hendelsesrespons og dødsfall.

I hovedsak er det viktig at SRE-er vet hvordan de best kan overvåke systemer og reagere når ting går galt. De skriver og omskriver svarsspillbøker hele tiden for å redusere tiden til å løse eventuelle sammenbrudd som kan oppstå. Hos Google innebærer dette å dokumentere en hendelse, forstå alle medvirkende årsaker og implementere fremtidige forebyggende handlinger.

"Å skrive et dødsfall er ikke straff - det er en læringsmulighet for hele selskapet," skriver Googlers John Lunney og Sue Lueder i et bidratt kapittel av Site Reliability Engineering bok.

[Også om: 3 trinn for å anvende smidige metoder i IT-drift]

SREs vs devops ingeniører

Jeg vet hva du tenker. Alt høres ut som devops, men når det kommer til terminologi, er SRE-tittelen faktisk pre-dates devops engineer med omtrent fem år.

Begge er forankret i lignende prinsipper, men forskjellen er både subtil og viktig. Begge måtene å jobbe på innebærer å bryte ned barrierer mellom utviklere og driftspersonell, og begge tar sikte på å øke hastigheten på utviklerlag mens man opprettholder kjernens elastisitet i tjenestene.

Hovedforskjellen er at devops-ingeniører har en tendens til å fokusere på å støtte kontinuerlig levering og utviklerhastighet, mens SRE-er tar ansvar for pålitelighet og automatisering gjennom programvarens livssyklus, med vekt på vellykket distribusjon og overvåking av utgivelser og beholder programvaredefinert infrastruktur. SRE har en integrert funksjon i det bredere tekniske teamet: å sikre at det er en spesialist ved bordet med fokus på å bygge stabile systemer.

Som Jayne Groll ved The Devops Institute uttrykker det: “Devops fokuserer på å konstruere kontinuerlig levering til distribusjonsstedet; SRE fokuserer på å konstruere kontinuerlig drift i det punktet hvor kundene bruker. ”

Historien til SRE hos Google

Å spore SRE-prinsippene tilbake til opprinnelsen hos Google på begynnelsen av 2000-tallet gir en viktig leksjon i disiplinen.

“Da jeg kom til Google, var jeg heldig nok til å være en del av et team som delvis var sammensatt av folk som var programvareingeniører, og som var tilbøyelige til å bruke programvare som en måte å løse problemer som historisk hadde blitt løst for hånd. Så da det var på tide å opprette et formelt team for å gjøre dette operasjonelle arbeidet, var det naturlig å følge fremgangsmåten 'alt kan behandles som et programvareproblem' og kjøre med den, "uttalte Ben Treynor i et intervju på Googles interne blogg.

“Så SRE gjør i utgangspunktet arbeid som historisk har blitt utført av et operasjonsteam, men bruker ingeniører med programvarekompetanse, og banker på det faktum at disse ingeniørene iboende både er disponert for og har muligheten til å erstatte automatisering av menneskelig arbeid, ”Legger Treynor til.

Google tenker også ganske stivt på hvordan man kan sette sammen et SRE-team. Alle Google SRE-er må enten være Google Software Engineers eller "kandidater som er veldig nær Google Software Engineering-kvalifikasjoner." De må også ha ferdigheter i infrastrukturadministrasjon, vanligvis "Unix system internals and networking (Layer 1 to Layer 3) expertise."

SRE-kvalifikasjoner har fortsatt en tendens til å variere fra selskap til selskap, men når det gjelder grunnleggende prinsipper, er Google-tilnærmingen et solid utgangspunkt. Detaljene vil avhenge av forretningsbehovene, etablerte prosesser og tech stack som allerede er vedtatt av organisasjonen.

SRE stillingsbeskrivelse og lønn

SRE bruker vanligvis rundt 50 prosent av tiden sin på å utføre tradisjonelle operasjonsfunksjoner, for eksempel å være på vakt og hoppe inn for å løse problemer. De andre 50 prosentene er fokusert på å utvikle programvare for å gjøre underliggende systemer mer elastiske, automatiserte og selvhelbredende over tid. Derfor krever rollen en solid blanding av programvareteknikk og operasjonsferdigheter. En god SRE vil bli organisert, kult under press, og en problemløser. SRE-ledere er ansvarlige for teamets ytelse, strategi og optimalisering.

Men hva med organisasjoner der SRE-rollen ikke eksisterer? I O'Reilly-rapporten "Hva er SRE?" Kurt Andersen fra LinkedIn og Craig Sebenik fra Split (en programvareleverandør av frigjøringsadministrasjon) anbefaler å ta en “grasrot” -tilnærming. De anbefaler å finne “et utviklingsteam som er motivert for å endre og implementere et lite SRE-team (eller individ) der. Over tid kan du bruke den suksessen som et positivt eksempel for andre lag. ”

Gjennomsnittlig årslønn for en SRE er omtrent $ 130.000 i USA og £ 76.000 i Storbritannia, ifølge jobbsiden Indeed.

SRE ressurser

Det er mange ressurser for å bygge SRE-ferdigheter, fra sertifiseringer fra DevOps Institute til bøker og nettressurser fra O'Reilly, Microsoft og Google. Ovennevnte 550-siders behemothSite Reliability Engineering av Jennifer Petoff, Niall Richard Murphy, Chris Jones, og Betsy Beyer er det viktigste for temaet, utgitt i 2016. Boken er også tilgjengelig gratis online fra Google.

Andre nyere bøker om emnet inkludererTraining Site Reliability Engineers av Jennifer Petoff, JC van Winkel og Preston Yoshioka;Hva er SRE? av Kurt Andersen og Craig Sebenik;Søker SREav David N. Blank-Edelman, ogNettsteds pålitelighetsarbeidsbok av Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara og Stephen Thorne.

O'Reilly har også et omfattende bibliotek med elektroniske eiendeler, videoer og e-bøker om emnet, kuratert i denne SRE Essentials-spillelisten av den tidligere Googles nettstedspålitelighetsingeniør Liz Fong-Jones.

Online læringsjuggernaut Coursera tilbyr flere kurs, inkludert den populære Site Reliability Engineering: Måling og håndtering av pålitelighet fra Google Cloud Training. Dette kurset er også tilgjengelig fra Pluralsight, det samme er begynnerkurset Site Reliability Engineering (SRE): The Big Picture av Elton Stoneman. Linux Foundation tilbyr et selvstyrt kurs med tittelen DevOps and SRE Fundamentals: Implementing Continuous Delivery.

UK-baserte Jellyfish Training tilbyr ulike to-dagers private kursalternativer for SRE Foundation (SREF).