A szerverem leállt és öt órával később véletlenül jöttem rá

Az értesítés nem egy monitorozó szolgáltatástól érkezett. Nem egy automatikus riasztásból vagy egy Slackbe tüzelő webhookból. A legprimitívebb monitorozási rendszerből érkezett, amit csak el lehet képzelni: megnyitott egy böngészőt, begépeltem az URL-t, és egy üres oldalra néztem. Ez egy kedd délután volt. A webhely valamikor kilenc óra körül leállt, és már jóval kettő után járt az idő. Öt óra teljes csendből egy olyan webalkalmazásból, amely normál esetben naponta ezer kérést szolgál ki. Öt óra alatt minden látogató hibát kapott, minden API-hívás semmit sem adott vissza, és minden ütemezett feladat halkan meghiúsult a háttérben. A szerver nem zuhant össze dramatikusan. Nem volt kernel panic, nincs merevlemez-hiba, nincs támadási vektor, amely nyomóanyagot hagyott volna. A Contabo VPS egyszerűen nem válaszolt a HTTP-kérésekre, csak ott ült érvényes IP-címmel és életjellel a hálózati rétegben, de megtagadta az összes webes forgalom kiszolgálását.

A felfedezés egy teljesen kapcsolódó feladat miatt történt. Szükség volt egy adott oldal elrendezésének ellenőrzésére egy tervezési változás miatt, ezért a böngésző az URL-re ment, és semmit sem kapott vissza. Az első ösztön a helyi hálózatot hibáztatni. Frissítette az oldalt. Még mindig semmi. Egy másik böngészőt próbált. Még mindig semmi. Megnyitotta a terminált, és megpingelte a szervert. A csomagok normálisan visszatértek. SSH-kapcsolat? Jól működik. Apache státusza? Halott. A webszerver folyamata valamikor a kora reggeli órákon összeomolt, és nem indult újra, mert egyáltalán nem volt feldolgozta-felügyelő konfigurálva az adott hibamód kezeléséhez. A javítás harminc másodpercet vett igénybe. Az a felismerés, hogy ez ismét megtörténhet, és valószínűleg korábban is megtörtént anélkül, hogy valaki észrevette volna, sokkal tovább tartott megemészteni.

Minden fejlesztőnek, aki termelési szolgáltatásokat futtat egy VPS-en, van ennek a történetnek egy verziója. Talán nem öt óra volt. Talán kettő, nyolc, vagy egy teljes hétvége volt. A specifikus részletek eltérőek, de a minta azonos. A szerver leállt, senki nem vette észre, és a felfedezés véletlenül történt. Az alapvető probléma nem a szerver megbízhatósága. A szerverek meghibásodnak, a folyamatok összeomolnak, a lemezek megtelnek, a memória szivárgása felhalmozódik. Ez a szoftver fizikai hardveren való futtatásának természete. Az alapvető probléma a monitorozás hiánya, és még pontosabban, a szerver online voltának ismerete és az alkalmazás tényleges működésének ismerete közötti hézag.

A különbség az üzemidő-monitorozás és az, hogy tudod a webhely valóban működik-e

A hagyományos üzemidő-monitorok jól végeznek egy dolgot. Egy URL-hez rendszeres időközönként HTTP-kérést küldenek, és ellenőrzik, hogy a válaszkód 200-e. Ha a kód bármi más, vagy ha a kérés túllépi az időkorlátot, riasztás indul el. Ez elkapja a legkatasztrofálisabb hibákat: a szerver teljesen elérhetetlen, a tartomány lejárt, az SSL-tanúsítvány érvénytelen. De egy hatalmas kategóriát hagyott ki a problémáknak, amelyek valószínűleg gyakoribbak és károsabbak.

Vegyünk egy olyan forgatókönyvet, ahol a szerver 200 állapotot ad vissza, de az oldal megtört. Az adatbázis-kapcsolat meghiúsult, így a tartalmi terület hibaüzenetet mutat az elvárt terméklistázás helyett. A CSS-fájl nem töltödött be, így az oldal stílusozatlan HTML-ként jelenik meg. Egy JavaScript-hiba megakadályozza az alkalmazás inicializálását, így a felhasználó egy olyan betöltési spinnerbe néz, amely soha nem oldódik meg. Egy harmadik fél widget olyan átfedést szúr be, amely az egész oldaltartalmat lefedi. Ezekben az esetekben az üzemidő-monitor minden terv szerint működőnek jelenti, mivel 200 válaszban részesült. A szerver működik. Az oldal megtört. Senki nem tudja.

