Moj server je pao i saznao sam za to slučajno pet sati kasnije

Obaveštenje nije došlo od usluge za praćenje. Nije došlo od automatizovanog upozorenja ili vebhooka koji se aktivira u Slacku. Došlo je od najprimitivnijeg sistema praćenja koji je moguć zamisliti: otvaranje pregledača, pisanje URL-a i zurenje u praznu stranicu. Bila je utorak popodne. Sajt je bio onemogućen od negde oko devet sati ujutro, a sada je bilo daleko posle dva popodne. Pet sati potpune tišine od veb-aplikacije koja je obično služila hiljade zahteva dnevno. Pet sati tokom kojih je svaki posjetilac vidio stranicu greške, svaki API poziv je vratio ništa, i svaki zakazani zadatak je tiho pao u pozadini. Server nije pao dramatiično. Nije bilo kernel panika, bez kvara diska, bez vektora napada koji je ostavio forenzičke dokaze. Contabo VPS je jednostavno prestao da reaguje na HTTP zahteve, sedi tamo sa validnom IP adresom i pulsem na mrežnom sloju, ali odbijajući da služi bilo kakav veb saobraćaj.

Otkriće se desilo zbog potpuno nepovezanog zadatka. Bila je potreba da se proveri specifičan raspored stranice za promenu dizajna, pa je pregledač otišao na URL i vratio ništa. Prvi instinkt je bio da okrivim lokalnu mrežu. Osvežio stranicu. Još uvek ništa. Pokušao drugačiji pregledač. Još uvek ništa. Otvorio terminal i pingirao server. Paketi su se normalno vratili. SSH konekcija? Radi savršeno. Status Apache-a? Mrtav. Veb-serverski proces je pao u nekom trenutku tokom ranog jutra i nikada se nije ponovo pokrenuo, jer nije bilo nadzornika procesa konfiguranog da rukuje tom tačnom neuspešnom načinom. Popravka je trajala trideset sekundi. Razumevanje da se ovo može dogoditi ponovo, i verovatno se desilo pre bez da bilo ko to primeti, trajalo je znatno duže da procesuiram.

Svaki razvojni programer koji je pokrenuo proizvodne usluge na VPS-u ima verziju ove priče. Možda nije bilo pet sati. Možda je bilo dva, osam, ili ceo vikend. Specifičnosti se razlikuju, ali obrazac je identičan. Server je pao, niko nije primetio, a otkriće je bilo slučajno. Osnovni problem nije pouzdanost servera. Serveri padaju, procesi se slamaju, diskovi se popunjavaju, curenja memorije se akumuliraju. To je priroda pokretanja softvera na fizičkom hardveru. Osnovni problem je odsustvo praćenja, i tačnije, jaz između znanja da je server online i znanja da aplikacija stvarno funkcionira.

Razlika između monitoringa dostupnosti i znanja da vaš sajt stvarno radi

Tradicionalni monitori dostupnosti rade dobro jednu stvar. Šalju HTTP zahtev na URL redovnim intervalima i proveravaju da li je kod odgovora 200. Ako je kod bilo šta drugo, ili ako zahtev istekne, upozorenje se aktivira. Ovo hvata najkatastrofalne greške: server je potpuno nedostupan, domen je istekao, SSL sertifikat je nevažeći. Ali propušta ogromnu kategoriju problema koji su verovatno češće i destruktivniji.

Razmotrimo scenario u kojem server vraća kod 200 statusa, ali je stranica pokvarena. Konekcija baze podataka je neuspešna, pa sadržaj pokazuje poruku greške umesto očekivanog popisa proizvoda. CSS datoteka nije uspela da se učita, pa se stranica prikazuje kao nestilizovani HTML. Greška u JavaScriptu sprečava glavnu aplikaciju da se inicijalizira, ostavljajući korisnika da gleda u spinner koji se nikada ne razrešava. Vebhostingski widget trećeg lica ubacuje preklapanje koje pokriva ceo sadržaj stranice. U svim ovim slučajevima, monitor dostupnosti izveštava da je sve zdravo jer je primio odgovor od 200. Server je gore. Sajt je slomljen. Niko ne zna.

