Gëzuar të Premten të gjithëve! Miq, sot vazhdojmë serinë e botimeve kushtuar kursit , sepse mësimet në grupin e ri për kursin do të fillojnë në fund të javës së ardhshme. Pra, le të fillojmë!
Monitorimi është просто. Ky është një fakt i njohur. Ngritni Nagios, ekzekutoni NRPE në sistemin në distancë, konfiguroni Nagios në portin NRPE TCP 5666 dhe keni monitorim.
Është aq e lehtë sa nuk është interesante. Tani keni metrikë bazë për kohën e procesorit, nënsistemin e diskut, RAM-in, të dhëna si parazgjedhje për Nagios dhe NRPE. Por ky në fakt nuk është "monitorim" si i tillë. Ky eshte vetem fillimi.
(Zakonisht ata instalojnë PNP4Nagios, RRDtool dhe Thruk, konfigurojnë njoftimet në Slack dhe shkojnë direkt në nagiosexchange, por le ta lëmë këtë për momentin).
Monitorim i mirë është në të vërtetë mjaft komplekse, ju me të vërtetë duhet të dini të brendshmet e aplikacionit që po monitoroni.
A është i vështirë monitorimi?
Çdo server, qoftë Linux apo Windows, me përkufizim do të shërbejë për një qëllim. Apache, Samba, Tomcat, ruajtja e skedarëve, LDAP - të gjitha këto shërbime janë pak a shumë unike në një ose më shumë aspekte. Secili ka funksionin e vet, karakteristikat e veta. Ka mënyra të ndryshme për të marrë metrikë, KPI (treguesit kryesorë të performancës), që janë interesante për ju kur serveri është nën ngarkesë.
Autori i fotos mbi
(Do të doja që tabelat e mia të ishin blu neoni - duke psherëtirë me ëndërrim -... hmm...)
Çdo softuer që ofron shërbime duhet të ketë një mekanizëm për të mbledhur metrikë. Apache ka një modul mod-status, duke shfaqur faqen e statusit të serverit. Nginx ka - stub_status. Tomcat ka aplikacione uebi JMX ose të personalizuara që tregojnë matjet kryesore. MySQL ka një komandë "shfaq statusin global" etj.
Pra, pse zhvilluesit nuk ndërtojnë mekanizma të ngjashëm në aplikacionet që krijojnë?
A e bëjnë këtë vetëm zhvilluesit?
Një nivel i caktuar i indiferencës ndaj futjes së metrikës nuk kufizohet vetëm tek zhvilluesit. Kam punuar në kompani ku ata zhvilluan aplikacione duke përdorur Tomcat dhe nuk ofruan asnjë nga metrikat e tyre, asnjë regjistër të aktivitetit të shërbimit, përveç regjistrave të përgjithshëm të gabimeve Tomcat. Disa zhvillues gjenerojnë shumë regjistra që nuk kanë asgjë për administratorin e sistemit, i cili nuk ka fatin t'i lexojë ato në orën 3:15 të mëngjesit.
Autori i fotos mbi
Inxhinierët e sistemit që mundësojnë lëshimin e produkteve të tilla duhet gjithashtu të mbajnë njëfarë përgjegjësie për situatën. Pak inxhinierë sistemesh kanë kohën ose kujdesin të përpiqen të nxjerrin metrikë kuptimplotë nga regjistrat, pa kontekstin e këtyre metrikave dhe aftësinë për t'i interpretuar ato në dritën e aktivitetit të aplikacionit. Disa nuk e kuptojnë se si mund të përfitojnë prej tij, përveç treguesve "diçka është aktualisht (ose së shpejti do të jetë e gabuar)".
Një ndryshim në të menduarit në lidhje me nevojën për metrikë duhet të ndodhë jo vetëm midis zhvilluesve, por edhe midis inxhinierëve të sistemeve.
Për çdo inxhinier sistemesh që duhet jo vetëm t'i përgjigjet ngjarjeve kritike, por edhe të sigurojë që ato të mos ndodhin, mungesa e metrikës është zakonisht një pengesë për ta bërë këtë.
Sidoqoftë, inxhinierët e sistemeve zakonisht nuk ndërhyjnë me kodin për të fituar para për kompaninë e tyre. Ata kanë nevojë për zhvillues kryesorë që kuptojnë rëndësinë e përgjegjësisë së inxhinierit të sistemeve në identifikimin e problemeve, rritjen e ndërgjegjësimit për çështjet e performancës dhe të ngjashme.
Kjo përshkon gjë
Mentaliteti devops përshkruan sinergjinë midis të menduarit të zhvillimit (dev) dhe operacioneve (ops). Çdo kompani që pretendon se "bën devops" duhet:
- duke thënë gjëra që ndoshta nuk i bëjnë (duke iu referuar meme-s së The Princess Bride - "Unë nuk mendoj se do të thotë atë që ju mendoni se do të thotë!")
- Inkurajoni një qëndrim të përmirësimit të vazhdueshëm të produktit.
Ju nuk mund të përmirësoni një produkt dhe ta dini se ai është përmirësuar nëse nuk e dini se si funksionon aktualisht. Ju nuk mund të dini se si funksionon një produkt nëse nuk kuptoni se si funksionojnë përbërësit e tij, shërbimet nga të cilat varet, pikat kryesore të dhimbjes dhe pengesat e tij.
Nëse nuk shikoni për pengesat e mundshme, nuk do të jeni në gjendje të ndiqni teknikën Pesë Pse kur shkruani një Postmortem. Nuk do të mund të vendosni gjithçka në një ekran për të parë se si funksionon një produkt ose për të ditur se si duket "normal dhe i lumtur".
Zhvendos majtas, Majtas, thashë LEEEE-
Për mua, një nga parimet kryesore të Devops është "ndryshimi majtas". Zhvendosja majtas në këtë kontekst do të thotë zhvendosje e mundësisë (asnjë përgjegjësi, por vetëm aftësitë) për të bërë gjëra për të cilat zakonisht kujdesen inxhinierët e sistemeve, të tilla si krijimi i matjeve të performancës, përdorimi i regjistrave në mënyrë më efikase, etj., majtas në ciklin jetësor të dorëzimit të softuerit.
Autori i fotos mbi
Zhvilluesit e programeve kompjuterike duhet të jenë në gjendje të përdorin dhe të njohin mjetet e monitorimit që përdor kompania për të kryer monitorimin në të gjitha format e tij, metrikat, regjistrimet, ndërfaqet e monitorimit dhe, më e rëndësishmja, shikoni se si produkti i tyre funksionon në prodhim. Ju nuk mund t'i detyroni zhvilluesit të investojnë përpjekje dhe kohë në monitorim derisa të mund të shohin metrikat dhe të ndikojnë në pamjen e tyre, se si pronari i produktit i paraqet ato tek CTO në konferencën e ardhshme, etj.
Shkurtimisht
- Çoje kalin te uji. Tregojuni 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, i cili bërtet nga CTO. Sillni ato në dritë, butësisht dhe me qetësi. Nëse kjo nuk funksionon, atëherë jepni ryshfet, kërcënoni dhe ftojini ata ose pronarin e produktit që të zbatojë marrjen e këtyre metrikave nga aplikacionet sa më shpejt që të jetë e mundur dhe më pas vizatoni diagramet. Kjo do të jetë e vështirë pasi nuk do të shihet si prioritet dhe udhërrëfyesi i produktit do të ketë shumë projekte që gjenerojnë të ardhura në pritje. Prandaj, do t'ju duhet një rast biznesi për të justifikuar kohën dhe shpenzimet e shpenzuara për zbatimin e monitorimit në produkt.
- Ndihmoni inxhinierët e sistemit të bëjnë një gjumë të mirë. Tregojuni atyre se përdorimi i një liste kontrolli "le të lëshojmë" për çdo produkt që lëshohet është një gjë e mirë. Dhe duke u siguruar që të gjitha aplikacionet në prodhim janë të mbuluara me metrikë, do t'ju ndihmojë të flini më mirë gjatë natës duke i lejuar zhvilluesit të shohin se çfarë po shkon keq dhe ku. Megjithatë, mënyra e duhur për të irrituar dhe frustruar çdo zhvillues, pronar produkti ose CTO është të këmbëngulësh dhe të rezistosh. Kjo sjellje do të ndikojë në datën e lëshimit të çdo produkti nëse prisni sërish deri në minutën e fundit, kështu që zhvendoseni sërish majtas dhe futini këto çështje në planin tuaj të projektit sa më shpejt të jetë e mundur. Nëse është e nevojshme, shkoni në takimet e produktit. Vishni mustaqe të rreme dhe ndjesi ose diçka tjetër, nuk do të dështojë kurrë. Komunikoni shqetësimet tuaja, tregoni përfitime të qarta dhe ungjillizoni.
- Sigurohuni që zhvillimi (dev) dhe operacionet (ops) të kuptojnë kuptimin dhe pasojat e metrikës së produktit që lëviz në zonën e kuqe. Mos e lini Ops si kujdestarin e vetëm të shëndetit të produktit, sigurohuni që edhe zhvilluesit të jenë të përfshirë (#productsquads).
- Regjistrat janë një gjë e mrekullueshme, por edhe metrikat. Kombinojini ato dhe mos lejoni që trungjet tuaja të bëhen plehra në një top të madh flakërues të padobishmërisë. Shpjegoni dhe tregojuni zhvilluesve pse askush tjetër nuk do t'i kuptojë regjistrat e tyre, tregojuni atyre se si është të shikosh regjistrat e padobishëm në orën 3:15 të mëngjesit.
Autori i fotos mbi
Kjo eshte e gjitha. Materiali i ri do të publikohet javën e ardhshme. Nëse dëshironi të mësoni më shumë rreth kursit, ju ftojmë , i cili do të zhvillohet të hënën. Dhe tani tradicionalisht presim komentet tuaja.
Burimi: www.habr.com