Még napokig húzódhat a MÁV jegyrendelési rendszerének megjavítása

Offtopic

http://www.origo.hu/itthon/20110826-meg-napokig-tarthat-a-mav-jegyrende…

Tudom bulvár hír, lehet nem is igaz hardver hiba.
de mindent elmond arról hogy milyen komoly informatika rendszerek vannak hogy 3 napig nem működik a cég lefontosabb szolgáltatása. Monjduk ha áll a vonat azt se veszik komolyan ez igaz. De persze ha állami pénzt kap valaki biztos nem kell olyna gyorsan dolgozni.
Komoly cégnél lehet fejek is repülnének, most meg gondolom lesz csak egy ejnye bejnye..
informatika, mérnökök, állami pénz..

( bazso | 2011. 08. 26., p – 15:09 )

Genyó dolog mások nevén viccelődni (és ha olvassa szeretnék sűrűn elnézést kérni miatta), de a kommunikációs vezető neve alapján én nem hardverhibára gyanakodtam volna :-) (Hackl Mónika)

( zeller | 2011. 08. 26., p – 15:57 )

"A MÁV tájékoztatása szerint egyelőre a rendszer lelkét képező számítógépek hardverproblémáinak elhárításán dolgoznak, a működés helyreállításához azonban a felhasználói adatokat is újra fel kell vinni majd a rendszerbe, ami még napokig eltarthat."

Erre nem lehet mit mondani...

Laikusként azt gondoltam volna, hogy erre már van valamilyen jól bevált technológia, (backup, redundancia, akármi)
és ezt egy ilyen méretű cégnél mundjuk meg is tudnák fizetni, de azt hiszem mással van a baj. Mégpedig azzal hogy
az utas van az utolsó utáni helyen az egész rendszerben.

( _Franko_ v | 2011. 08. 26., p – 16:11 )

"A MÁV Informatika Zrt. magyarázata szerint az e-Ticket rendszer leállását az azt kiszolgáló tárolórendszer meghibásodása okozta, amely kezeli egy, illetve kettő lemez meghibásodását a tartalék lemezek bevonásával. Szerdán - viszonylag egymáshoz közeli időben - három lemez hibásodott meg, így a RAID-technológia nem tudta pótolni a kiesett lemezeket és az e-Ticket-et kiszolgáló lemeztömb leállt."

...ahha... nem volt beállítva riasztás...

"A közlemény szerint a hiba észlelését követő bejelentés után a szállító cég azonnal megkezdte a helyszínen a munkát, azonban a meghibásodott diszkek cseréje sem vezetett eredményre, mert szoftverhiba miatt nem lehetett üzembe helyezni az új lemezeket."

...ahha... nincs mentés se...

"Amíg a hardver- és a szoftverhibát nem tudják kijavítani, és az új lemezek nem állnak rendelkezésre, nem lehet visszaállítani az e-Ticket szolgáltatást, illetve nem lehet felelősen megbecsülni újraindulásának idejét - jegyzi meg közleményében a MÁV."

...ahha... nincs backup rendszer...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Képzelem, mekkora műszaki szenzáció lehet egy jegyrendelő rendszer... ha csak nem tárolják 9600dpi truecolor BMP-ben az összes kiadott jegyet :) akkor pár diszkből lehet kellő kapacitással és IOPS-al rendelkező tömböt csinálni egy kutyaközönséges szerverből, a polcról lepottyanó első kommersz RAID vezérlővel, aztán давай!

... aztán majd csak megtojja a beszállító a "világon-csak-egy-van-belőle" ÜberSAN(TM)-hoz a hiányzó csavaralátétet...

Ugye, milyen okos vagyok, így távolról? Pedig még csak két pohárral ittam.

Gondolom volt spare -> "tartalek lemezek bevonasaval". Csakhat ha egy sok diszkes, ugyanolyan lemezokbol allo tombot beuzemelunk, annal nagyobb az egyideju tobb disk kihullasanak az eselye minel tobb diskbol all a tomb es ilyenkor hiaba van spare, ha rebuild alatt a RAID tureshatarahoz kepest +1 disk kiesik.

A sparediszket b...hatod, ha akkor hull ki egy újabb lemez a tömbödből, amikor még nem szinkronizált be a spare...
Az persze csúnya dolog, hogy nincs dDR-site, amire ilyen kiesésnél rövid, előre tervezhető idő alatt át lehetne állni, vagy legalábbis nincs egy másodlagos storage, amire megy a DB-szinkronizálás...

