Palvelimeni Meni Offline ja Huomasin Sen Viisi Tuntia Myöhemmin Sattumalta

Ilmoitus ei tullut valvontapalvelusta. Se ei tullut automaattisesta hälytyskeista tai webhook-ketjusta, joka ampui Slack-kanavaan. Se tuli primitiivisimmästä valvontajärjestelmästä, jota voi kuvitella: selaimen avaaminen, URL-osoitteen kirjoittaminen ja tyhjän sivun tuijottaminen. Se oli tiistain jälkeen. Sivusto oli ollut pois päältä joskus noin yhdeksän aamulla, ja se oli nyt hyvin yli kaksi iltapäivällä. Viisi tuntia täydellistä hiljaisuutta verkkosovelluksesta, joka tavallisesti palveli tuhansia pyyntöjä päivässä. Viisi tuntia, jonka aikana jokainen vierailija näki virhesivun, jokainen API-kutsu palautti mitään, ja jokainen ajoitettu tehtävä epäonnistui hiljaisesti taustalla. Palvelin ei ollut kaatunut dramaattisesti. Ydin-paniikkia ei ollut, levyvirhettä ei ollut, hyökkäysvektoria, joka jätti rikosteknisiä todisteita. Contabon VPS oli yksinkertaisesti lopettanut HTTP-pyyntöihin vastaamisen, istuen siellä kelvollisella IP-osoitteella ja sydämenlyönnillä verkon kerroksella, mutta kieltäytyi palvelemasta mitään verkkaliikennettä.

Löytö tapahtui täysin erinäköisen tehtävän takia. Oli tarvetta tarkistaa tietty sivun asettelu suunnittelumuutokseen, joten selain meni URL-osoitteeseen ja palautti mitään. Ensimmäinen vaistos oli syyttää paikallista verkkoa. Päivitettävä sivu. Edelleen mitään. Kokeilin eri selainta. Edelleen mitään. Avattu terminaali ja pingattu palvelin. Paketit palautuivat normaalisti. SSH-yhteys? Toimii hyvin. Apache-tila? Kuollut. Web-palvelimen prosessi oli kaatunut joskus aikaisin aamulla eivätkä koskaan uudelleenkäynnistyneet, koska mikään prosessin valvojan ei ollut konfiguroitu käsittelemään tätä tiettyä vikatilaa. Korjaus kesti kolmekymmentä sekuntia. Ymmärrys, että tämä voisi tapahtua uudelleen, ja se oli luultavasti tapahtunut aiemmin ilman että kukaan huomasi, vei huomattavasti pidempään sulattaa.

Jokaisella kehittäjällä, joka on harjoittanut tuotantopalveluita VPS:ssä, on versio tästä tarinasta. Ehkä se ei ollut viisi tuntia. Ehkä se oli kaksi tai kahdeksan tai kokonainen viikonloppu. Yksityiskohdat vaihtelevat, mutta malli on identtinen. Palvelin meni offline-tilaan, kukaan ei huomannut, ja löytö oli sattumaa. Juuriongelma ei ole palvelimen luotettavuus. Palvelimet epäonnistuvat, prosessit kaatuvat, levyt täyttyvät, muistivuodot kertyvät. Se on luonto, joka johtaa ohjelmiston suorittamiseen fyysisessä laitteistossa. Juuriongelma on valvonnan puuttuminen, ja tarkemmin sanottuna, ero tietää, että palvelin on online-tilassa ja tietää, että sovellus toimii oikeastaan.

Ero Käyttöäjän Valvonnan ja Tietää, Että Sivustosi Todella Toimii

Perinteinen käyttövalvonta tekee yhden asian hyvin. Se lähettää HTTP-pyynnön URL-osoitteeseen säännöllisin väliajoin ja tarkistaa, onko vastauskoodi 200. Jos koodi on jotain muuta tai jos pyyntö aikakatkaisu, hälytys laukeaa. Tämä saa katastrofaalisimmat virheet: palvelin on täysin tavoittamaton, toimialue on vanhentunut, SSL-sertifikaatti on virheellinen. Mutta se jää pois valtavasta ongelmien kategoriasta, jota voidaan väittää olevan yleisempiä ja vahingollisempia.

Harkitse skenaariota, jossa palvelin palauttaa 200-tilakoodin, mutta sivu on rikki. Tietokantayhteys epäonnistui, joten sisältöalue näyttää virheilmoituksen odotetun tuotelistan sijaan. CSS-tiedosto epäonnistui latautua, joten sivu renderöidään tyylittömänä HTML-koodina. JavaScript-virhe estää pääsovelluksen käynnistymisen, jolloin käyttäjä tuijottaa latauskaaria, joka ei koskaan ratkea. Kolmannen osapuolen pienoisohjelma injisoi peittävän kuvan, joka peittää koko sivun sisällön. Kaikissa näissä tapauksissa käyttövalvonta raportoi kaiken terveeksi, koska se vastaanotti 200-vastauksen. Palvelin on poissa. Sivusto on rikki. Kukaan ei tiedä.

