🥇 Är övervakningen död? — Länge leve övervakning

Sedan 2008 har vårt företag främst varit engagerat i infrastrukturhantering och teknisk support dygnet runt för webbprojekt: vi har mer än 400 kunder, vilket är cirka 15 % av rysk e-handel. Följaktligen stöds en mycket varierad arkitektur. Om något faller är vi skyldiga att åtgärda det inom 15 minuter. Men för att förstå att en olycka har inträffat måste du övervaka projektet och reagera på incidenter. Hur gor man det har?

Jag anser att det finns ett problem med att organisera ett ordentligt övervakningssystem. Om det inte hade varit några problem skulle mitt tal bestå av en tes: "Vänligen installera Prometheus + Grafana och plugins 1, 2, 3." Tyvärr fungerar det inte så längre. Och huvudproblemet är att alla fortsätter att tro på något som fanns 2008, vad gäller mjukvarukomponenter.

Angående organisationen av övervakningssystemet skulle jag våga påstå att... projekt med kompetent övervakning inte existerar. Och situationen är så dålig att om något faller finns det risk att det går obemärkt förbi - alla är trots allt säkra på att "allt övervakas."
Kanske övervakas allt. Men hur?

Vi har alla stött på en historia som följande: en viss devops, en viss administratör arbetar, ett utvecklingsteam kommer till dem och säger - "vi är släppta, övervaka nu." Övervaka vad? Hur det fungerar?

OK. Vi övervakar det gammalmodiga sättet. Och det håller redan på att förändras, och det visar sig att du övervakade tjänst A, som blev tjänst B, som interagerar med tjänst C. Men utvecklingsteamet säger till dig: "Installera programvaran, den borde övervaka allt!"

Så vad har förändrats? - Allt har förändrats!

2008 Allt är bra

Det finns ett par utvecklare, en server, en databasserver. Allt går härifrån. Vi har lite information, vi installerar zabbix, Nagios, kaktusar. Och sedan ställer vi in tydliga varningar på CPU, om diskdrift och om diskutrymme. Vi gör även ett par manuella kontroller för att säkerställa att sajten svarar och att beställningar kommer in i databasen. Och det är det – vi är mer eller mindre skyddade.

Om vi jämför mängden arbete som administratören gjorde då för att tillhandahålla övervakning, så var 98% av det automatiskt: personen som gör övervakningen måste förstå hur man installerar Zabbix, hur man konfigurerar det och konfigurerar varningar. Och 2% - för externa kontroller: att sajten svarar och gör en förfrågan till databasen, att nya beställningar har kommit.

2010 Belastningen växer

Vi börjar skala webben och lägga till en sökmotor. Vi vill se till att produktkatalogen innehåller alla produkter. Och den produktsökningen fungerar. Att databasen fungerar, att beställningar görs, att sajten svarar externt och svarar från två servrar och att användaren inte sparkas ut från sajten medan den balanseras om till en annan server osv. Det finns fler enheter.

Dessutom är den enhet som är kopplad till infrastruktur fortfarande den största i chefens huvud. Det finns fortfarande en idé i mitt huvud att den som gör övervakningen är den som ska installera zabbix och kunna konfigurera den.

Men samtidigt dyker det upp arbete med att utföra externa kontroller, med att skapa en uppsättning sökindexeringsfrågeskript, en uppsättning skript för att kontrollera att sökningen ändras under indexeringsprocessen, en uppsättning skript som kontrollerar att varor överförs till leveransservice etc. och så vidare.

Notera: Jag skrev "en uppsättning skript" 3 gånger. Det vill säga att den som ansvarar för övervakningen inte längre är den som bara installerar zabbix. Det här är en person som börjar koda. Men inget har förändrats i lagets tankar ännu.

Men världen förändras, blir mer och mer komplex. Ett virtualiseringslager och flera nya system tillkommer. De börjar interagera med varandra. Vem sa "luktar som mikrotjänster?" Men varje tjänst ser fortfarande ut som en webbplats individuellt. Vi kan vända oss till den och förstå att den ger nödvändig information och fungerar på egen hand. Och om du är en administratör som ständigt är involverad i ett projekt som har utvecklats i 5-7-10 år, ackumuleras denna kunskap: en ny nivå dyker upp - du insåg det, en annan nivå dyker upp - du insåg det...

Men sällan följer någon med ett projekt på 10 år.

Monitoringmans CV

