Mtandao una sauti duni, kwa hivyo tumeinukuu.
Jina langu ni Medvedev Eduard. Leo nitazungumzia kuhusu SRE ni nini, jinsi SRE ilionekana, ni vigezo gani vya kazi wahandisi wa SRE wanayo, kidogo kuhusu vigezo vya kuaminika, kidogo kuhusu ufuatiliaji wake. Tutatembea juu, kwa sababu huwezi kusema mengi kwa saa moja, lakini nitatoa nyenzo kwa ukaguzi wa ziada, na sote tunakungojea. . huko Moscow mwishoni mwa Januari.
Kwanza, hebu tuzungumze kuhusu SRE ni nini - Uhandisi wa Kuegemea wa Tovuti. Na jinsi ilionekana kama nafasi tofauti, kama mwelekeo tofauti. Yote ilianza na ukweli kwamba katika duru za maendeleo ya jadi, Dev na Ops ni timu mbili tofauti kabisa, kawaida na malengo mawili tofauti kabisa. Lengo la timu ya maendeleo ni kuzindua vipengele vipya na kukidhi mahitaji ya biashara. Lengo la timu ya Ops ni kuhakikisha kila kitu kinafanya kazi na hakuna kitakachoharibika. Kwa wazi, malengo haya yanapingana moja kwa moja: kwa kila kitu kufanya kazi na hakuna kitu cha kuvunja, toa vipengele vipya kidogo iwezekanavyo. Kwa sababu hii, kuna migogoro mingi ya ndani ambayo mbinu ambayo sasa inaitwa DevOps inajaribu kutatua.
Shida ni kwamba hatuna ufafanuzi wazi wa DevOps na utekelezaji wazi wa DevOps. Nilizungumza kwenye mkutano huko Yekaterinburg miaka 2 iliyopita, na hadi sasa sehemu ya DevOps ilianza na ripoti "DevOps ni nini". Mnamo 2017, Devops ana karibu miaka 10, lakini bado tunabishana ni nini. Na hii ni hali ya ajabu sana ambayo Google ilijaribu kutatua miaka michache iliyopita.
Mnamo 2016, Google ilitoa kitabu kinachoitwa Uhandisi wa Kuegemea wa Tovuti. Na kwa kweli, ilikuwa na kitabu hiki kwamba harakati ya SRE ilianza. SRE ni utekelezaji mahususi wa dhana ya DevOps katika kampuni mahususi. Wahandisi wa SRE wamejitolea kuhakikisha kuwa mifumo inafanya kazi kwa uhakika. Mara nyingi hutoka kwa wasanidi programu, wakati mwingine kutoka kwa wasimamizi walio na usuli dhabiti wa ukuzaji. Na wanafanya kile ambacho wasimamizi wa mfumo walikuwa wakifanya, lakini historia yenye nguvu katika maendeleo na ujuzi wa mfumo katika suala la kanuni inaongoza kwa ukweli kwamba watu hawa hawana mwelekeo wa kazi ya kawaida ya utawala, lakini wana mwelekeo wa automatisering.
Inabadilika kuwa dhana ya DevOps katika timu za SRE inatekelezwa na ukweli kwamba kuna wahandisi wa SRE ambao hutatua matatizo ya kimuundo. Huu hapa, muunganisho sawa kati ya Dev na Ops ambao watu wamekuwa wakizungumza kwa miaka 8. Jukumu la SRE ni sawa na lile la mbunifu kwa kuwa wageni hawawi SRE. Watu mwanzoni mwa kazi zao bado hawana uzoefu wowote, hawana upana wa lazima wa ujuzi. Kwa sababu SRE inahitaji maarifa ya hila ya ni nini haswa na wakati gani haswa unaweza kwenda vibaya. Kwa hivyo, uzoefu fulani unahitajika hapa, kama sheria, ndani ya kampuni na nje.
Wanauliza ikiwa tofauti kati ya SRE na devops itaelezewa. Ameelezwa hivi punde. Tunaweza kuzungumza juu ya nafasi ya SRE katika shirika. Tofauti na mbinu hii ya kawaida ya DevOps, ambapo Ops bado ni idara tofauti, SRE ni sehemu ya timu ya maendeleo. Wanahusika katika maendeleo ya bidhaa. Kuna hata mbinu ambapo SRE ni jukumu ambalo hupita kutoka kwa msanidi mmoja hadi mwingine. Wanashiriki katika ukaguzi wa kanuni kwa njia sawa na, kwa mfano, wabunifu wa UX, watengenezaji wenyewe, wakati mwingine wasimamizi wa bidhaa. SRE hufanya kazi kwa kiwango sawa. Tunahitaji kuziidhinisha, tunahitaji kuzipitia, ili kwa kila SRE ya kupelekwa iseme: "Sawa, utumaji huu, bidhaa hii haitaathiri vibaya uaminifu. Na ikiwa inafanya, basi ndani ya mipaka inayokubalika. Pia tutazungumza kuhusu hili.
Ipasavyo, SRE ina kura ya turufu ya kubadilisha kanuni. Na kwa ujumla, hii pia husababisha aina fulani ya migogoro ndogo ikiwa SRE inatekelezwa vibaya. Katika kitabu hicho hicho kuhusu Uhandisi wa Kuegemea wa Tovuti, sehemu nyingi, hata moja, zinaelezea jinsi ya kuzuia migogoro hii.
Wanauliza jinsi SRE inahusiana na usalama wa habari. SRE haihusiki moja kwa moja katika usalama wa habari. Kimsingi, katika makampuni makubwa, hii inafanywa na watu binafsi, wapimaji, wachambuzi. Lakini SRE pia huingiliana nao kwa maana kwamba baadhi ya shughuli, baadhi hufanya, baadhi ya utumaji unaoathiri usalama pia unaweza kuathiri upatikanaji wa bidhaa. Kwa hivyo, SRE kwa ujumla ina mwingiliano na timu yoyote, ikiwa ni pamoja na timu za usalama, ikiwa ni pamoja na wachambuzi. Kwa hiyo, SRE zinahitajika hasa wakati wanajaribu kutekeleza DevOps, lakini wakati huo huo, mzigo wa watengenezaji unakuwa mkubwa sana. Hiyo ni, timu ya maendeleo yenyewe haiwezi tena kukabiliana na ukweli kwamba sasa wanahitaji pia kuwajibika kwa Ops. Na kuna jukumu tofauti. Jukumu hili limepangwa katika bajeti. Wakati mwingine jukumu hili limewekwa kwa ukubwa wa timu, mtu tofauti anaonekana, wakati mwingine mmoja wa watengenezaji huwa. Hivi ndivyo SRE ya kwanza inavyoonekana kwenye timu.
Ugumu wa mfumo unaoathiriwa na SRE, ugumu unaoathiri uaminifu wa operesheni, ni muhimu na kwa ajali. Utata unaohitajika ni wakati utata wa bidhaa unapoongezeka kwa kiwango kinachohitajika na vipengele vipya vya bidhaa. Utata wa nasibu ni wakati utata wa mfumo unapoongezeka, lakini kipengele cha bidhaa na mahitaji ya biashara hayaathiri hii moja kwa moja. Inabadilika kuwa ama msanidi programu alifanya makosa mahali fulani, au algorithm sio sawa, au masilahi mengine ya ziada yanaletwa ambayo huongeza ugumu wa bidhaa bila hitaji maalum. SRE nzuri inapaswa kukata hali hii kila wakati. Hiyo ni, ahadi yoyote, upelekaji wowote, ombi lolote la kuvuta, ambapo ugumu unaongezeka kwa sababu ya nyongeza ya nasibu, inapaswa kuzuiwa.
Swali ni kwa nini usiajiri tu mhandisi, msimamizi wa mfumo aliye na ujuzi mwingi kwenye timu. Msanidi programu katika nafasi ya mhandisi, tunaambiwa, sio suluhisho bora la wafanyikazi. Msanidi programu katika nafasi ya mhandisi sio kila wakati suluhisho bora zaidi la wafanyikazi, lakini jambo hapa ni kwamba msanidi programu ambaye anajishughulisha na Ops ana hamu zaidi ya otomatiki, ana maarifa zaidi na ujuzi uliowekwa ili kutekeleza. otomatiki hii. Na ipasavyo, tunapunguza sio tu wakati wa shughuli fulani maalum, sio tu utaratibu, lakini pia vigezo muhimu vya biashara kama MTTR (Wakati wa Kuokoa, wakati wa kurejesha). Kwa hivyo, na pia tutazungumza juu ya hii baadaye kidogo, tunaokoa pesa kwa shirika.
Sasa hebu tuzungumze juu ya vigezo vya uendeshaji wa SRE. Na kwanza kabisa juu ya kuegemea. Katika makampuni madogo, startups, mara nyingi hutokea kwamba watu wanadhani kwamba ikiwa huduma imeandikwa vizuri, ikiwa bidhaa imeandikwa vizuri na kwa usahihi, itafanya kazi, haitavunja. Hiyo ndiyo yote, tunaandika msimbo mzuri, kwa hiyo hakuna kitu cha kuvunja. Kanuni ni rahisi sana, hakuna kitu cha kuvunja. Hizi ni kuhusu watu sawa ambao wanasema kwamba hatuhitaji vipimo, kwa sababu, angalia, hizi ni njia tatu za VPI, kwa nini kuvunja hapa.
Hii yote ni makosa, bila shaka. Na watu hawa mara nyingi huumwa na kanuni kama hizo katika mazoezi, kwa sababu mambo huvunjika. Mambo huvunjika wakati mwingine kwa njia zisizotabirika. Wakati mwingine watu husema hapana, haitatokea kamwe. Na hutokea kila wakati. Inatokea mara nyingi vya kutosha. Na ndiyo sababu hakuna mtu anayewahi kujitahidi kwa upatikanaji wa 100%, kwa sababu upatikanaji wa 100% haufanyiki kamwe. Hii ni kawaida. Na kwa hivyo, tunapozungumza juu ya upatikanaji wa huduma, tunazungumza kila wakati kuhusu nines. 2 nine, 3 nine, 4 nine, 5 nine. Ikiwa tunatafsiri hii kwa muda wa chini, basi, kwa mfano, nines 5, basi hii ni zaidi ya dakika 5 ya muda wa kupumzika kwa mwaka, nines 2 ni siku 3,5 za muda wa kupumzika.
Lakini ni dhahiri kwamba wakati fulani kuna kupungua kwa POI, kurudi kwenye uwekezaji. Kuanzia nine mbili hadi tatu kunamaanisha muda mdogo wa kupumzika kwa zaidi ya siku 3. Kutoka nne tisa hadi tano hupunguza muda wa kupumzika kwa dakika 47 kwa mwaka. Na inageuka kuwa kwa biashara inaweza kuwa sio muhimu. Na kwa ujumla, uaminifu unaohitajika sio suala la kiufundi, kwanza kabisa, ni suala la biashara, ni suala la bidhaa. Ni kiwango gani cha muda wa chini kinachokubalika kwa watumiaji wa bidhaa, wanachotarajia, ni kiasi gani wanacholipa, kwa mfano, ni kiasi gani cha fedha wanachopoteza, ni kiasi gani cha fedha ambacho mfumo unapoteza.
Swali muhimu hapa ni nini kuaminika kwa vipengele vilivyobaki. Kwa sababu tofauti kati ya 4 na 5 nines haitaonekana kwenye smartphone na 2 nines ya kuegemea. Kwa kusema, ikiwa kitu kitavunjika kwenye simu mahiri katika huduma yako mara 10 kwa mwaka, uwezekano mkubwa mara 8 kuvunjika kulitokea upande wa OS. Mtumiaji hutumiwa kwa hili, na hatazingatia mara moja zaidi kwa mwaka. Ni muhimu kuunganisha bei ya kuongeza kuegemea na kuongeza faida.
Katika kitabu cha SRE kuna mfano mzuri wa kuongezeka hadi 4 nines kutoka 3 nines. Inatokea kwamba ongezeko la upatikanaji ni kidogo chini ya 0,1%. Na ikiwa mapato ya huduma ni dola milioni 1 kwa mwaka, basi ongezeko la mapato ni $ 900. Ikiwa inatugharimu chini ya $900 kwa mwaka ili kuongeza uwezo wa kumudu kwa tisa, ongezeko hilo linaleta maana ya kifedha. Ikiwa inagharimu zaidi ya dola 900 kwa mwaka, haina maana tena, kwa sababu kuongezeka kwa mapato haitoi fidia kwa gharama za kazi, gharama za rasilimali. Na tisa 3 zitatosha kwetu.
Bila shaka huu ni mfano uliorahisishwa ambapo maombi yote ni sawa. Na kwenda kutoka tisa 3 hadi 4 ni rahisi kutosha, lakini wakati huo huo, kwa mfano, kutoka 2 nines hadi 3, hii tayari ni akiba ya dola elfu 9, inaweza kuwa na maana ya kifedha. Kwa kawaida, kwa kweli, kushindwa kwa ombi la usajili ni mbaya zaidi kuliko kushindwa kuonyesha ukurasa, maombi yana uzito tofauti. Wanaweza kuwa na kigezo tofauti kabisa kutoka kwa mtazamo wa biashara, lakini hata hivyo, kama sheria, ikiwa hatuzungumzi juu ya huduma fulani maalum, hii ni makadirio ya kuaminika.
Tulipokea swali ikiwa SRE ni mmoja wa waratibu wakati wa kuchagua suluhisho la usanifu wa huduma. Hebu tuseme katika suala la ushirikiano katika miundombinu iliyopo, ili hakuna hasara katika utulivu wake. Ndiyo, SREs, kwa njia sawa na maombi ya kuvuta, kufanya, kutolewa kuathiri usanifu, kuanzishwa kwa huduma mpya, microservices, utekelezaji wa ufumbuzi mpya. Kwa nini nilisema kabla uzoefu huo haujahitajika, sifa zinahitajika. Kwa kweli, SRE ni mojawapo ya sauti za kuzuia katika ufumbuzi wowote wa usanifu na programu. Ipasavyo, SRE kama mhandisi lazima, kwanza kabisa, sio tu kuelewa, lakini pia kuelewa jinsi maamuzi fulani maalum yataathiri kuegemea, utulivu, na kuelewa jinsi hii inahusiana na mahitaji ya biashara, na kutoka kwa mtazamo gani inaweza kukubalika na. ambayo sivyo.
Kwa hivyo, sasa tunaweza tu kuzungumza juu ya vigezo vya kuegemea, ambavyo kijadi hufafanuliwa katika SRE kama SLA (Mkataba wa Kiwango cha Huduma). Uwezekano mkubwa zaidi ni neno linalojulikana. SLI (Kiashiria cha Kiwango cha Huduma). SLO (Lengo la Kiwango cha Huduma). Makubaliano ya Kiwango cha Huduma labda ni neno la ishara, haswa ikiwa umefanya kazi na mitandao, na watoa huduma, na upangishaji. Haya ni makubaliano ya jumla ambayo yanaelezea utendakazi wa huduma yako yote, adhabu, baadhi ya adhabu kwa makosa, vipimo, vigezo. Na SLI ndio kipimo chenyewe cha upatikanaji. Hiyo ni, SLI inaweza kuwa nini: wakati wa kujibu kutoka kwa huduma, idadi ya makosa kama asilimia. Inaweza kuwa bandwidth ikiwa ni aina fulani ya mwenyeji wa faili. Linapokuja suala la algorithms ya utambuzi, kiashiria kinaweza kuwa, kwa mfano, hata usahihi wa jibu. SLO (Lengo la Kiwango cha Huduma) ni, kwa mtiririko huo, mchanganyiko wa kiashiria cha SLI, thamani yake na kipindi.
Wacha tuseme SLA inaweza kuwa kama hii. Huduma inapatikana kwa 99,95% ya muda kwa mwaka mzima. Au tiketi 99 muhimu za usaidizi zitafungwa ndani ya saa 3 kwa kila robo. Au 85% ya hoja zitapata majibu ndani ya sekunde 1,5 kila mwezi. Hiyo ni, hatua kwa hatua tunaelewa kuwa makosa na kushindwa ni kawaida kabisa. Hii ni hali inayokubalika, tunaipanga, hata tunaitegemea kwa kiasi fulani. Hiyo ni, SRE hujenga mifumo ambayo inaweza kufanya makosa, ambayo lazima ijibu kwa kawaida kwa makosa, ambayo lazima izingatiwe. Na wakati wowote inapowezekana, wanapaswa kushughulikia makosa kwa njia ambayo mtumiaji hata hawaoni, au taarifa, lakini kuna aina fulani ya kazi, shukrani ambayo kila kitu hakitaanguka kabisa.
Kwa mfano, ikiwa unapakia video kwenye YouTube, na YouTube haiwezi kuibadilisha mara moja, ikiwa video ni kubwa sana, ikiwa umbizo sio bora, basi ombi halitashindwa na kuisha kwa muda, YouTube haitatoa hitilafu 502. , YouTube itasema: βTumeunda kila kitu, video yako inachakatwa. Itakuwa tayari baada ya dakika 10." Hii ndiyo kanuni ya uharibifu wa neema, ambayo inajulikana, kwa mfano, kutoka kwa maendeleo ya mbele, ikiwa umewahi kufanya hivi.
Masharti yafuatayo ambayo tutazungumzia, ambayo ni muhimu sana kwa kufanya kazi kwa kuaminika, na makosa, na matarajio, ni MTBF na MTTR. MTBF ni muda wa wastani kati ya kushindwa. MTTR Inamaanisha Wakati wa Kuokoa, muda wa wastani wa kupona. Hiyo ni, ni muda gani umepita kutoka wakati kosa lilipogunduliwa, kutoka wakati kosa lilipoonekana hadi wakati huduma ilirejeshwa kwa operesheni kamili ya kawaida. MTBF hurekebishwa hasa na kazi ya ubora wa msimbo. Hiyo ni, ukweli kwamba SRE zinaweza kusema "hapana". Na unahitaji uelewa wa timu nzima kwamba SRE inaposema "hapana", anasema sio kwa sababu ana madhara, si kwa sababu yeye ni mbaya, lakini kwa sababu vinginevyo kila mtu atateseka.
Tena, kuna makala nyingi, mbinu nyingi, njia nyingi hata katika kitabu sana ambacho ninarejelea mara nyingi, jinsi ya kuhakikisha kwamba watengenezaji wengine hawaanza kuchukia SRE. MTTR, kwa upande mwingine, inahusu kufanyia kazi SLO zako (Lengo la Kiwango cha Huduma). Na zaidi ni automatisering. Kwa sababu, kwa mfano, SLO yetu ni nyongeza ya tisa kwa robo. Hii ina maana kwamba katika miezi 4 tunaweza kuruhusu dakika 3 za muda wa kupumzika. Na zinageuka kuwa MTTR haiwezi kuwa zaidi ya dakika 13. Ikiwa tutajibu angalau wakati 13 wa kupumzika katika dakika 13, hii inamaanisha kuwa tayari tumemaliza bajeti yote ya robo. Tunavunja SLO. Dakika 1 za kujibu na kurekebisha ajali ni nyingi kwa mashine, lakini ni fupi sana kwa binadamu. Kwa sababu mpaka mtu apate tahadhari, mpaka atakapofanya, mpaka aelewe kosa, tayari ni dakika kadhaa. Mpaka mtu anaelewa jinsi ya kurekebisha, nini hasa kurekebisha, nini cha kufanya, basi hii ni dakika chache zaidi. Na kwa kweli, hata ikiwa unahitaji tu kuanzisha tena seva, kama inavyogeuka, au kuinua nodi mpya, basi kwa mikono MTTR tayari ni kama dakika 13-7. Wakati wa kufanya mchakato kiotomatiki, MTTR mara nyingi hufikia sekunde, wakati mwingine milisekunde. Google kawaida huzungumza juu ya milliseconds, lakini kwa kweli, kwa kweli, kila kitu sio nzuri sana.
Kwa kweli, SRE inapaswa kubinafsisha kazi yake karibu kabisa, kwa sababu hii inathiri moja kwa moja MTTR, metriki zake, SLO ya huduma nzima, na, ipasavyo, faida ya biashara. Muda ukipitwa, tunaulizwa ikiwa SRE ina makosa. Kwa bahati nzuri, hakuna mtu wa kulaumiwa. Na hii ni tamaduni tofauti inayoitwa balmeless postmortem, ambayo hatutazungumza juu yake leo, lakini tutaichambua kwenye Slurm. Hii ni mada ya kuvutia sana ambayo inaweza kuzungumzwa sana. Takribani muda uliopangwa kwa robo umepitwa, basi kidogo kila mtu analaumiwa, maana yake ni kwamba kulaumu kila mtu hakuleti tija, badala yake, labda tusimlaumu mtu, bali turekebishe hali hiyo na tufanye kazi na tulichonacho. Kwa uzoefu wangu, mbinu hii ni ngeni kwa timu nyingi, haswa nchini Urusi, lakini inaeleweka na inafanya kazi vizuri sana. Kwa hiyo, nitapendekeza mwishoni mwa makala na maandiko ambayo unaweza kusoma juu ya mada hii. Au njoo kwenye Slurm SRE.
Hebu nielezee. Ikiwa wakati wa SLO kwa robo umezidi, ikiwa wakati wa kupumzika haukuwa dakika 13, lakini 15, ni nani anayeweza kulaumiwa kwa hili? Bila shaka, SRE inaweza kuwa na lawama, kwa sababu alifanya wazi aina fulani ya ahadi mbaya au kupelekwa. Msimamizi wa kituo cha data anaweza kuwa na lawama kwa hili, kwa sababu anaweza kuwa amefanya aina fulani ya matengenezo yasiyopangwa. Ikiwa msimamizi wa kituo cha data ana lawama kwa hili, basi mtu kutoka Ops ana lawama kwa hili, ambaye hakuhesabu matengenezo wakati aliratibu SLO. Meneja, mkurugenzi wa kiufundi au mtu ambaye alitia saini mkataba wa kituo cha data na hakuzingatia ukweli kwamba SLA ya kituo cha data haijaundwa kwa muda unaohitajika ni lawama kwa hili. Ipasavyo, wote hatua kwa hatua katika hali hii wana lawama. Na ina maana kwamba hakuna maana katika kuweka lawama kwa mtu yeyote katika hali hii. Lakini bila shaka inahitaji kusahihishwa. Ndio maana kuna postmortems. Na ikiwa unasoma, kwa mfano, GitHub postmortems, na hii daima ni hadithi ya kuvutia sana, ndogo na zisizotarajiwa katika kila kesi, unaweza kuchukua nafasi ya kwamba hakuna mtu aliyewahi kusema kwamba mtu huyu alikuwa na lawama. Lawama daima huwekwa kwenye michakato maalum isiyokamilika.
Hebu tuendelee na swali linalofuata. Otomatiki. Ninapozungumza juu ya otomatiki katika muktadha mwingine, mara nyingi mimi hurejelea jedwali ambalo hukuambia ni muda gani unaweza kufanya kazi ya kuhariri kazi kiotomatiki bila kuchukua muda zaidi kuibadilisha kiotomatiki kuliko vile unavyohifadhi. Kuna snag. Kukamata ni kwamba wakati SRE huendesha kazi otomatiki, sio tu kuokoa muda, huokoa pesa, kwa sababu otomatiki huathiri moja kwa moja MTTR. Wanaokoa, kwa kusema, ari ya wafanyikazi na watengenezaji, ambayo pia ni rasilimali inayoweza kumaliza. Wanapunguza utaratibu. Na yote haya yana athari nzuri juu ya kazi na, kwa sababu hiyo, kwenye biashara, hata ikiwa inaonekana kuwa automatisering haina maana kwa suala la gharama za wakati.
Kwa kweli, ina karibu kila mara, na kuna matukio machache sana ambapo kitu haipaswi kuwa automatiska katika jukumu la SRE. Ifuatayo tutazungumza juu ya kile kinachoitwa bajeti ya makosa, bajeti ya makosa. Kwa kweli, inageuka kwamba ikiwa kila kitu ni bora zaidi kwako kuliko SLO uliyojiwekea, hii pia si nzuri sana. Hii ni mbaya, kwa sababu SLO haifanyi kazi kama ya chini tu, bali pia kama njia ya juu inayokadiriwa. Unapojiwekea SLO ya upatikanaji wa 99%, na kwa kweli una 99,99%, zinageuka kuwa una nafasi fulani ya majaribio ambayo hayatadhuru biashara hata kidogo, kwa sababu wewe mwenyewe umeamua haya yote pamoja, na wewe ni. nafasi hii usitumie. Una bajeti ya makosa, ambayo katika kesi yako haitumiki.
Tunafanya nini nayo. Tunatumia kwa kila kitu halisi. Kwa ajili ya majaribio katika hali ya uzalishaji, kwa ajili ya kusambaza vipengele vipya vinavyoweza kuathiri utendaji, kwa matoleo, kwa matengenezo, kwa muda uliopangwa. Sheria ya kinyume inatumika pia: ikiwa bajeti imekamilika, hatuwezi kutoa chochote kipya, kwa sababu vinginevyo tutazidi SLO. Bajeti tayari imeisha, tumetoa kitu ikiwa inaathiri vibaya utendaji, yaani, ikiwa hii sio aina fulani ya kurekebisha ambayo yenyewe inaongeza SLO moja kwa moja, basi tunaenda zaidi ya bajeti, na hii ni hali mbaya. , inahitaji kuchambuliwa , postmortem, na ikiwezekana baadhi ya marekebisho ya mchakato.
Hiyo ni, zinageuka kuwa ikiwa huduma yenyewe haifanyi kazi vizuri, na SLO inatumiwa na bajeti haitumiki kwa majaribio, si kwa baadhi ya matoleo, lakini yenyewe, basi badala ya baadhi ya marekebisho ya kuvutia, badala ya vipengele vya kuvutia, badala ya matoleo ya kuvutia. Badala ya kazi yoyote ya ubunifu, itabidi ushughulikie marekebisho ya kijinga ili kurejesha bajeti kwa mpangilio, au kuhariri SLO, na huu pia ni mchakato ambao haupaswi kutokea mara nyingi.
Kwa hiyo, zinageuka kuwa katika hali ambapo tuna bajeti zaidi ya makosa, kila mtu ana nia: wote SRE na watengenezaji. Kwa wasanidi programu, bajeti kubwa ya hitilafu inamaanisha kuwa unaweza kukabiliana na matoleo, majaribio, majaribio. Kwa SREs, bajeti ya makosa na kuingia kwenye bajeti hiyo inamaanisha kuwa moja kwa moja wanafanya kazi yao vizuri. Na hii inathiri msukumo wa aina fulani ya kazi ya pamoja. Ukisikiliza SRE zako kama wasanidi, utakuwa na nafasi zaidi ya kufanya kazi nzuri na utaratibu mdogo zaidi.
Inabadilika kuwa majaribio katika uzalishaji ni muhimu sana na karibu sehemu muhimu ya SRE katika timu kubwa. Na kwa kawaida huitwa uhandisi wa machafuko, ambayo hutoka kwa timu ya Netflix ambayo ilitoa huduma inayoitwa Chaos Monkey.
Chaos Monkey huunganisha kwenye bomba la CI/CD na huharibu seva katika uzalishaji bila mpangilio. Tena, katika muundo wa SRE, tunazungumza juu ya ukweli kwamba seva iliyopungua sio mbaya yenyewe, inatarajiwa. Na ikiwa ni ndani ya bajeti, inakubalika na haidhuru biashara. Bila shaka, Netflix ina seva za kutosha za kutosha, replication ya kutosha, ili yote haya yaweze kurekebishwa, na ili mtumiaji kwa ujumla asitambue, na hata zaidi hakuna mtu anayeacha seva moja kwa bajeti yoyote.
Netflix ilikuwa na seti nzima ya huduma kama hizo kwa muda, moja ambayo, Chaos Gorilla, inazima kabisa moja ya Kanda za Upatikanaji za Amazon. Na vitu kama hivyo husaidia kufunua, kwanza, utegemezi uliofichwa, wakati haijulikani kabisa ni nini kinachoathiri nini, inategemea nini. Na hii, ikiwa unafanya kazi na microservice, na nyaraka sio kamili kabisa, hii inaweza kuwa ya kawaida kwako. Na tena, hii inasaidia sana kupata makosa katika msimbo ambao hauwezi kushika kwenye hatua, kwa sababu hatua yoyote sio simulizi halisi, kwa sababu ya ukweli kwamba kiwango cha mzigo ni tofauti, muundo wa mzigo ni tofauti, vifaa ni tofauti. pia, uwezekano mkubwa, nyingine. Mizigo ya kilele inaweza pia kuwa zisizotarajiwa na zisizotarajiwa. Na upimaji kama huo, ambao hauendi zaidi ya bajeti, husaidia vizuri kupata makosa katika miundombinu ambayo uwekaji, ukaguzi wa otomatiki, bomba la CI / CD halitawahi kupata. Na mradi yote yamejumuishwa kwenye bajeti yako, haijalishi huduma yako ilishuka hapo, ingawa ingeonekana kuwa ya kutisha sana, seva ilipungua, ni ndoto gani. Hapana, hiyo ni kawaida, hiyo ni nzuri, ambayo husaidia kupata mende. Ikiwa una bajeti, basi unaweza kuitumia.
Swali: Ni fasihi gani ninaweza kupendekeza? Orodha mwishoni. Kuna fasihi nyingi, nitashauri ripoti chache. Inafanyaje kazi, na SRE inafanya kazi katika makampuni bila bidhaa zao za programu au kwa maendeleo madogo. Kwa mfano, katika biashara ambapo shughuli kuu sio programu. Katika biashara, ambapo shughuli kuu sio programu, SRE inafanya kazi sawa na kila mahali pengine, kwa sababu katika biashara unahitaji pia kutumia, hata ikiwa haijatengenezwa, bidhaa za programu, unahitaji kusambaza sasisho, unahitaji kubadilisha. miundombinu, unahitaji kukua, unahitaji kuongeza kiwango. Na SRE husaidia kutambua na kutabiri matatizo yanayoweza kutokea katika michakato hii na kuyadhibiti baada ya ukuaji fulani kuanza na mahitaji ya biashara kubadilika. Kwa sababu sio lazima kabisa kuhusika katika ukuzaji wa programu ili kuwa na SRE ikiwa una seva chache na unatarajiwa kuwa na ukuaji angalau.
Vile vile huenda kwa miradi midogo, mashirika madogo, kwa sababu makampuni makubwa yana bajeti na nafasi ya majaribio. Lakini wakati huo huo, matunda haya yote ya majaribio yanaweza kutumika popote, yaani, SRE, bila shaka, ilionekana kwenye Google, katika Netflix, katika Dropbox. Lakini wakati huo huo, makampuni madogo na wanaoanza wanaweza tayari kusoma nyenzo zilizofupishwa, kusoma vitabu, ripoti za kutazama. Wanaanza kusikia juu yake mara nyingi zaidi, wanaangalia mifano maalum, nadhani ni sawa, inaweza kuwa muhimu sana, tunahitaji hii pia, ni nzuri.
Hiyo ni, kazi yote kuu ya kusawazisha michakato hii tayari imefanywa kwako. Inabakia kwako kuamua jukumu la SRE haswa katika kampuni yako na kuanza kutekeleza mazoea haya yote, ambayo, tena, tayari yameelezewa. Hiyo ni, kutoka kwa kanuni muhimu kwa makampuni madogo, hii daima ni ufafanuzi wa SLA, SLI, SLO. Ikiwa hushiriki katika programu, basi hizi zitakuwa SLA za ndani na SLO za ndani, bajeti ya ndani ya makosa. Hii karibu kila mara husababisha majadiliano ya kuvutia ndani ya timu na ndani ya biashara, kwa sababu inaweza kugeuka kuwa unatumia kwenye miundombinu, kwa aina fulani ya shirika la michakato bora, bomba bora ni zaidi ya lazima. Na hizi tisa 4 ulizo nazo katika idara ya IT, hauzihitaji sana sasa. Lakini wakati huo huo, unaweza kutumia muda, kutumia bajeti kwa makosa kwenye kitu kingine.
Kwa hiyo, ufuatiliaji na shirika la ufuatiliaji ni muhimu kwa kampuni ya ukubwa wowote. Na kwa ujumla, njia hii ya kufikiria, ambapo makosa ni kitu kinachokubalika, ambapo kuna bajeti, ambapo kuna Malengo, ni muhimu tena kwa kampuni ya ukubwa wowote, kuanzia mwanzo kwa watu 3.
Mwisho wa nuances ya kiufundi ya kuzungumza juu ni ufuatiliaji. Kwa sababu ikiwa tunazungumza kuhusu SLA, SLI, SLO, hatuwezi kuelewa bila kufuatilia ikiwa tunalingana na bajeti, kama tunazingatia Malengo yetu, na jinsi tunavyoathiri SLA ya mwisho. Nimeona mara nyingi kwamba ufuatiliaji hufanyika kama hii: kuna thamani fulani, kwa mfano, wakati wa ombi kwa seva, wakati wa wastani, au idadi ya maombi kwenye hifadhidata. Ana kiwango kilichoamuliwa na mhandisi. Ikiwa metric inapotoka kutoka kwa kawaida, basi barua pepe inakuja. Hii yote haina maana kabisa, kama sheria, kwa sababu inaongoza kwa tahadhari nyingi kama hizo, ujumbe mwingi kutoka kwa ufuatiliaji, wakati mtu, kwanza, lazima azifasiri kila wakati, ambayo ni, kuamua ikiwa thamani ya njia za metri. hitaji la hatua fulani. Na pili, yeye huacha tu kutambua tahadhari hizi zote, wakati kimsingi hakuna hatua inayohitajika kutoka kwake. Hiyo ni sheria nzuri ya ufuatiliaji na sheria ya kwanza kabisa SRE inapotekelezwa ni kwamba arifa inapaswa kuja tu wakati hatua inahitajika.
Katika kesi ya kawaida, kuna viwango 3 vya matukio. Kuna arifu, kuna tikiti, kuna kumbukumbu. Arifa ni kitu chochote kinachohitaji kuchukua hatua mara moja. Hiyo ni, kila kitu kimevunjika, unahitaji kurekebisha hivi sasa. Tikiti ndizo zinazohitaji hatua iliyochelewa. Ndiyo, unahitaji kufanya kitu, unahitaji kufanya kitu kwa manually, automatisering imeshindwa, lakini huna kufanya hivyo kwa dakika chache zifuatazo. Kumbukumbu ni kitu chochote kisichohitaji hatua, na kwa ujumla, ikiwa mambo yataenda vizuri, hakuna mtu atakayesoma. Utahitaji tu kusoma magogo wakati, kwa kuzingatia, ikawa kwamba kitu kilivunjika kwa muda fulani, hatukujua kuhusu hilo. Au unahitaji kufanya utafiti. Lakini kwa ujumla, kila kitu kisichohitaji hatua yoyote huenda kwenye magogo.
Kama athari ya haya yote, ikiwa tumefafanua ni matukio gani yanahitaji vitendo na tumeelezea vizuri vitendo hivi vinapaswa kuwa nini, hii inamaanisha kuwa kitendo kinaweza kujiendesha. Hiyo ni, nini kinatokea. Tunatoka kwa tahadhari. Twende kwenye hatua. Tunaenda kwa maelezo ya kitendo hiki. Na kisha tunaendelea na automatisering. Hiyo ni, automatisering yoyote huanza na majibu kwa tukio.
Kutoka kwa ufuatiliaji, tunahamia kwenye neno linaloitwa Kuzingatiwa. Pia kumekuwa na hype kidogo karibu na neno hili kwa miaka michache iliyopita. Na watu wachache wanaelewa maana yake nje ya muktadha. Lakini jambo kuu ni kwamba Kuzingatiwa ni kipimo cha uwazi wa mfumo. Ikiwa kitu kilienda vibaya, unaweza kuamua kwa haraka nini hasa kilienda vibaya na hali ya mfumo ilikuwa nini wakati huo. Kwa upande wa msimbo: ni kazi gani imeshindwa, ni huduma gani imeshindwa. Ni hali gani, kwa mfano, vigezo vya ndani, usanidi. Kwa upande wa miundombinu, hii ndio eneo la kupatikana ambapo kutofaulu kulitokea, na ikiwa una Kubernetes iliyosanikishwa, basi ni katika ganda gani kutofaulu kulitokea, hali ya pod ilikuwaje. Na ipasavyo, Kuzingatiwa kuna uhusiano wa moja kwa moja na MTTR. Ya juu ya Uangalizi wa huduma, ni rahisi kutambua kosa, ni rahisi zaidi kurekebisha kosa, ni rahisi zaidi kugeuza kosa, chini ya MTTR.
Kuhamia kwa makampuni madogo tena, ni kawaida sana kuuliza, hata sasa, jinsi ya kukabiliana na ukubwa wa timu, na ikiwa timu ndogo inahitaji kuajiri SRE tofauti. Tayari nilizungumza juu ya hii mapema kidogo. Katika hatua za kwanza za maendeleo ya mwanzo au, kwa mfano, timu, hii sio lazima kabisa, kwa sababu SRE inaweza kufanywa jukumu la mpito. Na hii itafufua timu kidogo, kwa sababu kuna angalau utofauti fulani. Na pamoja na itatayarisha watu kwa ukweli kwamba kwa ukuaji, kwa ujumla, majukumu ya SRE yatabadilika sana. Ikiwa unaajiri mtu, basi, bila shaka, ana matarajio fulani. Na matarajio haya hayatabadilika kwa muda, lakini mahitaji yatabadilika sana. Kwa hivyo, jinsi ya kuajiri SRE ni ngumu sana katika hatua za mwanzo. Kukua mwenyewe ni rahisi zaidi. Lakini inafaa kufikiria.
Isipokuwa tu, labda, ni wakati kuna mahitaji madhubuti na yaliyofafanuliwa vizuri ya ukuaji. Hiyo ni, katika kesi ya kuanza, hii inaweza kuwa aina fulani ya shinikizo kutoka kwa wawekezaji, aina fulani ya utabiri wa ukuaji mara kadhaa mara moja. Kisha kuajiri SRE kimsingi ni sawa kwa sababu inaweza kuhesabiwa haki. Tuna mahitaji ya ukuaji, tunahitaji mtu ambaye atawajibika kwa ukweli kwamba kwa ukuaji kama huo hakuna kitakachovunjika.
Swali moja zaidi. Nini cha kufanya wakati mara kadhaa watengenezaji hukata kipengele ambacho hupita vipimo, lakini huvunja uzalishaji, hupakia msingi, huvunja vipengele vingine, ni mchakato gani wa kutekeleza. Ipasavyo, katika kesi hii, ni bajeti ya makosa ambayo huletwa. Na baadhi ya huduma, baadhi ya vipengele tayari vinajaribiwa katika uzalishaji. Inaweza kuwa canary, wakati idadi ndogo tu ya watumiaji, lakini tayari katika uzalishaji, kipengele kinatumika, lakini tayari kwa matarajio kwamba ikiwa kitu kitavunjika, kwa mfano, kwa nusu ya asilimia ya watumiaji wote, bado itakutana na bajeti kwa makosa. Ipasavyo, ndio, kutakuwa na kosa, kwa watumiaji wengine kila kitu kitavunjika, lakini tayari tumesema kuwa hii ni kawaida.
Kulikuwa na swali kuhusu zana za SRE. Hiyo ni, kuna kitu haswa ambacho SRE zinaweza kutumia ambacho kila mtu mwingine hangetumia. Kwa kweli, kuna huduma maalum sana, kuna aina fulani ya programu ambayo, kwa mfano, inaiga mizigo au inajishughulisha na upimaji wa canary A / B. Lakini kimsingi zana ya zana ya SRE ndiyo ambayo watengenezaji wako tayari wanatumia. Kwa sababu SRE huingiliana moja kwa moja na timu ya ukuzaji. Na ikiwa una zana tofauti, itageuka kuwa inachukua muda kusawazisha. Hasa ikiwa SRE zinafanya kazi katika timu kubwa, katika kampuni kubwa ambapo kunaweza kuwa na timu kadhaa, ni viwango vya kampuni nzima ambavyo vitasaidia sana hapa, kwa sababu ikiwa huduma 50 tofauti zitatumika katika timu 50, hii inamaanisha kuwa SRE lazima iwajue. zote. Na bila shaka hii haitatokea kamwe. Na ubora wa kazi, ubora wa udhibiti wa angalau baadhi ya timu itapungua kwa kiasi kikubwa.
Mtandao wetu unakaribia mwisho. Nilifanikiwa kusema mambo ya msingi. Bila shaka, hakuna chochote kuhusu SRE kinachoweza kuambiwa na kueleweka kwa saa moja. Lakini natumai kuwa niliweza kufikisha njia hii ya kufikiria, mambo makuu muhimu. Na kisha itawezekana, ikiwa nia, kuingia kwenye mada, kujifunza peke yako, angalia jinsi inavyotekelezwa na watu wengine, katika makampuni mengine. Na ipasavyo, mapema Februari, njoo kwetu huko Slurm SRE.
Slurm SRE ni kozi ya siku tatu ya kina ambayo itazungumza juu ya kile ninazungumza sasa, lakini kwa kina zaidi, na kesi halisi, kwa mazoezi, kazi kubwa inalenga kazi ya vitendo. Watu watagawanywa katika timu. Nyote mtakuwa mnafanyia kazi kesi za kweli. Ipasavyo, tunao wakufunzi wa Booking.com Ivan Kruglov na Ben Tyler. Tuna Eugene Barabbas mzuri kutoka Google, kutoka San Francisco. Nami nitakuambia kitu pia. Kwa hivyo hakikisha unatutembelea.
Kwa hivyo, biblia. Kuna marejeleo kwenye SRE. kwenye kitabu kimoja, au tuseme kwenye vitabu 2 kuhusu SRE, vilivyoandikwa na Google. Mwingine , ambapo masharti na matumizi yao yana maelezo zaidi kidogo. 3 zinazofuata ni ripoti kuhusu SRE katika makampuni tofauti. Kwanza - , haya ni maelezo muhimu kutoka kwa Ben Trainer wa Google. Pili - . Ya tatu ni tena . Ripoti ya nne kutoka , ambayo ina wafanyakazi 5 pekee wa SRE katika nchi 190. Inafurahisha sana kutazama haya yote, kwa sababu kama vile DevOps inamaanisha vitu tofauti kwa kampuni tofauti na hata timu tofauti, SRE ina majukumu tofauti sana, hata katika kampuni za saizi zinazofanana.
Viungo 2 zaidi juu ya kanuni za uhandisi wa machafuko: , . Na mwisho kuna orodha 3 kutoka kwa safu ya Orodha za Ajabu kuhusu , kuhusu na kuhusu . Orodha kwenye SRE ni kubwa sana, sio lazima kupitia yote, kuna nakala 200 hivi. Ninapendekeza sana makala kutoka hapo kuhusu kupanga uwezo na kuhusu postmortem isiyo na hatia.
Nakala ya kuvutia:
Asante kwa kunisikiliza wakati huu wote. Natumai umejifunza kitu. Natumai una nyenzo za kutosha kujifunza zaidi. Na kukuona. Natumai mnamo Februari.
Mtandao huo uliandaliwa na Eduard Medvedev.
PS: kwa wale wanaopenda kusoma, Eduard alitoa orodha ya marejeleo. Wale ambao wanapendelea kuelewa katika mazoezi wanakaribishwa .
Chanzo: mapenzi.com