SRE (Uhandisi wa Kuegemea wa Tovuti) ni mbinu ya kufanya miradi ya wavuti kufikiwa. Inachukuliwa kuwa mfumo wa DevOps na inaelezea jinsi ya kufaulu katika utumiaji wa mazoea ya DevOps. Makala hii inatafsiri Sura ya 6 Ufuatiliaji Mifumo Inayosambazwa vitabu Uhandisi wa Kuegemea wa Tovuti kutoka Google. Nilitayarisha tafsiri hii mwenyewe na kutegemea uzoefu wangu mwenyewe katika kuelewa michakato ya ufuatiliaji. Katika chaneli ya telegraph @monitorim_it и blogi kwenye Medium Pia nilichapisha kiungo cha tafsiri ya Sura ya 4 ya kitabu hicho hicho kuhusu Malengo ya Ngazi ya Huduma.

Tafsiri ya paka. Furahia kusoma!

Timu za Google SRE zina kanuni za msingi na mbinu bora za kuunda mifumo yenye ufanisi ya ufuatiliaji na arifa. Sura hii inatoa mapendekezo kuhusu matatizo ambayo mtembeleaji wa ukurasa wa wavuti anaweza kukutana nayo na jinsi ya kutatua matatizo ambayo hufanya iwe vigumu kuonyesha kurasa za wavuti.

Ufafanuzi

Hakuna msamiati mmoja unaotumika kujadili mada zinazohusiana na ufuatiliaji. Hata kwenye Google, maneno hapa chini hayatumiki kwa kawaida, lakini tutaorodhesha tafsiri za kawaida.

Ufuatiliaji

Ukusanyaji, usindikaji, mkusanyiko na maonyesho ya data ya kiasi cha muda halisi kuhusu mfumo: idadi ya maombi na aina za maombi, idadi ya makosa na aina za makosa, wakati wa usindikaji wa ombi na uptime wa seva.

Ufuatiliaji wa sanduku nyeupe

Ufuatiliaji kulingana na vipimo vinavyoonyeshwa na wandani wa mfumo, ikiwa ni pamoja na kumbukumbu, vipimo vya wasifu vya JVM au kidhibiti cha HTTP ambacho hutoa takwimu za ndani.

Ufuatiliaji wa sanduku nyeusi

Kujaribu tabia ya programu kutoka kwa mtazamo wa mtumiaji.

Dashibodi (dashibodi)

Kiolesura (kawaida kiolesura cha wavuti) ambacho hutoa muhtasari wa viashirio muhimu vya afya vya huduma. Dashibodi inaweza kuwa na vichujio, uwezo wa kuchagua vipimo vya kuonyesha, na kadhalika. Kiolesura kimeundwa ili kutambua vipimo muhimu zaidi kwa watumiaji. Dashibodi pia inaweza kuonyesha taarifa kwa wafanyakazi wa usaidizi wa kiufundi: foleni ya ombi, orodha ya makosa yaliyopewa kipaumbele, mhandisi aliyekabidhiwa kwa eneo fulani la uwajibikaji.

Tahadhari (arifa)

Arifa zinazokusudiwa kupokelewa na mtu kwa barua pepe au vinginevyo, ambazo zinaweza kuanzishwa kutokana na makosa au ongezeko la foleni ya ombi. Arifa zimeainishwa kama: tiketi, arifa za barua pepe na ujumbe wa wajumbe.

Chanzo cha mizizi (sababu)

Kasoro ya programu au hitilafu ya kibinadamu ambayo, inaporekebishwa, haifai kutokea tena. Tatizo linaweza kuwa na sababu kadhaa kuu: automatisering ya kutosha ya mchakato, kasoro ya programu, utafiti wa kutosha wa mantiki ya maombi. Kila moja ya mambo haya inaweza kuwa sababu ya mizizi, na kila mmoja wao lazima aondolewa.

Nodi na mashine (nodi na mashine)

Masharti ya kubadilishana kurejelea mfano mmoja wa programu inayoendeshwa kwenye seva halisi, mashine pepe au kontena. Kunaweza kuwa na huduma kadhaa kwenye mashine moja. Huduma zinaweza kuwa:

• kuhusiana na kila mmoja: kwa mfano, seva ya cache na seva ya wavuti;
• huduma zisizohusiana kwenye maunzi sawa: kwa mfano, hazina ya msimbo na mchawi wa mfumo wa usanidi, kama vile Bomba au Chef.

Kushinikiza

Mabadiliko yoyote kwa usanidi wa programu.

Kwa nini ufuatiliaji unahitajika

Kuna sababu kadhaa kwa nini maombi yanapaswa kufuatiliwa:

Uchambuzi wa mwenendo wa muda mrefu

Je, hifadhidata ni kubwa kiasi gani na inakua kwa kasi gani? Je, idadi ya kila siku ya watumiaji inabadilikaje?

