Programovanie

Čo je SRE? Zásadná úloha inžiniera spoľahlivosti stránok

Keď sa svet posunul online, spoľahlivosť webových stránok, cloudových aplikácií a cloudovej infraštruktúry sa stala kritickým obchodným imperatívom - od operácií elektronického obchodu cez globálne banky až po vyhľadávače.

Zmenil sa spôsob, akým riadime systémy a ich pracovné zaťaženie. Dnes už málokedy myslíme na vzácne, vysoko dotykové a vysoko výkonné servery, ale namiesto toho sa stojíme na stojane komoditných serverov združených prostredníctvom virtualizácie, pričom distribuovaná softvérová architektúra zabraňuje výpadkom serverov spôsobovať výpadky. Ťažisko sa presunulo z hardvéru na softvérovo definovanú infraštruktúru a z nekonzistentných manuálnych procesov náchylných na chyby na konzistentné, spoľahlivé a opakovateľné automatizované úlohy.

Inžinierstvo spoľahlivosti stránok je prax udržiavania programovateľnej infraštruktúry a maximalizácie dostupnosti pracovných záťaží, ktoré na nej bežia. Názov pracovnej pozície inžiniera spoľahlivosti stránok (SRE) vznikol v halách spoločnosti Google, ktorá na prelome tisícročí chcela predefinovať vzťah medzi vývojármi softvéru a prevádzkovým personálom - a pomôcť im spolupracovať pri vytváraní stabilných a flexibilných systémov s: neustále zlepšovanie a automatizácia ako základné princípy.

Čo je SRE?

Na základnej úrovni prinášajú SRE princípy softvérového inžinierstva do problémov s infraštruktúrou a prevádzkou, s cieľom severnej hviezdy vytvoriť vysoko škálovateľné a spoľahlivé systémy.

„V zásade je to, čo sa stane, keď požiadate softvérového inžiniera o návrh prevádzkovej funkcie,“ ako sa často hovorí o Ben Treynorovi, viceprezidentovi inžinierstva spoločnosti Google a kmotrovi SRE.

Medzi zodpovednosťami SRE patrí predovšetkým stanovenie prahových úrovní služieb, ktoré sa často prejavujú ako ciele na úrovni služieb (SLO), ktoré pomáhajú informovať o tom, či sa vydanie dostane do zelenej farby. Svätý grál je vždy posvätnou „piatou deviatkou“ alebo 99,999% dobou prevádzkyschopnosti. Čím lepšia je doba prevádzkyschopnosti, tým viac vývojárov povrazov začína uvádzať na trh nové veci a tým viac spánkových SRE, čo vedie k vzájomne výhodnému vzťahu medzi funkciami, ďaleko od starých čias vývojárov a antagonizmu operácií.

Funkcia SRE sa bude zvyčajne merať na základe súboru kľúčových metrík spoľahlivosti, a to: výkon systému, dostupnosť, latencia, účinnosť, monitorovanie, plánovanie kapacity a núdzová reakcia.

[Tiež na: Monitorovanie aplikácií: Čo môže devops urobiť lepšie]

Kľúčové pracovné povinnosti SRE

Každá dobrá SRE bude posadnutá najmä jednou vecou: automatizáciou.

Ako v príspevku na blogu uvádza Jason Qualman, pracovník SRE v oblasti monitorovania dodávateľa softvéru New Relic: „Mnoho z tejto úlohy premýšľa o neefektívnych a časovo náročných veciach, ktoré ľudia robia, a čo najskôr ich zastaviť. Namiesto toho, aby ste kopali plechovku po ceste manuálnej práce, hovoríte: „Teraz si dám čas na automatizáciu a zabránim komukoľvek inému, aby urobil túto bolestivú vec.“ “

Ďalším kľúčovým prvkom úlohy SRE je niečo, čo sa nazýva „release engineering“, čo zahŕňa definovanie najlepších postupov na zabezpečenie konzistentnosti a opakovateľnosti vydaní softvéru.

„Inžinieri vydania majú dôkladné (ak nie odborné) znalosti správy zdrojových kódov, kompilátorov, konfiguračných jazykov zostavovania, automatických nástrojov na zostavovanie, správcov balíkov a inštalátorov. Ich sada zručností zahŕňa hlboké znalosti viacerých domén: vývoj, správa konfigurácie, integrácia testov, správa systému a podpora zákazníkov, “napísala k hlavnej knihe Dinah McNutt, manažérka technického programu spoločnosti Google. Inžinierstvo spoľahlivosti stránok (publikovali O’Reilly v roku 2016 a autormi sú zamestnanci spoločnosti Google Jennifer Petoff, Niall Richard Murphy, Chris Jones a Betsy Beyer).

