Programiranje

Kaj je SRE? Ključna vloga inženirja zanesljivosti strani

Ko se je svet preusmeril v splet, je zanesljivost spletnih mest, aplikacij v oblaku in infrastruktura v oblaku postala ključna poslovna nujnost - za vse, od operacij e-poslovanja do globalnih bank do iskalnikov.

Način upravljanja sistemov in njihovih delovnih obremenitev se je spremenil. Danes redko razmišljamo z dragocenimi visokozmogljivimi visokozmogljivimi strežniki, ampak namesto tega stojimo na stojalih blagovnih strežnikov, združenih z virtualizacijo, z razdeljeno arhitekturo programske opreme, ki preprečuje, da bi izpadi strežnikov povzročali izpad. Poudarek se je preusmeril s strojne na programsko določeno infrastrukturo in z nedoslednih in napak nagnjenih ročnih postopkov na dosledne, zanesljive in ponovljive avtomatizirane naloge.

Inženiring zanesljivosti spletnega mesta je praksa vzdrževanja te programabilne infrastrukture in povečanja razpoložljivosti delovnih obremenitev, ki se na njej izvajajo. Naslov delovnega mesta inženirja zanesljivosti spletnega mesta (SRE) je nastal v Googlovih dvoranah, ki je na prelomu tisočletja želel na novo definirati odnos med razvijalci programske opreme in operativnim osebjem - ter jim pomagati pri skupni gradnji trdnih, prilagodljivih sistemov z nenehno izboljševanje in avtomatizacija kot temeljna načela.

Kaj je SRE?

Na osnovni ravni SRE vnašajo načela programskega inženiringa v infrastrukturo in operativne težave, njihov cilj pa je ustvariti zelo razširljive in zanesljive sisteme.

"V bistvu se to zgodi, ko od programskega inženirja zahtevate, da oblikuje operacijsko funkcijo," kot pogosto piše Ben Treynor, podpredsednik inženiringa pri Googlu in boter SRE.

Glavna naloga odgovornosti SRE je določitev pragov za raven storitve, ki se pogosto kažejo kot cilji na ravni storitve (SLO), ki pomagajo pri obveščanju o tem, ali je objava osvetljena ali ne. Sveti gral je vedno posvečenih "pet devetk" ali 99,999% uptime. Boljši kot je čas delovanja, več razvijalcev vrvi začne s sproščanjem novih novih stvari in več snovov SRE za spanje, kar vodi do obojestransko koristnega razmerja med funkcijami, kar je daleč od starih časov razvijalčevega in operativnega antagonizma.

Funkcija SRE se običajno meri na naboru ključnih meritev zanesljivosti, in sicer: zmogljivost sistema, razpoložljivost, zakasnitev, učinkovitost, spremljanje, načrtovanje zmogljivosti in odzivanje v izrednih razmerah.

[Tudi o: Spremljanje aplikacij: kaj lahko devops naredi bolje]

Ključne delovne naloge SRE

Vsak dober SRE bo obseden predvsem z enim: avtomatizacijo.

Kot trdi Jason Qualman, SRE pri nadzoru prodajalca programske opreme New Relic, v prispevku v spletnem dnevniku: "Veliko vloge razmišlja o neučinkovitih in dolgotrajnih stvareh, ki jih ljudje počnejo, in jih čim prej zaustavimo. Namesto da bi pri ročnem delu brcali po pločevinkah, pravite: "Vzel si bom čas, da to avtomatiziram zdaj in preprečil, da bi kdo drug počel to bolečo stvar."

Drug ključni element vloge SRE je nekaj, kar se imenuje "inženiring izdaje", kar vključuje določitev najboljših praks za zagotovitev skladnosti in ponovljivosti izdaj programske opreme.

»Inženirji za izdajo dobro (če ne strokovno) razumejo upravljanje izvorne kode, prevajalnike, konfiguracijske jezike gradnje, avtomatizirana orodja za gradnjo, upravitelje paketov in namestitvene programe. Njihov nabor spretnosti vključuje globoko poznavanje več domen: razvoj, upravljanje konfiguracije, integracija preizkusov, skrbništvo sistema in podpora strankam, «je za uvodno knjigo zapisala Dinah McNutt, vodja tehničnega programa pri Googlu. Inženiring zanesljivosti strani (objavil O’Reilly leta 2016 in avtorji Googlov Jennifer Petoff, Niall Richard Murphy, Chris Jones in Betsy Beyer).

