ProHoster > Blogs > Administrācija > Vebināra "SRE - hype or the future?" transkripcija.

Vebināra "SRE - hype or the future?" transkripcija.

Vebināram ir vājÅ” audio, tāpēc mēs izveidojām stenogrammu.

Mani sauc Medvedevs Eduards. Å odien es runāŔu par to, kas ir SRE, kā parādÄ«jās SRE, kādi ir SRE inženieru darba kritēriji, nedaudz par uzticamÄ«bas kritērijiem, nedaudz par tā uzraudzÄ«bu. Mēs iesim pāri, jo stundas laikā neko daudz nevar pateikt, bet es jums iedoÅ”u materiālus papildu izskatÄ«Å”anai, un mēs visi gaidām jÅ«s plkst. Slurme SRE. janvāra beigās Maskavā.

Vispirms parunāsim par to, kas ir SRE ā€” vietnes uzticamÄ«bas inženierija. Un kā tas parādÄ«jās kā atseviŔķa pozÄ«cija, kā atseviŔķs virziens. Viss sākās ar to, ka tradicionālajās attÄ«stÄ«bas aprindās Dev un Ops ir divas pilnÄ«gi atŔķirÄ«gas komandas, parasti ar diviem pilnÄ«gi atŔķirÄ«giem mērÄ·iem. Izstrādes komandas mērÄ·is ir ieviest jaunas funkcijas un apmierināt uzņēmuma vajadzÄ«bas. Ops komandas mērÄ·is ir pārliecināties, ka viss darbojas un nekas neplÄ«st. AcÄ«mredzot Å”ie mērÄ·i ir tieŔā pretrunā viens otram: lai viss darbotos un nekas nesabojātos, pēc iespējas mazāk izvērsiet jaunas funkcijas. Å Ä« iemesla dēļ ir daudz iekŔēju konfliktu, ko mēģina atrisināt metodoloÄ£ija, ko tagad sauc par DevOps.

Problēma ir tā, ka mums nav skaidras DevOps definÄ«cijas un skaidras DevOps ievieÅ”anas. Es runāju konferencē Jekaterinburgā pirms 2 gadiem, un lÄ«dz Å”im DevOps sadaļa sākās ar ziņojumu ā€œKas ir DevOpsā€. 2017. gadā devops ir gandrÄ«z 10 gadus vecs, bet mēs joprojām strÄ«damies par to, kas tas ir. Un Ŕī ir ļoti dÄ«vaina situācija, ko Google mēģināja atrisināt pirms dažiem gadiem.

2016. gadā Google izlaida grāmatu ā€œVietnes uzticamÄ«bas inženierijaā€. Un patiesÄ«bā tieÅ”i ar Å”o grāmatu sākās SRE kustÄ«ba. SRE ir Ä«paÅ”a iespēja DevOps paradigmas ievieÅ”anai konkrētā uzņēmumā. SRE inženieri izvirzÄ«ja sev mērÄ·i nodroÅ”ināt sistēmu uzticamu darbÄ«bu. Tie galvenokārt tiek ņemti no izstrādātājiem, dažreiz no administratoriem ar spēcÄ«gu izstrādes pieredzi. Un viņi dara to, ko agrāk darÄ«ja sistēmu administratori, bet spēcÄ«ga pieredze izstrādē un zināŔanas par sistēmu no koda viedokļa noved pie tā, ka Å”ie cilvēki nav tendēti uz ikdienas administratÄ«vo darbu, bet gan ir tendēti uz automatizāciju.

Izrādās, ka DevOps paradigma SRE komandās tiek Ä«stenota ar to, ka ir SRE inženieri, kas risina strukturālās problēmas. LÅ«k, tas pats savienojums starp Dev un Ops, par ko cilvēki runā jau 8 gadus. SRE loma ir lÄ«dzÄ«ga arhitekta lomai, jo iesācēji nekļūst par SRE. Cilvēkiem savas karjeras sākumā vēl nav pieredzes un nepiecieÅ”amo zināŔanu plaÅ”uma. Tā kā SRE ir nepiecieÅ”amas ļoti sarežģītas zināŔanas par to, kas un kad tieÅ”i var noiet greizi. Tāpēc Å”eit, kā likums, ir nepiecieÅ”ama sava veida pieredze gan uzņēmumā, gan ārpus tā.

Viņi jautā, vai tiks aprakstÄ«ta atŔķirÄ«ba starp SRE un devops. Viņa tikko tika aprakstÄ«ta. Var runāt par SRE vietu organizācijā. AtŔķirÄ«bā no Ŕīs klasiskās DevOps pieejas, kur Ops joprojām ir atseviŔķa nodaļa, SRE ir daļa no izstrādes komandas. Viņi ir iesaistÄ«ti produktu izstrādē. Ir pat pieeja, kurā SRE ir loma, kas pāriet no viena izstrādātāja uz otru. Viņi piedalās kodu pārskatÄ«Å”anā tāpat kā, piemēram, UX dizaineri, paÅ”i izstrādātāji, dažreiz produktu vadÄ«tāji. SRE darbojas tajā paŔā lÄ«menÄ«. Mums tie ir jāapstiprina, mums tie ir jāpārskata, lai par katru izvietoÅ”anu SRE teiktu: ā€œLabi, Ŕī izvietoÅ”ana, Å”is produkts negatÄ«vi neietekmēs uzticamÄ«bu. Un, ja tā notiek, tad dažās pieņemamās robežās. Par to arÄ« runāsim.

AttiecÄ«gi SRE ir veto tiesÄ«bas uz koda izmaiņām. Un vispār tas arÄ« noved pie kaut kāda neliela konflikta, ja SRE tiek ieviests nepareizi. Tajā paŔā grāmatā par vietnes uzticamÄ«bas inženieriju daudzas daļas, pat vairāk nekā viena, stāsta, kā izvairÄ«ties no Å”iem konfliktiem.