Anta att du kom till en ny start som omedelbart anställde 20 utvecklare, skrev 15 mikrotjänster och att du är en administratör som får höra: "Bygg CI/CD. Snälla du." Du har byggt CI/CD och plötsligt hör du: "Det är svårt för oss att arbeta med produktion i en "kub", utan att förstå hur applikationen kommer att fungera i den. Gör oss en sandlåda i samma "kub".
Du gör en sandlåda i den här kuben. De säger direkt till dig: "Vi vill ha en scendatabas som uppdateras varje dag från produktionen, så att vi förstår att den fungerar på databasen, men samtidigt inte förstör produktionsdatabasen."

Du lever i allt detta. Det är 2 veckor kvar innan släppet, de säger till dig: "Låt oss nu övervaka allt detta..." Det vill säga. övervaka klusterinfrastrukturen, övervaka mikrotjänstarkitekturen, övervaka arbete med externa tjänster...

Och mina kollegor tar det vanliga upplägget ur sina huvuden och säger: ”Jaha, här är allt klart! Installera ett program som övervakar allt detta.” Ja, ja: Prometheus + Grafana + plugins.
Och de tillägger: "Du har två veckor på dig, se till att allt är säkert."

I många projekt som vi ser är en person tilldelad för övervakning. Föreställ dig att vi vill anställa en person för att göra övervakning i 2 veckor, och vi skriver ett CV för honom. Vilka färdigheter ska den här personen ha, med tanke på allt vi har sagt hittills?

Han måste förstå övervakningen och detaljerna i driften av järninfrastrukturen.
Han måste förstå detaljerna i att övervaka Kubernetes (och alla vill gå till "kuben", eftersom du kan abstrahera från allt, gömma sig, eftersom administratören kommer att ta itu med resten) - sig själv, dess infrastruktur och förstå hur man övervakar applikationer inuti.
Han måste förstå att tjänster kommunicerar med varandra på speciella sätt och känna till detaljerna i hur tjänster interagerar med varandra. Det är fullt möjligt att se ett projekt där vissa tjänster kommunicerar synkront, eftersom det inte finns något annat sätt. Till exempel går backend via REST, via gRPC till katalogtjänsten, tar emot en lista över produkter och returnerar den tillbaka. Du kan inte vänta här. Och med andra tjänster fungerar det asynkront. Överför beställningen till leveranstjänsten, skicka brev osv.
Du har säkert redan simmat från allt det här? Och administratören, som behöver övervaka detta, blev ännu mer förvirrad.
Han måste kunna planera och planera rätt – allt eftersom arbetet blir mer och mer.
Han måste därför skapa en strategi från den skapade tjänsten för att förstå hur man specifikt övervakar den. Han behöver en förståelse för projektets arkitektur och dess utveckling + en förståelse för de teknologier som används i utvecklingen.

Låt oss komma ihåg ett helt normalt fall: vissa tjänster är i PHP, vissa tjänster är i Go, vissa tjänster är i JS. De jobbar på något sätt med varandra. Det är härifrån termen "mikroservice" kommer: det finns så många individuella system att utvecklare inte kan förstå projektet som helhet. En del av teamet skriver tjänster i JS som fungerar på egen hand och som inte vet hur resten av systemet fungerar. Den andra delen skriver tjänster i Python och stör inte hur andra tjänster fungerar, de är isolerade i sitt eget område. Den tredje är skrivtjänster i PHP eller något annat.
Alla dessa 20 personer är indelade i 15 tjänster, och det finns bara en administratör som måste förstå allt detta. Sluta! vi delar bara upp systemet i 15 mikrotjänster eftersom 20 personer inte kan förstå hela systemet.

Men det måste övervakas på något sätt...

Vad är resultatet? Som ett resultat är det en person som kommer på allt som hela teamet av utvecklare inte kan förstå, och samtidigt måste han också veta och kunna göra det vi angav ovan - hårdvaruinfrastruktur, Kubernetes-infrastruktur, etc.

Vad kan jag säga... Houston, vi har problem.

Att övervaka ett modernt mjukvaruprojekt är ett mjukvaruprojekt i sig

