Lep petek vsem! Prijatelji, danes nadaljujemo serijo publikacij, posvečenih tečaju , saj se pouk v novi skupini za tečaj začne konec naslednjega tedna. Torej, začnimo!
Spremljanje je samo. To je znano dejstvo. Prikličite Nagios, zaženite NRPE na oddaljenem sistemu, konfigurirajte Nagios na vratih NRPE TCP 5666 in imate nadzor.
Tako enostavno je, da ni zanimivo. Zdaj imate osnovne meritve za čas procesorja, diskovni podsistem, RAM, ki so privzeto na voljo Nagios in NRPE. Vendar to dejansko ni "nadzor" kot tak. To je šele začetek.
(Običajno namestijo PNP4Nagios, RRDtool in Thruk, nastavijo obvestila v Slacku in gredo naravnost na nagiosexchange, a pustimo to za zdaj).
Dobro spremljanje je pravzaprav precej zapleteno, res morate poznati notranjost aplikacije, ki jo spremljate.
Ali je spremljanje težko?
Vsak strežnik, naj bo to Linux ali Windows, bo po definiciji služil nekemu namenu. Apache, Samba, Tomcat, shranjevanje datotek, LDAP - vse te storitve so bolj ali manj edinstvene v enem ali več pogledih. Vsak ima svojo funkcijo, svoje značilnosti. Obstajajo različni načini, kako pridobiti metrike, KPI (ključne kazalnike uspešnosti), ki so za vas zanimivi, ko je strežnik obremenjen.
Avtor fotografije o
(Želim si, da bi bile moje armaturne plošče neonsko modre - zasanjano vzdihnem - ... hmm ...)
Vsaka programska oprema, ki ponuja storitve, mora imeti mehanizem za zbiranje meritev. Apache ima modul mod-status, ki prikazuje stran s statusom strežnika. Nginx ima - stub_status. Tomcat ima JMX ali spletne aplikacije po meri, ki prikazujejo ključne meritve. MySQL ima ukaz "prikaži globalni status" itd.
Zakaj torej razvijalci ne vgradijo podobnih mehanizmov v aplikacije, ki jih ustvarijo?
Ali to počnejo samo razvijalci?
Določena raven brezbrižnosti do vdelave metrik ni omejena na razvijalce. Delal sem v podjetjih, kjer so razvijali aplikacije z uporabo Tomcata in niso zagotovili nobenih lastnih meritev, nobenih dnevnikov storitev, razen splošnih dnevnikov napak Tomcat. Nekateri razvijalci ustvarijo veliko dnevnikov, ki sistemskemu skrbniku, ki nima sreče, da bi jih prebral ob 3:15 zjutraj, ne pomenijo nič.
Avtor fotografije o
Del odgovornosti za nastalo situacijo morajo nositi tudi sistemski inženirji, ki omogočajo izdajo takih izdelkov. Le malo sistemskih inženirjev ima čas ali skrb, da bi poskušali izvleči pomembne meritve iz dnevnikov, brez konteksta teh meritev in zmožnosti njihove interpretacije v luči dejavnosti aplikacije. Nekateri ne razumejo, kako lahko koristijo od tega, razen indikatorjev "trenutno (ali bo kmalu) nekaj narobe".
Sprememba v razmišljanju glede potrebe po meritvah se mora zgoditi ne le med razvijalci, ampak tudi med sistemskimi inženirji.
Za vsakega sistemskega inženirja, ki se mora ne le odzvati na kritične dogodke, ampak tudi zagotoviti, da do njih ne pride, je pomanjkanje meritev običajno ovira pri tem.
Vendar se sistemski inženirji običajno ne ukvarjajo s kodo, da bi zaslužili denar za svoje podjetje. Potrebujejo vodilne razvijalce, ki razumejo pomen odgovornosti sistemskega inženirja pri prepoznavanju težav, ozaveščanju o težavah z zmogljivostjo in podobno.
Ta devops stvar
Miselnost devops opisuje sinergijo med razmišljanjem o razvoju (dev) in operacijah (ops). Vsako podjetje, ki trdi, da "dela devops", mora:
- govoriti stvari, ki jih verjetno ne (sklicevanje na meme Princess Bride - "Mislim, da to ne pomeni, kar misliš, da pomeni!")
- Spodbujajte odnos do nenehnega izboljševanja izdelkov.
Ne morete izboljšati izdelka in vedeti, da je bil izboljšan, če ne veste, kako trenutno deluje. Ne morete vedeti, kako izdelek deluje, če ne razumete, kako delujejo njegove komponente, storitev, od katerih je odvisen, njegovih glavnih težav in ozkih grl.
Če ne boste pozorni na morebitna ozka grla, pri pisanju Postmortema ne boste mogli slediti tehniki petih zakaj. Vsega ne boste mogli postaviti na en zaslon, da bi videli, kako izdelek deluje, ali vedeli, kako je videti kot »normalno in srečno«.
Premik levo, LEVO, REKEL sem LEEEE—
Zame je eno ključnih načel Devopsa »premik v levo«. Premik levo v tem kontekstu pomeni premik možnosti (brez odgovornosti, ampak le zmožnosti) za opravljanje stvari, ki običajno zanimajo sistemske inženirje, na primer ustvarjanje meritev zmogljivosti, učinkovitejša uporaba dnevnikov itd., na levi v življenjskem ciklu dostave programske opreme.
Avtor fotografije o
Razvijalci programske opreme morajo biti sposobni uporabljati in poznati orodja za spremljanje, ki jih podjetje uporablja za izvajanje spremljanja v vseh njegovih oblikah, meritvah, beleženju, vmesnikih za spremljanje in, kar je najpomembnejše, opazujte, kako njihov izdelek deluje v proizvodnji. Ne morete pripraviti razvijalcev, da vložijo trud in čas v spremljanje, dokler ne vidijo meritev in vplivajo na njihov videz, na to, kako jih lastnik izdelka predstavi tehničnemu direktorju na naslednjem sestanku itd.
Skratka
- Pelji svojega konja do vode. Pokažite razvijalcem, koliko težav se lahko sami izognejo, pomagajte jim prepoznati prave KPI-je in meritve za njihove aplikacije, tako da bo manj vpitja lastnika izdelka, na katerega vpije tehnični direktor. Pripeljite jih na svetlobo, nežno in mirno. Če to ne deluje, potem podkupite, zagrozite in nagovarjajte bodisi njih bodisi lastnika izdelka, da čim prej izvedete pridobivanje teh meritev iz aplikacij, nato pa narišite diagrame. To bo težko, saj ne bo obravnavano kot prednostna naloga, načrt izdelka pa bo vseboval veliko projektov, ki ustvarjajo prihodek. Zato boste potrebovali poslovni primer, da upravičite čas in stroške, porabljene za implementacijo nadzora v izdelek.
- Pomagajte sistemskim inženirjem pri dobrem spancu. Pokažite jim, da je uporaba kontrolnega seznama »izdajmo« za vsak izdelek, ki se izda, dobra stvar. Zagotavljanje, da so vse aplikacije v proizvodnji pokrite z meritvami, vam bo pomagalo bolje spati ponoči, saj bo razvijalcem omogočilo, da vidijo, kaj gre narobe in kje. Vendar pa je pravi način, da razdražite in frustrirate katerega koli razvijalca, lastnika izdelka ali tehničnega direktorja, vztrajanje in upiranje. To vedenje bo vplivalo na datum izdaje katerega koli izdelka, če boste spet čakali do zadnje minute, zato znova premaknite levo in te težave čim prej vključite v svoj načrt projekta. Po potrebi se odpravite na sestanke o izdelkih. Nosite lažne brke in filc ali kaj podobnega, nikoli ne bo spodletelo. Sporočite svoje skrbi, pokažite jasne koristi in oznanjujte.
- Zagotovite, da razvoj (dev) in operacije (ops) razumeta pomen in posledice premikanja meritev izdelka v rdeče območje. Ne pustite Opsa kot edinega varuha zdravja izdelka, poskrbite, da bodo vključeni tudi razvijalci (#productsquads).
- Dnevniki so odlična stvar, a tudi meritve. Združite jih in ne dovolite, da vaša polena postanejo smeti v ogromni goreči krogli neuporabnosti. Pojasnite in pokažite razvijalcem, zakaj nihče drug ne bo razumel njihovih dnevnikov, pokažite jim, kako je gledati neuporabne dnevnike ob 3:15 zjutraj.
Avtor fotografije o
To je vse. Nov material bo izšel naslednji teden. Če želite izvedeti več o tečaju, vas vabimo , ki bo v ponedeljek. In zdaj tradicionalno čakamo na vaše komentarje.
Vir: www.habr.com