Viņi jautā, kā SRE ir saistÄ«ts ar informācijas droŔību. SRE nav tieÅ”i iesaistÄ«ts informācijas droŔībā. BÅ«tÄ«bā lielos uzņēmumos to dara privātpersonas, testētāji, analÄ«tiÄ·i. Taču SRE arÄ« mijiedarbojas ar tiem tādā nozÄ«mē, ka dažas darbÄ«bas, dažas saistÄ«bas, dažas izvietoÅ”anas, kas ietekmē droŔību, var ietekmēt arÄ« produkta pieejamÄ«bu. Tāpēc SRE kopumā mijiedarbojas ar jebkurām komandām, tostarp droŔības komandām, tostarp analÄ«tiÄ·iem. Tāpēc SRE galvenokārt ir nepiecieÅ”ami, kad tie mēģina ieviest DevOps, taču tajā paŔā laikā izstrādātāju slogs kļūst pārāk liels. Tas ir, pati izstrādes komanda vairs nevar tikt galā ar to, ka tagad viņiem ir jāatbild arÄ« par Ops. Un ir atseviŔķa loma. Å Ä« loma ir paredzēta budžetā. Dažreiz Ŕī loma tiek noteikta komandas lielumā, parādās atseviŔķs cilvēks, dažreiz par to kļūst kāds no izstrādātājiem. Tā komandā parādās pirmais SRE.

Sistēmas sarežģītÄ«ba, ko ietekmē SRE, sarežģītÄ«ba, kas ietekmē darbÄ«bas uzticamÄ«bu, var bÅ«t nepiecieÅ”ama vai nejauÅ”a. NepiecieÅ”amā sarežģītÄ«ba ir tad, ja produkta sarežģītÄ«ba palielinās tiktāl, cik nepiecieÅ”ams jaunām produkta Ä«paŔībām. GadÄ«juma sarežģītÄ«ba ir tad, kad sistēmas sarežģītÄ«ba palielinās, bet produkta iezÄ«me un biznesa prasÄ«bas to tieÅ”i neietekmē. Izrādās, ka vai nu izstrādātājs kaut kur kļūdÄ«jies, vai arÄ« algoritms nav optimāls, vai arÄ« tiek ieviestas kādas papildus intereses, kas lieki palielina produkta sarežģītÄ«bu. Labam SRE vienmēr vajadzētu izvairÄ«ties no Ŕīs situācijas. Tas nozÄ«mē, ka ir jābloķē ikviena apņemÅ”anās, jebkura izvietoÅ”ana, jebkurÅ” izvilkÅ”anas pieprasÄ«jums, kas palielina sarežģītÄ«bu nejauÅ”u papildinājumu dēļ.

Jautājums ir, kāpēc komandā vienkārÅ”i nenoalgot inženieri, sistēmas administratoru ar daudzām zināŔanām. Mums saka, ka izstrādātājs inženiera lomā nav labākais personāla komplektÄ“Å”anas risinājums. Izstrādātājs inženiera lomā ne vienmēr ir labākais personāla komplektÄ“Å”anas risinājums, taču Å”eit ir runa par to, ka izstrādātājam, kurÅ” nodarbojas ar Ops, ir nedaudz vairāk vēlmes pēc automatizācijas, viņam ir nedaudz vairāk zināŔanu un prasmju kopuma, lai to ieviestu. Ŕī automatizācija. Un attiecÄ«gi mēs samazinām ne tikai laiku dažām specifiskām operācijām, ne tikai rutÄ«nu, bet arÄ« tādus svarÄ«gus biznesa parametrus kā MTTR (Mean Time To Recovery, recovery time). Tādējādi, un mēs arÄ« par to runāsim nedaudz vēlāk, mēs ietaupām naudu organizācijai.

Tagad parunāsim par SRE darba kritērijiem. Un vispirms par uzticamÄ«bu. Mazajos uzņēmumos un startup bieži gadās, ka cilvēki pieņem, ka, ja pakalpojums ir uzrakstÄ«ts labi, ja produkts ir uzrakstÄ«ts labi un pareizi, tas darbosies, tas neplÄ«sÄ«s. Tas arÄ« viss, mēs rakstām labu kodu, tāpēc nav ko lauzt. Kods ir ļoti vienkārÅ”s, nav ko lauzt. Tie ir apmēram tie paÅ”i cilvēki, kuri saka, ka mums nav vajadzÄ«gi testi, jo, lÅ«k, Ŕīs ir trÄ«s VPI metodes, kāpēc gan uztraukties?

Tas viss, protams, ir nepareizi. Un Å”ie cilvēki ļoti bieži tiek sāpināti ar Ŕāda veida kodeksu praksē, jo lietas sabojājas. Lietas dažreiz salÅ«zt visneparedzamākajos veidos. Dažreiz cilvēki saka nē, tas nekad nenotiks. Un tas joprojām notiek. Notiek diezgan bieži. Un tāpēc neviens nekad netiecas uz 100% pieejamÄ«bu, jo 100% pieejamÄ«ba nekad nenotiek. Tā ir norma. Un tāpēc mēs vienmēr runājam par deviņiem, kad runājam par pakalpojumu pieejamÄ«bu. 2 deviņi, 3 deviņi, 4 deviņi, 5 deviņi. Ja mēs to pārvērÅ”am dÄ«kstāves laikā, tad, piemēram, 5 deviņi ir nedaudz vairāk par 5 minÅ«tēm dÄ«kstāves gadā, 2 deviņi ir 3,5 dÄ«kstāves dienas.

Bet ir acÄ«mredzams, ka kādā brÄ«dÄ« POI un ieguldÄ«jumu atdeve samazinās. Pārejot no diviem deviņiem uz trim deviņiem, tiek samazināts dÄ«kstāves laiks par vairāk nekā 3 dienām. Pārejot no četriem deviņiem uz piecām, dÄ«kstāves laiks tiek samazināts par 47 minÅ«tēm gadā. Un izrādās, ka biznesam tas var nebÅ«t kritiski. Un vispār nepiecieÅ”amā uzticamÄ«ba nav tehniska problēma, pirmkārt, tā ir biznesa problēma, tā ir produkta problēma. Kāds dÄ«kstāves lÄ«menis ir pieņemams produkta lietotājiem, ko viņi sagaida, cik viņi maksā, piemēram, cik daudz naudas viņi zaudē, cik daudz naudas zaudē sistēma.

