Kwa nini wahandisi hawajali ufuatiliaji wa programu?

Ijumaa njema nyote! Marafiki, leo tunaendelea na safu ya machapisho yaliyotolewa kwa kozi hiyo "Mazoea na zana za DevOps", kwa sababu masomo katika kikundi kipya cha kozi hiyo yataanza mwishoni mwa juma lijalo. Kwa hiyo, hebu tuanze!

Ufuatiliaji ni tu. Huu ni ukweli unaojulikana. Leta Nagios, endesha NRPE kwenye mfumo wa mbali, sanidi Nagios kwenye bandari ya NRPE TCP 5666 na una ufuatiliaji.

Ni rahisi sana haipendezi. Sasa una vipimo vya msingi vya wakati wa CPU, mfumo mdogo wa diski, RAM, iliyotolewa kwa chaguomsingi kwa Nagios na NRPE. Lakini hii sio "ufuatiliaji" kama hivyo. Huu ni mwanzo tu.

(Kawaida wao husakinisha PNP4Nagios, RRDtool na Thruk, huweka arifa katika Slack na kwenda moja kwa moja kwenye nagiosexchange, lakini tuache hiyo kwa sasa).

Ufuatiliaji mzuri kwa kweli ni changamano, unahitaji kweli kujua mambo ya ndani ya programu unayofuatilia.

Je, ufuatiliaji ni mgumu?

Seva yoyote, iwe Linux au Windows, kwa ufafanuzi itatumikia kusudi fulani. Apache, Samba, Tomcat, hifadhi ya faili, LDAP - huduma hizi zote ni za kipekee zaidi au chache kwa njia moja au zaidi. Kila mmoja ana kazi yake mwenyewe, sifa zake. Kuna njia tofauti za kupata vipimo, KPIs (viashiria muhimu vya utendakazi), ambavyo vinakuvutia wakati seva iko chini ya upakiaji.

Mwandishi wa picha Luke Chesser juu ya Unsplash

(Laiti dashibodi zangu zingekuwa neon blue - nikihema kwa ndoto -... hmm...)

Programu yoyote inayotoa huduma lazima iwe na utaratibu wa kukusanya vipimo. Apache ina moduli mod-status, kuonyesha ukurasa wa hali ya seva. Nginx ina - stub_status. Tomcat ina JMX au programu maalum za wavuti zinazoonyesha vipimo muhimu. MySQL ina amri "onyesha hali ya kimataifa" nk.
Kwa hivyo kwa nini watengenezaji hawatengenezi mifumo kama hiyo kwenye programu wanazounda?

Je, ni watengenezaji pekee wanaofanya hivi?

Kiwango fulani cha kutojali kwa upachikaji wa vipimo si tu kwa wasanidi programu. Nilifanya kazi katika kampuni ambapo walitengeneza programu kwa kutumia Tomcat na hawakutoa metrics zao wenyewe, hakuna kumbukumbu za shughuli za huduma, isipokuwa kumbukumbu za makosa ya jumla ya Tomcat. Wasanidi wengine hutengeneza kumbukumbu nyingi ambazo hazimaanishi chochote kwa msimamizi wa mfumo ambaye hakubahatika kuzisoma saa 3:15 asubuhi.

Mwandishi wa picha Tim Gouw juu ya Unsplash

Wahandisi wa mfumo ambao huwezesha bidhaa hizo kutolewa lazima pia kubeba jukumu fulani kwa hali hiyo. Wahandisi wachache wa mifumo wana muda au uangalifu wa kujaribu kutoa vipimo muhimu kutoka kwenye kumbukumbu, bila muktadha wa vipimo hivyo na uwezo wa kuvitafsiri kulingana na shughuli za programu. Wengine hawaelewi jinsi wanavyoweza kufaidika nayo, zaidi ya viashiria vya "kuna kitu kwa sasa (au kitakuwa) kibaya".

Mabadiliko katika fikra kuhusu hitaji la vipimo lazima yatokee sio tu kati ya wasanidi programu, lakini pia kati ya wahandisi wa mifumo.

Kwa mhandisi yeyote wa mifumo ambaye anahitaji sio tu kujibu matukio muhimu, lakini pia kuhakikisha kuwa hayatokei, ukosefu wa vipimo kawaida huwa kikwazo kufanya hivyo.

Hata hivyo, wahandisi wa mifumo kwa kawaida huwa hawachagui msimbo ili kupata pesa kwa kampuni yao. Wanahitaji wasanidi programu wakuu ambao wanaelewa umuhimu wa wajibu wa mhandisi wa mifumo katika kutambua matatizo, kuongeza ufahamu wa masuala ya utendaji na mengineyo.

Jambo hili linaumiza

Mtazamo wa devops unaelezea ushirikiano kati ya maendeleo (dev) na uendeshaji (ops) kufikiri. Kampuni yoyote inayodai "kufanya ibada" lazima:

1. kusema mambo ambayo labda hawafanyi (akirejelea The Princess Bibi meme - "Sidhani kama inamaanisha unachofikiria inamaanisha!")
2. Himiza mtazamo wa kuendelea kuboresha bidhaa.

