Varför bryr sig ingenjörer om applikationsövervakning?

Glad fredag ​​allihopa! Vänner, idag fortsätter vi serien av publikationer som är tillägnad kursen "DevOps praxis och verktyg", eftersom klasserna i den nya gruppen för kursen börjar i slutet av nästa vecka. Så, låt oss börja!

Övervakning är bara. Detta är ett känt faktum. Ta fram Nagios, kör NRPE på fjärrsystemet, konfigurera Nagios på NRPE TCP-port 5666 och du har övervakning.

Det är så lätt att det inte är intressant. Nu har du grundläggande mätvärden för CPU-tid, diskundersystem, RAM-minne, levererad som standard till Nagios och NRPE. Men detta är faktiskt inte "övervakning" som sådan. Detta är bara början.

(Vanligtvis installerar de PNP4Nagios, RRDtool och Thruk, ställer in aviseringar i Slack och går direkt till nagiosexchange, men låt oss utelämna det för nu).

Bra övervakning är faktiskt ganska komplicerat, du behöver verkligen känna till det interna i programmet du övervakar.

Är övervakning svårt?

Vilken server som helst, oavsett om det är Linux eller Windows, kommer per definition att tjäna något syfte. Apache, Samba, Tomcat, fillagring, LDAP – alla dessa tjänster är mer eller mindre unika i ett eller flera avseenden. Var och en har sin egen funktion, sina egna egenskaper. Det finns olika sätt att få mätvärden, KPI:er (key performance indicators), som är intressanta för dig när servern är under belastning.

Författare till fotot Luke Chesser på Unsplash

(Jag önskar att mina instrumentbrädor var neonblå - suckade drömmande -... hmm...)

All programvara som tillhandahåller tjänster måste ha en mekanism för att samla in mätvärden. Apache har en modul mod-status, visar serverstatussidan. Nginx har - stub_status. Tomcat har JMX eller anpassade webbapplikationer som visar nyckelmått. MySQL har ett kommando "visa global status" osv.
Så varför bygger inte utvecklare in liknande mekanismer i applikationerna de skapar?

Är det bara utvecklare som gör detta?

En viss nivå av likgiltighet för inbäddning av mätvärden är inte begränsad till utvecklare. Jag arbetade i företag där de utvecklade applikationer med Tomcat och tillhandahöll inga egna mätvärden, inga loggar över tjänsteaktivitet, förutom allmänna Tomcat-felloggar. Vissa utvecklare genererar många loggar som inte betyder något för systemadministratören som har otur att läsa dem klockan 3:15 på morgonen.

Författare till fotot Tim Gouw på Unsplash

Systemingenjörer som möjliggör att sådana produkter kan släppas måste också bära ett visst ansvar för situationen. Få systemingenjörer har tid eller omsorg att försöka extrahera meningsfulla mätvärden från loggar, utan sammanhanget för dessa mätvärden och förmågan att tolka dem i ljuset av applikationsaktivitet. Vissa förstår inte hur de kan dra nytta av det, annat än "något är för närvarande (eller kommer snart att vara) fel"-indikatorer.

En förändring i tänkandet om behovet av mått måste ske inte bara bland utvecklare utan även bland systemingenjörer.

För alla systemingenjörer som inte bara behöver svara på kritiska händelser, utan också se till att de inte inträffar, är bristen på mätvärden vanligtvis ett hinder för att göra det.

Systemingenjörer pysslar dock vanligtvis inte med kod för att tjäna pengar till sitt företag. De behöver ledande utvecklare som förstår vikten av systemingenjörens ansvar för att identifiera problem, öka medvetenheten om prestandaproblem och liknande.

Det här försvinner

Devops-mentaliteten beskriver synergin mellan utvecklings- (dev) och operations- (ops) tänkande. Alla företag som påstår sig "göra devops" måste:

1. säger saker de förmodligen inte gör (med hänvisning till The Princess Bride meme - "Jag tror inte att det betyder vad du tror att det betyder!")
2. Uppmuntra en attityd av kontinuerlig produktförbättring.

