Programmēšana

Kas ir SRE? Vietnes uzticamības inženiera būtiskā loma

Kad pasaule ir mainījusies tiešsaistē, vietņu, mākoņu lietojumprogrammu un mākoņu infrastruktūras uzticamība ir kļuvusi par būtisku uzņēmējdarbības prasību - sākot no e-komercijas operācijām līdz globālām bankām līdz meklētājprogrammām.

Ir mainījies veids, kā mēs pārvaldām sistēmas un to slodzi. Šodien mēs reti domājam par dārgiem, pieskārieniem un augstas veiktspējas serveriem, bet tā vietā tiek pakļauti preču serveri, kas tiek apvienoti, izmantojot virtualizāciju, ar sadalītu programmatūras arhitektūru, kas novērš serveru darbības pārtraukumus, kas izraisa dīkstāvi. Uzmanība ir pārcelta no aparatūras uz programmatūras definētu infrastruktūru un no nekonsekventiem un kļūdām raksturīgiem manuāliem procesiem uz konsekventiem, uzticamiem un atkārtojamiem automatizētiem uzdevumiem.

Vietnes uzticamības inženierija ir šīs programmējamās infrastruktūras uzturēšanas prakse un maksimāla tajā darbināmo slodžu pieejamība. Vietnes uzticamības inženiera (SRE) amata nosaukums radies Google zālēs, kas tūkstošgades mijā vēlējās no jauna definēt attiecības starp programmatūras izstrādātājiem un operāciju personālu - un palīdzēt viņiem strādāt kopā, lai izveidotu izturīgas, elastīgas sistēmas ar pastāvīga uzlabošana un automatizācija kā pamatprincipi.

Kas ir SRE?

Bāzes līmenī SRE iekļauj programmatūras inženierijas principus infrastruktūras un darbības problēmās, un ziemeļu zvaigznes mērķis ir izveidot ļoti mērogojamas un uzticamas sistēmas.

"Būtībā tas notiek, kad jūs lūdzat programmatūras inženierim izstrādāt operācijas funkciju," kā bieži citē Bens Treinors, Google inženierzinātņu viceprezidents un SRE krusttēvs.

Galvenais starp SRE pienākumiem ir noteikt pakalpojumu līmeņa sliekšņus, kas bieži izpaužas kā pakalpojumu līmeņa mērķi (SLO), kas palīdz informēt, vai izlaidums tiek izgaismots. Svētais grāls vienmēr ir svētais ‘pieci deviņi’ jeb 99,999% darbības laiks. Jo labāks darbspējas laiks, jo vairāk virvju izstrādātājiem ir iespēja sākt jaunu foršu lietošanu un jo vairāk miega SRE saņem, kas noved pie abpusēji izdevīgām attiecībām starp funkcijām, kas ir tālu no vecajiem izstrādātāja laikiem un operāciju antagonisma.

SRE funkciju parasti mēra, izmantojot galveno uzticamības metriku kopumu, proti: sistēmas veiktspēju, pieejamību, latentumu, efektivitāti, uzraudzību, jaudas plānošanu un reaģēšanu ārkārtas situācijās.

[Arī par: Lietojumprogrammu uzraudzība: ko devops var darīt labāk]

Galvenie SRE darba pienākumi

Jebkurš labs SRE būs apsēsts ar vienu lietu: automatizāciju.

Kā bloga ierakstā apgalvo programmatūras pārdevēja New Relic novērošanas SRE Džeisons Kvalmans: “Liela daļa šīs lomas ir domāt par neefektīvām un laikietilpīgām lietām, ko cilvēki dara, un pēc iespējas ātrāk tām pielikt punktu. Tā vietā, lai spiestu bundžu pa roku darbu, jūs sakāt: "Es izmantošu laiku, lai to automatizētu tieši tagad un nevienam citam vairs nevajadzētu darīt šo sāpīgo lietu." "

Vēl viens svarīgs SRE lomas elements ir kaut kas, ko sauc par “izlaišanas inženieriju”, kas ietver labākās prakses noteikšanu, lai nodrošinātu programmatūras izlaidumu konsekvenci un atkārtojamību.

“Izlaiduma inženieriem ir laba (ja ne ekspertu) izpratne par pirmkodu pārvaldību, kompilatoriem, būvēšanas konfigurācijas valodām, automatizētiem būvēšanas rīkiem, pakotņu pārvaldniekiem un instalētājiem. Viņu prasmju kopums ietver dziļas zināšanas par vairākām jomām: izstrādi, konfigurācijas pārvaldību, testu integrāciju, sistēmas administrēšanu un klientu atbalstu, ”pamatrakstam raksta Dinah McNutt, Google tehnisko programmu vadītāja. Vietnes uzticamības inženierija (publicēja O’Reilly 2016. gadā un autori: Google darbinieki Jennifer Petoff, Niall Richard Murphy, Chris Jones un Betsy Beyer).

