Webinaret har dårlig lyd, så vi lavede en transskription.
Mit navn er Medvedev Eduard. I dag vil jeg tale om, hvad SRE er, hvordan SRE fremstod, hvad er arbejdskriterierne for SRE-ingeniører, lidt om pålidelighedskriterier, lidt om dets overvågning. Vi går over toppen, for du kan ikke fortælle meget på en time, men jeg giver dig materialer til yderligere gennemgang, og vi venter alle på dig kl. . i Moskva i slutningen af januar.
Lad os først tale om, hvad SRE - Site Reliability Engineering - er. Og hvordan det fremstod som en separat position, som en separat retning. Det hele startede med, at i traditionelle udviklingskredse er Dev og Ops to helt forskellige hold, som regel med to helt forskellige mål. Målet med udviklingsteamet er at udrulle nye funktioner for at imødekomme forretningsbehov. Målet med Ops-teamet er at sikre, at alt fungerer, og at intet går i stykker. Det er klart, at disse mål er direkte i modstrid med hinanden: så alt fungerer, og intet går i stykker, er det bedre at udrulle nye funktioner så lidt som muligt. På grund af dette opstår der mange interne konflikter, som metoden nu kaldet DevOps forsøger at løse.
Problemet er, at vi ikke har en klar definition af DevOps og en klar implementering af DevOps. Jeg talte ved en konference i Jekaterinburg for 2 år siden, og indtil nu begyndte DevOps-sektionen med rapporten "Hvad er DevOps." I 2017 er devops næsten 10 år gammel, men vi skændes stadig om, hvad det er. Og det er en meget mærkelig situation, som Google forsøgte at løse for et par år siden.
I 2016 udgav Google en bog kaldet "Site Reliability Engineering." Og faktisk var det med denne bog, at SRE-bevægelsen begyndte. SRE er en specifik mulighed for implementering af DevOps-paradigmet i en specifik virksomhed. SRE-ingeniører har sat sig som mål at sikre pålidelig drift af systemer. De er hovedsageligt taget fra udviklere, nogle gange fra administratorer med en stærk udviklingsbaggrund. Og de gør, hvad systemadministratorer plejede at gøre, men en stærk baggrund i udvikling og viden om systemet fra et kodesynspunkt fører til, at disse mennesker ikke er tilbøjelige til rutinemæssigt administrativt arbejde, men er tilbøjelige til automatisering.
Det viser sig, at DevOps-paradigmet i SRE-teams er implementeret ved, at der er SRE-ingeniører, der løser strukturelle problemer. Her er den samme forbindelse mellem Dev og Ops, som folk har talt om i 8 år. En SRE's rolle ligner en arkitekts rolle, idet nybegyndere ikke bliver SRE'er. Folk i begyndelsen af deres karriere har endnu ikke nogen erfaring og har ikke den nødvendige bredde af viden. Fordi SRE kræver en meget sofistikeret viden om præcis, hvad og hvornår præcist kan gå galt. Derfor skal der som udgangspunkt en form for erfaring til her, både i virksomheden og udenfor.
De spørger, om forskellen mellem SRE og devops vil blive beskrevet. Hun er netop blevet beskrevet. Vi kan tale om SRE's plads i organisationen. I modsætning til den klassiske DevOps-tilgang, hvor Ops stadig er en separat afdeling, er SRE en del af udviklingsteamet. De er involveret i produktudvikling. Der er endda en tilgang, hvor SRE er en rolle, der går fra en udvikler til en anden. De deltager i kodegennemgange på samme måde som for eksempel UX-designere, udviklere selv og nogle gange produktchefer. SRE'er opererer på dette samme niveau. Vi har brug for deres godkendelse, vi har brug for deres gennemgang, så for hver implementering siger SRE: "Okay, denne implementering, dette produkt vil ikke påvirke pålideligheden negativt. Og hvis det gør det, vil det være inden for nogle acceptable grænser.” Vi vil også tale om dette.
Derfor har SRE et veto om kodeændringer. Og generelt fører dette også til nogle små konflikter, hvis SRE implementeres forkert. I netop den bog om Site Reliability Engineering fortæller mange dele, endda mere end én, hvordan man undgår disse konflikter.
Folk spørger, hvordan SRE forholder sig til informationssikkerhed. SRE er ikke direkte involveret i informationssikkerhed. For det meste i store virksomheder udføres dette af individuelle personer, testere og analytikere. Men SRE interagerer også med dem i den forstand, at nogle operationer, nogle commits, nogle implementeringer, der påvirker sikkerheden, også kan påvirke tilgængeligheden af produktet. Derfor har SRE generelt interaktion med alle teams, herunder sikkerhedsteams, herunder analytikere. Derfor er SRE'er primært nødvendige, når man forsøger at implementere DevOps, men byrden på udviklere bliver for stor. Det vil sige, at udviklingsteamet ikke selv kan klare længere, at de nu også skal stå for Ops. Og en separat rolle dukker op. Denne rolle er planlagt i budgettet. Nogle gange er denne rolle indbygget i teamets størrelse, en separat person dukker op, nogle gange bliver en af udviklerne det. Sådan optræder den første SRE på holdet.
Systemkompleksitet, der påvirkes af SRE, kompleksitet, der påvirker driftssikkerheden, kan være nødvendig eller tilfældig. Nødvendig kompleksitet er, når produktets kompleksitet øges i det omfang, nye produktfunktioner kræver det. Tilfældig kompleksitet er, når kompleksiteten af systemet øges, men produktfunktionen og forretningskravene påvirker ikke direkte dette. Det viser sig, at enten har udvikleren lavet en fejl et sted, eller også er algoritmen ikke optimal, eller der indføres nogle ekstra interesser, der øger produktets kompleksitet unødigt. En god SRE bør altid undgå denne situation. Det vil sige, enhver commit, enhver implementering, enhver pull-anmodning, der øger kompleksiteten på grund af tilfældige tilføjelser, skal blokeres.
Spørgsmålet er, hvorfor ikke bare hyre en ingeniør, en systemadministrator med en masse viden, til at slutte sig til teamet. En udvikler i rollen som ingeniør, får vi at vide, er ikke den mest optimale personaleløsning. En udvikler i rollen som ingeniør er ikke altid den optimale personaleløsning, men pointen her er, at en udvikler, der beskæftiger sig med Ops, har lidt mere lyst til automatisering, har lidt mere viden og færdigheder for at kunne implementere dette. automatisering. Og derfor reducerer vi ikke kun tiden til nogle specifikke operationer, ikke kun rutinen, men også så vigtige forretningsparametre som MTTR (Mean Time To Recovery, recovery time). Således, og det vil vi også tale om lidt senere, sparer vi penge til organisationen.
Lad os nu tale om kriterierne for SRE-arbejde. Og først og fremmest om pålidelighed. I små virksomheder og startups sker det ofte, at folk går ud fra, at hvis ydelsen er skrevet godt, hvis produktet er skrevet godt og korrekt, så virker det, det går ikke i stykker. Det er det, vi skriver god kode, så der er ikke noget at bryde. Koden er meget enkel, der er intet at bryde. Det er omtrent de samme mennesker, der siger, at vi ikke har brug for tests, for se, det er tre VPI-metoder, hvorfor gider det?
Det hele er selvfølgelig forkert. Og disse mennesker bliver meget ofte såret af denne form for kode i praksis, fordi tingene går i stykker. Ting går nogle gange i stykker på de mest uforudsigelige måder. Nogle gange siger folk nej, det vil aldrig ske. Og det sker stadig. Sker ret ofte. Og det er derfor, ingen nogensinde stræber efter 100 % tilgængelighed, for 100 % tilgængelighed sker aldrig. Dette er normen. Og derfor taler vi altid om nire, når vi taler om servicetilgængelighed. 2 niere, 3 niere, 4 niere, 5 niere. Hvis vi oversætter dette til nedetid, så er for eksempel 5 nire lidt mere end 5 minutters nedetid om året, 2 niere er 3,5 dages nedetid.
Men det er indlysende, at der på et tidspunkt er et fald i POI og investeringsafkast. At gå fra to niere til tre niere betyder at reducere nedetiden med mere end 3 dage. At gå fra fire nire til fem reducerer nedetiden med 47 minutter om året. Og det viser sig, at dette måske ikke er kritisk for erhvervslivet. Og generelt er den nødvendige pålidelighed ikke et teknisk problem, først og fremmest er det et forretningsproblem, det er et produktproblem. Hvilket niveau af nedetid er acceptabelt for brugere af produktet, hvad forventer de, hvor meget betaler de, for eksempel hvor mange penge mister de, hvor mange penge taber systemet.
Et vigtigt spørgsmål er, hvad er pålideligheden af de resterende komponenter. Fordi forskellen mellem 4 og 5 niere vil ikke være synlig på en smartphone med 2 pålidelighedsniere. Groft sagt, hvis noget går i stykker på en smartphone i din tjeneste 10 gange om året, er det højst sandsynligt 8 gange nedbrud sket på OS-siden. Brugeren er vant til dette, og vil ikke være opmærksom på det en ekstra gang om året. Det er nødvendigt at sammenligne prisen på stigende pålidelighed og øget overskud.
Bare i bogen om SRE er der et godt eksempel på at øge til 4 niere fra 3 niere. Det viser sig, at stigningen i tilgængelighed er lidt mindre end 0,1 %. Og hvis tjenestens omsætning er $1 million om året, så er omsætningsstigningen $900. Hvis en forøgelse af tilgængeligheden med ni koster os mindre end $900 om året, giver stigningen økonomisk mening. Hvis det koster mere end 900 dollars om året, giver det ikke længere mening, fordi stigningen i omsætningen simpelthen ikke kompenserer for lønomkostninger og ressourceomkostninger. Og 3 niere vil være nok for os.
Dette er naturligvis et forenklet eksempel, hvor alle anmodninger er lige. Og fra 3 niere til 4 niere er det ret nemt at gå, men samtidig er det for eksempel allerede en besparelse på 2 tusind dollars at gå fra 3 niere til 9, det kan give økonomisk mening. Naturligvis er en manglende registrering af en anmodning værre end en manglende visning af en side; anmodninger har forskellig vægt. De kan have helt andre kriterier fra et forretningsmæssigt synspunkt, men stadig, som regel, hvis vi ikke taler om nogen specifikke tjenester, er dette en ret pålidelig tilnærmelse.
Vi fik et spørgsmål om, hvorvidt SRE er en af koordinatorerne ved valg af arkitektonisk løsning til ydelsen. Dette er acceptabelt med hensyn til integration i den eksisterende infrastruktur, så der ikke er noget tab i dens stabilitet. Ja, SRE'er påvirker pull-anmodninger, commits, releases på samme måde; de påvirker arkitekturen, implementeringen af nye tjenester, mikrotjenester og implementeringen af nye løsninger. Hvorfor sagde jeg før, at du har brug for erfaring, du har brug for kvalifikationer. Faktisk er SRE en af de blokerende stemmer i enhver arkitektur- og softwareløsning. Derfor skal en SRE som ingeniør først og fremmest ikke kun forstå, men også forstå, hvordan nogle specifikke beslutninger vil påvirke pålidelighed, stabilitet og forstå, hvordan dette forholder sig til forretningsbehov, og fra hvilket synspunkt dette kan være tilladt, og som det ikke er med.
Derfor er tiden inde til at tale om pålidelighedskriterier, som i SRE traditionelt defineres som SLA (Service Level Agreement). Mest sandsynligt et kendt udtryk. SLI (Service Level Indicator). SLO (Service Level Objective). Service Level Agreement er måske et væsentligt udtryk, især hvis du har arbejdet med netværk, udbydere og hosting. Dette er en generel aftale, der beskriver udførelsen af hele din tjeneste, sanktioner, nogle sanktioner for fejl, målinger, kriterier. Og SLI er selve tilgængelighedsmetrikken. Det vil sige, hvad SLI kan være: responstid fra tjenesten, antal fejl i procent. Dette kan være båndbredde, hvis vi taler om en form for filhosting. Når det kommer til genkendelsesalgoritmer, kan indikatoren endda være for eksempel rigtigheden af svaret. SLO (Service Level Objective) er henholdsvis en kombination af SLI-indikatoren, dens værdi og periode.
Lad os sige, at SLA kunne være sådan her. Tjenesten er tilgængelig 99,95 % af tiden hele året. Ellers vil 99 kritiske tekniske supportbilletter blive lukket inden for 3 timer pr. kvartal. Eller 85 % af forespørgslerne vil blive besvaret inden for 1,5 sekund hver måned. Det vil sige, at vi efterhånden er ved at forstå, at fejl og fejl er ganske normale. Det er en acceptabel situation, vi planlægger det, vi regner endda med det til en vis grad. Det vil sige, at SRE bygger systemer, der kan lave fejl, som skal reagere normalt på fejl, og som skal tage højde for dem. Og hvis det er muligt, bør de håndtere fejl på en sådan måde, at brugeren enten ikke bemærker dem, eller bemærker dem, men der er en form for løsning, så alt ikke falder helt fra hinanden.
For eksempel, hvis du uploader en video til YouTube, og YouTube ikke kan konvertere den med det samme, hvis videoen er for stor, hvis formatet ikke er optimalt, så vil anmodningen naturligvis ikke fejle med en timeout, YouTube vil ikke vise en 502 fejl, vil YouTube sige: "Vi har oprettet alt, din video bliver behandlet. Den er klar om cirka 10 minutter.” Dette er princippet om yndefuld nedbrydning, som for eksempel er kendt fra frontend-udvikling, hvis du nogensinde har gjort dette.
De næste termer, som vi vil tale om, som er meget vigtige for at arbejde med pålidelighed, med fejl, med forventninger, er MTBF og MTTR. MTBF er den gennemsnitlige tid mellem fejl. MTTR Mean Time To Recovery, gennemsnitlig tid til restitution. Det vil sige, hvor lang tid der gik fra det øjeblik, fejlen blev opdaget, fra det øjeblik fejlen opstod, til det øjeblik, tjenesten blev genoprettet til helt normal drift. MTBF korrigeres hovedsageligt ved at arbejde med kodekvalitet. Det vil sige, at SRE'er kan sige "nej". Og hele holdet skal forstå, at når SRE siger "nej", siger han det, ikke fordi han er skadelig, ikke fordi han er dårlig, men fordi ellers vil alle lide.
Igen er der en masse artikler, en masse metoder, mange måder, selv i den bog, som jeg så ofte refererer til, hvordan man sikrer sig, at andre udviklere ikke begynder at hade SRE. MTTR handler på den anden side om at arbejde med din SLO (Service Level Objective). Og det er for det meste automatisering. Fordi vores SLO for eksempel er en oppetid på 4 ni per kvartal. Det betyder, at vi på 3 måneder kan tillade 13 minutters nedetid. Og det viser sig, at vores MTTR umuligt kan være mere end 13 minutter. Hvis vi bruger 13 minutter på at reagere på mindst 1 nedetid, betyder det, at vi allerede har opbrugt hele budgettet for kvartalet. Vi overtræder SLO. 13 minutter til at reagere og rette en fejl er meget for en maskine, men meget lidt for en person. For når en person modtager en advarsel, når han reagerer, når han finder ud af fejlen, er det allerede et par minutter. Indtil en person forstår, hvordan man løser det, hvad man præcist skal rette, hvad man skal gøre, vil det tage et par minutter mere. Og faktisk, selvom du bare skal genstarte serveren, som det viser sig, eller hæve en ny node, så tager MTTR manuelt omkring 7-8 minutter. Når man automatiserer en proces, når MTTR meget ofte et sekund, nogle gange millisekunder. Google taler normalt om millisekunder, men i virkeligheden er tingene selvfølgelig ikke så gode.
Ideelt set bør en SRE næsten fuldstændig automatisere sit arbejde, fordi dette direkte påvirker MTTR, dets målinger, SLO for hele tjenesten og dermed virksomhedens overskud. Hvis tiden overskrides, bliver vi spurgt, om skylden ligger hos SRE. Heldigvis lægges skylden ikke på nogen. Og dette er en separat kultur, som kaldes balmeless postmortem, som vi ikke vil tale om i dag, men vi vil analysere på Slurm. Dette er et meget interessant emne, der kan tales meget om. Groft sagt, hvis den afsatte tid pr. kvartal overskrides, så er alle lidt skylden, hvilket betyder, at det ikke er produktivt at skyde skylden på alle, lad os i stedet måske ikke bebrejde nogen, men rette op på situationen og arbejde med det, vi har. Efter min erfaring er denne tilgang lidt fremmed for de fleste hold, især i Rusland, men den giver mening og fungerer meget godt. Derfor vil jeg til sidst anbefale artikler og litteratur, som du kan læse om dette emne. Eller kom til Slurm SRE.
Lad mig forklare. Hvis SLO-tiden for kvartalet overskrides, hvis nedetiden ikke var 13 minutter, men 15, hvem kan så være skyld i dette? Selvfølgelig kan SRE være skyld, fordi den tydeligvis har foretaget en dårlig commit eller implementering. Datacenteradministratoren kan være skyld i dette, fordi han kan have udført noget uplanlagt vedligeholdelse. Hvis datacenteradministratoren er skyld i dette, så er personen fra Ops også skyld i ikke at beregne vedligeholdelse ved aftale om SLO. Dette er fejlen hos lederen, den tekniske direktør eller en person, der underskrev datacenterkontrakten og ikke var opmærksom på, at datacentrets SLA ikke er designet til den nødvendige nedetid. Derfor er alle lidt skyld i denne situation. Og det betyder, at det ikke nytter noget at lægge skylden på nogen bestemt for denne situation. Men det skal selvfølgelig rettes. Det er derfor, der findes postmortem. Og hvis du læser for eksempel GitHub postmortems, og det her altid er en meget interessant, lille og uventet historie i hvert enkelt tilfælde, kan du erstatte, at ingen nogensinde siger, at netop denne person var skyld i det. Skylden pålægges altid specifikke mangelfulde processer.
Lad os gå videre til næste spørgsmål. Automatisering. Jeg plejer, når jeg taler om automatisering i andre sammenhænge, meget ofte at henvise til en tabel, der fortæller om, hvor lang tid man kan arbejde med at automatisere en opgave for ikke at tage længere tid at automatisere den, end man generelt sparer. Der er en fangst. Fangsten er, at når SRE'er automatiserer en opgave, sparer de ikke kun tid, de sparer penge, fordi automatisering direkte påvirker MTTR. De sparer så at sige moralen hos medarbejdere og udviklere, som også er en udtømmelig ressource. De reducerer rutinen. Og alt dette har en positiv effekt på arbejdet og som følge heraf på forretningen, selvom det ser ud til, at automatisering ikke giver mening med hensyn til tidsomkostninger.
Det gør det faktisk næsten altid, og der er meget få tilfælde, hvor det ikke kan betale sig at automatisere noget i SRE-rollen. Dernæst vil vi tale om det, der kaldes fejlbudget, budget for fejl. Faktisk viser det sig, at hvis du klarer dig væsentligt bedre end den SLO, du sætter for dig selv, er dette heller ikke særlig godt. Dette er ret dårligt, fordi SLO fungerer ikke kun som en nedre grænse, men også som en omtrentlig øvre grænse. Når du sætter dig selv en SLO på 99% tilgængelighed, og faktisk har 99,99%, viser det sig, at du har lidt plads til at eksperimentere, hvilket slet ikke vil skade forretningen, fordi du selv har bestemt det hele sammen, og du har denne plads, brug den ikke. Du har et budget for fejl, som i dit tilfælde ikke bliver brugt.
Hvad laver vi med det? Vi bruger det til bogstaveligt talt alt. Til test under produktionsforhold, til udrulning af nye funktioner, der kan påvirke ydeevnen, til udgivelser, til vedligeholdelse, til planlagte nedetider. Den modsatte regel gælder også: Hvis budgettet er opbrugt, kan vi ikke frigive noget nyt, for ellers overskrider vi SLO. Budgettet er allerede opbrugt, vi har frigivet noget, hvis det påvirker ydeevnen negativt, det vil sige, hvis det ikke er en form for fix, der i sig selv direkte øger SLO, så overskrider vi budgettet, og det er en dårlig situation , det kræver analyse, postmortem og muligvis en vis proceskorrektion.
Det vil sige, at det viser sig, at hvis selve tjenesten ikke fungerer godt, og SLO'en er brugt og budgettet ikke bruges på eksperimenter, ikke på nogen udgivelser, men alene, så i stedet for nogle interessante rettelser i stedet for interessante funktioner i stedet for interessante udgivelser. I stedet for at lave noget kreativt arbejde, bliver du nødt til at lave dumme rettelser for at få budgettet i orden igen, eller redigere SLO, og det er også en proces, der ikke bør ske for ofte.
Derfor viser det sig, at i en situation, hvor vi har mere budget til fejl, er alle interesserede: både SRE og udviklere. For udviklere betyder et stort budget for fejl, at de kan håndtere udgivelser, tests og eksperimenter. For SRE betyder et budget for fejl og indgåelse af dette budget, at de rent faktisk gør et godt stykke arbejde. Og det påvirker motivationen for en form for fælles arbejde. Hvis du lytter til dine SRE'er som udviklere, vil du have mere plads til at udføre godt arbejde og meget færre pligter.
Det viser sig, at eksperimenter i produktionen er en ret vigtig og næsten integreret del af SRE i store teams. Og det går normalt under navnet chaos engineering, som kommer fra holdet hos Netflix, der udgav et hjælpeprogram kaldet Chaos Monkey.
Chaos Monkey opretter forbindelse til CI/CD-pipelinen og crasher tilfældigt serveren i produktionen. Igen siger vi i SRE-strukturen, at en nedbrudt server ikke er dårlig i sig selv, det forventes. Og hvis det indgår i budgettet, er det acceptabelt og skader ikke virksomheden. Selvfølgelig har Netflix nok overflødige servere, nok replikering, til at alt dette kan ordnes, uden at brugeren som helhed selv bemærker det, og bestemt ingen forlader én server til ethvert budget.
Netflix havde på et tidspunkt et helt sæt af sådanne hjælpeprogrammer, hvoraf det ene, Chaos Gorilla, fuldstændig deaktiverer en af tilgængelighedszonerne i Amazon. Og sådanne ting hjælper godt med at identificere for det første skjulte afhængigheder, når det ikke er helt klart, hvad der påvirker hvad, hvad afhænger af hvad. Og dette, hvis du arbejder med en mikroservice, og dokumentationen ikke er helt perfekt, er dette måske bekendt for dig. Og igen hjælper dette med at fange fejl i koden, som du ikke kan fange under iscenesættelse, fordi enhver iscenesættelse ikke er en nøjagtig simulering, på grund af det faktum, at belastningsskalaen er anderledes, belastningsmønsteret er anderledes, udstyret er også, de fleste sandsynligt, andet. Spidsbelastninger kan også være uventede og uforudsigelige. Og sådan test, som igen ikke går ud over budgettet, hjælper meget godt med at fange fejl i infrastrukturen, som iscenesættelse, autotest og CI/CD-pipelines aldrig vil fange. Og så længe det hele er inkluderet i dit budget, gør det ikke noget, at din service er faldet der, selvom det virker meget skræmmende, serveren er gået ned, hvilket mareridt. Nej, det er normalt, det er godt, det hjælper med at fange fejl. Hvis du har et budget, kan du bruge det.
Spørgsmål: hvilken litteratur kan jeg anbefale? Listen er til sidst. Der er meget litteratur, jeg vil anbefale flere rapporter. Hvordan fungerer det, og om SRE fungerer i virksomheder uden eget softwareprodukt eller med minimal udvikling. For eksempel i en virksomhed, hvor hovedaktiviteten ikke er software. I en virksomhed, hvor hovedaktiviteten ikke er software, fungerer SRE nøjagtigt på samme måde som alle andre steder, for i en virksomhed skal du også bruge, selvom du ikke udvikler, softwareprodukter, du skal udrulle opdateringer, du skal ændre infrastrukturen, du skal vokse, du skal skalere. Og SRE'er hjælper med at identificere og forudsige mulige problemer i disse processer og kontrollere dem, efter at en vis vækst begynder, og forretningsbehov ændrer sig. For det er absolut ikke nødvendigt at engagere sig i softwareudvikling for at have SRE, hvis du har mindst flere servere, og du forventer mindst en vis vækst.
Det samme gælder små projekter, små organisationer, fordi store virksomheder har budget og plads til at eksperimentere. Men på samme tid kan alle disse frugter af eksperimenter bruges overalt, det vil sige, at SRE'er selvfølgelig dukkede op i Google, Netflix og Dropbox. Men samtidig kan små virksomheder og startups allerede læse komprimeret materiale, læse bøger og se rapporter. De begynder at høre om det her oftere, se på specifikke eksempler, jeg tror, okay, det kan virkelig være nyttigt, vi har også brug for det her, cool.
Det vil sige, at alt hovedarbejdet med at standardisere disse processer allerede er udført for dig. Alt du skal gøre er at definere SRE's rolle specifikt i din virksomhed og begynde at implementere alle disse praksisser, som igen allerede er blevet beskrevet. Det vil sige, ud fra nyttige principper for små virksomheder er dette altid definitionen af SLA, SLI, SLO. Hvis du ikke er involveret i software, så vil disse være interne SLA'er og interne SLO'er, internt budget for fejl. Dette fører næsten altid til nogle interessante diskussioner i teamet og i virksomheden, fordi det kan vise sig, at du bruger meget mere end nødvendigt på infrastruktur, på en eller anden form for organisering af ideelle processer, en ideel pipeline. Og disse 4 niere, som du har i IT-afdelingen, har du ikke rigtig brug for dem nu. Men samtidig var det muligt at bruge tid, bruge budgettet på fejl på noget andet.
Følgelig er overvågning og organisering af overvågning nyttig for en virksomhed af enhver størrelse. Og generelt er denne måde at tænke på, hvor fejl er noget acceptabelt, hvor der er et budget, hvor målsætninger eksisterer, igen nyttig for en virksomhed af enhver størrelse, startende fra en 3-personers startup.
Den sidste af de tekniske nuancer, vi kan tale om, er overvågning. For hvis vi taler om SLA, SLI, SLO, kan vi ikke forstå uden at overvåge, om vi passer ind i budgettet, om vi overholder vores Målsætninger, og hvordan vi påvirker den endelige SLA. Jeg har observeret mange gange, at overvågning sker på følgende måde: der er en vis værdi, for eksempel tidspunktet for en anmodning til serveren, den gennemsnitlige tid eller antallet af anmodninger til databasen. Han har en standard fastsat af ingeniøren. Hvis metrikken afviger fra normen, sendes en e-mail. Alt dette er som regel absolut nytteløst, fordi det fører til en sådan overmætning af advarsler, en overmætning af overvågningsmeddelelser, når en person for det første skal fortolke dem hver gang, dvs. bestemme, om den metriske værdi betyder behovet for en form for handling. Og for det andet holder han simpelthen op med at lægge mærke til alle disse advarsler, når der stort set ikke kræves handling fra ham. Det vil sige, at en god overvågningsregel og den allerførste regel ved implementering af SRE er, at en underretning først skal komme, når en handling er påkrævet.
I standardtilfældet er der 3 niveauer af hændelser. Der er alarmer, der er billetter, der er logfiler. Advarsler er alt, hvad der kræver øjeblikkelig handling fra dig. Det vil sige alt er i stykker, det skal rettes lige nu. Billetter er noget, der kræver afventende handling. Ja, du skal gøre noget, du skal gøre noget manuelt, automatiseringen har fejlet, men du behøver ikke at gøre det inden for de næste par minutter. Logs er alt, der ikke kræver handling, og generelt, hvis det går godt, vil ingen nogensinde læse dem. Det vil kun være nødvendigt at læse loggene, når det i retrospekt viser sig, at noget var gået i stykker i nogen tid, vi vidste ikke om det. Eller der skal laves en form for undersøgelse. Men generelt går alt, der ikke kræver nogen handling, til logfilerne.
Som en bieffekt af alt dette, hvis vi har identificeret, hvilke hændelser der kræver handlinger og godt har beskrevet, hvad disse handlinger skal være, betyder det, at handlingen kan automatiseres. Altså hvad der sker. Vi kommer fra en alarm. Lad os gå til handling. Lad os gå til beskrivelsen af denne handling. Og så bevæger vi os mod automatisering. Det vil sige, at enhver automatisering begynder med en reaktion på en begivenhed.
Fra overvågning går vi videre til et begreb kaldet Observabilitet. Der har også været lidt hype omkring dette ord de sidste par år. Og få mennesker forstår, hvad dette betyder uden for kontekst. Men hovedpointen er, at observerbarhed er en målestok for systemgennemsigtighed. Hvis noget gik galt, hvor hurtigt kan du så afgøre, hvad der præcist gik galt, og hvordan systemets tilstand var på det tidspunkt. Fra et kodesynspunkt: hvilken funktion fejlede, hvilken tjeneste fejlede. Hvad var tilstanden af for eksempel interne variabler, konfiguration. Fra et infrastrukturmæssigt synspunkt er dette i hvilken tilgængelighedszone fejlen opstod, og hvis du har en form for Kubernetes, så i hvilken pod fejlen opstod, hvad var tilstanden af poden. Og følgelig har Observability et direkte forhold til MTTR. Jo højere observerbarheden af tjenesten er, jo lettere er det at identificere fejlen, jo lettere er det at rette fejlen, jo lettere er det at automatisere fejlen, jo lavere er MTTR.
Hvis vi går videre til små virksomheder igen, spørger de meget ofte, selv nu, hvad man skal gøre med størrelsen på teamet, og om det er nødvendigt at ansætte en separat SRE i et lille team. Jeg har allerede talt om dette lidt tidligere. I de første udviklingsstadier af en startup eller for eksempel et team er dette slet ikke nødvendigt, fordi SRE kan gøres til en overgangsrolle. Og det vil sætte lidt liv i holdet, for der er i hvert fald en vis diversitet. Og plus vil det forberede folk på, at når de vokser, vil SRE's ansvar generelt ændre sig meget betydeligt. Hvis du ansætter en person, så har han selvfølgelig nogle forventninger. Og disse forventninger vil ikke ændre sig over tid, men kravene vil ændre sig rigtig meget. Derfor er det ret svært at ansætte en SRE i de tidlige stadier. Det er meget nemmere at opdrage din egen. Men det er værd at tænke over.
Den eneste undtagelse er sandsynligvis, når der er meget strenge og veldefinerede højdekrav. Det vil sige, at i tilfælde af en startup, kan dette være en form for pres fra investorer, en form for prognose for vækst flere gange på én gang. Så er det generelt berettiget at ansætte en SRE, fordi det kan berettiges. Vi har vækstkrav, vi har brug for en person, der vil være ansvarlig for, at intet bryder med en sådan vækst.
Et spørgsmål mere. Hvad skal man gøre, når udviklere flere gange skærer en funktion, der består test, men bryder produktet, indlæser databasen, bryder andre funktioner, hvilken proces, der skal implementeres. Derfor indføres der i dette tilfælde et budget for fejl. Og nogle tjenester, nogle funktioner testes straks i produktionen. Dette kan være en kanariefugl, når kun et lille antal brugere, men allerede i produktion, implementerer en funktion, men med en forventning om, at hvis noget går i stykker, for eksempel for en halv procent af alle brugere, vil det stadig passe inden for budget for fejl. Følgelig, ja, der vil være en fejl, for nogle brugere vil alt gå i stykker, men vi har allerede sagt, at dette er normalt.
Der var et spørgsmål om SRE-værktøjer. Det vil sige, er der noget specifikt, SRE'er ville bruge, som alle andre ikke ville? Faktisk er der nogle højt specialiserede hjælpeprogrammer, der er noget software, der for eksempel simulerer belastninger eller laver kanariske A/B-tests. Men dybest set er SRE-værktøj, hvad dine udviklere allerede bruger. Fordi SRE interagerer direkte med udviklingsteamet. Og har man forskellige værktøjer, viser det sig, at det tager tid at synkronisere. Især hvis SRE'er arbejder i store teams, i store virksomheder, hvor der kan være flere teams, vil virksomhedsdækkende standardisering være meget nyttig her, for hvis 50 teams bruger 50 forskellige hjælpeprogrammer, betyder det, at SRE'en skal kende dem alle. Og det vil selvfølgelig aldrig ske. Og kvaliteten af arbejdet, kvaliteten af kontrol af i hvert fald nogle af holdene vil falde betydeligt.
Vores webinar er efterhånden ved at være slut. Det lykkedes mig at fortælle dig nogle grundlæggende ting. Selvfølgelig kan intet om SRE fortælles og forstås på en time. Men jeg håber, at det lykkedes mig at formidle denne måde at tænke på, de vigtigste nøglepunkter. Og så, hvis du er interesseret, kan du dykke dybere ned i emnet, studere på egen hånd og se på, hvordan det bliver implementeret af andre mennesker, i andre virksomheder. Og derfor, i begyndelsen af februar, kom til os på Slurm SRE.
Slurm SRE er et tre-dages intensivt kursus, der vil dække cirka det, jeg taler om nu, men med meget større dybde, med reelle cases, med praksis, er hele intensiven rettet mod praktisk arbejde. Folk vil blive opdelt i hold. I vil alle arbejde på rigtige sager. Derfor har vi instruktører fra Booking.com Ivan Kruglov og Ben Tyler. Vi har en vidunderlig Evgeniy Varabbas fra Google, fra San Francisco. Og jeg vil også fortælle dig noget. Så husk at komme og besøge os.
Så en liste over referencer. Der er links på SRE. på den samme bog, eller rettere sagt på 2 bøger om SRE, skrevet af Google. Endnu en , hvor vilkårene og deres anvendelse er forklaret lidt mere detaljeret. De næste 3 er rapporter om SRE i forskellige virksomheder. Først - , dette er en keynote fra Ben Trainer fra Google. Anden - . Den tredje handler igen om . Fjerde rapport fra , som kun har 5 nøgle SRE-medarbejdere i 190 lande. Det er meget interessant at se på alt dette, for ligesom DevOps betyder meget forskellige ting for forskellige virksomheder og endda forskellige teams, har SRE meget forskellige ansvarsområder, selv i virksomheder af samme størrelse.
2 flere links om principperne for kaosteknik: , . Og til sidst er der 3 lister fra Awesome Lists-serien om om og om . Listen på SRE er utrolig stor, du behøver ikke at gennemgå det hele, der er omkring 200 artikler. Jeg anbefaler stærkt artiklerne om kapacitetsplanlægning og ulastelig postmortem.
Interessant artikel:
Tak fordi du lyttede til mig hele tiden. Jeg håber du har lært noget. Jeg håber, du har nok materialer til at lære endnu mere. Og vi ses senere. Forhåbentlig i februar.
Webinaret blev afholdt af Eduard Medvedev.
PS: for dem, der kan lide at læse, gav Eduard en liste over referencer. De, der foretrækker at forstå det i praksis, er velkomne kl .
Kilde: www.habr.com