Linksmo penktadienio visiems! Bičiuliai, šiandien tęsiame kursui skirtų leidinių seriją , nes naujoje kurso grupėje užsiėmimai prasidės kitos savaitės pabaigoje. Taigi, pradėkime!
Stebėjimas yra tiesiog. Tai žinomas faktas. Iškvieskite „Nagios“, paleiskite NRPE nuotolinėje sistemoje, sukonfigūruokite „Nagios“ NRPE TCP prievade 5666 ir galėsite stebėti.
Tai taip paprasta, kad neįdomu. Dabar turite pagrindines procesoriaus laiko, disko posistemės, RAM metrikas, kurios pagal numatytuosius nustatymus tiekiamos Nagios ir NRPE. Tačiau tai nėra „stebėjimas“ kaip toks. Tai tik pradžia.
(Paprastai jie įdiegia „PNP4Nagios“, „RRDtool“ ir „Thruk“, nustato pranešimus „Slack“ ir eina tiesiai į „nagiosexchange“, bet kol kas tai palikime).
Geras stebėjimas iš tikrųjų yra gana sudėtinga, jums tikrai reikia žinoti stebimos programos vidines savybes.
Ar sunku stebėti?
Bet koks serveris, ar tai būtų „Linux“, ar „Windows“, pagal apibrėžimą pasitarnaus tam tikram tikslui. Apache, Samba, Tomcat, failų saugykla, LDAP – visos šios paslaugos yra daugiau ar mažiau unikalios vienu ar keliais aspektais. Kiekvienas turi savo funkciją, savo ypatybes. Yra įvairių būdų gauti metriką, KPI (pagrindinius našumo rodiklius), kurie jus domina, kai serveris yra apkrautas.
Nuotraukos autorius apie
(Norėčiau, kad mano prietaisų skydeliai būtų neoninės mėlynos spalvos – svajingai atsidūsta –... hmm...)
Bet kuri paslaugas teikianti programinė įranga turi turėti metrikos rinkimo mechanizmą. Apache turi modulį mod-status, rodantis serverio būsenos puslapį. Nginx turi - stub_status. Tomcat turi JMX arba pasirinktines žiniatinklio programas, kuriose rodoma pagrindinė metrika. MySQL turi komandą „show global status“ ir kt.
Taigi kodėl kūrėjai savo kuriamose programose neįdiegė panašių mechanizmų?
Ar tai daro tik kūrėjai?
Tam tikras abejingumo lygis metrikos įterpimui neapsiriboja kūrėjais. Dirbau įmonėse, kuriose jos kūrė programas naudodamos Tomcat ir nepateikė jokių savo metrikų, paslaugų veiklos žurnalų, išskyrus bendruosius Tomcat klaidų žurnalus. Kai kurie kūrėjai sukuria daug žurnalų, kurie nieko nereiškia sistemos administratoriui, kuriam nesiseka juos perskaityti 3:15 ryto.
Nuotraukos autorius apie
Sistemos inžinieriai, kurie leidžia išleisti tokius produktus, taip pat turi prisiimti tam tikrą atsakomybę už situaciją. Nedaugelis sistemų inžinierių turi laiko ar rūpesčio pabandyti iš žurnalų išgauti reikšmingą metriką, neatsižvelgdami į tų metrikų kontekstą ir nesugebėdami jas interpretuoti atsižvelgiant į taikomųjų programų veiklą. Kai kurie nesupranta, kokios naudos iš to gali gauti, išskyrus „kažkas šiuo metu (arba greitai bus) negerai“ rodiklius.
Mąstymas apie metrikų poreikį turi pasikeisti ne tik tarp kūrėjų, bet ir tarp sistemų inžinierių.
Bet kuriam sistemų inžinieriui, kuriam reikia ne tik reaguoti į kritinius įvykius, bet ir užtikrinti, kad jie neįvyktų, metrikos trūkumas paprastai yra kliūtis tai padaryti.
Tačiau sistemų inžinieriai paprastai nedirba su kodu, kad užsidirbtų pinigų savo įmonei. Jiems reikia vadovaujančių kūrėjų, kurie suprastų sistemų inžinieriaus atsakomybės svarbą nustatant problemas, didinant informuotumą apie veikimo problemas ir panašiai.
Tai devops dalykas
Devops mentalitetas apibūdina sinergiją tarp vystymosi (dev) ir operacijų (ops) mąstymo. Bet kuri įmonė, kuri teigia, kad „daro devops“, privalo:
- sakydami tai, ko tikriausiai nedaro (turint galvoje „The Princess Bride“ memą – „Nemanau, kad tai reiškia tai, ką tu manai!“)
- Skatinkite požiūrį į nuolatinį produkto tobulinimą.
Negalite tobulinti produkto ir žinoti, kad jis buvo patobulintas, jei nežinote, kaip jis šiuo metu veikia. Negalite žinoti, kaip veikia produktas, jei nesuprantate, kaip veikia jo komponentai, paslaugos, nuo kurių jis priklauso, pagrindinių jo skausmo taškų ir kliūčių.
Jei nestebėsite galimų kliūčių, negalėsite vadovautis „Five Whys“ technikos rašydami „Pomirtinį“. Negalėsite visko sudėti į vieną ekraną, kad pamatytumėte, kaip veikia produktas, ar žinotumėte, kaip jis atrodo „normalus ir laimingas“.
Perkelkite į kairę, į KAIRĘ, AŠ SAKAU LEE...
Man vienas pagrindinių „Devops“ principų yra „slinkti į kairę“. Šiame kontekste perkelti į kairę reiškia pakeisti galimybę (jokios atsakomybės, bet tik galimybes) atlikti dalykus, kurie paprastai rūpi sistemų inžinieriams, pvz., kurti našumo metriką, efektyviau naudoti žurnalus ir pan., programinės įrangos pristatymo gyvavimo ciklo kairėje.
Nuotraukos autorius apie
Programinės įrangos kūrėjai turi mokėti naudoti ir žinoti stebėjimo įrankius, kuriuos įmonė naudoja, kad galėtų vykdyti visų formų stebėjimą, metriką, registravimą, stebėjimo sąsajas ir, svarbiausia, stebėti, kaip jų produktas veikia gamyboje. Negalite priversti kūrėjų investuoti pastangų ir laiko į stebėjimą, kol jie nematys metrikų ir nepadarys įtakos jų išvaizdai, kaip produkto savininkas juos pristatys CTO kitame instruktaže ir pan.
Trumpai tariant
- Nuvesk arklį prie vandens. Parodykite kūrėjams, kiek problemų jie gali išvengti patys, padėkite jiems nustatyti tinkamus jų taikomųjų programų KPI ir metrikas, kad mažiau šauktų produkto savininkas, dėl kurio šaukia CTO. Iškelkite juos į šviesą švelniai ir ramiai. Jei tai nepadeda, papirkkite, grasinkite ir raginkite juos arba produkto savininką, kad šie rodikliai būtų kuo greičiau gauti iš programų, tada nubraižykite diagramas. Tai bus sunku, nes tai nebus laikoma prioritetu, o produkto veiksmų plane bus laukiama daug pajamas generuojančių projektų. Todėl jums reikės verslo atvejo, kad pateisintumėte laiką ir išlaidas, sugaištas stebint gaminį.
- Padėkite sistemų inžinieriams gerai išsimiegoti. Parodykite jiems, kad naudoti „išleiskime“ kontrolinį sąrašą bet kuriam išleidžiamam produktui yra geras dalykas. Įsitikinę, kad visos gamybinės programos yra padengtos metrika, padės geriau miegoti naktimis, nes kūrėjai galės matyti, kas ir kur negerai. Tačiau tinkamas būdas suerzinti ir nuvilti bet kurį kūrėją, produkto savininką ar techninės priežiūros vadovą – atkakliai ir priešintis. Šis elgesys turės įtakos bet kurio produkto išleidimo datai, jei vėl lauksite iki paskutinės minutės, todėl vėl pasukite į kairę ir kuo greičiau įtraukite šias problemas į projekto planą. Jei reikia, eikite į produktų susitikimus. Dėvėkite netikrus ūsus ir veltinį ar dar ką nors, tai niekada nepasiges. Praneškite apie savo rūpesčius, parodykite aiškią naudą ir evangelizuokite.
- Įsitikinkite, kad tiek kūrimas (kūrėjas), tiek operacijos (operacijos) supranta produkto metrikos perkėlimo į raudonąją zoną prasmę ir pasekmes. Nepalikite „Ops“ kaip vieninteliu produkto sveikatos sergėtoju, įsitikinkite, kad įtraukiami ir kūrėjai (#productsquads).
- Rąstai yra puikus dalykas, bet taip pat ir metrika. Sujunkite juos ir neleiskite, kad jūsų rąstai virstų šiukšlėmis didžiuliame liepsnojančiame nenaudingumo kamuoliuke. Paaiškinkite ir parodykite kūrėjams, kodėl niekas kitas nesupras jų žurnalų, parodykite, kaip atrodo 3:15 ryto žiūrėti į nenaudingus žurnalus.
Nuotraukos autorius apie
Tai viskas. Kitą savaitę bus išleista nauja medžiaga. Jei norite daugiau sužinoti apie kursą, kviečiame į , kuris vyks pirmadienį. O dabar tradiciškai laukiame Jūsų komentarų.
Šaltinis: www.habr.com