Min Server Gik ned, og jeg fandt ud af det fem timer senere ved et uheld

Beskeden kom ikke fra en overvågningstjeneste. Den kom ikke fra en automatiseret advarsel eller en webhook, der skyder ind i Slack. Den kom fra det mest primitive overvågningssystem, man kan forestille sig: at åbne en browser, skrive URL'en og stirre på en tom side. Det var en tirsdag eftermiddag. Siden havde været nede siden et eller andet tidspunkt omkring ni om morgenen, og det var nu langt efter klokken to eftermiddag. Fem timer med total stilhed fra en webapplikation, der normalt serverede tusindvis af forespørgsler pr. dag. Fem timer, hvor hver besøgende så en fejlside, hvert API-kald returnerede ingenting, og hver planlagt opgave fejlede uden lyd i baggrunden. Serveren var ikke styrtet dramatisk ned. Der var ingen kernepanic, ingen diskfejl, ingen angrebsvektor, der efterlod juridiske spor. Contabo VPS'en havde simpelt hen stoppet med at reagere på HTTP-forespørgsler, sad der med en gyldig IP-adresse og et hjerteslaget på netværkslaget, men nægtede at servere noget webtrafik overhovedet.

Opdagelsen skete på grund af en fuldstændig urelateret opgave. Der var behov for at kontrollere et specifikt sidelayout for en designændring, så browseren gik til URL'en og returnerede ingenting. Det første instinkt var at give det lokale netværk skylden. Opdaterede siden. Stadig ingenting. Prøvede en anden browser. Stadig ingenting. Åbnede terminalen og pingede serveren. Pakker returnerede normalt. SSH-forbindelse? Fungerer fint. Apache-status? Død. Webserverprocessen var styrtet på et tidspunkt i løbet af de tidlige morgentimer og genstartet aldrig, fordi der ikke var nogen proceshandler konfigureret til at håndtere denne præcise fejltilstand. Rettelsen tog tredive sekunder. Realiseringen af, at dette kunne ske igen, og sandsynligvis var sket før uden at nogen opdagede det, tog betydeligt længere tid at fordøje.

Hver udvikler, der har kørt produktionstjenester på en VPS, har en version af denne historie. Måske var det ikke fem timer. Måske var det to, eller otte, eller en helt weekend. Detaljerne varierer, men mønsteret er identisk. Serveren gik ned, ingen opdagede det, og opdagelsen var tilfældig. Rodproblemet er ikke serverens pålidelse. Servere fejler, processer styrter ned, diske fyldes, hukommelseslækager ophober sig. Det er arten af at køre software på fysisk hardware. Rodproblemet er fraværet af overvågning, og mere specifikt gabet mellem at vide, at serveren er online, og at vide, at applikationen faktisk fungerer.

Forskellen mellem Uptime-overvågning og at vide, at dit site faktisk fungerer

Traditionelle uptime-monitorer gør én ting godt. De sender en HTTP-forespørgsel til en URL med jævne mellemrum og kontrollerer, om svarkodet er 200. Hvis koden er noget andet, eller hvis forespørgslen timeout, fyres en advarsel. Dette fanger de mest katastrofale fejl: serveren er helt unalerbar, domænet er udløbet, SSL-certifikatet er ugyldigt. Men det misser en enorm kategori af problemer, der er argumenteret som mere almindelige og mere skadelige.

Overvej et scenarie, hvor serveren returnerer en 200-statuskode, men siden er ødelagt. Databaseforbindelsen mislyktes, så indholdsområdet viser en fejlbesked i stedet for den forventede produktliste. CSS-filen kunne ikke indlæses, så siden gengives som ustylet HTML. En JavaScript-fejl forhindrer hovedapplikationen i at initialisere og efterlader brugeren stirrende på en spinner, der aldrig opløses. En tredjepartswidget injicerer et overlay, der dækker alt sideindhold. I alle disse tilfælde rapporterer uptime-monitoren alt som sundt, fordi den modtog et 200-svar. Serveren er oppe. Siden er ødelagt. Ingen ved det.

