Miks insenerid ei huvitu rakenduste jälgimisest?

Head reedet! Sõbrad, täna jätkame oma postituste seeriat kursusest „DevOps praktikas ja tööriistades“, kuna uue grupi tunnid algavad juba järgmisel nädalal. Nii et alustame!

Jälgimine on lihtne. See on tuntud fakt. Käivitage Nagios, käitage NRPE eemaloleval süsteemil, seadistage Nagios NRPE TCP pordile 5666 ja teil on jälgimine.

See on nii lihtne, et see pole huvitav. Nüüd on teil põhimetriigid, nagu protsessori aeg, diskiallikas ja mälu, mis tulevad vaikimisi Nagiosesse ja NRPEsse. Kuid tegelikult ei ole see «jälgimine» niivõrd. See on vaid algus.

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

Hea jälgimine on tegelikult üsna keeruline, peate tõeliselt teadma rakenduse siseelundeid, mida te jälgite.

Kas jälgimine on keeruline?

Iga server, olgu see Linux või Windows, teenib kindlat eesmärki. Apache, Samba, Tomcat, failisüsteem, LDAP — kõik need teenused on ühes või mitmes aspektis ainulaadsed. Igal neist on oma funktsioon ja omadused. Serveri koormuse all saadud mõõdikute ja KPI-de (võtmemõõdikud) hankimiseks on erinevaid võimalusi.

Foto autor Luke Chesser järgnevaga Unsplash

(sooviks, et mu juhtpaneelid oleksid värvitud neooni siniseks — unistavalt ohates —… hmm…)

Iga teenuseid pakkuv tarkvara peab omama mehhanismi mõõdikute kogumiseks. Apachil on moodul mod-status, mis kuvab serveri oleku lehte. Nginx-il on stub_status. Tomcatil on JMX või spetsiaalsed veebirakendused, mis näitavad võtmemõõdikuid. MySQL-is on käsk „show global status“ jne.
Miks siis arendajad ei integreeri selliseid mehhanisme rakendustesse, mida nad loovad?

Kas seda teevad ainult arendajad?

Mõistetav ükskõiksuse tase mõõdikute integreerimise osas ei piirdu ainult arendajatega. Olen töötanud ettevõtetes, kus arendati rakendusi Tomcatiga, kuid ei jagatud mingeid oma mõõdikuid ega teenuse aktiivsuse logisid, välja arvatud Tomcati üldised vealogid. Mõned arendajad genereerivad hulgaliselt logisid, mis ei tähenda süsteemiadministraatori jaoks midagi, kes peab nende lugemisega tegelema kell 3:15 hommikul.

Foto autor Tim Gouw järgnevaga Unsplash

Süsteeminsenerid, kes lubavad sellistel toodetel versioonile minna, peaksid samuti kandma teatud vastutust olukorra eest. Väga vähestel süsteeminseneridel on aega ja nad ei püüa midagi olulist logidest välja võtta, ilma et neil oleks konteksti nende mõõdikute jaoks või võimalust neid tõlgendada rakenduse tegevuse valguses. Mõned ei saa aru, millist kasu nad sellest saavad, välja arvatud teavet nagu 'midagi on praegu (või peagi) valesti'.

Mõtlemise muutmine seoses mõõdikute vajalikusega peaks toimuma mitte ainult arendajate seas, vaid ka süsteeminseneride seas.

Iga süsteemiinsener, kellele on vajalik mitte ainult reageerida kriitilistele sündmustele, vaid ka tagada nende puudumine, seisab tavaliselt silmitses mõõdikute puudumisega.

Kuid süsteemiinsenerid ei süvene tavaliselt koodisse, teenides raha oma ettevõtte jaoks. Neil on vaja juhtivaid arendajaid, kes mõistavad süsteemiinseneri vastutuse tähtsust probleemide avastamisel, jõudluse probleemide teadlikkuse tõstmisel ja muus.

See devops asi

Devops mentaliteet kirjeldab arendajate (dev) ja ekspluateerimise (ops) mõtlemise sünergiat. Iga ettevõtte kohta, kes väidab, et nad „teevad devopsi”, peab olema:

1. ütlema, et nad tõenäoliselt ei tee (viide filmi „Printsess-Immer” memele — „Ma ei arva, et see tähendab seda, mida sa arvad, et see tähendab!”)
2. soodustama pideva toote täiustamise hoiakut.