Ez a hézag a "szerver válaszol" és "az oldal működik" között az, ahol a képernyőmegfigyelés elengedhetetlenné válik. Az ütemezett képernyőkép rögzíti, hogy az oldal valóban milyen néz ki rendszeres időközönként. Ha az oldal hirtelen egy hibaüzenetet, egy megtört elrendezést vagy egy üres fehér képernyőt mutat, a képernyőkép ezt azonnal láthatóvá teszi. Kombinálja az ütemezett képernyőképeket a pixel diff összehasonlítással, és a rendszer automatikusan felismerheti, amikor egy oldal váratlan módon megváltozik. Az, hogy néhány pixel eltolódik a tartalom frissítése miatt, normális. Az egész oldal elfordul vagy egy hiba stack trace-t jelenít meg nem, és a diff algoritmus az adott konfigurálható érzékenységi küszöbökkel meg tudja különböztetni a kettőt.

Az öt órás kimaradás után az első, amit beállítottak, egy üzemidő-monitor volt minden kritikus szolgáltatás számára. De az érdekelsebbe az ajánlat a ütemezett képernyőmegfigyelés volt, amely a kulcs oldalak tényleges vizuális állapotát rögzíti tizenöt percenként. Az üzemidő-monitor a nyilvánvaló összeomlásos. A képernyőmegfigyelés mindent elkapott: a finom hibákat, amelyek 200 állapotban visszatérnek, miközben egy megtört oldalt mutatnak, a harmadik fél szkripteket, amelyek váratlan tartalmat szúrnak be, az adatbázis-hibákat, amelyek csak meghatározott feltételek mellett bukkannak fel.

A riasztási vezeték felépítése, amely az első naptól létezni kellett volna

A megfelelő monitorozási rendszer architektúrája elméletben nem bonyolult. Az ütemező egy definiált időközönként váltja ki az ellenőrzést. Az ellenőrzés rögzíti a cél aktuális állapotát. Az állapotot az elvárt alapvonalhoz viszonyítják. Ha az összehasonlítás meghaladja a küszöbértéket, riasztás indul el. A kihívás nem az architektúrában van, hanem az egyes komponensek megbízhatóságában. Egy monitorozási rendszer, amely maga is leáll, rosszabb, mint nem monitoring, mivel hamis biztonságérzetet kelt.

A képernyőmegfigyelési csatorna szakaszos működik. Az ütemező a konfigurált intervallumban egy rögzítési feladatot kiszállít, általában öt, tíz vagy tizenöt percenként az oldal kritikussági szintjétől függően. A rögzítési feladat egy fejlécnélküli Chromium-példányt futtat, amely betölti az oldalt, megvárja a renderelés befejezését, és menti az eredményül kapott képernyőképet. Az új képernyőkép ezután az előző rögzítéshez képest egy pixel diff algoritmus segítségével kerül összehasonlításra, amely azonosítja a megváltozott régiókat, és kiszámítja a teljes változás százalékát. Ha a változás meghaladja a konfigurált küszöbértéket, egy értesítést továbbítanak az konfigurált csatornákon keresztül: e-mail, webhook, Slack vagy bármely egyéni végpont.

A diff összehasonlítás az, ahol a dolgok valóban érdekessé válnak technikai szempontból. Az intuitív pixel összehasonlítás minden képernyőképet megváltoztatottnak jelöl meg, mivel dinamikus tartalom, például időbélyegek, hirdetések vagy animált elemek miatt. A diff motor ezt támogatja az úgynevezett kizárási zónák támogatásával, az oldal téglalapkérésű régióival, amelyek az összehasonlítás előtt maszkolódnak. Az időbélyeg a fejlécben, a forgó bannerreklám, az élő csevegési widget a sarokban: ezek mind kizárhatók, így csak a jelentős változások váltanak ki riasztásokat. Az, ami marad után a kizárás az az stabil tartalmi terület, és minden ott történő változtatás szinte biztosan megér figyelmet.

Az öt órás kimaradást perceken belül felkaptuk volna ezalatt a rendszer alatt. Az első ütemezett képernyőkép a szerver leálása után vagy egy üres képét vagy egy hiba oldalt adott volna vissza, amelyek közül mindkettő drasztikusan eltérne az alapvonalaktól. A diff százalék közel 100% lenne, messze bármely ésszerű küszöb felett, és a riasztás azonnal indul el. Öt óra üzemszünete öt perc lenne, és ezek az öt perc a monitorozási intervallum lenne, nem az az idő, amely ahhoz szükséges, hogy egy ember véletlenül rábukkanjon a problémára.

