Môj server padol a ja som to zistil o päť hodín neskôr náhodou

Upozornenie neprichádzalo od monitorovaciej služby. Neprichádzalo od automatizovaného upozornenia ani od webhooku vysielajúceho sa do služby Slack. Pochádzalo z najprimitívnejšieho monitorovacieho systému, aký si možno predstaviť: otvorenie prehliadača, zadanie adresy URL a pozeranie sa na prázdnu stránku. Bol pondelok popoludní. Lokalita bola vypnutá odkedy bolo okolo deviatej ráno a teraz bolo už po druhej popoludní. Päť hodín úplného ticha z webovej aplikácie, ktorá normálne obsluhovávala tisíce požiadaviek za deň. Päť hodín, počas ktorých každý návštevník videl chybovú stránku, každý volanie rozhrania API vrátilo nič a každá naplánovaná úloha zlyhala ticho na pozadí. Server sa nezrútil dramaticky. Nebol žiadny kernel panic, žiadne zlyhanie disku, žiadny vektor útoku, ktorý by zanechal forenzné dôkazy. Virtuálny súkromný server Contabo sa jednoducho prestал reagovať na HTTP požiadavky, sediac tam s platnou IP adresou a pulzom na vrstvách siete, ale odmietal slúžiť akúkoľvek webovú prevádzku.

Objavenie sa stalo kvôli úplne inej úlohe. Bola potreba skontrolovať špecifický rozloženie stránky pre zmenu dizajnu, takže prehliadač prešiel na adresu URL a vrátil nič. Prvý inštinkt bolo obviniť lokálnu sieť. Obnovil som stránku. Stále nič. Skúšal som iný prehliadač. Stále nič. Otvoril som terminál a pingol som server. Pakety sa vrátili normálne. Pripojenie SSH? Funguje správne. Stav Apache? Mrtav. Proces webového servera sa v nejakom bode v skorých ranných hodinách zrútil a nikdy sa reštartoval, pretože nebol nakonfigurovaný žiadny dohľadávač procesov na spracovanie tohto špecifického režimu zlyhania. Oprava trvala tridsať sekúnd. Uvedomenie si, že by sa to mohlo stať znova a pravdepodobne sa to stalo už predtým, keď to nikto nezaregistroval, trvalo oveľa dlhšie.

Každý vývojár, ktorý kedysi prevádzkoval produkčné služby na virtuálnom súkromnom serveri, má verziu tohto príbehu. Možno to nebolo päť hodín. Možno to boli dve, osem alebo celý víkend. Podrobnosti sa líšia, ale vzor je identický. Server padol, nikto si to nezaregistroval a objavenie bolo náhodné. Hlavný problém nie je spoľahlivosť servera. Servery zlyháva, procesy sa padajú, disky sa zaplňujú, úniky pamäti sa hromadia. To je povaha prevádzky softvéru na fyzickom hardvéri. Základný problém je absencia monitorovania, a konkrétnejšie, medzera medzi poznaním, že je server online, a poznaním, že aplikácia skutočne funguje.

Rozdiel medzi monitorovaním dostupnosti a vedením, že vaša stránka skutočne funguje

Tradičné monitory dostupnosti robia jednu vec dobre. Posielajú HTTP požiadavku na adresu URL v pravidelných intervaloch a kontrolujú, či je kód odozvy 200. Ak je kód čokoľvek iné alebo ak časový limit požiadavky vypršal, upozornenie sa spustí. Toto zachytáva najkatastrálnejšie zlyhania: server je úplne nedostupný, doména vypršala, certifikát SSL je neplatný. Ale zmeškáva obrovskú kategóriu problémov, ktoré sú pravdepodobne bežnejšie a viac škodlivé.

Zvážte scenár, kde server vracia kód stavu 200, ale stránka je rozbití. Pripojenie k databáze zlyhalo, takže oblasť obsahu zobrazuje chybovú správu namiesto očakávaného zoznamu produktov. Súbor CSS sa nepodarilo načítať, takže stránka sa vykresľuje ako neštýlovaný HTML. Chyba JavaScriptu bráni hlavnej aplikácii v inicializácii a nechá používateľa pozerať sa na indikátor načítavania, ktorý sa nikdy nevyriešil. Widget tretej strany injektuje prekrytie, ktoré pokrýva celý obsah stránky. Vo všetkých týchto prípadoch monitor dostupnosti hlási všetko ako zdravé, pretože dostal odpoveď 200. Server je hore. Lokalita je rozbití. Nikto nevie.

