ProHoster > Blogs > Administrācija > Kāpēc inženieriem nerūp lietojumprogrammu uzraudzība?

Kāpēc inženieriem nerūp lietojumprogrammu uzraudzība?

PriecÄ«gu piektdienu visiem! Draugi, Å”odien mēs turpinām kursam veltÄ«to publikāciju sēriju "DevOps prakse un rÄ«ki", jo nodarbÄ«bas jaunajā grupā kursam sāksies nākamās nedēļas beigās. Tātad, sāksim!

Kāpēc inženieriem nerūp lietojumprogrammu uzraudzība?

Uzraudzība ir tikko. Tas ir zināms fakts. Atveriet Nagios, palaidiet NRPE attālajā sistēmā, konfigurējiet Nagios NRPE TCP portā 5666, un jums ir pārraudzība.

Tas ir tik vienkārÅ”i, ka nav interesanti. Tagad jums ir pamata metrika par CPU laiku, diska apakÅ”sistēmu, operatÄ«vo atmiņu, kas pēc noklusējuma tiek nodroÅ”ināta Nagios un NRPE. Bet patiesÄ«bā tā nav ā€œuzraudzÄ«baā€ kā tāda. Å is ir tikai sākums.

(Parasti viņi instalē PNP4Nagios, RRDtool un Thruk, iestata paziņojumus Slack un dodas tieÅ”i uz nagiosexchange, taču pagaidām to atstāsim).

Laba uzraudzÄ«ba patiesÄ«bā ir diezgan sarežģīts, jums patieŔām ir jāzina uzraugāmās lietojumprogrammas iekŔējās Ä«paŔības.

Vai uzraudzība ir sarežģīta?

JebkurÅ” serveris, neatkarÄ«gi no tā, vai tas ir Linux vai Windows, pēc definÄ«cijas kalpos kādam mērÄ·im. Apache, Samba, Tomcat, failu krātuve, LDAP ā€“ visi Å”ie pakalpojumi ir vairāk vai mazāk unikāli vienā vai vairākos aspektos. Katram ir sava funkcija, savas Ä«paŔības. Ir dažādi veidi, kā iegÅ«t metriku, KPI (galvenos veiktspējas rādÄ«tājus), kas jums ir interesanti, kad serveris ir noslogots.

Kāpēc inženieriem nerūp lietojumprogrammu uzraudzība?
Fotogrāfijas autors Lūks Šahers par Unsplash

(Es vēlos, lai mani informācijas paneļi bÅ«tu neona zilā krāsā ā€” sapņaini nopÅ«Å”as ā€”... hmm...)

Jebkurai programmatūrai, kas nodroŔina pakalpojumus, ir jābūt mehānismam datu vākŔanai. Apache ir modulis mod-status, parāda servera statusa lapu. Nginx ir - stub_status. Tomcat ir JMX vai pielāgotas tīmekļa lietojumprogrammas, kas parāda galvenos rādītājus. MySQL ir komanda "show global status" utt.
Tātad, kāpēc izstrādātāji savās lietojumprogrammās neiebūvē līdzīgus mehānismus?

Vai to dara tikai izstrādātāji?

Zināma lÄ«meņa vienaldzÄ«ba pret metrikas iegulÅ”anu attiecas ne tikai uz izstrādātājiem. Es strādāju uzņēmumos, kur viņi izstrādāja lietojumprogrammas, izmantojot Tomcat, un nesniedzu nekādus savus rādÄ«tājus, pakalpojumu darbÄ«bas žurnālus, izņemot vispārÄ«gos Tomcat kļūdu žurnālus. Daži izstrādātāji Ä£enerē daudz žurnālu, kas neko nenozÄ«mē sistēmas administratoram, kuram nav paveicies tos izlasÄ«t pulksten 3:15 no rÄ«ta.

Kāpēc inženieriem nerūp lietojumprogrammu uzraudzība?
Fotogrāfijas autors Tims Gouw par Unsplash

