Gleðilegan föstudag allir! Vinir, í dag höldum við áfram ritröðinni sem er tileinkuð námskeiðinu , því kennsla í nýja hópnum fyrir námskeiðið hefst í lok næstu viku. Svo, við skulum byrja!
Eftirlit er bara. Þetta er þekkt staðreynd. Komdu upp Nagios, keyrðu NRPE á ytra kerfinu, stilltu Nagios á NRPE TCP tengi 5666 og þú hefur eftirlit.
Það er svo auðvelt að það er ekki áhugavert. Nú hefurðu grunntölur fyrir örgjörvatíma, undirkerfi disks, vinnsluminni, sem sjálfgefið er til staðar fyrir Nagios og NRPE. En þetta er í raun ekki „eftirlit“ sem slíkt. Þetta er aðeins byrjunin.
(Venjulega setja þeir upp PNP4Nagios, RRDtool og Thruk, setja upp tilkynningar í Slack og fara beint í nagiosexchange, en við skulum sleppa því í bili).
Gott eftirlit er í raun frekar flókið, þú þarft virkilega að þekkja innra hluta forritsins sem þú ert að fylgjast með.
Er eftirlit erfitt?
Hvaða netþjónn sem er, hvort sem það er Linux eða Windows, mun samkvæmt skilgreiningu þjóna einhverjum tilgangi. Apache, Samba, Tomcat, skráageymsla, LDAP - öll þessi þjónusta er meira og minna einstök í einu eða fleiri atriðum. Hver hefur sína virkni, sína eigin eiginleika. Það eru mismunandi leiðir til að fá mælikvarða, KPI (key performance indicators), sem eru áhugaverðar fyrir þig þegar þjónninn er undir álagi.
Höfundur myndarinnar á
(Ég vildi að mælaborðin mín væru neonblá - andvarpaði dreymandi -... hmm...)
Sérhver hugbúnaður sem veitir þjónustu verður að hafa kerfi til að safna mælingum. Apache er með einingu mod-status, sýnir stöðusíðu miðlarans. Nginx hefur - stub_status. Tomcat er með JMX eða sérsniðin vefforrit sem sýna lykilmælikvarða. MySQL hefur skipunina "show global status" o.s.frv.
Svo hvers vegna byggja forritarar ekki svipaðar aðferðir inn í forritin sem þeir búa til?
Eru bara forritarar að gera þetta?
Ákveðið afskiptaleysi gagnvart innfellingu mæligilda er ekki takmarkað við forritara. Ég vann í fyrirtækjum þar sem þau þróuðu forrit með Tomcat og gáfu enga eigin mælikvarða fram, enga skrá yfir þjónustustarfsemi, nema almennar Tomcat villuskrár. Sumir forritarar búa til fullt af annálum sem þýðir ekkert fyrir kerfisstjórann sem er svo óheppinn að lesa þær klukkan 3:15 að morgni.
Höfundur myndarinnar á
Kerfisfræðingar sem gera kleift að gefa út slíkar vörur verða einnig að bera nokkra ábyrgð á ástandinu. Fáir kerfisfræðingar hafa tíma eða umhyggju til að reyna að draga marktækar mælingar úr annálum, án samhengis þessara mæligilda og getu til að túlka þær í ljósi umsóknarvirkni. Sumir skilja ekki hvernig þeir geta notið góðs af því, annað en "eitthvað er núna (eða mun bráðum verða) rangt" vísbendingar.
Breyting á hugsun varðandi þörfina fyrir mælikvarða verður ekki aðeins að eiga sér stað meðal þróunaraðila, heldur einnig meðal kerfisfræðinga.
Fyrir alla kerfisfræðinga sem þurfa ekki aðeins að bregðast við mikilvægum atburðum, heldur einnig tryggja að þeir eigi sér ekki stað, er skortur á mælingum venjulega hindrun í því að gera það.
Hins vegar eru kerfisfræðingar venjulega ekki að fikta í kóða til að græða peninga fyrir fyrirtæki sitt. Þeir þurfa leiðandi þróunaraðila sem skilja mikilvægi ábyrgðar kerfisfræðingsins við að greina vandamál, vekja athygli á frammistöðuvandamálum og þess háttar.
Þetta eyðileggur hlutur
Devops hugarfarið lýsir samvirkni milli þróunar (dev) og rekstrar (ops) hugsunar. Sérhvert fyrirtæki sem segist „gera devops“ verður að:
- segja hluti sem þeir gera líklega ekki (með The Princess Bride meme - "Ég held ekki að það þýði það sem þú heldur að það þýðir!")
- Hvetja til viðhorfs stöðugrar umbóta á vöru.
Þú getur ekki bætt vöru og veist að hún hefur verið endurbætt ef þú veist ekki hvernig hún virkar eins og er. Þú getur ekki vitað hvernig vara virkar ef þú skilur ekki hvernig íhlutir hennar virka, þjónustuna sem hún er háð, helstu verkjapunkta hennar og flöskuhálsa.
Ef þú fylgist ekki með hugsanlegum flöskuhálsum muntu ekki geta fylgt Five Whys tækninni þegar þú skrifar Postmortem. Þú munt ekki geta sett allt á einn skjá til að sjá hvernig vara virkar eða vita hvernig hún lítur út "venjuleg og hamingjusöm."
Breyttu til vinstri, til vinstri, ég sagði LEEEE—
Fyrir mér er ein af lykilreglum Devops að „skipta til vinstri“. Breyting til vinstri í þessu samhengi þýðir að færa möguleika (engin ábyrgð, en aðeins getu) til að gera hluti sem kerfisfræðingum er venjulega sama um, eins og að búa til árangursmælikvarða, nota annála á skilvirkari hátt o.s.frv., til vinstri í hugbúnaðarafhendingarferli.
Höfundur myndarinnar á
Hugbúnaðarframleiðendur verða að geta notað og þekkja þau vöktunartæki sem fyrirtækið notar til að sinna vöktun í öllum sínum myndum, mæligildum, skráningu, vöktunarviðmótum og síðast en ekki síst, horfa á hvernig varan þeirra virkar í framleiðslu. Þú getur ekki fengið þróunaraðila til að fjárfesta fyrirhöfn og tíma í eftirlit fyrr en þeir geta séð mælikvarðana og haft áhrif á hvernig þeir líta út, hvernig vörueigandinn kynnir þær fyrir CTO á næstu kynningarfundi o.s.frv.
Í stuttu máli
- Leiddu hestinn þinn að vatninu. Sýndu þróunaraðilum hversu mikil vandræði þeir geta forðast sjálfir, hjálpaðu þeim að bera kennsl á réttu KPI og mælikvarða fyrir forritin sín svo að það sé minna öskur frá vörueigandanum sem tæknistjórinn hrópar á. Komdu þeim fram í ljósið, varlega og rólega. Ef það virkar ekki, þá múta, hóta og hvetja annaðhvort þeim eða vörueigandanum til að innleiða að fá þessar mælikvarðar úr forritunum eins fljótt og auðið er og teikna síðan skýringarmyndirnar. Þetta verður erfitt þar sem það verður ekki litið á það sem forgangsverkefni og vöruleiðarvísirinn mun hafa mörg tekjuskapandi verkefni í bið. Þess vegna þarftu viðskiptatilvik til að réttlæta þann tíma og kostnað sem varið er í að innleiða eftirlit með vörunni.
- Hjálpaðu kerfisfræðingum að fá góðan nætursvefn. Sýndu þeim að það er gott að nota „látum gefa út“ gátlista fyrir hvaða vöru sem er að gefa út. Og að tryggja að öll forrit í framleiðslu séu þakin mæligildum mun hjálpa þér að sofa betur á nóttunni með því að leyfa forriturum að sjá hvað er að fara úrskeiðis og hvar. Hins vegar er rétta leiðin til að pirra og pirra alla þróunaraðila, vörueiganda eða tæknistjóra að halda áfram og standast. Þessi hegðun mun hafa áhrif á útgáfudag allra vara ef þú bíður til síðustu stundar aftur, svo farðu til vinstri aftur og færðu þessi mál inn í verkefnaáætlun þína eins fljótt og auðið er. Ef nauðsyn krefur, leggðu leið þína á vörufundi. Notaðu falsað yfirvaraskegg og filt eða eitthvað, það mun aldrei mistakast. Komdu á framfæri áhyggjum þínum, sýndu skýran ávinning og boðaðu boðun.
- Gakktu úr skugga um að bæði þróun (dev) og rekstur (ops) skilji merkingu og afleiðingu þess að vörumælingar færast inn á rauða svæðið. Ekki yfirgefa Ops sem eina verndara vöruheilbrigðis, vertu viss um að þróunaraðilar taki þátt líka (#productsquads).
- Logs eru frábær hlutur, en það eru mælingar líka. Sameina þá og ekki láta trjástokkana þína verða rusl í risastórum logandi kúlu gagnsleysis. Útskýrðu og sýndu þróunaraðilum hvers vegna enginn annar mun skilja annálana þeirra, sýndu þeim hvernig það er að horfa á gagnslausa annála klukkan 3:15 að morgni.
Höfundur myndarinnar á
Það er allt og sumt. Nýtt efni kemur út í næstu viku. Ef þú vilt fræðast meira um námskeiðið þá bjóðum við þér að mæta , sem fram fer á mánudaginn. Og nú erum við venjulega að bíða eftir athugasemdum þínum.
Heimild: www.habr.com