Táto medzera medzi "server reaguje" a "stránka funguje" je miesto, kde sa monitorovanie snímkov obrazovky stáva nevyhnutným. Naplánovaný snímok obrazovky zachytáva to, ako stránka skutočne vyzerá v pravidelných intervaloch. Ak stránka zrazu zobrazuje chybovú správu, rozbité rozloženie alebo bielu obrazovku, snímok obrazovky to okamžite sprístupní. Skombinujte naplánované snímky obrazovky s porovnávaním pixelových rozdielov a systém môže automaticky zistiť, kedy sa stránka zmenila neočakávanými spôsobmi. Niekoľko pixelov posúvajúcich sa kvôli aktualizácii obsahu je normálne. Celá stránka sa zmení na bielu alebo zobrazuje chybovú stopu je nie, a algoritmus diff môže rozlíšiť medzi týmito dvoma s nastaviteľnými prahmi citlivosti.

Po päťhodinovom výpadku bola prvá vec, ktorá sa nastavila, monitor dostupnosti pre každú kritickú službu. Ale zaujímavejšie bolo monitorovanie naplánovaných snímkov obrazovky, ktoré zachytáva skutočný vizuálny stav kľúčových stránok každých pätnásť minút. Monitor dostupnosti zachytáva zrejmé zlyhania. Monitor snímkov obrazovky zachytáva všetko ostatné: jemné zlyhania, ktoré vracia kód stavu 200, zatiaľ čo zobrazujú rozbití stránku, skripty tretích strán, ktoré injektujú neočakávaný obsah, chyby databázy, ktoré sa objavujú iba za špecifických podmienok.

Budovanie potrubia upozornení, ktoré malo existovať už od začiatku

Architektúra správneho monitorovacieho systému nie je komplikovaná v teórii. Plánovač spúšťa kontrolu v definovaných intervaloch. Kontrola zachytáva aktuálny stav cieľa. Stav sa porovnáva so očakávaným základným plánom. Ak porovnanie prekročí prah, upozornenie sa spustí. Výzvou nie je architektúra, ale spoľahlivosť každej súčasti. Monitorovací systém, ktorý sa sám padá, je horší ako žiadne monitorovanie, pretože vytvárame falošný zmysel bezpečnosti.

Potrubie monitorovania snímkov obrazovky funguje v etapách. Plánovač vysiela úlohu zachytávania v nastavenom intervale, zvyčajne každých päť, desať alebo pätnásť minút v závislosti od kritičnosti stránky. Úloha zachytávania spúšťa bezhlasy inštanciu Chromium, ktorá načíta stránku, čaká na dokončenie vykresľovania a uloží výsledný snímok obrazovky. Nový snímok obrazovky sa potom porovnáva s predchádzajúcim záberom pomocou algoritmu pixelového rozdielu, ktorý identifikuje zmenené oblasti a vypočítava celkové percento zmeny. Ak zmena prekročí nastavený prah, upozornenie sa vysiela cez nakonfigurované kanály: e-mail, webhook, Slack alebo akýkoľvek vlastný koncový bod.

Porovnanie rozdielov je miesto, kde sa veci stávajú skutočne zaujímavými z technického hľadiska. Naivné porovnanie pixelov by označilo každý snímok obrazovky ako zmenený kvôli dynamickému obsahu, ako sú časové značky, reklamy alebo animované prvky. Diff engine to zohľadňuje podporou zón vylúčenia, obdĺžnikových oblastí stránky, ktoré sú maskované pred porovnávaním. Časová značka v hlavičke, rotujúci banner reklama, widžet živej chatu v rohu: všetky sa dajú vylúčiť, takže iba zmysluplné zmeny spúšťajú upozornenia. To, čo zostane po vylúčení, je oblasť stabilného obsahu a akékoľvek zmeny tam sú takmer určite stojí za vyšetrovanie.

Päťhodinový výpadok by bol zachytený v priebehu minút pod týmto systémom. Prvý naplánovaný snímok obrazovky po vypnutí servera by vrátil buď prázdny obrázok alebo chybovú stránku, z ktorých oboje by sa dramaticky líšilo od základného plánu. Percento rozdielu by bolo blízko 100 %, oveľa vyššie ako akýkoľvek rozumný prah, a upozornenie by sa okamžite spustilo. Päť hodín výpadku by bolo päť minút a tie päť minút by bol sám monitoring interval, nie čas, ktorý trvala, aby si človek náhodou všimol problém.

