Co je SRE? Zásadní role inženýra spolehlivosti webu

Jak se svět přesunul online, spolehlivost webů, cloudových aplikací a cloudové infrastruktury se stala zásadním obchodním imperativem - od operací elektronického obchodování přes globální banky až po vyhledávače.

Způsob, jakým spravujeme systémy a jejich pracovní vytížení, se změnil. Dnes málokdy myslíme na vzácné, vysoce dotykové a vysoce výkonné servery, ale místo toho stojíme na stojanu komoditních serverů, které se sdružují prostřednictvím virtualizace, přičemž distribuovaná softwarová architektura brání výpadkům serveru způsobovat výpadky. Důraz se přesunul z hardwaru na softwarově definovanou infrastrukturu a z nekonzistentních manuálních procesů náchylných k chybám na konzistentní, spolehlivé a opakovatelné automatizované úkoly.

Inženýrství spolehlivosti webu je praxe udržování programovatelné infrastruktury a maximalizace dostupnosti úloh, které na ní běží. Název pracovní pozice inženýra spolehlivosti stránek (SRE) vznikl v halách společnosti Google, která na přelomu tisíciletí chtěla předefinovat vztah mezi vývojáři softwaru a provozním personálem - a pomoci jim spolupracovat na vybudování robustních a flexibilních systémů s neustálé zlepšování a automatizace jako základní principy.

Co je SRE?

Na základní úrovni přinášejí SRE principy softwarového inženýrství problémům s infrastrukturou a provozem, s cílem polární hvězdy vytvořit vysoce škálovatelné a spolehlivé systémy.

„Zásadně se to stane, když požádáte softwarového inženýra, aby navrhl provozní funkci,“ často se uvádí Ben Treynor, viceprezident pro inženýrství ve společnosti Google a kmotr SRE.

Hlavním úkolem SRE je stanovení prahových hodnot úrovně služeb, které se často projevují jako cíle na úrovni služeb (SLO), které pomáhají informovat o tom, zda bude vydání vydáno zeleně. Svatý grál je vždy posvěcenou „pěticí devíti“ neboli 99,999% provozuschopnosti. Čím lepší je doba provozuschopnosti, tím více vývojářů provazů začne spouštět skvělé nové věci a tím více spánkových SRE, což povede ke vzájemně výhodnému vztahu mezi funkcemi, daleko od starých časů vývojářského a provozního antagonismu.

Funkce SRE se obvykle měří na souboru klíčových metrik spolehlivosti, a to: výkon systému, dostupnost, latence, účinnost, monitorování, plánování kapacity a reakce na mimořádné události.

[Také na: Monitorování aplikací: Co může devops udělat lépe]

Klíčové pracovní povinnosti SRE

Každá dobrá SRE bude posedlá zejména jednou věcí: automatizací.

Jak uvádí Jason Qualman, odborník na monitorování dodavatelů softwaru New Relic, v příspěvku na blogu: „Mnoho z této role přemýšlí o neefektivních a časově náročných věcech, které lidé dělají, a co nejdříve je zastavit. Místo toho, abyste kopali plechovku po silnici ruční prací, říkáte: „Budu si teď dělat čas, abych to automatizoval a zabránil komukoli jinému, aby musel dělat tuto bolestnou věc.“ “

Dalším klíčovým prvkem role SRE je něco, čemu se říká „release engineering“, což zahrnuje definování osvědčených postupů, které zajistí konzistentní a opakovatelné verze softwaru.

„Inženýři vydání mají důkladné (ne-li odborné) znalosti správy zdrojových kódů, překladačů, konfiguračních jazyků sestavení, automatických nástrojů pro sestavování, správců balíčků a instalačních programů. Jejich sada dovedností zahrnuje hlubokou znalost více domén: vývoj, správu konfigurace, integraci testů, správu systému a zákaznickou podporu, “napsal Dinah McNutt, technický programový manažer společnosti Google, k původní knize Engineering spolehlivosti stránek (vydané O’Reilly v roce 2016 a jejichž autory jsou zaměstnanci společnosti Google Jennifer Petoff, Niall Richard Murphy, Chris Jones a Betsy Beyer).

Pak je tu role role odezvy, která zahrnuje varování, pohotovostní službu a řešení problémů, spolu s reakcí na mimořádné události a mimořádné události a posmrtné zprávy.

V zásadě je důležité, aby SRE věděli, jak nejlépe monitorovat systémy a reagovat, když se něco pokazí, neustále psát a přepisovat příručky s reakcemi, aby se zkrátila doba potřebná k vyřešení případných poruch. Ve společnosti Google to zahrnuje dokumentaci incidentu, pochopení všech hlavních příčin a implementaci budoucích preventivních akcí.

„Psaní posmrtného není trest - je to příležitost k učení pro celou společnost,“ píší zaměstnanci Googlu John Lunney a Sue Lueder v příspěvku kapitoly Engineering spolehlivosti stránek rezervovat.

[Také k: 3 kroky k použití agilních metodik v provozu IT]

Inženýři SRE vs. Devops

Vím, na co myslíš. To vše zní hodně jako devops, ale pokud jde o terminologii, název pracovní pozice SRE ve skutečnosti antedatuje devops engineer asi o pět let.

Oba jsou založeny na podobných principech, ale rozdíl je jemný i důležitý. Oba způsoby práce zahrnují prolomení bariér mezi vývojáři a provozním personálem a oba mají za cíl zvýšit rychlost vývojářských týmů při zachování základní odolnosti těchto služeb.