Å eit svarÄ«gs jautājums ir, kāda ir atlikuÅ”o komponentu uzticamÄ«ba. Jo starpÄ«ba starp 4 un 5 devÄ«tniekiem nebÅ«s redzama viedtālrunÄ« ar 2 devÄ«tnieku uzticamÄ«bu. Aptuveni runājot, ja jÅ«su servisā 10 reizes gadā kaut kas saplÄ«st viedtālrunÄ«, visticamāk, 8 reizes bojājums noticis OS pusē. Lietotājs pie tā ir pieradis un nepievērsÄ«s uzmanÄ«bu vēl vienu reizi gadā. Ir nepiecieÅ”ams korelēt uzticamÄ«bas palielināŔanas un peļņas palielināŔanas cenu.
Tikai grāmatā par SRE ir labs piemērs, kā palielināt lÄ«dz 4 deviņiem no 3 deviņiem. Izrādās, ka pieejamÄ«bas pieaugums ir nedaudz mazāks par 0,1%. Un, ja pakalpojuma ieņēmumi ir USD 1 miljons gadā, ieņēmumu pieaugums ir USD 900. Ja pieejamÄ«bas palielināŔana par deviņām mums izmaksā mazāk nekā 900 USD gadā, palielinājums ir finansiāli saprātÄ«gs. Ja tas maksā vairāk par 900 USD gadā, tam vairs nav jēgas, jo ieņēmumu pieaugums vienkārÅ”i nekompensē darbaspēka izmaksas un resursu izmaksas. Un mums pietiks ar 3 deviņiem.

Å is, protams, ir vienkārÅ”ots piemērs, kur visi pieprasÄ«jumi ir vienādi. Un pāriet no 3 deviņiem uz 4 deviņiem ir pietiekami vienkārÅ”i, bet tajā paŔā laikā, piemēram, pārejot no 2 deviņiem uz 3, tas jau ir 9 tÅ«kstoÅ”u dolāru ietaupÄ«jums, tam var bÅ«t finansiāla jēga. Protams, patiesÄ«bā reÄ£istrācijas pieprasÄ«juma neveiksme ir sliktāka nekā lapas nerādÄ«Å”ana, pieprasÄ«jumiem ir atŔķirÄ«gs svars. Viņiem var bÅ«t pilnÄ«gi atŔķirÄ«gs kritērijs no biznesa viedokļa, taču, kā likums, ja mēs nerunājam par dažiem konkrētiem pakalpojumiem, tas ir diezgan uzticams tuvinājums.
Saņēmām jautājumu, vai VNÄŖ ir viens no koordinatoriem, izvēloties dienesta arhitektonisko risinājumu. Tas ir pieņemami no integrācijas esoÅ”ajā infrastruktÅ«rā, lai nezaudētu tās stabilitāti. Jā, SRE, tāpat kā pull pieprasÄ«jumi, apņemÅ”anās, izlaidumi ietekmē arhitektÅ«ru, jaunu servisu ievieÅ”anu, mikropakalpojumus, jaunu risinājumu ievieÅ”anu. Kāpēc es iepriekÅ” teicu, ka ir vajadzÄ«ga pieredze, vajadzÄ«ga kvalifikācija. Faktiski SRE ir viena no bloķējoÅ”ajām balsÄ«m jebkurā arhitektÅ«ras un programmatÅ«ras risinājumā. AttiecÄ«gi SRE kā inženierim, pirmkārt, ir ne tikai jāsaprot, bet arÄ« jāsaprot, kā daži konkrēti lēmumi ietekmēs uzticamÄ«bu, stabilitāti, un jāsaprot, kā tas ir saistÄ«ts ar biznesa vajadzÄ«bām un no kāda viedokļa tas var bÅ«t pieļaujams, un ar ko tā nav.

Tāpēc tagad ir pienācis laiks runāt par uzticamÄ«bas kritērijiem, kas SRE tradicionāli tiek definēti kā SLA (Service Level Agreement). Visticamāk pazÄ«stams termins. SLI (servisa lÄ«meņa indikators). SLO (Service Level Objective). Pakalpojuma lÄ«meņa lÄ«gums, iespējams, ir nozÄ«mÄ«gs termins, it Ä«paÅ”i, ja esat strādājis ar tÄ«kliem, pakalpojumu sniedzējiem un mitināŔanu. Å Ä« ir vispārÄ«ga vienoÅ”anās, kas apraksta visa jÅ«su pakalpojuma darbÄ«bu, sodus, dažus sodus par kļūdām, metriku, kritērijus. Un SLI ir pats pieejamÄ«bas rādÄ«tājs. Tas ir, kas var bÅ«t SLI: servisa reakcijas laiks, kļūdu skaits procentos. Tas varētu bÅ«t joslas platums, ja mēs runājam par kāda veida failu mitināŔanu. Ja runājam par atpazÄ«Å”anas algoritmiem, rādÄ«tājs var bÅ«t pat, piemēram, atbildes pareizÄ«ba. SLO (Service Level Objective) ir attiecÄ«gi SLI indikatora, tā vērtÄ«bas un perioda kombinācija.

Pieņemsim, ka SLA varētu bÅ«t Ŕāds. Pakalpojums ir pieejams 99,95% laika visa gada garumā. Vai arÄ« 99 kritiskā tehniskā atbalsta biļetes tiks slēgtas 3 stundu laikā ceturksnÄ«. Vai arÄ« uz 85% vaicājumu katru mēnesi tiks atbildēts 1,5 sekunžu laikā. Tas ir, mēs pakāpeniski sākam saprast, ka kļūdas un neveiksmes ir diezgan normāla parādÄ«ba. Tā ir pieņemama situācija, mēs to plānojam, zināmā mērā pat ar to rēķināmies. Tas ir, SRE veido sistēmas, kas var kļūdÄ«ties, kurām normāli jāreaģē uz kļūdām un kurām tās ir jāņem vērā. Un, ja iespējams, viņiem vajadzētu rÄ«koties ar kļūdām tā, lai lietotājs tās vai nu nepamanÄ«tu, vai arÄ« tās pamanÄ«tu, bet ir kaut kāds risinājums, lai viss nesabruktu pilnÄ«bā.