Ulinganisho wa Utendaji

Je, maswali yana kasi kwenye Acme Bucket ya Bytes 2.72 kuliko Ajax DB 3.14? Ni bora zaidi maombi yanahifadhiwa baada ya kuonekana kwa nodi ya ziada? Je, tovuti imekuwa polepole kuliko wiki iliyopita?

Tahadhari (arifa)

Kitu kimevunjika na mtu anapaswa kurekebisha. Au kitu kitavunjika hivi karibuni na mtu anapaswa kukiangalia hivi karibuni.

Kuunda dashibodi

Dashibodi zinapaswa kujibu maswali ya msingi na kujumuisha kitu kutoka "Ishara 4 za dhahabu" - ucheleweshaji (latency), trafiki (trafiki), makosa (makosa) na thamani ya mzigo (kueneza).

Kufanya uchanganuzi wa kutazama nyuma (utatuzi)

Muda wa kusubiri uchakataji uliongezeka, ni nini kingine kilifanyika karibu wakati huo huo?
Mifumo ya ufuatiliaji ni muhimu kama chanzo cha data kwa mifumo ya kijasusi ya biashara na kuwezesha uchanganuzi wa matukio ya usalama. Kwa kuwa kitabu hiki kinaangazia maeneo ya uhandisi ambayo SREs wana utaalamu, hatutajadili mbinu za ufuatiliaji hapa.

Ufuatiliaji na arifa huruhusu mfumo kusema wakati umekatika au unakaribia kukatika. Wakati mfumo hauwezi kujirekebisha kiotomatiki, tunataka mwanadamu kuchanganua arifa, atambue ikiwa tatizo bado lipo, kulitatua na kubaini chanzo chake. Usipokagua vipengele vya mfumo, hutawahi kupata arifa kwa sababu tu "kitu kinaonekana kuwa cha ajabu."

Kupakia arifa za kibinadamu ni matumizi ya gharama kubwa ya wakati wa mfanyakazi. Ikiwa mfanyakazi anafanya kazi, arifa hukatiza mtiririko wa kazi. Ikiwa mfanyakazi yuko nyumbani, tahadhari hukatiza wakati wa kibinafsi na uwezekano wa kulala. Arifa zinapotokea mara kwa mara, wafanyikazi hupuuza, huchelewesha, au hupuuza arifa zinazoingia. Mara kwa mara wao hupuuza tahadhari halisi, ambayo inafichwa na matukio ya kelele. Kukatizwa kwa huduma kunaweza kudumu kwa muda mrefu kwani matukio ya kelele huzuia utambuzi wa haraka wa shida na utatuzi. Mifumo ifaayo ya anwani za umma ina uwiano mzuri wa mawimbi kati ya kelele.

Kuamua matarajio yanayofaa kutoka kwa mfumo wa ufuatiliaji

Kuweka ufuatiliaji wa programu ngumu ni kazi ngumu ya uhandisi yenyewe. Hata ikiwa na miundombinu muhimu ya ukusanyaji, maonyesho na zana za arifa, timu ya Google SRE yenye wanachama 10-12 kwa kawaida hujumuisha mtu mmoja au wawili ambao madhumuni yao makuu ni kujenga na kudumisha mifumo ya ufuatiliaji. Idadi hii imepungua kadri muda unavyopita tunapojumlisha na kuweka msingi wa miundombinu ya ufuatiliaji, lakini kila timu ya SRE huwa na angalau mfanyakazi mmoja wa ufuatiliaji pekee. Ni lazima kusema kwamba ingawa inavutia sana kutazama dashibodi za mfumo wa ufuatiliaji, timu za SRE huepuka kwa uangalifu hali ambazo zinahitaji mtu kutazama skrini ili kufuatilia shida.

Kwa ujumla, Google imehamia kwenye mifumo rahisi na ya haraka ya ufuatiliaji yenye zana bora zaidi za uchanganuzi baada ya ukweli. Tunaepuka mifumo ya "uchawi" ambayo hujaribu kutabiri vizingiti au kugundua kiotomatiki chanzo. Sensorer zinazotambua maudhui yasiyotarajiwa katika maombi ya mtumiaji wa mwisho ni mfano pekee wa kupinga; muda mrefu kama sensorer hizi kubaki rahisi, wanaweza haraka kuchunguza sababu za anomalies kubwa. Miundo mingine ya kutumia data ya ufuatiliaji, kama vile kupanga uwezo au utabiri wa trafiki, ni changamoto zaidi. Uchunguzi wa muda mrefu sana (miezi au miaka) kwa kiwango cha chini cha sampuli (saa au siku) utaonyesha mwelekeo wa muda mrefu.