Du kan inte förbättra en produkt och veta att den har förbättrats om du inte vet hur den fungerar för närvarande. Du kan inte veta hur en produkt fungerar om du inte förstår hur dess komponenter fungerar, vilka tjänster den är beroende av, dess huvudsakliga smärtpunkter och flaskhalsar.
Om du inte ser efter potentiella flaskhalsar, kommer du inte att kunna följa Five Whys-tekniken när du skriver en postmortem. Du kommer inte att kunna lägga allt på en skärm för att se hur en produkt fungerar eller veta hur den ser ut "normal och glad."

Skift åt vänster, VÄNSTER, JAG SADE LEEEE—

För mig är en av nyckelprinciperna för Devops "växling åt vänster". Växla åt vänster i detta sammanhang innebär att flytta möjligheten (inget ansvar, men bara kapacitet) för att göra saker som systemingenjörer vanligtvis bryr sig om, som att skapa prestandamått, använda loggar mer effektivt, etc., till vänster i Software Delivery Life Cycle.

Författare till fotot NESA av Makers på Unsplash

Mjukvaruutvecklare måste kunna använda och känna till de övervakningsverktyg som företaget använder för att utföra övervakning i alla dess former, mått, loggning, övervakningsgränssnitt och, viktigast av allt, se hur deras produkt fungerar i produktionen. Du kan inte få utvecklare att investera kraft och tid i övervakning förrän de kan se mätvärdena och påverka hur de ser ut, hur produktägaren presenterar dem för CTO vid nästa genomgång, etc.

Kort sagt

1. Led din häst till vattnet. Visa utvecklare hur mycket problem de själva kan undvika, hjälp dem att identifiera rätt KPI:er och mätvärden för sina applikationer så att det blir mindre skrik från produktägaren som ropas på av CTO. Ta fram dem i ljuset, försiktigt och lugnt. Om det inte fungerar, muta, hota och övertala antingen dem eller produktägaren att implementera att hämta dessa mätvärden från applikationerna så snabbt som möjligt och rita sedan diagrammen. Detta kommer att bli svårt eftersom det inte kommer att ses som en prioritet och produktfärdplanen kommer att ha många intäktsgenererande projekt på gång. Därför kommer du att behöva ett affärscase för att motivera tiden och kostnaderna för att implementera övervakning i produkten.
2. Hjälp systemingenjörer att få en god natts sömn. Visa dem att det är bra att använda en checklista "låt oss släppa" för alla produkter som släpps. Och att se till att alla applikationer i produktionen är täckta med mätvärden hjälper dig att sova bättre på natten genom att tillåta utvecklare att se vad som går fel och var. Men det rätta sättet att irritera och frustrera alla utvecklare, produktägare eller CTO är att envisa och göra motstånd. Detta beteende kommer att påverka lanseringsdatumet för alla produkter om du väntar till sista minuten igen, så byt vänster igen och få in dessa problem i din projektplan så snart som möjligt. Vid behov, ta dig till produktmöten. Bär en falsk mustasch och filt eller något, det kommer aldrig att misslyckas. Kommunicera dina bekymmer, visa tydliga fördelar och evangelisera.
3. Se till att både utveckling (dev) och drift (ops) förstår innebörden och konsekvensen av att produktmått flyttas in i den röda zonen. Lämna inte Ops som den enda väktaren av produktens hälsa, se till att utvecklare också är inblandade (#productsquads).
4. Loggar är en fantastisk sak, men det är även mått. Kombinera dem och låt inte dina stockar bli skräp i en enorm flammande boll av värdelöshet. Förklara och visa utvecklarna varför ingen annan kommer att förstå deras loggar, visa dem hur det är att titta på värdelösa loggar klockan 3:15 på morgonen.

Författare till fotot Marko Horvat på Unsplash

Det är allt. Nytt material kommer att släppas nästa vecka. Om du vill lära dig mer om kursen, bjuder vi in ​​dig Öppen dag, som äger rum på måndag. Och nu väntar vi traditionellt på dina kommentarer.

Källa: will.com