Piemēram, ja augÅ”upielādējat videoklipu pakalpojumā YouTube un YouTube nevar to uzreiz konvertēt, ja videoklips ir pārāk liels, ja formāts nav optimāls, pieprasÄ«jums, protams, neizdosies ar taimautu, YouTube nerādÄ«s 502. kļūda, YouTube teiks: ā€œMēs visu izveidojām, jÅ«su video tiek apstrādāts. Tas bÅ«s gatavs apmēram 10 minÅ«tēs." Å is ir graciozās degradācijas princips, kas ir pazÄ«stams, piemēram, no priekÅ”gala izstrādes, ja kādreiz esat to darÄ«jis.

Nākamie termini, par kuriem mēs runāsim un kuri ir ļoti svarÄ«gi, lai strādātu ar uzticamÄ«bu, ar kļūdām, ar cerÄ«bām, ir MTBF un MTTR. MTBF ir vidējais laiks starp neveiksmēm. MTTR vidējais atveseļoÅ”anās laiks, vidējais laiks lÄ«dz atveseļoÅ”anai. Tas ir, cik daudz laika ir pagājis no brīža, kad kļūda tika atklāta, no brīža, kad kļūda parādÄ«jās, lÄ«dz brÄ«dim, kad pakalpojums tika pilnÄ«bā atjaunots normālā režīmā. MTBF galvenokārt nosaka darbs pie koda kvalitātes. Tas ir, fakts, ka SRE var pateikt "nē". Un vajag visas komandas izpratni, ka tad, kad SRE saka "nē", viņŔ to saka nevis tāpēc, ka ir kaitÄ«gs, nevis tāpēc, ka ir slikts, bet tāpēc, ka citādi cietÄ«s visi.

Atkal ir daudz rakstu, daudz metožu, daudz veidu, pat tajā paŔā grāmatā, uz kuru es tik bieži atsaucos, kā pārliecināties, ka citi izstrādātāji nesāk ienÄ«st SRE. No otras puses, MTTR ir darbs pie jÅ«su SLO (pakalpojuma lÄ«meņa mērÄ·a). Un tā galvenokārt ir automatizācija. Tā kā, piemēram, mÅ«su SLO darbÄ«bas laiks ir 4 deviņi ceturksnÄ«. Tas nozÄ«mē, ka 3 mēneÅ”u laikā varam pieļaut 13 minÅ«Å”u dÄ«kstāvi. Un izrādās, ka mÅ«su MTTR nevar bÅ«t ilgāks par 13 minÅ«tēm. Ja mēs ņemam 13 minÅ«tes, lai reaģētu uz vismaz 1 dÄ«kstāvi, tas nozÄ«mē, ka mēs jau esam iztērējuÅ”i visu ceturkŔņa budžetu. Mēs laužam SLO. 13 minÅ«tes, lai reaģētu un novērstu avāriju, ir daudz maŔīnai, bet ļoti Ä«ss cilvēkam. Jo lÄ«dz brÄ«dim, kad cilvēks saņem brÄ«dinājumu, kamēr viņŔ nereaģē, kamēr viņŔ nesaprot kļūdu, tas jau ir vairākas minÅ«tes. Kamēr cilvēks nesapratÄ«s, kā to salabot, ko tieÅ”i labot, ko darÄ«t, tad Ŕīs ir vēl dažas minÅ«tes. Un patiesÄ«bā, pat ja jums vienkārÅ”i ir jārestartē serveris, kā izrādās, vai jāpaaugstina jauns mezgls, tad manuāli MTTR jau ir apmēram 7-8 minÅ«tes. Automatizējot procesu, MTTR ļoti bieži sasniedz sekundi, dažreiz milisekundes. Google parasti runā par milisekundēm, bet patiesÄ«bā, protams, viss nav tik labi.

Ideālā gadÄ«jumā SRE vajadzētu gandrÄ«z pilnÄ«bā automatizēt savu darbu, jo tas tieÅ”i ietekmē MTTR, tā rādÄ«tājus, visa pakalpojuma SLO un attiecÄ«gi arÄ« biznesa peļņu. Ja laiks tiek pārsniegts, mums tiek jautāts, vai SRE ir vainÄ«gs. Par laimi, neviens nav vainÄ«gs. Un Ŕī ir atseviŔķa kultÅ«ra, ko sauc par balmeless postmortem, par kuru mēs Å”odien nerunāsim, bet mēs to analizēsim vietnē Slurm. Å Ä« ir ļoti interesanta tēma, par kuru var runāt daudz. Rupji runājot, ja tiek pārsniegts atvēlētais laiks ceturksnÄ«, tad vainÄ«gi ir pa druskai visi, kas nozÄ«mē, ka vainot visus nav produktÄ«vi, tā vietā, varbÅ«t nevainosim nevienu, bet labosim situāciju un strādāsim ar to, kas ir. Pēc manas pieredzes Ŕī pieeja lielākajai daļai komandu ir nedaudz sveÅ”a, it Ä«paÅ”i Krievijā, taču tai ir jēga un tā darbojas ļoti labi. Tāpēc es ieteikÅ”u raksta un literatÅ«ras beigās, ko varat izlasÄ«t par Å”o tēmu. Vai arÄ« nāc uz Slurm SRE.