Tad ir lomas atbildes daļa, kas ietver trauksmi, dežūru un problēmu novēršanu, kā arī reaģēšanu ārkārtas situācijās un incidentos un pēcnāves gadījumus.

Būtībā ir svarīgi, lai SRE zinātu, kā vislabāk uzraudzīt sistēmas un reaģēt, ja kaut kas noiet greizi, pastāvīgi rakstot un pārrakstot atbildes playbookus, lai samazinātu laiku, lai novērstu iespējamo traucējumu. Uzņēmumā Google tas ir saistīts ar incidenta dokumentēšanu, visu cēloņu izpratni un turpmāko preventīvo darbību īstenošanu.

"Pēcnāves rakstīšana nav sods - tā ir mācību iespēja visam uzņēmumam," raksta Google darbinieki Džons Lunnijs un Sjū Lueders. Vietnes uzticamības inženierija grāmata.

[Arī par: 3 soļi veiklu metodiku pielietošanai IT operācijās]

SRE un devops inženieri

Es zinu, ko tu domā. Tas viss izklausās daudz kā devops, bet, runājot par terminoloģiju, SRE amata nosaukums faktiski ir devops inženiera inženieri par aptuveni pieciem gadiem.

Abi ir balstīti uz līdzīgiem principiem, taču atšķirība ir gan smalka, gan svarīga. Abi darba veidi ietver šķēršļu nojaukšanu starp izstrādātājiem un operatīvajiem darbiniekiem, un abu mērķis ir palielināt izstrādātāju komandu ātrumu, vienlaikus saglabājot šo pakalpojumu galveno elastību.

Galvenā atšķirība ir tā, ka devops inženieri mēdz koncentrēties uz nepārtrauktas piegādes un izstrādātāja ātruma atbalstīšanu, savukārt SRE uzņemas atbildību par uzticamību un automatizāciju visā programmatūras dzīves ciklā, galveno uzmanību pievēršot izlaidumu veiksmīgai izvietošanai un uzraudzībai un programmatūras noteiktas infrastruktūras dungošanas uzturēšanai. SRE ir neatņemama funkcija plašākā inženieru komandā: nodrošinot, ka pie galda ir speciālista vieta, kas vērsta uz stabilu sistēmu izveidi.

Kā saka Džeina Grola no The Devops Institute: “Devops koncentrējas uz nepārtrauktu inženiertehnisko piegādi līdz izvietošanas vietai; SRE koncentrējas uz nepārtrauktu inženiertehnisko darbību klientu patēriņa vietā. ”

SRE vēsture Google

SRE principu izsekošana līdz to izcelsmei Google 2000. gadu sākumā nodrošina galveno objektu mācību disciplīnā.

“Kad es nonācu Google tīklā, man bija paveicies piedalīties komandā, kuru daļēji veidoja cilvēki, kuri bija programmatūras inženieri un kuri bija tendēti izmantot programmatūru kā problēmu risināšanas veidu, kas vēsturiski tika atrisināts ar roku. Tāpēc, kad bija pienācis laiks izveidot oficiālu komandu šī operatīvā darba veikšanai, bija dabiski izvēlēties pieeju “visu var uzskatīt par programmatūras problēmu” un palaist to kopā, ”Bens Treinors paziņoja intervijā Google iekšējā emuārā.

"Tātad SRE principā veic darbu, ko vēsturiski ir veikusi operāciju komanda, taču izmanto inženierus ar programmatūras lietpratību un banku darbību par to, ka šie inženieri pēc savas būtības ir gan noskaņoti, gan spējīgi aizstāt automatizāciju cilvēku darbā, ”Piebilst Treynor.

Google arī diezgan stingri domā par to, kā salikt SRE komandu. Visiem Google SRE jābūt vai nu Google programmatūras inženieriem, vai arī “kandidātiem, kuriem ir ļoti tuva Google programmatūras inženierijas kvalifikācija”. Viņiem jābūt arī infrastruktūras pārvaldības prasmēm, visbiežāk “Unix sistēmas iekšējām un tīkla (no 1. līdz 3. slānim) zināšanām”.

Dažādos uzņēmumos SRE kvalifikācija joprojām mēdz atšķirties, taču, ciktāl tas attiecas uz pamatprincipiem, Google pieeja ir drošs sākumpunkts. Sīkāka informācija būs atkarīga no biznesa vajadzībām, izveidotajiem procesiem un tehnoloģiju kaudzes, kuru organizācija jau ir pieņēmusi.