Sistēmas inženieriem, kas nodroÅ”ina Ŕādu produktu izlaiÅ”anu, arÄ« ir jāuzņemas zināma atbildÄ«ba par situāciju. Tikai dažiem sistēmu inženieriem ir laiks vai rÅ«pes, lai mēģinātu no žurnāliem iegÅ«t jēgpilnu metriku bez Å”o metrikas konteksta un iespējas tos interpretēt, ņemot vērā lietojumprogrammu darbÄ«bas. Daži nesaprot, kādu labumu no tā var gÅ«t, izņemot rādÄ«tājus "kaut kas paÅ”laik nav (vai drÄ«zumā bÅ«s) nepareizi".

DomāŔanas maiņai par metriku nepiecieÅ”amÄ«bu ir jānotiek ne tikai izstrādātāju, bet arÄ« sistēmu inženieru vidÅ«.

Ikvienam sistēmu inženierim, kuram ir ne tikai jāreaģē uz kritiskiem notikumiem, bet arÄ« jānodroÅ”ina, lai tie nenotiktu, metrikas trÅ«kums parasti ir Ŕķērslis to darÄ«t.

Tomēr sistēmu inženieri parasti nestrādā ar kodu, lai pelnÄ«tu naudu savam uzņēmumam. Viņiem ir nepiecieÅ”ami vadoÅ”ie izstrādātāji, kas saprot sistēmu inženiera atbildÄ«bas nozÄ«mi problēmu identificÄ“Å”anā, izpratnes veicināŔanā par veiktspējas problēmām un tamlÄ«dzÄ«gi.

Å Ä« devops lieta

Devops mentalitāte apraksta sinerÄ£iju starp attÄ«stÄ«bas (dev) un operāciju (ops) domāŔanu. Jebkuram uzņēmumam, kas apgalvo, ka veic devops, ir:

  1. saka lietas, ko viņi, iespējams, nedara (atsaucoties uz The Princess Bride mēmu ā€” "Es nedomāju, ka tas nozÄ«mē to, ko jÅ«s domājat!")
  2. Veicināt attieksmi pret nepārtrauktu produktu uzlaboŔanu.

Jūs nevarat uzlabot produktu un zināt, ka tas ir uzlabots, ja nezināt, kā tas paŔlaik darbojas. Jūs nevarat zināt, kā produkts darbojas, ja nesaprotat, kā darbojas tā sastāvdaļas, pakalpojumi, no kuriem tas ir atkarīgs, tā galvenās sāpju vietas un vājās vietas.
Ja jūs neuzmanīsit iespējamās vājās vietas, rakstot pēcnāves grāmatu, jūs nevarēsit ievērot Five Whys tehniku. Jūs nevarēsiet visu ievietot vienā ekrānā, lai redzētu, kā produkts darbojas, vai zināt, kā tas izskatās "parasts un laimīgs".

Pārslēdziet pa kreisi, pa kreisi, es teicu Lī...

Man viens no galvenajiem Devops principiem ir ā€œnobÄ«de pa kreisiā€. PārbÄ«de pa kreisi Å”ajā kontekstā nozÄ«mē iespēju mainÄ«t (nekādas atbildÄ«bas, bet tikai iespējas), lai veiktu darbÄ«bas, kas parasti rÅ«p sistēmu inženieriem, piemēram, izveidot veiktspējas rādÄ«tājus, efektÄ«vāk izmantot žurnālus utt., kas atrodas programmatÅ«ras piegādes dzÄ«ves cikla kreisajā pusē.

Kāpēc inženieriem nerūp lietojumprogrammu uzraudzība?
Fotogrāfijas autors Makernieku NESA par Unsplash

ProgrammatÅ«ras izstrādātājiem ir jāspēj izmantot un zināt uzraudzÄ«bas rÄ«kus, ko uzņēmums izmanto, lai veiktu uzraudzÄ«bu visos tā veidos, metrikā, reÄ£istrÄ“Å”anā, uzraudzÄ«bas saskarnēs un, pats galvenais, skatÄ«ties, kā viņu produkts darbojas ražoÅ”anā. JÅ«s nevarat likt izstrādātājiem ieguldÄ«t pÅ«les un laiku uzraudzÄ«bā, kamēr viņi nevar redzēt rādÄ«tājus un ietekmēt to izskatu, kā produkta Ä«paÅ”nieks tos iepazÄ«stina ar CTO nākamajā instruktāžā utt.