Mit költenek valójában az öt óra láthatatlan üzemszünete

Az öt óra üzemszünete azonnali költsége könnyen kiszámítható, ha a számok rendelkezésre állnak. Az egy napi ezer kérést kezelő webhely öt órája az esetek az esetek az esetek az napi forgalom jelentős szeletét jelenti. Minden olyan kérés, amely hibát adott vissza, olyan felhasználó volt, aki nem kapta meg, amit keresett. Néhányuk új látogató volt, aki soha nem tér vissza. Néhányuk meglévő felhasználó volt, aki egy kis mennyiségű bizalmat veszítene el. Néhányuk API-fogyasztó volt, akiknek a saját alkalmazása meghibásodott a függőség miatt. A közvetlen bevétel-hatás az oldal természetétől függ, de még egy kis SaaS-alkalmazásnál is, az öt óra üzemszünete az üzleti órákon jelentős számú elveszett konverziót képviselhet.

A rejtett költség nehezebben számszerűsíthető, de valószínűleg nagyobb. A keresőmotorok, amelyek az oldalt ezek az öt óra alatt meglátogatták, hibaválaszokat kaptak, és bár a rövid kimaradást általában tolerálják a Google indexelési infrastruktúrája, a kiterjesztett üzemszünetek az érintett oldalak ideiglenes kizárásához vezethetnek. Az üzemszünete alatt futó e-mail kampányok forgalmat hajtottak egy halott végponthoz, pazarlásokérő az egész kampány költségeit. Az olyan webalkalmazástól függő ütemezett feladatok, mint a webhook-szállítások, a jelentések létrehozása és a kötegelt feldolgozás, mind halkan meghiúsultak, és azonosítást és újrafuttatást kellett szükséges után a szerver visszaállítása után.

A legspekulatívabb költség az reputációs. Az azok találkozóit a leállt oldallal típúsan nem küld e-mailt, amely azt mondja, hogy "az oldal leállt." Egyszerűen elmennek, és esetleg nem térnek vissza. Nincs visszajelzési mechanizmus az üzemszünethez, mivel az visszajelzési mechanizmus maga is leállt. Az öt órás ablak hosszú volt, hogy néhány felhasználó szinte biztosan megpróbálta az oldalt, megtörve találta, és egyetlen adat pont nélkül is elkészülhetett, amely azt jelzi, hogy mi történt. Egyszerűen eltűntek, és nincs mód annak megtudására, hogy hányan vagy kik voltak.

A reaktívtól a proaktív felé, és soha nem ismerhetjük meg véletlenül

A kedd délutánjának tanulsága nem az volt, hogy a szerverek összeomlanak. Ez már ismert volt. A tanulság az volt, hogy a hiba és annak felfedezésé közötti minden perc a kumulatív kár percet jelent, és az egyetlen módja ennek az ablak minimalizálásához az az, hogy automatizálá a detektálást. Az emberi monitoring nem skálázódik. Az oldal kézi ellenőrzése naponta egyszer azt jelenti, hogy az egy kimaradás átlagos detektálási ideje tizenkét óra. Ezt óránként egyszer ellenőrizve harmincig percet lehet csökkenteni, de egyetlen ember sem tud realisztikusan minden oldal az összes alkalmazás ellenőrzésére órákban a nap körül.

Az üzemidő-monitorozás és a vizuális képernyőmegfigyelés kombinációja a probléma mindkét rétegét fedi le. Az üzemidő-monitor elkapja a szerverre teljesen leállása. A képernyőmegfigyelés elkapja az alkalmazás szakadása, miközben a szerver felül marad. Együtt csökkentik a detektálási ablakot "amikor valaki véletlenül rábukkan" az monitorozási intervallum önmagában, amely akár egy perc is lehet kritikus szolgáltatások számára. A riasztás indul, az értesítés érkezik, és a javítás perceken belül kezdődik az órák helyett.

A szerver az eredeti incidens óta még kétszer leállt. Mindkét alkalommal az értesítés három percen belül érkezett. Mindkét alkalommal a javítást alkalmazták, mielőtt bármilyen jelentős forgalom megtörtént volna. A monitorozási infrastruktúra magáért fizetett az első incidensben, amelyet megragadott, és minden ezt követő tiszta felépítmény. Az üzemszünetek véletlen megismerésének korszaka vége, és vissza tekintve, az egyetlen valódi kérdés az, hogy miért tartott egy öt órás kimaradás ahhoz, hogy a beruházás nyilvánvalóvá váljon.