Hyvää perjantaita kaikki! Ystävät, tänään jatkamme kurssille omistettua julkaisusarjaa , koska kurssin uuden ryhmän tunnit alkavat ensi viikon lopulla. Joten, aloitetaan!
Valvonta on vain. Tämä on tunnettu tosiasia. Ota Nagios käyttöön, suorita NRPE etäjärjestelmässä, määritä Nagios NRPE TCP -porttiin 5666 ja sinulla on valvonta.
Se on niin helppoa, ettei se ole kiinnostavaa. Nyt sinulla on perustiedot suorittimen ajasta, levyalijärjestelmästä, RAM-muistista, jotka toimitetaan oletuksena Nagiosille ja NRPE:lle. Mutta tämä ei itse asiassa ole "seurantaa" sellaisenaan. Tämä on vasta alkua.
(Yleensä he asentavat PNP4Nagios, RRDtool ja Thruk, määrittävät ilmoitukset Slackiin ja siirtyvät suoraan nagiosexchangeen, mutta jätetään se pois toistaiseksi).
Hyvä seuranta on itse asiassa melko monimutkainen, sinun on todella tiedettävä valvomasi sovelluksen sisäiset ominaisuudet.
Onko seuranta vaikeaa?
Mikä tahansa palvelin, oli se sitten Linux tai Windows, palvelee määritelmän mukaan jotakin tarkoitusta. Apache, Samba, Tomcat, tiedostojen tallennus, LDAP - kaikki nämä palvelut ovat enemmän tai vähemmän ainutlaatuisia yhdessä tai useammassa suhteessa. Jokaisella on oma tehtävänsä, omat ominaisuutensa. On olemassa erilaisia tapoja saada mittareita, KPI:itä (avain suorituskykyindikaattoreita), jotka kiinnostavat sinua, kun palvelin on kuormitettuna.
Kuvan tekijä päälle
(Toivon, että kojelautani olisivat neonsinisiä - huokaisen unenomaisesti -... hmm...)
Kaikissa palveluita tarjoavissa ohjelmistoissa on oltava mekanismi mittareiden keräämiseksi. Apachessa on moduuli mod-status, joka näyttää palvelimen tilasivun. Nginxillä on - stub_status. Tomcatissa on JMX- tai mukautettuja verkkosovelluksia, jotka näyttävät tärkeimmät tiedot. MySQL:ssä on komento "näytä globaali tila" jne.
Joten miksi kehittäjät eivät rakenna samanlaisia mekanismeja luomiinsa sovelluksiin?
Tekevätkö tämän vain kehittäjät?
Tietty välinpitämättömyys mittareiden upottamista kohtaan ei rajoitu kehittäjiin. Työskentelin yrityksissä, joissa he kehittivät sovelluksia Tomcatilla, eivätkä toimittaneet omia mittareitaan, ei palvelutoimintalokeja, lukuun ottamatta yleisiä Tomcat-virhelokeja. Jotkut kehittäjät luovat paljon lokeja, jotka eivät merkitse mitään järjestelmänvalvojalle, joka ei ole onnekas lukemaan ne kello 3 aamulla.
Kuvan tekijä päälle
Järjestelmäinsinöörien, jotka mahdollistavat tällaisten tuotteiden julkaisun, on myös kannettava jonkin verran vastuuta tilanteesta. Harvalla järjestelmäsuunnittelijalla on aikaa tai huolenpitoa yrittää poimia merkityksellisiä mittareita lokeista ilman näiden mittareiden kontekstia ja kykyä tulkita niitä sovellustoiminnan valossa. Jotkut eivät ymmärrä, miten he voivat hyötyä siitä, paitsi "jotain on tällä hetkellä (tai pian) vialla" -indikaattoreita.
Ajattelun muutos mittareiden tarpeesta ei saa tapahtua vain kehittäjien, vaan myös järjestelmäsuunnittelijoiden keskuudessa.
Kaikille järjestelmäsuunnittelijoille, joiden on paitsi reagoitava kriittisiin tapahtumiin, myös varmistettava, että niitä ei tapahdu, mittareiden puute on yleensä esteenä.
Järjestelmäsuunnittelijat eivät kuitenkaan tavallisesti etsi koodia ansaitakseen rahaa yritykselleen. He tarvitsevat johtavia kehittäjiä, jotka ymmärtävät järjestelmäsuunnittelijan vastuun merkityksen ongelmien tunnistamisessa, tietoisuuden lisäämisessä suorituskykyongelmista ja vastaavissa.
Tämä devops-juttu
Devops-mentaliteetti kuvaa synergiaa kehitys- (dev) ja toiminta-ajattelun (ops) välillä. Kaikkien yritysten, jotka väittävät tekevänsä devopsia, on:
- sanomalla asioita, joita he eivät luultavasti sano (viittaen The Princess Bride -meemiin - "En usko, että se tarkoittaa sitä, mitä luulet sen tarkoittavan!")
- Kannusta asennetta jatkuvaan tuotekehitykseen.
Et voi parantaa tuotetta ja tietää, että sitä on parannettu, jos et tiedä, miten se tällä hetkellä toimii. Et voi tietää, miten tuote toimii, jos et ymmärrä sen komponenttien toimintaa, palveluita, joista se riippuu, sen pääasiallisia kipukohtia ja pullonkauloja.
Jos et tarkkaile mahdollisia pullonkauloja, et voi seurata Five Whys -tekniikkaa postmortemia kirjoittaessasi. Et voi laittaa kaikkea yhdelle näytölle nähdäksesi, miten tuote toimii tai miltä se näyttää "normaalilta ja onnelliselta".
Vaihto vasemmalle, VASEN, SANOIN LEEEE-
Minulle yksi Devopsin keskeisistä periaatteista on "siirto vasemmalle". Siirto vasemmalle tarkoittaa tässä yhteydessä mahdollisuuden siirtämistä (ei vastuuta, mutta vain ominaisuudet) tehdä asioita, joista järjestelmäsuunnittelijat tyypillisesti välittävät, kuten suorituskykymittareiden luominen, lokien tehokkaampi käyttö jne. Ohjelmiston toimituksen elinkaaren vasemmalla puolella.
Kuvan tekijä päälle
Ohjelmistokehittajien tulee osata käyttää ja tuntea yrityksen käyttämiä seurantatyökaluja valvonnan kaikissa muodoissaan, mittareissa, kirjaamisessa, seurantaliittymissä ja mikä tärkeintä, katsoa kuinka heidän tuotteensa toimii tuotannossa. Kehittäjiä ei voi saada panostamaan vaivaa ja aikaa seurantaan, ennen kuin he voivat nähdä mittarit ja vaikuttaa siihen, miltä ne näyttävät, miten tuotteen omistaja esittelee ne CTO:lle seuraavassa tiedotustilaisuudessa jne.
Lyhyesti sanottuna
- Vie hevosesi veteen. Näytä kehittäjille, kuinka paljon ongelmia he voivat välttää itselleen, auta heitä tunnistamaan oikeat KPI:t ja mittarit sovelluksilleen, jotta tuotteen omistaja, jolle CTO huutaa, ei huuda vähemmän. Tuo ne valoon hellästi ja rauhallisesti. Jos tämä ei auta, lahjoita, uhkaile ja houkuttele joko heitä tai tuotteen omistajaa toteuttamaan näiden mittareiden saaminen sovelluksista mahdollisimman nopeasti ja piirrä sitten kaaviot. Tämä on vaikeaa, koska sitä ei pidetä prioriteettina ja tuotesuunnitelmassa on monia tuloja tuottavia projekteja vireillä. Siksi tarvitset liiketoimintaa koskevan perustelun, joka perustelee valvonnan tuomiseen tuotteeseen käytetyn ajan ja kustannukset.
- Auta järjestelmäinsinöörejä nukkumaan hyvät yöunet. Näytä heille, että "vapautetaan" -tarkistuslistan käyttäminen mille tahansa julkaistavalle tuotteelle on hyvä asia. Ja varmistamalla, että kaikki tuotantosovellukset on peitetty mittareilla, auttaa sinua nukkumaan paremmin yöllä, koska kehittäjät voivat nähdä, mikä menee pieleen ja missä. Oikea tapa ärsyttää ja turhauttaa jokaista kehittäjää, tuotteen omistajaa tai teknologiajohtajaa on kuitenkin sinnittää ja vastustaa. Tämä käyttäytyminen vaikuttaa minkä tahansa tuotteen julkaisupäivään, jos odotat jälleen viimeiseen minuuttiin, joten siirry uudelleen vasemmalle ja sisällytä nämä ongelmat projektisuunnitelmaasi mahdollisimman pian. Lähde tarvittaessa tuotekokouksiin. Käytä väärennettyjä viiksiä ja huopaa tai jotain, se ei koskaan petä. Kerro huolenaiheistasi, osoita selkeitä etuja ja evankelioi.
- Varmista, että sekä kehitys (dev) että operaatiot (ops) ymmärtävät tuotteen mittareiden merkityksen ja seuraukset siirtymällä punaiselle alueelle. Älä jätä Opsia tuotteiden terveyden ainoaksi valvojaksi, vaan varmista, että myös kehittäjät ovat mukana (#productsquads).
- Lokit ovat hieno asia, mutta niin ovat myös mittarit. Yhdistä ne äläkä anna tukkien muuttua roskiksi valtavassa liekehtivässä hyödyttömyyden pallossa. Selitä ja näytä kehittäjille, miksi kukaan muu ei ymmärrä heidän lokejaan, näytä heille, millaista on katsoa hyödyttömiä lokeja klo 3 aamulla.
Kuvan tekijä päälle
Siinä kaikki. Uutta materiaalia julkaistaan ensi viikolla. Jos haluat tietää lisää kurssista, kutsumme sinut mukaan , joka järjestetään maanantaina. Ja nyt odotamme perinteisesti kommenttejasi.
Lähde: will.com