Veebiseminaril on kehv heli, nii et oleme selle transkribeerinud.
Minu nimi on Medvedev Eduard. Täna räägin sellest, mis on SRE, kuidas SRE tekkis, millised on SRE inseneride töökriteeriumid, natuke töökindluse kriteeriumidest, natuke selle jälgimisest. Kõnnime tippudel, sest tunniga ei saa palju öelda, aga annan materjalid täiendavaks ülevaatamiseks ja ootame teid kõik . jaanuari lõpus Moskvas.
Kõigepealt räägime sellest, mis on SRE – saidi töökindluse tehnika. Ja kuidas see ilmus eraldi positsioonina, eraldi suunana. Kõik sai alguse sellest, et traditsioonilistes arendusringkondades on Dev ja Ops kaks täiesti erinevat meeskonda, kellel on tavaliselt kaks täiesti erinevat eesmärki. Arendusmeeskonna eesmärk on juurutada uusi funktsioone ja vastata ettevõtte vajadustele. Opsi meeskonna eesmärk on tagada, et kõik toimiks ja miski ei puruneks. Ilmselgelt on need eesmärgid üksteisega otseses vastuolus: et kõik toimiks ja miski ei puruneks, juurutage uusi funktsioone nii vähe kui võimalik. Seetõttu on palju sisemisi konflikte, mida praegune DevOps-nimeline metoodika püüab lahendada.
Probleem on selles, et meil pole DevOpsi selget määratlust ja DevOpsi selget rakendamist. Rääkisin 2 aastat tagasi ühel konverentsil Jekaterinburgis ja siiani algas DevOpsi sektsioon raportiga “Mis on DevOps”. Aastal 2017 on Devops peaaegu 10 aastat vana, kuid me vaidleme endiselt, mis see on. Ja see on väga kummaline olukord, mida Google üritas paar aastat tagasi lahendada.
2016. aastal andis Google välja raamatu nimega Site Reliability Engineering. Ja tegelikult sai just selle raamatuga SRE liikumine alguse. SRE on DevOpsi paradigma konkreetne rakendamine konkreetses ettevõttes. SRE insenerid on pühendunud süsteemide töökindluse tagamisele. Need tulevad enamasti arendajatelt, vahel ka tugeva arendustaustaga administraatoritelt. Ja nad teevad seda, mida varem tegid süsteemiadministraatorid, kuid tugev arendustaust ja süsteemi tundmine koodi osas viib selleni, et need inimesed ei kipu rutiinsele haldustööle, vaid kalduvad automatiseerimisele.
Selgub, et DevOpsi paradigmat SRE meeskondades rakendab asjaolu, et on olemas SRE insenerid, kes lahendavad struktuurseid probleeme. Siin on see sama seos Devi ja Opsi vahel, millest inimesed on rääkinud juba 8 aastat. SRE roll sarnaneb arhitekti omaga, sest uustulnukatest ei saa SRE-sid. Inimestel, kes on oma karjääri alguses, puuduvad veel kogemused, puuduvad vajalikud teadmised. Sest SRE nõuab väga peent teadmist selle kohta, mis ja millal täpselt võib valesti minna. Seetõttu on siin vaja teatud kogemusi reeglina nii ettevõtte sees kui ka väljaspool.
Nad küsivad, kas kirjeldatakse erinevust SRE ja devopsi vahel. Teda just kirjeldati. Saab rääkida SRE kohast organisatsioonis. Erinevalt sellest klassikalisest DevOpsi lähenemisviisist, kus Ops on endiselt eraldi osakond, on SRE osa arendusmeeskonnast. Nad on seotud tootearendusega. On isegi lähenemisviis, kus SRE on roll, mis läheb ühelt arendajalt teisele. Nad osalevad koodiülevaatustes samamoodi nagu näiteks UX disainerid, arendajad ise, vahel ka tootejuhid. SRE-d töötavad samal tasemel. Peame need heaks kiitma, peame need üle vaatama, nii et iga juurutuse kohta ütleb SRE: „Olgu, see juurutus, see toode ei mõjuta negatiivselt töökindlust. Ja kui on, siis teatud vastuvõetavates piirides. Sellest räägime ka.
Sellest tulenevalt on SRE-l koodi muutmiseks vetoõigus. Ja üldiselt toob see kaasa ka mingi väikese konflikti, kui SRE-d valesti rakendatakse. Samas raamatus Site Reliability Engineeringist räägivad paljud osad, isegi mitte üks, kuidas neid konflikte vältida.
Nad küsivad, kuidas on SRE infoturbega seotud. SRE ei ole otseselt infoturbega seotud. Põhimõtteliselt teevad seda suurtes ettevõtetes eraisikud, testijad, analüütikud. Kuid SRE suhtleb nendega ka selles mõttes, et mõned turvalisust mõjutavad toimingud, mõned sissekanded, mõned juurutused võivad samuti mõjutada toote saadavust. Seetõttu suhtleb SRE tervikuna kõigi meeskondadega, sealhulgas turvameeskondadega, sealhulgas analüütikutega. Seetõttu on SRE-sid vaja peamiselt siis, kui nad üritavad DevOpsi juurutada, kuid samal ajal muutub arendajate koormus liiga suureks. See tähendab, et arendusmeeskond ise ei saa enam hakkama sellega, et nüüd tuleb ka Opsi eest vastutada. Ja seal on omaette roll. See roll on eelarvesse planeeritud. Mõnikord on see roll meeskonna suuruses paika pandud, ilmub eraldi inimene, mõnikord saab selleks keegi arendajatest. Nii ilmub meeskonda esimene SRE.
Süsteemi keerukus, mida SRE mõjutab, keerukus, mis mõjutab töökindlust, on vajalik ja juhuslik. Vajalik keerukus on siis, kui toote keerukus suureneb nii palju, kui seda nõuavad toote uued omadused. Juhuslik keerukus on siis, kui süsteemi keerukus suureneb, kuid toote funktsioon ja ärinõuded seda otseselt ei mõjuta. Selgub, et kas arendaja tegi kuskil vea või pole algoritm optimaalne või tuuakse sisse mingid lisahuvid, mis ilma erivajaduseta toote keerukust suurendavad. Hea SRE peaks selle olukorra alati ära lõikama. See tähendab, et mis tahes sidumine, juurutamine ja tõmbamistaotlus, mille raskus suureneb juhusliku lisamise tõttu, tuleks blokeerida.
Küsimus on selles, miks mitte palgata meeskonda lihtsalt insener, süsteemiadministraator, kellel on palju teadmisi. Meile öeldakse, et inseneri rollis olev arendaja ei ole parim personalilahendus. Inseneri rollis olev arendaja ei ole alati parim personalilahendus, kuid siin on mõte selles, et Opsiga tegeleval arendajal on natuke rohkem automatiseerimishimu, tal on natuke rohkem teadmisi ja oskusi, mida rakendada. see automatiseerimine. Ja vastavalt sellele ei vähenda me mitte ainult mõne konkreetse toimingu jaoks kuluvat aega, mitte ainult rutiini, vaid ka selliseid olulisi äriparameetreid nagu MTTR (Mean Time To Recovery, taastumisaeg). Seega ja me räägime sellest ka veidi hiljem, hoiame organisatsiooni jaoks raha kokku.
Nüüd räägime SRE toimimise kriteeriumidest. Ja ennekõike usaldusväärsuse kohta. Väikestes ettevõtetes, startupides juhtub sageli, et inimesed eeldavad, et kui teenus on hästi kirjutatud, kui toode on hästi ja õigesti kirjutatud, siis see töötab, ei lähe katki. See on kõik, me kirjutame head koodi, nii et pole midagi murda. Kood on väga lihtne, pole midagi murda. Need on umbes samad inimesed, kes ütlevad, et meil pole teste vaja, sest vaata, need on kolm VPI meetodit, miks siin murda.
See kõik on muidugi vale. Ja neid inimesi närib selline kood praktikas väga sageli, sest asjad lähevad katki. Asjad purunevad mõnikord kõige ettearvamatumal viisil. Mõnikord inimesed ütlevad, et ei, seda ei juhtu kunagi. Ja seda juhtub kogu aeg. Seda juhtub piisavalt sageli. Ja sellepärast ei püüdle keegi kunagi 100% kättesaadavuse poole, sest 100% kättesaadavust ei juhtu kunagi. See on norm. Ja seetõttu räägime teenuse kättesaadavusest rääkides alati üheksast. 2 üheksat, 3 üheksat, 4 üheksat, 5 üheksat. Kui tõlkida see seisakuajaks, siis näiteks 5 üheksat, siis see on veidi rohkem kui 5 minutit seisakut aastas, 2 üheksat on 3,5 päeva seisakut.
Aga on ilmselge, et ühel hetkel on POI, investeeringutasuvuse langus. Kahelt üheksalt kolmele üheksale liikumine tähendab rohkem kui 3 päeva võrra vähem seisakuid. Neljalt üheksalt viiele vähendamine vähendab seisakuid 47 minuti võrra aastas. Ja selgub, et äri jaoks ei pruugi see olla kriitiline. Ja üldiselt ei ole nõutav töökindlus tehniline küsimus, ennekõike on see äriküsimus, see on toote küsimus. Millise seisaku tase on toote kasutajatele vastuvõetav, mida nad ootavad, kui palju nad näiteks maksavad, kui palju raha kaotavad, kui palju süsteem raha kaotab.
Siin on oluline küsimus, milline on ülejäänud komponentide töökindlus. Sest erinevus 4 ja 5 üheksa vahel ei ole 2 üheksa töökindlusega nutitelefonis nähtav. Jämedalt öeldes, kui teie teenuses olevas nutitelefonis läheb midagi katki 10 korda aastas, tekkis tõenäoliselt 8 korda rike OS-i poolel. Kasutaja on sellega harjunud ega pööra tähelepanu enam ühele korrale aastas. On vaja korreleerida usaldusväärsuse suurendamise ja kasumi suurendamise hinda.
Just SRE-teemalises raamatus on hea näide 4 üheksalt 3 üheksani suurendamisest. Selgub, et saadavuse kasv on veidi alla 0,1%. Ja kui teenuse tulu on 1 miljon dollarit aastas, siis tulu kasv on 900 dollarit. Kui taskukohasuse suurendamine üheksa võrra maksab meile vähem kui 900 dollarit aastas, on suurendamine rahaliselt mõistlik. Kui see maksab üle 900 dollari aastas, pole sellel enam mõtet, sest tulude kasv lihtsalt ei kompenseeri tööjõukulusid, ressursikulusid. Ja meile piisab 3 üheksast.
See on muidugi lihtsustatud näide, kus kõik taotlused on võrdsed. Ja 3 üheksalt 4 üheksani minek on piisavalt lihtne, aga samas näiteks 2 üheksalt 3 peale minnes on see juba 9 tuhande dollari suurune kokkuhoid, see võib olla rahaliselt mõttekas. Loomulikult on tegelikkuses registreerimistaotluse ebaõnnestumine hullem kui lehe kuvamata jätmine, päringud on erineva kaaluga. Neil võib ärilisest vaatenurgast olla täiesti erinev kriteerium, kuid reeglina, kui me ei räägi mõnest konkreetsest teenusest, on see üsna usaldusväärne ligikaudne hinnang.
Saime küsimuse, kas SRE on teenuse arhitektuurse lahenduse valikul üks koordinaatoritest. Ütleme nii integreerimise mõttes olemasolevasse infrastruktuuri, et selle stabiilsus ei kaoks. Jah, SRE-d, samamoodi, nagu tõmbavad päringud, kohustused, väljalasked, mõjutavad arhitektuuri, uute teenuste, mikroteenuste juurutamist, uute lahenduste juurutamist. Miks ma enne ütlesin, et kogemust on vaja, kvalifikatsiooni on vaja. Tegelikult on SRE üks blokeerivaid hääli igas arhitektuuri- ja tarkvaralahenduses. Sellest tulenevalt peab SRE kui insener mitte ainult mõistma, vaid ka mõistma, kuidas mõned konkreetsed otsused mõjutavad usaldusväärsust, stabiilsust, ning mõistma, kuidas see on seotud ärivajadustega ning millisest vaatenurgast võib see olla vastuvõetav ja mis mitte.
Seetõttu saame nüüd rääkida lihtsalt usaldusväärsuse kriteeriumidest, mida SRE-s traditsiooniliselt määratletakse SLA-na (Service Level Agreement). Tõenäoliselt tuttav termin. SLI (teenusetaseme indikaator). SLO (teenusetaseme eesmärk). Teenusetaseme leping on võib-olla sümboolne termin, eriti kui olete töötanud võrkude, teenusepakkujate või hostimisega. See on üldleping, mis kirjeldab kogu teie teenuse toimivust, karistusi, mõningaid karistusi vigade eest, mõõdikuid, kriteeriume. Ja SLI on kättesaadavuse mõõdik ise. See tähendab, milline SLI võib olla: teenuse reageerimisaeg, vigade arv protsentides. See võib olla ribalaius, kui see on mingi failimajutus. Kui rääkida äratundmisalgoritmidest, siis indikaatoriks võib olla näiteks kasvõi vastuse õigsus. SLO (Service Level Objective) on vastavalt SLI indikaatori, selle väärtuse ja perioodi kombinatsioon.
Oletame, et SLA võiks olla selline. Teenus on saadaval 99,95% ajast aastaringselt. Või 99 kriitilist tugipiletit suletakse 3 tunni jooksul kvartalis. Või 85% päringutest vastatakse iga kuu 1,5 sekundi jooksul. See tähendab, et järk-järgult saame aru, et vead ja tõrked on täiesti normaalsed. See on aktsepteeritav olukord, me planeerime seda, me isegi arvestame sellega mingil määral. See tähendab, et SRE ehitab süsteeme, mis võivad teha vigu, mis peavad vigadele normaalselt reageerima, mis peavad nendega arvestama. Ja kui vähegi võimalik, peaksid nad vigadega hakkama saama nii, et kasutaja neid kas ei märkaks või märkaks, aga on mingisugune lahendus, tänu millele kõik päris ära ei kuku.
Näiteks kui laadite video YouTube'i üles ja YouTube ei saa seda kohe teisendada, kui video on liiga suur, kui formaat pole optimaalne, siis taotlus loomulikult ei nurju ajalõpuga, YouTube ei anna 502 viga , YouTube ütleb: "Oleme kõik loonud, teie videot töödeldakse. See on valmis umbes 10 minutiga." See on graatsilise degradatsiooni põhimõte, mis on tuttav näiteks esiotsa arendusest, kui olete seda kunagi teinud.
Järgmised terminid, millest me räägime, mis on väga olulised töökindluse, vigade ja ootustega töötamiseks, on MTBF ja MTTR. MTBF on keskmine aeg rikete vahel. MTTR keskmine taastumise aeg, keskmine taastumise aeg. See tähendab, kui palju aega on möödunud vea avastamisest, vea ilmnemisest hetkeni, mil teenus taastati normaalselt. MTBF on peamiselt fikseeritud koodikvaliteediga seotud tööga. See tähendab, et SRE-d võivad öelda "ei". Ja teil on vaja kogu meeskonna mõistmist, et kui SRE ütleb "ei", siis ta ei ütle seda mitte sellepärast, et ta on kahjulik, mitte sellepärast, et ta on halb, vaid sellepärast, et muidu kõik kannatavad.
Jällegi on palju artikleid, palju meetodeid, palju viise isegi selles raamatus, millele ma nii sageli viitan, kuidas tagada, et teised arendajad ei hakkaks SRE-d vihkama. MTTR seevastu on seotud teie SLO-de (teenusetaseme eesmärk) kallal töötamisega. Ja see on enamasti automatiseerimine. Sest näiteks meie SLO tööaeg on 4 üheksat kvartalis. See tähendab, et 3 kuu jooksul saame lubada 13 minutit seisakuid. Ja selgub, et MTTR ei saa olla pikem kui 13 minutit. Kui reageerime 13 minuti jooksul vähemalt ühele seisakule, tähendab see, et oleme kogu kvartali eelarve juba ammendanud. Me rikume SLO-d. 1 minutit reageerimiseks ja krahhi parandamiseks on masina jaoks palju, kuid inimese jaoks väga lühike aeg. Sest kuni inimene saab hoiatuse, kuni ta reageerib, kuni ta veast aru saab, on juba mitu minutit. Kuni inimene ei mõista, kuidas seda parandada, mida täpselt parandada, mida teha, on see veel paar minutit. Ja tegelikult, isegi kui peate lihtsalt serveri taaskäivitama, nagu selgub, või uue sõlme tõstma, on MTTR käsitsi juba umbes 13-7 minutit. Protsessi automatiseerimisel jõuab MTTR väga sageli sekundini, mõnikord millisekundini. Google räägib tavaliselt millisekunditest, kuid tegelikult pole kõik muidugi nii hästi.
Ideaalis peaks SRE oma töö peaaegu täielikult automatiseerima, kuna see mõjutab otseselt MTTR-i, selle mõõdikuid, kogu teenuse SLO-d ja vastavalt ka ärikasumit. Aja ületamise korral küsitakse, kas SRE on süüdi. Õnneks pole keegi süüdi. Ja see on omaette kultuur nimega palmeless postmortem, millest me täna ei räägi, aga analüüsime seda Slurmis. See on väga huvitav teema, millest võib palju rääkida. Jämedalt öeldes, kui kvartalis ettenähtud aeg ületatakse, siis on süüdi natukene igaüks, mis tähendab, et kõigi süüdistamine ei ole produktiivne, selle asemel, võib-olla mitte kedagi süüdistada, vaid parandame olukorda ja töötame sellega, mis meil on. Minu kogemuse järgi on selline lähenemine enamikule meeskondadele, eriti Venemaal, veidi võõras, kuid see on mõistlik ja töötab väga hästi. Seetõttu soovitan artikli ja kirjanduse lõpus, mida saate sellel teemal lugeda. Või tulge Slurm SRE-sse.
Las ma seletan. Kui SLO aeg kvartalis on ületatud, kui seisak ei olnud 13 minutit, vaid 15, siis kes saab selles süüdi olla? Muidugi võib süüdi olla SRE, sest ta tegi ilmselgelt mingisuguse halva toime või kasutuselevõtu. Selles võib süüdi olla andmekeskuse administraator, kes võis teha mingisuguse plaanivälise hoolduse. Kui selles on süüdi andmekeskuse administraator, siis selles on süüdi inimene Opsist, kes SLO-d koordineerides hooldust ei arvestanud. Süüdi on selles juht, tehniline direktor või keegi, kes andmekeskuse lepingu allkirjastas ja ei pööranud tähelepanu sellele, et andmekeskuse SLA ei ole mõeldud vajalikuks seisakuajaks. Järelikult on selles olukorras kõik vähehaaval süüdi. Ja see tähendab, et selles olukorras pole mõtet kedagi süüdistada. Aga loomulikult tuleb seda parandada. Sellepärast on postmortem. Ja kui loed näiteks GitHubi postmortemsi ja see on igal konkreetsel juhul alati väga huvitav, väike ja ootamatu lugu, võid asendada selle, et keegi ei ütle kunagi, et see konkreetne inimene oli süüdi. Süüdistatakse alati konkreetseid ebatäiuslikke protsesse.
Liigume edasi järgmise küsimuse juurde. Automatiseerimine. Kui räägin automatiseerimisest muudes kontekstides, viitan sageli tabelile, mis ütleb teile, kui kaua saate ülesande automatiseerimisega töötada, ilma et selle automatiseerimiseks kuluks rohkem aega, kui tegelikult säästate. Seal on tõrksus. Konks on selles, et kui SRE-d ülesande automatiseerivad, ei säästa nad mitte ainult aega, vaid ka raha, sest automatiseerimine mõjutab otseselt MTTR-i. Säästavad nii-öelda töötajate ja arendajate moraali, mis on samuti ammendav ressurss. Nad vähendavad rutiini. Ja see kõik mõjub tööle ja sellest tulenevalt ka ärile positiivselt, isegi kui tundub, et automatiseerimisel pole ajakulu mõttes mõtet.
Tegelikult on see peaaegu alati nii ja väga vähe on juhtumeid, kus midagi ei tohiks SRE rollis automatiseerida. Järgmisena räägime sellest, mida nimetatakse veaeelarveks, vigade eelarveks. Tegelikult selgub, et kui kõik on teie jaoks palju parem kui enda jaoks seatud SLO, pole see ka väga hea. See on üsna halb, sest SLO ei tööta mitte ainult alumise, vaid ka ligikaudse ülemise piirina. Kui seate endale SLO-ks 99% saadavuse ja tegelikult on teil 99,99%, siis selgub, et teil on natuke ruumi katseteks, mis ei kahjusta ettevõtet üldse, sest olete ise selle kõik koos kindlaks määranud ja olete seda ruumi ei kasuta. Teil on vigade jaoks eelarve, mida teie puhul ei kasutata.
Mida me sellega peale hakkame. Me kasutame seda sõna otseses mõttes kõige jaoks. Tootmistingimustes testimiseks, jõudlust mõjutada võivate uute funktsioonide juurutamiseks, väljalasete jaoks, hoolduseks, planeeritud seisakuaegadeks. Kehtib ka vastupidine reegel: kui eelarve on ammendunud, ei saa me midagi uut välja anda, sest muidu ületame SLO. Eelarve on juba ammendatud, oleme midagi välja andnud, kui see mõjutab jõudlust negatiivselt, st kui see pole mingi parandus, mis iseenesest suurendab otseselt SLO-d, siis läheme eelarvest kaugemale ja see on halb olukord , tuleb seda analüüsida, surmajärgselt ja võib-olla mõned protsessiparandused.
See tähendab, et kui teenus ise ei tööta hästi ja SLO kulutatakse ja eelarvet kulutatakse mitte katsetele, mitte mõnele väljalasele, vaid iseendale, siis huvitavate funktsioonide asemel huvitavate paranduste asemel huvitavate väljaannete asemel. Loomingulise töö asemel tuleb eelarve taastamiseks teha rumalaid parandusi või SLO-d redigeerida ja see on ka protsess, mida ei tohiks liiga sageli juhtuda.
Seetõttu selgub, et olukorras, kus meil on vigade jaoks rohkem eelarvet, on kõik huvitatud: nii SRE kui ka arendajad. Arendajate jaoks tähendab suur vigade eelarve seda, et saate tegeleda väljalasete, testide ja eksperimentidega. SRE-de jaoks tähendab vigade eelarve ja selle eelarve sisestamine, et nad teevad oma tööd hästi. Ja see mõjutab mingisuguse ühise töö motivatsiooni. Kui kuulate oma SRE-sid arendajatena, on teil rohkem ruumi hea töö jaoks ja palju vähem rutiini.
Selgub, et katsed tootmises on suurtes meeskondades SRE jaoks üsna oluline ja peaaegu lahutamatu osa. Ja seda nimetatakse tavaliselt kaosetehnoloogiaks, mis pärineb Netflixi meeskonnalt, kes andis välja utiliidi nimega Chaos Monkey.
Chaos Monkey loob ühenduse CI/CD torujuhtmega ja jookseb juhuslikult tootmises oleva serveri kokku. Jällegi, SRE struktuuris räägime sellest, et alla kukkunud server pole iseenesest halb, seda oodatakse. Ja kui see on eelarve piires, on see vastuvõetav ega kahjusta äri. Muidugi on Netflixil piisavalt üleliigseid servereid, piisavalt paljundust, et seda kõike saaks parandada ja et kasutaja tervikuna ei märkakski ja veel enam, et keegi ei jätaks ühegi eelarve eest ühte serverit.
Netflixil oli mõnda aega terve komplekt selliseid utiliite, millest üks, Chaos Gorilla, sulgeb täielikult ühe Amazoni saadavuse tsoonidest. Ja sellised asjad aitavad paljastada esiteks varjatud sõltuvused, kui pole päris selge, mis mida mõjutab, mis millest sõltub. Ja see, kui töötate mikroteenusega ja dokumentatsioon pole päris täiuslik, võib see teile tuttav olla. Ja jällegi aitab see kõvasti tabada koodis vigu, mida lavastusel tabada ei õnnestu, sest igasugune lavastus ei ole just täpne simulatsioon, kuna koormusskaala on erinev, koormusmuster on erinev, varustus on erinev. ka suure tõenäosusega muu. Tippkoormused võivad olla ka ootamatud ja ettearvamatud. Ja selline testimine, mis jällegi ei ületa eelarvet, aitab väga hästi tabada infrastruktuuri vigu, mida lavastus, automaattestid, CI / CD torujuhe kunagi ei taba. Ja seni, kuni see kõik on teie eelarves, pole vahet, et teie teenus seal katkes, kuigi see tunduks väga hirmutav, server läks alla, milline õudusunenägu. Ei, see on normaalne, see on hea, see aitab vigu tabada. Kui teil on eelarve, saate selle kulutada.
K: Millist kirjandust ma soovitan? Loetelu lõpus. Kirjandust on palju, annan nõu mõne aruande kohta. Kuidas see töötab ja kas SRE töötab ettevõtetes ilma oma tarkvaratooteta või minimaalse arendusega. Näiteks ettevõttes, kus põhitegevus ei ole tarkvara. Ettevõttes, kus põhitegevuseks ei ole tarkvara, töötab SRE täpselt samamoodi nagu igal pool mujal, sest ettevõttes on vaja kasutada ka, isegi kui pole välja töötatud, tarkvaratooteid, vaja on uuendusi juurutada, tuleb muuta infrastruktuuri, peate kasvama, te peate skaleerima. Ja SRE-d aitavad tuvastada ja ennustada nende protsesside võimalikke probleeme ning kontrollida neid pärast kasvu algust ja ärivajaduste muutumist. Sest SRE omamiseks pole absoluutselt vaja tegeleda tarkvaraarendusega, kui sul on vähemalt paar serverit ja sinult oodatakse vähemalt mingit kasvu.
Sama kehtib ka väikeste projektide, väikeste organisatsioonide kohta, sest suurtel ettevõtetel on eelarve ja ruumi katsetamiseks. Kuid samal ajal saab kõiki neid katsete vilju kasutada kõikjal, see tähendab, et SRE ilmus loomulikult Google'is, Netflixis, Dropboxis. Kuid samas saavad väikeettevõtted ja startupid juba lugeda tihendatud materjali, lugeda raamatuid, vaadata reportaaže. Nad hakkavad sellest sagedamini kuulma, nad vaatavad konkreetseid näiteid, ma arvan, et see on okei, see võib tõesti kasulik olla, me vajame ka seda, see on suurepärane.
See tähendab, et kogu põhitöö nende protsesside standardiseerimiseks on teie eest juba tehtud. Jääb teie teha kindlaks SRE roll konkreetselt teie ettevõttes ja hakata kõiki neid praktikaid, mida jällegi on juba kirjeldatud, tegelikult rakendama. See tähendab, et väikeettevõtete jaoks kasulikest põhimõtetest lähtudes on see alati SLA, SLI, SLO määratlus. Kui te pole tarkvaraga seotud, on need sisemised SLA-d ja sisemised SLO-d, vigade sisemine eelarve. See toob peaaegu alati kaasa huvitavaid arutelusid meeskonnas ja ettevõtte sees, sest võib selguda, et kulutate infrastruktuurile, ideaalsete protsesside mingisugusele korraldamisele, ideaalset torujuhtme on palju rohkem kui vaja. Ja need 4 üheksat, mis teil IT-osakonnas on, ei vaja te neid praegu. Kuid samal ajal võite kulutada aega, kulutada eelarve vigade jaoks millelegi muule.
Järelikult on monitooring ja seire korraldamine kasulik igas suuruses ettevõttele. Ja üleüldse selline mõtteviis, kus vead on midagi vastuvõetavat, kus on eelarve, kus on Eesmärgid, on jällegi kasulik igas suuruses ettevõttele, alustades 3 inimese startupidest.
Tehnilistest nüanssidest viimane, millest rääkida, on seire. Sest kui me räägime SLA-st, SLI-st, SLO-st, ei saa me ilma jälgimata aru, kas mahume eelarvesse, kas täidame oma eesmärke ja kuidas me mõjutame lõplikku SLA-d. Olen nii palju kordi näinud, et jälgimine toimub nii: mingi väärtus on olemas, näiteks serverisse pöördumise aeg, keskmine aeg või andmebaasi päringute arv. Tal on standard, mille määrab insener. Kui mõõdik kaldub normist kõrvale, siis tuleb e-kiri. See kõik on reeglina täiesti kasutu, kuna see toob kaasa sellise hoiatuste rohkuse, jälgimise sõnumite rohkuse, kui inimene peab esiteks neid iga kord tõlgendama, st määrama, kas mõõdiku väärtus tähendab. vajadus mingi tegevuse järele. Ja teiseks, ta lihtsalt ei märka kõiki neid hoiatusi, kui tal pole põhimõtteliselt midagi vaja teha. See on hea järelevalvereegel ja kõige esimene reegel SRE rakendamisel on see, et teavitamine peaks tulema ainult siis, kui on vaja meetmeid.
Tavalisel juhul on sündmustel 3 taset. On hoiatusi, on pileteid, on logisid. Hoiatused on kõik, mis nõuab viivitamatut tegutsemist. See tähendab, et kõik on katki, peate selle kohe parandama. Piletid nõuavad edasilükkamist. Jah, sa pead midagi tegema, sa pead tegema midagi käsitsi, automatiseerimine ebaõnnestus, kuid sa ei pea seda järgmise paari minuti jooksul tegema. Logid on kõik, mis ei nõua tegutsemist ja üldiselt, kui asjad lähevad hästi, siis keegi ei loe neid kunagi. Logisid on vaja lugeda alles siis, kui tagantjärele selgus, et midagi läks juba mõnda aega katki, me ei teadnud sellest. Või peate tegema uurimistööd. Aga üldiselt läheb logidesse kõik, mis tegevust ei nõua.
Selle kõige kõrvalmõjuna on see, et kui oleme defineerinud, millised sündmused nõuavad tegevusi ja oleme hästi kirjeldanud, millised need tegevused olema peaksid, tähendab see, et tegevust saab automatiseerida. See tähendab, mis juhtub. Lähme valvelolekust. Lähme tegudele. Läheme selle toimingu kirjelduse juurde. Ja siis liigume edasi automatiseerimise juurde. See tähendab, et igasugune automatiseerimine algab reaktsioonist sündmusele.
Seire juurest liigume edasi termini nimega vaadeldavus. Viimastel aastatel on selle sõna ümber olnud ka väike hüpe. Ja vähesed inimesed mõistavad kontekstiväliselt, mida see tähendab. Kuid peamine on see, et jälgitavus on süsteemi läbipaistvuse mõõdik. Kui midagi läks valesti, siis kui kiiresti saate kindlaks teha, mis täpselt valesti läks ja milline oli süsteemi olukord sel hetkel. Koodi osas: milline funktsioon ebaõnnestus, milline teenus ebaõnnestus. Mis seisus olid näiteks sisemuutujad, konfiguratsioon. Infrastruktuuri osas on see see, millises saadavuse tsoonis tõrge ilmnes ja kui teil on installitud mõni Kubernetes, siis millises pesas tõrge ilmnes, milline oli hoidiku olek. Ja vastavalt sellele on vaadeldavusel otsene seos MTTR-iga. Mida kõrgem on teenuse Vaadeldavus, seda lihtsam on viga tuvastada, seda lihtsam on viga parandada, seda lihtsam on viga automatiseerida, seda madalam on MTTR.
Liikudes taas väikeettevõtete juurde, on juba praegu väga levinud küsimus, kuidas tulla toime meeskonna suurusega ja kas väikesele meeskonnale on vaja palgata eraldi SRE. Sellest juba natuke varem juttu olnud. Startupi või näiteks meeskonna arengu esimestel etappidel pole see sugugi vajalik, sest SRE-st saab teha üleminekurolli. Ja see elavdab meeskonda veidi, sest seal on vähemalt mõningane mitmekesisus. Ja lisaks valmistab see inimesi ette selleks, et kasvuga muutuvad SRE kohustused üldiselt väga oluliselt. Kui võtta inimene tööle, siis loomulikult on tal mingid ootused. Ja need ootused aja jooksul ei muutu, kuid nõuded muutuvad väga palju. Seetõttu on SRE palkamine varases staadiumis üsna keeruline. Enda kasvatamine on palju lihtsam. Aga selle peale tasub mõelda.
Ainus erand on ehk siis, kui kasvunõuded on väga ranged ja täpselt määratletud. St startupi puhul võib see olla mingisugune investorite surve, mingisugune kasvuprognoos mitu korda korraga. Siis on SRE palkamine põhimõtteliselt põhjendatud, sest seda saab õigustada. Meil on kasvunõuded, vajame inimest, kes vastutaks selle eest, et sellise kasvuga ei purune midagi.
Veel üks küsimus. Mida teha, kui arendajad lõikavad mitu korda funktsiooni, mis läbib testid, kuid rikub tootmist, laadib baasi, rikub muid funktsioone, millist protsessi rakendada. Sellest lähtuvalt võetakse sel juhul kasutusele vigade eelarve. Ja mõnda teenust, mõnda funktsiooni katsetatakse juba tootmises. See võib olla kanaari saar, kui ainult väike arv kasutajaid, kuid juba tootmises, võetakse kasutusele funktsioon, kuid juba eeldusega, et kui midagi läheb katki, näiteks poolel protsendil kõigist kasutajatest, vastab see ikkagi eelarve vigade jaoks. Sellest lähtuvalt, jah, tekib tõrge, mõne kasutaja jaoks läheb kõik katki, kuid oleme juba öelnud, et see on normaalne.
Tekkis küsimus SRE tööriistade kohta. See tähendab, kas on midagi konkreetset, mida SRE-d kasutaksid, mida kõik teised ei kasutaks. Tegelikult on mõned väga spetsialiseerunud utiliidid, on mingi tarkvara, mis näiteks simuleerib koormusi või tegeleb kanaari A / B testimisega. Kuid põhimõtteliselt on SRE tööriistakomplekt see, mida teie arendajad juba kasutavad. Kuna SRE suhtleb otse arendusmeeskonnaga. Ja kui teil on erinevad tööriistad, siis selgub, et sünkroonimine võtab aega. Eriti kui SRE-d töötavad suurtes meeskondades, suurtes ettevõtetes, kus võib olla mitu meeskonda, on siin palju abiks ettevõtteülene standardiseerimine, sest kui 50 meeskonnas kasutatakse 50 erinevat utiliiti, siis see tähendab, et SRE peab neid teadma. kõik. Ja seda muidugi kunagi ei juhtu. Ja töö kvaliteet, vähemalt mõne meeskonna kontrolli kvaliteet langeb oluliselt.
Meie veebiseminar hakkab lõppema. Jõudsin mõned põhilised asjad ära rääkida. SRE-st ei saa muidugi tunniga midagi rääkida ja aru saada. Aga ma loodan, et mul õnnestus see mõtteviis, peamised võtmepunktid, edasi anda. Ja siis on huvi korral võimalik teemasse süveneda, ise õppida, vaadata, kuidas seda rakendatakse teiste inimeste poolt, teistes ettevõtetes. Ja vastavalt sellele tulge veebruari alguses meie juurde Slurm SRE-sse.
Slurm SRE on kolmepäevane intensiivkursus, mis räägib sellest, millest ma praegu räägin, kuid palju sügavamalt, reaalsete juhtumitega, praktikaga on kogu intensiivne suunatud praktilisele tööle. Inimesed jagatakse meeskondadesse. Te kõik töötate reaalsete juhtumite kallal. Sellest lähtuvalt on meil Booking.com-i juhendajad Ivan Kruglov ja Ben Tyler. Meil on suurepärane Eugene Barabbas Google'ist San Franciscost. Ja ma ütlen sulle ka midagi. Nii et külastage meid kindlasti.
Niisiis, bibliograafia. SRE kohta on viiteid. samal raamatul või õigemini kahel SRE-teemalisel raamatul, mille on kirjutanud Google. Veel üks , kus terminid ja nende rakendamine on veidi täpsemad. Järgmised 3 on aruanded SRE kohta erinevates ettevõtetes. Esiteks - , see on Google'i Ben Traineri peakõne. Teine - . Kolmas on jälle . Neljas aruanne alates , millel on vaid 5 SRE võtmetöötajat 190 riigis. Seda kõike on väga huvitav vaadata, sest nii nagu DevOps tähendab erinevatele ettevõtetele ja isegi erinevatele meeskondadele väga erinevaid asju, on SRE-l ka sarnase suurusega ettevõtetes väga erinevad kohustused.
Veel 2 linki kaosetehnoloogia põhimõtete kohta: , . Ja lõpus on 3 loendit sarjast Awesome Lists umbes umbes ja umbes . SRE nimekiri on uskumatult suur, seda kõike pole vaja läbi lugeda, seal on umbes 200 artiklit. Soovitan soojalt artikleid, mis käsitlevad võimsuse planeerimist ja laitmatut surmajärgset surma.
Huvitav artikkel:
Aitäh, et kuulasite mind kogu selle aja. Loodetavasti õppisite midagi. Loodetavasti on teil piisavalt materjali, et veelgi rohkem õppida. Ja kohtumiseni. Loodetavasti veebruaris.
Veebiseminari juhtis Eduard Medvedev.
PS: kellele meeldib lugeda, andis Eduard viidete nimekirja. Need, kes eelistavad praktikas mõista, on oodatud .
Allikas: www.habr.com