Timu ya Google SRE imeshughulikia madaraja changamano ya utegemezi kwa mafanikio mseto. Mara chache sisi hutumia sheria kama vile "nikigundua kuwa hifadhidata imekuwa polepole, napata arifa ya kushuka kwa hifadhidata, vinginevyo ninapata tahadhari ya tovuti polepole." Kanuni za utegemezi kwa kawaida hurejelea sehemu zisizobadilika za mfumo wetu, kama vile mfumo wa kuchuja trafiki ya watumiaji hadi kituo cha data. Kwa mfano, "ikiwa uchujaji wa trafiki wa kituo cha data umesanidiwa, usiniarifu kuhusu ucheleweshaji wa kuchakata maombi ya watumiaji" ni kanuni moja ya kawaida ya arifa za kituo cha data. Timu chache kwenye Google zinaauni madaraja changamano ya utegemezi kwa sababu miundombinu yetu ina kiwango cha kudumu cha urekebishaji upya.

Baadhi ya mawazo yaliyoainishwa katika sura hii bado yana ukweli: daima kuna njia ya kusonga haraka kutoka kwa dalili hadi kwa sababu ya mizizi, hasa katika mifumo inayobadilika kila wakati. Kwa hiyo, wakati sura hii inaelezea baadhi ya malengo ya mifumo ya ufuatiliaji na jinsi ya kufikia malengo hayo, ni muhimu mifumo ya ufuatiliaji iwe rahisi na inayoeleweka kwa kila mtu kwenye timu.

Vivyo hivyo, ili kuweka kiwango cha kelele chini na kiwango cha mawimbi juu, mbinu za ufuatiliaji wa vitu vinavyoonywa lazima ziwe rahisi sana na za kuaminika. Sheria zinazozalisha maonyo kwa wanadamu zinapaswa kuwa rahisi kuelewa na kuwasilisha shida iliyo wazi.

Dalili dhidi ya sababu

Mfumo wako wa ufuatiliaji unapaswa kujibu maswali mawili: "ni nini kimevunjika" na "kwa nini kimevunjwa".
"Nini kilichovunja" inahusu dalili, na "kwa nini kuvunja" inahusu sababu. Jedwali hapa chini linaonyesha mifano ya viungo kama hivyo.

Dalili
Kusababisha

Inapokea Hitilafu ya HTTP 500 au 404
Seva za hifadhidata zinakataa miunganisho

Majibu ya polepole ya seva
Matumizi ya Juu ya CPU au Kebo ya Ethaneti Iliyoharibika

Watumiaji katika Antaktika hawapati GIF za paka
CDN yako inachukia wanasayansi na paka, kwa hivyo baadhi ya IPs zimeorodheshwa

Maudhui ya faragha yanapatikana kila mahali
Kutoa toleo jipya la programu kulifanya ngome kusahau ACL zote na kuruhusu kila mtu aingie

"Nini" na "kwa nini" ni mojawapo ya vizuizi muhimu zaidi vya kujenga mfumo mzuri wa ufuatiliaji na ishara ya juu na kelele ya chini.

Sanduku Nyeusi dhidi ya Sanduku Nyeupe

Tunachanganya ufuatiliaji wa kina wa kisanduku cheupe na ufuatiliaji wa wastani wa kisanduku cheusi kwa vipimo muhimu. Njia rahisi zaidi ya kulinganisha Black-box na White-box ni kwamba Black-box inazingatia dalili na inafanya kazi badala ya ufuatiliaji makini: "mfumo haufanyi kazi ipasavyo kwa sasa." Sanduku nyeupe inategemea uwezo wa ukaguzi wa ndani wa mifumo: kumbukumbu za matukio au seva za wavuti. Kwa hivyo, Sanduku Nyeupe hukuruhusu kugundua shida zinazokuja, malfunctions ambayo yanaonekana kama uwasilishaji wa ombi, nk.

Kumbuka kuwa katika mfumo wa tabaka nyingi, dalili katika eneo la uwajibikaji wa mhandisi mmoja ni dalili katika eneo la uwajibikaji wa mhandisi mwingine. Kwa mfano, utendaji wa hifadhidata umepungua. Usomaji wa hifadhidata polepole ni dalili ya hifadhidata ya SRE inayozigundua. Walakini, kwa SRE ya mbele inayotazama tovuti polepole, sababu ya hifadhidata hiyo hiyo ya polepole kusoma ni kwamba hifadhidata ni polepole. Kwa hiyo, ufuatiliaji wa sanduku nyeupe wakati mwingine huzingatia dalili na wakati mwingine juu ya sababu, kulingana na jinsi ilivyo pana.

Wakati wa kukusanya telemetry kwa utatuzi, ufuatiliaji wa kisanduku Nyeupe unahitajika. Ikiwa seva za wavuti ni polepole kujibu maswali ya hifadhidata, unahitaji kujua kasi ya seva ya wavuti inawasiliana na hifadhidata na jinsi inavyojibu. Vinginevyo, hutaweza kutofautisha kati ya seva ya hifadhidata polepole na tatizo la mtandao kati ya seva ya wavuti na hifadhidata.