Ä»auj man paskaidrot. Ja ceturkŔņa SLO laiks ir pārsniegts, ja dÄ«kstāve bija nevis 13 minÅ«tes, bet 15, kas pie tā var bÅ«t vainÄ«gs? Protams, SRE var bÅ«t vainÄ«gs, jo tas nepārprotami izdarÄ«ja sliktu apņemÅ”anos vai izvietoÅ”anu. Pie tā var bÅ«t vainÄ«gs datu centra administrators, jo viņŔ, iespējams, veicis kādu neplānotu apkopi. Ja pie tā vainojams datu centra administrators, tad arÄ« Ops cilvēks, vienojoties par SLO, nav aprēķinājis uzturlÄ«dzekļus. Pie tā ir vainÄ«gs vadÄ«tājs, tehniskais direktors vai kāds, kurÅ” parakstÄ«ja datu centra lÄ«gumu un nav pievērsis uzmanÄ«bu tam, ka datu centra SLA nav paredzēts nepiecieÅ”amajai dÄ«kstāvei. AttiecÄ«gi visi pamazām Å”ajā situācijā ir vainÄ«gi. Un tas nozÄ«mē, ka Å”ajā situācijā nav jēgas nevienu vainot. Bet, protams, tas ir jālabo. Tāpēc ir pēcnāves gadÄ«jumi. Un, ja jÅ«s lasāt, piemēram, GitHub postmortems, un tas vienmēr ir ļoti interesants, mazs un negaidÄ«ts stāsts katrā konkrētajā gadÄ«jumā, jÅ«s varat aizstāt to, ka neviens nekad nesaka, ka vainÄ«gs ir Å”is konkrētais cilvēks. Vaina vienmēr tiek novelta uz konkrētiem nepilnÄ«giem procesiem.

Pāriesim pie nākamā jautājuma. Automatizācija. Kad es runāju par automatizāciju citos kontekstos, es bieži atsaucos uz tabulu, kurā ir norādÄ«ts, cik ilgi varat strādāt pie uzdevuma automatizÄ“Å”anas, neprasot tā automatizÄ“Å”anai vairāk laika, nekā faktiski saglabājat. Ir aizÄ·erÅ”anās. Āķis ir tāds, ka SRE automatizējot uzdevumu, tie ne tikai ietaupa laiku, bet arÄ« ietaupa naudu, jo automatizācija tieÅ”i ietekmē MTTR. Tie ietaupa, tā teikt, darbinieku un izstrādātāju morāli, kas arÄ« ir izsmeļams resurss. Tie samazina rutÄ«nu. Un tas viss pozitÄ«vi ietekmē darbu un lÄ«dz ar to arÄ« biznesu, pat ja Ŕķiet, ka laika izmaksu ziņā automatizācijai nav jēgas.

Faktiski tā notiek gandrÄ«z vienmēr, un ir ļoti maz gadÄ«jumu, kad nav vērts kaut ko automatizēt SRE lomā. Tālāk mēs runāsim par to, ko sauc par kļūdu budžetu, par kļūdu budžetu. Faktiski izrādās, ka, ja jums veicas ievērojami labāk par sev iestatÄ«to SLO, arÄ« tas nav Ä«paÅ”i labi. Tas ir diezgan slikti, jo SLO darbojas ne tikai kā apakŔējā robeža, bet arÄ« kā aptuvenā augŔējā robeža. Kad jÅ«s uzstādāt sev 99% pieejamÄ«bas SLO un patiesÄ«bā jums ir 99,99%, izrādās, ka jums ir vieta eksperimentiem, kas biznesam nemaz nekaitēs, jo jÅ«s pats to visu esat noteicis, un jÅ«s esat Å”o vietu neizmanto. Jums ir budžets kļūdām, kas jÅ«su gadÄ«jumā netiek izlietots.

Ko mēs ar to darām? Mēs to izmantojam burtiski visam. TestÄ“Å”anai ražoÅ”anas apstākļos, jaunu funkciju ievieÅ”anai, kas var ietekmēt veiktspēju, laidieniem, apkopei, plānotām dÄ«kstāvēm. Spēkā arÄ« apgrieztais noteikums: ja budžets ir izsmelts, neko jaunu laist nevaram, jo ā€‹ā€‹pretējā gadÄ«jumā pārsniegsim SLO. Budžets jau ir izsmelts, mēs esam kaut ko atbrÄ«vojuÅ”i, ja tas negatÄ«vi ietekmē veiktspēju, tas ir, ja tas nav kaut kāds labojums, kas pats par sevi tieÅ”i palielina SLO, tad mēs pārsniedzam budžetu, un tā ir slikta situācija. , ir nepiecieÅ”ama analÄ«ze, pēcnāves un, iespējams, daži procesa labojumi.

Tas ir, izrādās, ka, ja pats pakalpojums nedarbojas labi, un SLO tiek iztērēts un budžets tiek tērēts nevis eksperimentiem, nevis kaut kādiem izlaidumiem, bet gan paÅ”am, tad interesantu labojumu vietā funkcijas, nevis interesantus izdevumus. Tā vietā, lai nodarbotos ar radoÅ”iem darbiem, jums bÅ«s jāveic stulbi labojumi, lai budžets atkal bÅ«tu kārtÄ«bā, vai jārediģē SLO, un arÄ« tas ir process, kam nevajadzētu notikt pārāk bieži.

Tāpēc izrādās, ka situācijā, kad mums ir lielāks budžets kļūdām, interesējas visi: gan SRE, gan izstrādātāji. Izstrādātājiem liels budžets kļūdu novērÅ”anai nozÄ«mē, ka jÅ«s varat nodarboties ar izlaidumiem, testiem, eksperimentiem. AttiecÄ«bā uz SRE budžets kļūdām un Ŕī budžeta ievadÄ«Å”ana nozÄ«mē, ka viņi tieÅ”i labi veic savu darbu. Un tas ietekmē sava veida kopÄ«ga darba motivāciju. Ja klausÄ«sities savus SRE kā izstrādātājus, jums bÅ«s vairāk vietas labam darbam un daudz mazāk rutÄ«nas.

Izrādās, ka eksperimenti ražoÅ”anā ir diezgan svarÄ«ga un gandrÄ«z neatņemama SRE sastāvdaļa lielās komandās. Un to parasti sauc par haosa inženieriju, kas nāk no Netflix komandas, kas izlaida utilÄ«tu ar nosaukumu Chaos Monkey.
Chaos Monkey izveido savienojumu ar CI/CD cauruļvadu un nejauÅ”i avarē serveri ražoÅ”anas procesā. Atkal SRE struktÅ«rā mēs runājam par to, ka nolaists serveris pats par sevi nav slikts, tas ir sagaidāms. Un, ja tas ir budžeta ietvaros, tas ir pieņemami un nekaitē biznesam. Protams, Netflix ir pietiekami daudz lieku serveru, pietiekami daudz replikācijas, lai to visu varētu salabot, un lai lietotājs kopumā to pat nepamana, un vēl jo vairāk neviens neatstāj vienu serveri par kādu budžetu.