Túl jókat gondolsz róluk, hogy feltételezed egyszerre haltak meg. Szerintem meghalt egy, jött a "tartalék lemezek bevonása", de basztak rá, meghalt még egy "ó megy ez még, majd következő negyedévben veszünk, mert elfogyott a keret", oszt a harmadik meg úgy döntött, nem igazodik a könyveléshez.

Miota en 2-3 alkalommal szembesultem a "ket diszk egyszerre halt meg, egyszerre vettuk oket" esettel, megtanultam, hogy a raidet csak es kizarolag sebesseg szempontjabol hasznaljuk, nem backupnak, mert joesellyel mindegyik egyszerre szall el ugyis.

(Ergo nem igerunk arra hogy diszkhalal eseten nem kell 1 napnyit visszagorgetni, az egyszerre vett raid az single point of failure, ennyi)

Merhogy a RAID az nem backup, hanem egy redundáns tömb, olcsó diszkekből, ergo annak is kéne használni, felmérve azt, hogy a redundancia pontosan mit is jelent, milyen hibákra ad megoldást. Plusz manapság a k. nagy diszkek világában is meg kéne tartani azt a jó szokást, hogy raid-tömb alá nem nagy, hanem sok diszk kell. Egy nagy diszk kihullása ugyanakkora probléma, mint egy kicsié - viszont tovább tart a helyreállítás, hosszabb ideig marad sérülékeny a tömb.

Oke, mashogy fogalmazok: nem ruhazunk be raid tombbe azert, mert azt hisszuk, hogy a redundancia azt jelenti, hogy nem lesz adatvesztesunk, mert raid tombben vagyunk. Magyarul nem ruhazunk bele nagyon a raidesdibe, mert x > 0 esellyel semmit nem er mint redundancia, ehelyett fizikai redundanciat (hot backup, stb) hasznalunk.