ÄŖsāk sakot

  1. Pieved zirgu pie Å«dens. Parādiet izstrādātājiem, cik daudz problēmu viņi paÅ”i var izvairÄ«ties, palÄ«dziet viņiem noteikt pareizos KPI un metriku savām lietojumprogrammām, lai mazāk bļautu no produkta Ä«paÅ”nieka, uz kuru kliedz CTO. Viegli un mierÄ«gi izvediet tos gaismā. Ja tas nedarbojas, uzpirkt, draudēt un mudināt viņus vai produkta Ä«paÅ”nieku, lai tie pēc iespējas ātrāk ieviestu Å”os rādÄ«tājus no lietojumprogrammām, un pēc tam uzzÄ«mējiet diagrammas. Tas bÅ«s sarežģīti, jo tas netiks uzskatÄ«ts par prioritāti, un produktu ceļvedÄ« bÅ«s daudz nepabeigtu projektu, kas rada ieņēmumus. Tāpēc jums bÅ«s nepiecieÅ”ams biznesa gadÄ«jums, lai pamatotu laiku un izdevumus, kas pavadÄ«ti, ievieÅ”ot uzraudzÄ«bu produktā.
  2. PalÄ«dziet sistēmu inženieriem labi izgulēties. Parādiet viņiem, ka kontrolsaraksta ā€œatlaidÄ«simā€ izmantoÅ”ana jebkuram izlaistajam produktam ir laba lieta. Un pārliecinoties, ka visas ražoÅ”anas lietojumprogrammas ir pārklātas ar metriku, jÅ«s varēsiet labāk gulēt naktÄ«, ļaujot izstrādātājiem redzēt, kas un kur notiek nepareizi. Tomēr pareizais veids, kā kairināt un nomākt jebkuru izstrādātāju, produkta Ä«paÅ”nieku vai CTO, ir pastāvēt un pretoties. Å Ä« darbÄ«ba ietekmēs jebkura produkta izlaiÅ”anas datumu, ja atkal gaidÄ«sit lÄ«dz pēdējai minÅ«tei, tāpēc atkal pārvietojiet pa kreisi un pēc iespējas ātrāk iekļaujiet Ŕīs problēmas savā projekta plānā. Ja nepiecieÅ”ams, dodieties uz produktu sanāksmēm. Valkājiet viltotas Å«sas un filcu vai kaut ko citu, tas nekad neizdosies. Paziņojiet par savām bažām, parādiet skaidrus ieguvumus un sludiniet evaņģelizāciju.
  3. NodroŔiniet, lai gan izstrāde (izstrādātājs), gan operācijas (operācijas) saprastu produktu metrikas nozīmi un sekas, kas nonāk sarkanajā zonā. Neatstājiet Ops kā vienīgo produktu veselības sargu, pārliecinieties, ka ir iesaistīti arī izstrādātāji (#productsquads).
  4. Baļķi ir lieliska lieta, taču tā ir arÄ« metrika. Apvienojiet tos un neļaujiet saviem baļķiem kļūt par atkritumiem milzÄ«gā liesmojoŔā bezjēdzÄ«bas bumbā. Izskaidrojiet un parādiet izstrādātājiem, kāpēc neviens cits nesapratÄ«s viņu žurnālus, parādiet, kā ir skatÄ«ties uz nederÄ«giem žurnāliem pulksten 3:15 no rÄ«ta.

Kāpēc inženieriem nerūp lietojumprogrammu uzraudzība?
Fotogrāfijas autors Marko Horvats par Unsplash

Tas ir viss. Nākamnedēļ tiks izdots jauns materiāls. Ja vēlaties uzzināt vairāk par kursu, mēs aicinām jūs uz to Atvērto durvju diena, kas notiks pirmdien. Un tagad mēs tradicionāli gaidām jūsu komentārus.

Avots: www.habr.com

Pievieno komentāru