Vinere fericită toată lumea! Prieteni, astăzi continuăm seria publicațiilor dedicate cursului , deoarece cursurile din noua grupă pentru curs vor începe la sfârșitul săptămânii viitoare. Deci, să începem!
Monitorizarea este doar. Acesta este un fapt cunoscut. Afișați Nagios, rulați NRPE pe sistemul de la distanță, configurați Nagios pe portul NRPE TCP 5666 și aveți monitorizare.
Este atât de ușor încât nu este interesant. Acum aveți valori de bază pentru timpul CPU, subsistemul discului, RAM, furnizate implicit Nagios și NRPE. Dar aceasta nu este de fapt „monitorizare” ca atare. Acesta este doar începutul.
(De obicei instalează PNP4Nagios, RRDtool și Thruk, setează notificări în Slack și merg direct la nagiosexchange, dar să lăsăm asta deoparte pentru moment).
Monitorizare bună este de fapt destul de complex, chiar trebuie să cunoașteți elementele interne ale aplicației pe care o monitorizați.
Monitorizarea este dificilă?
Orice server, fie că este Linux sau Windows, va servi prin definiție la un anumit scop. Apache, Samba, Tomcat, stocare fișiere, LDAP - toate aceste servicii sunt mai mult sau mai puțin unice din unul sau mai multe privințe. Fiecare are propria sa funcție, propriile sale caracteristici. Există diferite modalități de a obține valori, KPI (indicatori cheie de performanță), care sunt interesante pentru dvs. atunci când serverul este sub încărcare.
Fotografie de pe
(Mi-aș dori ca tablourile de bord să fie albastre neon - oftând visător -... hmm...)
Orice software care oferă servicii trebuie să aibă un mecanism pentru a colecta valori. Apache are un modul mod-status, afișând pagina de stare a serverului. Nginx are - stub_status. Tomcat are JMX sau aplicații web personalizate care arată valori cheie. MySQL are o comandă „show global status” etc.
Deci, de ce dezvoltatorii nu construiesc mecanisme similare în aplicațiile pe care le creează?
Doar dezvoltatorii fac asta?
Un anumit nivel de indiferență față de încorporarea valorilor nu se limitează la dezvoltatori. Am lucrat în companii în care au dezvoltat aplicații folosind Tomcat și nu au furnizat nicio măsură proprie, nici jurnalele de activitate ale serviciului, cu excepția jurnalelor generale de erori Tomcat. Unii dezvoltatori generează o mulțime de jurnale care nu înseamnă nimic pentru administratorul de sistem care are ghinionul să le citească la 3:15 dimineața.
Fotografie de pe
Inginerii de sistem care permit lansarea unor astfel de produse trebuie, de asemenea, să poarte o anumită responsabilitate pentru situație. Puțini ingineri de sisteme au timpul sau grija să încerce să extragă valori semnificative din jurnale, fără contextul acelor valori și fără capacitatea de a le interpreta în lumina activității aplicației. Unii nu înțeleg cum pot beneficia de pe urma ei, în afară de indicatorii „ceva este în prezent (sau va fi în curând) greșit”.
O schimbare în gândirea cu privire la nevoia de metrici trebuie să apară nu numai în rândul dezvoltatorilor, ci și în rândul inginerilor de sisteme.
Pentru orice inginer de sisteme care trebuie nu numai să răspundă la evenimentele critice, ci și să se asigure că acestea nu apar, lipsa de indicatori este de obicei o barieră în acest sens.
Cu toate acestea, inginerii de sisteme, de obicei, nu schimbă codul pentru a câștiga bani pentru compania lor. Ei au nevoie de dezvoltatori principali care înțeleg importanța responsabilității inginerului de sisteme în identificarea problemelor, creșterea gradului de conștientizare a problemelor de performanță și altele asemenea.
Acest lucru devops
Mentalitatea devops descrie sinergia dintre gândirea de dezvoltare (dev) și operațiuni (ops). Orice companie care pretinde că „face devops” trebuie să:
- spunând lucruri pe care probabil că nu le spun (referindu-ne la meme-ul The Princess Bride - „Nu cred că înseamnă ceea ce crezi tu că înseamnă!”)
- Încurajează o atitudine de îmbunătățire continuă a produsului.
Nu poți îmbunătăți un produs și știi că a fost îmbunătățit dacă nu știi cum funcționează în prezent. Nu poți ști cum funcționează un produs dacă nu înțelegi cum funcționează componentele sale, serviciile de care depinde, principalele sale dureri și blocaje.
Dacă nu urmăriți eventualele blocaje, nu veți putea urma tehnica Cinci De ce atunci când scrieți o autopsie. Nu veți putea pune totul pe un singur ecran pentru a vedea cum funcționează un produs sau pentru a ști cum arată „normal și fericit”.
Schimbați la stânga, la stânga, am spus LEEEE—
Pentru mine, unul dintre principiile cheie ale Devops este „schift left”. Schimbarea la stânga în acest context înseamnă schimbarea posibilității (nicio responsabilitate, dar numai capabilități) pentru a face lucruri la care inginerii de sisteme le pasă în mod obișnuit, cum ar fi crearea de metrici de performanță, utilizarea mai eficientă a jurnalelor etc., în stânga în Ciclul de viață al livrării software.
Fotografie de pe
Dezvoltatorii de software trebuie să fie capabili să folosească și să cunoască instrumentele de monitorizare pe care compania le folosește pentru a efectua monitorizarea sub toate formele, metrici, logging, interfețe de monitorizare și, cel mai important, urmăriți cum funcționează produsul lor în producție. Nu puteți determina dezvoltatorii să investească efort și timp în monitorizare până când nu pot vedea valorile și influența modul în care arată, modul în care proprietarul produsului le prezintă CTO la următorul briefing etc.
Pe scurt
- Condu-ți calul la apă. Arătați dezvoltatorilor cât de multe probleme pot evita pentru ei înșiși, ajutați-i să identifice KPI-urile și valorile potrivite pentru aplicațiile lor, astfel încât să fie mai puține strigăte din partea proprietarului produsului care este atacat de CTO. Aduceți-le în lumină, blând și calm. Dacă acest lucru nu funcționează, atunci mituiți, amenințați și convingeți-i fie pe ei, fie pe proprietarul produsului să implementeze obținerea acestor valori din aplicații cât mai repede posibil, apoi desenați diagramele. Acest lucru va fi dificil, deoarece nu va fi privit ca o prioritate, iar foaia de parcurs al produsului va avea multe proiecte generatoare de venituri în așteptare. Prin urmare, veți avea nevoie de un caz de afaceri pentru a justifica timpul și cheltuielile petrecute implementând monitorizarea în produs.
- Ajutați inginerii de sistem să doarmă bine. Arătați-le că folosirea unei liste de verificare „să lansăm” pentru orice produs lansat este un lucru bun. Și asigurați-vă că toate aplicațiile din producție sunt acoperite cu valori vă va ajuta să dormiți mai bine noaptea, permițând dezvoltatorilor să vadă ce nu merge bine și unde. Cu toate acestea, modalitatea corectă de a irita și frustra orice dezvoltator, proprietar de produs sau CTO este să persiste și să reziste. Acest comportament va afecta data lansării oricărui produs dacă așteptați din nou până în ultimul minut, așa că schimbați din nou la stânga și introduceți aceste probleme în planul dvs. de proiect cât mai curând posibil. Dacă este necesar, mergeți spre întâlnirile de produse. Purtați o mustață falsă și pâslă sau așa ceva, nu va eșua niciodată. Comunicați-vă preocupările, demonstrați beneficii clare și evanghelizați.
- Asigurați-vă că atât dezvoltarea (dezvoltarea), cât și operațiunile (operațiunile) înțeleg semnificația și consecințele valorilor produsului care se deplasează în zona roșie. Nu lăsați pe Ops singurul gardian al sănătății produsului, asigurați-vă că și dezvoltatorii sunt implicați (#productsquads).
- Jurnalele sunt un lucru grozav, dar și valorile sunt la fel. Combinați-le și nu lăsați buștenii să devină gunoi într-o minge uriașă de inutilitate. Explicați și arătați dezvoltatorilor de ce nimeni altcineva nu le va înțelege jurnalele, arată-le cum este să se uite la jurnalele inutile la 3:15 dimineața.
Fotografie de pe
Asta e tot. Material nou va fi lansat săptămâna viitoare. Dacă doriți să aflați mai multe despre curs, vă invităm , care va avea loc luni. Și acum așteptăm în mod tradițional comentariile voastre.
Sursa: www.habr.com