(Mivel a raid egy helyre fog menteni, es utana osztja szet, ezert a rendszerben meg mindig van egy pont. Ha pl. shardingolsz, teljesen fuggetlen gepekre (tehat a-c kozott gep1-en tarolod, kulon storage-dzsal, c-f kozt gep2-n stb, akkor elvesztettel 1000 user adatait, de a rendszer nem fog osszeomlani, mivel fuggetlenul mukodnek)

Mi még software raidnél is hetente verifyolunk mindenhol tudom hogy még ez se a legtutibb, de ott a backup, amit ráadásul még irodán kivülre is viszünk.

Legjobban idegesítő dolog hogy adófizetők pénzét pazarolják, mert nyilván pénzt nyúltak le itt is rendesen és minden máson spóroltak. ennyi..

Nem értem. Ez nem hardver/szoftver kérdése, hanem gondolkodásmódé.
Ha egy jegyértékesítő rendszert kell terveznem (mint ahogy részt vettem egy hasonlóban még a 90-es évek elején), akkor az első dolog, amire megoldást kell találni: minimum két fizikailag nem összefüggő helyen kell tárolnom az adatokat. Ha erre a modemes világban lehetett megoldást találni, akkor ma nem hiszem, hogy olyan irgalmatlan nagy probléma.

Van olyan, hogy költséglimit - gondolom, itt a DR-site (meg úgy a DRP mindenestől) lett az első körben ennek az áldozata, aztán hogy üzemeltetési hiányosság van-e a balhé mögött, nos azt szerintem hivatalosan nem fogjuk megtudni...

Attól, hogy x cég egyik terméke/szolgáltatása khm. problémákkal terhelt (azaz sz@r, adatvesztést produkálnak, etc.) attól még egy másik lehet jó - pláne, hogy ez utóbbival már van hosszú idejű tapasztalat.

Ez úgy hangzik, mintha a diszkek egyszerre lettek volna beüzemelve és elérték volna az üzemidejük határát... Nem volt pénz időben kicserélni 10-20 lemezt? Hogy néz ki ott az üzemeltetési terv, vazze?

Már csak egy költői kérdés: Ha System Z-re, meg DS8000-re volt pénz, akkor egy ilyen fontos rendszernél nem volt még plusz pár millió legalább egy disk-to-disk backupra, vagy szinkronizálásra? A hardver összárához képest ez elenyésző összeg és a MÁV nyilván nem listaáron vásárol... :(

( kisauto | 2011. 08. 26., p – 18:08 )

elmennek ezek a budos picsaba.. de komolyan.

az elmult 6 evben kb 180 sotrage lett telepitve, raid4dp -ben a lemezek.
es kurva eletnek nem jott elo, hogy egy raid groupbol egyszerre kihuljanak.

na jo jo... de ennek az a menete, hogy oda tolom moge a storageot.
Ha a storage kihullik, akkik kicsereli nekem a garanciaban a gyarto, mert ertelmes szerzodest kotok vele es backupbol visszatolom.

Ez legyen 1 nap. Nem tudom, hogy az IBM MO milyen csoda szolgaltatast ad, de NetApp -al es HDS -el ilyen a budos eletbe nem jott elo.

Ha extrém kritikus a rendszer, akkor a kihullott storage-ról átállok a tartalékra, amin a teljes adathalmaz on-line ott van tükrözve. Erre akár két szimpla szerver drbd-vel összerakva is megfelel. Bár ha a széthulló storage összekócolta az fs-t, akkor csak a backup marad.

Nem, ez a MÁV Informatika. Szerintem semmi köze az adóforintoknak hozzá, hacsak az nem, hogy sok mindent tőlük vesz a MÁV, kurva drágán. De próbáltak ők elmenni üzelti irányba is, csak hát, a MÁV-os, khm, munkamorál, az a szokásos volt. Vannak ott jó szakemberek, vagyis voltak, lehet azokat elüldözték, vagy lepattantak jobb helyre. A középvezetésük viszont, egyik ügyfélnél megtapasztalt kapcsolat alapján, - meg amiket hall az ember, de arra nem kell mindig adni ugye - egy kupac lócitrom volt.

Az lett volna a minimum, hogy van egy értelmes mentés, tartalék lemezek vagy olyan szerződés a storagehoz, hogy 8 órán belül hoznak lemezt, napi inkrementális mentés legalább heti full mentéssel. Nem tudom mekkora lehet az adatbázis, de azért 60-80GB-nál többre full mentésnél sem tippelek - tömörítve -, hiszen ez egy jegykezelő rendszer és a kiadott jegyek képét gondolom nem tárolják, csak a járatszámot, vásárló mail címét, az auth kódot az automatához, az időpontokat - vétel, kiadás -, meg ha duplikálják és nem kivülről kérdezik, akkor a vonatok adatait.

Mielőtt hallottam volna a történtet, azelőtt nekem sem volt ilyenben részem - az viszont biztos, hogy itt nem hallották a régi igazságot: Az az adat, ami egy helyen van meg, az nincs meg. Ami két helyen van meg, az talán megvan még... A RAID itt (sem) helyettesíti a backup-ot, és nem oldja meg a single point of failure problémát, amit a diszktömb teljes kiesése okoz...

( Maxim | 2011. 08. 26., p – 23:16 )

Ha nem képes a MÁV megfelelő hardvert tolni a szolgáltatása alá, akkor inkább profikra kellene bíznia ezt a feladatot. Már régen Amazon EC2-re kellett volna költöztetni ezeket a szervereket.

Mindig lesz aki megvédi a nagy "mérnököket", csak néha azt érzem hogy X évnyi felső oktatás helyett egy nagy adag józan paraszti ész kéne.
A vezetők meg csak utazni tudnak: http://www.vg.hu/gazdasag/gazdasagpolitika/ujabb-gyanusitasok-a-mav-inf…

De persze máv informatika kimagyarázza majd magát, hogy ez ilyen meg olyan bonyolult rendszer.
a nagy l..f.szt! komolytalan cég, aki ennyi idő után se tudja elhárítani ezt a hibát. Senkit ne tévesszen meg hogy mennyi forgalma van, állami pénz mosoda.

Ennyi idő alatt már bármilyen storageral újra tudnák indítani persze nincs mentés.

A felsőoktatás (így egyben) az "iparban" nem sokat ér - tisztelet a kevés kivételnek. Informatikus mérnök képzés, de egy komolyabb IT-rendszer alapjait összerakni, akár elvi síkon, "gombócokból" nem tanítják meg, teljesítményhangolás, hibakeresés általános alapjait dettó, hogy az IT-biztonság témájáról ne is beszéljünk...

Vagy van olyan képzés, ahol ez mind része a tananyagnak...?

Hat nekem azert meg fejbol kellett tudni adott feladatra skalazni .NET-et meg J2EE-t oracle backenddel, egyetemi tananyagkent... De igy akkor ehhez a TTL-hez milyen rpm-es vinyo kell ha az alaplapi buszsebesseg ennyi, a cpu ennyi, a muvelet becsult ideje ennyi stb... Szepen megszamoltattak minket neha, sokszor szandekosan kamu szamokat (as in: feladatot nem befolyasolja) berakva...

It biztonsagbol meg BME-s labor szerintem eleg eros, de majd eax elmondja, mit hallott Vajdaekrol.

Igen, így ki lehet számolni egy optimális hw-t, amihez becsülni kell egy 3 év alatti funkcióbővülést, szintén 3 év alatti forgalomnövekedést, majd egy biztonsági tényezőt, és még egy kicsivel fel kell szorozni. Aztán kapsz egy valamilyen hw-re pénzt, és a végeredmény úgyis az lesz, hogy olyat kell venni ami skálázható (és/vagy akciós a szerződött partnernél), mert sose lehet tudni mi lesz fél év múlva. De lehet hogy csak nekem vannak ilyen tapasztalataim.

Az gépészeti számítások, amiket anno a Krupp műveknél találtak ki és azóta is használják(*) őket nem ritkán tartalmaznak egy "tapasztalati úton felvett módosító érték"-et, ami azt jelenti, hogy az elméletnem passzolt össze a gyakorlattal, így viszont elég jól közelíti.

*) Ezt valaki erősítse vagy cáfolja meg, rém régen tanultam pl. mechanikát.

Hat en mai napig FPA-val becsulok szoftvert (hardvert marha ritkan kellett, jellemzo throughputot csak), ott ugy indul hogy tapasztalati teamsebesseg, ezt lattam mar 0.75-on es 8-on is, jellemzoen minel nagyobb egy ceg, annal lassabb, es erre jon a modulok mindenfele facetjeinek tapasztalati szamai, amibol megadnak egy induloerteket, hogy ugy kb. ilyen aranyban allnak egymassal iparilag, de piszkalgasd.

Ket-harom projekt utan +-10%-os becsles egy-ket honapig futo projekteknel, ez egesz jo, plusz-minusz egy het.

Nem az oktatást kérdőjeleztem meg, de ha történnek ilyen bakik, most lássuk be nem olyan probléma volt amire nem lehetett volna előre felkészülni, akkor valahol a rendszerben ezt valaki(k) nem tudják hogy hogy van.
Mert most ha felrobban épület ahol a rendszer van akkor még simán ügyfél szemével megérthető közel 1 heti kimaradás jegy eladásban.

Normális BCP esetén felrobbanhat az épület, az üzlet megy tovább... Ezen belül a drp meg megaszongya, hogy az IT-t hogy és miből és mikorra lehet és kell feléleszteni. Jelen helyzetben elmondható, hogy ezek a hárombetűsök :) nem, vagy nem jól lettek kitalálva/leírva...