Dette gab mellem "serveren reagerer" og "siden fungerer" er hvor screenshot-overvågning bliver vigtig. Et planlagt skærmbillede fanger, hvad siden faktisk ser ud på regelmæssige intervaller. Hvis siden pludselig viser en fejlbesked, et brændt layout eller en hvid tom skærm, gør skærmbilledet det umiddelbart synligt. Kombiner planlagte skærmbilleder med pixel diff-sammenligning, og systemet kan automatisk detektere, når en side har ændret sig på uventede måder. Et par pixels, der skifter på grund af en indholdsændring, er normalt. Hele siden bliver hvid eller viser en fejlstak, er det ikke, og diff-algoritmen kan skelne mellem de to med konfigurerbar følsomhedstærskel.

Efter fem timers strømafbrydelse var det første, der blev sat op, en uptime-monitor for hver kritisk tjeneste. Men det mere interessante supplement var planlagt screenshot-overvågning, der fanger den faktiske visuelle tilstand af nøglesider hvert femtende minut. Uptime-monitoren fanger de åbenlyse nedbrud. Screenshot-monitoren fanger alt andet: de subtile fejl, der returnerer en 200-statuskode, mens en ødelagt side vises, tredjepartsscripterne, der injicerer uventet indhold, databasefejlene, der kun øget under specifikke forhold.

Opbygning af advarselpipelinen, der skulle have eksisteret fra dag ét

Arkitekturen af et korrekt overvågningssystem er ikke kompliceret i teorien. En planlægger udløser en kontrol på definerede intervaller. Kontrollen fanger den aktuelle tilstand af målet. Tilstanden sammenlignes med den forventede baseline. Hvis sammenligningen overstiger en tærskel, fyres en advarsel. Udfordringen ligger ikke i arkitekturen, men i påidelighed hos hver komponent. Et overvågningssystem, der selv går ned, er værre end ingen overvågning overhovedet, fordi det skaber en falsk følelse af sikkerhed.

Screenshot-overvågningspipelinen fungerer i faser. Planlæggeren ekspederer et capture-job ved det konfigurerede interval, typisk hvert femte, tiende eller femtende minut afhængigt af sidens kritikalitet. Capture-jobbet kører en headless Chromium-instans, der indlæser siden, venter på, at rendering er fuldført, og gemmer det resulterende skærmbillede. Det nye skærmbillede sammenlignes derefter med tidligere capture ved hjælp af en pixel diff-algoritme, der identificerer ændrede regioner og beregner den samlede ændringsprocent. Hvis ændringen overstiger den konfigurerede tærskel, sendes en meddelelse gennem de konfigurerede kanaler: e-mail, webhook, Slack eller ethvert brugerdefineret endpoint.

Diff-sammenligningen er hvor tingene bliver virkelig interessante ud fra teknisk perspektiv. En naiv pixelsammenligning ville flag hvert skærmbillede som ændret på grund af dynamisk indhold som tidsstempler, annoncer eller animerede elementer. Diff-motoren tager højde for dette ved at understøtte eksklusionszoner, rektangulære områder på siden, der er maskeret før sammenligning. Tidsstemplet i header, den roterende bannerannoncer, live chat-widgeten i hjørnet: disse kan alle udelukkes, så kun meningsfulde ændringer udløser advarsler. Hvad der er tilbage efter eksklusioner er det stabile indholdsområde, og eventuelle ændringer der er næsten helt sikkert værd at undersøge.

De fem timers strømafbrydelse ville være blevet fanget inden for minutter under dette system. Det første planlagte skærmbillede efter serveren gik ned, ville have returneret enten et tomt billede eller en fejlside, som begge ville have adskilt sig dramatisk fra baseline. Diff-procenten ville have været tæt på 100%, langt over enhver rimelig tærskel, og advarslen ville være blevet fyret øjeblikkeligt. Fem timers nedetid ville have været fem minutter, og disse fem minutter ville have været selve overvågningsintervallet, ikke det tidspunkt, det tog for en mennesker at tilfældigvis stumble på problemet.

