Programavimas

Kas yra SRE? Gyvybiškai svarbus svetainės patikimumo inžinieriaus vaidmuo

Pasauliui keičiantis internetui, svetainių, debesijos programų ir debesų infrastruktūros patikimumas tapo svarbiu verslo būtinumu - pradedant e. Prekybos operacijomis, baigiant pasauliniais bankais ir baigiant paieškos sistemomis.

Pasikeitė būdas, kaip mes valdome sistemas ir jų darbo krūvius. Šiandien mes retai galvojame apie brangius, labai prisilietusius, našius serverius, tačiau pasirenkame prekių serverius, sujungtus per virtualizaciją, o paskirstyta programinės įrangos architektūra neleidžia serverių prastovoms sukelti prastovų. Dėmesys perėjo nuo aparatūros prie programinės įrangos apibrėžtos infrastruktūros ir nuo nenuoseklių bei linkusių į klaidas rankinių procesų prie nuoseklių, patikimų ir pakartotinų automatizuotų užduočių.

Svetainės patikimumo inžinerija yra praktika palaikyti tą programuojamą infrastruktūrą ir maksimaliai padidinti joje naudojamų darbo krūvių prieinamumą. Svetainės patikimumo inžinieriaus (SRE) pareigos kilo iš „Google“ salių, kurios tūkstantmečio pradžioje norėjo iš naujo apibrėžti programinės įrangos kūrėjų ir operacijų personalo santykius ir padėti jiems kartu kurti tvirtas, lanksčias sistemas su nuolatinis tobulinimas ir automatizavimas kaip pagrindiniai principai.

Kas yra SRE?

Pagrindiniame lygmenyje SRE pateikia programinės įrangos inžinerijos principus infrastruktūros ir operacijų problemoms spręsti, o šiaurės žvaigždės tikslas yra sukurti labai keičiamas ir patikimas sistemas.

„Iš esmės taip atsitinka, kai paprašote programinės įrangos inžinieriaus sukurti operacijos funkciją“, - dažnai cituojamas Benas Treynoras, „Google“ inžinerijos viceprezidentas ir SRE krikštatėvis.

Svarbiausias tarp SRE pareigų yra nustatyti paslaugų lygio slenksčius, kurie dažnai pasireiškia kaip paslaugų lygio tikslai (SLO), kurie padeda sužinoti, ar leidimas yra apšviestas. Šventasis gralis visada yra šventasis „penkių devynerių“ arba 99,999% veikimo laikas. Kuo geresnis veikimo laikas, tuo daugiau lynų kūrėjai gauna naujų įdomių dalykų ir daugiau miego SRE, o tai lemia abipusiai naudingą funkcijų ryšį, toli nuo senų kūrėjų dienų ir operacijų priešiškumo.

SRE funkcija paprastai bus vertinama pagal pagrindinių patikimumo metrikų rinkinį, būtent: sistemos našumą, prieinamumą, vėlavimą, efektyvumą, stebėjimą, pajėgumų planavimą ir reagavimą į avariją.

[Taip pat apie: Programos stebėjimas: ką gali geriau padaryti devopai]

Pagrindinės SRE darbo pareigos

Bet koks geras SRE bus ypač apsėstas vienu dalyku: automatika.

Kaip savo tinklaraščio įraše teigia programinės įrangos tiekėjo „New Relic“ stebėtojas SRE Jasonas Qualmanas: „Daug šio vaidmens tenka galvoti apie neefektyvius ir daug laiko reikalaujančius dalykus, kuriuos daro žmonės, ir kuo greičiau juos sustabdyti. Užuot spardžiusi skardinę rankinio darbo metu, jūs sakote: „Aš dabar skirsiu laiko tai automatizuoti ir sulaikysiu kitus, kad nereikėtų daryti šio skausmingo dalyko“.

Kitas svarbus SRE vaidmens elementas yra tai, kas vadinama „leidimų inžinerija“, apimanti geriausios praktikos apibrėžimą, siekiant užtikrinti programinės įrangos leidimų nuoseklumą ir pakartojamumą.

„Išleidimo inžinieriai turi tvirtą (jei ne ekspertų) supratimą apie šaltinio kodo valdymą, kompiliatorius, versijos konfigūravimo kalbas, automatizuotus kūrimo įrankius, paketų valdytojus ir montuotojus. Jų įgūdžių rinkinys apima gilias kelių sričių žinias: kūrimą, konfigūracijos valdymą, bandymų integravimą, sistemos administravimą ir klientų palaikymą “, - pagrindinei knygai parašė Dinah McNutt,„ Google “techninės programos vadovė. Patikimumo aikštelėje inžinerija (išleido O’Reilly 2016 m., autoriai - „Google“ darbuotojai Jennifer Petoff, Niall Richard Murphy, Chris Jones ir Betsy Beyer).

