Gëzuar të premten! Miq, sot vazhdojmë serinë e publikimeve që i kushtohet kursit , pasi mësimet në grupin e ri për kursin fillojnë tashmë në fund të javës së ardhshme. Le të nisim!
Monitorimi është thjesht. Ky është një fakt i njohur. Aktivizoni Nagios, nisni NRPE në sistemin e largët, konfiguroni Nagios për portin NRPE TCP 5666 dhe keni monitorim.
ĂshtĂ« kaq e lehtĂ«, saqĂ« nuk Ă«shtĂ« interesante. Tani keni metrika bazike pĂ«r kohĂ«n e procesorit, nĂ«nstrukturĂ«n e diskut dhe memorien operuese, tĂ« cilat vijnĂ« pĂ«r default nĂ« Nagios dhe NRPE. Por nĂ« tĂ« vĂ«rtetĂ«, kjo nuk Ă«shtĂ« âmonitorimâ si i tillĂ«. Kjo Ă«shtĂ« vetĂ«m fillimi.
(Zakonisht instalojnë PNP4Nagios, RRDtool dhe Thruk, konfigurjnë njoftimet në Slack dhe shkojnë direkt në nagiosexchange, por për tani le ta lëmë këtë).
Monitorimi i mirë në të vërtetë është mjaft i komplikuar, ju vërtet duhet të dini brendësitë e aplikacionit që po monitoroni.
A është monitorimi i vështirë?
Ădo server, qofshin kĂ«to Linux apo Windows, do tĂ« ketĂ« gjithmonĂ« njĂ« qĂ«llim tĂ« caktuar. Apache, Samba, Tomcat, ruajtja e skedarĂ«ve, LDAP - tĂ« gjitha kĂ«to shĂ«rbime janĂ« mĂ« shumĂ« apo mĂ« pak unike nĂ« njĂ« ose disa aspekte. Ădo njĂ«ra ka funksionin e vet, karakteristikat e saj. Ka mĂ«nyra tĂ« ndryshme pĂ«r tĂ« marrĂ« metrika, KPI (tĂ« treguesve kryesorĂ« tĂ« performancĂ«s) qĂ« ju interesojnĂ« kur serveri Ă«shtĂ« nĂ«n ngarkesĂ«.
Autori i fotos në
(do tĂ« doja qĂ« panelat e mi tĂ« ishin tĂ« ngjyrosura me ngjyra neon-blue - duke suspiruara Ă«ndrrisht -⊠hmâŠ)
Ădo software qĂ« ofron shĂ«rbime duhet tĂ« ketĂ« njĂ« mekanizĂ«m pĂ«r mbledhjen e metrikeve. Apache ka modulin mod-status, qĂ« tregon faqen e gjendjes sĂ« serverit. Nginx ka stub_status. Tomcat ka JMX ose aplikacione speciale nĂ« web qĂ« tregojnĂ« metrika kyçe. NĂ« MySQL ka komandĂ«n "show global status" dhe kĂ«shtu me radhĂ«.
Pra, pse zhvilluesit nuk integrojnë mekanizma të tillë në aplikacionet që ata krijojnë?
A janë vetëm zhvilluesit që e bëjnë këtë?
Një nivel i caktuar indiference ndaj integrimit të metrikeve nuk kufizohet vetëm tek zhvilluesit. Kam punuar në kompani ku zhvillonin aplikacione duke përdorur Tomcat dhe nuk jepnin asnjë metrikë të tyre, asnjë ditar aktiviteti të shërbimit, përveç gazetave të zakonshme të gabimeve të Tomcat. Disa zhvillues gjenerojnë një sasi të madhe ditarësh, të cilat nuk kanë asnjë kuptim për administratorin e sistemit, që i Godit në 3:15 të mëngjesit.
Autori i fotos në
Inxhinierët sistemorë, të cilët lejojnë që produkte të tilla të dalin në lansim, gjithashtu duhet të mbajnë një përgjegjësi të caktuar për situatën. Pak inxhinierë sistemorë kanë kohë dhe u intereson që të përpiqen të marrin metrika kuptimplote nga ditarët, pa kontekstin e këtyre metrikeve dhe mundësinë për t'i interpretuar ato në dritën e aktivitetit të aplikacionit. Disa nuk e kuptojnë se çfarë dobie mund të marrin nga kjo, përveç treguesve si 'diçka aktualisht (ose së shpejti) nuk është në rregull'.
Ndryshimi i mendësisë në lidhje me nevojën për metrika duhet të ndodhë jo vetëm mes zhvilluesve, por edhe mes inxhinierëve sistemorë.
Për çdo inxhinier sistemesh që duhet jo vetëm të përgjigjet ndaj ngjarjeve kritike, por edhe të garantojë mungesën e tyre, mungesa e metrikave zakonisht paraqet një pengesë për këtë.
Megjithatë, ingjinierët e sistemeve zakonisht nuk gjenden në kod, duke fituar para për kompaninë e tyre. Ata kanë nevojë për zhvillues të udhëhequr, të cilët kuptojnë rëndësinë e përgjegjësisë së inxhinierëve të sistemeve në identifikimin e problemeve, rritjen e ndërgjegjësimit për çështjet e performancës dhe të ngjashme.
Kjo gjë devops
Mentaliteti devops pĂ«rshkruan sinergjinĂ« midis tĂ« menduarit tĂ« zhvilluesve (dev) dhe operacioneve (ops). Ădo kompani qĂ« pretendon se "bĂ«n devops", duhet tĂ«:
- thotë atë që ata ndoshta nuk e bëjnë (këtu ka një referencë në një meme nga filmi "Princesha Nevestë" - "Nuk mendoj se do të thotë ajo që mendon se do të thotë!")
- incentivizojë pozitat e përmirësimit të vazhdueshëm të produktit.
Nuk mund ta përmirësoni produktin dhe të ndani se si është përmirësuar, nëse nuk e dini si funksionon aktualisht. Nuk do të jeni në gjendje të kuptoni si funksionon produkti, nëse nuk e kuptoni se si funksionojnë komponentët e tij, shërbimet nga të cilat varet, piketat e tij kryesore dhe ngushticat.
Nëse nuk i vëzhgoni potencialet ngushticë, nuk do të jeni në gjendje të aplikoni teknikën e "Pesë Pseve" kur shkruani një Postmortem. Nuk do të mund të grumbulloni gjithçka në një ekran, për të parë si funksionon produkti ose për të kuptuar si duket "normal dhe e lumtur".
ShkĂ«putje nĂ« majtas, NĂ MAJAS, THASHĂ MAJASâ
Për mua, një nga parimet kyçe të DevOps është "Shkëputja në Majtas". Shkëputja në majtas në këtë kontekst do të thotë zhvendosja e mundësisë (jo përgjegjësisë, por vetëm mundësisë) për të bërë atë që zakonisht i përket inxhinierëve të sistemit, si krijimi i metrikave të performancës, përdorimi më efektiv i logeve etj., në të majtë të ciklit të jetës së dorëzimit të softuerit (Software Delivery Life Cycle).
Autori i fotos në
Programuesit e softuerit duhet të kenë mundësinë të përdorin dhe të njohin mjetet e monitorimit që përdor kompania për të monitoruar të gjitha format e tij, metrikat, regjistrimin, ndërfaqet e monitorimit dhe, më e rëndësishmja, të vëzhgojnë si funksionon produkti i tyre në ambientin e prodhimit. Ju nuk mund të detyroni zhvilluesit të investojnë forcë dhe kohë në monitorim derisa ata të mund të shohin metrikat dhe të ndikojnë në mënyrën se si ato duken, si do t'ia paraqesë ato pronari i produktit CTO-së në takimin e ardhshëm, etj.
Në përmbledhje
- Ăonit kalin nĂ« ujĂ«. Tregoni zhvilluesve se sa probleme mund tĂ« shmangin pĂ«r veten e tyre, ndihmojini ata tĂ« identifikojnĂ« KPI-tĂ« dhe metrikat e duhura pĂ«r aplikacionet e tyre, nĂ« mĂ«nyrĂ« qĂ« tĂ« ketĂ« mĂ« pak zhurmĂ« nga pronari i produktit, pĂ«r tĂ« cilin ulĂ«ret shefi i teknologjisĂ« (CTO). Nxirrni ata nĂ« dritĂ«, butĂ«sisht dhe qetĂ«sisht. NĂ«se kjo nuk funksionon, atĂ«herĂ« korrupsioni, kĂ«rcĂ«nimi dhe bindja mund tĂ« jenĂ« tĂ« nevojshme, qoftĂ« pĂ«r ta, qoftĂ« pĂ«r pronarin e produktit, nĂ« mĂ«nyrĂ« qĂ« tĂ« realizoni sa mĂ« shpejt marrjen e kĂ«tyre metrikeve nga aplikacionet, dhe pastaj çizni grafikat. Kjo do tĂ« jetĂ« e vĂ«shtirĂ«, pasi nuk do tĂ« konsiderohet prioritet, dhe do tĂ« ketĂ« shumĂ« projekte nĂ« planin e produktit qĂ« presin tĂ« realizohen, duke sjellĂ« tĂ« ardhura. Prandaj, do t'ju nevojitet njĂ« arsyetim ekonomik pĂ«r tĂ« justifikuar kohĂ«n dhe burimet e shpenzuara pĂ«r implementimin e monitorimit nĂ« produkt.
- Ndihmoni inxhinierët sistemikë të flenë. Tregoni atyre se përdorimi i një liste kontrolli për "lëshimin e versionit" për çdo produkt në zhvillim është një ide e mirë. Dhe të sigurohesh që të gjitha aplikacionet në prodhim mbulohen me metrika do të ndihmojë për të arritur një gjumë të shëndetshëm gjatë natës, duke lejuar zhvilluesit të shohin se çfarë dhe ku nuk funksionon si duhet. Megjithatë, mënyra e duhur për të irrituar dhe shqetësuar çdo zhvillues, pronar produkti dhe drejtor teknik është të vendosësh vazhdimisht pengesa dhe të rezistosh. Ky sjellje do të ndikojë në datën e lëshimit të çdo produkti, nëse pritet deri në minutën e fundit përsëri, prandaj bëni një përsëritje dhe përfshini çështjet e këtyre në planin e projektit sa më shpejt të jetë e mundur. Nëse është e nevojshme, infiltroni në takimet për produktin. Vishni mustaqe false dhe ndonjë material tjetër, kjo kurrë nuk dështojnë. Raportoni shqetësimet tuaja, tregoni përfitimet e dukshme dhe bëni evangjelizimin.
- Sigurohuni që zhvilluesit (dev) dhe operacionet (ops) të kuptojnë rëndësinë dhe pasojat e kalimit të metrikeve të produktit në "zonën e kuqe". Mos e lini operacionin si rolin e vetëm mbikëqyrës të funksionit të produktit, sigurohuni që zhvilluesit të jenë gjithashtu të përfshirë në këtë (#productsquads).
- Logat janë një gjë e shkëlqyer, por metrikat gjithashtu. Bashkoni ato dhe mos e lejoni që logat tuaj të bëhen mbeturina në një top të madh të paqenësishmërisë. Shpjegoni dhe tregoni zhvilluesve se përse askush tjetër përveç tyre nuk do të kuptojë logat e tyre, tregoni atyre se si është të shikosh logat e padobishme në ora 3:15 të mëngjesit.
Autori i fotos në
Me këtë përfundojmë. Materiali i ri do të publikohet javën e ardhshme. Nëse dëshironi të mësoni më shumë për kursin, ju ftojmë në , e cila do të zhvillohet këtë të hënë. Dhe tani, tradicionalisht presim komentet tuaja.
Burimi: habr.com