Ufuatiliaji wa kisanduku cheusi una faida kuu wakati wa kutuma arifa: unaanzisha arifa kwa mpokeaji wakati tatizo tayari limesababisha dalili halisi. Kwa upande mwingine, kwa tatizo la Black-box ambalo halijatokea, lakini ijayo, ufuatiliaji hauna maana.

Ishara nne za dhahabu

Ishara nne za ufuatiliaji wa dhahabu ni muda, trafiki, makosa, na kueneza. Iwapo unaweza kupima tu vipimo vinne vya mfumo wa mtumiaji, zingatia hizo nne.

Kuchelewa

Muda unaohitajika kushughulikia ombi. Ni muhimu kutofautisha kati ya muda wa kusubiri wa maombi yenye mafanikio na yasiyofanikiwa. Kwa mfano, hitilafu ya HTTP 500 inayosababishwa na uunganisho uliopotea kwenye hifadhidata au sehemu nyingine ya nyuma inaweza kutambuliwa haraka sana, hata hivyo, hitilafu ya HTTP 500 inaweza kuonyesha ombi lililoshindwa. Kutafuta athari za hitilafu 500 kwenye muda wa kusubiri kwa ujumla kunaweza kusababisha hitimisho potofu. Kwa upande mwingine, kosa polepole ni kosa la haraka! Kwa hivyo, ni muhimu kufuatilia ucheleweshaji wa makosa badala ya kuchuja tu makosa.

trafiki

Idadi ya maombi kwa mfumo wako, inayopimwa kwa vipimo vya mfumo wa kiwango cha juu. Kwa huduma ya wavuti, kipimo hiki kwa kawaida huwakilisha idadi ya maombi ya HTTP kwa sekunde ikigawanywa na asili ya maombi (kwa mfano, maudhui tuli au yanayobadilika). Kwa mfumo wa utiririshaji wa sauti, kipimo hiki kinaweza kulenga kiwango cha I/O cha mtandao au idadi ya vipindi vinavyofanana. Kwa mfumo wa hifadhi ya thamani kuu, kipimo hiki kinaweza kuwa miamala au utafutaji kwa sekunde.

Makosa

Hiki ni kiwango cha maombi yaliyofeli, ama kwa uwazi (kwa mfano, HTTP 500), kwa uwazi (kwa mfano, HTTP 200 lakini pamoja na maudhui mabaya), au kwa sera (kwa mfano, "Ukinasa jibu kwa sekunde moja, sekunde moja ni kosa"). Ikiwa hakuna misimbo ya majibu ya HTTP ya kutosha kueleza hali zote za kutofaulu, itifaki za upili (za ndani) zinaweza kuhitajika ili kugundua kutofaulu kwa sehemu. Kufuatilia maombi hayo yote yenye makosa kunaweza kusiwe na taarifa, ilhali majaribio ya mfumo wa mwisho hadi mwisho yanaweza kukusaidia kugundua kuwa unachakata maudhui yasiyo sahihi.

Jumamosi

Kipimo kinaonyesha jinsi huduma yako inavyotumika. Hiki ni kipimo cha ufuatiliaji wa mfumo ambacho kinatambua rasilimali ambazo ni chache zaidi (kwa mfano, katika mfumo na kumbukumbu ndogo, inaonyesha kumbukumbu, katika mfumo na I / O mdogo, inaonyesha idadi ya I / O). Kumbuka kuwa mifumo mingi huharibika kabla ya kufikia matumizi ya 100%, kwa hivyo kuwa na lengo la matumizi ni muhimu.

Katika mifumo changamano, kueneza kunaweza kuongezwa kwa kipimo cha kiwango cha juu cha mzigo: je, huduma yako inaweza kushughulikia trafiki mara mbili ipasavyo, kushughulikia trafiki 10% zaidi, au kushughulikia trafiki kidogo kuliko inavyoweza sasa? Kwa huduma rahisi ambazo hazina vigezo vinavyobadilisha utata wa ombi (k.m. "Usinipe chochote" au "Ninahitaji nambari kamili ya kipekee ya monotonic") ambayo mara chache hubadilisha usanidi, thamani ya mtihani wa upakiaji tuli inaweza kutosha. Hata hivyo, kama ilivyojadiliwa katika aya iliyotangulia, huduma nyingi zinapaswa kutumia mawimbi yasiyo ya moja kwa moja kama vile matumizi ya CPU au kipimo data cha mtandao ambacho kina kikomo cha juu kinachojulikana. Kuchelewa kuongezeka mara nyingi ni kiashiria kuu cha kueneza. Kupima muda wa majibu wa asilimia 99 kwenye dirisha dogo (km dakika moja) kunaweza kutoa ishara ya mapema sana ya kueneza.