Potom je tu rola reakcie, ktorá zahŕňa výstrahu, pohotovostnú službu a riešenie problémov spolu s reakciou na núdzové situácie a mimoriadne udalosti a posmrtné správy.

V podstate je dôležité, aby SRE vedeli, ako najlepšie monitorovať systémy a reagovať, keď sa niečo pokazí, neustále písanie a prepisovanie príručiek odpovedí, aby sa tak skrátil čas na odstránenie prípadného poruchy. V spoločnosti Google to zahŕňa zdokumentovanie incidentu, pochopenie všetkých hlavných príčin a implementácia budúcich preventívnych opatrení.

„Písanie posmrtného života nie je trestom - je to vzdelávacia príležitosť pre celú spoločnosť,“ píšu zamestnanci spoločnosti Google John Lunney a Sue Lueder v prispievajúcej kapitole Inžinierstvo spoľahlivosti stránok kniha.

[Tiež k: 3 kroky k použitiu svižných metodík v operáciách IT]

Inžinieri SRE vs. Devops

Viem, na čo myslíš. To všetko znie dosť ako devops, ale pokiaľ ide o terminológiu, pracovná pozícia SRE v skutočnosti predchádza vývojovému pracovníkovi devops asi o päť rokov.

Obidve sú založené na podobných princípoch, rozdiel je však jemný a dôležitý. Oba spôsoby práce zahŕňajú búranie bariér medzi vývojármi a prevádzkovým personálom a obidva sa zameriavajú na zvýšenie rýchlosti vývojárskych tímov pri zachovaní základnej odolnosti týchto služieb.

Kľúčový rozdiel je v tom, že vývojoví inžinieri majú tendenciu zameriavať sa na podporu nepretržitého doručovania a rýchlosti vývojárov, zatiaľ čo SRE preberajú zodpovednosť za spoľahlivosť a automatizáciu počas celého životného cyklu softvéru s dôrazom na úspešné nasadenie a monitorovanie vydaní a udržanie bzučania softvérovo definovanej infraštruktúry. SRE má neoddeliteľnú funkciu v širšom inžinierskom tíme: zaistenie miesta špecialistu pri stole zameraného na budovanie stabilných systémov.

Ako hovorí Jayne Groll z The Devops Institute: „Devops sa zameriava na inžinierske kontinuálne dodávky až do bodu nasadenia; SRE sa zameriava na inžiniering nepretržitej prevádzky v mieste spotreby zákazníka. “

História SRE v Google

Sledovanie princípov SRE späť k ich pôvodu v spoločnosti Google na začiatku 2000-tych rokov predstavuje zásadné ponaučenie v tejto disciplíne.

„Keď som prišiel do spoločnosti Google, mal som to šťastie, že som bol súčasťou tímu, ktorý sa čiastočne skladal z ľudí, ktorí boli softvérovými inžiniermi a mali sklon používať softvér ako spôsob riešenia problémov, ktoré sa historicky riešili ručne. Takže keď bolo načase vytvoriť formálny tím, ktorý by vykonal túto operačnú prácu, bolo prirodzené zvoliť prístup „so všetkým sa dá zaobchádzať ako so softvérovým problémom“ a bežať s ním, “uviedol Ben Treynor v rozhovore pre interný blog spoločnosti Google.

„SRE teda zásadne vykonáva prácu, ktorú historicky vykonával operačný tím, ale využíva inžinierov so softvérovými znalosťami a bankovníctvo na tom, že títo inžinieri sú vo svojej podstate predisponovaní a sú schopní nahradiť automatizáciu ľudskou prácou, ”Dodáva Treynor.

Google tiež dosť rigidne uvažuje o tom, ako zostaviť tím SRE. Všetky štandardy SRE spoločnosti Google musia byť buď softvéroví inžinieri spoločnosti Google, alebo „kandidáti, ktorí majú veľmi blízko k kvalifikácii spoločnosti Google Software Engineering.“ Musia tiež mať zručnosti v oblasti správy infraštruktúry, najčastejšie „interné systémy systému Unix a odborné znalosti v oblasti sietí (vrstva 1 až vrstva 3).“