Huwezi kuboresha bidhaa na kujua kwamba imeboreshwa ikiwa hujui jinsi inavyofanya kazi kwa sasa. Huwezi kujua jinsi bidhaa inavyofanya kazi ikiwa huelewi jinsi vipengele vyake vinavyofanya kazi, huduma ambazo hutegemea, pointi zake kuu za maumivu na vikwazo.
Ikiwa hutaangalia vikwazo vinavyowezekana, hutaweza kufuata mbinu ya Sababu Tano wakati wa kuandika Postmortem. Hutaweza kuweka kila kitu kwenye skrini moja ili kuona jinsi bidhaa inavyofanya kazi au kujua inaonekana kama "kawaida na furaha."

Shift kushoto, KUSHOTO, NIKASEMA LEEEE—

Kwangu, moja ya kanuni muhimu za Devops ni "kuhama kushoto". Shift kushoto katika muktadha huu inamaanisha kubadilisha uwezekano (hakuna jukumu, lakini uwezo pekee) kufanya mambo ambayo wahandisi wa mifumo hujali kwa kawaida, kama vile kuunda vipimo vya utendakazi, kutumia kumbukumbu kwa ufanisi zaidi, n.k., upande wa kushoto katika Mzunguko wa Maisha ya Uwasilishaji wa Programu.

Mwandishi wa picha NESA na Watunga juu ya Unsplash

Wasanidi programu lazima waweze kutumia na kujua zana za ufuatiliaji ambazo kampuni hutumia ili kutekeleza ufuatiliaji katika aina zake zote, vipimo, ukataji miti, violesura vya ufuatiliaji na, muhimu zaidi, angalia jinsi bidhaa zao zinavyofanya kazi katika uzalishaji. Huwezi kuwafanya wasanidi programu wawekeze juhudi na muda katika ufuatiliaji hadi waweze kuona vipimo na kuathiri jinsi wanavyoonekana, jinsi mmiliki wa bidhaa anavyowawasilisha kwa CTO katika muhtasari unaofuata, n.k.

Kwa kifupi akizungumza

1. Ongoza farasi wako kwenye maji. Onyesha wasanidi programu ni shida ngapi wanaweza kujiepusha, wasaidie kutambua KPI na vipimo sahihi vya programu zao ili kusiwe na kelele kutoka kwa mmiliki wa bidhaa ambaye anazomewa na CTO. Walete kwenye nuru, kwa upole na kwa utulivu. Hilo lisipofanya kazi, basi mpe hongo, tishie, na uwadanganye wao au mmiliki wa bidhaa kutekeleza kupata vipimo hivi kutoka kwa programu haraka iwezekanavyo, na kisha kuchora michoro. Hili litakuwa gumu kwani halitaonekana kama kipaumbele na ramani ya bidhaa itakuwa na miradi mingi ya kuzalisha mapato ambayo inasubiriwa. Kwa hivyo, utahitaji kesi ya biashara ili kuhalalisha wakati na gharama zilizotumika kutekeleza ufuatiliaji kwenye bidhaa.
2. Wasaidie wahandisi wa mfumo kupata usingizi mzuri. Waonyeshe kwamba kutumia orodha tiki ya "hebu tumwachie" kwa bidhaa yoyote inayotolewa ni jambo zuri. Na kuhakikisha kuwa programu zote katika toleo la umma zimefunikwa na vipimo kutakusaidia kulala vyema usiku kwa kuwaruhusu wasanidi programu kuona kinachoendelea na wapi. Hata hivyo, njia sahihi ya kuudhi na kukatisha tamaa msanidi programu yeyote, mmiliki wa bidhaa, au CTO ni kuendelea na kupinga. Tabia hii itaathiri tarehe ya kutolewa kwa bidhaa yoyote ukisubiri hadi dakika ya mwisho tena, kwa hivyo sogeza kushoto tena na uyaweke masuala haya kwenye mpango wa mradi wako haraka iwezekanavyo. Ikiwa ni lazima, fanya njia yako kwenye mikutano ya bidhaa. Kuvaa masharubu ya uwongo na kujisikia au kitu, haitashindwa kamwe. Zungumza mahangaiko yako, onyesha manufaa wazi, na uhubiri evanjeli.
3. Hakikisha kwamba usanidi (dev) na utendakazi (ops) zinaelewa maana na matokeo ya vipimo vya bidhaa kuhamia katika eneo nyekundu. Usiiache Ops kama mlezi pekee wa afya ya bidhaa, hakikisha watengenezaji wanahusika pia (#productsquads).
4. Kumbukumbu ni jambo nzuri, lakini pia metriki. Zichanganye na usiruhusu kumbukumbu zako ziwe takataka katika mpira mkubwa unaowaka wa ubatili. Eleza na uonyeshe watengenezaji kwa nini hakuna mtu mwingine atakayeelewa kumbukumbu zao, waonyeshe jinsi inavyopendeza kuangalia magogo yasiyo na maana saa 3:15 asubuhi.

Mwandishi wa picha Marko Horvat juu ya Unsplash

Ni hayo tu. Nyenzo mpya zitatolewa wiki ijayo. Ikiwa ungependa kujifunza zaidi kuhusu kozi hiyo, tunakualika Siku ya wazi, ambayo itafanyika Jumatatu. Na sasa sisi ni jadi kusubiri kwa maoni yako.

Chanzo: mapenzi.com