SRE amata apraksts un alga

Parasti SRE tērē apmēram 50 procentus sava laika, veicot tradicionālās darbības funkcijas, piemēram, atrodoties izsaukumā un ielecot problēmu risināšanai. Pārējie 50 procenti ir vērsti uz programmatūras izstrādi, lai pamatā esošās sistēmas laika gaitā padarītu elastīgākas, automatizētākas un pašdziedinošākas. Tāpēc šai lomai ir nepieciešams stingrs programmatūras inženierijas kopu un operāciju prasmju apvienojums. Tiks organizēts labs SRE, atdzesēts zem spiediena un problēmu risinātājs. SRE vadītāji ir atbildīgi par komandas sniegumu, stratēģiju un optimizāciju.

Bet kā ar organizācijām, kur SRE loma nepastāv? O’Reilly ziņojumā “Kas ir SRE?” Kurts Andersens no LinkedIn un Kreigs Sebeniks no Splitas (laidienu pārvaldības programmatūras pārdevējs) iesaka izmantot “vietējo” pieeju. Viņi iesaka atrast “attīstības komandu, kas ir motivēta mainīt un ieviest tur nelielu SRE komandu (vai individuālu). Laika gaitā jūs varat izmantot šos panākumus kā pozitīvu piemēru citām komandām. ”

Saskaņā ar darba vietu Indeed vidējā SRE gada alga ir aptuveni 130 000 ASV dolāru ASV un 76 000 mārciņu Lielbritānijā.

SRE resursi

Resursu SRE prasmju veidošanai ir daudz, sākot no DevOps institūta sertifikātiem līdz grāmatām un tiešsaistes resursiem no O’Reilly, Microsoft un Google. Iepriekš minētais 550 lappušu behemotsVietnes uzticamības inženierija autori Dženifera Petofa, Niall Ričards Mērfijs, Kriss Džonss un Betsija Beijere ir tēmas sākumposms, kas publicēts 2016. gadā. Grāmata ir pieejama arī bez maksas tiešsaistē no Google.

Citas jaunākas grāmatas par šo tēmu ietverApmācības vietas uzticamības inženieri Dženifera Petofa, Dž. Van Vinkels un Prestons Joshioka;Kas ir SRE? autori Kurts Andersens un Kreigs Sebeniks;Meklēju SREautors Deivids N. Blanks-Edelmans unVietnes uzticamības darbgrāmata autori Betsija Beijere, Niall Ričards Mērfijs, Deivids K. Rensins, Kents Kavahara un Stīvens Torns.

O’Reilly rīcībā ir arī visaptveroša tiešsaistes aktīvu, videoklipu un e-grāmatu bibliotēka par šo tēmu, kuru šajā SRE Essentials atskaņošanas sarakstā ir ērti sastādījis bijušais Google vietņu uzticamības inženieris Liz Fong-Jones.

Tiešsaistes mācību juggernaut Coursera piedāvā vairākus kursus, tostarp populāro vietņu uzticamības inženieriju: Uzticamības mērīšana un pārvaldība no Google Cloud Training Šis kurss ir pieejams arī vietnē Pluralsight, tāpat kā iesācēju kurss Vietnes uzticamības inženierija (SRE): Eltona Stounemana lielais attēls. Linux fonds piedāvā pašu vadītu kursu ar nosaukumu DevOps un SRE Fundamentals: Implementing Continuous Delivery.

Lielbritānijā bāzētā medūzu apmācība piedāvā dažādas divu dienu privāto apmācību kursu iespējas SRE fondam (SREF).

Lasiet vairāk par devops

  • Kas ir devops? Programmatūras izstrādes pārveidošana
  • 3 veidi, kā sākt devops programmu
  • Izmanto paraugpraksi: 5 metodes, kas jums jāpieņem
  • 15 KPI, lai izsekotu devops transformācijai
  • Lietojumprogrammas uzraudzība: ko devops var darīt labāk
  • Vietas uzticamības inženierija satiekas ar devopiem
  • Pieci principi, kā kļūt par sadarbības veiklu devops komandu
  • 3 soļi veiklu metodiku pielietošanai IT operācijās
  • Kā veiklas komandas var atbalstīt incidentu pārvaldību
  • Kā datu kopas uzlabo datus, analīzi un mašīnmācīšanos
  • Devops pielietošana datu zinātnē un mašīnmācībā
  • 7 jautājumi, lai noteiktu prioritāti jūsu devops uzkrājumam
$config[zx-auto] not found$config[zx-overlay] not found