Kvalifikácia SRE sa stále líši od spoločnosti k spoločnosti, ale pokiaľ ide o základné princípy, prístup Google je dobrým východiskovým bodom. Podrobnosti budú závisieť od obchodných potrieb, zavedených procesov a technologického radu, ktorý už organizácia prijala.

SRE náplň práce a plat

SRE zvyčajne trávia asi 50 percent času vykonávaním tradičných operačných funkcií, ako je napríklad telefonovanie a vyskočenie na vyriešenie problému. Zvyšných 50 percent sa zameriava na vývoj softvéru, vďaka ktorému budú základné systémy v priebehu času odolnejšie, automatizovanejšie a samoliečiteľnejšie. Preto si táto rola vyžaduje solídnu kombináciu programového vybavenia a prevádzkových schopností. Dobré SRE bude zorganizované, chladné pod tlakom a riešenie problémov. Manažéri SRE sú zodpovední za výkon tímu, stratégiu a optimalizáciu.

Čo však s organizáciami, kde rola SRE neexistuje? V správe pána O’Reillyho „Čo je SRE?“ Kurt Andersen z LinkedIn a Craig Sebenik zo Splitu (predajca softvéru na správu vydaní) odporúčajú zvoliť „ľudový“ prístup. Odporúčajú nájsť „vývojový tím, ktorý je motivovaný zmeniť a implementovať malý tím SRE (alebo jednotlivca) tam. Postupom času môžete tento úspech použiť ako pozitívny príklad pre ďalšie tímy. “

Priemerná ročná mzda pre SRE je zhruba 130 000 dolárov v USA a 76 000 libier vo Veľkej Británii, podľa stránky práce Indeed.

Zdroje SRE

Na rozvoj zručností SRE je dostatok zdrojov, od certifikácií od DevOps Institute po knihy a online zdroje od O’Reilly, Microsoft a Google. Spomínaný monštrum na 550 stránInžinierstvo spoľahlivosti stránok autormi Jennifer Petoff, Niall Richard Murphy, Chris Jones a Betsy Beyer sú témou, ktorá bola publikovaná v roku 2016. Kniha je tiež k dispozícii zadarmo online na stránkach Google.

Medzi ďalšie novšie knihy na túto tému patriaŠkolenie technikov spoľahlivosti stránok Jennifer Petoff, JC van Winkel a Preston Yoshioka;Čo je SRE? Kurt Andersen a Craig Sebenik;Hľadám SREpredkladajú David N. Blank-Edelman aPracovný zošit spoľahlivosti stránok autormi: Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara a Stephen Thorne.

O’Reilly má tiež komplexnú knižnicu online aktív, videí a elektronických kníh na túto tému, ktoré sú ľahko zostavené v tomto zozname skladieb SRE Essentials bývalou inžinierkou spoľahlivosti webových stránok Google Liz Fong-Jones.

Online vzdelávací juggernaut Coursera ponúka niekoľko kurzov vrátane populárneho Engineeringu spoľahlivosti stránok: Meranie a správa spoľahlivosti z Google Cloud Training. Tento kurz je tiež k dispozícii na stránkach Pluralsight, rovnako ako začiatočnícky kurz Site Reliability Engineering (SRE): The Big Picture od Eltona Stonemana. Nadácia Linux Foundation ponúka kurz s názvom DevOps and SRE Fundamentals: Implementing Continuous Delivery.

Výcvik zameraný na medúzy so sídlom v Spojenom kráľovstve ponúka rôzne možnosti dvojdňového súkromného školenia pre Nadáciu SRE (SREF).

Prečítajte si viac o devops

  • Čo je to devops? Transformácia vývoja softvéru
  • 3 spôsoby spustenia devops programu
  • Najlepšie postupy Devops: 5 metód, ktoré by ste si mali osvojiť
  • 15 KPI na sledovanie transformácie devopsov
  • Monitorovanie aplikácií: Čo môže devops urobiť lepšie
  • Tam, kde sa inžinierstvo spoľahlivosti stránok stretáva s vývojom
  • 5 princípov k tomu, aby sa z vás stal tím agilných vývojových tímov
  • 3 kroky k uplatneniu svižných metodík v operáciách IT
  • Ako môžu agilné tímy podporovať správu nehôd
  • Ako dataops zlepšuje údaje, analýzu a strojové učenie
  • Uplatňovanie poznatkov v oblasti dátovej vedy a strojového učenia
  • Sedem otázok na uprednostnenie nevybavených položiek devops
$config[zx-auto] not found$config[zx-overlay] not found