Vefnámskeiðið hefur lélegt hljóð, svo við höfum umritað það.
Ég heiti Medvedev Eduard. Í dag mun ég tala um hvað SRE er, hvernig SRE birtist, hvaða vinnuviðmið SRE verkfræðingar hafa, aðeins um áreiðanleikaviðmið, aðeins um eftirlit með því. Við munum ganga á toppana, því þú getur ekki sagt mikið á klukkutíma, en ég mun gefa efni til frekari skoðunar og við bíðum öll eftir þér á . í Moskvu í lok janúar.
Í fyrsta lagi skulum við tala um hvað SRE - Site Reliability Engineering - er. Og hvernig það birtist sem sérstök staða, sem sérstök stefna. Þetta byrjaði allt með því að í hefðbundnum þróunarhringjum eru Dev og Ops tvö gjörólík lið, venjulega með tvö gjörólík markmið. Markmið þróunarteymisins er að útfæra nýja eiginleika til að mæta þörfum fyrirtækja. Markmið Ops liðsins er að tryggja að allt virki og ekkert brotni. Augljóslega stangast þessi markmið beint á milli: svo að allt virki og ekkert brotni, er betra að setja nýja eiginleika eins lítið og mögulegt er. Vegna þessa koma upp mörg innri átök sem aðferðafræðin sem nú heitir DevOps er að reyna að leysa.
Vandamálið er að við höfum ekki skýra skilgreiningu á DevOps og skýra útfærslu á DevOps. Ég talaði á ráðstefnu í Yekaterinburg fyrir 2 árum og þar til nú byrjaði DevOps hluti með skýrslunni „Hvað er DevOps“. Árið 2017 er Devops tæplega 10 ára en við erum enn að deila um hvað það er. Og þetta er mjög undarleg staða sem Google reyndi að leysa fyrir nokkrum árum.
Árið 2016 gaf Google út bók sem heitir Site Reliability Engineering. Og reyndar var það með þessari bók sem SRE hreyfingin hófst. SRE er sérstök útfærsla á DevOps hugmyndafræðinni í tilteknu fyrirtæki. SRE verkfræðingar eru staðráðnir í að tryggja að kerfi virki á áreiðanlegan hátt. Þeir koma aðallega frá forriturum, stundum stjórnendum með sterkan þróunarbakgrunn. Og þeir gera það sem kerfisstjórar voru vanir að gera, en sterkur bakgrunnur í þróun og þekkingu á kerfinu hvað varðar kóða leiðir til þess að þetta fólk hallast ekki að venjubundnum stjórnunarstörfum heldur sjálfvirkni.
Það kemur í ljós að DevOps hugmyndafræðin í SRE teymum er útfærð með því að það eru SRE verkfræðingar sem leysa uppbyggingarvandamál. Hérna er það sama tengslin milli Dev og Ops og fólk hefur talað um í 8 ár. Hlutverk SRE er svipað hlutverk arkitekts að því leyti að nýliðar verða ekki SREs. Fólk í upphafi starfsferils síns hefur enn enga reynslu og hefur ekki tilskilin breidd í þekkingu. Vegna þess að SRE krefst mjög háþróaðrar þekkingar á nákvæmlega hvað og hvenær nákvæmlega getur farið úrskeiðis. Hér þarf því að jafnaði einhvers konar reynslu bæði innan fyrirtækisins og utan.
Þeir spyrja hvort muninum á SRE og devops verði lýst. Henni hefur nýlega verið lýst. Við getum rætt um stöðu SRE í samtökunum. Ólíkt þessari klassísku DevOps nálgun, þar sem Ops er enn sérstök deild, er SRE hluti af þróunarteymi. Þeir taka þátt í vöruþróun. Það er jafnvel nálgun þar sem SRE er hlutverk sem fer frá einum þróunaraðila til annars. Þeir taka þátt í kóðadómum á sama hátt og til dæmis UX hönnuðir, þróunaraðilar sjálfir, stundum vörustjórar. SREs starfa á sama stigi. Við þurfum að samþykkja þau, við þurfum að endurskoða þau, þannig að fyrir hverja dreifingu segir SRE: „Allt í lagi, þessi dreifing, þessi vara mun ekki hafa neikvæð áhrif á áreiðanleika. Og ef það gerist, þá innan nokkurra viðunandi marka. Við munum líka tala um þetta.
Í samræmi við það hefur SRE neitunarvald til að breyta kóðanum. Og almennt leiðir þetta líka til einhvers konar smáátaka ef SRE er útfært á rangan hátt. Í sömu bók um Site Reliability Engineering segja margir hlutar, ekki einu sinni einn, hvernig eigi að forðast þessi árekstra.
Fólk spyr hvernig SRE tengist upplýsingaöryggi. SRE kemur ekki beint að upplýsingaöryggi. Aðallega í stórum fyrirtækjum er þetta gert af einstaklingum, prófunaraðilum og sérfræðingum. En SRE hefur einnig samskipti við þá í þeim skilningi að sumar aðgerðir, sumar skuldbindingar, sumar dreifingar sem hafa áhrif á öryggi geta einnig haft áhrif á framboð vörunnar. Þess vegna hefur SRE almennt samskipti við hvaða teymi sem er, þar á meðal öryggisteymi, þar á meðal sérfræðinga. Þess vegna er aðallega þörf á SRE þegar reynt er að innleiða DevOps, en álagið á þróunaraðila verður of mikið. Það er, þróunarteymið sjálft getur ekki lengur ráðið við þá staðreynd að nú þurfa þeir líka að bera ábyrgð á Ops. Og sérstakt hlutverk birtist. Þetta hlutverk er gert ráð fyrir í fjárlögum. Stundum er þetta hlutverk innbyggt í stærð teymis, sérstakur einstaklingur kemur fram, stundum verður einn verktaki það. Svona birtist fyrsti SRE í liðinu.
Flækjustig kerfisins sem SRE hefur áhrif á, flókið sem hefur áhrif á áreiðanleika starfseminnar, er nauðsynlegt og tilviljun. Nauðsynlegt flókið er þegar flókið vöru eykst að því marki sem nýir vörueiginleikar krefjast. Random flókið er þegar flókið kerfi eykst, en vörueiginleikinn og viðskiptakröfur hafa ekki bein áhrif á þetta. Það kemur í ljós að annað hvort hefur verktaki gert mistök einhvers staðar, eða reikniritið er ekki ákjósanlegt, eða einhver viðbótarhagsmunir eru kynntir sem auka flókið vörunnar án sérstakrar þörf. Gott SRE ætti alltaf að skera úr þessu ástandi. Það er að segja að allir skuldbindingar, hvaða dreifing sem er, hvaða pull-beiðni sem er, þar sem erfiðleikarnir eru auknir vegna tilviljunarkenndra samlagningar, ætti að vera læst.
Spurningin er af hverju ekki bara að ráða verkfræðing, kerfisstjóra með mikla þekkingu í teyminu. Okkur er sagt að verktaki í hlutverki verkfræðings sé ekki besta mönnunarlausnin. Verktaki í hlutverki verkfræðings er ekki alltaf besta mönnunarlausnin, en málið hér er að verktaki sem stundar Ops hefur aðeins meiri löngun í sjálfvirkni, hefur aðeins meiri þekkingu og færni til að framkvæma þessari sjálfvirkni. Og í samræmi við það, minnkum við ekki aðeins tíma fyrir tilteknar aðgerðir, ekki aðeins venjuna, heldur einnig svo mikilvægar viðskiptabreytur eins og MTTR (Mean Time To Recovery, batatími). Þannig, og við munum líka tala um þetta aðeins síðar, spörum við fé fyrir samtökin.
Nú skulum við tala um forsendur fyrir rekstri SRE. Og fyrst og fremst um áreiðanleika. Í litlum fyrirtækjum, sprotafyrirtækjum, gerist það oft að fólk gerir ráð fyrir því að ef þjónustan er vel skrifuð, ef varan er vel og rétt skrifuð, þá virki hún, hún brotni ekki. Það er það, við skrifum góðan kóða, svo það er ekkert að brjóta. Kóðinn er mjög einfaldur, það er ekkert að brjóta. Þetta er um það bil sama fólkið og segir að við þurfum ekki próf, því sjáðu, þetta eru þrjár VPI aðferðirnar, af hverju að brjótast hér.
Þetta er auðvitað allt rangt. Og þetta fólk er mjög oft bitið af slíkum kóða í reynd, vegna þess að hlutirnir brotna. Hlutir brotna stundum á ófyrirsjáanlegasta vegu. Stundum segir fólk nei, það mun aldrei gerast. Og það gerist alltaf. Það gerist nógu oft. Og þess vegna leitast enginn eftir 100% framboði, því 100% framboð gerist aldrei. Þetta er normið. Og þess vegna, þegar við tölum um framboð á þjónustu, tölum við alltaf um níu. 2 níur, 3 níur, 4 níur, 5 níur. Ef við þýðum þetta yfir í niðutíma, þá td 5 níu, þá er þetta aðeins meira en 5 mínútur af niðri á ári, 2 níu eru 3,5 dagar í niðri.
En það er augljóst að á einhverjum tímapunkti er lækkun á POI og arðsemi fjárfestingar. Að fara úr tveimur níu í þrjár níu þýðir að draga úr niður í miðbæ um meira en 3 daga. Með því að fara úr fjórum níu í fimm minnkar niðurtími um 47 mínútur á ári. Og það kemur í ljós að þetta er kannski ekki mikilvægt fyrir fyrirtæki. Og almennt séð er nauðsynlegur áreiðanleiki ekki tæknilegt mál, í fyrsta lagi er það viðskiptamál, það er vörumál. Hversu mikið niðritíma er ásættanlegt fyrir notendur vörunnar, hverju búast þeir við, hversu mikið þeir borga, til dæmis hversu miklum peningum þeir tapa, hversu miklum peningum tapar kerfið.
Mikilvæg spurning hér er hver er áreiðanleiki íhlutanna sem eftir eru. Vegna þess að munurinn á milli 4 og 5 níu mun ekki vera sýnilegur á snjallsíma með 2 níu af áreiðanleika. Í grófum dráttum, ef eitthvað bilar í snjallsíma í þjónustu þinni 10 sinnum á ári, þá er líklegast 8 sinnum bilunin á OS hliðinni. Notandinn er vanur þessu og mun ekki taka eftir einu sinni enn á ári. Nauðsynlegt er að tengja verðið við að auka áreiðanleika og auka hagnað.
Bara í bókinni um SRE er gott dæmi um að hækka í 4 níu úr 3 níu. Í ljós kemur að framboðsaukningin er aðeins innan við 0,1%. Og ef tekjur þjónustunnar eru $1 milljón á ári, þá er tekjuaukningin $900. Ef það kostar okkur minna en $900 á ári að auka viðráðanlegu verði um níu, þá er hækkunin fjárhagslega skynsamleg. Ef það kostar meira en 900 dollara á ári er það ekki lengur skynsamlegt, því tekjuaukningin bætir einfaldlega ekki upp launakostnað, auðlindakostnað. Og 3 níu verða nóg fyrir okkur.
Þetta er auðvitað einfaldað dæmi þar sem allar beiðnir eru jafnar. Og að fara úr 3 níu í 4 níu er nógu auðvelt, en á sama tíma, til dæmis að fara úr 2 níu í 3, er þetta nú þegar sparnaður upp á 9 þúsund dollara, það getur verið fjárhagslegt vit. Auðvitað, í raun og veru, er bilun í skráningarbeiðni verri en bilun á að birta síðuna, beiðnir hafa mismunandi vægi. Þeir geta haft allt aðra viðmiðun frá viðskiptalegu sjónarmiði, en alla vega, að jafnaði, ef við erum ekki að tala um einhverja sérstaka þjónustu, þá er þetta nokkuð áreiðanleg nálgun.
Við fengum fyrirspurn um hvort SRE sé einn af umsjónaraðilum við val á byggingarlausn fyrir þjónustuna. Við skulum segja hvað varðar samþættingu í núverandi innviði, þannig að það tapi ekki stöðugleika hans. Já, SREs, á sama hátt og pull-beiðnir, skuldbindingar, útgáfur hafa áhrif á arkitektúrinn, innleiðingu nýrrar þjónustu, örþjónustu, innleiðingu nýrra lausna. Af hverju sagði ég áður að það þurfi reynslu, menntun þarf. Reyndar er SRE ein af hindrunarröddunum í hvaða byggingar- og hugbúnaðarlausn sem er. Samkvæmt því verður SRE sem verkfræðingur, fyrst og fremst, ekki aðeins að skilja, heldur einnig skilja hvernig sumar sérstakar ákvarðanir munu hafa áhrif á áreiðanleika, stöðugleika og skilja hvernig þetta tengist viðskiptaþörfum og frá hvaða sjónarhorni það getur verið ásættanlegt og sem ekki.
Þess vegna getum við nú bara talað um áreiðanleikaviðmið, sem venjulega eru skilgreind í SRE sem SLA (Service Level Agreement). Líklegast kunnuglegt hugtak. SLI (Service Level Indicator). SLO (Service Level Objective). Þjónustustigssamningur er kannski táknrænt hugtak, sérstaklega ef þú hefur unnið með netkerfi, með veitendum, með hýsingu. Þetta er almennur samningur sem lýsir frammistöðu allrar þjónustu þinnar, viðurlögum, sumum viðurlögum fyrir villur, mælingum, viðmiðum. Og SLI er framboðsmælingin sjálf. Það er, hvað SLI getur verið: Viðbragðstími frá þjónustunni, fjöldi villna í prósentum. Það gæti verið bandbreidd ef það er einhvers konar skráhýsing. Þegar kemur að greiningarreikniritum getur vísirinn verið til dæmis jafnvel réttmæti svarsins. SLO (Service Level Objective) er, hver um sig, sambland af SLI vísinum, gildi hans og tímabili.
Segjum að SLA gæti verið svona. Þjónustan er í boði 99,95% af tímanum allt árið. Eða 99 mikilvægum stuðningsmiðum verður lokað innan 3 klukkustunda á ársfjórðungi. Eða 85% fyrirspurna verður svarað innan 1,5 sekúndna í hverjum mánuði. Það er, við komumst smám saman að því að villur og bilanir eru alveg eðlilegar. Þetta er viðunandi staða, við erum að skipuleggja það, við erum jafnvel að treysta á það að einhverju leyti. Það er að segja SRE byggir upp kerfi sem geta gert mistök, sem verða að bregðast eðlilega við villum, sem verða að taka tillit til þeirra. Og hvenær sem mögulegt er, ættu þeir að meðhöndla villur á þann hátt að notandinn annað hvort tekur ekki eftir þeim, eða tekur eftir því, en það er einhvers konar lausn, þökk sé því að allt mun ekki falla alveg niður.
Til dæmis, ef þú hleður upp myndbandi á YouTube, og YouTube getur ekki umbreytt því strax, ef myndbandið er of stórt, ef sniðið er ekki ákjósanlegt, þá mun beiðnin náttúrulega ekki mistakast með tímamörkum, YouTube mun ekki gefa 502 villu , YouTube mun segja: „Við höfum búið til allt, myndbandið þitt er í vinnslu. Það verður tilbúið eftir um það bil 10 mínútur." Þetta er meginreglan um þokkafulla niðurbrot, sem þekkist til dæmis frá framhliðarþróun, ef þú hefur einhvern tíma gert þetta.
Næstu hugtök sem við munum tala um, sem eru mjög mikilvæg til að vinna með áreiðanleika, með villum, með væntingum, eru MTBF og MTTR. MTBF er meðaltími milli bilana. MTTR meðaltími til bata, meðaltími til bata. Það er, hversu langur tími hefur liðið frá því að villan uppgötvaðist, frá því að villan birtist þar til þjónustan var endurheimt í fulla eðlilega virkni. MTBF er aðallega lagað með vinnu við gæði kóða. Það er sú staðreynd að SREs geta sagt "nei". Og þú þarft skilning á öllu liðinu að þegar SRE segir "nei", þá segir hann það ekki vegna þess að hann er skaðlegur, ekki vegna þess að hann er slæmur, heldur vegna þess að annars munu allir þjást.
Aftur, það eru fullt af greinum, fullt af aðferðum, margar leiðir jafnvel í bókinni sem ég vísa svo oft í, hvernig á að tryggja að aðrir forritarar fari ekki að hata SRE. MTTR snýst aftur á móti um að vinna að SLOs þínum (Service Level Objective). Og það er aðallega sjálfvirkni. Vegna þess, til dæmis, SLO okkar er spenntur 4 níu á ársfjórðungi. Þetta þýðir að á 3 mánuðum getum við leyft 13 mínútna niðritíma. Og það kemur í ljós að MTTR má ekki vera meira en 13 mínútur. Ef við bregðumst við að minnsta kosti 13 niður í miðbæ á 1 mínútum þýðir það að við höfum þegar tæmt allt fjárhagsáætlun fjórðungsins. Við erum að brjóta SLO. 13 mínútur til að bregðast við og laga hrun er mikið fyrir vél, en mjög stutt fyrir mann. Vegna þess að þangað til einstaklingur fær viðvörun, þar til hann bregst við, þar til hann skilur villuna, eru það nú þegar nokkrar mínútur. Þangað til maður skilur hvernig á að laga það, hvað nákvæmlega á að laga, hvað á að gera, þá eru þetta nokkrar mínútur í viðbót. Og í raun, jafnvel þótt þú þurfir bara að endurræsa netþjóninn, eins og það kemur í ljós, eða hækka nýjan hnút, þá handvirkt er MTTR nú þegar um 7-8 mínútur. Þegar ferlið er sjálfvirkt nær MTTR mjög oft sekúndu, stundum millisekúndum. Google talar venjulega um millisekúndur, en í raun og veru er auðvitað ekki allt svo gott.
Helst ætti SRE að gera vinnu sína sjálfvirkan nánast alveg, því þetta hefur bein áhrif á MTTR, mælikvarða þess, SLO allrar þjónustunnar og, í samræmi við það, hagnað fyrirtækisins. Ef farið er fram úr tímanum er spurt hvort sökin sé hjá SRE. Sem betur fer er sökin ekki á neinn. Og þetta er sérstakt menning sem kallast balmeless postmortem, sem við munum ekki tala um í dag, en við munum greina það á Slurm. Þetta er mjög áhugavert efni sem hægt er að ræða mikið um. Í grófum dráttum má segja að ef farið er yfir úthlutaðan tíma á ársfjórðung, þá er lítið af öllum um að kenna, sem þýðir að það er ekki afkastamikið að kenna öllum, við skulum í staðinn, kannski ekki kenna neinum um, en leiðrétta ástandið og vinna með það sem við höfum. Mín reynsla er að þessi nálgun er dálítið framandi fyrir flest lið, sérstaklega í Rússlandi, en hún er skynsamleg og virkar mjög vel. Þess vegna mun ég mæla með því í lok greinarinnar og bókmennta sem þú getur lesið um þetta efni. Eða komdu til Slurm SRE.
Leyfðu mér að útskýra. Ef farið er yfir SLO tíma á ársfjórðungi, ef stöðvunartíminn var ekki 13 mínútur, heldur 15, hver getur þá verið um að kenna? Auðvitað getur SRE verið um að kenna, því hann gerði greinilega einhvers konar slæma skuldbindingu eða dreifingu. Umsjónarmaður gagnaversins gæti átt sök á þessu því hann gæti hafa sinnt einhvers konar ótímabundnu viðhaldi. Ef umsjónarmaður gagnaversins á sök á þessu, þá er það sá sem er frá Ops um að kenna, sem reiknaði ekki út viðhaldið þegar hann samræmdi SLO. Umsjónarmaður, tæknistjóri eða einhver sem skrifaði undir gagnaverssamninginn og gaf ekki gaum að SLA gagnaversins er ekki hannað fyrir tilskilinn niðurtíma er um að kenna. Samkvæmt því er allt smátt og smátt í þessari stöðu að kenna. Og það þýðir að það þýðir ekkert að skella skuldinni á neinn í þessari stöðu. En það þarf auðvitað að laga það. Þess vegna eru skurðaðgerðir. Og ef þú lest til dæmis GitHub postmortems, og þetta er alltaf mjög áhugaverð, lítil og óvænt saga í hverju tilviki, geturðu skipt út fyrir það að enginn segir nokkurn tíma að þessum tiltekna einstaklingi hafi verið um að kenna. Sökin er alltaf lögð á ákveðin ófullkomin ferli.
Við skulum halda áfram að næstu spurningu. Sjálfvirkni. Þegar ég tala um sjálfvirkni í öðru samhengi vísa ég oft í töflu sem segir þér hversu lengi þú getur unnið við að gera verkefni sjálfvirkt án þess að taka meiri tíma til að gera það sjálfvirkt en þú raunverulega sparar. Það er hængur á. Gallinn er sá að þegar SREs gera sjálfvirkt verkefni, spara þeir ekki aðeins tíma, þeir spara peninga, vegna þess að sjálfvirkni hefur bein áhrif á MTTR. Þeir spara sem sagt starfsanda og þróunaraðila, sem er líka óþrjótandi auðlind. Þeir draga úr rútínu. Og allt hefur þetta jákvæð áhrif á vinnu og þar af leiðandi á viðskipti, jafnvel þó svo virðist sem sjálfvirkni sé ekki skynsamleg með tilliti til tímakostnaðar.
Reyndar gerir það það næstum alltaf og það eru mjög fá tilvik þar sem það er ekki þess virði að gera eitthvað sjálfvirkt í SRE hlutverkinu. Næst verður talað um það sem kallað er villufjárhagsáætlun, fjárhagsáætlun fyrir villur. Reyndar kemur í ljós að ef þú ert að standa þig verulega betur en SLO sem þú setur þér þá er þetta heldur ekki mjög gott. Þetta er frekar slæmt, því SLO virkar ekki aðeins sem neðri mörk, heldur einnig sem áætluð efri mörk. Þegar þú setur sjálfum þér SLO upp á 99% framboð, og í raun ertu með 99,99%, kemur í ljós að þú hefur pláss fyrir tilraunir, sem mun alls ekki skaða fyrirtækið, því þú hefur sjálfur ákveðið þetta allt saman, og þú hafa þetta pláss ekki nota það. Þú hefur fjárhagsáætlun fyrir mistök sem í þínu tilviki er ekki eytt.
Hvað erum við að gera við það? Við notum það fyrir bókstaflega allt. Til að prófa við framleiðsluaðstæður, til að útfæra nýja eiginleika sem geta haft áhrif á afköst, fyrir útgáfur, fyrir viðhald, fyrir fyrirhugaða niður í miðbæ. Öfug regla gildir líka: ef fjárhagsáætlunin er uppurin getum við ekki gefið út neitt nýtt, því annars förum við yfir SLO. Fjárhagsáætlunin hefur þegar verið uppurin, við höfum gefið út eitthvað ef það hefur neikvæð áhrif á afkomuna, það er að segja ef þetta er ekki einhver leiðrétting sem í sjálfu sér eykur SLO beint, þá erum við að fara út fyrir fjárlög og þetta er slæm staða , það þarf að greina það, eftir slátrun og hugsanlega einhverja ferlileiðréttingu.
Það er, það kemur í ljós að ef þjónustan sjálf virkar ekki vel, og SLO er eytt og fjárhagsáætluninni er varið ekki í tilraunir, ekki í sumar útgáfur, heldur af sjálfu sér, þá í staðinn fyrir áhugaverðar lagfæringar, í stað áhugaverðra eiginleika, í staðinn fyrir áhugaverðar útgáfur. Í stað hvers kyns skapandi vinnu verður þú að takast á við heimskulegar lagfæringar til að koma fjárhagsáætluninni í lag aftur, eða breyta SLO, og þetta er líka ferli sem ætti ekki að gerast of oft.
Þess vegna kemur í ljós að við aðstæður þar sem við höfum meira fjárhagsáætlun fyrir villur, hafa allir áhuga: bæði SRE og verktaki. Fyrir forritara þýðir mikið fjárhagsáætlun fyrir villur að þú getur tekist á við útgáfur, próf, tilraunir. Fyrir SRE þýðir fjárhagsáætlun fyrir villur og innsláttur á það fjárhagsáætlun að þeir séu beinlínis að vinna starf sitt vel. Og þetta hefur áhrif á hvata einhvers konar sameiginlegrar vinnu. Ef þú hlustar á SRE sem þróunaraðila muntu hafa meira pláss fyrir góða vinnu og mun minni rútínu.
Það kemur í ljós að tilraunir í framleiðslu eru nokkuð mikilvægur og nánast óaðskiljanlegur hluti af SRE í stórum teymum. Og það gengur venjulega undir nafninu chaos engineering, sem kemur frá teyminu hjá Netflix sem gaf út tól sem heitir Chaos Monkey.
Chaos Monkey tengist CI/CD leiðslunni og hrynur af handahófi þjóninum í framleiðslu. Aftur, í SRE uppbyggingunni erum við að tala um þá staðreynd að niðurlagður þjónn er ekki slæmur í sjálfu sér, það er gert ráð fyrir. Og ef það er innan fjárhagsáætlunar er það ásættanlegt og skaðar ekki viðskiptin. Auðvitað er Netflix með nóg af óþarfa netþjónum, nóg af afritun, svo að hægt sé að laga þetta allt og svo að notandinn í heild sinni tekur ekki einu sinni eftir því, og enn frekar að enginn skilur eftir einn netþjón fyrir hvaða fjárhagsáætlun sem er.
Netflix var með heila föruneyti af slíkum tólum um tíma, ein þeirra, Chaos Gorilla, lokar algjörlega á eitt af framboðssvæðum Amazon. Og slíkir hlutir hjálpa til við að sýna í fyrsta lagi huldar ósjálfstæði, þegar ekki er alveg ljóst hvað hefur áhrif á hvað, hvað fer eftir hverju. Og þetta, ef þú ert að vinna með örþjónustu og skjölin eru ekki alveg fullkomin, gæti þetta verið þér kunnuglegt. Og aftur, þetta hjálpar mikið til að fanga villur í kóðanum sem þú getur ekki náð í sviðsetningu, vegna þess að hvaða sviðsetning er ekki nákvæmlega eftirlíking, vegna þess að álagskvarðinn er öðruvísi, álagsmynstrið er öðruvísi, búnaðurinn er líka, líklegast, annað. Hámarksálag getur líka verið óvænt og ófyrirsjáanlegt. Og slíkar prófanir, sem aftur fara ekki út fyrir fjárhagsáætlun, hjálpa mjög vel við að ná villum í innviðum sem sviðsetning, sjálfvirkar prófanir, CI / CD leiðsla munu aldrei ná. Og svo framarlega sem þetta er allt innifalið í kostnaðarhámarkinu þínu, þá skiptir það ekki máli að þjónustan þín hafi farið niður þar, þó það þætti mjög skelfilegt, þjónninn fór niður, þvílík martröð. Nei, það er eðlilegt, það er gott, það hjálpar til við að veiða pöddur. Ef þú ert með fjárhagsáætlun geturðu eytt því.
Spurning: hvaða bókmenntum get ég mælt með? Listinn er í lokin. Það er mikið af bókmenntum, ég mæli með nokkrum skýrslum. Hvernig það virkar og hvort SRE virkar í fyrirtækjum án eigin hugbúnaðarvöru eða með lágmarksþróun. Til dæmis í fyrirtæki þar sem aðalstarfsemin er ekki hugbúnaður. Í fyrirtæki, þar sem aðalstarfsemin er ekki hugbúnaður, virkar SRE nákvæmlega eins og annars staðar, því í fyrirtæki þarftu líka að nota, jafnvel þótt þú sért ekki að þróa, hugbúnaðarvörur, þú þarft að setja upp uppfærslur, þú þú þarft að breyta innviðum, þú þarft að vaxa, þú þarft að stækka. Og SREs hjálpa til við að bera kennsl á og spá fyrir um hugsanleg vandamál í þessum ferlum og stjórna þeim eftir að nokkur vöxtur hefst og viðskiptaþarfir breytast. Vegna þess að það er alls ekki nauðsynlegt að taka þátt í hugbúnaðarþróun til að hafa SRE, ef þú ert með að minnsta kosti nokkra netþjóna og býst við að minnsta kosti einhverjum vexti.
Sama gildir um lítil verkefni, lítil samtök, því stór fyrirtæki hafa fjárhagsáætlun og svigrúm til tilrauna. En á sama tíma er hægt að nota alla þessa ávexti tilrauna hvar sem er, það er að sjálfsögðu SREs birtust í Google, Netflix og Dropbox. En á sama tíma geta lítil fyrirtæki og sprotafyrirtæki nú þegar lesið samantekið efni, lesið bækur og horft á skýrslur. Þeir byrja að heyra um þetta oftar, skoða ákveðin dæmi, ég held, allt í lagi, þetta getur virkilega verið gagnlegt, við þurfum þetta líka, flott.
Það er, öll aðalvinna við að staðla þessa ferla hefur þegar verið unnin fyrir þig. Það er eftir fyrir þig að ákvarða hlutverk SRE sérstaklega í fyrirtækinu þínu og byrja í raun að innleiða allar þessar venjur, sem aftur hefur þegar verið lýst. Það er, frá gagnlegum meginreglum fyrir lítil fyrirtæki, þetta er alltaf skilgreiningin á SLA, SLI, SLO. Ef þú tekur ekki þátt í hugbúnaði, þá verða þetta innri SLAs og innri SLOs, innri fjárhagsáætlun fyrir villur. Þetta leiðir næstum alltaf til áhugaverðra umræðna innan teymisins og innan fyrirtækisins, vegna þess að það getur komið í ljós að þú eyðir í innviði, í einhvers konar skipulagningu hugsjónaferla, hin fullkomna leiðsla er miklu meira en nauðsynlegt er. Og þessar 4 níur sem þú ert með í upplýsingatæknideildinni, þú þarft þær ekki núna. En á sama tíma gætirðu eytt tíma, eytt fjárhagsáætlun fyrir mistök í eitthvað annað.
Samkvæmt því er eftirlit og skipulag eftirlits gagnlegt fyrir fyrirtæki af hvaða stærð sem er. Og almennt er þessi hugsunarháttur, þar sem mistök eru eitthvað ásættanleg, þar sem fjárhagsáætlun er fyrir hendi, þar sem markmið eru fyrir hendi, aftur gagnlegur fyrir fyrirtæki af hvaða stærð sem er, allt frá 3ja manna gangsetningu.
Síðasta tæknileg blæbrigði til að tala um er eftirlit. Vegna þess að ef við erum að tala um SLA, SLI, SLO, getum við ekki skilið án þess að fylgjast með því hvort við passum inn í fjárhagsáætlunina, hvort við uppfyllum markmið okkar og hvernig við höfum áhrif á endanlegt SLA. Ég hef séð svo oft að vöktun gerist svona: það er eitthvað gildi, til dæmis tími beiðni til þjónsins, meðaltími eða fjöldi beiðna í gagnagrunninn. Hann hefur staðal sem er ákveðinn af verkfræðingi. Ef mæligildið víkur frá viðmiðunarreglunni kemur tölvupóstur. Þetta er allt algjörlega gagnslaust, að jafnaði, vegna þess að það leiðir til þess að viðvörunum, ofgnótt af skilaboðum frá eftirliti, þegar einstaklingur þarf í fyrsta lagi að túlka þau í hvert skipti, það er að segja hvort gildi mæligildisins þýðir þörf á einhverjum aðgerðum. Og í öðru lagi hættir hann einfaldlega að taka eftir öllum þessum viðvörunum, þegar í rauninni er ekki krafist aðgerða af honum. Það er góð eftirlitsregla og fyrsta reglan þegar SRE er innleidd er að tilkynning ætti aðeins að koma þegar aðgerða er þörf.
Í venjulegu tilviki eru 3 stig atburða. Það eru tilkynningar, það eru miðar, það eru logs. Viðvaranir eru allt sem krefst tafarlausra aðgerða frá þér. Það er, allt er bilað, það þarf að laga það núna. Miðar eru eitthvað sem krefst aðgerða í bið. Já, þú þarft að gera eitthvað, þú þarft að gera eitthvað handvirkt, sjálfvirkni hefur mistekist, en þú þarft ekki að gera það á næstu mínútum. Logs eru allt sem krefst ekki aðgerða og almennt, ef vel gengur, mun enginn nokkurn tíma lesa þær. Nauðsynlegt er að lesa loggana aðeins þegar eftir á að hyggja kemur í ljós að eitthvað var bilað í nokkurn tíma, við vissum ekki af því. Eða það þarf að gera einhvers konar rannsókn. En almennt fer allt sem ekki krefst neinna aðgerða í logs.
Sem fylgifiskur alls þessa, ef við höfum skilgreint hvaða atburðir krefjast aðgerða og höfum lýst vel hverjar þessar aðgerðir ættu að vera, þýðir þetta að aðgerðin er hægt að gera sjálfvirkan. Það er það sem gerist. Við förum úr árvekni. Við skulum fara í aðgerð. Við förum að lýsingu á þessari aðgerð. Og svo förum við yfir í sjálfvirkni. Það er, öll sjálfvirkni byrjar með viðbrögðum við atburði.
Frá vöktun förum við yfir í hugtak sem kallast Observability. Það hefur líka verið smá hype í kringum þetta orð undanfarin ár. Og fáir skilja hvað það þýðir úr samhengi. En aðalatriðið er að Observability er mælikvarði fyrir gagnsæi kerfisins. Ef eitthvað fór úrskeiðis, hversu fljótt er hægt að ákvarða hvað nákvæmlega fór úrskeiðis og hvernig ástand kerfisins var á því augnabliki. Hvað varðar kóða: hvaða aðgerð mistókst, hvaða þjónusta mistókst. Hvernig var ástandið á til dæmis innri breytum, uppsetningu. Hvað varðar innviði, þá er þetta á hvaða framboðssvæði bilunin átti sér stað, og ef þú ert með einhverjar Kubernetes, þá í hvaða belg bilunin átti sér stað, hvernig var ástand belgsins. Og í samræmi við það hefur Observability bein tengsl við MTTR. Því meiri sem eftirlitshæfni þjónustunnar er, því auðveldara er að bera kennsl á villuna, því auðveldara er að laga villuna, því auðveldara er að gera villuna sjálfvirkan, því lægra er MTTR.
Þegar farið er yfir í lítil fyrirtæki aftur, er mjög algengt að spyrja, jafnvel núna, hvernig eigi að bregðast við teymisstærð og hvort lítið teymi þurfi að ráða sérstakan SRE. Búinn að tala um þetta aðeins áðan. Á fyrstu stigum þróunar sprotafyrirtækis eða, til dæmis, teymi, er þetta alls ekki nauðsynlegt, vegna þess að hægt er að gera SRE að bráðabirgðahlutverki. Og þetta mun endurlífga liðið aðeins, því það er að minnsta kosti nokkur fjölbreytileiki. Og auk þess mun það undirbúa fólk fyrir þá staðreynd að með vexti, almennt, munu ábyrgð SRE breytast mjög verulega. Ef þú ræður mann, þá hefur hann auðvitað einhverjar væntingar. Og þessar væntingar munu ekki breytast með tímanum, en kröfurnar breytast mjög mikið. Þess vegna er frekar erfitt hvernig á að ráða SRE á fyrstu stigum. Það er miklu auðveldara að rækta þitt eigið. En það er umhugsunarvert.
Eina undantekningin er líklega þegar það eru mjög strangar og vel skilgreindar kröfur um hæð. Það er að segja ef um sprotafyrirtæki er að ræða gæti þetta verið einhvers konar þrýstingur frá fjárfestum, einhvers konar spá um vöxt nokkrum sinnum í einu. Þá er almennt réttlætanlegt að ráða SRE vegna þess að það er hægt að réttlæta það. Við höfum vaxtarkröfur, við þurfum mann sem mun bera ábyrgð á því að við slíkan vöxt brotni ekkert.
Ein spurning enn. Hvað á að gera þegar forritararnir klippa nokkrum sinnum eiginleika sem standast prófin, en brýtur framleiðsluna, hleður grunninn, brýtur aðra eiginleika, hvaða ferli á að innleiða. Samkvæmt því er það í þessu tilviki fjárveiting vegna villna sem er kynnt. Og sumir þjónustunnar, sumir eiginleikarnir eru nú þegar í prófun í framleiðslunni. Það getur verið kanarí, þegar aðeins lítill fjöldi notenda, en þegar í framleiðslu, er aðgerð notuð, en nú þegar með von um að ef eitthvað bilar, til dæmis fyrir hálft prósent allra notenda, mun það samt uppfylla fjárhagsáætlun vegna villna. Í samræmi við það, já, það verður villa, fyrir suma notendur mun allt brotna, en við höfum þegar sagt að þetta sé eðlilegt.
Spurt var um SRE verkfæri. Það er, er eitthvað sérstakt sem SREs myndu nota sem allir aðrir myndu ekki? Reyndar eru til mjög sérhæfð tól, það er einhver hugbúnaður sem til dæmis líkir eftir álagi eða gerir kanarífugl A/B próf. En í grundvallaratriðum er SRE verkfæri það sem verktaki þínir nota nú þegar. Vegna þess að SRE hefur bein samskipti við þróunarteymið. Og ef þú ert með mismunandi verkfæri kemur í ljós að það tekur tíma að samstilla. Sérstaklega ef SREs vinna í stórum teymum, í stórum fyrirtækjum þar sem það geta verið mörg teymi, mun stöðlun á öllu fyrirtækinu vera mjög gagnleg hér, því ef 50 teymi nota 50 mismunandi veitur þýðir það að SRE verður að þekkja þær allar. Og auðvitað mun þetta aldrei gerast. Og gæði vinnunnar, gæði eftirlits að minnsta kosti sumra teyma munu minnka verulega.
Vefnámskeiðinu okkar er að ljúka. Mér tókst að segja nokkur grundvallaratriði. Auðvitað er ekkert hægt að segja og skilja um SRE á klukkutíma. En ég vona að mér hafi tekist að koma þessum hugsunarhætti á framfæri, helstu lykilatriðin. Og þá verður hægt, ef áhugi er fyrir, að kafa ofan í efnið, læra á eigin spýtur, skoða hvernig það er útfært af öðru fólki, í öðrum fyrirtækjum. Og í samræmi við það, í byrjun febrúar, komdu til okkar á Slurm SRE.
Slurm SRE er þriggja daga átaksnámskeið sem mun fjalla um það sem ég er að tala um núna, en með miklu meiri dýpt, með raunverulegum tilfellum, með æfingum, miðar allt námið að verklegu starfi. Fólki verður skipt í lið. Þið munuð öll vinna að raunverulegum málum. Í samræmi við það höfum við kennara frá Booking.com Ivan Kruglov og Ben Tyler. Við eigum dásamlegan Evgeniy Varabbas frá Google, frá San Francisco. Og ég skal líka segja þér eitthvað. Svo endilega komið í heimsókn til okkar.
Svo, listi yfir tilvísanir. Það eru tenglar á SRE. á sömu bók, eða réttara sagt á 2 bækur um SRE, skrifaðar af Google. Annar , þar sem skilmálar og beiting þeirra eru aðeins ítarlegri. Næstu 3 eru skýrslur um SRE í mismunandi fyrirtækjum. Fyrst - , þetta er grunntónn frá Ben Trainer hjá Google. Annað - . Þriðja er aftur . Fjórða skýrsla frá , sem hefur aðeins 5 lykilstarfsmenn SRE í 190 löndum. Það er mjög áhugavert að skoða þetta allt, því alveg eins og DevOps þýðir mjög mismunandi hluti fyrir mismunandi fyrirtæki og jafnvel mismunandi teymi, þá hefur SRE mjög mismunandi skyldur, jafnvel í fyrirtækjum af svipaðri stærð.
2 fleiri tenglar um meginreglur óreiðuverkfræði: , . Og í lokin eru 3 listar úr seríunni Awesome Lists um um og um . Listinn á SRE er ótrúlega stór, þú þarft ekki að fara í gegnum þetta allt, það eru um 200 greinar. Ég mæli eindregið með greinunum um getuskipulagningu og saklausa skurðaðgerð.
Áhugavert grein:
Þakka þér fyrir að hlusta á mig allan þennan tíma. Vona að þú hafir lært eitthvað. Vona að þú hafir nóg efni til að læra enn meira. Og sjáumst. Vonandi í febrúar.
Vefnámskeiðið var gestgjafi af Eduard Medvedev.
PS: fyrir þá sem hafa gaman af að lesa gaf Eduard lista yfir tilvísanir. Þeir sem kjósa að skilja í reynd eru velkomnir .
Heimild: www.habr.com