Contabo vypol môj server bez varovania a zistil som to päť hodín neskôr náhodou

Server bežal bez problémov mesiacmi. Contabo, nemecká spoločnosť zabezpečujúca hostovanie známa svojimi mimoriadne lacnými VPS plánmi, zvládala všetko od webových aplikácií až po naplánované úlohy a databázové operácie. Neexistovali žiadne neobvyklé nárasty v prevádzke, žiadne známky degradácie hardvéru, žiadne varovné e-maily od kohokoľvek. Server bol tam jednoducho, robiť to, čo servery robia, kým nebol. Niekedy v dopoludní sa počítač vypol bez signálu. Neprišla žiadna notifikácia. Nebol zverejnený žiadny incident report. Žiaden automatizovaný systém neflagoval problém. Aplikácie, ktoré na tomto serveri záviseli, pokračovali vo svojom bezsilnom zlyhávaní, vracajúc chyby pripojenia každému, kto sa pozrel, zatiaľ čo čas beží ďalej bez toho, aby si niekto všimol, že sa niečo deje.

Päť hodín prešlo predtým, ako bol problém objavený, a samotný objev bol úplne náhodný. Rutinný pokus o SSH prístup na server pre nesúvisejúcu úlohu údržby vrátil timeout pripojenia. To bol moment, keď sa začala ukazovať realita. Päť plných hodín výpadku. Každá webová vlastnosť hostovaná na tomto počítači bola nedostupná. Každý API endpoint vrátil chyby. Každá naplánovaná úloha zlyhala pri vykonaní. A nikto to nevedel, pretože neexistoval žiadny systém na zaznamenanie alarmu. Predpoklad bol, že poskytovateľ hostingu by aspoň poslal e-mail, ak by sa niečo na ich strane pokazilo, alebo že určite by si niekto všimol, ak by webová stránka bola vypnutá. Oba predpoklady sa ukázali ako nebezpečne nesprávne.

Následky boli dlhé popoludnie vyhodnocovania škôd. Kontrola logov, aby sa určilo presne, kedy výpadok začal. Preskúmanie toho, ktoré služby boli ovplyvnené. Výpočet toho, koľko API požiadaviek zlyhalo počas týchto piatich hodín. Kontaktovanie podpory Contabo, aby sme sa dozvedeli, že server bol zastavený z dôvodu, čo oni opisovali ako rutinný údržbový event, ktorý sa zjavne nezdal vhodný na upozornenie zákazníka. Frustrácia nebola len z vlastného výpadku. Výpadky sa stávajú. Hardvér zlyháva. Siete majú problémy. Frustrácia bola z úplnej absencie informácií, z úplného ticha medzi okamihom, keď sa server vypol, a okamihom, keď bol problém objavený náhodou.

Prečo pasívne monitorovanie zlyháva, keď ho potrebujete najviac

Pred incidentom by sa monitorovacie stratégia dala opísať štedro ako pasívna a realisticky ako neexistentná. Prístup bol jednoduchý: ak sa niečo pokazí, niekto si to všimne. Používatelia si budú sťažovať. Chybovosti v analytike tretích strán budú skákať. Poskytovateľ hostingu sa bude komunikovať. Určite, v modernej dobe cloudovej infraštruktúry a automatizovaných systémov, server, ktorý úplne vypne, by spustil nejaký druh pozorovateľnej reakcie. Ale nič z toho sa nestalo v žiadnom užitočnom časovom rámci. Používatelia, ktorí sa stretli s chybami, jednoducho odišli. Platformy analytiky len hlásia, čo dokážu zmerať, a keď server, ktorý ich zásobuje údajmi, vypne, nie je nič na meranie. Poskytovateľ hostingu, ako sa ukázalo, nepovažoval neohlásené vypnutie za niečo, čo stojí za poslanie e-mailu.

Toto je pasť, ktorá chytá prekvapivý počet malých a stredných operácií. Podnikové spoločnosti prevádzkujú vyhradené monitorovacie systémy s celými tímami, ktoré sa pozerajú na palubné dosky bez prestávky. Individuálni vývojári a malé firmy majú tendenciu pracovať na predpoklady, že ich hosting je dosť spoľahlivý, že katastrofálne zlyhania sú dosť zriedkavé a že manuálna réžia nastavenia monitorovania nestojí za úsilie niečo, čo sa "pravdepodobne nestane." Problém s takým tímto logikom je, že náklady na výpadok sa stupňujú s tým, ako dlho je neobjasneným, a nie s tým, ako často sa to stáva. Päť minút výpadku, ktorý sa hneď chytí, je menší event. Päť hodinový výpadok, ktorý si nikto nevšimne, kým na to neprekúkne náhodou, je skutočný podnikateľský problém.