Tämä kuilu "palvelin vastaa" ja "sivusto toimii" välillä on, missä kuvakaappauksen valvonta tulee välttämättömäksi. Ajoitettu kuvakaappaus kuvaa, miltä sivu todella näyttää säännöllisesti. Jos sivu yhtäkkiä näyttää virheilmoitusta, rikki olevaa asettelua tai tyhjää valkoista ruutua, kuvakaappaus tekee siitä välittömästi näkyvän. Yhdistä ajoitetut kuvakaappaukset pikselidiffien vertailuun, ja järjestelmä voi automaattisesti havaita, kun sivu on muuttunut odottamattomasti. Muutama pikseli, joka siirtyy sisällön päivityksen vuoksi, on normaalia. Koko sivu kääntyy valkoiseksi tai näyttää virhepinon ei ole, ja diffin algoritmi voi erottaa näiden kahden välillä, joilla on konfiguroitavissa olevat herkkyyskynnyokset.

Viiden tunnin häiriön jälkeen ensimmäinen asia, joka otettiin käyttöön, oli käyttövalvonta jokaiselle kriittiselle palvelulle. Mutta kiinnostavampi lisäys oli ajoitettu kuvakaappauksen valvonta, joka kaappaa avainten sivustojen todellisen visuaalisen tilan joka viisitoista minuuttia. Käyttövalvonta saa ilmeisiä kaatumisia. Kuvakaappauksen valvonta saa kaiken muun: hienovaraisemmat virat, jotka palauttavat 200-tilakoodin näyttäessään rikotun sivun, kolmannen osapuolen komentosarjat, jotka injisioivat odottamattoman sisällön, tietokantavirheet, jotka ilmenevät vain tietyissä olosuhteissa.

Hälytysputkilinjan Rakentaminen, Joka Olisi Pitänyt Olla Olemassa Päivästä Yksi

Asianmukaisen valvontajärjestelmän arkkitehtuuri ei ole teoriassa monimutkaista. Ajoitus käynnistää sekin määritellyin väliajoin. Sekin kaappaa nykyisen kohteen tilan. Tilaa verrataan odotettuun vertailuarvoon. Jos vertailu ylittää kynnyksen, hälytys laukeaa. Haaste ei ole arkkitehtuurissa vaan kunkin komponentin luotettavuudessa. Valvontajärjestelmä, joka itse menee pois käytöstä, on huonompi kuin mikään valvonta ollenkaan, koska se luo väärän turvallisuuden tunteen.

Kuvakaappauksen valvontaputki toimii vaiheissa. Ajoitus lähettää siepattavaa työtä konfiguroituun väliajoin, tyypillisesti joka viisi, kymmenen tai viisitoista minuuttia sivun kriittisyydestä riippuen. Siepattava työ ajaa pää Chromium-esiintymää, joka lataa sivun, odottaa renderöinnin valmistumista ja tallentaa tuloksena olevan kuvakaappauksen. Uutta kuvakaappausta verrataan sitten aiempaan sieppaukseen pikselidiffin algoritmin avulla, joka tunnistaa muuttuneet alueet ja laskee muutoksen kokonaisprosentin. Jos muutos ylittää konfiguroitun kynnyksen, ilmoitus lähetetään konfiguroitujen kanavien kautta: sähköposti, webhook, Slack tai mikä tahansa mukautettu pääte.

Diffien vertailu on paikka, jossa asiat muuttuvat aidosti mielenkiintoisiksi teknisen näkökohdan näkökulmasta. Naiivi pikseleiden vertailu merkitsisi jokaisen kuvakaappauksen muuttuneeksi dynaattisen sisällön, kuten aikaileimien, mainosten tai animaatioelementtien vuoksi. Diffin moottori selviää tämän tukemalla poissulkemisen alueita, sivun suorakaiteen alueet, jotka peitetään ennen vertailua. Otsikon aikaleiima, kiertävä mainosapu, live-chat-seutu kulmassa: kaikki nämä voidaan jättää pois niin, että vain merkitykselliset muutokset laukaisevat hälytykset. Mitä jää poissulkemisen jälkeen, on vakaa sisältöalue, ja kaikki muutokset siellä ovat lähes varmasti arvoisia tutkimista.

Viiden tunnin häiriö olisi saatu kiinni minuuttien kuluessa tämän järjestelmän alla. Ensimmäinen ajoitettu kuvakaappaus sen jälkeen, kun palvelin meni offline-tilaan, olisi palauttanut joko tyhjän kuvan tai virhesivun, joista molemmat olisivat poikenneet dramaattisesti lähtökohdasta. Diffien prosentti olisi ollut lähellä 100%, paljon korkeampi kuin mikä tahansa kohtuullinen kynnys, ja hälytys olisi lauennut välittömästi. Viisi tuntia alasaikaa olisi ollut viisi minuuttia, ja nuo viisi minuuttia olisivat olleet valvontaväli itse, eivät aika, jonka ihminen sattui löytämään ongelman.