Från den falska övertygelsen att övervakning är mjukvara, utvecklar vi en tro på mirakel. Men mirakel, tyvärr, händer inte. Du kan inte installera zabbix och förvänta dig att allt ska fungera. Det är ingen idé att installera Grafana och hoppas att allt ska ordna sig. Merparten av tiden kommer att läggas på att organisera kontroller av driften av tjänster och deras interaktion med varandra, kontrollera hur externa system fungerar. Faktum är att 90 % av tiden inte går åt till att skriva manus, utan på att utveckla mjukvara. Och det ska hanteras av ett team som förstår projektets arbete.
Om en person i den här situationen kastas in i övervakningen kommer en katastrof att hända. Vilket är vad som händer överallt.

Det finns till exempel flera tjänster som kommunicerar med varandra via Kafka. Beställningen kom, vi skickade ett meddelande om beställningen till Kafka. Det finns en tjänst som lyssnar på information om beställningen och skickar varorna. Det finns en tjänst som lyssnar på information om beställningen och skickar ett brev till användaren. Och så dyker det upp en massa fler tjänster och vi börjar bli förvirrade.

Och om du också ger detta till administratören och utvecklarna i det skede när det är en kort tid kvar innan releasen kommer personen att behöva förstå hela detta protokoll. De där. Ett projekt i denna skala tar en betydande tid i anspråk, och detta bör tas med i systemutvecklingen.
Men väldigt ofta, särskilt i startups, ser vi hur övervakning skjuts upp till senare. "Nu ska vi göra ett Proof of Concept, vi kommer att lansera med det, låta det falla - vi är redo att offra. Och sedan kommer vi att övervaka det hela.” När (eller om) projektet börjar tjäna pengar vill verksamheten lägga till ännu fler funktioner – eftersom det har börjat fungera, så det behöver rullas ut ytterligare! Och du är vid den punkt där du först måste övervaka allt tidigare, vilket inte tar 1% av tiden, utan mycket mer. Och förresten, utvecklare kommer att behövas för övervakning, och det är lättare att låta dem arbeta med nya funktioner. Som ett resultat skrivs nya funktioner, allt blir snett och du befinner dig i ett oändligt dödläge.

Så hur övervakar man ett projekt från början, och vad ska man göra om du får ett projekt som behöver övervakas, men du inte vet var du ska börja?

Först måste du planera.

Lyrisk utvikning: mycket ofta börjar de med infrastrukturövervakning. Vi har till exempel Kubernetes. Låt oss börja med att installera Prometheus med Grafana, installera plugins för att övervaka "kuben". Inte bara utvecklare, utan även administratörer har den olyckliga praxisen att: "Vi installerar det här pluginet, men pluginet vet förmodligen hur man gör det." Människor gillar att börja med det enkla och okomplicerade, snarare än med de viktiga åtgärderna. Och infrastrukturövervakning är lätt.

Bestäm först vad och hur du vill övervaka och välj sedan ett verktyg, eftersom andra inte kan tänka åt dig. Och borde de? Andra människor tänkte för sig själva, om ett universellt system - eller tänkte inte alls när detta plugin skrevs. Och bara för att detta plugin har 5 tusen användare betyder det inte att det är till någon nytta. Kanske kommer du att bli den 5001:a bara för att det redan fanns 5000 personer där tidigare.

Om du börjar övervaka infrastrukturen och din applikations backend slutar svara, kommer alla användare att förlora anslutningen till mobilapplikationen. Ett fel kommer att visas. De kommer till dig och säger "Applikationen fungerar inte, vad gör du här?" – Vi övervakar. — "Hur övervakar du om du inte ser att applikationen inte fungerar?!"

Jag tror att du måste börja övervaka exakt från användarens ingångspunkt. Om användaren inte ser att applikationen fungerar, är det det, det är ett misslyckande. Och övervakningssystemet bör varna för detta först.
Och först då kan vi övervaka infrastrukturen. Eller gör det parallellt. Det är enklare med infrastruktur - här kan vi äntligen bara installera zabbix.
Och nu måste du gå till rötterna av applikationen för att förstå var saker och ting inte fungerar.

Min huvudtanke är att övervakningen ska gå parallellt med utvecklingsprocessen. Om du distraherar övervakningsteamet för andra uppgifter (skapa CI/CD, sandlådor, omorganisation av infrastruktur), kommer övervakningen att börja släpa och du kanske aldrig kommer ikapp utvecklingen (eller förr eller senare måste du stoppa den).

Allt efter nivåer

Så ser jag på organisationen av ett övervakningssystem.

1) Applikationsnivå:

övervakning av applikationens affärslogik;
övervakning av hälsomått för tjänster;
integrationsövervakning.

