Ostiral on guztioi! Lagunok, gaur ikastaroari eskainitako argitalpen sortarekin jarraitzen dugu , ikastaroko talde berriko klaseak datorren aste amaieran hasiko direlako. Beraz, has gaitezen!
Jarraipena da besterik ez. Hau gertaera ezaguna da. Ekarri Nagios, exekutatu NRPE urruneko sisteman, konfiguratu Nagios NRPE TCP 5666 atakan eta jarraipena duzu.
Hain erraza da ez da interesgarria. Orain CPU denboraren, diskoaren azpisistemaren, RAMaren oinarrizko neurketak dituzu, lehenespenez Nagios-i eta NRPEri emandakoak. Baina hori ez da benetan "monitorizazioa" gisa. Hau hasiera besterik ez da.
(Normalean PNP4Nagios, RRDtool eta Thruk instalatzen dituzte, Slack-en jakinarazpenak konfiguratzen dituzte eta zuzenean nagiosexchange-ra joaten dira, baina utzi dezagun oraingoz).
Jarraipen ona nahiko konplexua da benetan, kontrolatzen ari zaren aplikazioaren barneak ezagutu behar dituzu.
Zaila al da jarraipena?
Edozein zerbitzari, Linux edo Windows izan, definizioz helbururen bat izango du. Apache, Samba, Tomcat, fitxategien biltegiratzea, LDAP - zerbitzu hauek guztiak gutxi gorabehera bereziak dira alderdi batean edo gehiagotan. Bakoitzak bere funtzioa du, bere ezaugarriak. Zerbitzaria kargatuta dagoenean interesgarriak diren neurketak, KPIak (errendimendu-adierazle nagusiak) lortzeko modu desberdinak daude.
Argazkiaren egilea on
(Nire aginte-panelak neoi urdina izatea nahiko nuke - ametsetan hasperen eginez -... hmm...)
Zerbitzuak eskaintzen dituen software orok metrikak biltzeko mekanismo bat izan behar du. Apache-k modulu bat du mod-status, zerbitzariaren egoera orria erakutsiz. Nginx-ek - stub_status. Tomcat-ek JMX edo web-aplikazio pertsonalizatuak ditu funtsezko neurketak erakusten dituztenak. MySQL-k "erakutsi egoera globala" komandoa du, etab.
Beraz, zergatik ez dituzte garatzaileek antzeko mekanismoak sortzen dituzten aplikazioetan?
Garatzaileek bakarrik egiten al dute hori?
Metrikoen txertatzearekiko nolabaiteko axolagabekeria ez da garatzaileetara mugatzen. Tomcat erabiliz aplikazioak garatzen zituzten enpresetan lan egin nuen eta ez zuten beren neurketarik eman, ez zerbitzu-jardueren erregistrorik, Tomcat-en akatsen erregistro orokorrak izan ezik. Garatzaile batzuek erregistro asko sortzen dituzte, goizeko 3:15ean irakurtzeko zorte txarra duen sistema-administratzailearentzat ezer esan nahi ez dutenak.
Argazkiaren egilea on
Produktu horiek kaleratzea ahalbidetzen duten sistema ingeniariek ere egoeraren erantzukizuna izan behar dute. Sistema-ingeniari gutxik dute erregistroetatik metrika esanguratsuak ateratzen saiatzeko denbora edo ardura, metrika horien testuingururik gabe eta aplikazioaren jardueraren arabera interpretatzeko gaitasunik gabe. Batzuek ez dute ulertzen nola onura atera dezaketen, "zerbait gaur egun (edo laster egongo da) gaizki dago" adierazleez gain.
Neurrien beharrari buruzko pentsamolde aldaketa garatzaileen artean ez ezik, sistema ingeniarien artean ere gertatu behar da.
Gertaera kritikoei erantzun ez ezik, gertatzen ez direla ziurtatu behar duen edozein sistema ingeniariarentzat, neurketa falta izan ohi da horretarako oztopoa.
Hala ere, sistemen ingeniariek normalean ez dute kodea aldatzen beren enpresarentzat dirua irabazteko. Arazoak identifikatzeko, errendimendu-arazoei buruz sentsibilizatzeko eta antzeko sistemen ingeniariaren erantzukizunaren garrantzia ulertzen duten garatzaile nagusiak behar dituzte.
Hau devots gauza
Devops mentalitateak garapenaren (dev) eta operazioen (ops) pentsamenduaren arteko sinergia deskribatzen du. "Devops-ak" egiten dituela dioen edozein enpresak:
- Seguruenik egiten ez dituzten gauzak esatea (The Princess Bride memeari erreferentzia eginez - "Ez dut uste zuk esan nahi duzuna esan nahi duenik!")
- Produktuaren etengabeko hobekuntzarako jarrera sustatzea.
Ezin duzu produktu bat hobetu eta jakin hobetu egin dela gaur egun nola funtzionatzen duen ez badakizu. Ezin duzu jakin produktu batek nola funtzionatzen duen bere osagaiek nola funtzionatzen duten, zein zerbitzuren menpe dauden, bere min-puntu nagusiak eta botila-lepoak nola funtzionatzen duten ulertzen ez baduzu.
Ez baduzu behatzen balizko botilak, ezin izango duzu Five Whys teknika jarraitu Postmortem bat idaztean. Ezin izango duzu dena pantaila batean jarri produktu batek nola funtzionatzen duen ikusteko edo "normala eta zoriontsua" den jakiteko.
Maius ezkerrera, EZKERRA, LEEEE ESAN DUT...
Niretzat, Devops-en funtsezko printzipioetako bat "ezkerrera aldatzea" da. Testuinguru honetan ezkerrera aldatzeak aukera aldatzea esan nahi du (erantzukizunik ez, baina gaitasunak soilik) sistemen ingeniariek normalean axola zaizkien gauzak egiteko, esate baterako, errendimendu-neurriak sortzea, erregistroak modu eraginkorragoan erabiltzea, etab., softwarearen entregaren bizi-zikloan ezkerrean.
Argazkiaren egilea on
Software garatzaileek gai izan behar dute konpainiak erabiltzen dituen monitorizazio-tresnak erabili eta ezagutu behar ditu monitorizazioa bere forma guztietan egiteko, metrika, erregistro, monitorizazio interfaze eta, batez ere, ikusi haien produktuak nola funtzionatzen duen ekoizpenean. Ezin diezu garatzaileei esfortzua eta denbora inbertitzea monitorizazioan neurketak ikusi eta nola itxura duten, produktuaren jabeak hurrengo hitzaldian CTOri nola aurkezten dizkion, etab.
Laburbilduz
- Eraman zure zaldia uretara. Erakutsi garatzaileei zenbat arazo ekidin ditzaketen beren kabuz, lagundu beren aplikazioetarako KPI eta neurketa egokiak identifikatzen, CTOk oihukatzen ari den produktuaren jabearen oihu gutxiago izan daitezen. Ekar itzazu argira, emeki eta lasai. Horrek ez badu funtzionatzen, eros ezazu, mehatxatu eta txalotu haiek edo produktuaren jabeari neurri horiek aplikazioetatik ahalik eta azkarren ezar dezan, eta ondoren marraztu diagramak. Hori zaila izango da, ez baita lehentasunezkotzat hartuko eta produktuaren bide-orriak diru-sarrerak sortzeko proiektu asko izango ditu pendiente. Hori dela eta, negozio-kasu bat beharko duzu produktuan monitorizazioa ezartzeko emandako denbora eta gastua justifikatzeko.
- Lagundu sistema ingeniariei lo ona egiten. Erakuts iezaiezu kaleratzen den edozein produktutarako "askatu dezagun" kontrol-zerrenda erabiltzea ona dela. Eta ekoizpenean dauden aplikazio guztiak neurgailuz estalita daudela ziurtatzeak gauez hobeto lo egiten lagunduko dizu, garatzaileei zer gertatzen den eta non dagoen ikusteko aukera emanez. Hala ere, edozein garatzaile, produktu-jabe edo CTO haserretzeko eta zapuzteko modu egokia irautea eta aurre egitea da. Jokabide honek edozein produkturen kaleratze datan eragina izango du berriro azken unera arte itxaronez gero, beraz, mugitu berriro ezkerrera eta sartu arazo hauek zure proiektuaren planean ahalik eta azkarren. Beharrezkoa izanez gero, egin produktuen bileretarako bidea. Erabili bibote eta feltro faltsuak edo zerbait, ez du inoiz huts egingo. Komunikatu zure kezkak, erakutsi onura argiak eta ebanjelizatu.
- Ziurtatu bai garapenak (garapena) bai eragiketak (operazioak) eremu gorrira mugitzen diren produktuen neurketen esanahia eta ondorioa ulertzen dutela. Ez utzi Ops produktuen osasunaren zaindari bakar gisa, ziurtatu garatzaileek ere parte hartzen dutela (#productsquads).
- Erregistroak gauza bikainak dira, baina neurriak ere bai. Konbinatu itzazu eta ez utzi zure erregistroak zabor bihurtu alferrikako bola erraldoi batean. Azaldu eta erakutsi garatzaileei zergatik inork ez dituen bere erregistroak ulertuko, erakutsi zer den alferrikako erregistroak goizeko 3:15etan ikustea.
Argazkiaren egilea on
Hori da dena. Datorren astean material berria kaleratuko da. Ikastaroari buruz gehiago jakin nahi baduzu, gonbidatzen zaitugu , astelehenean egingo dena. Eta orain, tradizionalki, zure iruzkinen zain gaude.
Iturria: www.habr.com