Netflix savulaik bija vesels Ŕādu utilÄ«tu komplekts, no kuriem viens, Chaos Gorilla, pilnÄ«bā atspējo vienu no Amazon pieejamÄ«bas zonām. Un Ŕādas lietas labi palÄ«dz identificēt, pirmkārt, slēptās atkarÄ«bas, kad nav lÄ«dz galam skaidrs, kas ko ietekmē, kas no kā ir atkarÄ«gs. Un tas, ja strādājat ar mikropakalpojumu un dokumentācija nav pilnÄ«gi perfekta, tas jums var bÅ«t pazÄ«stams. Un atkal, tas palÄ«dz noÄ·ert kļūdas kodā, ko nevarat uztvert inscenÄ“Å”anas laikā, jo jebkura inscenÄ“Å”ana nav precÄ«za simulācija, jo atŔķiras slodzes skala, slodzes modelis ir atŔķirÄ«gs, aprÄ«kojums ir arÄ«, lielākā daļa iespējams, cits. Maksimālās slodzes var bÅ«t arÄ« negaidÄ«tas un neparedzamas. Un Ŕāda testÄ“Å”ana, kas atkal nepārsniedz budžetu, ļoti labi palÄ«dz infrastruktÅ«rā noÄ·ert kļūdas, kuras inscenējums, autotesti un CI/CD konveijeri nekad neuzÄ·ers. Un, kamēr tas viss ir iekļauts jÅ«su budžetā, nav nozÄ«mes tam, ka jÅ«su pakalpojums ir krities, lai gan tas varētu Ŕķist ļoti biedējoÅ”i, serveris ir avarējis, kāds murgs. Nē, tas ir normāli, tas ir labi, tas palÄ«dz noÄ·ert kļūdas. Ja jums ir budžets, varat to iztērēt.

J: Kādu literatÅ«ru es varu ieteikt? Saraksts ir beigās. LiteratÅ«ras ir daudz, es ieteikÅ”u dažus ziņojumus. Kā tas darbojas, un vai SRE darbojas uzņēmumos bez sava programmatÅ«ras produkta vai ar minimālu attÄ«stÄ«bu. Piemēram, uzņēmumā, kurā galvenā darbÄ«ba nav programmatÅ«ra. Uzņēmumā, kur galvenā darbÄ«ba nav programmatÅ«ra, SRE darbojas tieÅ”i tāpat kā visur citur, jo uzņēmumā arÄ« ir jāizmanto, pat ja nav izstrādāti, programmatÅ«ras produkti, jāizlaiž atjauninājumi, jāmaina infrastruktÅ«ra, jums ir jāaug, jums ir jāmēro. Un SRE palÄ«dz identificēt un paredzēt iespējamās problēmas Å”ajos procesos un kontrolēt tās pēc izaugsmes sākuma un biznesa vajadzÄ«bu izmaiņām. Jo absolÅ«ti nav nepiecieÅ”ams iesaistÄ«ties programmatÅ«ras izstrādē, lai bÅ«tu SRE, ja jums ir vismaz daži serveri un jums tiek gaidÄ«ta vismaz izaugsme.

Tas pats attiecas uz maziem projektiem, mazām organizācijām, jo ā€‹ā€‹lieliem uzņēmumiem ir budžets un vieta eksperimentiem. Bet tajā paŔā laikā visus Å”os eksperimentu augļus var izmantot jebkur, tas ir, SRE, protams, parādÄ«jās Google, Netflix un Dropbox. Bet tajā paŔā laikā mazie uzņēmumi un jaunuzņēmumi jau var lasÄ«t saÄ«sinātus materiālus, lasÄ«t grāmatas un skatÄ«ties atskaites. Viņi sāk par to dzirdēt biežāk, skatās konkrētus piemērus, manuprāt, tas ir labi, tas tieŔām var noderēt, mums arÄ« vajag Å”o, tas ir lieliski.

Tas ir, viss galvenais darbs pie Å”o procesu standartizācijas jau ir paveikts jÅ«su vietā. Viss, kas jums jādara, ir konkrēti definēt SRE lomu jÅ«su uzņēmumā un sākt reāli Ä«stenot visas Ŕīs prakses, kuras, atkal, jau ir aprakstÄ«tas. Tas ir, no maziem uzņēmumiem noderÄ«giem principiem, Ŕī vienmēr ir SLA, SLI, SLO definÄ«cija. Ja neesat saistÄ«ts ar programmatÅ«ru, tad tie bÅ«s iekŔējie SLA un iekŔējie SLO, iekŔējais budžets kļūdām. Tas gandrÄ«z vienmēr noved pie kādām interesantām diskusijām komandā un uzņēmuma iekÅ”ienē, jo var izrādÄ«ties, ka infrastruktÅ«rai, kaut kādai ideālu procesu organizācijai, ideālam cauruļvadam tērējat daudz vairāk nekā nepiecieÅ”ams. Un Å”ie 4 deviņi, kas jums ir IT nodaļā, jums tagad nav Ä«sti vajadzÄ«gi. Bet tajā paŔā laikā bija iespēja tērēt laiku, tērēt budžetu kļūdām kaut kam citam.

AttiecÄ«gi uzraudzÄ«ba un monitoringa organizÄ“Å”ana ir noderÄ«ga jebkura lieluma uzņēmumam. Un vispār Ŕāds domāŔanas veids, kur kļūdas ir kaut kas pieņemams, kur ir budžets, kur MērÄ·i pastāv, atkal noder jebkura izmēra uzņēmumam, sākot no 3 cilvēku startapa.