Incident tiež odhalil jemnejší problém so spoliehnutím sa na poskytovateľa hostingu ako na jediný zdroj pravdy o stave servera. Contabo, ako väčšina lacných hostingových spoločností, poskytuje základné informácie o stave servera cez kontrolný panel. Ale návšteva kontrolného panelu si vyžaduje, aby ste už podozrevali, že sa niečo pokazilo. Neexistuje žiadny push mechanizmus, žiadne proaktívne upozornenie, žiaden systém, ktorý by vám dosiahol a povedal "váš server je vypnutý, tu je čo sa stalo." Vzťah je úplne reaktívny. Zákazník musí položiť otázku predtým, ako dostane odpoveď. V svete, kde každá sekunda výpadku sa premieňa na zmeškané tržby, stratené dôvery a poškodený rebríček vyhľadávačov, tento reaktívny model je zásadne nedostatočný.

Čo päť hodín ticha skutočne stojí

Kvantifikácia škôd z neobjaveného výpadku je komplikovanejšia ako len počítanie minút. Okamžité náklady sú dosť jednoduché: strata príjmov z API, zlyhaných webhook dodávok, prerušené integrácie pre používateľov, ktorí závisia od dostupnosti pre ich vlastné pracovné postupy. Ale sekundárne náklady sa hromadia spôsobmi, ktoré sa neobjavujú na žiadnom palubnej doske. Vyhľadávacie roboty, ktoré prídu počas výpadku a dostanú chybové odpovede, môžu spustiť penalizácie v rebríčkoch, ktoré trvajú týždne na obnovu. Používatelia, ktorí sa stretnú s vypnutou stránkou, sa už nikdy nemusia vrátiť, a nie je spôsob, ako vedieť, koľko potenciálnych zákazníkov navštívilo počas týchto piatich hodín, dostalo chybovú stránku a vytvorilo si trvalý negatívny dojem.

Expírácia SSL certifikátu je ďalšou tichá hrozbou, ktorá zhoršuje problém. Certifikát, ktorý vyprší bez varovania, nevytvára len bezpečnostnú zraniteľnosť. Spúšťa upozornenia prehliadača, ktoré aktívne odrádzajú návštevníkov od pokračovania na stránku. Vyhľadávacie motory považujú vypršené certifikáty za signál hodnotenia. A na rozdiel od výpadku servera, ktorý sa aspoň vyrieši, keď sa server vrátí online, vypršený certifikát pokračuje v spôsobovaní škôd, kým ho niekto ručne neobnoví. Kombinácia nemonitorovaného zdravia servera a nemonitorovanej platnosti certifikátu vytvára situáciu, kde sa na seba môžu navrstvovať viaceré režimy zlyhania, z ktorých každý sťažuje obnovu.

Degradácia doby odozvy je ďalší rozmer, ktorý pasívne monitorovanie úplne zmeškáva. Server sa nealways nemení z pracujúceho na mŕtveho v jednom okamihu. Viac často sa výkon postupne zhoršuje. Doby odozvy, ktoré boli 200 milisekúnd, začínajú stúpať na 800, potom 1500, potom 3000. V čase, keď sa server skutočne zrúti, používateľský zážitok sa zhoršuje už niekoľko hodín alebo dní. Bez aktívneho monitorovania, ktoré sleduje doby odozvy a upozorňuje, keď sú prekročené prahové hodnoty, sa toto postupné zhoršenie pozoruje bez povšimnutia, kým sa nakoniec, katastrofálne zlyhanie. A do tej doby je škoda na používateľskom zážitku a rebríčkoch vyhľadávačov už hotová.

Stavba monitorovacieho systému, ktorý mal existovať

