Hvorfor bryr ikke ingeniører seg om applikasjonsovervåking?

God fredag ​​alle sammen! Venner, i dag fortsetter vi serien med publikasjoner dedikert til kurset "DevOps-praksis og verktøy", fordi undervisningen i den nye gruppen for kurset starter i slutten av neste uke. Så la oss begynne!

Overvåking er bare. Dette er et kjent faktum. Ta opp Nagios, kjør NRPE på det eksterne systemet, konfigurer Nagios på NRPE TCP-port 5666 og du har overvåking.

Det er så enkelt at det ikke er interessant. Nå har du grunnleggende beregninger for CPU-tid, diskundersystem, RAM, levert som standard til Nagios og NRPE. Men dette er faktisk ikke "overvåking" som sådan. Dette er bare begynnelsen.

(Vanligvis installerer de PNP4Nagios, RRDtool og Thruk, setter opp varsler i Slack og går rett til nagiosexchange, men la oss utelate det for nå).

God overvåking er faktisk ganske komplisert, du trenger virkelig å kjenne til innsiden av applikasjonen du overvåker.

Er overvåking vanskelig?

Enhver server, det være seg Linux eller Windows, vil per definisjon tjene et eller annet formål. Apache, Samba, Tomcat, fillagring, LDAP - alle disse tjenestene er mer eller mindre unike på ett eller flere punkter. Hver har sin egen funksjon, sine egne egenskaper. Det er forskjellige måter å få metrikk, KPIer (key performance indicators), som er interessante for deg når serveren er under belastning.

Forfatter av bildet Luke Chesser på Unsplash

(Jeg skulle ønske dashbordene mine var neonblå - sukket drømmende -... hmm...)

All programvare som tilbyr tjenester må ha en mekanisme for å samle inn beregninger. Apache har en modul mod-status, viser serverstatussiden. Nginx har - stub_status. Tomcat har JMX eller egendefinerte nettapplikasjoner som viser nøkkeltall. MySQL har en kommando "vis global status" osv.
Så hvorfor bygger ikke utviklere lignende mekanismer inn i applikasjonene de lager?

Er det bare utviklere som gjør dette?

En viss grad av likegyldighet til innbygging av beregninger er ikke begrenset til utviklere. Jeg jobbet i selskaper der de utviklet applikasjoner ved hjelp av Tomcat og ga ingen av sine egne beregninger, ingen logger over tjenesteaktivitet, bortsett fra generelle Tomcat-feillogger. Noen utviklere genererer mange logger som ikke betyr noe for systemadministratoren som er så uheldig å lese dem klokken 3:15 om morgenen.

Forfatter av bildet Tim Gouw på Unsplash

Systemingeniører som muliggjør utgivelse av slike produkter må også bære et visst ansvar for situasjonen. Få systemingeniører har tid eller bry seg til å prøve å trekke ut meningsfulle beregninger fra logger, uten konteksten til disse beregningene og muligheten til å tolke dem i lys av applikasjonsaktivitet. Noen forstår ikke hvordan de kan dra nytte av det, annet enn "noe er for øyeblikket (eller vil snart være) galt"-indikatorer.

En endring i tenkningen angående behovet for beregninger må skje ikke bare blant utviklere, men også blant systemingeniører.

For enhver systemingeniør som ikke bare trenger å svare på kritiske hendelser, men også sørge for at de ikke skjer, er mangelen på beregninger vanligvis en barriere for å gjøre det.

Systemingeniører tuller imidlertid vanligvis ikke med kode for å tjene penger for selskapet deres. De trenger ledende utviklere som forstår viktigheten av systemingeniørens ansvar for å identifisere problemer, øke bevisstheten om ytelsesproblemer og lignende.

Dette devoper ting

Devops-mentaliteten beskriver synergien mellom utvikling (dev) og drift (ops) tenkning. Ethvert selskap som hevder å "gjøre devops" må:

1. sier ting de sannsynligvis ikke gjør (refererer til The Princess Bride meme - "Jeg tror ikke det betyr det du tror det betyr!")
2. Oppmuntre til en holdning med kontinuerlig produktforbedring.

