Můj server selhal a zjistil jsem to pět hodin později náhodou

Oznámení nepřišlo z monitorovací služby. Nepřišlo z automatizovaného upozornění ani z webhooku palícího se na Slack. Přišlo z nejprimitivnějšího monitorovacího systému, jaký si lze představit: otevření prohlížeče, napsání adresy URL a zírání na prázdnou stránku. Byla úterý odpoledne. Web byl vypnutý již od nějakých devíti hodin ráno a bylo už více než dvě odpoledne. Pět hodin naprostého ticha od webové aplikace, která normálně obsluhovala tisíce požadavků za den. Pět hodin, během kterých každý návštěvník viděl chybovou stránku, každé volání API vrátilo nic a každý naplánovaný úkol tiše selhal na pozadí. Server se nezhroutil dramaticky. Nebyla zde žádná kernel panika, žádné selhání disku, žádný útok, který by zanechal digitální stopy. Contabo VPS jednoduše přestala reagovat na požadavky HTTP, seděla tam s platnou IP adresou a tep v síťové vrstvě, ale odmítala sloužit jakoukoli webovou dopravu.

Objev se stal kvůli naprosto nesouvisející úloze. Bylo třeba zkontrolovat konkrétní rozložení stránky pro změnu designu, takže prohlížeč šel na adresu URL a vrátil nic. Prvním instinktem bylo vinit místní síť. Aktualizoval stránku. Pořád nic. Vyzkoušel jiný prohlížeč. Pořád nic. Otevřel terminál a pingoval server. Pakety se vracely normálně. Připojení SSH? Fungovalo skvěle. Stav Apache? Mrtvý. Webový server se někdy během ranních hodin zhroutil a nikdy se nerestartoval, protože neexistoval žádný supervizor procesu nakonfigurovaný tak, aby zvládl tento konkrétní způsob selhání. Oprava trvala třicet sekund. Uvědomění si, že by se to mohlo stát znovu a pravděpodobně se to stalo dříve bez všimnutí, trvalo výrazně déle.

Každý vývojář, který provozoval produkční služby na VPS, má verzi tohoto příběhu. Možná to nebyly pět hodin. Možná to byly dvě, osm nebo celý víkend. Specifika se liší, ale vzor je totožný. Server šel dolů, nikdo si toho nevšiml a objev byl náhodný. Základní problém není spolehlivost serveru. Servery selhávají, procesy selhávají, disky se zaplňují, paměťové úniky se hromadí. To je podstata provozu softwaru na fyzickém hardwaru. Základní problém je absence monitorování a konkrétněji rozpor mezi vědomím, že je server online, a vědomím, že aplikace skutečně funguje.

Rozdíl mezi monitorováním dostupnosti a vědomím, že váš web skutečně funguje

Tradiční monitorování dostupnosti dělá jednu věc dobře. Odesílá požadavek HTTP na adresu URL v pravidelných intervalech a kontroluje, zda je kód odpovědi 200. Pokud je kód něco jiného nebo pokud požadavek vyprší, vyvolá se upozornění. Toto zachytí nejkatastroftčtější selhání: server je zcela nedostupný, domény vypršela platnost, certifikát SSL je neplatný. Ale chybí mu obrovská kategorie problémů, které jsou pravděpodobně běžnější a škodlivější.

Vezměme si scénář, kdy server vrátí stavový kód 200, ale stránka je rozbitá. Připojení k databázi selhalo, takže oblast obsahu ukazuje chybovou zprávu místo očekávaného seznamu produktů. Soubor CSS se nepodařilo načíst, takže se stránka vykresluje jako nestylizovaný HTML. Chyba JavaScriptu zabrání hlavní aplikaci v inicializaci, ponechávající uživatele zírajícího na spinner, který se nikdy nerozhodne. Widget třetí strany vstrčí překrytí, které pokryje veškerý obsah stránky. Ve všech těchto případech monitor dostupnosti hlásí vše jako zdravé, protože obdržel odpověď 200. Server je nahoru. Web je rozbitý. Nikdo to neví.

