Miks insenerid ei hooli rakenduste jälgimisest?

Headset kõigile! Sõbrad, täna jätkame koolituskursusele pühendatud postituste seeriat «DevOps praktikad ja tööriistad», sest uue grupi tunnid algavad juba järgmise nädala lõpus. Nii et alustame!

Jälgimine on lihtsalt. See on tuntud fakt. Käivitage Nagios, seadistage NRPE kaugsüsteemis, seadistage Nagios NRPE TCP pordile 5666 ja te ei ole enam jälgimata.

See on nii lihtne, et pole isegi huvitav. Nüüd on teil põhilised mõõdikud protsessori ajast, kettaalaste, mälust, mis tulevad vaikimisi Nagiosesse ja NRPEsse. Kuid tegelikult ei ole see „jälgimine” sellisel kujul. See on vaid algus.

(Tavaliselt installitakse PNP4Nagios, RRDtool ja Thruk, seadistatakse teavitused Slackis ja minnakse otse nagiosexchange'i, kuid jätame selle praegu kõrvale).

Hea jälgimine on tegelikult üsna keeruline, peate tõesti teadma rakenduse sisemust, mille üle te jälgite.

Kas jälgimine on keeruline?

Iga server, olgu see Linux või Windows, teenib definitsioonilt mingit eesmärki. Apache, Samba, Tomcat, failiserver, LDAP — kõik need teenused on millegipärast ainulaadsed ühes või mitmes aspektis. Igal teenusel on oma funktsioon ja omadused. On erinevaid viise mõõdikute, KPI-de (võtme efektiivsuse näitajate) hankimiseks, mis teile huvi pakuvad, kui server on koormuse all.

Pilt autor Luke Chesser . Tundub, et Unsplash

(tahaks, et mu armatuurlaud oleks värvitud neoon-sinisele — unistavalt sigh… hmmm…)

Igal teenusepakkujal, mis teenuseid pakub, peab olema mehanism mõõdikute kogumiseks. Apache'il on moodul mod-status, mis näitab serveri oleku lehte. Nginx'il on stub_status. Tomcat'il on JMX või spetsiaalsed veebirakendused, mis näitavad võtme mõõdikuid. MySQL'is on käsk „show global status“ jne.
Aga miks arendajad ei integreeri selliseid mehhanisme rakendustesse, mida nad loovad?

Kas ainult arendajad teevad seda?

Teatud määral ükskõiksus mõõdikute integreerimise osas ei piirdu ainult arendajatega. Olen töötanud ettevõtetes, kus arendati rakendusi Tomcat'i kasutades ja ei antud välja mingeid mõõdikuid, mingit teenuse tegevuse logi, välja arvatud Tomcat'i üldised tõrke logid. Teatud arendajad genereerivad külluslikult logisid, mis ei tähenda süsteemi administreerijale, kes peab neid kell 3:15 hommikul lugema, midagi.

Pilt autor Tim Gouw . Tundub, et Unsplash

Süsteemi insenerid, kes võimaldavad sellistel toodetel turule tulla, peavad samuti kandma teatud vastutust olukorra eest. Vähemalt mõned süsteemi insenerid ei leia aega ega tunne huvi tähenduslike mõõdikute saamiseks logidest, ilma konteksti ja võimaluseta neid tõlgendada rakenduse aktiivsuse valguses. Mõned ei saa aru, millist kasu nad sellest saavad, välja arvatud näitajad, mis näitavad, et "midagi on praegu (või peagi) valesti".

Mõtlemise muutmine mõõdikute vajalikkuse osas peaks toimuma mitte ainult arendajate, vaid ka süsteemi inseneride seas.

Iga süsteemi inseneri jaoks, kellele on vajalik mitte ainult reageerida kriitilistele sündmustele, vaid ka tagada nende puudumine, on mõõdikute puudumine tavaliselt tõkkeks.

Kuid süsteemi insenerid ei kaeva tavaliselt koodi, teenides oma ettevõttele raha. Neil on vaja juhtivaid arendajaid, kes mõistavad süsteemi inseneride vastutuse tähtsust probleemide avastamisel, probleemide teadlikkuse tõstmisel ja sarnastel teemadel.

See devops asi

Devops mentaliteet kirjeldab arendajate (dev) ja opereerimise (ops) mõtlemise sünergiat. Iga ettevõte, kes väidab, et nad "teevad devopsi", peaks:

1. ütlema seda, mida nad tõenäoliselt ei tee (viide filmi "Printsess-pruut" meemile - "Ma ei arva, et see tähendab seda, mida sa arvad, et see tähendab!")
2. soodustama pideva täiustamise positsiooni.

Te ei saa toodet täiustada ja teada, et see on paranenud, kui te ei tea, kuidas see praegu töötab. Te ei saa teada, kuidas toode töötab, kui te ei mõista, kuidas toimivad tema komponendid, teenused, millest ta sõltub, tema peamised probleemid ja kitsaskohad.
Kui te ei jälgi potentsiaalselt kitsaskohti, ei saa te järgida "Viie miks" tehnikat postmortemi kirjutamisel. Te ei saa koguda kõike ühele ekraanile, et näha, kuidas toode töötab või teada, kuidas see näeb välja "normaalselt ja õnnelikult".

Kallutamine vasakule, VASAKULE, MA KÄSIN, VAALEEEEEE—

Minu jaoks on üks Devopsi võtmeprintsiipidest "Kallutamine vasakule" (shift left). Kallutamine vasakule selles kontekstis tähendab võimaluse nihkumist (mitte vastutust, vaid mitte ainult võimaluste) teha seda, millest tavaliselt hoolivad süsteemiinsenerid, näiteks luua jõudluse mõõdikuid, kasutada logisid tõhusamalt jms, tarkvaraprogrammide kohaletoimetamise elutsükli (Software Delivery Life Cycle) alguses.

Pilt autor NESA by Makers . Tundub, et Unsplash

Tarkvaraarendajad peavad saama kasutada ja tundma ettevõtte jälgimise tööriistu, et realiseerida jälgimist kõikides selle vormides, mõõdikutena, logimisena, jälgimisliidestena ja, mis kõige tähtsam, vaatama, kuidas nende toode tootmises töötab. Te ei saa sundida arendajaid panustama aega ja energiat jälgimisse, kui nad ei näe mõõdikuid ja ei saa mõjutada, kuidas need välja näevad, kuidas toote omanik tutvustab neid järgmises infokogumisel CTO-le jms.

Lühidalt öeldes

1. Tooge hobune vette. Näidake arendajatele, kui palju probleeme nad saavad enda jaoks vältida, aidake neil tuvastada õiged KPI-d ja mõõdikud oma rakenduste jaoks, et vähendada toote omanikult tulevat karjumist, millele reageerib tehniline direktor (CTO). Tooge need valgusesse, õrnalt ja rahulikult. Kui see ei õnnestu, siis korruptseerige, ähvardage ja veenke kas neid või toote omaniku, et võimalikult kiiresti rakendada nende mõõdikute hankimist rakendustest, ja siis joonistage diagrammid. See on keeruline, kuna seda ei peeta prioriteetseks ning toote arengukaardil on palju ootel projekte, mis toovad tulu. Seetõttu vajate majandusuuringut, et õigustada aega ja vahendeid, mis kulutatakse jälgimise rakendamiseks tootes.
2. Aitäh süsteemiinseneritele korraliku une nimel. Näidake neile, et "väljalaskmis-checklisti" rakendamine igasuguste väljaantavate toodete puhul on hea. Ja see, et kõik tootmises olevad rakendused on mõõdikute kattega, aitab saavutada õiget und öösel, võimaldades arendajatel näha, mis ja kus ei tööta. Siiski on õige viis ärritada ja häirida iga arendajat, tooteomanikku ja tehnilist direktorit see, et takistada ja vastu seista. Selline käitumine mõjutab iga toote väljalaskekuupäeva, kui oodata jälle viimase minutini, seega viige jälle vasakule ja kaasake need küsimused projekti plaani niipea kui võimalik. Kui vaja, siseneda tooteüritustele. Kandke vale vuntse ja fetr või midagi sarnast, see ei petta kunagi. Teatage oma probleemidest, näidake ilmseid eeliseid ja propageerige.
3. Veenduge, et nii arendajad (dev) kui ka operatsioon (ops) mõistavad toote mõõdikute ülemineku "punasesse tsooni" tähendust ja tagajärgi. Ärge jätke operatsiooni ainukeseks toote töövõimekuse valvseks, veenduge, et arendajad osaleksid ka selles (#productsquads).
4. Logid on suurepärane asi, kuid mõõdikud ka. Koondage need ja ärge laske oma logidel muutuda prügi tohutuks, leegitsevaks kasutu palliks. Selgitage ja näidake arendajatele, miks keegi peale nende ei saa aru nende logidest, näidake neile, kuidas on näha kasutu logisid kella 3:15 hommikul.

Pilt autor Marko Horvat . Tundub, et Unsplash

Selleks on kõik. Uus materjal ilmub järgmisel nädalal. Kui soovite kursuse kohta rohkem teada, ootame teid avatud uste päev, mis toimub juba esmaspäeval. Ja praegu ootame traditsiooniliselt teie kommentaare.

Allikas: habr.com