A szoftver már egy külön kérdés, de itt a vas adta meg magát. Szerintem most sem grátisz áras az üzemeltetés, MÁV-nál nem szokás. :-)
Az EC2 természetesen nem az egyetlen választás. A lényeg, hogy profik kezében legyen a vas, mert ami most van az egy amatőr projektre emlékeztet.

Nem külső üzemeltető, aki válogathat, hogy mit vesz át önsziva... akarom mondani üzemeltetésre, és mit nem. Az más kérdés, hogy ilyen struktúrában meg szokás kérdezni, hogy az üzemeltetés milyen hardveres infrastruktúrát lát jónak az adott szolgáltatás alá, és figyelembe venni a válaszokat a beszerzés során. Viszont a beszerzésnél ott van a költségkorlát, ami kompromisszumokat hoz magával - pl. azt, hogy egy darab storage lesz a nyugodt alvást biztosító kettő helyett. Az persze sajnálatos dolog, hogy normális drp nem készült, de gondolom, ahogy az nagyon sok esetben lenni szokott azt "csak egy plusz papírkupac"-nak tekintette az, akinek a pénzt kellett volna rászánni...
Az, hogy nem érdekli a céget a szolgáltatás rendelkezésre állása, mert marginális bevételt generál, ez sajnálatos - itt nem a pénzben kifejezett veszteség a jelentős - aki utazni akar, az más, hagyományos módon is meg tudja venni a jegyeket - hanem az, hogy egy jó és jövőbe mutató (máv szinten legalábbis jövőbe mutató, hiszen a világ boldogabbik részén ez már régóta létező és jól működő dolog) szolgáltatást sikerül olyan igazi mávos szinten megoldani, úgy, hogy ennél a szolgáltatásnál is nyugodtan rákérdezhet a naív ügyfél, hogy "Miért Állunk Vazzeg???"

