Webinaarin ääni on huono, joten olemme litteroineet sen.
Nimeni on Medvedev Eduard. Tänään puhun siitä, mitä SRE on, miten SRE ilmestyi, mitä työkriteereitä SRE-insinööreillä on, vähän luotettavuuskriteereistä, vähän sen valvonnasta. Kävelemme huipulla, koska tunnissa ei voi kertoa paljoa, mutta annan materiaalit lisäarviointia varten, ja odotamme sinua kaikki . Moskovassa tammikuun lopussa.
Ensinnäkin puhutaan siitä, mitä SRE on – sivuston luotettavuuden suunnittelu. Ja kuinka se ilmestyi erillisenä asemana, erillisenä suunnana. Kaikki alkoi siitä, että perinteisissä kehityspiireissä Dev ja Ops ovat kaksi täysin erilaista joukkuetta, joilla on yleensä kaksi täysin erilaista tavoitetta. Kehitystiimin tavoitteena on ottaa käyttöön uusia ominaisuuksia liiketoiminnan tarpeisiin. Ops-tiimin tavoitteena on varmistaa, että kaikki toimii eikä mikään hajoa. Ilmeisesti nämä tavoitteet ovat suoraan ristiriidassa keskenään: jotta kaikki toimisi eikä mikään hajoa, on parempi ottaa uusia ominaisuuksia käyttöön mahdollisimman vähän. Tästä johtuen syntyy monia sisäisiä ristiriitoja, joita nyt DevOps-niminen menetelmä yrittää ratkaista.
Ongelmana on, että meillä ei ole selkeää määritelmää DevOpsille ja selkeää DevOps-toteutusta. Puhuin konferenssissa Jekaterinburgissa 2 vuotta sitten, ja tähän asti DevOps-osio alkoi raportilla "Mikä on DevOps". Vuonna 2017 Devops on melkein 10 vuotta vanha, mutta kiistellään edelleen mistä se on. Ja tämä on hyvin outo tilanne, jonka Google yritti ratkaista muutama vuosi sitten.
Vuonna 2016 Google julkaisi kirjan nimeltä Site Reliability Engineering. Ja itse asiassa, juuri tästä kirjasta SRE-liike alkoi. SRE on DevOps-paradigman erityinen toteutus tietyssä yrityksessä. SRE:n insinöörit ovat sitoutuneet varmistamaan, että järjestelmät toimivat luotettavasti. He tulevat enimmäkseen kehittäjiltä, joskus järjestelmänvalvojilta, joilla on vahva kehitystausta. Ja he tekevät niin kuin järjestelmänvalvojat ennenkin, mutta vahva kehitystausta ja järjestelmän tuntemus koodin suhteen johtaa siihen, että nämä ihmiset eivät ole taipuvaisia rutiininomaiseen hallintotyöhön, vaan ovat taipuvaisia automaatioon.
Osoittautuu, että DevOps-paradigma SRE-tiimeissä toteutuu sillä, että on SRE-insinöörejä, jotka ratkaisevat rakenteellisia ongelmia. Tässä se on sama yhteys Devin ja Opsin välillä, josta ihmiset ovat puhuneet 8 vuoden ajan. SRE:n rooli on samanlainen kuin arkkitehdin, sillä aloittelijasta ei tule SRE:tä. Uransa alussa olevilla ihmisillä ei ole vielä kokemusta, heillä ei ole tarvittavaa tietämystä. Koska SRE vaatii erittäin hienovaraista tietoa siitä, mikä ja milloin tarkalleen voi mennä pieleen. Siksi täällä tarvitaan jonkinlaista kokemusta, pääsääntöisesti sekä yrityksen sisällä että sen ulkopuolella.
He kysyvät, kuvataanko SRE:n ja devopsin eroa. Häntä on juuri kuvattu. Voimme puhua SRE:n paikasta organisaatiossa. Toisin kuin tämä klassinen DevOps-lähestymistapa, jossa Ops on edelleen erillinen osasto, SRE on osa kehitystiimiä. He ovat mukana tuotekehityksessä. On jopa lähestymistapa, jossa SRE on rooli, joka siirtyy kehittäjältä toiselle. He osallistuvat koodiarviointiin samalla tavalla kuin esimerkiksi UX-suunnittelijat, itse kehittäjät, joskus tuotepäälliköt. SRE:t toimivat samalla tasolla. Tarvitsemme heidän hyväksyntänsä, tarvitsemme heidän tarkistuksensa, jotta SRE sanoo jokaisesta käyttöönotosta: "Okei, tämä käyttöönotto, tämä tuote ei vaikuta negatiivisesti luotettavuuteen. Ja jos on, se on joissakin hyväksyttävissä rajoissa." Puhumme myös tästä.
Näin ollen SRE:llä on veto-oikeus koodin muuttamiseen. Ja yleensä tämä johtaa myös jonkinlaiseen pieneen konfliktiin, jos SRE toteutetaan väärin. Samassa kirjassa Site Reliability Engineeringistä monet osat, ei edes yksi, kertovat, kuinka nämä ristiriidat vältetään.
He kysyvät, miten SRE liittyy tietoturvaan. SRE ei ole suoraan mukana tietoturvassa. Useimmiten suurissa yrityksissä tämän tekevät yksittäiset ihmiset, testaajat ja analyytikot. Mutta SRE on myös vuorovaikutuksessa heidän kanssaan siinä mielessä, että jotkin turvallisuuteen vaikuttavat toiminnot, jotkin sitoumukset ja jotkin käyttöönotot voivat myös vaikuttaa tuotteen saatavuuteen. Siksi SRE:llä kokonaisuudessaan on vuorovaikutusta minkä tahansa tiimin kanssa, mukaan lukien turvallisuustiimit, mukaan lukien analyytikot. Siksi SRE:itä tarvitaan pääasiassa yritettäessä ottaa käyttöön DevOpsia, mutta kehittäjien taakka tulee liian suureksi. Eli kehitystiimi itse ei enää kestä sitä tosiasiaa, että nyt heidän täytyy myös olla vastuussa Opsista. Ja siinä on erillinen rooli. Tämä rooli on suunniteltu budjettiin. Joskus tämä rooli on rakennettu joukkueen kokoon, erillinen henkilö ilmestyy, joskus joku kehittäjistä tulee siihen. Näin ensimmäinen SRE ilmestyy joukkueeseen.
Järjestelmän monimutkaisuus, johon SRE vaikuttaa, monimutkaisuus, joka vaikuttaa toiminnan luotettavuuteen, on välttämätöntä ja sattumaa. Välttämätön monimutkaisuus on silloin, kun tuotteen monimutkaisuus lisääntyy siinä määrin, kuin tuotteen uudet ominaisuudet vaativat. Satunnainen monimutkaisuus on, kun järjestelmän monimutkaisuus lisääntyy, mutta tuotteen ominaisuudet ja liiketoiminnan vaatimukset eivät suoraan vaikuta tähän. Osoittautuu, että joko kehittäjä on tehnyt virheen jossain tai algoritmi ei ole optimaalinen, tai esille tulee joitain lisäintressejä, jotka lisäävät tuotteen monimutkaisuutta tarpeettomasti. Hyvän SRE:n tulisi aina välttää tämä tilanne. Toisin sanoen kaikki sitoumukset, käyttöönotto ja vetopyynnöt, jotka lisäävät monimutkaisuutta satunnaisten lisäysten vuoksi, tulee estää.
Kysymys kuuluu, miksi et vain palkata tiimiin insinööriä, järjestelmänvalvojaa, jolla on paljon tietoa. Meille kerrotaan, että kehittäjä insinöörin roolissa ei ole optimaalinen henkilöstöratkaisu. Kehittäjä insinöörin roolissa ei ole aina optimaalinen henkilöstöratkaisu, mutta pointti tässä on, että Opsissa työskentelevällä kehittäjällä on hieman enemmän halua automaatioon, hänellä on hieman enemmän tietoa ja taitoa tämän toteuttamiseksi. automaatio. Ja vastaavasti emme lyhennä vain tiettyjen toimintojen aikaa, ei vain rutiinia, vaan myös sellaisia tärkeitä liiketoimintaparametreja kuin MTTR (Mean Time To Recovery, Recovery time). Näin ollen, ja puhumme tästä myös hieman myöhemmin, säästämme rahaa organisaatiolle.
Puhutaanpa nyt SRE:n toiminnan kriteereistä. Ja ennen kaikkea luotettavuudesta. Pienissä yrityksissä ja startupeissa usein tapahtuu, että ihmiset olettavat, että jos palvelu on kirjoitettu hyvin, jos tuote on kirjoitettu hyvin ja oikein, se toimii, se ei katkea. Siinä kaikki, kirjoitamme hyvää koodia, joten ei ole mitään rikki. Koodi on hyvin yksinkertainen, siinä ei ole mitään rikkomista. Nämä ovat samoja ihmisiä, jotka sanovat, että emme tarvitse testejä, koska katso, nämä ovat kolme VPI-menetelmää, miksi vaivautua?
Tämä kaikki on tietysti väärin. Ja nämä ihmiset joutuvat hyvin usein tällaiseen koodiin käytännössä, koska asiat hajoavat. Asiat katkeavat joskus arvaamattomimmilla tavoilla. Joskus ihmiset sanovat ei, sitä ei koskaan tapahdu. Ja sitä tapahtuu edelleen. Tapahtuu melko usein. Ja siksi kukaan ei koskaan pyri 100-prosenttiseen käytettävyyteen, koska 100-prosenttista käytettävyyttä ei koskaan tapahdu. Tämä on normi. Ja siksi kun puhumme palvelun saatavuudesta, puhumme aina yhdeksästä. 2 yhdeksää, 3 yhdeksää, 4 yhdeksää, 5 yhdeksää. Jos tämä muunnetaan seisokkeiksi, niin esimerkiksi 5 yhdeksän on hieman enemmän kuin 5 minuuttia seisonta-aikaa vuodessa, 2 yhdeksän on 3,5 vuorokautta.
Mutta on selvää, että jossain vaiheessa POI, sijoitetun pääoman tuotto laskee. Siirtyminen kahdesta yhdeksästä kolmeen yhdeksään tarkoittaa seisokkien lyhentämistä yli kolmella päivällä. Neljästä yhdeksästä viiteen vähentäminen vähentää seisokkeja 3 minuutilla vuodessa. Ja käy ilmi, että yrityksille se ei ehkä ole kriittinen. Ja yleisesti ottaen vaadittu luotettavuus ei ole tekninen kysymys, ensinnäkin se on liiketoimintakysymys, se on tuotekysymys. Minkä tasoinen seisokki on tuotteen käyttäjille hyväksyttävää, mitä he odottavat, kuinka paljon he maksavat, esimerkiksi kuinka paljon rahaa menettää, kuinka paljon rahaa järjestelmä menettää.
Tärkeä kysymys tässä on, mikä on muiden komponenttien luotettavuus. Koska ero 4 ja 5 yhdeksän välillä ei näy älypuhelimessa, jossa on 2 yhdeksän luotettavuus. Karkeasti sanottuna, jos palvelussasi olevassa älypuhelimessa jotain hajoaa 10 kertaa vuodessa, todennäköisesti 8 kertaa vika tapahtui käyttöjärjestelmän puolella. Käyttäjä on tottunut tähän, eikä kiinnitä huomiota enää kerran vuodessa. On tarpeen korreloida luotettavuuden lisäämisen ja kasvavien voittojen hinta.
Juuri SRE:tä käsittelevässä kirjassa on hyvä esimerkki 4 yhdeksän lisäämisestä 3 yhdeksästä. Kävi ilmi, että saatavuuden kasvu on hieman alle 0,1 %. Ja jos palvelun tuotto on 1 miljoona dollaria vuodessa, tulojen kasvu on 900 dollaria. Jos kohtuuhintaisuuden lisääminen yhdeksällä maksaa alle 900 dollaria vuodessa, korotus on taloudellisesti järkevää. Jos se maksaa yli 900 dollaria vuodessa, siinä ei ole enää järkeä, koska tulojen kasvu ei yksinkertaisesti kompensoi työvoimakustannuksia, resurssikustannuksia. Ja 3 yhdeksää riittää meille.
Tämä on tietysti yksinkertaistettu esimerkki, jossa kaikki pyynnöt ovat samat. Ja siirtyminen 3 yhdeksästä 4 yhdeksään on tarpeeksi helppoa, mutta samaan aikaan esimerkiksi siirtyminen 2 yhdeksästä 3: een, tämä on jo 9 tuhannen dollarin säästö, se voi olla taloudellisesti järkevää. Luonnollisesti todellisuudessa rekisteröintipyynnön epäonnistuminen on pahempaa kuin sivun näyttämättä jättäminen, pyynnöillä on eri painoarvot. Niillä voi olla täysin erilainen kriteeri liiketoiminnan näkökulmasta, mutta yleensä, jos emme puhu tietyistä palveluista, tämä on melko luotettava arvio.
Saimme kysymyksen, onko SRE yksi koordinaattoreista valittaessa palvelun arkkitehtonista ratkaisua. Tämä on hyväksyttävää integroitaessa olemassa olevaan infrastruktuuriin, jotta sen vakaus ei menetä. Kyllä, SRE:t vaikuttavat vetopyyntöihin, sitoumuksiin, julkaisuihin samalla tavalla, ne vaikuttavat arkkitehtuuriin, uusien palveluiden, mikropalvelujen käyttöönottoon ja uusien ratkaisujen käyttöönottoon. Miksi sanoin aiemmin, että tarvitaan kokemusta, tarvitaan pätevyyttä. Itse asiassa SRE on yksi estoäänistä kaikissa arkkitehtuuri- ja ohjelmistoratkaisuissa. Näin ollen SRE:n insinöörinä on ensinnäkin ei vain ymmärrettävä, vaan myös ymmärrettävä, miten tietyt päätökset vaikuttavat luotettavuuteen, vakauteen, ja ymmärrettävä, miten tämä liittyy liiketoiminnan tarpeisiin ja mistä näkökulmasta tämä voi olla sallittua, ja jonka kanssa se ei ole.
Siksi nyt voidaan puhua vain luotettavuuskriteereistä, jotka SRE:ssä on perinteisesti määritelty SLA:ksi (Service Level Agreement). Todennäköisesti tuttu termi. SLI (Service Level Indicator). SLO (Service Level Objective). Palvelutasosopimus on ehkä symbolinen termi, varsinkin jos olet työskennellyt verkkojen, palveluntarjoajien tai isännöinnin kanssa. Tämä on yleinen sopimus, joka kuvaa koko palvelusi suorituskykyä, rangaistuksia, joitain virheiden sakkoja, mittareita, kriteerejä. Ja SLI on itse saatavuusmittari. Eli mikä SLI voi olla: vasteaika palvelusta, virheiden määrä prosentteina. Se voi olla kaistanleveyttä, jos se on jonkinlainen tiedostojen isännöinti. Tunnistusalgoritmeissa indikaattorina voi olla vaikkapa vastauksen oikeellisuus. SLO (Service Level Objective) on vastaavasti SLI-indikaattorin, sen arvon ja ajanjakson yhdistelmä.
Oletetaan, että SLA voisi olla tällainen. Palvelu on käytettävissä 99,95 % ajasta ympäri vuoden. Tai 99 kriittistä teknisen tuen lippua suljetaan 3 tunnin sisällä vuosineljänneksestä. Tai 85 % kyselyistä vastataan 1,5 sekunnissa joka kuukausi. Toisin sanoen alamme vähitellen ymmärtää, että virheet ja epäonnistumiset ovat aivan normaaleja. Tämä on hyväksyttävä tilanne, suunnittelemme sitä, jopa luotamme siihen jossain määrin. Toisin sanoen SRE rakentaa järjestelmiä, jotka voivat tehdä virheitä, joiden on reagoitava virheisiin normaalisti ja joiden on otettava ne huomioon. Ja jos mahdollista, niiden tulee käsitellä virheitä niin, että käyttäjä joko ei huomaa niitä tai huomaa ne, mutta on olemassa jonkinlainen kiertotapa, jotta kaikki ei hajoa kokonaan.
Jos esimerkiksi lataat videon YouTubeen, eikä YouTube voi muuntaa sitä heti, jos video on liian suuri, jos muoto ei ole optimaalinen, pyyntö ei tietenkään epäonnistu aikakatkaisulla, YouTube ei anna 502-virhettä , YouTube sanoo: "Olemme luoneet kaiken, videotasi käsitellään. Se on valmis noin 10 minuutissa." Tämä on siron degradaation periaate, joka on tuttu esimerkiksi front-end-kehityksestä, jos olet joskus tehnyt niin.
Seuraavat termit, joista puhumme ja jotka ovat erittäin tärkeitä luotettavuuden, virheiden ja odotusten kannalta, ovat MTBF ja MTTR. MTBF on keskimääräinen aika vikojen välillä. MTTR Keskimääräinen palautumisaika, keskimääräinen palautumisaika. Eli kuinka paljon aikaa on kulunut virheen havaitsemisesta, virheen ilmenemishetkestä siihen hetkeen, kun palvelu palautettiin täysin normaaliksi. MTBF korjataan pääasiassa koodin laatutyöllä. Eli se tosiasia, että SRE:t voivat sanoa "ei". Ja sinun on ymmärrettävä koko tiimi, että kun SRE sanoo "ei", hän ei sano sitä siksi, että hän on haitallinen, ei siksi, että hän on huono, vaan koska muutoin kaikki kärsivät.
Jälleen on paljon artikkeleita, paljon menetelmiä, monia tapoja jopa siinä kirjassa, johon niin usein viittaan, kuinka varmistaa, etteivät muut kehittäjät alkaisi vihata SRE:tä. MTTR puolestaan tarkoittaa SLO:iden (Service Level Objective) -työtä. Ja tämä on lähinnä automaatiota. Koska esimerkiksi SLO:mme käyttöaika on 4 yhdeksän vuosineljänneksessä. Tämä tarkoittaa, että 3 kuukaudessa voimme sallia 13 minuutin seisokkeja. Ja käy ilmi, että meidän MTTR ei voi olla yli 13 minuuttia. Jos käytämme 13 minuuttia reagoidaksemme vähintään yhteen seisokkiin, tämä tarkoittaa, että olemme jo käyttäneet koko vuosineljänneksen budjetin. Olemme rikkomassa SLO:ta. 1 minuuttia reagoida ja korjata vika on paljon koneelle, mutta hyvin vähän ihmiselle. Koska siihen mennessä, kun henkilö saa hälytyksen, siihen mennessä, kun hän reagoi, siihen mennessä, kun hän selvittää virheen, on jo muutama minuutti. Ennen kuin henkilö ymmärtää kuinka korjata se, mitä tarkalleen korjata, mitä tehdä, kestää vielä muutaman minuutin. Ja itse asiassa, vaikka sinun tarvitsee vain käynnistää palvelin uudelleen, kuten käy ilmi, tai nostaa uusi solmu, MTTR kestää manuaalisesti noin 13-7 minuuttia. Prosessia automatisoitaessa MTTR saavuttaa hyvin usein sekunnin, joskus millisekunnin. Google puhuu yleensä millisekunneista, mutta todellisuudessa asiat eivät tietenkään ole niin hyvin.
Ihannetapauksessa SRE:n tulisi lähes täysin automatisoida työnsä, koska tämä vaikuttaa suoraan MTTR:ään, sen mittareihin, koko palvelun SLO:han ja vastaavasti liiketoiminnan tuottoon. Jos aika ylittyy, meiltä kysytään, onko SRE:ssä vika. Onneksi kukaan ei ole syyllinen. Ja tämä on erillinen kulttuuri, jota kutsutaan nimellä balmeless postmortem, josta emme puhu tänään, mutta analysoimme Slurmissa. Tämä on erittäin mielenkiintoinen aihe, josta voidaan puhua paljon. Karkeasti sanottuna, jos vuosineljännekselle varattu aika ylittyy, niin kaikki ovat vähän syyllisiä, mikä tarkoittaa, että kaikkien syyttäminen ei ole tuottavaa, emme sen sijaan kenties syyttele ketään, vaan korjaamme tilannetta ja työskentelemme sen kanssa, mitä meillä on. Kokemukseni mukaan tämä lähestymistapa on hieman vieras useimmille joukkueille, etenkin Venäjällä, mutta se on järkevä ja toimii erittäin hyvin. Siksi suosittelen lopuksi artikkeleita ja kirjallisuutta, joita voit lukea tästä aiheesta. Tai tule Slurm SRE:lle.
Anna minun selittää. Jos SLO-aika neljännesvuosittain ylitetään, jos seisokkiaika ei ollut 13 minuuttia, vaan 15 minuuttia, kuka voi olla syypää tähän? Tietysti SRE voi olla syyllinen, koska hän selvästi teki jonkinlaisen huonon sitoumuksen tai käyttöönoton. Palvelinkeskuksen ylläpitäjä voi olla syyllinen tähän, koska hän on saattanut tehdä jonkinlaisen odottamattoman huollon. Jos palvelinkeskuksen ylläpitäjä on syyllinen tähän, niin Opsin henkilö on syyllinen tähän, joka ei laskenut ylläpitoa koordinoiessaan SLO:ta. Tähän on syypää johtaja, tekninen johtaja tai joku, joka on allekirjoittanut konesalin sopimuksen eikä kiinnittänyt huomiota siihen, että konesalin SLA ei ole suunniteltu vaadittuun seisokkiaikaan. Näin ollen kaikki ovat vähän syyllisiä tähän tilanteeseen. Ja tämä tarkoittaa, että ei ole mitään järkeä syyttää ketään erityisesti tästä tilanteesta. Mutta tietysti se pitää korjata. Siksi postmortemit ovat olemassa. Ja jos luet esimerkiksi GitHubin postmortemia, ja tämä on aina erittäin mielenkiintoinen, pieni ja odottamaton tarina joka tapauksessa, voit korvata sen, että kukaan ei koskaan sano, että tämä henkilö oli syyllinen. Syytetään aina tiettyjä puutteellisia prosesseja.
Siirrytään seuraavaan kysymykseen. Automaatio. Kun puhun automaatiosta muissa yhteyksissä, viittaan usein taulukkoon, joka kertoo, kuinka kauan voit työskennellä tehtävän automatisoinnissa ilman, että sen automatisointiin kuluu enemmän aikaa kuin itse säästät. Siellä on pulma. Havainto on, että kun SRE:t automatisoivat tehtävän, ne säästävät paitsi aikaa myös rahaa, koska automaatio vaikuttaa suoraan MTTR:ään. Ne säästävät niin sanotusti työntekijöiden ja kehittäjien moraalia, joka on myös ehtymätön resurssi. Ne vähentävät rutiinia. Ja kaikki tämä vaikuttaa positiivisesti työhön ja sitä kautta liiketoimintaan, vaikka automaatiolla ei näyttäisikään olevan aikakustannusten kannalta järkeä.
Itse asiassa se on melkein aina, ja on hyvin harvoja tapauksia, joissa jotain ei pitäisi automatisoida SRE: n roolissa. Seuraavaksi puhumme virhebudjetista, virhebudjetista. Itse asiassa käy ilmi, että jos kaikki on sinulle paljon paremmin kuin itsellesi asettamasi SLO, tämä ei myöskään ole kovin hyvä. Tämä on melko huono, koska SLO ei toimi vain alarajana, vaan myös likimääräisenä ylärajana. Kun asetat itsellesi SLO:ksi 99 % käytettävyyden ja itse asiassa sinulla on 99,99 %, käy ilmi, että sinulla on tilaa kokeiluille, jotka eivät vahingoita liiketoimintaa ollenkaan, koska olet itse määrittänyt tämän kaiken yhdessä ja olet älä käytä tätä tilaa. Sinulla on budjetti virheitä varten, joita sinun tapauksessasi ei käytetä loppuun.
Mitä sillä tehdään. Käytämme sitä kirjaimellisesti kaikkeen. Testaukseen tuotantoolosuhteissa, uusien suorituskykyyn vaikuttavien ominaisuuksien käyttöönottoon, julkaisuihin, ylläpitoon, suunniteltuihin seisokkeihin. Myös päinvastainen sääntö pätee: jos budjetti on käytetty loppuun, emme voi julkaista mitään uutta, koska muuten ylitämme SLO:n. Budjetti on jo käytetty loppuun, olemme julkaisseet jotain, jos se vaikuttaa negatiivisesti suorituskykyyn, eli jos tämä ei ole jonkinlainen korjaus, joka itsessään lisää suoraan SLO:ta, niin menemme yli budjetin, ja tämä on huono tilanne. , se on analysoitava, post mortem ja mahdollisesti joitain prosessikorjauksia.
Toisin sanoen käy ilmi, että jos itse palvelu ei toimi hyvin ja SLO:ta käytetään ja budjettia ei käytetä kokeiluihin, ei joihinkin julkaisuihin, vaan itsessään, niin mielenkiintoisten korjausten sijaan mielenkiintoisten ominaisuuksien sijaan, mielenkiintoisten julkaisujen sijaan. Luovan työn sijaan joudut tekemään typeriä korjauksia saadaksesi budjetti takaisin kuntoon tai muokkaamaan SLO:ta, ja tämä on myös prosessi, jota ei pitäisi tapahtua liian usein.
Siksi käy ilmi, että tilanteessa, jossa meillä on enemmän budjettia virheille, kaikki ovat kiinnostuneita: sekä SRE että kehittäjät. Kehittäjille suuri bugibudjetti tarkoittaa, että voit käsitellä julkaisuja, testejä ja kokeiluja. SRE:n kohdalla virhebudjetti ja budjetin syöttäminen tarkoittaa, että he tekevät työnsä suoraan hyvin. Ja tämä vaikuttaa jonkinlaisen yhteisen työn motivaatioon. Jos kuuntelet SRE:täsi kehittäjinä, sinulla on enemmän tilaa hyvälle työlle ja paljon vähemmän rutiineja.
Osoittautuu, että tuotantokokeilut ovat varsin tärkeä ja lähes olennainen osa SRE:tä suurissa ryhmissä. Ja sitä kutsutaan yleensä kaaossuunnitteluksi, joka tulee Netflixin tiimiltä, joka julkaisi Chaos Monkey -nimisen apuohjelman.
Chaos Monkey muodostaa yhteyden CI/CD-putkilinjaan ja kaataa satunnaisesti tuotannossa olevan palvelimen. Jälleen SRE-rakenteessa sanomme, että kaatunut palvelin ei sinänsä ole huono, se on odotettavissa. Ja jos se sisältyy budjettiin, se on hyväksyttävää eikä vahingoita liiketoimintaa. Tietysti Netflixillä on tarpeeksi redundantteja palvelimia, tarpeeksi replikaatiota, jotta tämä kaikki voidaan korjata ilman, että käyttäjä kokonaisuutena edes huomaa, eikä varmasti kukaan jätä yhtä palvelinta millä tahansa budjetilla.
Netflixillä oli aikoinaan koko joukko tällaisia apuohjelmia, joista yksi, Chaos Gorilla, poistaa kokonaan yhden Amazonin saatavuusvyöhykkeistä. Ja sellaiset asiat auttavat hyvin tunnistamaan ensinnäkin piileviä riippuvuuksia, kun ei ole täysin selvää, mikä vaikuttaa mihin, mikä riippuu mistä. Ja tämä, jos työskentelet mikropalvelun kanssa ja dokumentaatio ei ole täysin täydellinen, tämä voi olla sinulle tuttua. Ja taas, tämä auttaa paljon havaitsemaan koodissa olevia virheitä, joita et voi havaita lavastuksessa, koska mikään lavastus ei ole aivan tarkka simulaatio, koska kuormitusasteikko on erilainen, kuormituskuvio on erilainen, laitteisto on erilainen. myös todennäköisesti muita. Huippukuormitukset voivat myös olla odottamattomia ja arvaamattomia. Ja tällainen testaus, joka taas ei ylitä budjettia, auttaa erittäin hyvin havaitsemaan infrastruktuurin virheet, joita lavastus, automaattiset testit, CI / CD-putki ei koskaan saa kiinni. Ja niin kauan kuin se kaikki sisältyy budjettiisi, ei ole väliä, että palvelusi katkesi siellä, vaikka se tuntuisi erittäin pelottavalta, palvelin kaatui, mikä painajainen. Ei, se on normaalia, se on hyvä, se auttaa havaitsemaan virheet. Jos sinulla on budjetti, voit käyttää sen.
K: Mitä kirjallisuutta voin suositella? Lista on lopussa. Kirjallisuutta on paljon, neuvon muutaman raportin. Miten se toimii ja toimiiko SRE yrityksissä, joissa ei ole omaa ohjelmistotuotetta tai vähän kehitystä. Esimerkiksi yrityksessä, jonka päätoimiala ei ole ohjelmisto. Yrityksessä, jossa pääasiallinen toiminta ei ole ohjelmistoja, SRE toimii täsmälleen samalla tavalla kuin missä tahansa muuallakin, koska yrityksessä on myös käytettävä, vaikka et kehitäisikään, ohjelmistotuotteita, päivityksiä, infrastruktuuria on muutettava, sinun on kasvattava, sinun on skaalattava. Ja SRE:t auttavat tunnistamaan ja ennustamaan mahdollisia ongelmia näissä prosesseissa ja hallitsemaan niitä sen jälkeen, kun kasvu alkaa ja liiketoiminnan tarpeet muuttuvat. Koska SRE:n saamiseksi ei todellakaan ole välttämätöntä osallistua ohjelmistokehitykseen, jos sinulla on vähintään useita palvelimia ja odotat ainakin jonkin verran kasvua.
Sama koskee pieniä projekteja, pieniä organisaatioita, koska suurilla yrityksillä on budjetti ja tilaa kokeilla. Mutta samaan aikaan kaikkia näitä kokeilujen hedelmiä voidaan käyttää missä tahansa, eli SRE tietysti ilmestyi Googlessa, Netflixissä, Dropboxissa. Mutta samaan aikaan pienet yritykset ja startupit voivat jo lukea tiivistettyä materiaalia, lukea kirjoja, katsella raportteja. He alkavat kuulla siitä useammin, he katsovat konkreettisia esimerkkejä, mielestäni se on okei, se voi todella olla hyödyllistä, me tarvitsemme myös tätä, se on hienoa.
Eli kaikki näiden prosessien standardointityöt on jo tehty puolestasi. Sinun tarvitsee vain määritellä SRE:n rooli nimenomaan yrityksessäsi ja alkaa toteuttaa kaikkia näitä käytäntöjä, jotka on jälleen kerran kuvattu. Eli pienille yrityksille hyödyllisistä periaatteista tämä on aina SLA, SLI, SLO määritelmä. Jos et ole mukana ohjelmistoissa, nämä ovat sisäisiä SLA-sopimuksia ja sisäisiä SLO-sopimuksia, sisäinen budjetti virheiden varalta. Tämä johtaa lähes aina mielenkiintoisiin keskusteluihin tiimin ja yrityksen sisällä, koska voi käydä niin, että kulutat paljon enemmän kuin on tarpeen infrastruktuuriin, jonkinlaiseen ihanteellisten prosessien organisointiin, ihanteelliseen putkiin. Ja näitä 4 yhdeksää, jotka sinulla on IT-osastolla, et tarvitse niitä nyt. Mutta samaan aikaan oli mahdollista viettää aikaa, käyttää virheiden budjettia johonkin muuhun.
Näin ollen seuranta ja seurannan organisointi on hyödyllistä kaikenkokoiselle yritykselle. Ja ylipäänsä tämä ajattelutapa, jossa virheet ovat hyväksyttävää, missä on budjetti, missä on tavoitteet, se on jälleen hyödyllinen kaikenkokoiselle yritykselle, alkaen 3 hengen startupeista.
Viimeinen teknisistä vivahteista, joista voimme puhua, on valvonta. Koska jos puhumme SLA:sta, SLI:stä, SLO:sta, emme voi ymmärtää ilman valvontaa, sovimmeko budjettiin, noudatammeko tavoitteitamme ja miten vaikutamme lopulliseen SLA:han. Olen useaan otteeseen havainnut, että valvonta tapahtuu seuraavasti: on jokin arvo, esimerkiksi palvelimelle saapuvan pyynnön aika, keskimääräinen aika tai pyyntöjen määrä tietokantaan. Hänellä on insinöörin määrittelemä standardi. Jos mittari poikkeaa normista, lähetetään sähköposti. Tämä kaikki on pääsääntöisesti täysin hyödytöntä, koska se johtaa sellaiseen hälytysten ylikylläisyyteen, valvontaviestien ylikylläisyyteen, jolloin henkilön on ensinnäkin tulkittava ne joka kerta, eli määritettävä, tarkoittaako metriarvo tarvetta jonkinlaista toimintaa. Ja toiseksi, hän yksinkertaisesti lakkaa huomaamasta kaikkia näitä hälytyksiä, kun periaatteessa häneltä ei vaadita mitään toimia. Toisin sanoen hyvä valvontasääntö ja ensimmäinen sääntö SRE:n toteutuksessa on, että ilmoituksen pitäisi tulla vain silloin, kun toimenpiteitä vaaditaan.
Vakiotapauksessa tapahtumia on 3 tasoa. On hälytyksiä, on lippuja, on lokeja. Hälytykset ovat kaikkea, mikä edellyttää välittömiä toimia. Eli kaikki on rikki, sinun on korjattava se heti. Liput vaativat viivästyneitä toimia. Kyllä, sinun on tehtävä jotain, sinun on tehtävä jotain manuaalisesti, automaatio on epäonnistunut, mutta sinun ei tarvitse tehdä sitä seuraavien minuuttien aikana. Lokit ovat kaikkea, mikä ei vaadi toimia, ja yleensä, jos asiat menevät hyvin, kukaan ei koskaan lue niitä. Lokit on luettava vasta, kun jälkikäteen käy ilmi, että jotain oli rikki jo jonkin aikaa, emme tienneet siitä. Vai pitääkö sinun tehdä tutkimusta. Mutta yleensä kaikki, mikä ei vaadi toimia, menee lokeihin.
Kaiken tämän sivuvaikutuksena, jos olemme tunnistaneet mitkä tapahtumat vaativat toimia ja olemme hyvin kuvailleet, mitä niiden tulisi olla, tämä tarkoittaa, että toiminto voidaan automatisoida. Eli mitä tapahtuu. Poistumme valppaudesta. Mennään toimintaan. Siirrytään tämän toiminnon kuvaukseen. Ja sitten siirrytään kohti automaatiota. Eli mikä tahansa automaatio alkaa reaktiosta tapahtumaan.
Monitoroinnista siirrymme termiin nimeltä Observability. Myös tämän sanan ympärillä on ollut vähän hypeä viime vuosina. Ja harvat ymmärtävät, mitä se tarkoittaa kontekstinsa ulkopuolella. Mutta pääasia on, että havaittavuus on järjestelmän läpinäkyvyyden mittari. Jos jokin meni pieleen, kuinka nopeasti voit määrittää, mikä meni pieleen ja mikä järjestelmän tila oli sillä hetkellä. Koodin näkökulmasta: mikä toiminto epäonnistui, mikä palvelu epäonnistui. Mikä oli esimerkiksi sisäisten muuttujien tila, konfiguraatio. Infrastruktuurin näkökulmasta tämä on millä saatavuusvyöhykkeellä vika tapahtui, ja jos sinulla on jonkinlainen Kubernetes, niin missä podissa vika tapahtui, mikä oli podin tila. Ja vastaavasti Observability on suorassa suhteessa MTTR:ään. Mitä korkeampi palvelun Havainnoitavuus, sitä helpompi on tunnistaa virhe, sitä helpompi on korjata virhe, mitä helpompi on automatisoida virhe, sitä pienempi MTTR.
Jos taas siirrytään pieniin yrityksiin, he usein kysyvät nytkin, mitä tehdä tiimin koon kanssa ja onko tarpeen palkata erillinen SRE pieneen tiimiin. Puhuin tästä jo vähän aikaisemmin. Startupin tai esimerkiksi tiimin alkuvaiheessa tämä ei ole ollenkaan välttämätöntä, koska SRE:stä voidaan tehdä siirtymävaihe. Ja tämä elvyttää joukkuetta hieman, koska siellä on ainakin jonkin verran monimuotoisuutta. Ja lisäksi se valmistaa ihmisiä siihen, että heidän kasvaessaan SRE:n vastuut yleensä muuttuvat erittäin merkittävästi. Jos palkkaat henkilön, hänellä on tietysti joitain odotuksia. Ja nämä odotukset eivät muutu ajan myötä, mutta vaatimukset muuttuvat suuresti. Siksi SRE:n palkkaaminen on melko vaikeaa alkuvaiheessa. Oman kasvattaminen on paljon helpompaa. Mutta kannattaa miettiä.
Ainoa poikkeus luultavasti on silloin, kun korkeusvaatimukset ovat erittäin tiukat ja tarkasti määritellyt. Eli startupin tapauksessa kyseessä voi olla jonkinlainen sijoittajien paine, jonkinlainen kasvuennuste useaan kertaan kerralla. Silloin SRE:n palkkaaminen on periaatteessa perusteltua, koska se voi olla perusteltua. Meillä on kasvuvaatimuksia, tarvitsemme henkilön, joka on vastuussa siitä, että mikään ei katkea tällaisen kasvun kanssa.
Vielä yksi kysymys. Mitä tehdä, kun kehittäjät leikkaavat useita kertoja ominaisuuden, joka läpäisee testit, mutta katkaisee tuotannon, lataa pohjan, rikkoo muita ominaisuuksia, mikä prosessi otetaan käyttöön. Näin ollen tässä tapauksessa otetaan käyttöön virhebudjetti. Ja osa palveluista, osa ominaisuuksista on jo tuotannossa testattavana. Se voi olla kanaria, kun vain pieni määrä käyttäjiä, mutta jo tuotannossa, ominaisuus otetaan käyttöön, mutta jo sillä odotuksella, että jos jokin rikkoutuu esimerkiksi puolella prosentilla käyttäjistä, se täyttää silti virheiden budjetti. Vastaavasti kyllä, tulee virhe, joillekin käyttäjille kaikki hajoaa, mutta olemme jo sanoneet, että tämä on normaalia.
SRE-työkaluista oli kysymys. Eli onko jotain erityistä, jota SRE:t käyttäisivät, mitä kaikki muut eivät käyttäisi? Itse asiassa on olemassa joitain erittäin erikoistuneita apuohjelmia, on joitain ohjelmistoja, jotka esimerkiksi simuloivat kuormia tai tekevät kanarian A/B-testausta. Mutta pohjimmiltaan SRE-työkalupakki on se, mitä kehittäjät jo käyttävät. Koska SRE on suoraan vuorovaikutuksessa kehitystiimin kanssa. Ja jos sinulla on erilaisia työkaluja, käy ilmi, että synkronointi vie aikaa. Varsinkin jos SRE:t työskentelevät suurissa ryhmissä, suurissa yrityksissä, joissa voi olla useita ryhmiä, yrityksen laajuinen standardointi on tässä erittäin hyödyllinen, koska jos 50 tiimiä käyttää 50 erilaista apuohjelmaa, tämä tarkoittaa, että SRE:n on tunnettava ne kaikki. Ja tätä ei tietenkään koskaan tapahdu. Ja ainakin joidenkin ryhmien työn laatu, valvonnan laatu heikkenee merkittävästi.
Webinaarimme alkaa vähitellen loppua. Onnistuin kertomaan sinulle perusasiat. Tietenkään mitään SRE:stä ei voida kertoa ja ymmärtää tunnissa. Mutta toivon, että onnistuin välittämään tämän ajattelutavan, tärkeimmät avainkohdat. Ja sitten, jos olet kiinnostunut, voit syventää aihetta, opiskella itse ja katsoa, miten se on toteutettu muiden ihmisten toimesta, muissa yrityksissä. Ja vastaavasti helmikuun alussa tule meille Slurm SRE:hen.
Slurm SRE on kolmipäiväinen intensiivikurssi, joka kattaa suunnilleen sen, mistä nyt puhun, mutta paljon syvällisemmin, todellisilla tapauksilla, harjoittelulla, koko intensiivi on suunnattu käytännön työhön. Ihmiset jaetaan ryhmiin. Te kaikki työskentelette todellisten tapausten parissa. Näin ollen meillä on Booking.com-ohjaajat Ivan Kruglov ja Ben Tyler. Meillä on upea Eugene Barabbas Googlelta San Franciscosta. Ja minäkin kerron sinulle jotain. Muista siis käydä meillä.
Eli lista viittauksista. SRE:ssä on linkkejä. samaan kirjaan tai pikemminkin kahteen SRE:tä käsittelevään kirjaan, jotka Google on kirjoittanut. Toinen , jossa ehdot ja niiden soveltaminen ovat hieman yksityiskohtaisempia. Seuraavat 3 ovat raportteja SRE:stä eri yrityksissä. Ensimmäinen - , tämä on Googlen Ben Trainerin pääpuheenvuoro. Toinen - . Kolmas on taas . Neljäs raportti osoitteesta , jolla on vain viisi SRE:n avaintyöntekijää 5 maassa. On erittäin mielenkiintoista katsoa tätä kaikkea, sillä aivan kuten DevOps tarkoittaa hyvin erilaisia asioita eri yrityksille ja jopa eri tiimeille, SRE:llä on hyvin erilaisia vastuita jopa samankokoisissa yrityksissä.
2 muuta linkkiä kaaossuunnittelun periaatteista: , . Ja lopussa on 3 listaa sarjasta Awesome Lists noin noin ja noin . SRE:n lista on uskomattoman valtava, kaikkea ei tarvitse käydä läpi, artikkeleita on noin 200. Suosittelen lämpimästi artikkeleita kapasiteetin suunnittelusta ja moitteettomasta postmortemista.
Mielenkiintoinen artikkeli:
Kiitos, että kuuntelitte minua koko tämän ajan. Toivottavasti olet oppinut jotain. Toivottavasti sinulla on tarpeeksi materiaalia oppiaksesi lisää. Ja nähdään myöhemmin. Toivottavasti helmikuussa.
Webinaarin isännöi Eduard Medvedev.
PS: niille, jotka haluavat lukea, Eduard antoi luettelon lähdeluettelosta. Ne, jotka haluavat ymmärtää käytännössä, ovat tervetulleita .
Lähde: will.com