Sretan petak svima! Prijatelji, danas nastavljamo seriju publikacija posvećenih tečaju , jer nastava u novoj grupi za tečaj počinje krajem sljedećeg tjedna. Dakle, počnimo!
Praćenje je samo. Ovo je poznata činjenica. Pokrenite Nagios, pokrenite NRPE na udaljenom sustavu, konfigurirajte Nagios na NRPE TCP portu 5666 i imate nadzor.
Toliko je lako da nije zanimljivo. Sada imate osnovne metrike za CPU vrijeme, diskovni podsustav, RAM, koji se prema zadanim postavkama isporučuju Nagios-u i NRPE-u. Ali to zapravo nije "monitoring" kao takav. Ovo je tek početak.
(Obično instaliraju PNP4Nagios, RRDtool i Thruk, postave obavijesti u Slacku i odu ravno na nagiosexchange, ali ostavimo to za sada).
Dobar nadzor je zapravo prilično složen, stvarno morate znati unutrašnjost aplikacije koju nadzirete.
Je li praćenje teško?
Svaki poslužitelj, bio on Linux ili Windows, po definiciji će služiti nekoj svrsi. Apache, Samba, Tomcat, pohrana datoteka, LDAP - sve ove usluge su više ili manje jedinstvene u jednom ili više pogleda. Svaki ima svoju funkciju, svoje karakteristike. Postoje različiti načini za dobivanje metrike, KPI-ja (ključnih indikatora performansi), koji su vam zanimljivi kada je poslužitelj pod opterećenjem.
Autor fotografije na
(Volio bih da su moje ploče s instrumentima neonsko plave - sneno uzdahne -... hmm...)
Svaki softver koji pruža usluge mora imati mehanizam za prikupljanje metrike. Apache ima modul mod-status, prikazujući stranicu statusa poslužitelja. Nginx ima - stub_status. Tomcat ima JMX ili prilagođene web aplikacije koje prikazuju ključne metrike. MySQL ima naredbu "prikaži globalni status" itd.
Pa zašto programeri ne ugrade slične mehanizme u aplikacije koje stvaraju?
Rade li to samo programeri?
Određena razina ravnodušnosti prema ugrađivanju metrike nije ograničena na programere. Radio sam u tvrtkama u kojima su razvijali aplikacije koristeći Tomcat i nisu pružali nikakvu vlastitu metriku, niti dnevnike aktivnosti usluge, osim općih dnevnika grešaka Tomcata. Neki programeri generiraju mnogo zapisa koji ne znače ništa administratoru sustava koji nema sreće da ih pročita u 3:15 ujutro.
Autor fotografije na
Sistemski inženjeri koji omogućuju puštanje takvih proizvoda također moraju snositi dio odgovornosti za situaciju. Nekoliko sistemskih inženjera ima vremena ili brige pokušati izvući smislene metrike iz zapisa, bez konteksta tih metrika i mogućnosti njihovog tumačenja u svjetlu aktivnosti aplikacije. Neki ne razumiju kako mogu imati koristi od toga, osim pokazatelja "nešto trenutno (ili će uskoro biti) pogrešno".
Promjena u razmišljanju o potrebi za metrikom mora se dogoditi ne samo među programerima, već i među sistemskim inženjerima.
Za svakog inženjera sustava koji treba ne samo reagirati na kritične događaje, već i osigurati da se oni ne dogode, nedostatak metrike obično predstavlja prepreku u tome.
Međutim, sistemski inženjeri obično ne petljaju s kodom kako bi zaradili novac za svoju tvrtku. Oni trebaju vodeće programere koji razumiju važnost odgovornosti inženjera sustava u identificiranju problema, podizanju svijesti o problemima performansi i slično.
Ovo devops stvar
Devops mentalitet opisuje sinergiju između razmišljanja o razvoju (dev) i operacijama (ops). Svaka tvrtka koja tvrdi da "radi devops" mora:
- govoreći stvari koje vjerojatno ne govore (odnosi se na meme Princess Bride - "Mislim da to ne znači ono što ti misliš da znači!")
- Potaknite stav stalnog poboljšanja proizvoda.
Ne možete poboljšati proizvod i znati da je poboljšan ako ne znate kako trenutno radi. Ne možete znati kako proizvod radi ako ne razumijete kako rade njegove komponente, usluge o kojima ovisi, njegove glavne bolne točke i uska grla.
Ako ne pazite na potencijalna uska grla, nećete moći slijediti tehniku Pet zašto kada pišete postmortem. Nećete moći staviti sve na jedan zaslon da vidite kako proizvod radi ili znate kako izgleda "normalno i sretno".
Pomak ulijevo, ULJEVO, REKAO SAM LEEEE—
Za mene je jedan od ključnih principa Devopsa “pomak ulijevo”. Pomak ulijevo u ovom kontekstu znači pomicanje mogućnosti (nema odgovornosti, ali samo sposobnosti) za obavljanje stvari do kojih je sistemskim inženjerima obično stalo, kao što je stvaranje metrike performansi, učinkovitija upotreba zapisa itd., lijevo u životnom ciklusu isporuke softvera.
Autor fotografije na
Programeri softvera moraju biti u mogućnosti koristiti i poznavati alate za praćenje koje tvrtka koristi kako bi izvršili praćenje u svim njegovim oblicima, metrikama, zapisima, sučeljima za praćenje i, što je najvažnije, gledati kako njihov proizvod radi u proizvodnji. Ne možete natjerati programere da ulažu trud i vrijeme u praćenje dok ne vide metriku i utječu na to kako izgledaju, kako ih vlasnik proizvoda predstavlja CTO-u na sljedećem brifingu, itd.
Ukratko
- Vodi svog konja do vode. Pokažite programerima koliko problema mogu sami izbjeći, pomozite im identificirati prave KPI-ove i metrike za svoje aplikacije tako da vlasnik proizvoda na kojeg viče CTO manje viče. Iznesite ih na svjetlo, nježno i smireno. Ako to ne uspije, podmitite, zaprijetite i nagovorite bilo njih ili vlasnika proizvoda da implementiraju dobivanje tih metrika iz aplikacija što je brže moguće, a zatim nacrtajte dijagrame. To će biti teško jer se neće smatrati prioritetom, a plan proizvoda će sadržavati mnoge projekte koji generiraju prihod na čekanju. Stoga će vam trebati poslovni slučaj da opravdate vrijeme i troškove utrošene na implementaciju praćenja u proizvod.
- Pomozite sistemskim inženjerima da se dobro naspavaju. Pokažite im da je korištenje kontrolnog popisa "pustimo" za svaki proizvod koji se izdaje dobra stvar. A osiguravanje da su sve aplikacije u proizvodnji pokrivene mjernim podacima pomoći će vam da bolje spavate noću dopuštajući razvojnim programerima da vide što ide krivo i gdje. Međutim, pravi način iritiranja i frustracije bilo kojeg programera, vlasnika proizvoda ili tehničkog direktora jest ustrajati i odupirati se. Ovo će ponašanje utjecati na datum izdavanja bilo kojeg proizvoda ako ponovno čekate zadnji trenutak, pa ponovno pomaknite ulijevo i uključite te probleme u svoj plan projekta što je prije moguće. Ako je potrebno, idite na sastanke o proizvodima. Nosite lažne brkove i filc ili tako nešto, nikad neće uspjeti. Izrazite svoje brige, pokažite jasne prednosti i evangelizirajte.
- Osigurajte da i razvoj (dev) i operacije (ops) razumiju značenje i posljedice prelaska metrike proizvoda u crvenu zonu. Ne ostavljajte Ops kao jedinog čuvara ispravnosti proizvoda, pobrinite se da i programeri budu uključeni (#productsquads).
- Dnevnici su sjajna stvar, ali i metrika. Kombinirajte ih i ne dopustite da vaša cjepanica postane smeće u ogromnoj plamenoj kugli beskorisnosti. Objasnite i pokažite programerima zašto nitko drugi neće razumjeti njihove zapise, pokažite im kako je to gledati beskorisne zapise u 3:15 ujutro.
Autor fotografije na
To je sve. Novi materijal bit će objavljen sljedeći tjedan. Ukoliko želite saznati više o tečaju, pozivamo Vas da , koji će se održati u ponedjeljak. A sada već tradicionalno čekamo vaše komentare.
Izvor: www.habr.com