Lekker Vrydag almal! Vriende, vandag gaan ons voort met die reeks publikasies wat aan die kursus gewy is , want klasse in die nuwe groep vir die kursus begin einde volgende week. So, kom ons begin!
Monitering is net. Dit is 'n bekende feit. Bring Nagios op, hardloop NRPE op die afgeleë stelsel, stel Nagios op NRPE TCP-poort 5666 in en jy het monitering.
Dit is so maklik dat dit nie interessant is nie. Nou het jy basiese statistieke vir SVE-tyd, skyfsubstelsel, RAM, wat by verstek aan Nagios en NRPE verskaf word. Maar dit is nie eintlik "monitering" as sodanig nie. Dis net die begin.
(Gewoonlik installeer hulle PNP4Nagios, RRDtool en Thruk, stel kennisgewings in Slack op en gaan reguit na nagiosexchange toe, maar laat ons dit vir eers uitlaat).
Goeie monitering is eintlik nogal kompleks, jy moet regtig die internals van die toepassing ken wat jy monitor.
Is monitering moeilik?
Enige bediener, of dit nou Linux of Windows is, sal per definisie een of ander doel dien. Apache, Samba, Tomcat, lêerberging, LDAP - al hierdie dienste is min of meer uniek in een of meer opsigte. Elkeen het sy eie funksie, sy eie kenmerke. Daar is verskillende maniere om statistieke, KPI's (sleutelprestasie-aanwysers), te kry wat vir jou interessant is wanneer die bediener onder druk is.
Skrywer van die foto op
(Ek wens my dashboards was neonblou - sug dromerig -... hmm...)
Enige sagteware wat dienste verskaf, moet 'n meganisme hê om metrieke in te samel. Apache het 'n module mod-status, wat die bedienerstatusbladsy vertoon. Nginx het - stub_status. Tomcat het JMX of pasgemaakte webtoepassings wat sleutelstatistieke toon. MySQL het 'n opdrag "wys globale status" ens.
So hoekom bou ontwikkelaars nie soortgelyke meganismes in in die toepassings wat hulle skep nie?
Doen net ontwikkelaars dit?
'n Sekere vlak van onverskilligheid teenoor die inbedding van metrieke is nie beperk tot ontwikkelaars nie. Ek het in maatskappye gewerk waar hulle toepassings met Tomcat ontwikkel het en nie enige van hul eie statistieke verskaf het nie, geen logs van diensaktiwiteit nie, behalwe vir algemene Tomcat-foutloglêers. Sommige ontwikkelaars genereer baie logs wat niks beteken vir die stelseladministrateur wat ongelukkig genoeg is om dit om 3:15 in die oggend te lees nie.
Skrywer van die foto op
Stelselingenieurs wat dit moontlik maak om sulke produkte vry te stel, moet ook 'n mate van verantwoordelikheid vir die situasie dra. Min stelselingenieurs het die tyd of sorg om betekenisvolle statistieke uit logboeke te probeer onttrek, sonder die konteks van daardie statistieke en die vermoë om dit te interpreteer in die lig van toepassingsaktiwiteit. Sommige verstaan nie hoe hulle daarby kan baat nie, behalwe "iets is tans (of gaan binnekort) verkeerd wees" aanwysers.
’n Verandering in denke oor die behoefte aan metrieke moet nie net onder ontwikkelaars plaasvind nie, maar ook onder stelselingenieurs.
Vir enige stelselingenieur wat nie net op kritieke gebeure moet reageer nie, maar ook moet verseker dat dit nie plaasvind nie, is die gebrek aan maatstawwe gewoonlik 'n hindernis om dit te doen.
Stelselingenieurs peuter egter gewoonlik nie met kode om geld vir hul maatskappy te maak nie. Hulle het hoofontwikkelaars nodig wat die belangrikheid van die stelselingenieur se verantwoordelikheid verstaan om probleme te identifiseer, bewustheid van prestasiekwessies te verhoog, en dies meer.
Hierdie devops ding
Die devops mentaliteit beskryf die sinergie tussen ontwikkeling (dev) en operasies (ops) denke. Enige maatskappy wat beweer dat hulle "devops doen" moet:
- om dinge te sê wat hulle waarskynlik nie doen nie (verwys na The Princess Bride meme - "Ek dink nie dit beteken wat jy dink dit beteken nie!")
- Moedig 'n houding van deurlopende produkverbetering aan.
Jy kan nie 'n produk verbeter en weet dat dit verbeter is as jy nie weet hoe dit tans werk nie. Jy kan nie weet hoe 'n produk werk as jy nie verstaan hoe sy komponente werk, die dienste waarvan dit afhanklik is, sy hoofpynpunte en knelpunte nie.
As jy nie kyk vir potensiële knelpunte nie, sal jy nie die Five Whys-tegniek kan volg wanneer jy 'n nadoodse ondersoek skryf nie. Jy sal nie alles op een skerm kan plaas om te sien hoe 'n produk werk of te weet hoe dit "normaal en gelukkig" lyk nie.
Skuif links, LINKS, EK HET GESE LEEEE—
Vir my is een van die sleutelbeginsels van Devops "skuif links". Linksverskuiwing in hierdie konteks beteken om die moontlikheid te verskuif (geen verantwoordelikheid nie, maar slegs vermoëns) om dinge te doen waarvoor stelselingenieurs tipies omgee, soos die skep van prestasiemaatstawwe, die gebruik van logs meer doeltreffend, ens., aan die linkerkant in die Sagteware-afleweringslewensiklus.
Skrywer van die foto op
Sagteware-ontwikkelaars moet die moniteringsinstrumente wat die maatskappy gebruik om monitering in al sy vorme, metrieke, logboeke, monitering-koppelvlakke en, bowenal, uit te voer, kan gebruik en ken. kyk hoe hul produk in produksie werk. Jy kan nie ontwikkelaars kry om moeite en tyd in monitering te investeer totdat hulle die maatstawwe kan sien en kan beïnvloed hoe dit lyk, hoe die produkeienaar dit by die volgende inligtingsessie aan die CTO aanbied, ens.
Kortom
- Lei jou perd na die water. Wys ontwikkelaars hoeveel moeilikheid hulle vir hulself kan vermy, help hulle om die regte KPI's en maatstawwe vir hul toepassings te identifiseer sodat daar minder geskree is van die produkeienaar wat deur die CTO geskreeu word. Bring hulle in die lig, sagkens en kalm. As dit nie werk nie, koop dan om, dreig en lok óf hulle óf die produkeienaar om te implementeer om hierdie maatstawwe so vinnig moontlik uit die toepassings te kry, en teken dan die diagramme. Dit sal moeilik wees aangesien dit nie as 'n prioriteit gesien sal word nie en die produkpadkaart sal baie inkomstegenererende projekte hangende hê. Daarom sal jy 'n sakesaak nodig hê om die tyd en uitgawes wat spandeer word om monitering in die produk te implementeer, te regverdig.
- Help stelselingenieurs om 'n goeie nag se slaap te kry. Wys hulle dat die gebruik van 'n "laat ons vry" kontrolelys vir enige produk wat vrygestel word, 'n goeie ding is. En om seker te maak dat alle toepassings in produksie met maatstawwe bedek is, sal jou help om snags beter te slaap deur ontwikkelaars toe te laat om te sien wat verkeerd gaan en waar. Die regte manier om enige ontwikkelaar, produkeienaar of CTO te irriteer en frustreer, is egter om aan te hou en te weerstaan. Hierdie gedrag sal die vrystellingsdatum van enige produk beïnvloed as jy weer wag tot die laaste minuut, so skuif weer links en kry hierdie kwessies so gou moontlik in jou projekplan. Indien nodig, gaan na produkvergaderings. Dra 'n vals snor en vilt of iets, dit sal nooit misluk nie. Kommunikeer jou bekommernisse, toon duidelike voordele en evangeliseer.
- Maak seker dat beide ontwikkeling (ontwikkeling) en bedrywighede (operasies) die betekenis en gevolg van produkmetrieke wat in die rooi sone beweeg, verstaan. Moenie Ops as die enigste voog van produkgesondheid verlaat nie, maak seker dat ontwikkelaars ook betrokke is (#productsquads).
- Logs is 'n wonderlike ding, maar so ook metrieke. Kombineer hulle en moenie toelaat dat jou stompe asblik word in 'n groot vlammende bal van nutteloosheid nie. Verduidelik en wys die ontwikkelaars hoekom niemand anders hul logs sal verstaan nie, wys hulle hoe dit is om na nuttelose logs om 3:15 in die oggend te kyk.
Skrywer van die foto op
Dis al. Nuwe materiaal sal volgende week vrygestel word. As jy meer oor die kursus wil leer, nooi ons jou uit om , wat Maandag plaasvind. En nou wag ons tradisioneel vir jou kommentaar.
Bron: will.com