Hatimaye, kueneza pia kunahusishwa na utabiri wa ujazo unaokuja, kama vile: "Inaonekana hifadhidata yako itajaza diski yako kuu ndani ya saa 4."

Ukipima ishara zote nne za dhahabu na kunapokuwa na tatizo na moja ya vipimo (au, ikiwa kueneza, karibu tatizo), unamjulisha mtu, huduma yako itafunikwa zaidi au chini ya ufuatiliaji.

Wasiwasi juu ya mkia (au ala na utendaji)

Wakati wa kuunda mfumo wa ufuatiliaji kutoka mwanzo, inajaribu kuunda mfumo kulingana na wastani: muda wa wastani wa kusubiri, wastani wa matumizi ya nodi ya CPU, au wastani wa umiliki wa hifadhidata. Hatari ya mifano miwili ya mwisho ni dhahiri: wasindikaji na hifadhidata hutupwa kwa njia isiyotabirika sana. Vile vile hutumika kwa kuchelewa. Ikiwa unatumia huduma ya wavuti yenye ukawiaji wa wastani wa 100ms kwa maombi 1000 kwa sekunde, 1% ya maombi inaweza kuchukua sekunde 5. Iwapo watumiaji wanategemea huduma nyingi kama hizi za wavuti, asilimia 99 ya mandharinyuma moja inaweza kwa urahisi kuwa muda wa majibu wa kiolesura cha wastani.

Njia rahisi zaidi ya kutofautisha kati ya wastani wa polepole na mkia wa polepole sana wa maombi ni kukusanya vipimo vya maombi yaliyoonyeshwa katika takwimu (histograms ni zana inayofaa ya kuonyesha), badala ya ucheleweshaji halisi: ni maombi mangapi yalitekelezwa na huduma iliyochukua. kati ya 0 ms na 10ms, kati ya 10ms na 30ms, kati ya 30ms na 100ms, kati ya 100ms na 300ms, nk. Kupanua mipaka ya histogram takriban kwa kasi (kwa kipengele cha takriban 3) mara nyingi ni njia rahisi ya kuibua usambazaji wa maombi.

Kuchagua granularity sahihi kwa vipimo

Vipengele tofauti vya mfumo vinapaswa kupimwa kwa viwango tofauti vya maelezo. Kwa mfano:

• Kutazama utumiaji wa CPU kwa muda hautaonyesha miisho mirefu ambayo husababisha kucheleweshwa kwa hali ya juu.
• Kwa upande mwingine, kwa huduma ya wavuti inayolenga si zaidi ya saa 9 za muda wa kupumzika kwa mwaka (saa ya ziada ya 99,9% ya kila mwaka), kuangalia jibu la HTTP 200 zaidi ya mara moja au mbili kwa dakika labda itakuwa mara kwa mara bila lazima.
• Vile vile, kuangalia kwa nafasi ya bure kwenye gari ngumu kwa upatikanaji wa 99,9% zaidi ya mara moja kila dakika 1-2 labda sio lazima.

Jihadharini jinsi unavyounda granularity ya vipimo. Kiwango cha matumizi ya CPU cha 1 kwa sekunde kinaweza kutoa data ya kuvutia, lakini vipimo hivyo vya mara kwa mara vinaweza kuwa ghali sana kukusanya, kuhifadhi na kuchanganua. Ikiwa lengo lako la ufuatiliaji linahitaji uzito wa juu na halihitaji uwajibikaji wa juu, unaweza kupunguza gharama hizi kwa kuweka mkusanyiko wa vipimo kwenye seva na kisha kusanidi mfumo wa nje wa kukusanya na kujumlisha vipimo hivyo. Unaweza:

1. Pima matumizi ya CPU kila sekunde.
2. Punguza maelezo hadi 5%.
3. Jumla ya vipimo kila dakika.

Mkakati huu utakuruhusu kukusanya data yenye punjepunje nyingi bila kupitia maelezo ya juu kwa uchanganuzi na uhifadhi.

Rahisi iwezekanavyo, lakini si rahisi

Kuweka mahitaji tofauti juu ya kila mmoja kunaweza kusababisha mfumo mgumu sana wa ufuatiliaji. Kwa mfano, mfumo wako unaweza kuwa na vipengele vifuatavyo vya kutatanisha:

• Arifa kulingana na viwango tofauti vya muda wa kusubiri, katika asilimia tofauti, katika kila aina ya vipimo tofauti.
• Kuandika msimbo wa ziada ili kugundua na kutambua sababu zinazowezekana.
• Unda dashibodi zinazohusiana kwa kila moja ya sababu zinazowezekana za matatizo.

Vyanzo vya matatizo yanayoweza kutokea haviisha. Kama mifumo yote ya programu, ufuatiliaji unaweza kuwa mgumu sana hivi kwamba inakuwa dhaifu, ngumu kubadilika na kudumisha.