Te ei saa toodet täiustada ja teada, et see oli täiustatud, kui sa ei tea, kuidas see praegu töötab. Sa ei suuda aru saada, kuidas toode töötab, kui sa ei mõista, kuidas töötavad selle komponentid, teenused, millest see sõltub, ja selle peamised valupunktid ja kitsaskohad.
Kui sa ei jälgi võimalikke kitsaskohti, ei saa sa kasutada „Viit miks” tehnikat postmortem’i kirjutamisel. Sa ei suuda kõike ühel ekraanil kokku koguda, et näha, kuidas toode töötab või teada saada, kuidas see näeb välja „normaalsena ja õnnelikult”.

Liiguta vasakule, VASAKULE, MA ÜTLESIN, AAAAAAAA—

Minu jaoks on DevOpsi üks peamisi põhimõtteid „Liigutamine vasakule” (shift left). Liigutamine vasakule selle konteksti tähenduses tähendab võimaluse nihutamist (mitte vastutuse, vaid ainult võimaluse) teha seda, mille pärast hoolivad tavaliselt süsteemiinsenerid, näiteks luua jõudluse mõõdikuid, kasutada logisid tõhusamalt jne, vasakule tarkvara kohaletoimetamise elutsükli (Software Delivery Life Cycle) jooksul.

Foto autor NESA by Makers järgnevaga Unsplash

Tarkvaraarendajatel peab olema võimalus kasutada ja mõista neid jälgimisvahendeid, mida ettevõte kasutab, et jälgida kõiki seda tüüpi tegevusi, metrikate, logimise, jälgimisliideste ja, mis kõige tähtsam, vaadata, kuidas nende toode tootmises töötab. Te ei saa sundida arendajaid panustama aega ja ressursse jälgimisele, kui nad ei näe meetrikasid ja ei saa mõjutada, kuidas need välja näevad, kuidas toote omanik esitab need CTO-le järgmise koosoleku ajal jne.

Lühidalt

1. Viige hobune vee äärele. Näidake arendajatele, kui palju probleeme nad saaksid vältida, aidake neil välja tuua õiged KPI-d ja mõõdikud oma rakenduste jaoks, et vähendada toote omaniku kriitikat, kellele tehniline direktor (CTO) karjub. Viige nad valgusesse, õrnalt ja rahulikult. Kui see ei õnnestu, siis mahi neid, ähvardage ja veenke kas neid või toote omanikku, et need mõõdikud rakendustest nii kiiresti kui võimalik kätte saada ja joonistage siis diagrammid. See osutub keeruliseks, kuna see ei ole prioriteediks ja toote teekaardil on palju ootavaid projekte, mis toovad tulu. Seetõttu vajate majanduslikku õigustust, et põhjendada aega ja ressursse, mis kulutatakse jälgimise integreerimisele tootesse.
2. Aita süsteemiinseneritel hästi magada. Näidake neile, et 'väljalaskmise kontrollnimekirja' kasutamine iga väljastatava toote jaoks on positiivne. Samuti aitab see, et kõik tootmises olevad rakendused on katsetatud mõõdikute abil, tagada rahulik uni öösel, võimaldades arendajatel näha, mis ja kus ei tööta. Siiski on vale viis iga arendaja, tootjavastutaja ja tehnilise juhataja ärritamiseks ja häirimiseks pidevalt rattad kinni panna ja vastu seista. Selline käitumine mõjutab toote väljaandmise kuupäeva, kui oodata taas viimase minutini, seega tehke uuesti vasakule nihke ja lisage need küsimused võimalikult kiiresti projekti plaani. Kui vajalik, varjake end toote kohtumistel. Kandke vale vuntsi ja fetr, see ei petta kunagi. Tehke oma probleemidest teadlik, näidake selgeid eeliseid ja evangeliseerige.
3. Veenduge, et nii arendajad (dev) kui ka tootmine (ops) mõistavad, mida tähendab ja millised on tagajärjed toote mõõdikute sisenemisel "punasesse tsooni". Ärge jätke tootmist ainukeseks toote töökindluse valvamiseks, veenduge, et arendajad osalevad selles samuti (#productsquads).
4. Logid on suurepärased, kuid mõõdikud samuti. Ühendage need ja ärge laske oma logidel muutuda prügilaks tohutul tulel, mis on täis kasulikke. Selgitage ja näidake arendajatele, miks keegi peale nende ei suuda nende logisid lugeda, näidake neile, milline see on, kui vaadata kasutut logi kell 3:15 hommikul.

Foto autor Marko Horvat järgnevaga Unsplash

Sellega 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 nüüd ootame traditsiooniliselt teie kommentaare.

Allikas: habr.com