Rozhodnutie postaviť uptime.yeb.to nebolo spontánnou reakciou na zlý deň. Bol to logický záver problému, ktorý sa dlho budoval a nakoniec sa stal nemožným ignorovať. Požiadavky boli jasné od začiatku, pretože prišli priamo z živej skúsenosti. Monitor musel nepretržite overovať dostupnosť servera, nie raz za hodinu alebo raz za deň, ale často, aby bol výpadok detegovaný v priebehu sekúnd. Musel sa pozrieť nielen na to, že server reaguje na ping požiadavky, ale že HTTPS pripojenia sa úspešne zavŕšujú, že SSL certifikáty sú platné a neblížia sa vypršaniu, a že doby odozvy sú v prijateľných rozsahoch. A musel poskytnúť upozornenia okamžite, nie cez palubnú dosku, ktorá si vyžadovala manuálnu kontrolu, ale cez e-mailové notifikácie, ktoré by prišli do doručenej pošty v priebehu sekúnd od detekcie problému.

Architektúra, ktorá sa objavila, odráža tieto priority. Každý monitorovaný koncový bod sa kontroluje v bežných intervaloch vo viacerých rozmeroch súčasne. Ping kontrola potvrdzuje základnú dostupnosť siete. HTTPS kontrola overuje, že webový server reaguje a že handshake SSL sa bez chýb zavŕši. Certifikátna kontrola skúma dátum vypršania a upozorňuje na potrebu obnovenia. Kontrola doby odozvy meria, ako dlho úplný požiadavok trvá a vlaječka degradácia predtým, ako sa stane kritickou. Každá z týchto kontrol produkuje dátový bod, ktorý sa pohybuje do reálneho upozorňovania a historickej analýzy trendov, čo znamená, že systém nie len chytá výpadky po tom, ako sa stanu, ale tiež odhaľuje vzory, ktoré môžu predpovedať problémy predtým, ako sa stanú.

Denné a týždenné digest e-maily poskytujú zhrnutie všetkých monitorovaných koncových bodov, ich percento dostupnosti, priemerných dôb odozvy a akýchkoľvek incidentov, ktoré sa vyskytli počas obdobia. Tieto digesty slúžia inému účelu ako upozornenia v reálnom čase. Zatiaľ čo upozornenia sú o chytení problémov v momente, digesty sú o pochopení celkovej trajektórie zdravia infraštruktúry. Server, ktorý udržiaval 99,9% dostupnosti, ale preukázal stabilne rastúce doby odozvy za posledných dva týždne, je server smerujúci k problémom, a digest robí tento trend viditeľným spôsobom, ktorým jednotlivé alert e-maily nemohou.

Od osobného nástroja k platforme

Čo sa začalo ako riešenie osobnej krízy sa postupne rozšírilo na niečo širšie užitočné. Monitorovacie schopnosti v multi-regiónoch, ktoré posielajú skúšky zo šiestich rôznych geografických lokalít, pochádzali z reálneho scenára, keď bol server dostupný z Európy, ale nedostupný zo Severnej Ameriky z dôvodu problému s smerovacím. Monitorovanie v jednej lokácii by hlásilo všetko ako v poriadku. Multi-región sondy chytili nezrovnalosť okamžite a zistili presne, ktoré geografické regióny boli ovplyvnené. Tento druh prehľadu je neoceniteľný pre kohokoľvek, kto slúži globálnej publiku, kde môže regionálny výpadok uplne prejsť bez povšimnutia, ak monitorovanie prebieha iba z jednej lokácie.

Funkcia histórie incidentov vyrástla z potreby mať tvrdé dáta počas rozhovorov s poskytovateľmi hostingu. Keď sa kontaktuje podpora o opakujúcich sa problémoch, aby sa mal podrobný časový plán každého výpadku, jeho trvania, špecifických skúšok, ktoré zlyhali, a merania doby odozvy pred a po incidente, premení rozhovor z "myslíme si, že bol nejaký výpadok" do "tu sú presné časové značky, trvania a vzory zlyhania." Tieto dáta výrazne uľahčujú udržateľnosť poskytovateľov a podľa nich sa dajú informovane rozhodovať, či zostať s hostingovú spoločnosťou alebo migrovať niekam inde.

Celá platforma na uptime.yeb.to teraz existuje z dôvodu jedného neohlaseného vypnutia servera a päť hodín ticha. Každá funkcia sa vráti k špecifickému zlyhaniu, ktoré by bolo chytené, alebo úplne zabránené, správnym monitorovaním. Incident Contabo nebol posledný problém servera, ktorý sa vyskytol, ale bol posledný, ktorý si nikto nevšimol päť hodín. Táto diferenciácia robí všetok rozdiel.