Nettseminaret har dårlig lyd, så vi laget en transkripsjon.
Mitt navn er Medvedev Eduard. I dag skal jeg snakke om hva SRE er, hvordan SRE fremstod, hva er arbeidskriteriene for SRE-ingeniører, litt om pålitelighetskriterier, litt om overvåking av det. Vi går over toppen, for du kan ikke fortelle mye på en time, men jeg vil gi deg materiell for ytterligere vurdering, og vi venter alle på deg kl. . i Moskva i slutten av januar.
La oss først snakke om hva SRE – Site Reliability Engineering – er. Og hvordan det fremsto som en egen posisjon, som en egen retning. Det hele startet med at i tradisjonelle utviklingskretser er Dev og Ops to helt forskjellige lag, vanligvis med to helt forskjellige mål. Målet til utviklingsteamet er å rulle ut nye funksjoner for å møte forretningsbehov. Målet til Ops-teamet er å sørge for at alt fungerer og at ingenting går i stykker. Åpenbart er disse målene direkte i strid med hverandre: slik at alt fungerer og ingenting går i stykker, er det bedre å rulle ut nye funksjoner så lite som mulig. På grunn av dette oppstår det mange interne konflikter, som metodikken nå kalt DevOps prøver å løse.
Problemet er at vi ikke har en klar definisjon av DevOps og en klar implementering av DevOps. Jeg talte på en konferanse i Jekaterinburg for to år siden, og inntil nå begynte DevOps-delen med rapporten «Hva er DevOps». I 2 er devops snart 2017 år, men vi krangler fortsatt om hva det er. Og dette er en veldig merkelig situasjon som Google prøvde å løse for noen år siden.
I 2016 ga Google ut en bok kalt «Site Reliability Engineering». Og faktisk var det med denne boken SRE-bevegelsen startet. SRE er et spesifikt alternativ for å implementere DevOps-paradigmet i et spesifikt selskap. SRE-ingeniører satte seg som mål å sikre pålitelig drift av systemene. De er hovedsakelig hentet fra utviklere, noen ganger fra administratorer med sterk utviklingsbakgrunn. Og de gjør det systemadministratorer pleide å gjøre, men en sterk bakgrunn i utvikling og kunnskap om systemet fra et kodesynspunkt fører til at disse menneskene ikke er tilbøyelige til rutinemessig administrativt arbeid, men er tilbøyelige til automatisering.
Det viser seg at DevOps-paradigmet i SRE-team implementeres ved at det er SRE-ingeniører som løser strukturelle problemer. Her er den, den samme forbindelsen mellom Dev og Ops som folk har snakket om i 8 år. Rollen til en SRE er lik rollen til en arkitekt ved at nybegynnere ikke blir SREer. Folk i begynnelsen av karrieren har ennå ikke noen erfaring og har ikke den nødvendige bredden av kunnskap. Fordi SRE krever en svært sofistikert kunnskap om nøyaktig hva og når nøyaktig kan gå galt. Derfor trengs det som regel en eller annen form for erfaring her, både i og utenfor bedriften.
De spør om forskjellen mellom SRE og devops vil bli beskrevet. Hun har nettopp blitt beskrevet. Vi kan snakke om SREs plass i organisasjonen. I motsetning til den klassiske DevOps-tilnærmingen, hvor Ops fortsatt er en egen avdeling, er SRE en del av utviklingsteamet. De er involvert i produktutvikling. Det er til og med en tilnærming der SRE er en rolle som går fra en utvikler til en annen. De deltar i kodegjennomganger på samme måte som for eksempel UX-designere, utviklere selv, og noen ganger produktansvarlige. SRE-er opererer på samme nivå. Vi trenger deres godkjenning, vi trenger deres vurdering, slik at SRE sier for hver distribusjon: «Ok, denne utrullingen, dette produktet vil ikke påvirke påliteligheten negativt. Og hvis det gjør det, vil det være innenfor noen akseptable grenser.» Vi skal snakke om dette også.
Følgelig har SRE et veto mot kodeendringer. Og generelt fører dette også til noen små konflikter dersom SRE implementeres feil. I akkurat den boken om Site Reliability Engineering forteller mange deler, til og med mer enn én, hvordan man unngår disse konfliktene.
Folk spør hvordan SRE forholder seg til informasjonssikkerhet. SRE er ikke direkte involvert i informasjonssikkerhet. For det meste i store selskaper gjøres dette av enkeltpersoner, testere og analytikere. Men SRE samhandler også med dem i den forstand at noen operasjoner, noen forplikter seg, noen distribusjoner som påvirker sikkerheten også kan påvirke tilgjengeligheten til produktet. Derfor har SRE generelt interaksjon med alle team, inkludert sikkerhetsteam, inkludert analytikere. Derfor er SRE-er hovedsakelig nødvendig når man prøver å implementere DevOps, men byrden på utviklere blir for stor. Det vil si at utviklingsteamet selv ikke takler lenger at de nå også må ha ansvar for Ops. Og en egen rolle dukker opp. Denne rollen er planlagt i budsjettet. Noen ganger er denne rollen innebygd i størrelsen på teamet, en egen person dukker opp, noen ganger blir en av utviklerne den. Slik dukker den første SRE opp på laget.
Systemkompleksitet som påvirkes av SRE, kompleksitet som påvirker driftssikkerheten, kan være nødvendig eller tilfeldig. Nødvendig kompleksitet er når kompleksiteten til produktet øker i den grad nye produktfunksjoner krever. Tilfeldig kompleksitet er når kompleksiteten i systemet øker, men produktfunksjonen og forretningskravene påvirker ikke dette direkte. Det viser seg at enten har utvikleren gjort en feil et sted, eller at algoritmen ikke er optimal, eller at det introduseres noen ekstra interesser som øker kompleksiteten til produktet unødvendig. En god SRE bør alltid unngå denne situasjonen. Det vil si at enhver commit, enhver distribusjon, enhver pull-forespørsel som øker kompleksiteten på grunn av tilfeldige tillegg, bør blokkeres.
Spørsmålet er hvorfor ikke bare ansette en ingeniør, en systemadministrator med mye kunnskap, for å bli med på laget. En utvikler i rollen som ingeniør, blir vi fortalt, er ikke den mest optimale personalløsningen. En utvikler i rollen som ingeniør er ikke alltid den optimale personalløsningen, men poenget her er at en utvikler som driver med Ops har litt mer lyst til automatisering, har litt mer kunnskap og ferdigheter for å kunne implementere dette automasjon. Og følgelig reduserer vi ikke bare tiden for noen spesifikke operasjoner, ikke bare rutinen, men også slike viktige forretningsparametere som MTTR (Mean Time To Recovery, recovery time). Dermed, og vi skal også snakke om dette litt senere, sparer vi penger til organisasjonen.
La oss nå snakke om kriteriene for SRE-arbeid. Og først og fremst om pålitelighet. I små selskaper og startups hender det ofte at folk antar at hvis tjenesten er godt skrevet, hvis produktet er skrevet godt og riktig, så vil det fungere, det vil ikke gå i stykker. Det er det, vi skriver god kode, så det er ingenting å bryte. Koden er veldig enkel, det er ingenting å bryte. Dette er omtrent de samme menneskene som sier at vi ikke trenger tester, for se, dette er tre VPI-metoder, hvorfor bry deg?
Alt dette er selvfølgelig feil. Og disse menneskene blir veldig ofte såret av denne typen kode i praksis, fordi ting går i stykker. Ting går noen ganger i stykker på de mest uforutsigbare måter. Noen ganger sier folk nei, det vil aldri skje. Og det skjer fortsatt. Skjer ganske ofte. Og det er derfor ingen noen gang streber etter 100 % tilgjengelighet, fordi 100 % tilgjengelighet aldri skjer. Dette er normen. Og det er derfor vi alltid snakker om niere når vi snakker om tjenestetilgjengelighet. 2 niere, 3 niere, 4 niere, 5 niere. Oversetter vi dette til nedetid, så er for eksempel 5 nire litt mer enn 5 minutter nedetid per år, 2 nire er 3,5 dager nedetid.
Men det er åpenbart at det på et tidspunkt er en nedgang i POI og avkastning på investeringen. Å gå fra to niere til tre niere betyr å redusere nedetiden med mer enn 3 dager. Å gå fra fire niere til fem reduserer nedetiden med 47 minutter per år. Og det viser seg at dette kanskje ikke er kritisk for næringslivet. Og generelt er den nødvendige påliteligheten ikke et teknisk problem, for det første er det et forretningsproblem, det er et produktproblem. Hvilket nivå av nedetid er akseptabelt for brukere av produktet, hva forventer de, hvor mye betaler de, for eksempel hvor mye penger taper de, hvor mye penger taper systemet.
Et viktig spørsmål er hva som er påliteligheten til de resterende komponentene. Fordi forskjellen mellom 4 og 5 niere vil ikke være synlig på en smarttelefon med 2 pålitelighetsniere. Grovt sett, hvis noe går i stykker på en smarttelefon i tjenesten din 10 ganger i året, har det mest sannsynlig skjedd 8 ganger sammenbruddet på OS-siden. Brukeren er vant til dette, og vil ikke ta hensyn til det en ekstra gang i året. Det er nødvendig å sammenligne prisen på økende pålitelighet og økende fortjeneste.
Bare i boken om SRE er det et godt eksempel på å øke til 4 niere fra 3 niere. Det viser seg at økningen i tilgjengelighet er litt mindre enn 0,1 %. Og hvis tjenestens inntekt er $1 million per år, er inntektsøkningen $900. Hvis å øke tilgjengeligheten med ni koster oss mindre enn $900 per år, gir økningen økonomisk mening. Hvis det koster mer enn 900 dollar i året, gir det ikke lenger mening, fordi økningen i inntektene rett og slett ikke kompenserer for lønnskostnader og ressurskostnader. Og 3 niere vil være nok for oss.
Dette er selvfølgelig et forenklet eksempel hvor alle forespørsler er like. Og fra 3 nire til 4 nire er det ganske enkelt å gå, men samtidig er for eksempel å gå fra 2 nire til 3 allerede en besparelse på 9 tusen dollar, det kan gi økonomisk mening. Naturligvis, i virkeligheten, er en manglende registrering av en forespørsel verre enn en manglende visning av en side; forespørsler har forskjellig vekt. De kan ha helt andre kriterier fra et forretningssynspunkt, men likevel, som regel, hvis vi ikke snakker om noen spesifikke tjenester, er dette en ganske pålitelig tilnærming.
Vi fikk spørsmål om SRE er en av koordinatorene ved valg av arkitektonisk løsning for tjenesten. Dette er akseptabelt med tanke på integrering i eksisterende infrastruktur slik at det ikke går tapt i stabiliteten. Ja, SRE-er påvirker pull-forespørsler, forpliktelser, utgivelser på samme måte; de påvirker arkitekturen, implementeringen av nye tjenester, mikrotjenester og implementeringen av nye løsninger. Hvorfor sa jeg før at du trenger erfaring, du trenger kvalifikasjoner. Faktisk er SRE en av de blokkerende stemmene i enhver arkitektur- og programvareløsning. Følgelig må en SRE som ingeniør først og fremst ikke bare forstå, men også forstå hvordan noen spesifikke beslutninger vil påvirke pålitelighet, stabilitet, og forstå hvordan dette forholder seg til forretningsbehov, og fra hvilket synspunkt dette kan være tillatt, og som det ikke er med.
Derfor er det nå på tide å snakke om pålitelighetskriterier, som i SRE tradisjonelt defineres som SLA (Service Level Agreement). Mest sannsynlig et kjent begrep. SLI (Service Level Indicator). SLO (Service Level Objective). Service Level Agreement er kanskje et viktig begrep, spesielt hvis du har jobbet med nettverk, leverandører og hosting. Dette er en generell avtale som beskriver ytelsen til hele tjenesten din, straffer, noen straffer for feil, beregninger, kriterier. Og SLI er selve tilgjengelighetsberegningen. Det vil si hva SLI kan være: responstid fra tjenesten, antall feil i prosent. Dette kan være båndbredde hvis vi snakker om en slags filhosting. Hvis vi snakker om gjenkjennelsesalgoritmer, kan indikatoren til og med være for eksempel riktigheten av svaret. SLO (Service Level Objective) er henholdsvis en kombinasjon av SLI-indikatoren, dens verdi og periode.
La oss si at SLA kan være slik. Tjenesten er tilgjengelig 99,95 % av tiden hele året. Eller 99 kritiske billetter til teknisk støtte vil bli stengt innen 3 timer per kvartal. Eller 85 % av spørsmålene vil bli besvart innen 1,5 sekunder hver måned. Det vil si at vi gradvis begynner å forstå at feil og feil er ganske normalt. Dette er en akseptabel situasjon, vi planlegger for det, vi regner til og med til en viss grad med det. Det vil si at SRE bygger systemer som kan gjøre feil, som må reagere normalt på feil, og som må ta hensyn til dem. Og hvis mulig bør de håndtere feil på en slik måte at brukeren enten ikke legger merke til dem, eller legger merke til dem, men det er en slags løsning slik at alt ikke faller helt fra hverandre.
For eksempel, hvis du laster opp en video til YouTube, og YouTube ikke kan konvertere den med en gang, hvis videoen er for stor, hvis formatet ikke er optimalt, vil forespørselen naturligvis ikke mislykkes med et tidsavbrudd, YouTube vil ikke vise en 502 feil, vil YouTube si: "Vi har opprettet alt, videoen din blir behandlet. Den vil være klar om 10 minutter.» Dette er prinsippet om grasiøs degradering, som er kjent for eksempel fra front-end-utvikling hvis du noen gang har gjort dette.
De neste begrepene vi skal snakke om, som er svært viktige for å jobbe med pålitelighet, med feil, med forventninger, er MTBF og MTTR. MTBF er gjennomsnittstiden mellom feil. MTTR gjennomsnittlig tid til restitusjon, gjennomsnittlig tid til restitusjon. Det vil si hvor lang tid som gikk fra det øyeblikket feilen ble oppdaget, fra det øyeblikket feilen dukket opp til det øyeblikket tjenesten ble gjenopprettet til helt normal drift. MTBF korrigeres hovedsakelig ved å jobbe med kodekvalitet. Det vil si det faktum at SRE-er kan si «nei». Og hele teamet må forstå at når SRE sier «nei», sier han det ikke fordi han er skadelig, ikke fordi han er dårlig, men fordi ellers vil alle lide.
Igjen, det er mange artikler, mange metoder, mange måter, selv i selve boken som jeg så ofte refererer til, hvordan man kan sørge for at andre utviklere ikke begynner å hate SRE. MTTR, derimot, handler om å jobbe med din SLO (Service Level Objective). Og dette er for det meste automatisering. Fordi for eksempel vår SLO er en oppetid på 4 niere per kvartal. Dette betyr at vi på 3 måneder kan tillate 13 minutters nedetid. Og det viser seg at vår MTTR umulig kan være mer enn 13 minutter. Hvis vi bruker 13 minutter på å reagere på minst 1 nedetid, betyr dette at vi allerede har brukt opp hele budsjettet for kvartalet. Vi bryter SLO. 13 minutter å reagere og rette på en feil er mye for en maskin, men veldig lite for en person. For når en person mottar et varsel, når han reagerer, når han finner ut av feilen, er det allerede noen få minutter. Inntil en person forstår hvordan man fikser det, hva man skal fikse, hva man skal gjøre, vil det ta noen minutter til. Og faktisk, selv om du bare trenger å starte serveren på nytt, som det viser seg, eller heve en ny node, tar MTTR manuelt omtrent 7-8 minutter. Når du automatiserer en prosess, når MTTR veldig ofte et sekund, noen ganger millisekunder. Google snakker vanligvis om millisekunder, men i virkeligheten er det selvfølgelig ikke så bra.
Ideelt sett bør en SRE nesten fullstendig automatisere arbeidet sitt, fordi dette direkte påvirker MTTR, dets beregninger, SLO for hele tjenesten, og følgelig forretningsfortjeneste. Dersom tiden overskrides, blir vi spurt om skylden ligger hos SRE. Heldigvis legges ikke skylden på noen. Og dette er en egen kultur, som kalles balmeless postmortem, som vi ikke skal snakke om i dag, men vi skal analysere på Slurm. Dette er et veldig interessant tema som kan snakkes mye om. Grovt sett, hvis den tildelte tiden per kvartal overskrides, så får alle litt skylden, noe som betyr at det å skylde på alle ikke er produktivt, la oss i stedet kanskje ikke skylde på noen, men rette opp situasjonen og jobbe med det vi har. Etter min erfaring er denne tilnærmingen litt fremmed for de fleste lag, spesielt i Russland, men den gir mening og fungerer veldig bra. Derfor vil jeg på slutten anbefale artikler og litteratur som du kan lese om dette emnet. Eller kom til Slurm SRE.
La meg forklare. Hvis SLO-tiden for kvartalet overskrides, hvis nedetiden ikke var 13 minutter, men 15, hvem kan da ha skylden for dette? Selvfølgelig kan SRE være feil fordi det tydeligvis gjorde en dårlig forpliktelse eller distribusjon. Datasenteradministratoren kan ha skylden for dette, fordi han kan ha utført noe uplanlagt vedlikehold. Hvis datasenteradministratoren har skylden for dette, så er også personen fra Ops skyld i at han ikke har beregnet vedlikehold ved avtale om SLO. Dette er feilen til lederen, teknisk direktør eller noen som signerte datasenterkontrakten og ikke tok hensyn til det faktum at datasenterets SLA ikke er designet for den nødvendige nedetiden. Følgelig har alle litt skylden for denne situasjonen. Og det betyr at det ikke er noen vits i å legge skylden på noen spesielt for denne situasjonen. Men det må selvfølgelig rettes opp. Det er derfor postmortem eksisterer. Og hvis du leser for eksempel GitHub postmortems, og dette alltid er en veldig interessant, liten og uventet historie i hvert enkelt tilfelle, kan du erstatte at ingen noen gang sier at denne personen hadde skylden. Det legges alltid skylden på spesifikke mangelfulle prosesser.
La oss gå videre til neste spørsmål. Automasjon. Jeg pleier, når jeg snakker om automatisering i andre sammenhenger, veldig ofte å referere til en tabell som forteller om hvor lenge man kan jobbe med å automatisere en oppgave for ikke å bruke mer tid på å automatisere den enn man vanligvis sparer. Det er en hake. Fangsten er at når SRE-er automatiserer en oppgave, sparer de ikke bare tid, de sparer penger fordi automatisering direkte påvirker MTTR. De sparer så å si moralen til ansatte og utviklere, som også er en uttømmelig ressurs. De reduserer rutinen. Og alt dette har en positiv effekt på arbeidet og, som et resultat, på virksomheten, selv om det ser ut til at automatisering ikke gir mening når det gjelder tidskostnader.
Faktisk gjør det nesten alltid det, og det er svært få tilfeller der det ikke er verdt å automatisere noe i SRE-rollen. Deretter skal vi snakke om det som kalles feilbudsjett, budsjett for feil. Faktisk viser det seg at dersom du gjør det betydelig bedre enn SLO du setter for deg selv, er dette heller ikke særlig bra. Dette er ganske dårlig, fordi SLO fungerer ikke bare som en nedre grense, men også som en omtrentlig øvre grense. Når du setter deg en SLO på 99 % tilgjengelighet, og faktisk har 99,99 %, viser det seg at du har litt plass til eksperimentering, noe som ikke vil skade virksomheten i det hele tatt, fordi du selv har bestemt dette til sammen, og du har denne plassen ikke bruk den. Du har et budsjett for feil, som i ditt tilfelle ikke blir brukt.
Hva gjør vi med det? Vi bruker det til bokstavelig talt alt. For testing i produksjonsforhold, for utrulling av nye funksjoner som kan påvirke ytelsen, for utgivelser, for vedlikehold, for planlagte nedetider. Den motsatte regelen gjelder også: hvis budsjettet er oppbrukt kan vi ikke gi ut noe nytt, for ellers overskrider vi SLO. Budsjettet er allerede oppbrukt, vi har gitt ut noe, hvis det påvirker ytelsen negativt, det vil si hvis det ikke er en form for løsning som i seg selv direkte øker SLO, så går vi over budsjettet, og dette er en dårlig situasjon , krever det analyse , postmortem og muligens noe prosesskorreksjon.
Det vil si at det viser seg at hvis selve tjenesten ikke fungerer bra, og SLO brukes og budsjettet ikke brukes på eksperimenter, ikke på noen utgivelser, men på egen hånd, så i stedet for noen interessante rettelser, i stedet for interessante funksjoner, i stedet for interessante utgivelser. I stedet for å gjøre noe kreativt arbeid, må du gjøre dumme rettinger for å få orden på budsjettet igjen, eller redigere SLO, og dette er også en prosess som ikke bør skje for ofte.
Derfor viser det seg at i en situasjon hvor vi har mer budsjett for feil, er alle interessert: både SRE og utviklere. For utviklere betyr et stort budsjett for feil at de kan håndtere utgivelser, tester og eksperimenter. For SRE betyr et budsjett for feil og inngåelse av dette budsjettet at de faktisk gjør en god jobb. Og dette påvirker motivasjonen for en slags felles arbeid. Hvis du lytter til SRE-ene dine som utviklere, vil du ha mer plass til å gjøre godt arbeid og mye mindre gjøremål.
Det viser seg at eksperimenter i produksjon er en ganske viktig og nesten integrert del av SRE i store team. Og det går vanligvis under navnet chaos engineering, som kommer fra teamet hos Netflix som ga ut et verktøy kalt Chaos Monkey.
Chaos Monkey kobler til CI/CD-rørledningen og krasjer tilfeldig serveren i produksjon. Igjen, i SRE-strukturen sier vi at en krasjet server ikke er dårlig i seg selv, det er forventet. Og hvis det er inkludert i budsjettet, er det akseptabelt og skader ikke virksomheten. Selvfølgelig har Netflix nok redundante servere, nok replikering, til at alt dette kan fikses uten at brukeren som helhet merker det, og absolutt ingen forlater en server for et hvilket som helst budsjett.
Netflix hadde på en gang et helt sett med slike verktøy, hvorav ett, Chaos Gorilla, deaktiverer en av tilgjengelighetssonene i Amazon fullstendig. Og slike ting hjelper godt med å identifisere for det første skjulte avhengigheter, når det ikke er helt klart hva som påvirker hva, hva som avhenger av hva. Og dette, hvis du jobber med en mikrotjeneste og dokumentasjonen ikke er helt perfekt, kan dette være kjent for deg. Og igjen, dette bidrar til å fange opp feil i koden som du ikke kan fange under iscenesettelsen, fordi enhver iscenesettelse ikke er en nøyaktig simulering, på grunn av det faktum at belastningsskalaen er forskjellig, belastningsmønsteret er forskjellig, utstyret er også, de fleste sannsynlig, annet. Toppbelastninger kan også være uventede og uforutsigbare. Og slik testing, som igjen ikke går utover budsjettet, hjelper veldig godt til å fange opp feil i infrastrukturen som iscenesettelse, autotester og CI/CD-rørledninger aldri vil fange opp. Og så lenge dette er inkludert i budsjettet ditt, spiller det ingen rolle at tjenesten din har falt der, selv om det virker veldig skummelt, serveren har krasjet, for et mareritt. Nei, det er normalt, det er bra, det hjelper med å fange opp feil. Hvis du har et budsjett, kan du bruke det.
Spørsmål: hvilken litteratur kan jeg anbefale? Listen er på slutten. Det er mye litteratur, jeg vil anbefale flere rapporter. Hvordan det fungerer og om SRE fungerer i bedrifter uten eget programvareprodukt eller med minimal utvikling. For eksempel i en bedrift der hovedaktiviteten ikke er programvare. I en bedrift, der hovedaktiviteten ikke er programvare, fungerer SRE nøyaktig på samme måte som alle andre steder, for i en bedrift må du også bruke, selv om du ikke utvikler, programvareprodukter, du må rulle ut oppdateringer, du trenger å endre infrastrukturen, du må vokse, du må skalere. Og SRE-er hjelper til med å identifisere og forutsi mulige problemer i disse prosessene og kontrollere dem etter at en viss vekst begynner og forretningsbehov endres. For det er absolutt ikke nødvendig å drive med programvareutvikling for å ha SRE, hvis du har minst flere servere og forventer minst en viss vekst.
Det samme gjelder små prosjekter, små organisasjoner, fordi store selskaper har budsjett og rom for eksperimentering. Men samtidig kan alle disse fruktene av eksperimenter brukes hvor som helst, det vil si at SRE-er selvfølgelig dukket opp i Google, Netflix og Dropbox. Men samtidig kan små selskaper og startups allerede lese komprimert materiale, lese bøker og se rapporter. De begynner å høre om dette oftere, ser på konkrete eksempler, jeg tror, ok, dette kan virkelig være nyttig, vi trenger dette også, kult.
Det vil si at alt hovedarbeidet med å standardisere disse prosessene allerede er gjort for deg. Alt du trenger å gjøre er å definere rollen til SRE spesifikt i din bedrift og begynne å faktisk implementere alle disse praksisene, som igjen allerede er beskrevet. Det vil si at fra nyttige prinsipper for små selskaper er dette alltid definisjonen av SLA, SLI, SLO. Hvis du ikke er involvert i programvare, vil dette være interne SLAer og interne SLOer, internt budsjett for feil. Dette fører nesten alltid til noen interessante diskusjoner i teamet og i virksomheten, fordi det kan vise seg at du bruker mye mer enn nødvendig på infrastruktur, på en eller annen form for organisering av ideelle prosesser, en ideell pipeline. Og disse 4 nine som du har i IT-avdelingen, du trenger dem egentlig ikke nå. Men samtidig var det mulig å bruke tid, bruke budsjettet på feil på noe annet.
Følgelig er overvåking og organisering av overvåking nyttig for et selskap av enhver størrelse. Og generelt sett er denne måten å tenke på, hvor feil er noe akseptabelt, hvor det er et budsjett, der mål eksisterer, igjen nyttig for et selskap av alle størrelser, fra en 3-person oppstart.
Den siste av de tekniske nyansene vi kan snakke om er overvåking. For hvis vi snakker om SLA, SLI, SLO, kan vi ikke forstå uten å overvåke om vi passer inn i budsjettet, om vi overholder våre mål og hvordan vi påvirker den endelige SLA. Jeg har observert mange ganger at overvåking skjer på følgende måte: det er en viss verdi, for eksempel tidspunktet for en forespørsel til serveren, gjennomsnittlig tid eller antall forespørsler til databasen. Han har en standard fastsatt av ingeniøren. Hvis beregningen avviker fra normen, sendes en e-post. Alt dette er som regel helt ubrukelig fordi det fører til en slik overmetning av varsler, en overmetning av overvåkingsmeldinger, når en person for det første må tolke dem hver gang, det vil si bestemme om den metriske verdien betyr behovet for en slags handling. Og for det andre slutter han rett og slett å legge merke til alle disse varslene, når det i utgangspunktet ikke kreves noen handling fra ham. Det vil si at en god overvåkingsregel og den aller første regelen ved implementering av SRE er at et varsel kun skal komme når det kreves en handling.
I standardtilfellet er det 3 nivåer av hendelser. Det er varsler, det er billetter, det er logger. Varsler er alt som krever umiddelbar handling fra deg. Det vil si at alt er ødelagt, det må fikses akkurat nå. Billetter er noe som krever avventende handling. Ja, du må gjøre noe, du må gjøre noe manuelt, automatisering har mislyktes, men du trenger ikke å gjøre det i løpet av de neste minuttene. Logger er alt som ikke krever handling, og generelt, hvis ting går bra, vil ingen noen gang lese dem. Det vil være nødvendig å lese loggene først når det i ettertid viser seg at noe var ødelagt en stund, vi visste ikke om det. Eller det må gjøres en form for undersøkelse. Men generelt går alt som ikke krever noen handling til loggene.
Som en bieffekt av alt dette, hvis vi har identifisert hvilke hendelser som krever handlinger og har beskrevet godt hva disse handlingene skal være, betyr dette at handlingen kan automatiseres. Det vil si hva som skjer. Vi kommer fra et varsel. La oss gå til handling. La oss gå til beskrivelsen av denne handlingen. Og så går vi mot automatisering. Det vil si at enhver automatisering begynner med en reaksjon på en hendelse.
Fra overvåking går vi videre til et begrep som heter Observabilitet. Det har også vært litt hype rundt dette ordet de siste årene. Og få mennesker forstår hva dette betyr utenfor kontekst. Men hovedpoenget er at observerbarhet er en beregning av systemgjennomsiktighet. Hvis noe gikk galt, hvor raskt kan du finne ut hva som gikk galt og hvordan systemet var i det øyeblikket. Fra et kodesynspunkt: hvilken funksjon feilet, hvilken tjeneste mislyktes. Hva var tilstanden til for eksempel interne variabler, konfigurasjon. Fra et infrastruktursynspunkt er dette i hvilken tilgjengelighetssone feilen oppstod, og hvis du har en slags Kubernetes, så i hvilken pod feilen oppstod, hva var tilstanden til poden. Og følgelig har Observability et direkte forhold til MTTR. Jo høyere observerbarhet tjenesten har, jo lettere er det å identifisere feilen, jo lettere er det å fikse feilen, jo lettere er det å automatisere feilen, jo lavere er MTTR.
Går vi over til små bedrifter igjen, spør de veldig ofte, selv nå, hva de skal gjøre med størrelsen på teamet, og om det er nødvendig å ansette en egen SRE i et lite team. Jeg har allerede snakket om dette litt tidligere. I de første stadiene av utviklingen av en startup eller for eksempel et team, er dette slett ikke nødvendig, fordi SRE kan gjøres til en overgangsrolle. Og dette vil live opp laget litt, for det er i hvert fall litt mangfold. Og i tillegg vil det forberede folk på det faktum at med vekst, generelt, vil ansvaret til SRE endres veldig betydelig. Hvis du ansetter en person, så har han selvfølgelig noen forventninger. Og disse forventningene vil ikke endre seg over tid, men kravene vil endre seg veldig mye. Derfor er det ganske vanskelig å ansette en SRE i de tidlige stadiene. Det er mye lettere å oppdra sin egen. Men det er verdt å tenke på.
Det eneste unntaket er sannsynligvis når det er svært strenge og veldefinerte høydekrav. Det vil si at når det gjelder en oppstart, kan dette være et slags press fra investorer, en slags prognose for vekst flere ganger samtidig. Da er det generelt berettiget å ansette en SRE fordi det kan rettferdiggjøres. Vi har vekstkrav, vi trenger en person som skal ha ansvar for at ingenting bryter med slik vekst.
Et spørsmål til. Hva du skal gjøre når utviklere flere ganger kutter en funksjon som består tester, men bryter produktet, laster databasen, bryter andre funksjoner, hvilken prosess som skal implementeres. Følgelig, i dette tilfellet, innføres et budsjett for feil. Og noen tjenester, noen funksjoner testes umiddelbart i produksjon. Dette kan være en kanarifugl, når bare et lite antall brukere, men allerede i produksjon, implementerer en funksjon, men med en forventning om at hvis noe går i stykker, for eksempel for en halv prosent av alle brukere, vil det fortsatt passe innenfor budsjett for feil. Følgelig, ja, det vil være en feil, for noen brukere vil alt gå i stykker, men vi har allerede sagt at dette er normalt.
Det var et spørsmål om SRE-verktøy. Det vil si, er det noe spesifikt SRE-er vil bruke som alle andre ikke ville? Faktisk er det noen svært spesialiserte verktøy, det er noe programvare som for eksempel simulerer belastninger eller gjør kanariøyemed A/B-testing. Men i utgangspunktet er SRE-verktøy det utviklerne dine allerede bruker. Fordi SRE samhandler direkte med utviklingsteamet. Og har du ulike verktøy, viser det seg at det tar tid å synkronisere. Spesielt hvis SRE jobber i store team, i store selskaper hvor det kan være flere team, vil bedriftsomfattende standardisering være til stor hjelp her, for hvis 50 team bruker 50 ulike verktøy, betyr dette at SRE må kunne dem alle. Og dette vil selvfølgelig aldri skje. Og kvaliteten på arbeidet, kvaliteten på kontrollen til i hvert fall noen av teamene vil reduseres betydelig.
Webinaret vårt nærmer seg gradvis slutten. Jeg klarte å fortelle deg noen grunnleggende ting. Selvfølgelig kan ingenting om SRE fortelles og forstås på en time. Men jeg håper at jeg klarte å formidle denne tankegangen, hovedpoengene. Og så, hvis du er interessert, kan du gå dypere inn i emnet, studere på egen hånd og se på hvordan det blir implementert av andre mennesker, i andre selskaper. Og derfor, tidlig i februar, kom til oss på Slurm SRE.
Slurm SRE er et tredagers intensivkurs som skal dekke omtrent det jeg snakker om nå, men med mye større dybde, med reelle case, med praksis, er hele intensiven rettet mot praktisk arbeid. Folk vil bli delt inn i lag. Dere vil alle jobbe med reelle saker. Derfor har vi instruktører fra Booking.com Ivan Kruglov og Ben Tyler. Vi har en fantastisk Evgeniy Varabbas fra Google, fra San Francisco. Og jeg skal fortelle deg noe også. Så husk å besøke oss.
Så en liste over referanser. Det er lenker på SRE. på den samme boken, eller rettere sagt på 2 bøker om SRE, skrevet av Google. En annen , hvor vilkårene og deres anvendelse er forklart litt mer detaljert. De neste 3 er rapporter om SRE i ulike selskaper. Først - , dette er en keynote fra Ben Trainer fra Google. Sekund - . Den tredje handler igjen om . Fjerde rapport fra , som kun har 5 nøkkelansatte i SRE i 190 land. Det er veldig interessant å se på alt dette, for akkurat som DevOps betyr veldig forskjellige ting for forskjellige selskaper og til og med forskjellige team, har SRE veldig forskjellige ansvar, selv i selskaper av lignende størrelser.
2 flere lenker om prinsippene for kaosteknikk: , . Og på slutten er det 3 lister fra Awesome Lists-serien om , Om og om . Listen på SRE er utrolig stor, du trenger ikke gå gjennom alt, det er omtrent 200 artikler. Jeg anbefaler på det sterkeste artiklene om kapasitetsplanlegging og ulastelig postmortem.
Interessant artikkel:
Takk for at du lyttet til meg hele denne tiden. Jeg håper du har lært noe. Jeg håper du har nok materiale til å lære enda mer. Og ses senere. Forhåpentligvis i februar.
Webinaret ble arrangert av Eduard Medvedev.
PS: for de som liker å lese, ga Eduard en liste med referanser. De som foretrekker å forstå det i praksis er velkommen kl .
Kilde: www.habr.com