Die webinar het swak oudio, so ons het dit getranskribeer.
My naam is Medwedef Eduard. Vandag sal ek praat oor wat SRE is, hoe SRE verskyn het, watter werkskriteria SRE-ingenieurs het, 'n bietjie oor betroubaarheidskriteria, 'n bietjie oor die monitering daarvan. Ons sal op die toppe loop, want jy kan nie veel in 'n uur vertel nie, maar ek sal materiaal gee vir bykomende hersiening, en ons wag almal vir jou op . in Moskou aan die einde van Januarie.
Kom ons praat eers oor wat SRE is - Site Reliability Engineering. En hoe dit verskyn het as 'n aparte posisie, as 'n aparte rigting. Dit het alles begin met die feit dat in tradisionele ontwikkelingskringe, Dev en Ops twee heeltemal verskillende spanne is, gewoonlik met twee heeltemal verskillende doelwitte. Die doel van die ontwikkelingspan is om nuwe funksies uit te voer en aan die behoeftes van die besigheid te voldoen. Die doel van die Ops-span is om seker te maak alles werk en niks breek nie. Dit is duidelik dat hierdie doelwitte mekaar direk weerspreek: vir alles om te werk en niks om te breek nie, ontplooi nuwe funksies so min as moontlik. As gevolg hiervan is daar baie interne konflikte wat die metodologie wat nou DevOps genoem word, probeer oplos.
Die probleem is dat ons nie 'n duidelike definisie van DevOps en 'n duidelike implementering van DevOps het nie. Ek het 2 jaar gelede by 'n konferensie in Jekaterinburg gepraat, en tot nou toe het die DevOps-afdeling begin met die verslag "Wat is DevOps". In 2017 is Devops amper 10 jaar oud, maar ons stry steeds wat dit is. En dit is 'n baie vreemde situasie wat Google 'n paar jaar gelede probeer oplos het.
In 2016 het Google 'n boek genaamd Site Reliability Engineering vrygestel. En om die waarheid te sê, dit was met hierdie boek dat die SRE-beweging begin het. SRE is 'n spesifieke implementering van die DevOps-paradigma in 'n spesifieke maatskappy. SRE-ingenieurs is daartoe verbind om te verseker dat stelsels betroubaar werk. Hulle kom meestal van ontwikkelaars, soms van administrateurs met 'n sterk ontwikkelingsagtergrond. En hulle doen wat stelseladministrateurs vroeër gedoen het, maar 'n sterk agtergrond in ontwikkeling en kennis van die stelsel in terme van kode lei daartoe dat hierdie mense nie geneig is tot roetine administratiewe werk nie, maar wel tot outomatisering geneig is.
Dit blyk dat die DevOps-paradigma in SRE-spanne geïmplementeer word deur die feit dat daar SRE-ingenieurs is wat strukturele probleme oplos. Hier is dit, dieselfde verband tussen Dev en Ops waaroor mense al 8 jaar praat. Die rol van 'n SRE is soortgelyk aan dié van 'n argitek deurdat nuwelinge nie SRE's word nie. Mense aan die begin van hul loopbane het nog geen ervaring nie, het nie die nodige breedte van kennis nie. Omdat SRE 'n baie subtiele kennis vereis van presies wat en wanneer presies verkeerd kan gaan. Daarom is 'n bietjie ervaring hier nodig, as 'n reël, beide binne die maatskappy en buite.
Hulle vra of die verskil tussen SRE en devops beskryf sal word. Sy is pas beskryf. Ons kan praat oor die plek van die SRE in die organisasie. Anders as hierdie klassieke DevOps-benadering, waar Ops steeds 'n aparte afdeling is, is SRE deel van die ontwikkelingspan. Hulle is betrokke by produkontwikkeling. Daar is selfs 'n benadering waar SRE 'n rol is wat van een ontwikkelaar na 'n ander oorgaan. Hulle neem deel aan kodebeoordelings op dieselfde manier as byvoorbeeld UX-ontwerpers, ontwikkelaars self, soms produkbestuurders. SRE's werk op dieselfde vlak. Ons moet dit goedkeur, ons moet dit hersien, sodat SRE vir elke ontplooiing sê: “Goed, hierdie ontplooiing, hierdie produk sal nie betroubaarheid negatief beïnvloed nie. En as dit wel gebeur, dan binne 'n paar aanvaarbare perke. Ons sal ook hieroor praat.
Gevolglik het die SRE 'n veto om die kode te verander. En oor die algemeen lei dit ook tot 'n soort klein konflik as die SRE verkeerd geïmplementeer word. In dieselfde boek oor Site Reliability Engineering vertel baie dele, nie eers een nie, hoe om hierdie konflikte te vermy.
Hulle vra hoe SRE met inligtingsekuriteit verband hou. SRE is nie direk betrokke by inligtingsekuriteit nie. Basies, in groot maatskappye, word dit gedoen deur individue, toetsers, ontleders. Maar SRE het ook interaksie met hulle in die sin dat sommige bedrywighede, sommige commit, sommige implementerings wat sekuriteit beïnvloed, ook die beskikbaarheid van die produk kan beïnvloed. Daarom het SRE as geheel interaksie met enige spanne, insluitend sekuriteitspanne, insluitend ontleders. Daarom is SRE's hoofsaaklik nodig wanneer hulle probeer om DevOps te implementeer, maar terselfdertyd word die las op ontwikkelaars te groot. Dit wil sê, die ontwikkelingspan self kan nie meer die feit hanteer dat hulle nou ook verantwoordelik moet wees vir Ops nie. En daar is 'n aparte rol. Hierdie rol word in die begroting beplan. Soms word hierdie rol in die grootte van die span neergelê, 'n aparte persoon verskyn, soms word een van die ontwikkelaars dit. Dit is hoe die eerste SRE in die span verskyn.
Die kompleksiteit van die stelsel wat deur SRE geraak word, die kompleksiteit wat die betroubaarheid van die operasie beïnvloed, is nodig en toevallig. Nodige kompleksiteit is wanneer die kompleksiteit van 'n produk toeneem tot die mate wat deur nuwe produkkenmerke vereis word. Willekeurige kompleksiteit is wanneer die kompleksiteit van die stelsel toeneem, maar die produkkenmerk en besigheidsvereistes beïnvloed dit nie direk nie. Dit blyk dat óf die ontwikkelaar iewers 'n fout gemaak het, óf die algoritme is nie optimaal nie, óf 'n paar bykomende belange word bekendgestel wat die kompleksiteit van die produk verhoog sonder spesiale behoefte. 'n Goeie SRE moet altyd hierdie situasie afsny. Dit wil sê, enige commit, enige ontplooiing, enige trekversoek, waar die moeilikheid verhoog word as gevolg van ewekansige toevoeging, moet geblokkeer word.
Die vraag is hoekom nie net 'n ingenieur, 'n stelseladministrateur met baie kennis in die span aanstel nie. 'n Ontwikkelaar in die rol van 'n ingenieur, word ons vertel, is nie die beste personeeloplossing nie. 'n Ontwikkelaar in die rol van 'n ingenieur is nie altyd die beste personeeloplossing nie, maar die punt hier is dat 'n ontwikkelaar wat by Ops betrokke is 'n bietjie meer begeerte vir outomatisering het, 'n bietjie meer kennis en 'n vaardigheidstel het om te implementeer hierdie outomatisering. En dienooreenkomstig verminder ons nie net die tyd vir sekere spesifieke bedrywighede nie, nie net die roetine nie, maar ook sulke belangrike besigheidsparameters soos MTTR (Mean Time To Recovery, hersteltyd). So, en ons sal ook 'n bietjie later hieroor praat, spaar ons geld vir die organisasie.
Kom ons praat nou oor die kriteria vir die werking van SRE. En eerstens oor betroubaarheid. In klein maatskappye, startups, gebeur dit dikwels dat mense aanneem dat as die diens goed geskryf is, as die produk goed en korrek geskryf is, dit sal werk, dit sal nie breek nie. Dit is dit, ons skryf goeie kode, so daar is niks om te breek nie. Die kode is baie eenvoudig, daar is niks om te breek nie. Dit is omtrent dieselfde mense wat sê dat ons nie toetse nodig het nie, want kyk, dit is die drie VPI-metodes, hoekom breek dit hier.
Dit is natuurlik alles verkeerd. En hierdie mense word in die praktyk baie dikwels deur sulke kode gebyt, want dinge breek. Dinge breek soms op die mees onvoorspelbare maniere. Soms sê mense nee, dit sal nooit gebeur nie. En dit gebeur heeltyd. Dit gebeur gereeld genoeg. En daarom streef niemand ooit na 100% beskikbaarheid nie, want 100% beskikbaarheid gebeur nooit. Dit is die norm. En daarom, wanneer ons praat oor die beskikbaarheid van 'n diens, praat ons altyd van nege. 2 nege, 3 nege, 4 nege, 5 nege. As ons dit vertaal in stilstand, dan, byvoorbeeld, 5 nege, dan is dit 'n bietjie meer as 5 minute se stilstand per jaar, 2 nege is 3,5 dae se stilstand.
Maar dit is duidelik dat daar op 'n stadium 'n afname in PVB, opbrengs op belegging, is. Om van twee nege na drie nege te gaan beteken minder stilstand met meer as 3 dae. Om van vier nege na vyf te gaan, verminder stilstandtyd met 47 minute per jaar. En dit blyk dat dit dalk nie krities is vir besigheid nie. En oor die algemeen is die vereiste betroubaarheid nie 'n tegniese kwessie nie, eerstens is dit 'n besigheidskwessie, dit is 'n produkkwessie. Watter vlak van stilstand is aanvaarbaar vir gebruikers van die produk, wat hulle verwag, hoeveel hulle betaal, byvoorbeeld, hoeveel geld hulle verloor, hoeveel geld die stelsel verloor.
'n Belangrike vraag hier is wat die betroubaarheid van die oorblywende komponente is. Want die verskil tussen 4 en 5 nege sal nie sigbaar wees op 'n slimfoon met 2 nege van betroubaarheid nie. Rofweg gesproke, as iets 10 keer per jaar op 'n slimfoon in jou diens breek, het waarskynlik 8 keer die ineenstorting aan die bedryfstelselkant plaasgevind. Die gebruiker is gewoond hieraan, en sal nie aandag gee aan nog een keer per jaar nie. Dit is nodig om die prys van toenemende betroubaarheid en toenemende winste te korreleer.
Net in die boek oor SRE is daar 'n goeie voorbeeld van verhoging tot 4 nege vanaf 3 nege. Dit blyk dat die toename in beskikbaarheid 'n bietjie minder as 0,1% is. En as die inkomste van die diens $1 miljoen per jaar is, dan is die toename in inkomste $900. As dit ons minder as $900 per jaar kos om bekostigbaarheid met 'n nege te verhoog, maak die verhoging finansieel sin. As dit meer as 900 dollar per jaar kos, maak dit nie meer sin nie, want die toename in inkomste vergoed eenvoudig nie vir arbeidskoste, hulpbronkoste nie. En 3 nege sal vir ons genoeg wees.
Dit is natuurlik 'n vereenvoudigde voorbeeld waar alle versoeke gelyk is. En om van 3 nege na 4 nege te gaan is maklik genoeg, maar terselfdertyd, byvoorbeeld, om van 2 nege na 3 te gaan, is dit reeds 'n besparing van 9 duisend dollar, dit kan finansieel sin maak. Natuurlik, in werklikheid is die mislukking van die registrasieversoek erger as die versuim om die bladsy te vertoon, versoeke het verskillende gewigte. Hulle het dalk 'n heeltemal ander maatstaf vanuit 'n besigheidsoogpunt, maar in elk geval, as ons nie oor 'n paar spesifieke dienste praat nie, is dit 'n redelik betroubare benadering.
Ons het 'n vraag ontvang of SRE een van die koördineerders is wanneer 'n argitektoniese oplossing vir die diens gekies word. Kom ons sê in terme van integrasie in die bestaande infrastruktuur, sodat daar geen verlies in sy stabiliteit is nie. Ja, SRE's, op dieselfde manier wat trekversoeke, commits, vrystellings die argitektuur beïnvloed, die bekendstelling van nuwe dienste, mikrodienste, die implementering van nuwe oplossings. Hoekom het ek voorheen gesê ervaring is nodig, kwalifikasies is nodig. Trouens, SRE is een van die blokkerende stemme in enige argitektoniese en sagteware-oplossing. Gevolglik moet 'n SRE as 'n ingenieur eerstens nie net verstaan nie, maar ook verstaan hoe sekere spesifieke besluite betroubaarheid, stabiliteit sal beïnvloed, en verstaan hoe dit verband hou met besigheidsbehoeftes, en vanuit watter oogpunt dit aanvaarbaar kan wees en wat nie.
Daarom kan ons nou net praat oor betroubaarheidskriteria, wat tradisioneel in SRE gedefinieer word as SLA (Diensvlakooreenkoms). Heel waarskynlik 'n bekende term. SLI (Diensvlakaanwyser). SLO (Diensvlakdoelwit). Diensvlakooreenkoms is miskien 'n simboliese term, veral as jy met netwerke gewerk het, met verskaffers, met hosting. Dit is 'n algemene ooreenkoms wat die prestasie van jou hele diens beskryf, boetes, sommige boetes vir foute, maatstawwe, kriteria. En SLI is die beskikbaarheidsmetriek self. Dit wil sê wat SLI kan wees: reaksietyd vanaf die diens, die aantal foute as 'n persentasie. Dit kan bandwydte wees as dit 'n soort lêerhosting is. Wanneer dit by herkenningsalgoritmes kom, kan die aanwyser byvoorbeeld selfs die korrektheid van die antwoord wees. SLO (Diensvlakdoelwit) is onderskeidelik 'n kombinasie van die SLI-aanwyser, sy waarde en tydperk.
Kom ons sê die SLA kan so wees. Die diens is 99,95% van die tyd deur die jaar beskikbaar. Of 99 kritieke ondersteuningskaartjies sal binne 3 uur per kwartaal gesluit word. Of 85% van navrae sal elke maand binne 1,5 sekondes antwoorde kry. Dit wil sê, ons kom geleidelik agter dat foute en mislukkings redelik normaal is. Dit is 'n aanvaarbare situasie, ons beplan dit, ons reken selfs in 'n mate daarop. Dit wil sê, SRE bou stelsels wat foute kan maak, wat normaal moet reageer op foute, wat dit in ag moet neem. En waar moontlik, moet hulle foute op so 'n manier hanteer dat die gebruiker dit óf nie opmerk nie, óf opmerk, maar daar is 'n soort oplossing, waardeur alles nie heeltemal sal val nie.
Byvoorbeeld, as jy 'n video na YouTube oplaai, en YouTube kan dit nie dadelik omskakel nie, as die video te groot is, as die formaat nie optimaal is nie, dan sal die versoek natuurlik nie misluk met 'n uitteltyd nie, YouTube sal nie 'n 502-fout gee nie , YouTube sal sê: “Ons het alles geskep, jou video word verwerk. Dit sal binne ongeveer 10 minute gereed wees.” Dit is die beginsel van grasieuse degradasie, wat bekend is, byvoorbeeld van front-end ontwikkeling, as jy dit al ooit gedoen het.
Die volgende terme waaroor ons sal praat, wat baie belangrik is om met betroubaarheid te werk, met foute, met verwagtinge, is MTBF en MTTR. MTBF is die gemiddelde tyd tussen mislukkings. MTTR gemiddelde tyd tot herstel, gemiddelde tyd tot herstel. Dit wil sê, hoeveel tyd het verloop vanaf die oomblik dat die fout ontdek is, vanaf die oomblik dat die fout verskyn het tot die oomblik dat die diens na volle normale werking herstel is. MTBF word hoofsaaklik vasgestel deur werk aan kodekwaliteit. Dit wil sê die feit dat SRE's "nee" kan sê. En jy het 'n begrip van die hele span nodig dat wanneer SRE "nee" sê, hy dit nie sê omdat hy skadelik is nie, nie omdat hy sleg is nie, maar omdat andersins almal sal ly.
Weereens, daar is baie artikels, baie metodes, baie maniere, selfs in die einste boek waarna ek so gereeld verwys, hoe om seker te maak dat ander ontwikkelaars nie SRE begin haat nie. MTTR, aan die ander kant, gaan daaroor om aan jou SLO's (Diensvlakdoelwit) te werk. En dit is meestal outomatisering. Omdat ons SLO byvoorbeeld 'n optyd van 4 nege per kwartaal is. Dit beteken dat ons binne 3 maande 13 minute se stilstand kan toelaat. En dit blyk dat MTTR nie meer as 13 minute kan wees nie. As ons reageer op ten minste 13 stilstand in 1 minute, beteken dit dat ons reeds die hele begroting vir die kwartaal uitgeput het. Ons breek die SLO. 13 minute om te reageer en 'n ongeluk reg te stel is baie vir 'n masjien, maar baie kort vir 'n mens. Want totdat 'n persoon 'n waarskuwing ontvang, totdat hy reageer, totdat hy die fout verstaan, is dit reeds 'n paar minute. Totdat 'n persoon verstaan hoe om dit reg te maak, wat presies om reg te maak, wat om te doen, dan is dit nog 'n paar minute. En om die waarheid te sê, selfs as jy net die bediener moet herbegin, soos dit blyk, of 'n nuwe nodus moet oprig, dan is MTTR handmatig reeds sowat 7-8 minute. Wanneer die proses outomatiseer word, bereik MTTR baie dikwels 'n sekonde, soms millisekondes. Google praat gewoonlik van millisekondes, maar in werklikheid is alles natuurlik nie so goed nie.
Ideaal gesproke moet die SRE sy werk byna heeltemal outomatiseer, want dit raak die MTTR, sy maatstawwe, die SLO van die hele diens, en dienooreenkomstig die besigheidswins direk. Indien tyd oorskry word, word ons gevra of SRE skuldig is. Gelukkig is niemand te blameer nie. En dit is 'n aparte kultuur genaamd balmelose nadoodse ondersoek, waaroor ons nie vandag sal praat nie, maar ons sal dit op Slurm ontleed. Dit is 'n baie interessante onderwerp waaroor baie gepraat kan word. Rofweg gesproke, as die toegelate tyd per kwartaal oorskry word, dan is 'n bietjie van almal te blameer, wat beteken dat dit nie produktief is om almal te blameer nie, laat ons eerder, miskien niemand blameer nie, maar die situasie regstel en werk met wat ons het. In my ervaring is hierdie benadering 'n bietjie vreemd aan die meeste spanne, veral in Rusland, maar dit maak sin en werk baie goed. Daarom sal ek aan die einde van die artikel en literatuur aanbeveel dat u oor hierdie onderwerp kan lees. Of kom na Slurm SRE.
Laat ek verduidelik. As die SLO-tyd per kwartaal oorskry word, as die stilstand nie 13 minute was nie, maar 15, wie kan hiervoor die skuld kry? Natuurlik kan SRE die skuld kry, want hy het duidelik 'n soort slegte commit of ontplooiing gemaak. Die administrateur van die datasentrum kan dalk hiervoor die skuld kry, want hy het moontlik die een of ander ongeskeduleerde instandhouding uitgevoer. As die administrateur van die datasentrum hiervoor die skuld kry, dan is die persoon van Ops hiervoor die skuld, wat nie die onderhoud bereken het toe hy die SLO gekoördineer het nie. Die bestuurder, tegniese direkteur of iemand wat die datasentrumkontrak onderteken het en nie aandag gegee het aan die feit dat die SLA van die datasentrum nie ontwerp is vir die vereiste stilstandtyd nie, is hiervoor te blameer. Gevolglik is alles bietjie vir bietjie in hierdie situasie te blameer. En dit beteken dat daar geen sin is om die skuld op enigiemand in hierdie situasie te lê nie. Maar dit moet natuurlik reggestel word. Daarom is daar nadoodse ondersoeke. En as jy byvoorbeeld GitHub nadoodse ondersoeke lees, en dit is altyd 'n baie interessante, klein en onverwagte storie in elke spesifieke geval, kan jy vervang dat niemand ooit sê dat hierdie spesifieke persoon die skuld gehad het nie. Die blaam word altyd op spesifieke onvolmaakte prosesse geplaas.
Kom ons gaan aan na die volgende vraag. Outomatisering. Wanneer ek in ander kontekste oor outomatisering praat, verwys ek dikwels na 'n tabel wat jou vertel hoe lank jy kan werk aan die outomatisering van 'n taak sonder om meer tyd te neem om dit te outomatiseer as wat jy werklik spaar. Daar is 'n haakplek. Die vangs is dat wanneer SRE's 'n taak outomatiseer, hulle nie net tyd bespaar nie, hulle spaar geld, want outomatisering raak MTTR direk. Hulle spaar so te sê die moraal van werknemers en ontwikkelaars, wat ook 'n uitputbare hulpbron is. Hulle verminder die roetine. En dit alles het 'n positiewe uitwerking op werk en, gevolglik, op besigheid, al lyk dit of outomatisering nie sin maak in terme van tydskoste nie.
Trouens, dit het amper altyd, en daar is baie min gevalle waar iets nie geoutomatiseer moet word in die rol van SRE nie. Vervolgens gaan ons praat oor wat die foutbegroting genoem word, die begroting vir foute. Trouens, dit blyk dat as alles vir jou baie beter is as die SLO wat jy vir jouself stel, dit ook nie baie goed is nie. Dit is nogal sleg, want SLO werk nie net as 'n onderste grens nie, maar ook as 'n benaderde boonste grens. Wanneer jy vir jouself 'n SLO van 99% beskikbaarheid stel, en jy het eintlik 99,99%, blyk dit dat jy 'n bietjie ruimte het vir eksperimente wat glad nie die besigheid sal benadeel nie, want jy het dit self alles saam bepaal, en jy is hierdie spasie nie gebruik nie. Jy het ’n begroting vir foute, wat in jou geval nie opgebruik word nie.
Wat maak ons daarmee. Ons gebruik dit vir letterlik alles. Vir toetsing in produksietoestande, vir die uitrol van nuwe kenmerke wat werkverrigting kan beïnvloed, vir vrystellings, vir instandhouding, vir beplande stilstand. Die omgekeerde reël geld ook: as die begroting uitgeput is, kan ons niks nuuts vrystel nie, want anders gaan ons die SLO oorskry. Die begroting is reeds uitgeput, ons het iets vrygestel, as dit prestasie negatief beïnvloed, dit wil sê, as dit nie 'n soort oplossing is wat op sigself die SLO direk verhoog nie, dan gaan ons verder as die begroting, en dit is 'n slegte situasie , dit moet ontleed word, nadoodse ondersoek, en moontlik 'n paar proses regstellings.
Dit wil sê, dit blyk dat as die diens self nie goed werk nie, en SLO word bestee en die begroting word nie aan eksperimente bestee nie, nie op sommige vrystellings nie, maar op sigself, dan in plaas van 'n paar interessante regstellings, in plaas van interessante kenmerke, in plaas van interessante vrystellings. In plaas van enige kreatiewe werk, sal jy met dom regstellings te doen kry om die begroting weer in orde te kry, of die SLO te wysig, en dit is ook 'n proses wat nie te dikwels moet gebeur nie.
Daarom blyk dit dat in 'n situasie waar ons meer begroting vir foute het, almal belangstel: beide SRE en ontwikkelaars. Vir ontwikkelaars beteken 'n groot begroting vir foute dat jy vrystellings, toetse, eksperimente kan hanteer. Vir SRE's beteken 'n begroting vir foute en die invoer van daardie begroting dat hulle direk hul werk goed doen. En dit beïnvloed die motivering van een of ander soort gesamentlike werk. As jy na jou SRE's as ontwikkelaars luister, sal jy meer ruimte hê vir goeie werk en baie minder roetine.
Dit blyk dat eksperimente in produksie nogal 'n belangrike en byna integrale deel van SRE in groot spanne is. En dit word gewoonlik chaos-ingenieurswese genoem, wat kom van die span by Netflix wat 'n program genaamd Chaos Monkey vrygestel het.
Chaos Monkey koppel aan die CI/CD-pyplyn en laat die bediener in produksie lukraak ineenstort. Weereens, in die SRE-struktuur, praat ons van die feit dat 'n afgelaaide bediener nie op sigself sleg is nie, dit word verwag. En as dit binne die begroting is, is dit aanvaarbaar en benadeel nie die besigheid nie. Natuurlik het Netflix genoeg oortollige bedieners, genoeg replikasie, sodat dit alles reggemaak kan word, en sodat die gebruiker as geheel nie eers agterkom nie, en selfs meer nog, niemand los een bediener vir enige begroting nie.
Netflix het vir 'n rukkie 'n hele reeks sulke hulpmiddels gehad, waarvan een, Chaos Gorilla, een van Amazon se beskikbaarheidsones heeltemal afskakel. En sulke dinge help om eerstens verborge afhanklikhede te openbaar, wanneer dit nie heeltemal duidelik is wat wat raak, wat afhang van wat nie. En dit, as jy met 'n mikrodiens werk, en die dokumentasie is nie heeltemal perfek nie, is dit dalk aan jou bekend. En weereens, dit help baie om foute in die kode op te vang wat jy nie op staging kan opvang nie, want enige staging is nie presies 'n presiese simulasie nie, as gevolg van die feit dat die vragskaal verskil, die laspatroon verskil, die toerusting is ook, heel waarskynlik, ander. Piekladings kan ook onverwags en onvoorspelbaar wees. En sulke toetsing, wat weereens nie verder gaan as die begroting nie, help baie goed om foute in die infrastruktuur op te vang wat staging, outotoetse, CI / CD-pyplyn nooit sal opvang nie. En solank dit alles by jou begroting ingesluit is, maak dit nie saak dat jou diens daar afgegaan het nie, alhoewel dit baie skrikwekkend lyk, het die bediener afgegaan, wat 'n nagmerrie. Nee, dit is normaal, dit is goed, dit help om goggas te vang. As jy 'n begroting het, kan jy dit spandeer.
V: Watter literatuur kan ek aanbeveel? Lys aan die einde. Daar is baie literatuur, ek sal 'n paar verslae adviseer. Hoe werk dit, en werk SRE in maatskappye sonder hul eie sagtewareproduk of met minimale ontwikkeling. Byvoorbeeld, in 'n onderneming waar die hoofaktiwiteit nie sagteware is nie. In 'n onderneming, waar die hoofaktiwiteit nie sagteware is nie, werk SRE presies dieselfde as oral anders, want in 'n onderneming moet jy ook sagtewareprodukte gebruik, al is dit nie ontwikkel nie, jy moet opdaterings uitrol, jy moet verander die infrastruktuur, jy moet groei, jy moet skaal. En SRE's help om moontlike probleme in hierdie prosesse te identifiseer en te voorspel en dit te beheer nadat 'n mate van groei begin het en besigheidsbehoeftes verander het. Omdat dit absoluut nie nodig is om by sagteware-ontwikkeling betrokke te wees om 'n SRE te hê as jy ten minste 'n paar bedieners het en daar word van jou verwag om ten minste 'n mate van groei te hê nie.
Dieselfde geld vir klein projekte, klein organisasies, want groot maatskappye het die begroting en die ruimte om te eksperimenteer. Maar terselfdertyd kan al hierdie vrugte van eksperimente oral gebruik word, dit wil sê, SRE het natuurlik in Google, in Netflix, in Dropbox verskyn. Maar terselfdertyd kan klein maatskappye en beginners reeds verkorte materiaal lees, boeke lees, verslae kyk. Hulle begin meer gereeld daarvan hoor, hulle kyk na spesifieke voorbeelde, ek dink dit is oukei, dit kan regtig nuttig wees, ons het dit ook nodig, dit is wonderlik.
Dit wil sê, al die hoofwerk aan die standaardisering van hierdie prosesse is reeds vir jou gedoen. Dit bly vir jou om die rol van SRE spesifiek in jou maatskappy te bepaal en te begin om al hierdie praktyke, wat weereens reeds beskryf is, daadwerklik te implementeer. Dit wil sê, uit nuttige beginsels vir klein maatskappye, is dit altyd die definisie van SLA, SLI, SLO. As jy nie by sagteware betrokke is nie, sal dit interne SLA's en interne SLO's wees, 'n interne begroting vir foute. Dit lei amper altyd tot 'n paar interessante gesprekke binne die span en binne die besigheid, want dit kan blyk dat jy spandeer op infrastruktuur, op 'n soort organisasie van ideale prosesse, die ideale pyplyn is baie meer as wat nodig is. En hierdie 4 nege wat jy in die IT-afdeling het, jy het hulle nie nou regtig nodig nie. Maar terselfdertyd kan jy tyd spandeer, die begroting vir foute aan iets anders bestee.
Gevolglik is monitering en organisering van monitering nuttig vir 'n maatskappy van enige grootte. En oor die algemeen, hierdie manier van dink, waar foute iets aanvaarbaars is, waar daar 'n begroting is, waar daar Doelwitte is, is dit weer nuttig vir 'n maatskappy van enige grootte, vanaf startups vir 3 mense.
Die laaste van die tegniese nuanses om oor te praat, is monitering. Want as ons van SLA, SLI, SLO praat, kan ons nie verstaan sonder om te moniteer of ons in die begroting pas, of ons aan ons doelwitte voldoen, en hoe ons die finale SLA beïnvloed nie. Ek het al soveel keer gesien dat monitering so gebeur: daar is 'n mate van waarde, byvoorbeeld die tyd van 'n versoek aan die bediener, die gemiddelde tyd, of die aantal versoeke na die databasis. Hy het 'n standaard wat deur 'n ingenieur bepaal word. As die maatstaf van die norm afwyk, dan kom 'n e-pos. Dit is alles absoluut nutteloos, as 'n reël, want dit lei tot so 'n klomp waarskuwings, 'n klomp boodskappe van monitering, wanneer 'n persoon dit eerstens elke keer moet interpreteer, dit wil sê, bepaal of die waarde van die metrieke beteken die behoefte aan aksie. En tweedens hou hy eenvoudig op om al hierdie waarskuwings op te let, wanneer basies geen optrede van hom vereis word nie. Dit is 'n goeie moniteringsreël en die heel eerste reël wanneer SRE geïmplementeer word, is dat kennisgewing slegs moet kom wanneer aksie vereis word.
In die standaard geval is daar 3 vlakke van gebeure. Daar is waarskuwings, daar is kaartjies, daar is logs. Waarskuwings is enigiets wat vereis dat jy onmiddellik optree. Dit wil sê, alles is stukkend, jy moet dit nou regmaak. Kaartjies is wat vertraagde optrede vereis. Ja, jy moet iets doen, jy moet iets handmatig doen, outomatisering het misluk, maar jy hoef dit nie vir die volgende paar minute te doen nie. Logs is enigiets wat nie aksie vereis nie, en in die algemeen, as dinge goed gaan, sal niemand dit ooit lees nie. Jy sal net die logs hoef te lees wanneer dit in retrospek blyk dat iets vir 'n geruime tyd gebreek het, ons het nie daarvan geweet nie. Of moet jy navorsing doen. Maar oor die algemeen gaan alles wat geen aksie vereis nie, na die logs.
As 'n newe-effek van dit alles, as ons gedefinieer het watter gebeurtenisse aksies vereis en goed beskryf het wat hierdie aksies moet wees, beteken dit dat die aksie geoutomatiseer kan word. Dit is, wat gebeur. Ons gaan van wakker. Kom ons gaan tot aksie. Ons gaan na die beskrywing van hierdie aksie. En dan gaan ons oor na outomatisering. Dit wil sê, enige outomatisering begin met 'n reaksie op 'n gebeurtenis.
Van monitering gaan ons aan na 'n term genaamd Waarneembaarheid. Daar was ook die afgelope paar jaar 'n bietjie ophef rondom hierdie woord. En min mense verstaan wat dit beteken buite konteks. Maar die belangrikste punt is dat waarneembaarheid 'n maatstaf is vir stelseldeursigtigheid. As iets verkeerd geloop het, hoe vinnig kan jy bepaal wat presies verkeerd geloop het en wat die toestand van die stelsel op daardie oomblik was. In terme van kode: watter funksie het misluk, watter diens het misluk. Wat was die toestand van byvoorbeeld interne veranderlikes, konfigurasie. Wat infrastruktuur betref, is dit in watter beskikbaarheidsone die fout plaasgevind het, en as jy enige Kubernetes het, dan in watter peul die mislukking plaasgevind het, wat was die toestand van die peul. En dienooreenkomstig het waarneembaarheid 'n direkte verband met MTTR. Hoe hoër die waarneembaarheid van die diens, hoe makliker is dit om die fout te identifiseer, hoe makliker is dit om die fout reg te stel, hoe makliker is dit om die fout te outomatiseer, hoe laer is die MTTR.
As ons weer na klein maatskappye gaan, is dit baie algemeen om te vra, selfs nou, hoe om spangrootte te hanteer, en of 'n klein span 'n aparte SRE moet huur. Het al 'n bietjie vroeër hieroor gepraat. In die eerste stadiums van ontwikkeling van 'n beginonderneming of, byvoorbeeld, 'n span, is dit glad nie nodig nie, want SRE kan 'n oorgangsrol gemaak word. En dit sal die span 'n bietjie laat herleef, want daar is ten minste 'n mate van diversiteit. En plus dit sal mense voorberei vir die feit dat met groei, oor die algemeen, die verantwoordelikhede van SRE baie aansienlik sal verander. As jy 'n persoon aanstel, dan het hy natuurlik 'n paar verwagtinge. En hierdie verwagtinge sal nie mettertyd verander nie, maar die vereistes sal baie verander. Daarom, hoe om 'n SRE te huur, is nogal moeilik in die vroeë stadiums. Om jou eie te kweek is baie makliker. Maar dit is die moeite werd om oor na te dink.
Die enigste uitsondering is miskien wanneer daar baie streng en goed gedefinieerde groeivereistes is. Dit wil sê, in die geval van 'n begin, kan dit 'n soort druk van beleggers wees, 'n soort voorspelling vir groei 'n paar keer gelyktydig. Dan is die huur van 'n SRE basies geregverdig omdat dit geregverdig kan word. Ons het vereistes vir groei, ons het 'n persoon nodig wat verantwoordelik sal wees vir die feit dat met sulke groei niks sal breek nie.
Nog 'n vraag. Wat om te doen wanneer die ontwikkelaars verskeie kere 'n kenmerk sny wat die toetse slaag, maar die produksie breek, die basis laai, ander kenmerke breek, watter proses om te implementeer. Gevolglik is dit in hierdie geval die begroting vir foute wat ingestel word. En sommige van die dienste, sommige van die kenmerke word reeds in die produksie getoets. Dit kan kanarie wees, wanneer slegs 'n klein aantal gebruikers, maar reeds in die produksie, 'n kenmerk ontplooi word, maar reeds met die verwagting dat as iets breek, byvoorbeeld vir 'n halwe persent van alle gebruikers, dit steeds aan die begroot vir foute. Gevolglik, ja, daar sal 'n fout wees, vir sommige gebruikers sal alles breek, maar ons het reeds gesê dat dit normaal is.
Daar was 'n vraag oor SRE-gereedskap. Dit wil sê, is daar iets spesifiek wat SRE's sou gebruik wat almal anders nie sou nie. Trouens, daar is 'n paar hoogs gespesialiseerde nutsprogramme, daar is 'n soort sagteware wat byvoorbeeld vragte simuleer of besig is met kanarie A / B-toetse. Maar basies is die SRE-gereedskapstel wat u ontwikkelaars reeds gebruik. Omdat SRE direk met die ontwikkelingspan in wisselwerking tree. En as jy verskillende gereedskap het, sal dit blyk dat dit tyd neem om te sinchroniseer. Veral as SRE'e in groot spanne werk, in groot maatskappye waar daar verskeie spanne kan wees, is dit maatskappywye standaardisering wat hier baie sal help, want as 50 verskillende nutsdienste in 50 spanne gebruik word, beteken dit dat die SRE hulle moet ken almal. En dit sal natuurlik nooit gebeur nie. En die kwaliteit van werk, die kwaliteit van beheer van ten minste sommige van die spanne sal aansienlik verminder.
Ons webinar kom tot 'n einde. Ek het daarin geslaag om 'n paar basiese dinge te vertel. Natuurlik kan niks oor SRE in 'n uur vertel en verstaan word nie. Maar ek hoop dat ek dit reggekry het om hierdie manier van dink, die belangrikste sleutelpunte, oor te dra. En dan sal dit moontlik wees om, indien belangstel, in die onderwerp te delf, op jou eie te leer, te kyk hoe dit deur ander mense, in ander maatskappye geïmplementeer word. En dienooreenkomstig, vroeg in Februarie, kom na ons by Slurm SRE.
Die Slurm SRE is 'n drie-dag intensiewe kursus wat sal praat oor dit waarvan ek nou praat, maar met baie meer diepte, met werklike gevalle, met oefening, is die hele intensiewe gerig op praktiese werk. Mense sal in spanne verdeel word. Julle sal almal aan werklike sake werk. Gevolglik het ons Booking.com-instrukteurs Ivan Kruglov en Ben Tyler. Ons het 'n wonderlike Eugene Barabbas van Google, van San Francisco. En ek sal jou ook iets vertel. Maak dus seker om ons te besoek.
Dus, die bibliografie. Daar is verwysings oor SRE. op dieselfde boek, of eerder op 2 boeke oor SRE, geskryf deur Google. Nog een , waar die bepalings en hul toepassing effens meer gedetailleerd is. Die volgende 3 is verslae oor SRE in verskillende maatskappye. Eerstens - , dit is 'n hoofnota van Ben Trainer van Google. Tweede - . Die derde is weer . Vierde verslag van , wat slegs 5 sleutel SRE-werknemers in 190 lande het. Dit is baie interessant om na dit alles te kyk, want net soos DevOps baie verskillende dinge vir verskillende maatskappye en selfs verskillende spanne beteken, het SRE baie verskillende verantwoordelikhede, selfs in maatskappye van soortgelyke grootte.
Nog 2 skakels oor die beginsels van chaos-ingenieurswese: , . En aan die einde is daar 3 lyste uit die reeks Awesome Lists oor , oor en oor . Die lys op SRE is ongelooflik groot, dit is nie nodig om alles deur te gaan nie, daar is ongeveer 200 artikels. Ek beveel artikels van daar af oor kapasiteitsbeplanning en oor onberispelike nadoodse ondersoek ten sterkste aan.
Interessante artikel:
Dankie dat jy al die tyd na my geluister het. Hoop jy het iets geleer. Hoop jy het genoeg materiaal om nog meer te leer. En sien jou. Hopelik in Februarie.
Die webinar is deur Eduard Medvedev aangebied.
NS: vir diegene wat graag lees, het Eduard 'n lys van verwysings gegee. Diegene wat verkies om te verstaan in die praktyk is welkom om .
Bron: will.com