Függetlenül az érintett, állítólag kevés neten jegyet vásárló utastól, ez az ügy komoly arcvesztés a MÁV-nak.
Hogyan bízzak meg abban, hogy a váltókat precízen és balesetmentesen állítgatják ha itt ilyen trehányak?? Azoknak is ez jön le ebből a történetből akik még legalább 5 évig biztosan nem fognak semmilyen jegyet neten vásárolni.

Lényegtelen melyik vágányon megy, a biztber mindenképp megállítja (bár a rézkábel ugye elég kelendő...) a térköz előtt a szembejövőt és a helytelen vágányon haladót is. Ha egy kicsit visszakeresel a mindenféle, és szerencsére nem túl sűrű, vasúti (tehát nem arra, amikor az autós a tilos jelzés ellenére szétcsapatta magát) balesetre akkor látni fogod, hogy nagyrészt valamilyen emberi mulasztás (esetleg üzemzavar közben) okozta a bajt.

(Ha nincs biztber akkor állomásközben lehet közlekedni, nincs olyan hogy ráeresztik a vonatot a másikra. A nagyszülők pont egy gyérebb forgalmú vonal mentén laknak és látom, hogy hiába tudják a vasutasok, hogy "á biztosan nincs vonat" szigorúan betartják a rendet.)

A napi 1000-es vásárlásnál az sem mind1, hogy vesznek 1000db bp-nyíregyháza retúr IC jegyet vagy csak mondjuk Komáromtól-Bábolnáig... :)

Mi elég sokat vonatozunk nagyszülőkhöz, de az átvétel miatt eddig inkább nem próbáltam ki, mert igencsak ciki egy lastminute variálás ha esetleg mégsem megy. Egy vonalkódos vagy SMS-es módszer sokkal jobb lenne amit csak meg kell mutatni a kalauznak, ellenőrzi a "központtal" és kész.

A Volánnál már próbáltam, de a sofőr elég furcsán nézett rám, nem igazán tudta, hogy mit kell ezzel csinálni. :)

Nyilván nem grátisz, de feltehetően ezen a szinten olcsóbban kijön (egy rendesen hibatűrő) megoldás is, mint mondjuk 2-3 évnyi EC2-zés. Arról nem is beszélve, hogy az EC2 jó esetben is Írországból megy és a két példányos házon belüli backupot is meg kellene oldani onnan.

Ja és mégvalami. Gondolom nem vagyok egyedüli aki már több olyannal találkozott hogy a sw vagy hw support is erősen vakarta csak a fejét vagy csak simán minden előzetes nélkül szétszált a RAID tömb és a megoldás a backup visszarakása volt. (Igen ez ellen véd a redundancia és a failover is, csak aztán ne egyszerre halljon meg a két node.)

( pepelopez | 2011. 08. 27., szo – 11:55 )

A MÁV Informatikán tudják mitől döglik a RAID :)

( trying | 2011. 08. 29., h – 16:25 )

Nemrég voltam állásinterjún a MÁV Informátikánál. Egy tesztfeladatot kellett megoldani számítógép előtt, amit szinte hibátlanul teljesítettem. Mondta is az ember, hogy megfelelek, majd értesít. Értesített is, nem vett föl. Kérdeztem, hogy miért nem vesz fel, hiszen a teszten megfeleltem? Azt mondta, hogy igen, a teszten megfeleltem, de nem mondja meg az okát, hogy miért nem vesz fel. Úgy néz ki, hogy nem szakmai okok miatt nem vettek fel. Ide nem tudás kell, hanem valami más. Undorító szemét társaság. Megérdemlik, hogy összeomlott a rendszerük.

Nembaj, a publikus dühöngésedet meg a többi munkáltató fogja undorítónak tartani.
Tegyük fel, hogy bemész egy boltba, felpróbálsz egy ruhadarabot, jó is neked, jól is áll, de nem veszed meg, és nem magyarázod meg, hogy miért. Ezt követően az eladó egy nyilvános fórumban névvel odaokádja, hogy nem indokoltad meg, miért nem vetted meg az adott árut, holott jó volt rád, és hogy ez milyen undorító dolog már...
Te ennek az üzletnek a hozzáállását hogyan értékelnéd?

( zeller | 2011. 08. 29., h – 17:41 )

"2011.08.28. 18:55: Ismét lehet a neten vonatjegyet rendelni" - úgyhogy megoldották a problémát - igaz picit sokáig tartott...