Kwa hivyo, tengeneza mfumo wako wa ufuatiliaji ili kurahisisha iwezekanavyo. Wakati wa kuchagua cha kufuatilia, kumbuka yafuatayo:

• Sheria ambazo mara nyingi hushika matukio halisi zinapaswa kuwa rahisi, kutabirika, na kutegemewa iwezekanavyo.
• Mipangilio ya ukusanyaji wa data, ujumlishaji, na arifa ambayo hufanywa mara chache (kwa mfano, chini ya kila robo mwaka kwa baadhi ya timu za SRE) inapaswa kuondolewa.
• Vipimo vinavyokusanywa lakini havionyeshwi kwenye kidirisha chochote cha onyesho la kukagua au kutumiwa na arifa yoyote ni wagombeaji wa kufutwa.

Katika Google, mkusanyiko wa kimsingi na ujumlishaji wa vipimo, pamoja na arifa na dashibodi, hufanya kazi vizuri kama mfumo unaojitosheleza (mfumo wa ufuatiliaji wa Google kwa kweli umevunjwa katika mifumo midogo kadhaa, lakini kwa kawaida watu wanafahamu vipengele vyote vya mifumo hii ndogo). Inaweza kushawishi kuchanganya ufuatiliaji na mbinu nyingine za kupima mifumo changamano: uwekaji wasifu wa kina wa mfumo, utatuzi wa mchakato, ubaguzi wa kufuatilia au maelezo ya kushindwa, majaribio ya upakiaji, ukusanyaji wa kumbukumbu na uchanganuzi, au ukaguzi wa trafiki. Ingawa mengi ya mambo haya yanashiriki mambo ya kawaida na ufuatiliaji wa kimsingi, kuchanganya kutasababisha matokeo mengi na kuunda mfumo tata na brittle. Kama ilivyo kwa vipengele vingine vingi vya ukuzaji wa programu, kuunga mkono mifumo tofauti iliyo na vidokezo vya ujumuishaji vilivyo wazi, rahisi na vilivyounganishwa kwa urahisi ndio mkakati bora (kwa mfano, kutumia API ya wavuti kupata muhtasari wa data katika umbizo ambalo linaweza kubaki bila kubadilika kwa muda mrefu. )

Kuunganisha kanuni pamoja

Kanuni zilizojadiliwa katika sura hii zinaweza kuunganishwa kuwa falsafa ya ufuatiliaji na tahadhari ambayo imeidhinishwa na kufuatwa na timu za Google SRE. Kuzingatia falsafa hii ya ufuatiliaji ni jambo linalofaa, ni mwanzo mzuri wa kuunda au kusahihisha mbinu ya tahadhari, na kunaweza kukusaidia kuuliza maswali yanayofaa kwa utendakazi bila kujali ukubwa wa shirika lako au utata wa huduma au mfumo.

Wakati wa kuunda sheria za ufuatiliaji na tahadhari, kuuliza maswali yafuatayo kunaweza kukusaidia kuzuia chanya za uwongo na arifa zisizo za lazima:

• Je, sheria hii hutambua hali ya mfumo isiyoweza kutambulika ambayo ni ya dharura, wito wa kuchukua hatua, na kuathiri mtumiaji bila kuepukika?
• Ninaweza kupuuza onyo hili nikijua ni nzuri? Ni lini na kwa nini ninaweza kupuuza onyo hili na ninawezaje kuepuka hali hii?
• Je, arifa hii inamaanisha kuwa watumiaji wanaathiriwa vibaya? Je, kuna hali ambapo watumiaji hawaathiriwi vibaya, kwa mfano, kutokana na uchujaji wa trafiki au wakati wa kutumia mifumo ya majaribio, arifa ambazo zinapaswa kuchujwa?
• Je, ninaweza kuchukua hatua kujibu arifa hii? Je, hatua hizi ni za dharura au zinaweza kusubiri hadi asubuhi? Je, ni salama kugeuza kitendo kiotomatiki? Je, kitendo hiki kitakuwa suluhu la muda mrefu au suluhisho la muda mfupi?
• Watu wengine hupata arifa nyingi za suala hili, kwa hivyo inawezekana kupunguza idadi?

Maswali haya yanaonyesha falsafa ya kimsingi juu ya mifumo ya arifa na arifa:

• Kila wakati tahadhari inapoingia, lazima nijibu haraka. Ninaweza kukimbilia mara kadhaa kwa siku kabla sijachoka.
• Kila arifa lazima lisasishwe.
• Kila jibu kwa tahadhari lazima lihitaji uingiliaji kati wa binadamu. Ikiwa arifa inaweza kuchakatwa kiotomatiki, haipaswi kuja.
• Arifa zinapaswa kuwa kuhusu suala jipya au tukio ambalo halijafanyika hapo awali.

