Webinari ka audio të dobët, kështu që ne bëmë një transkript.
Emri im është Medvedev Eduard. Sot do të flas se çfarë është SRE, si u shfaq SRE, cilat janë kriteret e punës për inxhinierët e SRE, pak për kriteret e besueshmërisë, pak për monitorimin e saj. Ne do të kalojmë në krye, sepse nuk mund të thuash shumë për një orë, por unë do t'ju jap materiale për shqyrtim shtesë dhe ne të gjithë ju presim në . në Moskë në fund të janarit.
Së pari, le të flasim për atë që është SRE - Site Reliability Engineering -. Dhe si u shfaq si një pozicion më vete, si një drejtim më vete. E gjitha filloi me faktin se në qarqet tradicionale të zhvillimit, Dev dhe Ops janë dy ekipe krejtësisht të ndryshme, zakonisht me dy qëllime krejtësisht të ndryshme. Qëllimi i ekipit të zhvillimit është të nxjerrë në pah veçori të reja për të përmbushur nevojat e biznesit. Qëllimi i ekipit të Ops është të sigurohet që gjithçka funksionon dhe asgjë nuk prishet. Natyrisht, këto qëllime kundërshtojnë drejtpërdrejt njëra-tjetrën: në mënyrë që gjithçka të funksionojë dhe asgjë të mos prishet, është më mirë të hapni veçori të reja sa më pak të jetë e mundur. Për shkak të kësaj, lindin shumë konflikte të brendshme, të cilat metodologjia e quajtur tani DevOps po përpiqet t'i zgjidhë.
Problemi është se ne nuk kemi një përkufizim të qartë të DevOps dhe një zbatim të qartë të DevOps. Unë fola në një konferencë në Yekaterinburg 2 vjet më parë, dhe deri më tani seksioni DevOps filloi me raportin "Çfarë është DevOps". Në 2017, devops është pothuajse 10 vjeç, por ne ende po debatojmë se çfarë është. Dhe kjo është një situatë shumë e çuditshme që Google u përpoq ta zgjidhte disa vite më parë.
Në vitin 2016, Google publikoi një libër të quajtur "Inxhinieria e besueshmërisë së sitit". Dhe në fakt, pikërisht me këtë libër filloi lëvizja e SRE. SRE është një opsion specifik për zbatimin e paradigmës DevOps në një kompani specifike. Inxhinierët SRE i vendosën vetes qëllimin për të siguruar funksionim të besueshëm të sistemeve. Ato janë marrë kryesisht nga zhvilluesit, ndonjëherë nga administratorë me një sfond të fortë zhvillimi. Dhe ata bëjnë atë që bënin administratorët e sistemit, por një sfond i fortë në zhvillim dhe njohuri të sistemit nga pikëpamja e kodit çon në faktin se këta njerëz nuk janë të prirur për punë rutinë administrative, por janë të prirur për automatizim.
Rezulton se paradigma e DevOps në ekipet SRE zbatohet nga fakti se ka inxhinierë SRE që zgjidhin problemet strukturore. Këtu është, e njëjta lidhje midis Dev dhe Ops për të cilën njerëzit kanë folur për 8 vjet. Roli i një SRE është i ngjashëm me atë të një arkitekti në atë që fillestarët nuk bëhen SRE. Njerëzit në fillim të karrierës së tyre nuk kanë ende ndonjë përvojë dhe nuk kanë gjerësinë e kërkuar të njohurive. Sepse SRE kërkon një njohuri shumë të sofistikuar se çfarë saktësisht dhe kur mund të shkojë keq. Prandaj, këtu nevojitet një lloj përvoje, si rregull, si brenda kompanisë ashtu edhe jashtë saj.
Ata pyesin nëse ndryshimi midis SRE dhe devops do të përshkruhet. Ajo sapo është përshkruar. Mund të flasim për vendin e SRE në organizatë. Ndryshe nga qasja klasike e DevOps, ku Ops është ende një departament i veçantë, SRE është pjesë e ekipit të zhvillimit. Ata janë të përfshirë në zhvillimin e produktit. Ekziston madje një qasje ku SRE është një rol që kalon nga një zhvillues në tjetrin. Ata marrin pjesë në rishikimet e kodit në të njëjtën mënyrë si, për shembull, projektuesit UX, vetë zhvilluesit dhe ndonjëherë menaxherët e produkteve. SRE-të funksionojnë në të njëjtin nivel. Ne kemi nevojë për miratimin e tyre, kemi nevojë për rishikimin e tyre, në mënyrë që për çdo vendosje SRE të thotë: "Në rregull, ky vendosje, ky produkt nuk do të ndikojë negativisht në besueshmërinë. Dhe nëse ndodh, do të jetë brenda disa kufijve të pranueshëm.” Do të flasim edhe për këtë.
Prandaj, SRE ka të drejtën e vetos për ndryshimet e kodit. Dhe në përgjithësi, kjo gjithashtu çon në një konflikt të vogël nëse SRE zbatohet gabimisht. Në atë libër për Inxhinierinë e Besueshmërisë së Site, shumë pjesë, madje më shumë se një, tregojnë se si të shmangni këto konflikte.
Njerëzit pyesin se si SRE lidhet me sigurinë e informacionit. SRE nuk është e përfshirë drejtpërdrejt në sigurinë e informacionit. Kryesisht në kompanitë e mëdha, kjo bëhet nga njerëz individualë, testues dhe analistët. Por SRE gjithashtu ndërvepron me ta në kuptimin që disa operacione, disa angazhime, disa vendosje që ndikojnë në sigurinë mund të ndikojnë gjithashtu në disponueshmërinë e produktit. Prandaj, SRE në përgjithësi ka ndërveprim me çdo ekip, duke përfshirë ekipet e sigurisë, duke përfshirë analistët. Prandaj, SRE-të nevojiten kryesisht kur përpiqeni të zbatoni DevOps, por barra mbi zhvilluesit bëhet shumë e madhe. Kjo do të thotë, vetë ekipi i zhvillimit nuk mund të përballojë më faktin se tani ata gjithashtu duhet të jenë përgjegjës për Ops. Dhe shfaqet një rol më vete. Ky rol është planifikuar në buxhet. Ndonjëherë ky rol ndërtohet në madhësinë e ekipit, shfaqet një person i veçantë, ndonjëherë një nga zhvilluesit bëhet ai. Kështu shfaqet SRE-ja e parë në ekip.
Kompleksiteti i sistemit që ndikohet nga SRE, kompleksiteti që ndikon në besueshmërinë operacionale, mund të jetë i nevojshëm ose i rastësishëm. Kompleksiteti i domosdoshëm është kur kompleksiteti i produktit rritet në masën që kërkojnë veçoritë e reja të produktit. Kompleksiteti i rastësishëm është kur kompleksiteti i sistemit rritet, por veçoria e produktit dhe kërkesat e biznesit nuk ndikojnë drejtpërdrejt në këtë. Rezulton se ose zhvilluesi ka bërë një gabim diku, ose algoritmi nuk është optimal, ose janë futur disa interesa shtesë që rrisin kompleksitetin e produktit në mënyrë të panevojshme. Një SRE e mirë duhet ta shmangë gjithmonë këtë situatë. Kjo do të thotë, çdo angazhim, çdo vendosje, çdo kërkesë tërheqjeje që rrit kompleksitetin për shkak të shtesave të rastësishme duhet të bllokohet.
Pyetja është pse të mos punësoni thjesht një inxhinier, një administrator sistemi me shumë njohuri, për t'iu bashkuar ekipit. Një zhvillues në rolin e një inxhinieri, na thuhet, nuk është zgjidhja më optimale e personelit. Një zhvillues në rolin e një inxhinieri nuk është gjithmonë zgjidhja optimale e personelit, por çështja këtu është se një zhvillues që është i angazhuar në Ops ka pak më shumë dëshirë për automatizim, ka pak më shumë njohuri dhe aftësi për ta zbatuar këtë. automatizimi. Dhe në përputhje me rrethanat, ne zvogëlojmë jo vetëm kohën për disa operacione specifike, jo vetëm rutinën, por edhe parametrat e tillë të rëndësishëm të biznesit si MTTR (Mean Time To Recovery, koha e rikuperimit). Kështu, dhe ne gjithashtu do të flasim për këtë pak më vonë, ne kursejmë para për organizatën.
Tani le të flasim për kriteret për punën e SRE. Dhe para së gjithash për besueshmërinë. Në kompanitë e vogla dhe startup-et, shpesh ndodh që njerëzit të supozojnë se nëse shërbimi është shkruar mirë, nëse produkti është shkruar mirë dhe saktë, ai do të funksionojë, nuk do të prishet. Kjo është e gjitha, ne shkruajmë kod të mirë, kështu që nuk ka asgjë për të thyer. Kodi është shumë i thjeshtë, nuk ka asgjë për të thyer. Bëhet fjalë për të njëjtët njerëz që thonë se ne nuk kemi nevojë për teste, sepse, shikoni, këto janë tre metoda VPI, pse të shqetësohemi?
E gjithë kjo është e gabuar, sigurisht. Dhe këta njerëz shumë shpesh lëndohen nga ky lloj kodi në praktikë, sepse gjërat prishen. Gjërat ndonjëherë prishen në mënyrat më të paparashikueshme. Ndonjëherë njerëzit thonë jo, nuk do të ndodhë kurrë. Dhe ende ndodh. Ndodh mjaft shpesh. Dhe kjo është arsyeja pse askush nuk përpiqet kurrë për disponueshmërinë 100%, sepse disponueshmëria 100% nuk ndodh kurrë. Kjo është norma. Dhe kjo është arsyeja pse ne gjithmonë flasim për nëntë kur flasim për disponueshmërinë e shërbimit. 2 nëntë, 3 nëntë, 4 nëntë, 5 nëntë. Nëse e përkthejmë këtë në kohë joproduktive, atëherë, për shembull, 5 nëntë janë pak më shumë se 5 minuta pushim në vit, 2 nëntë janë 3,5 ditë pushim.
Por është e qartë se në një moment ka një rënie në POI dhe kthim nga investimi. Kalimi nga dy nëntë në tre nëntë do të thotë reduktim i kohës së ndërprerjes me më shumë se 3 ditë. Kalimi nga katër nëntë në pesë redukton kohën e pushimit me 47 minuta në vit. Dhe rezulton se kjo mund të mos jetë kritike për biznesin. Dhe në përgjithësi, besueshmëria e kërkuar nuk është një çështje teknike, para së gjithash, është një çështje biznesi, është një çështje produkti. Çfarë niveli i kohës së ndërprerjes është i pranueshëm për përdoruesit e produktit, çfarë presin ata, sa paguajnë, për shembull, sa para humbasin, sa para humbet sistemi.
Një pyetje e rëndësishme është se cila është besueshmëria e komponentëve të mbetur. Sepse ndryshimi midis 4 dhe 5 nëntë nuk do të jetë i dukshëm në një smartphone me 2 nëntë besueshmërie. Përafërsisht, nëse diçka prishet në një smartphone në shërbimin tuaj 10 herë në vit, ka shumë të ngjarë 8 herë prishja ka ndodhur në anën e OS. Përdoruesi është mësuar me këtë dhe nuk do t'i kushtojë vëmendje një herë shtesë në vit. Është e nevojshme të krahasohet çmimi i rritjes së besueshmërisë dhe rritjes së fitimeve.
Vetëm në librin për SRE ka një shembull të mirë të rritjes në 4 nëntë nga 3 nëntë. Rezulton se rritja e disponueshmërisë është pak më pak se 0,1%. Dhe nëse të ardhurat e shërbimit janë 1 milion dollarë në vit, atëherë rritja e të ardhurave është 900 dollarë. Nëse rritja e disponueshmërisë me nëntë na kushton më pak se 900 dollarë në vit, rritja ka kuptim financiar. Nëse kushton më shumë se 900 dollarë në vit, nuk ka më kuptim, sepse rritja e të ardhurave thjesht nuk kompenson kostot e punës dhe kostot e burimeve. Dhe 3 nëntë do të na mjaftojnë.
Ky është sigurisht një shembull i thjeshtuar ku të gjitha kërkesat janë të barabarta. Dhe nga 3 nëntë në 4 nëntë është mjaft e lehtë të shkosh, por në të njëjtën kohë, për shembull, kalimi nga 2 nëntë në 3 është tashmë një kursim prej 9 mijë dollarësh, mund të ketë kuptim financiar. Natyrisht, në realitet, dështimi për të regjistruar një kërkesë është më i keq sesa dështimi për të shfaqur një faqe; kërkesat kanë peshë të ndryshme. Ata mund të kenë kritere krejtësisht të ndryshme nga pikëpamja e biznesit, por megjithatë, si rregull, nëse nuk po flasim për ndonjë shërbim specifik, ky është një përafrim mjaft i besueshëm.
Ne morëm një pyetje nëse SRE është një nga koordinatorët kur zgjedh një zgjidhje arkitekturore për shërbimin. Kjo është e pranueshme në aspektin e integrimit në infrastrukturën ekzistuese në mënyrë që të mos ketë humbje në stabilitetin e saj. Po, SRE-të ndikojnë në kërkesat për tërheqje, angazhime, lëshime në të njëjtën mënyrë; ato ndikojnë në arkitekturën, zbatimin e shërbimeve të reja, mikroshërbimet dhe zbatimin e zgjidhjeve të reja. Pse thashë më parë se duhet përvojë, duhen kualifikime. Në fakt, SRE është një nga zërat bllokues në çdo zgjidhje arkitekturore dhe softuerike. Prandaj, një SRE si inxhinier duhet, para së gjithash, jo vetëm të kuptojë, por edhe të kuptojë se si disa vendime specifike do të ndikojnë në besueshmërinë, stabilitetin dhe të kuptojë se si kjo lidhet me nevojat e biznesit dhe nga cili këndvështrim kjo mund të jetë e lejueshme; dhe me të cilën nuk është.
Prandaj, tani është koha për të folur për kriteret e besueshmërisë, të cilat në SRE përkufizohen tradicionalisht si SLA (Marrëveshja e Nivelit të Shërbimit). Me shumë mundësi një term i njohur. SLI (Treguesi i Nivelit të Shërbimit). SLO (Objektivi i Nivelit të Shërbimit). Marrëveshja e nivelit të shërbimit është ndoshta një term i rëndësishëm, veçanërisht nëse keni punuar me rrjete, ofrues dhe hosting. Kjo është një marrëveshje e përgjithshme që përshkruan performancën e të gjithë shërbimit tuaj, penalitetet, disa dënime për gabime, metrikë, kritere. Dhe SLI është vetë metrika e aksesueshmërisë. Kjo do të thotë, çfarë mund të jetë SLI: koha e përgjigjes nga shërbimi, numri i gabimeve në përqindje. Kjo mund të jetë gjerësia e brezit nëse po flasim për një lloj pritjeje skedarësh. Nëse po flasim për algoritmet e njohjes, treguesi madje mund të jetë, për shembull, korrektësia e përgjigjes. SLO (Service Level Objective) është, përkatësisht, një kombinim i treguesit SLI, vlerës së tij dhe periudhës.
Le të themi se SLA mund të jetë kështu. Shërbimi është i disponueshëm 99,95% të kohës gjatë gjithë vitit. Ose 99 bileta të mbështetjes teknike kritike do të mbyllen brenda 3 orëve në tremujor. Ose 85% e pyetjeve do të përgjigjen brenda 1,5 sekondash çdo muaj. Kjo do të thotë, gradualisht po arrijmë të kuptojmë se gabimet dhe dështimet janë mjaft normale. Kjo është një situatë e pranueshme, ne po e planifikojmë, madje po llogarisim deri diku. Kjo do të thotë, SRE ndërton sisteme që mund të bëjnë gabime, që duhet t'i përgjigjen normalisht gabimeve dhe që duhet t'i marrin parasysh ato. Dhe nëse është e mundur, ata duhet të trajtojnë gabimet në atë mënyrë që përdoruesi ose të mos i vërë re, ose t'i vërë re, por ekziston një lloj zgjidhjeje në mënyrë që gjithçka të mos shpërbëhet plotësisht.
Për shembull, nëse ngarkoni një video në YouTube dhe YouTube nuk mund ta konvertojë atë menjëherë, nëse videoja është shumë e madhe, nëse formati nuk është optimal, atëherë kërkesa natyrisht nuk do të dështojë me një afat kohor, YouTube nuk do të shfaqë një 502 gabim, YouTube do të thotë: "Ne krijuam gjithçka, videoja juaj po përpunohet. Do të jetë gati për rreth 10 minuta.” Ky është parimi i degradimit të këndshëm, i cili është i njohur, për shembull, nga zhvillimi në front-end nëse e keni bërë ndonjëherë këtë.
Termat e radhës për të cilat do të flasim, të cilat janë shumë të rëndësishme për të punuar me besueshmëri, me gabime, me pritshmëri, janë MTBF dhe MTTR. MTBF është koha mesatare midis dështimeve. Koha mesatare e MTTR deri në rikuperim, koha mesatare deri në rikuperim. Kjo do të thotë, sa kohë ka kaluar nga momenti i zbulimit të gabimit, nga momenti i shfaqjes së gabimit deri në momentin kur shërbimi u rikthye në funksionimin plotësisht normal. MTBF korrigjohet kryesisht duke punuar në cilësinë e kodit. Kjo është, fakti që SRE-të mund të thonë "jo". Dhe i gjithë ekipi duhet të kuptojë se kur SRE thotë "jo", ai e thotë jo sepse është i dëmshëm, jo sepse është i keq, por sepse përndryshe të gjithë do të vuajnë.
Përsëri, ka shumë artikuj, shumë metoda, shumë mënyra, madje edhe në librin të cilit i referohem kaq shpesh, si të sigurohemi që zhvilluesit e tjerë të mos fillojnë të urrejnë SRE. MTTR, nga ana tjetër, ka të bëjë me punën në SLO tuaj (Objektivi i Nivelit të Shërbimit). Dhe kjo është kryesisht automatizimi. Sepse, për shembull, SLO-ja jonë është një kohë pune prej 4 nëntë për tremujor. Kjo do të thotë që në 3 muaj mund të lejojmë 13 minuta pushim. Dhe rezulton se MTTR-ja jonë nuk mund të jetë më shumë se 13 minuta. Nëse marrim 13 minuta për të reaguar ndaj të paktën 1 pushimi, kjo do të thotë se tashmë e kemi ezauruar të gjithë buxhetin për tremujorin. Ne po shkelim SLO. 13 minuta për të reaguar dhe korrigjuar një dështim është shumë për një makinë, por shumë pak për një person. Sepse në kohën kur një person merr një alarm, në kohën kur ai reagon, në kohën kur ai kupton gabimin, tashmë janë disa minuta. Derisa një person të kuptojë se si ta rregullojë atë, çfarë saktësisht të rregullojë, çfarë të bëjë, do të duhen edhe disa minuta. Dhe në fakt, edhe nëse thjesht duhet të rindizni serverin, siç rezulton, ose të ngrini një nyje të re, atëherë MTTR merr manualisht rreth 7-8 minuta. Kur automatizon një proces, MTTR shumë shpesh arrin një sekondë, ndonjëherë milisekonda. Google zakonisht flet për milisekonda, por në realitet, natyrisht, gjërat nuk janë aq të mira.
Idealisht, një SRE duhet të automatizojë pothuajse plotësisht punën e tij, sepse kjo ndikon drejtpërdrejt në MTTR, metrikat e tij, SLO-në e të gjithë shërbimit dhe, në përputhje me rrethanat, fitimet e biznesit. Nëse koha tejkalohet, ne pyetemi nëse fajin e ka SRE. Për fat të mirë, faji nuk i vihet askujt. Dhe kjo është një kulturë më vete, e cila quhet postmortem pa balsam, për të cilën nuk do të flasim sot, por do ta analizojmë në Slurm. Kjo është një temë shumë interesante për të cilën mund të flitet shumë. Në mënyrë të përafërt, nëse tejkalohet koha e caktuar për tremujor, atëherë të gjithë e kanë pak fajin, që do të thotë se fajësimi i të gjithëve nuk është produktiv, le të mos fajësojmë askënd, por të korrigjojmë situatën dhe të punojmë me atë që kemi. Në përvojën time, kjo qasje është pak e huaj për shumicën e ekipeve, veçanërisht në Rusi, por ka kuptim dhe funksionon shumë mirë. Prandaj, në fund do t'ju rekomandoj artikuj dhe literaturë që mund të lexoni për këtë temë. Ose ejani në Slurm SRE.
Më lejo të shpjegohem. Nëse koha e SLO për tremujorin tejkalohet, nëse koha e ndërprerjes nuk ishte 13 minuta, por 15, kush mund të jetë fajtor për këtë? Natyrisht, SRE mund të jetë fajtor sepse në mënyrë të qartë bëri një kryerje ose vendosje të keqe. Për këtë mund të fajësohet administratori i qendrës së të dhënave, sepse ai mund të ketë kryer ndonjë mirëmbajtje të paplanifikuar. Nëse për këtë është fajtor administratori i qendrës së të dhënave, atëherë fajtor është edhe personi nga Ops që nuk ka llogaritur mirëmbajtjen kur është dakord për SLO. Ky është faji i menaxherit, drejtorit teknik ose dikush që ka nënshkruar kontratën e qendrës së të dhënave dhe nuk i ka kushtuar vëmendje faktit që qendra e të dhënave SLA nuk është projektuar për kohën e kërkuar të joproduktive. Prandaj, të gjithë janë pak fajtorë për këtë situatë. Dhe kjo do të thotë se nuk ka kuptim të fajësohet dikush në veçanti për këtë situatë. Por sigurisht që duhet korrigjuar. Kjo është arsyeja pse ekzistojnë postmortemat. Dhe nëse lexoni, për shembull, postmortemat e GitHub, dhe kjo është gjithmonë një histori shumë interesante, e vogël dhe e papritur në secilin rast specifik, mund ta zëvendësoni atë që askush të mos thotë kurrë se ky person i veçantë ishte fajtor. Faji u vihet gjithmonë proceseve specifike të mangëta.
Le të kalojmë në pyetjen tjetër. Automatizimi. Zakonisht, kur flas për automatizimin në kontekste të tjera, shumë shpesh i referohem një tabele që flet për sa kohë mund të punoni në automatizimin e një detyre, në mënyrë që të mos merrni më shumë kohë për ta automatizuar atë sesa kurseni në përgjithësi. Ka një kapje. Kapja është se kur SRE-të automatizojnë një detyrë, ata jo vetëm që kursejnë kohë, por kursejnë para sepse automatizimi ndikon drejtpërdrejt në MTTR. Ata kursejnë, si të thuash, moralin e punonjësve dhe zhvilluesve, i cili është gjithashtu një burim i shtershëm. Ata reduktojnë rutinën. Dhe e gjithë kjo ka një efekt pozitiv në punë dhe, si rezultat, në biznes, edhe nëse duket se automatizimi nuk ka kuptim për sa i përket kostove kohore.
Në fakt, pothuajse gjithmonë ndodh, dhe ka shumë pak raste kur nuk ia vlen të automatizosh diçka në rolin e SRE. Më pas do të flasim për atë që quhet buxheti i gabimeve, buxheti për gabimet. Në fakt, rezulton se nëse po bëni dukshëm më mirë se SLO që keni vendosur për veten tuaj, kjo gjithashtu nuk është shumë e mirë. Kjo është mjaft e keqe, sepse SLO funksionon jo vetëm si kufi i poshtëm, por edhe si kufi i sipërm i përafërt. Kur i vendosni vetes një SLO prej 99% disponueshmërie, dhe në fakt keni 99,99%, rezulton se keni një hapësirë për eksperimente, e cila nuk do ta dëmtojë aspak biznesin, sepse ju vetë e keni përcaktuar këtë të gjitha së bashku, dhe ju keni këtë hapësirë mos e përdorni. Ju keni një buxhet për gabime, i cili në rastin tuaj nuk shpenzohet.
Çfarë po bëjmë me të? Ne e përdorim atë fjalë për fjalë për gjithçka. Për testimin në kushtet e prodhimit, për nxjerrjen e veçorive të reja që mund të ndikojnë në performancën, për lëshimet, për mirëmbajtjen, për kohët e planifikuara të ndërprerjes. Vlen edhe rregulli i kundërt: nëse shterohet buxheti, nuk mund të nxjerrim asgjë të re, sepse në të kundërtën do ta kalojmë SLO-në. Buxheti tashmë është shteruar, ne kemi lëshuar diçka, nëse kjo ndikon negativisht në performancën, domethënë nëse nuk është një lloj rregullimi që në vetvete rrit drejtpërdrejt SLO, atëherë ne po kalojmë buxhetin dhe kjo është një situatë e keqe. , kërkon analizë, postmortem dhe ndoshta një korrigjim të procesit.
Kjo do të thotë, rezulton se nëse vetë shërbimi nuk funksionon mirë, dhe SLO shpenzohet dhe buxheti nuk shpenzohet për eksperimente, jo në ndonjë lëshim, por më vete, atëherë në vend të disa rregullimeve interesante, në vend të interesave veçoritë, në vend të publikimeve interesante. Në vend që të bëni ndonjë punë krijuese, do t'ju duhet të bëni rregullime budallaqe për të rikthyer buxhetin në rregull, ose të redaktoni SLO, dhe ky është gjithashtu një proces që nuk duhet të ndodhë shumë shpesh.
Prandaj, rezulton se në një situatë ku kemi më shumë buxhet për gabime, të gjithë janë të interesuar: si SRE ashtu edhe zhvilluesit. Për zhvilluesit, një buxhet i madh për gabime do të thotë që ata mund të merren me lëshime, teste dhe eksperimente. Për SRE-të, një buxhet për gabime dhe futja në këtë buxhet do të thotë se ata në fakt po bëjnë një punë të mirë. Dhe kjo ndikon në motivimin e një lloj pune të përbashkët. Nëse dëgjoni SRE-të tuaja si zhvillues, do të keni më shumë hapësirë për të bërë punë të mirë dhe shumë më pak punë.
Rezulton se eksperimentet në prodhim janë një pjesë mjaft e rëndësishme dhe pothuajse integrale e SRE në ekipe të mëdha. Dhe zakonisht quhet kaos inxhinieri, i cili vjen nga ekipi në Netflix që lëshoi një program të quajtur Chaos Monkey.
Chaos Monkey lidhet me tubacionin CI/CD dhe përplaset rastësisht serverin në prodhim. Përsëri, në strukturën SRE themi se një server i prishur nuk është i keq në vetvete, është i pritshëm. Dhe nëse futet në buxhet është e pranueshme dhe nuk e dëmton biznesin. Natyrisht, Netflix ka mjaft serverë të tepërt, mjaftueshëm përsëritje, saqë e gjithë kjo mund të rregullohet pa e vënë re edhe përdoruesi në tërësi, dhe sigurisht askush nuk lë një server për çdo buxhet.
Netflix në një kohë kishte një grup të tërë shërbimesh të tilla, njëra prej të cilave, Chaos Gorilla, çaktivizon plotësisht një nga zonat e disponueshmërisë në Amazon. Dhe gjëra të tilla ndihmojnë mirë për të identifikuar, së pari, varësitë e fshehura, kur nuk është plotësisht e qartë se çfarë ndikon në çfarë, çfarë varet nga çfarë. Dhe kjo, nëse jeni duke punuar me një mikroservis dhe dokumentacioni nuk është plotësisht i përsosur, kjo mund të jetë e njohur për ju. Dhe përsëri, kjo ndihmon për të kapur gabimet në kod që nuk mund t'i kapni gjatë vendosjes, sepse çdo skemë nuk është një simulim i saktë, për faktin se shkalla e ngarkesës është e ndryshme, modeli i ngarkesës është i ndryshëm, pajisjet janë gjithashtu, shumica me gjasë, të tjera. Ngarkesat maksimale mund të jenë gjithashtu të papritura dhe të paparashikueshme. Dhe një testim i tillë, i cili përsëri nuk shkon përtej buxhetit, ndihmon shumë mirë për të kapur gabimet në infrastrukturë që inskenimet, autotestet dhe tubacionet CI/CD nuk do t'i kapin kurrë. Dhe për sa kohë që kjo është e gjitha e përfshirë në buxhetin tuaj, nuk ka rëndësi që shërbimi juaj ka rënë atje, megjithëse do të dukej shumë e frikshme, serveri është rrëzuar, çfarë makthi. Jo, kjo është normale, kjo është mirë, ndihmon në kapjen e gabimeve. Nëse keni një buxhet, mund ta shpenzoni atë.
Pyetje: çfarë literaturë mund të rekomandoj? Lista është në fund. Ka shumë literaturë, unë do të rekomandoja disa raporte. Si funksionon dhe nëse SRE funksionon në kompani pa produktin e tyre softuerik ose me zhvillim minimal. Për shembull, në një ndërmarrje, ku aktiviteti kryesor nuk është softueri. Në një ndërmarrje, ku aktiviteti kryesor nuk është softueri, SRE funksionon saktësisht njësoj si kudo tjetër, sepse në një ndërmarrje duhet gjithashtu të përdorni, edhe nëse nuk zhvilloni, produkte softuerësh, duhet të shpërndani përditësime, ju duhet të ndryshosh infrastrukturën, duhet të rritesh, duhet të shkallëzohesh. Dhe SRE-të ndihmojnë në identifikimin dhe parashikimin e problemeve të mundshme në këto procese dhe kontrollin e tyre pasi të fillojë një rritje dhe nevojat e biznesit të ndryshojnë. Sepse nuk është absolutisht e nevojshme të angazhoheni në zhvillimin e softuerit në mënyrë që të keni SRE, nëse keni të paktën disa serverë dhe prisni të paktën një rritje.
E njëjta gjë vlen edhe për projektet e vogla, organizatat e vogla, sepse kompanitë e mëdha kanë buxhetin dhe hapësirën për eksperimentim. Por në të njëjtën kohë, të gjitha këto fryte të eksperimenteve mund të përdoren kudo, domethënë SRE-të, natyrisht, u shfaqën në Google, Netflix dhe Dropbox. Por në të njëjtën kohë, kompanitë e vogla dhe startup-et tashmë mund të lexojnë materiale të përmbledhura, të lexojnë libra dhe të shikojnë raporte. Ata fillojnë të dëgjojnë për këtë më shpesh, shikoni shembuj specifikë, mendoj, në rregull, kjo mund të jetë vërtet e dobishme, edhe ne kemi nevojë për këtë, mirë.
Kjo do të thotë, e gjithë puna kryesore për standardizimin e këtyre proceseve është bërë tashmë për ju. E tëra çfarë ju duhet të bëni është të përcaktoni rolin e SRE-së në mënyrë specifike në kompaninë tuaj dhe të filloni të zbatoni të gjitha këto praktika, të cilat, përsëri, janë përshkruar tashmë. Kjo është, nga parimet e dobishme për kompanitë e vogla, ky është gjithmonë përkufizimi i SLA, SLI, SLO. Nëse nuk jeni i përfshirë në softuer, atëherë këto do të jenë SLA të brendshme dhe SLO të brendshme, buxhet i brendshëm për gabime. Kjo pothuajse gjithmonë çon në disa diskutime interesante brenda ekipit dhe brenda biznesit, sepse mund të rezultojë se shpenzoni shumë më tepër sesa duhet për infrastrukturën, për një lloj organizimi të proceseve ideale, një tubacion ideal. Dhe këto 4 nëntë që keni në departamentin e IT, nuk ju duhen vërtet tani. Por në të njëjtën kohë, ishte e mundur të shpenzoje kohë, të shpenzoje buxhetin për gabime për diçka tjetër.
Prandaj, monitorimi dhe organizimi i monitorimit është i dobishëm për një kompani të çdo madhësie. Dhe në përgjithësi, kjo mënyrë e të menduarit, ku gabimet janë diçka e pranueshme, ku ka buxhet, ku ekzistojnë Objektivat, është sërish e dobishme për një kompani të çdo madhësie, duke filluar nga një startup me 3 persona.
E fundit nga nuancat teknike për të cilat mund të flasim është monitorimi. Sepse nëse flasim për SLA, SLI, SLO, nuk mund të kuptojmë pa monitoruar nëse përshtatemi në buxhet, nëse respektojmë Objektivat tona dhe si ndikojmë në SLA përfundimtare. Unë kam vërejtur shumë herë se monitorimi ndodh në këtë mënyrë: ka një vlerë, për shembull, koha e një kërkese në server, koha mesatare ose numri i kërkesave në bazën e të dhënave. Ai ka një standard të përcaktuar nga inxhinieri. Nëse metrika devijon nga norma, dërgohet një email. E gjithë kjo është absolutisht e padobishme, si rregull, sepse çon në një mbingopje të tillë të alarmeve, një mbingopje të mesazheve monitoruese, kur një person, së pari, duhet t'i interpretojë ato çdo herë, domethënë të përcaktojë nëse vlera metrike nënkupton nevojën për një lloj veprimi. Dhe së dyti, ai thjesht ndalon së vënë re të gjitha këto alarme, kur në thelb nuk kërkohet asnjë veprim prej tij. Kjo do të thotë, një rregull i mirë monitorimi dhe rregulli i parë kur zbatohet SRE është që një njoftim duhet të vijë vetëm kur kërkohet një veprim.
Në rastin standard ka 3 nivele të ngjarjeve. Ka alarme, ka bileta, ka regjistra. Alarmet janë çdo gjë që kërkon veprim të menjëhershëm nga ju. Kjo do të thotë, gjithçka është prishur, duhet të rregullohet menjëherë. Biletat janë diçka që kërkon veprime në pritje. Po, duhet të bësh diçka, duhet të bësh diçka me dorë, automatizimi ka dështuar, por nuk duhet ta bësh në minutat e ardhshme. Shkrimet janë gjithçka që nuk kërkon veprim dhe në përgjithësi, nëse gjërat shkojnë mirë, askush nuk do t'i lexojë kurrë. Do të jetë e nevojshme të lexoni regjistrat vetëm kur, në retrospektivë, rezulton se diçka ishte thyer për ca kohë, ne nuk dinim për të. Ose duhet bërë një lloj hetimi. Por në përgjithësi, gjithçka që nuk kërkon ndonjë veprim shkon në regjistrat.
Si efekt anësor i gjithë kësaj, nëse kemi identifikuar se cilat ngjarje kërkojnë veprime dhe kemi përshkruar mirë se cilat duhet të jenë ato veprime, kjo do të thotë se veprimi mund të automatizohet. Kjo është, çfarë ndodh. Ne vijmë nga një alarm. Le të shkojmë në veprim. Le të kalojmë në përshkrimin e këtij veprimi. Dhe më pas kalojmë drejt automatizimit. Kjo do të thotë, çdo automatizim fillon me një reagim ndaj një ngjarjeje.
Nga monitorimi kalojmë në një term të quajtur Vëzhgueshmëri. Ka pasur gjithashtu pak zhurmë rreth kësaj fjale vitet e fundit. Dhe pak njerëz e kuptojnë se çfarë do të thotë kjo jashtë kontekstit. Por çështja kryesore është se Vëzhgueshmëria është një metrikë e transparencës së sistemit. Nëse diçka shkoi keq, sa shpejt mund të përcaktoni se çfarë saktësisht shkoi keq dhe cila ishte gjendja e sistemit në atë moment. Nga pikëpamja e kodit: cili funksion dështoi, cili shërbim dështoi. Cila ishte gjendja e, për shembull, variablave të brendshëm, konfigurimi. Nga pikëpamja e infrastrukturës, kjo është se në cilën zonë të disponueshmërisë ndodhi dështimi, dhe nëse keni një lloj Kubernetes, atëherë në cilin pod ndodhi dështimi, cila ishte gjendja e pod. Dhe në përputhje me rrethanat, Vëzhgueshmëria ka një lidhje të drejtpërdrejtë me MTTR. Sa më i lartë të jetë Vëzhgueshmëria e shërbimit, aq më e lehtë është të identifikohet gabimi, aq më e lehtë është të rregullohet gabimi, aq më e lehtë është automatizimi i gabimit, aq më i ulët është MTTR.
Nëse kalojmë përsëri te kompanitë e vogla, ata shumë shpesh pyesin, edhe tani, çfarë të bëjnë me madhësinë e ekipit dhe nëse është e nevojshme të punësosh një SRE të veçantë në një ekip të vogël. Unë tashmë fola për këtë pak më herët. Në fazat e para të zhvillimit të një startup-i ose, për shembull, një ekipi, kjo nuk është aspak e nevojshme, sepse SRE mund të bëhet një rol kalimtar. Dhe kjo do ta gjallërojë pak ekipin, sepse ka të paktën një diversitet. Dhe plus do t'i përgatisë njerëzit për faktin se ndërsa rriten, në përgjithësi, përgjegjësitë e SRE do të ndryshojnë shumë ndjeshëm. Nëse punësoni një person, atëherë, natyrisht, ai ka disa pritshmëri. Dhe këto pritshmëri nuk do të ndryshojnë me kalimin e kohës, por kërkesat do të ndryshojnë shumë. Prandaj, punësimi i një SRE është mjaft i vështirë në fazat e hershme. Është shumë më e lehtë për të rritur tuajën. Por ia vlen të mendosh.
Përjashtimi i vetëm, ndoshta, është kur ka kërkesa shumë strikte dhe të përcaktuara mirë për lartësinë. Kjo do të thotë, në rastin e një startup, ky mund të jetë një lloj presioni nga investitorët, një lloj parashikimi për rritje disa herë në të njëjtën kohë. Atëherë punësimi i një SRE është përgjithësisht i justifikuar sepse mund të justifikohet. Ne kemi kërkesa për rritje, na duhet një person i cili do të jetë përgjegjës për të siguruar që me një rritje të tillë asgjë të mos prishet.
Edhe një pyetje. Çfarë duhet bërë kur disa herë zhvilluesit prenë një veçori që kalon testet, por prish produktin, ngarkon bazën e të dhënave, prish veçori të tjera, çfarë procesi duhet të zbatojë. Prandaj, në këtë rast, futet një buxhet për gabime. Dhe disa shërbime, disa veçori testohen menjëherë në prodhim. Kjo mund të jetë një kanarinë, kur vetëm një numër i vogël përdoruesish, por tashmë në prodhim, po vendosin një veçori, por me pritjen që nëse diçka prishet, për shembull, për gjysmë për qind të të gjithë përdoruesve, ajo ende do të përshtatet brenda buxhet për gabime. Prandaj, po, do të ketë një gabim, për disa përdorues gjithçka do të prishet, por ne kemi thënë tashmë se kjo është normale.
Kishte një pyetje në lidhje me mjetet SRE. Kjo do të thotë, a ka diçka specifike që SRE-të do të përdornin që të gjithë të tjerët nuk do ta përdornin? Në fakt, ka disa shërbime shumë të specializuara, ka disa softuer që, për shembull, simulon ngarkesa ose bën testimin e kanarinës A/B. Por në thelb, veglat SRE janë ato që zhvilluesit tuaj po përdorin tashmë. Sepse SRE ndërvepron drejtpërdrejt me ekipin e zhvillimit. Dhe nëse keni mjete të ndryshme, rezulton se kërkon kohë për t'u sinkronizuar. Sidomos nëse SRE-të punojnë në ekipe të mëdha, në kompani të mëdha ku mund të ketë disa ekipe, standardizimi në të gjithë kompaninë do të jetë shumë i dobishëm këtu, sepse nëse 50 ekipe përdorin 50 shërbime të ndryshme, kjo do të thotë që SRE duhet t'i njohë të gjitha. Dhe sigurisht kjo nuk do të ndodhë kurrë. Dhe cilësia e punës, cilësia e kontrollit të të paktën disa prej ekipeve do të ulet ndjeshëm.
Webinari ynë gradualisht po i vjen fundi. Arrita t'ju them disa gjëra themelore. Natyrisht, asgjë për SRE nuk mund të thuhet dhe të kuptohet brenda një ore. Por shpresoj se kam arritur të përcjell këtë mënyrë të menduari, pikat kryesore kryesore. Dhe pastaj, nëse jeni të interesuar, mund të futeni më thellë në temën, të studioni vetë dhe të shikoni se si po zbatohet nga njerëz të tjerë, në kompani të tjera. Dhe në përputhje me rrethanat, në fillim të shkurtit, ejani tek ne në Slurm SRE.
Slurm SRE është një kurs intensiv treditor që do të mbulojë përafërsisht atë për të cilën po flas tani, por me thellësi shumë më të madhe, me raste reale, me praktikë, i gjithë intensivi synon punën praktike. Njerëzit do të ndahen në ekipe. Të gjithë do të punoni në raste reale. Prandaj, ne kemi instruktorë nga Booking.com Ivan Kruglov dhe Ben Tyler. Ne kemi një Evgeniy Varabbas të mrekullueshëm nga Google, nga San Francisko. Dhe unë do t'ju them edhe diçka. Prandaj sigurohuni që të na vizitoni.
Pra, një listë e referencave. Ka lidhje në SRE. në të njëjtin libër, ose më mirë në 2 libra për SRE, të shkruar nga Google. Nje tjeter , ku termat dhe zbatimi i tyre shpjegohen pak më në detaje. 3 në vijim janë raportet mbi SRE në kompani të ndryshme. Së pari - , ky është një fjalim kryesor nga Ben Trainer nga Google. E dyta - . E treta është përsëri rreth . Raporti i katërt nga , e cila ka vetëm 5 punonjës kyç të SRE në 190 vende. Është shumë interesante të shikosh të gjitha këto, sepse ashtu si DevOps do të thotë gjëra shumë të ndryshme për kompani të ndryshme dhe madje edhe ekipe të ndryshme, SRE ka përgjegjësi shumë të ndryshme, madje edhe në kompani me madhësi të ngjashme.
2 lidhje të tjera mbi parimet e inxhinierisë së kaosit: , . Dhe në fund ka 3 lista nga seria Awesome Lists rreth , rreth dhe rreth . Lista në SRE është tepër e madhe, nuk keni pse t'i kaloni të gjitha, ka rreth 200 artikuj. Unë rekomandoj shumë artikujt rreth planifikimit të kapaciteteve dhe pas vdekjes së pafajshme.
Artikull interesant:
Faleminderit që më dëgjuat gjatë gjithë kësaj kohe. Shpresoj se keni mësuar diçka. Shpresoj të keni materiale të mjaftueshme për të mësuar edhe më shumë. Dhe shihemi më vonë. Shpresojmë në shkurt.
Webinari u drejtua nga Eduard Medvedev.
PS: për ata që duan të lexojnë, Eduardi dha një listë të referencave. Ata që preferojnë ta kuptojnë atë në praktikë janë të mirëpritur .
Burimi: www.habr.com