Tada yra atsakymo vaidmens dalis, apimanti įspėjimą, budėjimą ir trikčių šalinimą, taip pat reagavimą į avarijas ir įvykius bei mirusiuosius.

Iš esmės svarbu, kad SRE žinotų, kaip geriausiai stebėti sistemas ir reaguoti, kai kas nors blogai, nuolat rašydami ir perrašydami atsakymo vadovėlius, kad sutrumpintumėte laiką, kad pašalintumėte galimą gedimą. „Google“ tai reiškia dokumentuoti įvykį, suprasti visas pagrindines priežastis ir įgyvendinti būsimus prevencinius veiksmus.

„Postmortem rašymas nėra bausmė - tai yra mokymosi galimybė visai įmonei“, - „Google“ darbuotojai John Lunney ir Sue Lueder rašo Patikimumo aikštelėje inžinerija knyga.

[Taip pat apie: 3 judrių metodikų taikymą IT operacijose]

SRE ir devops inžinieriai

Aš žinau, ką tu galvoji. Visa tai skamba panašiai kaip „devops“, tačiau kalbant apie terminologiją, SRE pareigos iš tikrųjų yra ankstesnės, kaip „devops“ inžinierius.

Abi yra pagrįstos panašiais principais, tačiau skirtumas yra subtilus ir svarbus. Abu darbo būdai apima barjerų tarp kūrėjų ir eksploatavimo personalo panaikinimą, ir abiem jais siekiama padidinti kūrėjų komandų greitį išlaikant pagrindinį šių paslaugų atsparumą.

Pagrindinis skirtumas yra tas, kad „devops“ inžinieriai yra linkę sutelkti dėmesį į nuolatinį pristatymą ir kūrėjo greitį, o SRE prisiima atsakomybę už patikimumą ir automatizavimą per visą programinės įrangos gyvavimo ciklą, akcentuodami sėkmingą leidimų diegimą ir stebėjimą bei programinės įrangos apibrėžtos infrastruktūros dūzgimą. SRE turi neatsiejamą platesnės inžinerijos komandos funkciją: užtikrinti, kad prie stalo būtų specialisto vieta, orientuota į stabilių sistemų kūrimą.

Kaip teigia Jayne Groll iš „The Devops Institute“: „Devopsas sutelkia dėmesį į nuolatinį inžinerinį pristatymą iki dislokavimo vietos; SRE orientuojasi į nuolatines inžinerines operacijas klientų vartojimo taške. “

SRE istorija „Google“

SRE principų susiejimas su jų ištakomis „Google“ 2000-ųjų pradžioje suteikia pagrindinę dalyko pamoką disciplinoje.

„Kai atėjau į„ Google “, man pasisekė dalyvauti komandoje, kurią iš dalies sudarė žmonės, kurie buvo programinės įrangos inžinieriai ir kurie buvo linkę naudoti programinę įrangą kaip problemą, kuri istoriškai buvo išspręsta rankomis, spręsti. Taigi, kai atėjo laikas sukurti oficialią komandą, kuri atliktų šį operatyvinį darbą, buvo natūralu pasirinkti „viskas gali būti traktuojama kaip programinės įrangos problema“ ir paleisti su juo “, - interviu vidiniame„ Google “tinklaraštyje pareiškė Benas Treynoras.

„Taigi SRE iš esmės atlieka darbą, kurį istoriškai atliko operacijų komanda, tačiau pasitelkia inžinierius, turinčius programinės įrangos patirties ir bankininkystę, kad šie inžinieriai iš esmės yra linkę ir turi galimybę automatizuoti žmogaus darbą, “- priduria Treynor.

„Google“ taip pat gana griežtai galvoja, kaip suburti SRE komandą. Visi „Google SRE“ turi būti „Google“ programinės įrangos inžinieriai arba „kandidatai, kurie labai atitinka„ Google “programinės įrangos inžinerijos kvalifikaciją“. Jie taip pat turi turėti infrastruktūros valdymo įgūdžių, dažniausiai „Unix sistemos vidinių ir tinklų (nuo 1 iki 3 lygio žinių“).

SRE kvalifikacija vis dar skiriasi skirtingose ​​įmonėse, tačiau, kiek tai susiję su pagrindiniais principais, „Google“ metodas yra tvirtas atspirties taškas. Išsami informacija priklausys nuo verslo poreikių, nusistovėjusių procesų ir organizacijos jau priimtų technologijų.