Mbinu hii inatia ukungu utofauti fulani: ikiwa arifa inakidhi masharti manne yaliyotangulia, haijalishi ikiwa arifa inatumwa kutoka kwa mfumo wa ufuatiliaji wa Sanduku Nyeupe au Black-Box. Mbinu hii pia inaimarisha tofauti fulani: ni bora kutumia juhudi zaidi katika kutambua dalili kuliko kwa sababu; linapokuja suala la sababu, unahitaji tu kuwa na wasiwasi juu ya sababu zisizoweza kuepukika.

Ufuatiliaji wa muda mrefu

Katika mazingira ya kisasa ya uzalishaji, mifumo ya ufuatiliaji hufuatilia mfumo wa uzalishaji unaobadilika kila wakati na usanifu wa programu unaobadilika, sifa za upakiaji na malengo ya utendaji. Tahadhari, ambazo kwa sasa ni vigumu kuziweka kiotomatiki, zinaweza kuwa za kawaida, pengine hata zinafaa kushughulikiwa. Katika hatua hii, mtu anapaswa kupata na kurekebisha sababu za msingi za tatizo; ikiwa azimio kama hilo haliwezekani, mwitikio wa tahadhari unahitaji otomatiki kamili.

Ni muhimu maamuzi ya ufuatiliaji yafanywe kwa kuzingatia malengo ya muda mrefu. Kila tahadhari inayoendelea leo huondoa mtu katika kuboresha mfumo kesho, hivyo mara nyingi kunakuwa na kupungua kwa upatikanaji au utendaji wa mfumo wa uzalishaji kwa muda unaochukua ili kuboresha mfumo wa ufuatiliaji kwa muda mrefu. Hebu tuangalie mifano miwili inayoonyesha jambo hili.

Bigtable SRE: Hadithi kuhusu tahadhari zaidi

Miundombinu ya ndani ya Google kwa kawaida hutolewa na kupimwa kulingana na Kiwango cha Huduma (SLO). Miaka iliyopita, SLO ya huduma ya Bigtable ilitokana na utendaji wa wastani wa shughuli ya sintetiki inayoiga mteja anayeendesha. Kutokana na matatizo katika Bigtable na viwango vya chini vya rafu ya hifadhi, wastani wa utendaji uliendeshwa na mkia "mkubwa": 5% mbaya zaidi ya hoja mara nyingi zilikuwa za polepole zaidi kuliko zingine.

Arifa za barua pepe zilitumwa kadri kiwango cha juu cha SLO kilivyofikiwa, na arifa za mjumbe zilitumwa wakati SLO ilipitwa. Aina zote mbili za arifa zilitumwa mara kwa mara, zikitumia muda usiokubalika wa muda wa uhandisi: timu ilitumia muda mwingi kuchanganua arifa ili kupata chache ambazo zilikuwa muhimu. Mara nyingi tulikosa suala ambalo liliathiri watumiaji kwa sababu ni arifa chache tu ndizo zilikuwa za suala hilo mahususi. Arifa nyingi hazikuwa za dharura kwa sababu ya maswala ya miundombinu yanayoeleweka na zilishughulikiwa kwa njia ya kawaida, au hazikushughulikiwa kabisa.

Ili kurekebisha hali hiyo, timu ilitumia mbinu yenye vipengele vitatu: huku tukifanya kazi kwa bidii ili kuboresha utendakazi wa Bigtable, tuliweka kwa muda asilimia ya 75 ya ucheleweshaji wa majibu ya hoja kama lengo letu la SLO. Pia tulizima arifa za barua pepe, kwa kuwa zilikuwa nyingi sana hivi kwamba haikuwezekana kupoteza muda kuzitambua.

Mkakati huu ulitusaidia kwa muda mfupi kuanza kurekebisha masuala ya muda mrefu katika Bigtable na safu za chini za rafu ya hifadhi, badala ya kurekebisha masuala ya kiufundi kila mara. Wahandisi wanaweza kufanya kazi hiyo wakati hawakupigwa na arifa kila wakati. Hatimaye, kuchelewa kwa muda katika kuchakata arifa kulituruhusu kuboresha ubora wa huduma.

Gmail: Majibu ya Kibinadamu ya Kutabirika, ya Algorithmic

Hapo mwanzo kabisa, Gmail iliundwa kwa kutumia mfumo wa udhibiti wa mchakato wa Foleni ya Kazi uliorekebishwa ambao uliundwa ili kubandika visehemu vya faharasa ya utafutaji. Foleni ya kazi ilichukuliwa kwa michakato ya muda mrefu na baadaye kutumika kwa Gmail, lakini baadhi ya hitilafu katika msimbo wa kipanga ratiba usio wazi zilionekana kuwa vigumu sana kurekebisha.