Potem je tu še del odzivne vloge, ki vključuje opozarjanje, dežurstvo in odpravljanje težav, skupaj z odzivanjem na nujne primere in nezgode ter postmortems.

V bistvu je pomembno, da SRE vedo, kako najbolje nadzirati sisteme in se odzivati, ko gre kaj narobe, nenehno pišejo in prepisujejo knjige odzivov, da skrajšajo čas za odpravo morebitnih okvar. Pri Googlu to vključuje dokumentiranje incidenta, razumevanje vseh osnovnih vzrokov in izvajanje prihodnjih preventivnih ukrepov.

"Pisanje posmrtnih ostankov ni kazen - to je priložnost za učenje celotnega podjetja," pišeta Googlerina John Lunney in Sue Lueder v prispevnem poglavju Inženiring zanesljivosti strani knjigo.

[Prav tako v nadaljevanju: 3 koraki za uporabo agilnih metodologij v IT-dejavnostih]

SRE v primerjavi z inženirji devops

Vem, kaj misliš. Vse to zveni podobno kot devops, toda kar zadeva terminologijo, naziv delovnega mesta SRE dejansko pred inštruktorjem devopsa začne približno pet let.

Oba temeljita na podobnih načelih, vendar je razlika tako prefinjena kot pomembna. Oba načina dela vključujeta rušenje ovir med razvijalci in operativnim osebjem, oba pa si prizadevata povečati hitrost ekip razvijalcev, hkrati pa ohraniti temeljno odpornost teh storitev.

Ključna razlika je v tem, da se inženirji devops osredotočajo na podporo neprekinjene dostave in hitrosti razvijalcev, medtem ko SRE prevzemajo odgovornost za zanesljivost in avtomatizacijo v celotnem življenjskem ciklu programske opreme, s poudarkom na uspešnem uvajanju in spremljanju izdaj ter ohranjanju programsko opredeljene infrastrukture. SRE ima v širši inženirski ekipi integrirano funkcijo: zagotoviti je, da je za mizo sedež strokovnjaka, osredotočen na gradnjo stabilnih sistemov.

Kot pravi Jayne Groll z Inštituta Devops: „Devops se osredotoča na neprekinjeno inženirsko dostavo do točke uvajanja; SRE se osredotoča na neprekinjeno inženirstvo na mestu porabe kupcev. "

Zgodovina SRE pri Googlu

Sledenje principom SRE do njihovega izvora v Googlu v zgodnjih 2000-ih je osrednji pouk predmeta v tej disciplini.

»Ko sem prišel v Google, sem imel to srečo, da sem bil del ekipe, ki je bila delno sestavljena iz ljudi, ki so bili programski inženirji in so bili nagnjeni k uporabi programske opreme kot načina reševanja problemov, ki so bili v preteklosti rešeni ročno. Torej, ko je bil čas, da se ustvari formalna ekipa, ki bo opravila to operativno delo, je bilo naravno, da uporabimo pristop "vse je mogoče obravnavati kot težavo s programsko opremo" in z njim začnemo, "je izjavil Ben Treynor v intervjuju na Googlovem internem blogu.

"Torej SRE v bistvu opravlja delo, ki ga je v preteklosti opravljala operativna skupina, vendar uporablja inženirje s strokovnim znanjem programske opreme in pri tem upošteva dejstvo, da so ti inženirji po naravi predispozicijski in nadomeščajo avtomatizacijo človeškega dela, ”Dodaja Treynor.

Google tudi precej togo razmišlja o tem, kako sestaviti ekipo za SRE. Vsi Googlovi SRE morajo biti bodisi Googlovi inženirji programske opreme bodisi „kandidati, ki so zelo blizu usposobljenosti za Google Software Engineering“. Imeti morajo tudi spretnosti upravljanja infrastrukture, najpogosteje "Notranjost sistema Unix in strokovno znanje o mreženju (od 1 do 3)."

Kvalifikacije za SRE se še vedno razlikujejo od podjetja do podjetja, toda kar zadeva osnovna načela, je Googlov pristop trdno izhodišče. Podrobnosti bodo odvisne od poslovnih potreb, uveljavljenih procesov in tehnološkega sklada, ki ga je organizacija že sprejela.