SRE pareigybės aprašymas ir atlyginimas

SRE paprastai praleidžia apie 50 procentų savo laiko atliekant tradicines operacijų funkcijas, pavyzdžiui, budėjimą ir šokinėjimą, kad išspręstų problemas. Kiti 50 procentų yra skirti programinės įrangos kūrimui, kad pagrindinės sistemos laikui bėgant taptų atsparesnės, automatizuotesnės ir savaime išgydomos. Štai kodėl tam vaidmeniui reikia patikimo programinės įrangos inžinerijos ir operacijų įgūdžių derinio. Geras SRE bus organizuotas, kietas esant spaudimui ir problemų sprendimas. SRE vadovai yra atsakingi už komandos darbą, strategiją ir optimizavimą.

Bet ką daryti su organizacijomis, kuriose nėra SRE vaidmens? O’Reilly pranešime „Kas yra SRE?“ Kurtas Andersenas iš „LinkedIn“ ir Craigas Sebenikas iš „Split“ (leidimų valdymo programinės įrangos pardavėjas) rekomenduoja laikytis „vietinio“ požiūrio. Jie rekomenduoja surasti „kūrėjų komandą, kuri būtų motyvuota pakeisti ir įgyvendinti ten mažą SRE komandą (ar asmenį). Laikui bėgant tą sėkmę galite naudoti kaip teigiamą pavyzdį kitoms komandoms “.

Vidutinis metinis atlyginimas už SRE JAV yra maždaug 130 000 USD, o JK - 76 000 GBP, skelbiama darbo vietoje „Indeed“.

SRE ištekliai

Išteklių SRE įgūdžiams kaupti yra daug, pradedant „DevOps“ instituto sertifikatais, baigiant knygomis ir internetiniais šaltiniais iš „O’Reilly“, „Microsoft“ ir „Google“. Minėtas 550 puslapių begemotasPatikimumo aikštelėje inžinerija Jennifer Petoff, Niall Richard Murphy, Chris Jones ir Betsy Beyer yra šios temos pagrindas, paskelbtas 2016 m. Knygą taip pat galima nemokamai atsisiųsti iš „Google“.

Kitos naujesnės knygos šia tema yraMokymo vietos patikimumo inžinieriai pateikė Jennifer Petoff, JC van Winkel ir Preston Yoshioka;Kas yra SRE? Kurto Anderseno ir Craigo Sebeniko;Ieškau SREpateikė Davidas N. Blankas-Edelmanas irPatikimumo svetainėje darbaknygė Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara ir Stephen Thorne.

„O’Reilly“ taip pat turi išsamią internetinių išteklių, vaizdo įrašų ir el. Knygų apie šią temą biblioteką, kurią šiame „SRE Essentials“ grojaraštyje patogiai kuruoja buvusi „Google“ svetainių patikimumo inžinierė Liz Fong-Jones.

Internetinis mokymasis „Juggernaut Coursera“ siūlo keletą kursų, įskaitant populiarią svetainių patikimumo inžineriją: patikimumo matavimas ir valdymas naudojant „Google Cloud Training“. Šį kursą taip pat galima įsigyti „Pluralsight“, taip pat pradedančiųjų kursą „Svetainės patikimumo inžinerija (SRE): Eltono Stonemano didelis paveikslas“. „Linux Foundation“ siūlo savarankišką kursą „DevOps and SRE Fundamentals: Implementing Continuous Delivery“.

JK įsikūrę „Medūzų mokymai“ siūlo įvairias dviejų dienų privačių mokymo kursų galimybes SRE fondui (SREF).

Skaitykite daugiau apie „devops“

  • Kas yra devops? Programinės įrangos kūrimo transformavimas
  • 3 būdai, kaip paleisti „devops“ programą
  • Geriausia praktika: 5 metodai, kuriuos turėtumėte pritaikyti
  • 15 KPI sekti transformacijų transformacijas
  • Programos stebėjimas: ką „devops“ gali padaryti geriau
  • Vietos patikimumo inžinerija susitinka su devopais
  • 5 principai, kaip tapti judrios „devops“ komandos bendradarbiavimu
  • 3 žingsniai taikant judrią metodiką IT operacijose
  • Kaip judrios komandos gali palaikyti incidentų valdymą
  • Kaip duomenų rinkiniai pagerina duomenis, analizę ir mašininį mokymąsi
  • „Devops“ taikymas duomenų moksle ir mašininiame mokyme
  • 7 klausimai, pagal kuriuos pirmenybė teikiama „devops“ atsilikimams
$config[zx-auto] not found$config[zx-overlay] not found