Hvad fem timer med usynlig nedetid faktisk koster

De umiddelbare omkostninger ved fem timers nedetid er lette at beregne, når tallene er tilgængelige. For et site, der håndterer tusindvis af daglige forespørgsler, repræsenterer fem timer en betydelig del af daglig trafik. Hver forespørgsel, der returnerede en fejl, var en bruger, der ikke fik, hvad de kom for. Nogle af disse brugere var nye besøgende, der aldrig ville vende tilbage. Nogle var eksisterende brugere, der ville miste en lille mængde tillid. Nogle var API-forbrugere, hvis egne applikationer fejlede på grund af afhængighed. Den direkte indtjaeningseffekt afhænger af sitets natur, men selv for en lille SaaS-applikation kan fem timers nedetid i arbejdstiden let repræsentere hundredvis af dollars i tabte konverteringer.

De skjulte omkostninger er sværere at kvantificere, men argumenteres være større. Søgemaskiner, der crawlede siden i løbet af disse fem timer, modtog fejlsvar, og selvom en kort strømafbrydelse generelt tolereres af Googles crawling-infrastruktur, kan udvidet nedetid resultere i midlertidig afindeksering af berørte sider. E-mailkampagner, der kørte under strømafbrydelsen, drev trafik til en død endpoint og spildte hele kampagneudgiften. Planlagte opgaver, der afhænger af webapplikationen, ting som webhook-leveringer, rapportgenerering og batchbehandling, fejlede alle stille og skulle identificeres og køres igen manuelt efter serveren var gendannet.

Den mest krybrende omkostning er den omdømmemæssige. Brugere, der møder en nedgået side, sender typisk ikke en e-mail, der siger "dit site er nede." De forsvinder bare og kommer måske eller måske ikke tilbage. Der er ingen feedback-mekanisme for nedetid, fordi feedback-mekanismen selv er nede. De fem timer lange vindue var lange nok til, at nogle brugere helt sikkert prøvede siden, fandt den ødelagt og skiftede til en konkurrent uden nogensinde at generere et enkelt datapunkt, der ville angive, hvad der skete. De er simpelt hen væk, og der er ingen måde at vide hvor mange eller hvem de var.

Fra reaktiv til proaktiv og aldrig finde ud af det ved et uheld igen

Lektionen fra den tirsdag eftermiddag var ikke, at servere styrter ned. Det var allerede kendt. Lektionen var, at hvert minut mellem en fejl og dens opdagelse er et minut med sammensat skade, og den eneste måde at minimere det vindue på er at automatisere opdagelsen. Human-overvågning skalerer ikke. Kontrol af et site manuelt en gang om dagen betyder, at den gennemsnitlige opdagelsestid for en strømafbrydelse er tolv timer. Kontrol det en gang i timen bringer det ned til tredive minutter, men ingen menneske kan realistisk kontrollere hver side på hver applikation en gang i timen omkring døgnet.

Kombinationen af uptime-overvågning og visuel screenshot-overvågning dækker begge lag af problemet. Uptime-monitoren fanger serveren, der gik helt offline. Screenshot-monitoren fanger applikationen, der knækker, mens serveren forbliver oppe. Sammen reducerer de detektionsvinduet fra "når nogen tilfældigvis opdager" til overvågningsintervallet selv, som kan være så kort som et minut for kritiske tjenester. Advarslen fyres, notifikationen ankommer, og rettelsen begynder inden for minutter i stedet for timer.

Serveren er gået ned to gange mere siden det originale hændelse. Begge gange ankom advarslen inden for tre minutter. Begge gange blev rettelsen anvendt, før noget væsentlig trafik gik tabt. Overvågningsinfrastrukturen betalte for sig selv med det meget første hændelse, det fangede, og alt derefter har været ren upside. Æraen med at finde ud af strømafbrydelser ved et uheld er forbi, og set tilbage er det eneste rigtige spørgsmål, hvorfor det tog en fem timers strømafbrydelse at gøre investeringen åbenbar.