Opis dela in plača SRE

SRE običajno porabijo približno 50 odstotkov svojega časa za opravljanje tradicionalnih operativnih funkcij, na primer dežurstva in vstopa, da reši težave. Preostalih 50 odstotkov je osredotočenih na razvoj programske opreme, da bi bili osnovni sistemi sčasoma bolj odporni, avtomatizirani in samozdravljivi. Zato vloga zahteva trdno mešanico odsekov programskega inženirstva in operativnih veščin. Organiziran bo dober SRE, hladen pod pritiskom in reševalec težav. Vodje SRE so odgovorni za delovanje ekipe, strategijo in optimizacijo.

Kaj pa organizacije, kjer vloga SRE ne obstaja? V poročilu O’Reillyja „Kaj je SRE?“ Kurt Andersen iz LinkedIna in Craig Sebenik iz Splita (prodajalec programske opreme za upravljanje izdaj) priporočata, da se odločimo za "množični" pristop. Priporočajo iskanje "razvojne ekipe, ki bi bila motivirana za spremembo in izvajanje majhne skupine SRE (ali posameznika) tam. Sčasoma lahko ta uspeh uporabite kot pozitiven primer drugim ekipam. "

Povprečna letna plača za SRE znaša približno 130.000 ameriških dolarjev v ZDA in 76.000 funtov v Združenem kraljestvu, piše na spletnem mestu za zaposlovanje Indeed.

Viri SRE

Veliko je virov za razvoj spretnosti SRE, od certifikatov Inštituta DevOps do knjig in spletnih virov O’Reilly, Microsoft in Google. Omenjeni behemot na 550 stranehInženiring zanesljivosti strani avtorji Jennifer Petoff, Niall Richard Murphy, Chris Jones in Betsy Beyer so napotki na to temo, objavljeni leta 2016. Knjiga je brezplačno na voljo tudi pri Googlu.

Druge novejše knjige na to temo vključujejoInženirji za zanesljivost spletnega mesta za usposabljanje Jennifer Petoff, JC van Winkel in Preston Yoshioka;Kaj je SRE? avtorja Kurt Andersen in Craig Sebenik;Iskanje SREDavid N. Blank-Edelman, inDelovni zvezek o zanesljivosti spletnega mesta avtorji Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara in Stephen Thorne.

O’Reilly ima tudi obsežno knjižnico spletnih vsebin, videoposnetkov in e-knjig na to temo, ki jo je na tem seznamu predvajanja SRE Essentials zlahka pripravila nekdanja inženirka Googlove zanesljivosti spletnega mesta Liz Fong-Jones.

Spletno učenje juggernaut Coursera ponuja več tečajev, vključno s priljubljenim inženirstvom zanesljivosti spletnih mest: merjenje in upravljanje zanesljivosti iz storitve Google Cloud Training. Ta tečaj je na voljo tudi pri Pluralsightu, prav tako pa tudi začetni tečaj Site Reliability Engineering (SRE): Velika slika Eltona Stonemana. Linux Foundation ponuja samoupravni tečaj z naslovom DevOps in SRE Fundamentals: Implementing Continuous Delivery.

Združenje Jellyfish Training iz Združenega kraljestva ponuja različne dvodnevne možnosti zasebnega tečaja za SRE Foundation (SREF).

Preberite več o devopsu

  • Kaj je devops? Preoblikovanje razvoja programske opreme
  • 3 načini za začetek programa devops
  • Uvaja najboljše prakse: 5 metod, ki bi jih morali sprejeti
  • 15 KPI-jev za sledenje preobrazbe devops
  • Spremljanje aplikacij: kaj lahko devops naredi bolje
  • Kjer se inženiring zanesljivosti strani sreča z devops
  • 5 načel, kako postati skupna agilna ekipa devopsa
  • 3 koraki za uporabo agilnih metodologij v IT-operacijah
  • Kako lahko gibčne ekipe podpirajo obvladovanje incidentov
  • Kako dataops izboljšuje podatke, analitiko in strojno učenje
  • Uporaba devopsa v znanosti o podatkih in strojnem učenju
  • 7 vprašanj za prednostno razvrščanje zaostankov
$config[zx-auto] not found$config[zx-overlay] not found