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

 ( jzola | 2011. augusztus 26., péntek - 12:08 )

http://www.origo.hu/itthon/20110826-meg-napokig-tarthat-a-mav-jegyrendelesi-rendszerenek-megjavitasa.html

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..

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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)

"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.

A fentibol jol latszik, hogy nemhogy redundancia, de meg backup sem nagyon volt... Gratulalok.

Azért a MÁV-nál nagyobb infós multiknál is előfordulnak hasonló trehányságok.

Jól gondolod, van. De azt használni is kéne, meg ésszel tervezni a dolgokat, úgy, hogy egy raid-tömb teljes elhalálozása nem okozzon megoldhatatlan problémát...

"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

Ha igaz ez a kozlemeny, akkor alapvetoen azzal van a problema, hogy az erintett rendszert kiszolgalo storage egyetlen RAID 6 tombbol allt, ami nevetseges.

De legalább (biztosan) drága volt.
Térjünk vissza rá, ha sikerült megoldaniuk, hogy ne kelljen sorba állni a jegyek kinyomtatásáért.

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.

A commentem az idezett, velhetoen sajtoanyag alapjan szuletett es nem pedig a velt belsos informacioim alapjan.

Kihagytad, hogy a tökik nem konfiguráltak spare diszket sem.
Mellesleg egy időben 3 diszk meghibásodása igencsak necces.
És most már tudom, miért van a ZFS-ben tripe-parity raid. :D

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)

dup. bocs.

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)

Hol terjedt el, hogy a RAID backup célokra is jó? A RAID arra jó, hogy pár merevlemezt egyben, gyorsan és kiesésmentesen - ezekből kettőt választva - lehessen használni. :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Hol terjedt el, hogy a RAID backup célokra is jó? A RAID arra jó, hogy pár merevlemezt egyben, gyorsan és kiesésmentesen - ezekből kettőt választva - lehessen használni. :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

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..

Ma a közigazgatásban három hitelesítő cég aláíráshitelesítését, illetve időbélyegzését fogadják el, ebből a MÁV Informatika az egyik.

Brrrr... Ebbe rossz belegondolni...

Nagyon sok storage-on annak a Microsoft-nak az embedded XP oprendszere fut, aki a Sidekick felhasználók jelentős mennyiségű adatát oly ügyesen képes volt elveszíteni.
Brrrr... Ebbe rossz belegondolni...

Remélem, érted a párhuzam okát/lényegét...

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... :(

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.

Itt előjött valamilyen hiba - láttunk már olyat, hogy adott adatmenyiség utána elkezdte a raid-vezérlő kidobálni a ráaggatott ssd-ket egy raid10-es tömbből... mind a négyet... Az ssd-k persze hibátlanok, köszönik szépen, azóta is működnek...

haaaat, en nem lattam.
enterprise storagon egyszeruen csak nem tortenik ilyen.

Tettunk 2T -t egy raid groupra... eppen semmi nem tortent.

+1 márpedig mint az tudható mainframen fut a rendszer, gondolom normális storage is van mögötte (talán DS8*00)

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.

Hat de ezaz....

vagy van egy tartalek storage, ha nincs akkor ott a backup. a MAV -nak semmilye sincs.
Es az egeszben az duhit kurvara, hogy adobol fizetjuk oket. Ha nem tetszik valami, akkor meg sztrajkolnak.

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...

Ahogy a régi fotótanárom mondta: azt is lehet rosszul csinálni.

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.

Ekkor arccal simán elmehetnél linuxadminnak :)

De inkább olvass egy kicsit:
http://www.mavinformatika.hu/mavinformatika/referencia_lap.php?mid=145e55f11cb906

Csak nem vagy sáros az ügyben lúúzerke?
Rendelj MÁV jegyet a neten! Ja, hogy nem megy már napok óta, hát akkor befoghatnád a lepénylesőt!
:-)

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-informatika-zrt-nel-341595

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...?

A legó elég sok elemét tanítják - remélem - de hogy abból hogy lesz házacska, azt már az életben kell megtanulniuk. Legalábbis én így vélem.

Azért egy alapvető mit rakunk az alapba, miből húzzuk fel a falat, mi kerül a tetőre dolgot illene tudni a frissen végzett mérnöknek, mert ilyesmi nélkül önálló alkotó munkára alkalmatlan.

Illene.

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...

Náluk volt az a logwatch hogy ember meredt a monitorra és sasolta mint állat a pörgő logot?

És persze mindenképp PHP+Mysql... :) Ezt a felhőmániát azért nem teljesen értem, főleg hogy a mávos igényhez valszin elég rendesen felpörög a számla is EC2-n és csak az üzemelés.

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.

Lehet profi üzemeltető, ha a rendszer kialakításakor nem kérdezték meg, hogy hogyan is lenne jó üzemeltetési- és rendelkezésre állási szempontból megcsinálni a rendszert.

Akkor ne vállalja be. Egyhetes leállás nem kifejezetten jó reklám.
Állítólag napi 1.000 körüli jegyvásárlás történik, gondolom baromira nem érdekelte a mávot, minthogy ennél lényegesen több embert érintő dolog sem szokta.

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.

POntosan ez a probléma az egész balf@szk0dással, hogy az egész netes jegyvásárlási dologgal szemben bizalmatlanságot szül.

Jobb ha nem ismersz belsős sztorikat a melyik vonat, melyik vágányon megy részről... hidd el! Inkább kibirom pisilés nélkül a buszon. :)
--
http://www.naszta.hu

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 MÁV-nak nem nagyon van már miből vesztenie... minden szolgáltatásának a minősége alulról konvergál a nullához...

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.)

Én olyanról tudok, amikor a bécsi enterspájz support centerrel karöltve egy raid-tükör egyik fele alatt döglődő diszk cseréje során sikeresen elqrták a még jó diszken is az adatokat...

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

Most már igen :-D

Azt, hogy mitől, nem tudják, csak azt, hogy döglikött.
RAID veled.

RAID jo mindhalalig. :)

Nem ez van a háttérben?

---
http://youtu.be/wzEahz7pa7k

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.

Lehet, más is meg tudta oldani a tesztfeladatot. Csak jobban el tudta magát adni...

---
http://youtu.be/wzEahz7pa7k

Nem tudom, de ha így lett volna, akkor mondta volna meg. Más helyeken meg szokták mondani, hogy találtak tapasztaltabbat vagy valami ilyesmit. Azt viszont undorító dolognak tartom, hogy nem indokolják meg.

+1

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?

Jól van, igazad van. Megyek tovább. Remélem, hogy találok egyszer egy olyan céget, aki megvesz.

Ez a helyes hozzáállás - sokszor annak is lehet örülni,ha van visszajelzés - nem jó, de ez a sajnálatos tapasztalat...

A munkaerőpiacon te vagy az eladó, és a cégek a vevők. Ha megmondják, hogy miért nem, akkor szerencséd van, ha meg nem akkor...

---
http://youtu.be/wzEahz7pa7k

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

Az nagyobb kérdés, hogy a már megvett jegyeket visszahozták-e? Ha nem, akkor ez egy reinstall volt. :P
--
http://www.naszta.hu

Viszont innentől a tranzakció archiválása a vásárló feladata.