Pēdējā no tehniskajām niansēm, par kurām jārunā, ir monitorings. Jo, ja mēs runājam par SLA, SLI, SLO, mēs nevaram saprast, nekontrolējot, vai mēs iekļaujamies budžetā, vai mēs ievērojam savus mērÄ·us un kā mēs ietekmējam galÄ«go SLA. Daudzas reizes esmu novērojis, ka uzraudzÄ«ba notiek Ŕādi: ir kāda vērtÄ«ba, piemēram, pieprasÄ«juma laiks serverim, vidējais laiks vai pieprasÄ«jumu skaits datu bāzei. Viņam ir standarts, ko nosaka inženieris. Ja metrika atŔķiras no normas, tad pienāk e-pasts. Tas viss, kā likums, ir absolÅ«ti bezjēdzÄ«gi, jo tas rada tādu brÄ«dinājumu pārpilnÄ«bu, ziņojumu pārpilnÄ«bu no uzraudzÄ«bas, kad personai, pirmkārt, tie katru reizi ir jāinterpretē, tas ir, jānosaka, vai metrikas vērtÄ«ba nozÄ«mē. nepiecieÅ”amÄ«ba veikt kādu darbÄ«bu. Un, otrkārt, viņŔ vienkārÅ”i pārstāj pamanÄ«t visus Å”os brÄ«dinājumus, kad bÅ«tÄ«bā no viņa nav jāveic nekādas darbÄ«bas. Tas ir labs uzraudzÄ«bas noteikums, un pats pirmais noteikums, kad tiek ieviests SRE, ir tāds, ka paziņojums jāiesniedz tikai tad, kad ir nepiecieÅ”ama darbÄ«ba.

Standarta gadījumā ir 3 notikumu līmeņi. Ir brīdinājumi, ir biļetes, ir žurnāli. Brīdinājumi ir jebkas, kas prasa tūlītēju darbību. Tas ir, viss ir salūzis, jums tas ir jāsalabo tūlīt. Biļetes ir tas, kas prasa novēlotu darbību. Jā, jums kaut kas jādara, jums kaut kas jādara manuāli, automatizācija neizdevās, bet jums tas nav jādara tuvākajās minūtēs. Žurnāli ir jebkas, kas neprasa nekādas darbības, un vispār, ja viss iet labi, neviens tos nekad nelasīs. Žurnālus vajadzēs palasīt tikai tad, kad retrospektīvi atklājās, ka kādu laiku kaut kas salūza, mēs par to nezinājām. Vai arī jums ir jāveic daži pētījumi. Bet kopumā viss, kas neprasa nekādas darbības, nonāk baļķos.

Kā blakusefekts tam visam, ja esam identificējuÅ”i, kuri notikumi prasa darbÄ«bas, un esam labi aprakstÄ«juÅ”i, kādām Ŕīm darbÄ«bām jābÅ«t, tas nozÄ«mē, ka darbÄ«bu var automatizēt. Tas ir, kas notiek. Mēs izejam no modrÄ«bas. Pāriesim pie darbÄ«bas. Mēs ejam uz Ŕīs darbÄ«bas aprakstu. Un tad mēs pārejam pie automatizācijas. Tas ir, jebkura automatizācija sākas ar reakciju uz notikumu.

No monitoringa mēs pārejam pie termina, ko sauc par novērojamÄ«bu. Ap Å”o vārdu pēdējos gados ir bijusi arÄ« neliela ažiotāža. Un tikai daži cilvēki saprot, ko tas nozÄ«mē ārpus konteksta. Bet galvenais ir tas, ka novērojamÄ«ba ir sistēmas caurskatāmÄ«bas rādÄ«tājs. Ja kaut kas nogāja greizi, cik ātri var noteikt, kas tieÅ”i nogāja greizi un kāds bija sistēmas stāvoklis tajā brÄ«dÄ«. No koda viedokļa: kura funkcija neizdevās, kurÅ” pakalpojums neizdevās. Kāds bija, piemēram, iekŔējo mainÄ«go, konfigurācijas stāvoklis. No infrastruktÅ«ras viedokļa tas ir, kurā pieejamÄ«bas zonā radās kļūme, un, ja jums ir kāda veida Kubernetes, tad kurā podā radās kļūme, kāds bija pod stāvokļa. Un attiecÄ«gi novērojamÄ«bai ir tieÅ”a saistÄ«ba ar MTTR. Jo augstāka pakalpojuma NovērojamÄ«ba, jo vieglāk ir identificēt kļūdu, vieglāk novērst kļūdu, vieglāk automatizēt kļūdu, jo zemāks MTTR.

Ja atkal pārejam pie mazajiem uzņēmumiem, viņi ļoti bieži arÄ« tagad jautā, ko darÄ«t ar kolektÄ«va lielumu un vai mazā kolektÄ«vā ir nepiecieÅ”ams algot atseviŔķu VNÄŖ. Par to jau tika runāts nedaudz agrāk. Startup vai, piemēram, komandas attÄ«stÄ«bas pirmajos posmos tas nemaz nav nepiecieÅ”ams, jo SRE var padarÄ«t par pārejas lomu. Un tas nedaudz atdzÄ«vinās komandu, jo ir vismaz kaut kāda dažādÄ«ba. Un plus tas sagatavos cilvēkus tam, ka lÄ«dz ar izaugsmi kopumā SRE pienākumi ļoti bÅ«tiski mainÄ«sies. Ja pieņem darbā cilvēku, tad viņam, protams, ir zināmas cerÄ«bas. Un Ŕīs cerÄ«bas laika gaitā nemainÄ«sies, bet prasÄ«bas mainÄ«sies ļoti daudz. Tāpēc sākotnējā posmā ir diezgan grÅ«ti pieņemt darbā SRE. Audzēt paÅ”am ir daudz vieglāk. Bet par to ir vērts padomāt.

VienÄ«gais izņēmums, iespējams, ir gadÄ«jumi, kad ir ļoti stingras un skaidri noteiktas izaugsmes prasÄ«bas. Tas ir, starta gadÄ«jumā tas var bÅ«t kāds investoru spiediens, kaut kāda izaugsmes prognoze vairākas reizes vienlaikus. Tad SRE pieņemÅ”ana darbā bÅ«tÄ«bā ir attaisnojama, jo to var attaisnot. Mums ir prasÄ«bas izaugsmei, vajag cilvēku, kurÅ” atbildēs par to, ka ar tādu izaugsmi nekas nesalÅ«zÄ«s.

