Feliĉan vendredon al ĉiuj! Geamikoj, hodiaŭ ni daŭrigas la serion de eldonaĵoj dediĉitaj al la kurso , ĉar klasoj en la nova grupo por la kurso komenciĝos fine de la venonta semajno. Do, ni komencu!
Monitorado estas nur. Ĉi tio estas konata fakto. Alportu Nagios, rulu NRPE sur la fora sistemo, agordu Nagios sur NRPE TCP-haveno 5666 kaj vi havas monitoradon.
Ĝi estas tiel facila, ke ĝi ne estas interesa. Nun vi havas bazajn metrikojn por CPU-tempo, disksubsistemo, RAM, provizitaj defaŭlte al Nagios kaj NRPE. Sed ĉi tio ne estas fakte "monitorado" kiel tia. Ĉi tio estas nur la komenco.
(Kutime ili instalas PNP4Nagios, RRDtool kaj Thruk, starigas sciigojn en Slack kaj iras rekte al nagiosexchange, sed ni lasu tion por nun).
Bona monitorado estas fakte sufiĉe kompleksa, vi vere bezonas scii la internon de la aplikaĵo, kiun vi kontrolas.
Ĉu monitorado estas malfacila?
Ajna servilo, ĉu Linukso aŭ Vindozo, laŭdifine servos al iu celo. Apache, Samba, Tomcat, dosierstokado, LDAP - ĉiuj ĉi tiuj servoj estas pli-malpli unikaj en unu aŭ pluraj aspektoj. Ĉiu havas sian propran funkcion, siajn proprajn trajtojn. Estas malsamaj manieroj akiri metrikojn, KPIojn (ŝlosilajn rendimentajn indikilojn), kiuj estas interesaj por vi kiam la servilo estas ŝarĝita.
Aŭtoro de la foto sur
(Mi deziras, ke miaj instrumentpaneloj estus neonbluaj - revege ĝemante -... hmm...)
Ĉiu programaro kiu provizas servojn devas havi mekanismon por kolekti metrikojn. Apache havas modulon mod-status, montrante la servilan statuspaĝon. Nginx havas - stub_status. Tomcat havas JMX aŭ kutimajn TTT-aplikaĵojn, kiuj montras ŝlosilajn metrikojn. MySQL havas komandon "montri tutmondan statuson" ktp.
Do kial programistoj ne enkonstruas similajn mekanismojn en la aplikaĵojn, kiujn ili kreas?
Ĉu nur programistoj faras tion?
Certa nivelo de indiferenteco al metrika enkonstruado ne estas limigita al programistoj. Mi laboris en kompanioj, kie ili disvolvis aplikaĵojn uzante Tomcat kaj ne disponigis iun ajn el siaj propraj metrikoj, neniujn protokolojn de servo-agado, krom ĝeneralaj erarprotokoloj de Tomcat. Iuj programistoj generas multajn protokolojn, kiuj signifas nenion por la sistemadministranto, kiu estas sufiĉe malbonŝanca legi ilin je 3:15 matene.
Aŭtoro de la foto sur
Sisteminĝenieroj kiuj ebligas tiajn produktojn esti liberigitaj ankaŭ devas porti iom da respondeco pri la situacio. Malmultaj sistemaj inĝenieroj havas la tempon aŭ zorgon por provi ĉerpi signifajn metrikojn el protokoloj, sen la kunteksto de tiuj metrikoj kaj la kapablo interpreti ilin en lumo de aplika agado. Iuj ne komprenas kiel ili povas profiti el ĝi, krom "io estas nuntempe (aŭ baldaŭ estos) malĝusta" indikiloj.
Ŝanĝo en pensado pri la bezono de metriko devas okazi ne nur inter programistoj, sed ankaŭ inter sistemaj inĝenieroj.
Por ajna sistema inĝeniero, kiu bezonas ne nur respondi al kritikaj eventoj, sed ankaŭ certigi, ke ili ne okazas, la manko de metrikoj kutime estas baro por fari tion.
Tamen, sisteminĝenieroj kutime ne tuŝas kodon por gajni monon por sia firmao. Ili bezonas gvidajn programistojn, kiuj komprenas la gravecon de la respondeco de la sistem-inĝeniero por identigi problemojn, konsciigi pri rendimentaj problemoj kaj similaj.
Ĉi tio devops afero
La devops-pensaĵo priskribas la sinergion inter evoluado (dev) kaj operacio (ops) pensado. Ĉiu kompanio, kiu pretendas "fari devopojn" devas:
- dirante aferojn, kiujn ili verŝajne ne faras (rilatante al The Princess Bride-memeo - "Mi ne pensas, ke ĝi signifas tion, kion vi pensas, ke ĝi signifas!")
- Kuraĝigu sintenon de kontinua plibonigo de produktoj.
Vi ne povas plibonigi produkton kaj scii ke ĝi estis plibonigita se vi ne scias kiel ĝi funkcias nuntempe. Vi ne povas scii kiel funkcias produkto, se vi ne komprenas kiel funkcias ĝiaj komponantoj, la servojn, de kiuj ĝi dependas, ĝiaj ĉefaj dolorpunktoj kaj botelpunktoj.
Se vi ne rigardas eblajn botelojn, vi ne povos sekvi la Kvin Kial-teknikon kiam vi verkas Postmortem. Vi ne povos meti ĉion sur unu ekranon por vidi kiel produkto funkcias aŭ scii kiel ĝi aspektas "normala kaj feliĉa".
Movu maldekstren, maldekstren, mi diris: LEEEE—
Por mi, unu el la ĉefaj principoj de Devops estas "movo maldekstre". Ŝanĝi maldekstren en ĉi tiu kunteksto signifas ŝanĝi la eblecon (neniu respondeco, sed nur kapabloj) fari aferojn pri kiuj sisteminĝenieroj tipe zorgas, kiel ekzemple kreado de agado-metrikoj, uzado de tagaloj pli efike, ktp., maldekstren en la Programaro-Livera Vivociklo.
Aŭtoro de la foto sur
Programistoj devas povi uzi kaj koni la monitorajn ilojn, kiujn la kompanio uzas por efektivigi monitoradon en ĉiuj ĝiaj formoj, metrikoj, registradaj, monitoraj interfacoj kaj, plej grave, rigardu kiel ilia produkto funkcias en produktado. Vi ne povas igi programistojn investi penon kaj tempon en monitorado ĝis ili povas vidi la metrikojn kaj influi kiel ili aspektas, kiel la produktposedanto prezentas ilin al la CTO ĉe la venonta informkunveno, ktp.
Mallonge
- Konduku vian ĉevalon al la akvo. Montru al programistoj kiom da problemoj ili povas eviti por si mem, helpu ilin identigi la ĝustajn KPI-ojn kaj metrikojn por siaj aplikoj, por ke estu malpli kriado de la produktposedanto, kiun la CTO krias. Alportu ilin en la lumon, milde kaj trankvile. Se tio ne funkcias, tiam subaĉetu, minacu kaj ŝtolu ilin aŭ la produktposedanton por efektivigi ricevi ĉi tiujn metrikojn de la aplikaĵoj kiel eble plej rapide, kaj poste desegni la diagramojn. Ĉi tio estos malfacila ĉar ĝi ne estos rigardata kiel prioritato kaj la produkta vojmapo havos multajn enspezajn projektojn pritraktatajn. Tial vi bezonos komercan kazon por pravigi la tempon kaj elspezojn elspezitajn por efektivigi monitoradon en la produkton.
- Helpu sisteminĝenierojn akiri bonan noktan dormon. Montru al ili, ke uzi "ni liberigu" kontrolliston por iu ajn produkto estanta liberigita estas bona afero. Kaj certigi, ke ĉiuj aplikaĵoj en produktado estas kovritaj per mezuroj, helpos vin dormi pli bone nokte permesante al programistoj vidi kio misfunkcias kaj kie. Tamen, la ĝusta maniero inciti kaj frustri ajnan programiston, produktposedanton aŭ CTO estas persisti kaj rezisti. Ĉi tiu konduto influos la eldondaton de iu ajn produkto se vi atendas ĝis la lasta minuto denove, do movu denove maldekstren kaj enigu ĉi tiujn problemojn en vian projektan planon kiel eble plej baldaŭ. Se necese, faru vian vojon al produktaj renkontiĝoj. Portu falsajn lipharojn kaj felton aŭ ion, ĝi neniam malsukcesos. Komuniku viajn zorgojn, pruvu klarajn avantaĝojn kaj evangeliu.
- Certigu, ke kaj evoluo (dev) kaj operacioj (ops) komprenas la signifon kaj sekvon de produktaj metrikoj moviĝantaj en la ruĝan zonon. Ne lasu Ops kiel la sola gardanto de produkta sano, certigu, ke ankaŭ programistoj estas implikitaj (#productsquads).
- Registroj estas bonega afero, sed ankaŭ metrikoj. Kombinu ilin kaj ne lasu viajn ŝtipojn fariĝi rubo en grandega flamanta bulo de senutileco. Klarigu kaj montru al la programistoj kial neniu alia komprenos iliajn protokolojn, montru al ili, kiel estas rigardi senutilajn protokolojn je 3:15 matene.
Aŭtoro de la foto sur
Tio estas ĉio. Nova materialo estos publikigita venontsemajne. Se vi ŝatus lerni pli pri la kurso, ni invitas vin , kiu okazos lunde. Kaj nun ni tradicie atendas viajn komentojn.
fonto: www.habr.com