Čo päť hodín neviditeľného výpadku skutočne stojí

Okamžitá cena päť hodín výpadku je ľahko vypočítateľná, keď sú čísla dostupné. Pre lokalitu, ktorá spracováva tisíce denných požiadaviek, päť hodín predstavuje významný podiel dennej prevádzky. Každá požiadavka, ktorá vrátila chybu, bola používateľ, ktorý nedostal to, čo chcel. Niektorí z týchto používateľov boli noví návštevníci, ktorí sa už nikdy nevrátia. Niektorí boli existujúcimi používateľmi, ktorí by stratili malú množstvo dôvery. Niektorí boli spotrebitelia rozhrania API, ktorých vlastné aplikácie zlyhali kvôli závislosti. Priamy vplyv na príjmy závisí od povahy lokality, ale aj pre malú aplikáciu SaaS môže päť hodín výpadku počas pracovných hodín predstavovať ľahko stovky dolárov stratených konverzií.

Skrytá cena je ťažšie kvantifikovateľná, ale pravdepodobne väčšia. Vyhľadávacie motory, ktoré prešli lokalitu počas týchto päť hodín, dostali chybové odpovede a zatiaľ čo krátky výpadok je všeobecne tolerovaný infraštruktúrou Google crawlingu, predĺžený výpadok môže viesť k dočasnému odstráneniu dotknutých stránok z indexu. E-mailové kampane, ktoré bežali počas výpadku, viedli prevádzku na mrtvý koncový bod, čím sa marnil celý výdaj kampane. Naplánované úlohy, ktoré závisia od webovej aplikácie, veci ako dodávky webhooku, generovanie správ a spracovanie dávok, všetky zlyhali ticho a museli byť identifikované a znova spustené ručne po obnovení servera.

Najzákernejšia cena je reputačná. Používatelia, ktorí narazí na padnutú lokalitu, zvyčajne neposielajú e-mail s tým, že "vaša stránka je padnutá." Jednoducho odchádzajú a možno sa nevrátia. Neexistuje mechanizmus spätnej väzby pre výpadky, pretože samotný mechanizmus spätnej väzby je vypnutý. Päť hodinové okno bolo dosť dlhé na to, aby niektorí používatelia takmer určite skúšali lokalitu, našli ju rozbitú a presunuli sa na konkurenta bez toho, aby kedy vygenerovali jediný dátový bod, ktorý by naznačoval, čo sa stalo. Sú jednoducho preč a neexistuje spôsob, ako vedieť, koľko ich bolo alebo kto boli.

Od reaktívneho k proaktívnemu a nikdy sa to nezistilo náhodou znova

Ponaučenie z toho pondelka popoludnia nebolo to, že servery padajú. To sa už vedelo. Ponaučenie bolo, že každá minúta medzi zlyhaním a jeho objavením je minúta postupného poškodzovania a jediný spôsob, ako minimalizovať toto okno, je automatizovať detekciu. Monitorovanie človekom sa neškáluje. Kontrola lokality ručne raz za deň znamená, že priemerný čas detekcie pre výpadok je dvanásť hodín. Kontrola raz za hodinu to prináša na tridsať minút, ale žiadny človek nemôže realisticky skontrolovať každú stránku každej aplikácie raz za hodinu okolo hodín.

Kombinácia monitorovania dostupnosti a vizuálneho monitorovania snímkov obrazovky pokrýva obe vrstvy problému. Monitor dostupnosti zachytáva server, ktorý úplne padá offline. Monitor snímkov obrazovky zachytáva aplikáciu padajúcu, zatiaľ čo server zostáva hore. Spolu znižujú okno detekcie z "vždy, keď sa to náhodou všimnú" na samotný monitoring interval, ktorý môže byť aj krátky ako jedna minúta pre kritické služby. Upozornenie sa spustí, upozornenie príde a oprava začne v priebehu minút namiesto hodín.

Server padol ešte dvakrát od tej pôvodnej udalosti. Oba krát prišlo upozornenie do troch minút. Oba krát bola oprava aplikovaná skôr, ako sa stratila akákoľvek významná prevádzka. Monitorovacia infraštruktúra sa sama zaplatila pri prvej udalosti, ktorú zachytila a všetko potom bolo čistá výhoda. Éra zisťovania výpadkov náhodou je u konca a spätne sa dívam, jedinou skutočnou otázkou je, prečo to trvalo päť hodinový výpadok, aby bola investícia zrejmá.