2) Infrastrukturnivå:

övervakning av orkestreringsnivå;
övervakning av systemprogramvara;
övervakning av järnnivån.

3) Återigen applikationsnivån - men som en ingenjörsprodukt:

samla in och övervaka applikationsloggar;
APM;
spårning.

4) Varning:

organisation av ett varningssystem;
organisation av ett tjänstesystem;
organisation av en ”kunskapsbas” och arbetsflöde för incidenthantering.

Det är viktigt: vi kommer till larmet inte efter, utan direkt! Det finns ingen anledning att starta övervakning och "på något sätt senare" ta reda på vem som kommer att få varningar. När allt kommer omkring, vad är uppgiften att övervaka: att förstå var i systemet något fungerar fel, och att låta rätt personer veta om det. Om du lämnar detta till slutet kommer de rätta personerna att veta att något går fel bara genom att kalla "ingenting fungerar för oss."

Application Layer - Business Logic Monitoring

Här pratar vi om att kontrollera själva det faktum att applikationen fungerar för användaren.

Denna nivå bör göras under utvecklingsfasen. Till exempel har vi en villkorlig Prometheus: den går till servern som gör kontrollerna, drar slutpunkten och slutpunkten går och kontrollerar API.

När de ofta uppmanas att övervaka hemsidan för att se till att sajten fungerar, ger programmerare ett handtag som kan dras varje gång de behöver för att se till att API:et fungerar. Och programmerare för närvarande tar och skriver fortfarande /api/test/helloworld
Det enda sättet att se till att allt fungerar? - Nej!

Att skapa sådana kontroller är i huvudsak utvecklarnas uppgift. Enhetstest ska skrivas av de programmerare som skriver koden. För om du läcker det till administratören, "Dude, här är en lista över API-protokoll för alla 25 funktioner, vänligen övervaka allt!" - ingenting kommer att lösa sig.
Om du skriver ut "hej världen" kommer ingen någonsin att veta att API:t borde och fungerar. Varje API-ändring måste leda till en förändring i kontroller.
Om du redan har ett sådant problem, stoppa funktionerna och tilldela utvecklare som kommer att skriva dessa kontroller, eller acceptera förlusterna, acceptera att ingenting är kontrollerat och kommer att misslyckas.

Tekniska tips:

Se till att organisera en extern server för att organisera kontroller – du måste vara säker på att ditt projekt är tillgängligt för omvärlden.
Organisera kontroller över hela API-protokollet, inte bara enskilda slutpunkter.
Skapa en prometheus-slutpunkt med testresultaten.

Applikationslager - övervakning av hälsomått

Nu pratar vi om externa hälsomått för tjänster.

Vi bestämde oss för att övervaka alla "handtag" i applikationen med hjälp av externa kontroller, som vi anropar från ett externt övervakningssystem. Men det här är "handtagen" som användaren "ser". Vi vill vara säkra på att våra tjänster i sig fungerar. Det finns en bättre historia här: K8s har hälsokontroller, så att åtminstone "kuben" själv kan övertygas om att tjänsten fungerar. Men hälften av kontrollerna jag har sett är samma tryck "hej världen". De där. Så han drar en gång efter utplaceringen, han svarade att allt är bra - det är allt. Och tjänsten, om den tillhandahåller sitt eget API, har ett stort antal ingångspunkter för samma API, som också måste övervakas, eftersom vi vill veta att det fungerar. Och vi övervakar det redan inuti.

Hur man implementerar detta korrekt tekniskt: varje tjänst exponerar en slutpunkt om dess nuvarande prestanda, och i graferna för Grafana (eller någon annan applikation) ser vi statusen för alla tjänster.

Varje API-ändring måste leda till en förändring i kontroller.
Skapa en ny tjänst direkt med hälsostatistik.
En administratör kan komma till utvecklarna och fråga "lägg till mig ett par funktioner så att jag förstår allt och lägg till information om detta till mitt övervakningssystem." Men utvecklare brukar svara: "Vi kommer inte att lägga till något två veckor före releasen."
Låt utvecklingscheferna veta att det kommer att bli sådana förluster, låt utvecklingschefernas ledning veta också. För när allt faller kommer någon fortfarande att ringa och kräva att få övervaka den "ständigt fallande tjänsten" (c)
Förresten, tilldela utvecklare att skriva plugins för Grafana - detta kommer att vara en bra hjälp för administratörer.