Klíčový rozdíl spočívá v tom, že vývojoví inženýři mají tendenci soustředit se na podporu nepřetržitého doručování a rychlosti vývojářů, zatímco SRE přebírají odpovědnost za spolehlivost a automatizaci během celého životního cyklu softwaru, s důrazem na úspěšné nasazení a monitorování verzí a udržování softwarově definované infrastruktury bzučení. SRE má nedílnou funkci v širším inženýrském týmu: zajistit u stolu místo specialisty zaměřeného na budování stabilních systémů.

Jak říká Jayne Groll z The Devops Institute: „Devops se zaměřuje na inženýrské kontinuální dodávky až do bodu nasazení; SRE se zaměřuje na inženýrství nepřetržitého provozu v místě spotřeby zákazníka. “

Historie SRE ve společnosti Google

Sledování principů SRE zpět k jejich původu ve společnosti Google počátkem roku 2000 poskytuje klíčovou lekci v oboru.

"Když jsem přišel na Google, měl jsem to štěstí, že jsem byl součástí týmu, který byl částečně složen z lidí, kteří byli softwarovými inženýry a kteří měli sklon používat software jako způsob řešení problémů, které byly historicky vyřešeny ručně." Takže když nastal čas vytvořit formální tým, který by tuto operativní práci provedl, bylo přirozené přijmout přístup „vše lze považovat za softwarový problém“ a běžet s ním, “uvedl Ben Treynor v rozhovoru na interním blogu Google.

"SRE tedy zásadně dělá práci, kterou historicky provedl operační tým, ale využívá inženýry se softwarovými znalostmi a bankovnictví na tom, že tito inženýři jsou ze své podstaty předisponováni a mají schopnost nahradit automatizaci za lidskou práci," “Dodává Treynor.

Google také docela rigidně uvažuje o tom, jak sestavit tým SRE. Všechny SRE společnosti Google musí být buď softwaroví inženýři společnosti Google, nebo „kandidáti, kteří mají velmi blízko kvalifikaci Google Software Engineering.“ Musí také mít dovednosti v oblasti správy infrastruktury, nejčastěji „interní systémy Unix a síťové znalosti (vrstva 1 až vrstva 3).“

Kvalifikace SRE se stále liší od společnosti k společnosti, ale pokud jde o základní principy, přístup Google je dobrým výchozím bodem. Podrobnosti budou záviset na obchodních potřebách, zavedených procesech a technologickém zásobníku, který již organizace přijala.

SRE popis práce a plat

SRE obvykle stráví asi 50 procent svého času prováděním tradičních provozních funkcí, jako je volání a vyskočení k vyřešení problémů. Dalších 50 procent se zaměřuje na vývoj softwaru, aby byly základní systémy odolnější, automatizovanější a samoléčivé v průběhu času. To je důvod, proč tato role vyžaduje solidní kombinaci sekcí softwarového inženýrství a operačních dovedností. Dobrá SRE bude organizovaná, chladná pod tlakem a řeší problémy. Manažeři SRE jsou zodpovědní za výkon týmu, strategii a optimalizaci.

Ale co organizace, kde role SRE neexistuje? Ve zprávě O’Reilly „Co je SRE?“ Kurt Andersen z LinkedIn a Craig Sebenik ze Splitu (prodejce softwaru pro správu verzí) doporučují zaujmout „místní“ přístup. Doporučují najít „vývojový tým, který je motivován ke změně a implementaci malého týmu SRE (nebo jednotlivce). Postupem času můžete tento úspěch použít jako pozitivní příklad pro ostatní týmy. “

Průměrný roční plat za SRE je zhruba 130 000 USD v USA a 76 000 GBP ve Velké Británii, podle údajů na pracovišti Indeed.

Zdroje SRE

Zdrojů je dostatek k budování dovedností SRE, od certifikací od DevOps Institute po knihy a online zdroje od O’Reilly, Microsoftu a Google. Výše zmíněný 550stránkový monstrumEngineering spolehlivosti stránek autorky Jennifer Petoff, Niall Richard Murphy, Chris Jones a Betsy Beyer jsou tématem, které vyšlo v roce 2016. Kniha je k dispozici také zdarma online na Googlu.

Mezi další novější knihy na toto téma patříŠkolení techniků spolehlivosti stránek autorky Jennifer Petoff, JC van Winkel a Preston Yoshioka;Co je SRE? Kurt Andersen a Craig Sebenik;Hledám SREpředložil David N. Blank-Edelman aSešit spolehlivosti stránek autorů: Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara a Stephen Thorne.

O’Reilly má také komplexní knihovnu online aktiv, videí a e-knih na toto téma, které jsou snadno sestaveny v tomto seznamu skladeb SRE Essentials bývalou inženýrkou spolehlivosti webů Google Liz Fong-Jones.

Online výukový juggernaut Coursera nabízí několik kurzů, včetně populárního Engineeringu pro spolehlivost stránek: Měření a správa spolehlivosti z Google Cloud Training. Tento kurz je k dispozici také na webu Pluralsight, stejně jako kurz pro začátečníky Site Reliability Engineering (SRE): The Big Picture od Eltona Stonemana. Linux Foundation nabízí samoobslužný kurz s názvem DevOps a SRE Fundamentals: Implementing Continuous Delivery.

Výcvik medúzy se sídlem ve Velké Británii nabízí různé možnosti dvoudenního soukromého školení pro SRE Foundation (SREF).