Wakati huo, ufuatiliaji wa Gmail uliundwa ili arifa zitokee wakati kazi mahususi zilighairiwa kwa kutumia Foleni ya Kazi. Mbinu hii haikuwa bora, kwa sababu hata wakati huo Gmail ilifanya maelfu ya kazi, ambayo kila moja ilipewa sehemu za asilimia ya watumiaji wetu. Tulichukua tahadhari kubwa kuhakikisha kuwa watumiaji wa Gmail wanapata matumizi mazuri ya mtumiaji, lakini kushughulikia arifa nyingi hakukuwa na swali.

Ili kutatua tatizo hili, Gmail SRE iliunda zana ya kusaidia kutatua kipanga ratiba vizuri iwezekanavyo ili kupunguza athari kwa watumiaji. Timu ilikuwa na mijadala kadhaa kuhusu kama kugeuza mzunguko mzima kiotomatiki kutoka kutafuta tatizo hadi kusuluhisha hadi suluhisho la muda mrefu lipatikane, lakini baadhi walikuwa na wasiwasi kuwa suluhisho kama hilo lingechelewesha utatuzi halisi wa tatizo.

Mvutano kama huo ulikuwa wa kawaida ndani ya timu na mara nyingi ulionyesha kutokujiamini: wakati baadhi ya washiriki wa timu wanataka kutoa muda wa kurekebisha vizuri, wengine wana wasiwasi kwamba marekebisho ya mwisho yatasahauliwa na marekebisho ya muda yatachukua milele. Tatizo hili linastahili kuzingatia, kwa kuwa ni rahisi sana kurekebisha matatizo kwa muda, badala ya kufanya marekebisho ya kudumu. Wasimamizi na wafanyakazi wa kiufundi wana jukumu muhimu katika utekelezaji wa marekebisho ya muda mrefu kwa kusaidia na kuweka kipaumbele uwezekano wa marekebisho ya muda mrefu hata wakati maumivu ya awali yanapungua.

Arifa za mara kwa mara na athari za algoriti zinapaswa kuwa alama nyekundu. Kutosita kwa timu yako kuweka arifa hizi kiotomatiki kunamaanisha kuwa timu haina imani kuwa inaweza kuamini kanuni za msingi. Hili ni tatizo kubwa linalohitaji kushughulikiwa.

Muda mrefu

Mandhari ya kawaida huunganisha mifano ya Bigtable na Gmail: ushindani kati ya upatikanaji wa muda mfupi na mrefu. Mara nyingi jitihada kali zinaweza kusaidia mfumo dhaifu kufikia upatikanaji wa juu, lakini njia hii ni ya muda mfupi, imejaa uchovu wa timu na utegemezi wa idadi ndogo ya wanachama wa timu hii ya kishujaa.

Kupungua kwa kudhibitiwa, kwa muda mfupi kwa upatikanaji mara nyingi ni chungu, lakini muhimu kimkakati kwa uthabiti wa muda mrefu wa mfumo. Ni muhimu kutozingatia kila tahadhari kwa kutengwa, lakini kuzingatia ikiwa kiwango cha jumla cha arifa husababisha mfumo mzuri, unaofikiwa vizuri na timu inayofaa na ubashiri mzuri. Tunachanganua takwimu za kiwango cha arifa (kwa kawaida huonyeshwa kama matukio kwa kila zamu, ambapo tukio linaweza kujumuisha matukio mengi yanayohusiana) katika ripoti za kila robo mwaka na wasimamizi, kuruhusu watoa maamuzi kuendelea kuwasilisha mzigo wa mfumo wa arifa na afya ya timu kwa ujumla.

Hitimisho

Njia ya ufuatiliaji wa afya na tahadhari ni rahisi na moja kwa moja. Inaangazia dalili za tatizo ambalo arifa hutolewa, na ufuatiliaji wa sababu hutumika kama msaada wa kutatua matatizo. Ufuatiliaji wa dalili ni rahisi kadiri ulivyo juu zaidi kwenye rafu unayodhibiti, ingawa upakiaji wa hifadhidata na ufuatiliaji wa utendaji unapaswa kufanywa moja kwa moja kwenye hifadhidata yenyewe. Arifa za barua pepe ni za matumizi machache sana na huelekea kuongezeka hadi kelele kwa urahisi; badala yake, unapaswa kutumia dashibodi inayofuatilia masuala yote ya sasa ambayo yanaarifiwa kwa barua pepe. Dashibodi pia inaweza kuoanishwa na kumbukumbu ya matukio ili kuchanganua uwiano wa kihistoria.

Kwa muda mrefu, ubadilishanaji uliofaulu kati ya arifa za dalili na matatizo halisi yanayokaribia unahitajika kufikiwa, na malengo yarekebishwe ili kuhakikisha kwamba ufuatiliaji unasaidia utambuzi wa haraka.

Asante kwa kusoma tafsiri hadi mwisho. Jiunge na chaneli yangu ya telegraph kuhusu ufuatiliaji @monitorim_it и blogi kwenye Medium.

Chanzo: mapenzi.com