Tato mezera mezi „server reaguje" a „web funguje" je místo, kde se monitorování snímků obrazovky stává zásadním. Naplánovaný snímek obrazovky zachycuje, jak stránka skutečně vypadá v pravidelných intervalech. Pokud stránka náhle zobrazuje chybovou zprávu, rozbitý rozvrh nebo prázdnou bílou obrazovku, snímek obrazovky to okamžitě viditelné. Kombinujte naplánované snímky se srovnáním pixelových rozdílů a systém může automaticky zjistit, když se stránka změnila neočekávaným způsobem. Několik pixelů posunujících se kvůli aktualizaci obsahu je normální. Celá stránka se zbarví bíle nebo zobrazuje trasování zásobníku chyb není a algoritmus rozdílu může rozlišit mezi těmito dvěma s nastavitelnými prahy citlivosti.

Po pětihodinovém výpadku byla první věc, která byla nastavena, monitor dostupnosti pro každou kritickou službu. Ale zajímavější přidání bylo naplánované monitorování snímků obrazovky, které zachycuje skutečný vizuální stav klíčových stránek každých patnáct minut. Monitor dostupnosti zachytí zjevné havárie. Monitor snímků obrazovky zachytí vše ostatní: subtilní selhání, která vrací stavový kód 200, zatímco zobrazují rozbitou stránku, skripty třetích stran, které vstrčí neočekávaný obsah, chyby databáze, které se objevují pouze za specifických podmínek.

Vytvoření potrubí upozornění, které by mělo existovat od prvního dne

Architektura správného monitorovacího systému není v teorii složitá. Plánovač spustí kontrolu v definovaných intervalech. Kontrola zachycuje aktuální stav cíle. Stav se porovnává s očekávaným základním rámcem. Pokud srovnání překročí prahovou hodnotu, vyvolá se upozornění. Výzvou není architektura, ale spolehlivost každé součásti. Monitorovací systém, který sám selže, je horší než žádné monitorování, protože vytváří falešný pocit bezpečí.

Potrubí monitorování snímků obrazovky funguje v etapách. Plánovač odesílá úlohu zachycení v nakonfigurovaném intervalu, obvykle každých pět, deset nebo patnáct minut v závislosti na kritičnosti stránky. Úloha zachycení spustí instanci bezhlavého Chromia, která načte stránku, počká na dokončení vykreslování a uloží výsledný snímek obrazovky. Nový snímek obrazovky je pak porovnán s předchozím zachycením pomocí algoritmu pixelového rozdílu, který identifikuje změněné oblasti a vypočítá celkový procento změny. Pokud změna překročí nakonfigurovanou prahovou hodnotu, je oznámení odeslána přes nakonfigurované kanály: e-mail, webhook, Slack nebo libovolný vlastní koncový bod.

Srovnání rozdílů je místo, kde se věci stanou z technického hlediska opravdu zajímavé. Naivní pixelové srovnání by označilo každý snímek obrazovky jako změněný kvůli dynamickému obsahu, jako jsou časové razítka, reklamy nebo animované prvky. Modul rozdílu to řeší podporou zón vyloučení, obdélníkových oblastí stránky, které jsou makovány před srovnáním. Časové razítko v záhlaví, rotující reklamní banner, widget živého chatu v rohu: to vše lze vyloučit tak, aby pouze významné změny vyvolaly upozornění. Co zbývá po vyloučení, je oblast stabilního obsahu a všechny změny tam jsou téměř jistě věcí, která stojí za vyšetřením.

Pětihodinový výpadek by byl zachycen během minut pod tímto systémem. První naplánovaný snímek obrazovky po selhání serveru by vrátil buď prázdný obrázek nebo chybovou stránku, z nichž oba by se drasticky lišily od základního. Procento rozdílu by bylo blízko 100%, daleko nad jakoukoli rozumnou prahovou hodnotu, a upozornění by okamžitě vypršelo. Pět hodin výpadku by bylo pět minut a těchto pět minut by byl interval monitorování sám, ne čas, kdy se člověk náhodou narazil na problém.