Du kan ikke forbedre et produkt og vite at det har blitt forbedret hvis du ikke vet hvordan det fungerer for øyeblikket. Du kan ikke vite hvordan et produkt fungerer hvis du ikke forstår hvordan komponentene fungerer, tjenestene det er avhengig av, dets viktigste smertepunkter og flaskehalser.
Hvis du ikke ser etter potensielle flaskehalser, vil du ikke kunne følge Five Whys-teknikken når du skriver en postmortem. Du vil ikke kunne legge alt på én skjerm for å se hvordan et produkt fungerer eller vite hvordan det ser ut som «normalt og lykkelig».

Skift til venstre, VENSTRE, JEG SA LEEEE—

For meg er et av nøkkelprinsippene til Devops "skift til venstre". Skift til venstre i denne sammenheng betyr å flytte muligheten (intet ansvar, men bare evner) for å gjøre ting som systemingeniører vanligvis bryr seg om, for eksempel å lage ytelsesmålinger, bruke logger mer effektivt osv., til venstre i programvareleveransens livssyklus.

Forfatter av bildet NESA av produsenter på Unsplash

Programvareutviklere må kunne bruke og kjenne overvåkingsverktøyene som selskapet bruker for å utføre overvåking i alle dets former, beregninger, logging, overvåkingsgrensesnitt og, viktigst av alt, se hvordan produktet deres fungerer i produksjon. Du kan ikke få utviklere til å investere krefter og tid i overvåking før de kan se beregningene og påvirke hvordan de ser ut, hvordan produkteieren presenterer dem for CTO ved neste briefing, osv.

Kort oppsummert

1. Led hesten din til vannet. Vis utviklere hvor mye trøbbel de kan unngå selv, hjelp dem med å identifisere de riktige KPIene og beregningene for applikasjonene deres, slik at det blir mindre rop fra produkteieren som blir ropt på av CTO. Ta dem inn i lyset, forsiktig og rolig. Hvis det ikke fungerer, bestikke, true og overtale enten dem eller produkteieren til å implementere å hente disse beregningene fra applikasjonene så raskt som mulig, og deretter tegne diagrammene. Dette vil være vanskelig siden det ikke vil bli sett på som en prioritet, og produktveikartet vil ha mange inntektsgenererende prosjekter under behandling. Derfor vil du trenge en business case for å rettferdiggjøre tiden og kostnadene som brukes på å implementere overvåking i produktet.
2. Hjelp systemingeniører med å få en god natts søvn. Vis dem at det er en god ting å bruke en "la oss slippe"-sjekkliste for ethvert produkt som slippes. Og å sørge for at alle applikasjoner i produksjon er dekket med beregninger vil hjelpe deg å sove bedre om natten ved å la utviklere se hva som går galt og hvor. Den riktige måten å irritere og frustrere enhver utvikler, produkteier eller CTO på er imidlertid å vedvare og motstå. Denne oppførselen vil påvirke utgivelsesdatoen til ethvert produkt hvis du venter til siste minutt igjen, så flytt til venstre igjen og få disse problemene inn i prosjektplanen din så snart som mulig. Ta om nødvendig veien til produktmøter. Bruk en falsk bart og filt eller noe, det vil aldri svikte. Kommuniser bekymringene dine, vis klare fordeler og evangeliser.
3. Sørg for at både utvikling (dev) og drift (ops) forstår betydningen og konsekvensen av at produktmålinger beveger seg inn i den røde sonen. Ikke la Ops være den eneste vokteren av produkthelsen, sørg for at utviklerne også er involvert (#productsquads).
4. Logger er en flott ting, men det er beregninger også. Kombiner dem og ikke la tømmerstokkene dine bli søppel i en enorm flammende ball av ubrukelighet. Forklar og vis utviklerne hvorfor ingen andre vil forstå loggene deres, vis dem hvordan det er å se på ubrukelige logger klokken 3:15 om morgenen.

Forfatter av bildet Marko Horvat på Unsplash

Det er alt. Nytt materiale vil bli sluppet neste uke. Ønsker du å lære mer om kurset, inviterer vi deg til Åpen dag, som finner sted på mandag. Og nå venter vi tradisjonelt på kommentarene dine.

Kilde: www.habr.com