Application Layer - Integrationsövervakning

Integrationsövervakning fokuserar på att övervaka kommunikation mellan affärskritiska system.

Det finns till exempel 15 tjänster som kommunicerar med varandra. Dessa är inte längre separata webbplatser. De där. vi kan inte dra tjänsten på egen hand, skaffa /helloworld och förstå att tjänsten körs. Eftersom beställningswebbtjänsten ska skicka information om beställningen till bussen - från bussen, måste lagertjänsten ta emot detta meddelande och arbeta vidare med det. Och e-postdistributionstjänsten måste bearbeta detta vidare på något sätt osv.

Följaktligen kan vi inte förstå, när vi pekar på varje enskild tjänst, att allt fungerar. För vi har en viss buss genom vilken allt kommunicerar och interagerar.
Därför bör detta skede markera scenen för att testa tjänster för interaktion med andra tjänster. Det är omöjligt att organisera kommunikationsövervakning genom att övervaka meddelandeförmedlaren. Om det finns en tjänst som utfärdar data och en tjänst som tar emot den kommer vi vid övervakning av mäklaren bara att se data som flyger från sida till sida. Även om vi på något sätt lyckades övervaka interaktionen mellan dessa data internt - att en viss producent lägger upp datan, någon läser det, det här flödet fortsätter att gå till Kafka - kommer detta fortfarande inte att ge oss information om en tjänst skickade meddelandet i en version , men den andra tjänsten förväntade sig inte den här versionen och hoppade över den. Vi kommer inte att veta om detta, eftersom tjänsterna kommer att berätta för oss att allt fungerar.

Vad jag rekommenderar att du gör:

För synkron kommunikation: slutpunkten gör förfrågningar till relaterade tjänster. De där. vi tar den här slutpunkten, drar ett skript inuti tjänsten, som går till alla punkter och säger "Jag kan dra dit, och dra dit, jag kan dra dit..."
För asynkron kommunikation: inkommande meddelanden - slutpunkten kontrollerar bussen för testmeddelanden och visar bearbetningsstatus.
För asynkron kommunikation: utgående meddelanden - slutpunkten skickar testmeddelanden till bussen.

Som vanligt: vi har en tjänst som slänger in data i bussen. Vi kommer till denna tjänst och ber dig berätta om dess integrationshälsa. Och om tjänsten behöver producera ett meddelande någonstans längre (WebApp), kommer den att producera detta testmeddelande. Och om vi kör en tjänst på OrderProcessing-sidan, postar den först vad den kan posta oberoende, och om det finns några beroende saker, då läser den en uppsättning testmeddelanden från bussen, förstår att den kan bearbeta dem, rapportera det och , om det behövs, posta dem vidare, och om detta säger han - allt är ok, jag lever.

Mycket ofta hör vi frågan "hur kan vi testa detta på stridsdata?" Vi pratar till exempel om samma beställningstjänst. Beställningen skickar meddelanden till lagret där varorna skrivs av: vi kan inte testa detta på stridsdata, eftersom "mina varor kommer att skrivas av!" Lösning: Planera hela testet från början. Du har också enhetstester som gör hån. Så, gör det på en djupare nivå där du har en kommunikationskanal som inte skadar verksamheten i verksamheten.

Infrastrukturlager

Infrastrukturövervakning är något som länge har ansetts övervaka sig själv.

Infrastrukturövervakning kan och bör lanseras som en separat process.
Du bör inte börja med infrastrukturövervakning på ett pågående projekt, även om du verkligen vill. Detta är en smärta för alla devops. "Först ska jag övervaka klustret, jag ska övervaka infrastrukturen" - dvs. Först kommer den att övervaka vad som ligger nedan, men kommer inte att gå in i applikationen. Eftersom applikationen är en obegriplig sak för devops. Det läckte till honom, och han förstår inte hur det fungerar. Och han förstår infrastrukturen och börjar med den. Men nej – du måste alltid övervaka applikationen först.
Gå inte överbord med antalet varningar. Med tanke på komplexiteten hos moderna system, flyger varningar ständigt, och du måste på något sätt leva med det här gänget av varningar. Och jourhavaren, efter att ha tittat på hundra av de kommande varningarna, kommer att bestämma "Jag vill inte tänka på det." Varningar bör endast meddela om kritiska saker.

Användningsnivå som affärsenhet

Nyckelord:

ÄLG. Detta är industristandarden. Om du av någon anledning inte samlar loggar, börja göra det omedelbart.
APM. Externa APM:er som ett sätt att snabbt stänga applikationsövervakning (NewRelic, BlackFire, Datadog). Du kan installera den här saken tillfälligt för att åtminstone på något sätt förstå vad som händer med dig.
Spårning. I dussintals mikrotjänster måste du spåra allt, eftersom förfrågan inte längre lever av sig själv. Det är mycket svårt att lägga till senare, så det är bättre att omedelbart schemalägga spårning i utvecklingen - det här är utvecklarnas arbete och nytta. Om du inte har implementerat det än, implementera det! Se Jaeger/Zipkin

Varning

Organisation av ett meddelandesystem: i förhållanden för att övervaka en massa saker bör det finnas ett enhetligt system för att skicka meddelanden. Du kan i Grafana. I väst använder alla PagerDuty. Varningar ska vara tydliga (t.ex. var de kom ifrån...). Och det är tillrådligt att kontrollera att aviseringar överhuvudtaget tas emot
Organisation av ett tjänstesystem: varningar ska inte skickas till alla (antingen kommer alla att reagera i en folkmassa, eller så kommer ingen att reagera). Utvecklare måste också vara jour: se till att definiera ansvarsområden, göra tydliga instruktioner och skriv i den exakt vem de ska ringa på måndag och onsdag och vem de ska ringa på tisdag och fredag (annars ringer de inte någon ens i i händelse av ett stort problem - de kommer att vara rädda för att väcka dig eller störa dig: folk gillar i allmänhet inte att ringa och väcka andra människor, särskilt på natten). Och förklara att att be om hjälp inte är en indikator på inkompetens ("Jag ber om hjälp, det betyder att jag är en dålig arbetare"), uppmuntra förfrågningar om hjälp.
Organisation av en "kunskapsbas" och arbetsflöde för incidenthantering: för varje allvarlig incident bör en obduktion planeras, och som en tillfällig åtgärd bör åtgärder som kommer att lösa incidenten registreras. Och gör det till en praxis att upprepade varningar är en synd; de måste fixas i kod- eller infrastrukturarbete.

Teknikstapel

Låt oss föreställa oss att vår stack är som följer:

datainsamling - Prometheus + Grafana;
log analys - ELK;
för APM eller Tracing - Jaeger (Zipkin).

Valet av alternativ är inte kritiskt. För om du i början förstod hur du skulle övervaka systemet och skrev ner en plan, då börjar du välja verktyg som passar dina krav. Frågan är vad du valde att övervaka i första hand. För kanske det verktyg du valde i början inte passar dina krav alls.

Några tekniska punkter som jag ser överallt på sistone:

Prometheus trycks in i Kubernetes – vem kom på detta?! Om ditt kluster kraschar, vad gör du? Om du har ett komplext kluster inuti, bör det finnas något slags övervakningssystem inuti klustret, och något utanför, som samlar in data inifrån klustret.

Inne i klustret samlar vi stockar och allt annat. Men övervakningssystemet måste vara utanför. Mycket ofta, i ett kluster där det finns Promtheus installerat internt, finns det också system som utför externa kontroller av webbplatsens funktion. Vad händer om dina kontakter till omvärlden har tappats och applikationen inte fungerar? Det visar sig att allt är bra inuti, men det gör det inte lättare för användarna.

Resultat

Att övervaka utveckling är inte installation av verktyg, utan utveckling av en mjukvaruprodukt. 98 % av dagens övervakning är kodning. Kodning i tjänster, kodning av externa kontroller, kontroll av externa tjänster, och det är allt.
Slösa inte dina utvecklares tid på övervakning: det kan ta upp till 30 % av deras arbete, men det är värt det.
Devops, oroa dig inte för att du inte kan övervaka något, för vissa saker är ett helt annat sätt att tänka. Du var inte en programmerare, och övervakningsarbete är precis deras jobb.
Om projektet redan är igång och inte övervakas (och du är chef), allokera resurser för övervakning.
Om produkten redan är i produktion och du är en devops som blev tillsagd att "sätta upp övervakning" - försök förklara för ledningen vad jag skrev allt detta om.

Detta är en utökad version av rapporten vid Saint Highload++-konferensen.

Om du är intresserad av mina idéer och tankar om det och relaterade ämnen, så kan du här läs kanalen 🙂

Källa: will.com

Är övervakningen död? — Länge leve övervakning