Ovaj jaz između "server reaguje" i "sajt funkcionira" je gde praćenje snimaka ekrana postaje suštinsko. Zakazani snimak ekrana hvata kako stranica zapravo izgleda redovnim intervalima. Ako stranica iznenada prikaže poruku greške, slomljen raspored, ili prazan beli ekran, snimak to čini odmah vidljivim. Kombinujte zakazane snimke ekrana sa poređenjem razlike piksela, i sistem može automatski detektovati kada se stranica promenila na neočekivane načine. Nekoliko piksela koji se pomere zbog ažuriranja sadržaja je normalno. Čitava stranica koja postane bela ili prikazuje trag greške nije, i algoritam razlike može razlikovati dva sa konfigurabilnim pragovima osetljivosti.

Posle petosatnog pada, prva stvar koja je postavljena je monitor dostupnosti za svaki kritičan servis. Ali zanimljivije dodavanje je bilo zakazano praćenje snimaka ekrana koje hvata stvarno vizuelno stanje ključnih stranica svakih petnaest minuta. Monitor dostupnosti hvata očitne slomove. Monitor snimaka ekrana hvata sve ostalo: sutkane greške koje vraćaju kod 200 statusa dok prikazuju slomljenu stranicu, skripte trećih lica koje ubacuju neočekivani sadržaj, greške baze podataka koje se pojavljuju samo pod specifičnim uslovima.

Izgradnja pipeline-a upozorenja koja bi trebalo da je postojala od prvog dana

Arhitektura pravilnog sistema praćenja nije komplicirana u teoriji. Rasporedivač pokreće proveru u definisanim intervalima. Provera hvata trenutno stanje cilja. Stanje se poredi sa očekivanom bazom. Ako poređenje prelazi prag, upozorenje se aktivira. Izazov nije u arhitekturi već u pouzdanosti svake komponente. Sistem praćenja koji sam pada je gori od bez monitoringa uopšte, jer kreira lažnu osećaj sigurnosti.

Pipeline praćenja snimaka ekrana funkcionira u fazama. Rasporedivač raspodeljuje posao snimanja u konfigurovanom intervalu, obično svakih pet, deset, ili petnaest minuta zavisno od kritičnosti stranice. Posao snimanja pokrelće instancu headless Chromium-a koja učitava stranicu, čeka da se renderovanje završi, i čuva rezultujući snimak ekrana. Novi snimak ekrana se tada poredi sa prethodnim snimkom koristeći algoritam razlike piksela koji identifikuje promenjene regije i izračunava ukupan procenat promene. Ako promena prelazi konfiguralni prag, obaveštenje se raspodeljuje kroz konfigurane kanale: imejl, vebhuk, Slack, ili bilo koji prilagođeni endpoint.

Poređenje razlike je gde stvari postaju stvarno zanimljive sa tehnološke perspektive. Naivna poređenja piksela bi označila svaki snimak ekrana kao promenjen zbog dinamičnog sadržaja kao što su vremenske marke, oglas, ili animirani elementi. Razlika mašina računa na ovo podržavanjem zona isključenja, pravougaone regije stranice koje su maskirane pre poređenja. Vremenska marka u zaglavlju, rotirajući banner oglas, vebhostingski widget u uglovima: svi ovi se mogu isključiti tako da samo značajne promene aktiviraju upozorenja. Ono što ostaje nakon isključenja je stabilna oblast sadržaja, i sve promene tamo su skoro sigurno vredne istraživanja.

Petosatni pad bi se uhvatio u roku od nekoliko minuta pod ovim sistemom. Prvi zakazani snimak ekrana nakon što je server pao bi vratio bilo praznu sliku ili stranicu greške, oba su bila dramatično različita od bazne linije. Procenat razlike bi bio blizu 100%, daleko iznad bilo kog razumnog praga, i upozorenje bi se odmah aktiviralo. Pet sati prekida bi bila pet minuta, i te pet minuta bi bilo samo interval praćenja sam, a ne vreme potrebno da čovjek slučajno naiđe na problem.

