Október 24-i leállás

A tegnapelőtti nap során megbicsaklott egy-két órára a pályázati rendszerünk legújabb gyöngyszeme, azaz le kellett állítanunk átmenetileg, és úgy értékeltük, hogy ezért magyarázattal tartozunk.

„Egy jó számítógép egyetlenegy másodperc alatt képes annyi hibát elkövetni, mint száz matematikus egymillió év alatt” – tartja a mondás, azonban ne legyünk ilyen igazságtalanok a szilíciumalapú barátainkhoz; sokat lendít a szorgalmukon, ha mi magunk is hibázunk, amikor adatokkal „etetjük”.

A „Valóságmodell” novellapályázatunk kísérleti munkaprogram, amelyben ötvözni igyekszünk – több kevesebb sikerrel – az anonim pályázati rendszert a promptos tematizálással. Mint ilyen tesztüzemekkor mindig, két program fut: az egyik a már beélesített, a másik pedig egy munkafelület. Ha úgy látjuk, hogy az éles felületen valamit finomítani kellene, akkor azt először a tesztfelületen mókoljuk meg, majd miután rendben lefutnak a próbák, egyszerűen átmásoljuk az adott részt az éles térbe. Ezzel az ősrégi trükkel megoldható, hogy az oldal biztonságosan fusson, de közben valós időben javíthassuk, ha valami nem tökéletes.

Na, itt lép be az ember, amely minden technológiai fejlesztés ellenére mindig is kreatívabb lesz a gépeknél. Jelen esetünkben a jószándékú igyekezet az, amit kiemelnénk.

A programozó kollégánk az egyik ciklikus folyamaton dolgozott, amely – a pályázattól függetlenül – arra hivatott, hogy a megjelent kötetek adatait valós időben (2 percenként) frissítse. Itt elkövetett két apró hibát: a programozás közben egy változót elírt, illetve véletlenül két mappába mentette el magának a módosítandó programrészt, és amikor az éles környezetbe másolta az újat, rossz példánnyal tette. Ehhez járult a poszt elején említett virtuális gyorsaság, és már meg is volt a baj.

A weboldalakon futó programok nagy százaléka kritikus hiba esetén leáll, apróbb hibák esetén tovább fut, ám mindkét esetben feljegyzi a hiba mibenlétét (logolja azt). Nos, esetünkben egy apró beállítási malőr miatt a szerver nem tartotta kritikus hibának a változócserét, hiszen logikailag helyes is lehetett volna, ám a folyamat elindított egy végtelen ciklust. A nagy számítási teljesítménynek köszönhetően a hiba másodpercek alatt annyi hibabejegyzést generált a tárhelyünkön, amely felemésztette a rendelkezésre álló kapacitást. A futtatott program leállt, azonban a szerver nem engedett további adatfeltöltést. Ez nem okozott összeomlást, hiszen a weboldalunk jelentős része nem generál feltétlenül adatokat, viszont azok a funkciók lefagytak, amelyek új adatok átvitelével vagy adatcserével járnak (pl. a pályázati felület).

Mivel teljesen máson dolgozott a programozó-kolléga, egyszerűen nem feltételeztük, hogy a pályázati felület leállása és az ő munkája közt bármi kapcsolat lehet, ezért szóltunk neki, hogy prioritással nézze meg, mi a gond az előbbinél.

Első megközelítésben az egész egy klasszikus szerverhibának tűnt, ezért felvettük a kapcsolatot a tárhelyszolgáltatóval (ezt le is kommunikáltuk a követőink, olvasóink és szerzőink felé). Ők nagyon készségesen a segítségünkre siettek, annak ellenére, hogy ez egy olyan pénteki nap délutánján történt, ami hivatalosan szombatnak számított. Sajnos nem tudtak segíteni, viszont felhívták a figyelmünket a telített tárhelyre. Ennek azonnal utánanéztünk, hiszen tudomásunk szerint a rendelkezésünkre álló tár nagyjából felét használjuk ki. Sok-sok gigabyte-ról beszélünk, tehát ennek a duplája …na, az még több. Nehezen tudtunk elképzelni ekkora egybefüggő fájlt, de átnézve a tárhelyünk mappáit hamar ráakadtunk a szörnyetegre.

A hibalog akkora volt, hogy nem tudtuk megnyitni. Nem tudtunk belenézni, de arra volt módunk, hogy töröljük. Gyorsan cselekedtünk, aztán árgus szemekkel figyeltük, hogy történik-e valami. Mivel semmi nem változott, a programozó-kolléga lefuttatta az utoljára változtatott szkripteket, hogy rájöjjünk, vajon melyik okozza a galibát.

A második tipp bejött: a programrész futtatását és gyors lekapcsolását követően azonnal megjelent egy újabb hibaüzenet Gólem. Nem volt olyan termetes, mint a korábbi – csak néhány száz megabyte-os –, de egyértelműen jelezte, melyik részlet a problémás. Mivel ezt a logot még meg tudtuk nyitni, azonnal kiderült, hogy egyetlen változó a ludas mindenért.

Gyors javítás, tesztfuttatás, majd ugyanez élesben is… Minden remekül működött, hibajelzés nélkül. S lett az munkatársak éljenzése, s az arcok mosolyra húzódása.

A történet ennyi.

S minek örülhettünk?

Egyrészt hamar felismertük, hogy főleg mi hibáztunk, egy picit a szervert beállító tárhelyes kolléga, s – mint minden katasztrófa okai – ezek összeadódtak. Másrészt annak is örülünk, hogy a moszkvai vagy washingtoni (vagy párizsi … vagy londoni … vagy tel-avivi stb.) atomtöltetek indítóprogramjait nem mi kezeljük.

Feltorlódó folyamatok

A pályázat adatai nem sérültek, úgyhogy minden folytatódik az eredeti elképzelés szerint. Kisebb finomításokat végeztünk – főleg a szövegezésben –, hogy egyértelműbb legyen minden, ám ez nem befolyásolja a nagy összképet. Érdeklődve várjuk a pályaműveket, és drukkolunk a szerzőknek, hogy megjelenhessenek.