Vēl viens jautājums. Ko darÄ«t, ja vairākas reizes izstrādātāji izgriež funkciju, kas iztur testus, bet pārtrauc ražoÅ”anu, ielādē bāzi, pārtrauc citas funkcijas, kādu procesu ieviest. AttiecÄ«gi Å”ajā gadÄ«jumā tiek ieviests budžets kļūdām. Un daži pakalpojumi, dažas funkcijas jau tiek pārbaudÄ«tas ražoÅ”anā. Tas var bÅ«t kanārijputniņŔ, kad tikai neliels lietotāju skaits, bet jau ražoÅ”anā tiek izvietota funkcija, bet jau ar cerÄ«bu, ka, ja kaut kas saplÄ«st, piemēram, pusprocentam no visiem lietotājiem, tas joprojām atbilst budžets kļūdām. AttiecÄ«gi, jā, bÅ«s kļūda, dažiem lietotājiem viss salÅ«zÄ«s, bet mēs jau teicām, ka tas ir normāli.

Bija jautājums par SRE rÄ«kiem. Tas ir, vai ir kaut kas Ä«paÅ”s, ko SRE izmantotu, ko visi citi neizmantotu? PatiesÄ«bā ir dažas ļoti specializētas utilÄ«tas, ir programmatÅ«ra, kas, piemēram, simulē slodzes vai veic kanārijas A/B testÄ“Å”anu. Bet bÅ«tÄ«bā SRE rÄ«ki ir tas, ko jÅ«su izstrādātāji jau izmanto. Tā kā SRE tieÅ”i mijiedarbojas ar izstrādes komandu. Un, ja jums ir dažādi rÄ«ki, izrādās, ka sinhronizācija prasa laiku. ÄŖpaÅ”i, ja SRE strādā lielās komandās, lielos uzņēmumos, kur var bÅ«t vairākas komandas, Å”eit ļoti noderēs uzņēmuma mēroga standartizācija, jo, ja 50 komandas izmanto 50 dažādus utilÄ«tus, tas nozÄ«mē, ka SRE tās visas ir jāzina. Un tas, protams, nekad nenotiks. Un darba kvalitāte, kontroles kvalitāte vismaz daļai kolektÄ«vu ievērojami samazināsies.

MÅ«su vebinārs tuvojas noslēgumam. Man izdevās jums pastāstÄ«t dažas pamata lietas. Protams, stundas laikā par SRE neko nevar izstāstÄ«t un saprast. Bet es ceru, ka man izdevās nodot Å”o domāŔanas veidu, galvenos galvenos punktus. Un tad, ja ir interese, var iedziļināties tēmā, studēt paÅ”i, un paskatÄ«ties, kā to Ä«steno citi cilvēki, citos uzņēmumos. Un attiecÄ«gi februāra sākumā nāc pie mums Slurm SRE.

Slurm SRE ir trÄ«s dienu intensÄ«vs kurss, kurā tiks runāts par to, par ko es tagad runāju, bet daudz dziļāk, ar reāliem gadÄ«jumiem, ar praksi visa intensÄ«vā ir vērsta uz praktisko darbu. Cilvēki tiks sadalÄ«ti komandās. JÅ«s visi strādāsit pie reāliem gadÄ«jumiem. AttiecÄ«gi mums ir vietnes Booking.com instruktori Ivans Kruglovs un Bens Tailers. Mums ir brÄ«niŔķīgs Jevgeņijs Barabass no Google no Sanfrancisko. Un es tev arÄ« kaut ko pastāstÄ«Å”u. Tāpēc noteikti apmeklējiet mÅ«s.
Tātad, bibliogrāfija. Ir atsauces uz SRE. Pirmais par to paÅ”u grāmatu, pareizāk sakot, uz 2 grāmatām par SRE, ko sarakstÄ«jis Google. Vēl viens neliels raksts par SLA, SLI, SLO, kur termini un to pielietojums ir izskaidroti nedaudz sÄ«kāk. Nākamie 3 ir ziņojumi par SRE dažādos uzņēmumos. Pirmkārt - SRE atslēgas, Ŕī ir Bena trenera no Google pamatruna. Otrais - SRE pakalpojumā Dropbox. TreÅ”ais ir atkal SRE uzņēmumam Google. Ceturtais ziņojums no SRE pakalpojumā Netflix, kurā ir tikai 5 galvenie SRE darbinieki 190 valstÄ«s. Ir ļoti interesanti uz to visu skatÄ«ties, jo tāpat kā DevOps dažādiem uzņēmumiem un pat dažādām komandām nozÄ«mē ļoti dažādas lietas, SRE ir ļoti dažādi pienākumi pat lÄ«dzÄ«ga lieluma uzņēmumos.

Vēl 2 saites par haosa inženierijas principiem: (1), (2). Un beigās ir 3 saraksti no sērijas Awesome Lists par haosa inženierija, apmēram SRE un apmēram SRE rÄ«ku komplekts. Saraksts par SRE ir neticami milzÄ«gs, nav nepiecieÅ”ams tam visam iziet cauri, tur ir ap 200 rakstu. Es ļoti iesaku rakstus no turienes par kapacitātes plānoÅ”anu un par nevainojamu pēcnāves periodu.

Interesants raksts: SRE kā dzīves izvēle

Paldies, ka visu Å”o laiku mani klausÄ«jāties. Ceru, ka kaut ko uzzinājāt. Es ceru, ka jums ir pietiekami daudz materiālu, lai uzzinātu vēl vairāk. Un tiekamies. Cerams februārÄ«.
Vebināru vadīja Eduards Medvedevs.

PS: tiem, kam patÄ«k lasÄ«t, Eduards iedeva atsauču sarakstu. Tie, kas dod priekÅ”roku saprast praksē, laipni aicināti Slurme SRE.

Avots: www.habr.com

Pievieno komentāru