Šta pet sati nevidljive nestabilnosti stvarno košta

Neposredan trošak pet sati prekida je lako izračunati kada su brojevi dostupni. Za sajt koji rukuje hiljade dnevnih zahteva, pet sati predstavlja značajnu deobu dnevnog saobraćaja. Svaki zahtev koji je vratio grešku je bio korisnik koji nije dobio ono što je došao. Neki od tih korisnika bili su novi posjetilci koji se nikada neće vratiti. Neki su bili postojeći korisnici koji bi izgubili malu količinu poverenja. Neki su bili konzumenti API-ja čije su vlastite aplikacije neuspešne zbog zavisnosti. Direktni uticaj na dohodak zavisi od prirode sajta, ali čak i za malu SaaS aplikaciju, pet sati prekida tokom radnog vremena može lako predstavljati stotine dolara izgubljenih konverzija.

Skriveni trošak je teže kvantifikovati ali verovatno veći. Pretraživači koji su prikupljali sajt tokom tih pet sati su primili odgovore greške, a dok je kratko prekid generalno tolerisan infrastrukturom prikupljanja Gugl-a, prošireni prekid može rezultirati privremenim deindeksiranjem uticanih stranica. Email kampanje koje su se pokrenule tokom prekida su pokrenule saobraćaj na mrtav endpoint, bacujući celu potrošnju kampanje. Zakazani zadaci koji zavise od veb aplikacije, stvari kao što su isporuke vebhooka, generisanje izveštaja, i obrada paketa, sve su tiho neuspešne i trebalo je ručno da se identifikuju i ponovo pokrenu nakon što je server oporavljen.

Najopasniji trošak je reputacijski. Korisnici koji naiđu na pali sajt obično ne šalju imejl rekavši "vaš sajt je mali." Oni jednostavno odlaze i mogu ili ne mogu da se vrate. Nema mehanizma povratnih informacija za prekid jer je sam mehanizam povratnih informacija mali. Petosatni prozor je bio dovoljno dugačak da su neki korisnici skoro sigurno pokušali sajt, pronašli ga slomljenim, i prešli konkurenatu bez stvaranja bilo koje tačke podataka koja bi označila šta se desilo. Oni su jednostavno otišli, i nema načina da znamo koliko ili ko su bili.

Od reaktivnog do proaktivnog i nikada više neznavanja slučajno

Lekcija iz tog utorka popodne nije bila da serveri padaju. To je već poznato. Lekcija je bila da je svaki minut između neuspecha i njegovog otkrića minut kompajliranja štete, i jedini način da se minimizuje taj prozor je automatizovati detekciju. Ljudsko praćenje se ne skalira. Ručna provera sajta jednom dnevno znači da je prosečno vreme detekcije prekida dvanaest sati. Provera je jednom na sat donosi to na trideset minuta, ali niko realno ne može da proveri svaku stranicu svake aplikacije jednom na sat oko sata.

Kombinacija monitoringa dostupnosti i vizuelnog praćenja snimaka ekrana pokriva oba sloja problema. Monitor dostupnosti hvata server koji ide potpuno offline. Monitor snimaka ekrana hvata aplikaciju koja se slama dok server ostaje gore. Zajedno, oni smanjuju prozor detekcije sa "kad god neko slučajno primeti" na sam interval praćenja, koji može biti čak jedan minut za kritične usluge. Upozorenje se aktivira, obaveštenje stigna, i ispravka počinje u roku od minuta umesto sati.

Server je pao dva puta više od tog originalnog incidenta. Oba puta, upozorenje je stiglo u roku od tri minute. Oba puta, ispravka je primenjena pre nego što je bilo koji značajan saobraćaj ozbiljan. Infrastruktura praćenja je vratila investiciju sa samim prvim incidentom koji je uhvatio, i sve posle toga je bila čista dobit. Era saznavanja o prekidima slučajno je gotova, i gledajući unazad, jedino stvarno pitanje je zašto je trebalo petosatnog pada da je investicija očigledna.