Co pět hodin neviditelného výpadku skutečně stojí

Okamžité náklady na pět hodin výpadku jsou snadno vypočítatelné, když jsou čísla k dispozici. Pro web obsluhující tisíce denních požadavků představuje pět hodin významný řez denního provozu. Každý požadavek, který vrátil chybu, byl uživatel, který nedostal, co přišel hledat. Někteří z těchto uživatelů byli noví návštěvníci, kteří by se nikdy nevrátili. Někteří byli stávajícími uživateli, kteří by ztratili malou částku důvěry. Některé byly spotřebitelé API, jejichž vlastní aplikace selhaly kvůli závislosti. Přímý dopad na příjmy závisí na povaze webu, ale i pro malou aplikaci SaaS může pět hodin výpadku během pracovní doby snadno představovat stovky dolarů ztraceným konverzí.

Skrytá cena je obtížněji kvantifikovatelná, ale pravděpodobně větší. Vyhledávací stroje, které procházely web během těchto pěti hodin, obdržely chybové odpovědi a zatímco krátký výpadek je obecně tolerován infrastrukturou crawlingu společnosti Google, prodloužený výpadek může vést k dočasnému de-indexování ovlivněných stránek. E-mailové kampaně, které běžely během výpadku, řídily provoz na mrtvý koncový bod, plýtvaly celými náklady na kampaň. Naplánované úkoly, které závisí na webové aplikaci, věci jako doručování webhooku, generování zpráv a dávkové zpracování, vše selhalo tiše a bylo třeba je identifikovat a znovu spustit ručně poté, co byl server obnoven.

Nejzáludnější cena je reputační. Uživatelé, kteří se setkají s padlým webem, typicky neposílají e-mail s textem „váš web je vypnutý". Prostě odejdou a mohou se vrátit nebo ne. Neexistuje žádný mechanismus zpětné vazby pro výpadek, protože samotný mechanismus zpětné vazby je vypnutý. Okno pěti hodin bylo dost dlouhé na to, aby někteří uživatelé téměř jistě zkusili web, zjistili, že je rozbitý, a přesunuli se ke konkurentu, aniž by vygenerovali jediný datový bod, který by naznačoval, co se stalo. Jsou prostě pryč a není způsob, jak vědět, kolik jich bylo nebo kdo to byli.

Od reaktivního k proaktivnímu a nikdy se o tom nezvím náhodou

Lekce z toho úterního odpoledne nebyla, že servery padají. To už bylo známo. Lekcí bylo, že každá minuta mezi selháním a jeho objevem je minuta kumulativního poškození a jediný způsob, jak minimalizovat toto okno, je automatizovat detekci. Lidské monitorování neměřítko. Ruční kontrola webu jednou za den znamená, že průměrná doba detekce výpadku je dvanáct hodin. Kontrola jednou za hodinu to přináší na třicet minut, ale žádný člověk nemůže realističticky zkontrolovat každou stránku každé aplikace jednou za hodinu 24 hodin denně.

Kombinace monitorování dostupnosti a vizuálního monitorování snímků obrazovky pokrývá obě vrstvy problému. Monitor dostupnosti zachytí server, který jde úplně offline. Monitor snímků obrazovky zachytí aplikaci, která se během chodu serveru rozpadá. Dohromady snižují detekční okno z „kdykoli si to někdo všimne" na interval monitorování sám, který může být tak krátký jako jedna minuta pro kritické služby. Upozornění vypršelo, oznámení dorazí a oprava začíná během minut místo hodin.

Server šel dolů dvakrát více od toho původního incidentu. Oba časy upozornění dorazilo během tří minut. Oba časy byla oprava použita dříve, než byla ztracena nějaká významná přenosem. Infrastruktura monitorování se zaplatila s velmi prvním incidentem, který chytila, a vše po tom bylo čisté kladné. Éra zjišťování výpadků náhodou je u konce a zpět, jediná opravdu otázka je, proč trvalo pětihodinový výpadek, aby byla investice zřejmá.