God fredag allesammen! Venner, i dag fortsætter vi rækken af publikationer dedikeret til kurset , fordi undervisningen i den nye gruppe for kurset starter i slutningen af næste uge. Så lad os begynde!
Overvågning er bare. Dette er et kendt faktum. Hent Nagios, kør NRPE på fjernsystemet, konfigurer Nagios på NRPE TCP-port 5666, og du har overvågning.
Det er så nemt, at det ikke er interessant. Nu har du grundlæggende målinger for CPU-tid, diskundersystem, RAM, leveret som standard til Nagios og NRPE. Men dette er faktisk ikke "overvågning" som sådan. Dette er blot begyndelsen.
(Normalt installerer de PNP4Nagios, RRDtool og Thruk, sætter notifikationer op i Slack og går direkte til nagiosexchange, men lad os lade det være for nu).
God overvågning er faktisk ret kompleks, du har virkelig brug for at kende det interne af den applikation, du overvåger.
Er overvågning vanskelig?
Enhver server, det være sig Linux eller Windows, vil per definition tjene et eller andet formål. Apache, Samba, Tomcat, fillagring, LDAP - alle disse tjenester er mere eller mindre unikke i en eller flere henseender. Hver har sin egen funktion, sine egne karakteristika. Der er forskellige måder at få metrics, KPI'er (key performance indicators), som er interessante for dig, når serveren er under belastning.
Forfatter til billedet på
(Jeg ville ønske, at mine dashboards var neonblå - sukkede drømmende -... hmm...)
Enhver software, der leverer tjenester, skal have en mekanisme til at indsamle metrics. Apache har et modul mod-status, viser serverstatussiden. Nginx har - stub_status. Tomcat har JMX eller brugerdefinerede webapplikationer, der viser nøglemålinger. MySQL har en kommando "vis global status" osv.
Så hvorfor bygger udviklere ikke lignende mekanismer ind i de applikationer, de laver?
Er det kun udviklere, der gør dette?
En vis grad af ligegyldighed over for indlejring af metrics er ikke begrænset til udviklere. Jeg arbejdede i virksomheder, hvor de udviklede applikationer ved hjælp af Tomcat og ikke leverede nogen af deres egne metrics, ingen logs over serviceaktivitet, bortset fra generelle Tomcat-fejllogs. Nogle udviklere genererer en masse logfiler, der ikke betyder noget for systemadministratoren, som er så uheldig at læse dem klokken 3:15 om morgenen.
Forfatter til billedet på
Systemingeniører, der gør det muligt at frigive sådanne produkter, skal også bære et vist ansvar for situationen. Få systemingeniører har tid eller omsorg til at forsøge at udtrække meningsfulde målinger fra logfiler uden konteksten af disse målinger og evnen til at fortolke dem i lyset af applikationsaktivitet. Nogle forstår ikke, hvordan de kan drage fordel af det, bortset fra "noget er i øjeblikket (eller vil snart være) galt"-indikatorer.
En ændring i tankegangen vedrørende behovet for metrikker skal ikke kun ske blandt udviklere, men også blandt systemingeniører.
For enhver systemingeniør, der ikke kun skal reagere på kritiske hændelser, men også sikre, at de ikke opstår, er manglen på målinger normalt en barriere for at gøre det.
Systemingeniører roder dog typisk ikke med kode for at tjene penge til deres virksomhed. De har brug for ledende udviklere, der forstår vigtigheden af systemingeniørens ansvar for at identificere problemer, øge bevidstheden om præstationsproblemer og lignende.
Det her devoperer ting
Devops mentaliteten beskriver synergien mellem udvikling (dev) og operations (ops) tænkning. Enhver virksomhed, der hævder at "gøre devops" skal:
- siger ting, de sandsynligvis ikke gør (med henvisning til The Princess Bride meme - "Jeg tror ikke, det betyder, hvad du tror, det betyder!")
- Opmuntre til en holdning med løbende produktforbedring.
Du kan ikke forbedre et produkt og vide, at det er blevet forbedret, hvis du ikke ved, hvordan det fungerer i øjeblikket. Du kan ikke vide, hvordan et produkt fungerer, hvis du ikke forstår, hvordan dets komponenter fungerer, de tjenester, det afhænger af, dets vigtigste smertepunkter og flaskehalse.
Hvis du ikke holder øje med potentielle flaskehalse, vil du ikke være i stand til at følge Five Whys-teknikken, når du skriver en postmortem. Du vil ikke være i stand til at lægge alt på én skærm for at se, hvordan et produkt fungerer eller vide, hvordan det ser ud "normalt og glad."
Skift til venstre, til venstre, jeg sagde LEEEE—
For mig er et af nøgleprincipperne i Devops "skift til venstre". Skift til venstre betyder i denne sammenhæng at flytte muligheden (intet ansvar, men kun kapaciteter) til at gøre ting, som systemingeniører typisk interesserer sig for, f.eks. at skabe ydeevnemålinger, bruge logs mere effektivt osv., til venstre i Software Delivery Life Cycle.
Forfatter til billedet på
Softwareudviklere skal kunne bruge og kende de overvågningsværktøjer, som virksomheden anvender til at udføre overvågning i alle dens former, målinger, logning, overvågningsgrænseflader og, vigtigst af alt, se, hvordan deres produkt fungerer i produktionen. Du kan ikke få udviklere til at investere kræfter og tid i overvågning, før de kan se metrikken og påvirke, hvordan de ser ud, hvordan produktejeren præsenterer dem for CTO'en ved næste briefing osv.
Kort sagt
- Før din hest til vandet. Vis udviklere, hvor meget besvær de selv kan undgå, hjælp dem med at identificere de rigtige KPI'er og målinger for deres applikationer, så der er mindre råben fra produktejeren, som bliver råbt af CTO'en. Bring dem forsigtigt og roligt frem i lyset. Hvis det ikke virker, så bestikke, true og overtale enten dem eller produktejeren til at implementere at få disse målinger fra applikationerne så hurtigt som muligt, og derefter tegne diagrammerne. Dette vil være svært, da det ikke vil blive opfattet som en prioritet, og produktkøreplanen vil have mange indtægtsskabende projekter under behandling. Derfor skal du bruge en business case for at retfærdiggøre den tid og de udgifter, der er brugt på at implementere overvågning i produktet.
- Hjælp systemingeniører med at få en god nats søvn. Vis dem, at det er en god ting at bruge en "lad os frigive"-tjekliste for ethvert produkt, der udgives. Og at sikre, at alle applikationer i produktionen er dækket af metrics, vil hjælpe dig med at sove bedre om natten ved at give udviklere mulighed for at se, hvad der går galt, og hvor. Men den rigtige måde at irritere og frustrere enhver udvikler, produktejer eller CTO på er at vedholde og modstå. Denne adfærd vil påvirke udgivelsesdatoen for ethvert produkt, hvis du venter til sidste øjeblik igen, så skift til venstre igen og få disse problemer ind i din projektplan så hurtigt som muligt. Gå om nødvendigt til produktmøder. Bær et falsk overskæg og filt eller noget, det vil aldrig fejle. Kommuniker dine bekymringer, demonstrer klare fordele, og evangeliser.
- Sørg for, at både udvikling (dev) og drift (ops) forstår betydningen og konsekvensen af, at produktmålinger bevæger sig ind i den røde zone. Forlad ikke Ops som den eneste vogter af produktsundhed, sørg for, at udviklere også er involveret (#productsquads).
- Logfiler er en fantastisk ting, men det er metrics også. Kombiner dem og lad ikke dine træstammer blive affald i en enorm flammende kugle af ubrugelighed. Forklar og vis udviklerne, hvorfor ingen andre vil forstå deres logfiler, vis dem, hvordan det er at se på ubrugelige logfiler klokken 3:15 om morgenen.
Forfatter til billedet på
Det er alt. Nyt materiale udkommer i næste uge. Hvis du gerne vil vide mere om kurset, inviterer vi dig til , som finder sted på mandag. Og nu venter vi traditionelt på dine kommentarer.
Kilde: www.habr.com