Mitä Viiden Tunnin Näkymätön Alasaika Todella Maksaa

Viiden tunnin alasajan välitön kustannus on helppo laskea, kun numerot ovat saatavilla. Sivustolle, joka käsittelee tuhansia päivittäisiä pyyntöjä, viisi tuntia on merkittävä osa päivittäistä liikennettä. Jokainen pyyntö, joka palautti virheen, oli käyttäjä, joka ei saanut mitä he tulivat. Jotkut näistä käyttäjistä olivat uusia vierailijoita, jotka eivät koskaan palaa. Jotkut olivat olemassa olevia käyttäjiä, jotka menettäisivät pienen määrän luottamusta. Jotkut olivat API-kuluttajia, joiden omat sovellukset epäonnistuivat riippuvuuden vuoksi. Suoran tulojen vaikutus riippuu sivuston luonteesta, mutta jopa pienellä SaaS-sovelluksella viisi tuntia alasaikaa liiketoiminnan aikoina voi helposti edustaa satojen dollarien menetystä muunnosissa.

Piilotettu kustannus on vaikeampi määrittää, mutta väitettävasti suurempi. Hakukoneet, jotka katsoivat sivustoa näiden viiden tunnin aikana, saivat virhevastauksia, ja vaikka lyhyt häiriö on yleisesti sietävä Google-indexin infrastruktuurille, laajennettu alasaika voi johtaa vaikuttavien sivujen väliaikaiseen poisrajaamiseen. Sähköpostikampanjat, joita ajettiin häiriön aikana, ajoineet liikennettä kuolleeseen päätepisteeseen, tuhlaamalla koko kampanjakulut. Ajoitetut tehtävät, jotka riippuvat verkkosovelluksesta, kuten webhook-toimitus, raportin luominen ja erää käsittely, epäonnistuivat kaikki hiljaisesti ja piti tunnistaa ja ajaa uudelleen manuaalisesti sen jälkeen, kun palvelin oli palautettu.

Insidiousin kustannus on maine. Käyttäjät, jotka kohtaavat alas sivuston, eivät tyypillisesti lähetä sähköpostia sanoen "sivustosi on alas." He yksinkertaisesti lähtevät ja saattavat palata tai eivät palaa. Alasaika-palautteen mekanismi ei ole olemassa, koska palautemekanismi itse on pois. Viiden tunnin ikkuna oli riittävän pitkä, jonka jälkeen jotkut käyttäjät melkein varmasti yrittivät sivustoa, löysivät sen rikki, ja siirtyivät kilpailijaan ilman, että koskaan luodaan ainuttakaan datapistettä, joka ilmoittaisi, mitä tapahtui. He ovat yksinkertaisesti poissa, eikä ole tapa tietää kuinka monia tai ketkä he olivat.

Reaktiivisesta Proaktiiviseen ja Ei Koskaan Löytää Sattumalta Uudelleen

Oppitunti tiistain jälkeisestä oli ei, että palvelimet kaatuvat. Se oli jo tiedossa. Oppitunti oli, että jokainen minuutti vian ja sen löytämisen välillä on minuutti yhdistävää vahinkoa, ja ainoa tapa minimoida tämä ikkuna on automatisoida havaitseminen. Ihmisen valvonta ei mittakaavaksi. Sivuston tarkistaminen manuaalisesti kerran päivässä tarkoittaa, että keskimääräinen havaintoaika häiriölle on kaksitoista tuntia. Tarkistaminen kerran tunti tuo sen kolmeenkymmeneen minuuttiin, mutta kukaan ihminen ei voi realistisesti tarkistaa jokaisen sivustoista jokaisen sovelluksesta kerran tunti ympäri vuorokauden.

Yhdistelmä käyttövalvonnasta ja visuaalisen kuvakaappauksen valvonnasta kattaa ongelman molemmat kerrokset. Käyttövalvonta saa palvelimen kokonaan offline-tilaan. Kuvakaappauksen valvonta saa sovelluksen katkosta, kun palvelin pysyy yläpuolella. Yhdessä, ne pienentävät havaintoikkunaa "milloin tahansa joku sattuu huomaamaan" valvontavälin itse, joka voi olla lyhyt kuin yksi minuutti kriittisille palveluille. Hälytys laukeaa, ilmoitus saapuu, ja korjaus alkaa minuuttien sisällä tuntien sijaan.

Palvelin on mennyt offline-tilaan kahdesti sen alkuperäisen tapauksen jälkeen. Molemmat kerralla, hälytys saapui kolmen minuutin sisällä. Molemmat kerralla, korjaus otettiin käyttöön ennen kuin merkittävä liikenne menetettiin. Valvontainfrastruktuuri maksoi itseään erittäin ensimmäisellä tapauksen kanssa se sai, ja kaikki jälkeen sitä on ollut puhdasta plussia. Aikakausi löytöä häiriöistä sattumalta on ohi, ja katsomalla takaisin, ainoa todellinen kysymys on miksi se otti viisi tuntia häiriö tehdä sijoitus ilmeinen.