Ki a hibás? - 28 TB-nyi kutatási adatot vesztett el a Kiotói Egyetem

Egyéb

"77 TB kutatási anyagot törölt a HPE" és egyéb hangzatos címekkel ment a közösségi terekben, híroldalakon a sztori, miszerint óriási adatvesztés történt a Kiotói Egyetem szuperszámítógépes rendszerén. Kicsit utánajárva a témának, kiderült, hogy a 77 TB-ból "csak" 28 TB-nyi adatot nem tudnak visszaállítani a biztonsági mentés hiánya miatt (sajnos csak Google fordítás érhető el az eredeti japán nyelvű bejelentésből):

(Kiegészítő megjegyzés 2022. január 4-én)

Ebben az esetben a rendszert szállító Hewlett-Packard Japan által kifejlesztett és karbantartott biztonsági mentési program frissítési munkája során a cégért felelős mérnök nem vette kellőképpen figyelembe az eljárást, ami váratlan működést eredményezett. a fájl elveszett Az érintett felhasználó megkeresése fedezte fel, és a probléma törlési folyamata leállt. Csak a fájlvesztés a biztonsági mentési program meghibásodása miatt Egyéb probléma, pl. kiszivárgás nem fordult elő .

A biztonsági mentés hiánya miatt vissza nem állítható fájlok körülbelül 28 TByte kapacitásúak és körülbelül 25 millió fájlok voltak.
Mivel ez az érték tartalmazza azokat a fájlokat is, amelyeket nem kell visszaállítani, a vissza nem állítható fájlok tényleges helyzete körülbelül 8 TByte. , körülbelül 25 millió fájl Körülbelül 3,5 millió fájl.

A tároló elsősorban a szuperszámítógép számítási eredményeinek tárolására szolgál, a közvetlenül vissza nem állítható adatok közül fontolgatjuk a számítási erőforrások kiegészítését a szuperszámítógép általi újraszámítással visszanyerhető adatokkal.

A fájlvesztés által érintett felhasználók száma 68 volt. A felhasználók között vannak az egyetemen kívüliek is.

Ez a központ a Hewlett-Packard Japanhoz van kiszervezve, és úgy gondoljuk, hogy az üzemirányítási rendszerrel, mint egyetemmel volt probléma. Az ismétlődés megelőzése érdekében felülvizsgáljuk az üzemirányítási módszert, beleértve a biztonsági mentés megerősítését is.

A HPE, mert ő szállította a szoftvert és a frissítést és hozzá volt kiszervezve az üzemeltetés
29% (191 szavazat)
A HPE mérnöke, mert nem kellő gondossággal járt el
5% (34 szavazat)
Az egyetem, mert nem ellenőrizte a partnerét
3% (18 szavazat)
Mindenki hibás: a HPE, a mérnök és az egyetem is
40% (263 szavazat)
A HUP, mert ilyen híreket lehoz!!!
20% (129 szavazat)
Egyéb, leírom.
3% (18 szavazat)
Összes szavazat: 653

( Hevi v | 2022. 01. 06., cs – 15:15 )

Ki a hibás?
 

A backup stratégia kiot(l)ói!

Erre szoktam mondani, hogy 2020-as években már felhő, és három komolyan vehető felhős szolgáltató létezik: Google, Microsoft, Amazon. 

A többi meg orosz rulett. Legyenek annyira olcsók, hogy kijöjjön az árból két párhuzamos B kategóriás  megoldás. Helyi+felhő, vagy két olcsó felhő. Akkor meg lehet fontolni, de szvsz úgy is csak extra munka. 

“Az ellenség keze betette a lábát”

( arpi_esp v | 2022. 01. 06., cs – 15:22 )

> Ki a hibás?
 

Soros! Gyurcsany! Tesla! Apple!

( arpi_esp v | 2022. 01. 06., cs – 15:25 )

Szerkesztve: 2022. 01. 06., cs – 15:25

nem tudom arrafele mi a helyzet, de a magyar egyetemeken es kutato intezetekben (sokat ismerek) orulnek ha egy storagera osszekalapoznak valahogy penzt, nemhogy meg annak a full backupja (ami azert min 2x akkora tarhely) is meglegyen...

volt magyar egyetem is par eve ahol a HP cucca frissites vagy mi miatt elvesztette az adatokat, nem egyedi eset ezek szerint.

azaz:

"elmondta, hogy az egyetemnek alapvetően korszerű infrastruktúrája van, a mostanihoz hasonló hiba ritkán fordul elő, de a PTE-nek szűkös forrásai okán eddig nem volt pénze biztonsági szerver- és tárolórendszer vásárlására és üzembe helyezésére"

https://itcafe.hu/hir/pte_pecs_egyetem_rendszerosszeomlas_adatvesztes.h…

Lehet, hogy nem kurva drága HP EVA-ra kellett volna elverni a pénzt, hanem kisebb storage-ra, aztán maradt volna még lóvé pár nearline SAS (parasztos nevén: enterprise SATA SAS csatlékkal) diszkes mentésre is :D

A dolgot árnyalja, hogy - állítólag - végül mentésből lapátolták vissza a holmit, de "kismértékű" adatvesztés történt azért (gondolom az aznapi meló).

trey @ gépház

hat volt az tobb napos (email) es hetes (tanulmanyi rendszer) adatvesztes is a cikk szerint. de legalabb volt valami backupjuk :)

az EVA resszel nagyon egyetertek. anno, ugy 15 eve az OE is vett EVA-t palyazatbol, aztan amikor elkezdtek hullani a diskek, szembesultek vele, hogy 1db FC disk kerul 2000 euroba, es kb hetente kellett (volna) venni egyet, mert ugye supportra/garanciakiterjesztesre mar nem futotta. workaround: mindig csokkentettek a kapacitast addig amig szinte elfogyott :)

amugy mentsegul annyit hogy akkoriban kozbeszben nemigen volt mas opcio... amelyik gyarto a legjobban "lobbyzott" az kerult be a valasztekba, es azok nem az olcso cuccok voltak...

Mivel szerintem kevesek egyike vagyok itt, aki több HP EVA tanfolyamot is végigült, hetekig konfigurált laborban és vizsgám is van talán belőle több is, pontosan tudom, hogy itthon nem sok olyan vállalat volt, akinek szüksége lett volna a tudására és/vagy ár/érték arányban azt kellett volna feltétlen megvennie.

Ja, és persze, üzemeltettünk is élesben :D

trey @ gépház

Annak idején (10+ éve) a partner jó fej volt, mert simán lehetett vele egyezkedni (mi van a papíron és mi jön ténylegesen ki). Az is igaz, hogy masszívan nem volt szabályos, de így lehetett értelmesen működni olyan vassal, ami nekünk is jó volt. Ma nem tudom, hogy megy.

https://naszta.hu

Előtte meg volt egy IBM z-s adatvesztés is storage miatt a MÁV-nál.

Egyébként szerintem az egyetem és a HPE közötti szerződés alapján dől majd el, hogy ki a hibás, de leginkább a HPE esélyes. Ott meg már eldöntik, hogy a szoftver, vagy a mérnök, vagy mi.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Amennyire itt sikerult kibogozni a dolgokat, itt nem ilyen gondok voltak hogy nincs love storage-ra, hanem hogy az a cucc amit hasznaltak backupra az ahelyett hogy backupolt volna inkabb kitorolte a fajlokat (valami regi log fajlokat akartak torolni, de aztan kicsit tobbet sikerult). Meg ugye irjak hogy a december 3, 17:32 utan keszult/modositott fajlokat erinti a dolog, gondolom akkor volt elotte az utolso backup.

I hate myself, because I'm not open-source.

Tudom, hogy egy HPE Storage nem olcsó, de mentésre nem lenne elegendő egy 8 lemezes QNAP NAS?

98 TB RAID5-ben 1,5 millió forint alatt van (8 lemezes NAS + 8DB 14TB-OS HDD), de bővítőfiókkal és nagyobb lemezekkel könnyen lehet 300 TB-ot egybe rakni RAID5 alatt, és még úgy is meg lehet úszni 4 millió forint körül. 

Nagy Péter

Azert ez nem ilyen egyszeru. Siman lehet hogy gyorsabban kepzodik/valtozik az adat, minthogy egy ilyen lowcost storage-ra ki lehetne menteni. Foleg ha nem file-okrol van szo, hanem block storage snapshotolasrol (mert mondjuk adatbazis adata), amit mondjuk at kell szinkronizalni egy masik hasonlo kaliberu storage-ra.

Persze lehet hogy egy ilyen segitett volna, de azert ovatosan az ilyen bemondasokkal.

mi pont hasznaltunk qnap-ot mentesre. amig egyszerre egy gep ir ra addig nem is volt gond, de ha tobb szerver probalta iscsi-n hasznalni menteshez egyidoben akkor leszakadoztak es megallt a mentes, a syslogot meg ugy telefosta hogy betelt a rendszerdisk is :)

szoval ha van egy kozponti mento szoftvered es csak az ir ra, es huzza le sorban egyesevel az inputot ugy meg elmegy.

Azt, hogy ott konkrétan milyen módon és milyen adatformátum keletkezik, nem ismerem, de amit írtam NAS-t, az egy QNAP TS-873A + QXG-10G1T bővítőkártya + 8 Darab WD RED Pro 14 TB HDD.

Mentés közben az 579 MB / másodperc sebességet szokta hozni átlagosan (videofájlok és PNG szekvenciák vegyesen). Ezzel a sebességgel (ha nincs semmilyen különbözeti mentés), 28 Tb-ot ~14 óra alatt lehet lementeni. Ha csak időszakosan, kisebb hirtelen terheléseket kell elbírnia, akkor SSD cache-el az első 1/2/4 TB (SSD mérettől függően) mentése akár 1500 MB / másodperc sebességgel is tud menni vele (2 darab NVMe SSD hely van benne gyorsítótárnak).

Azt nem tudom, hogy az ottani storage milyen sebességgel tud dolgozni, de egy ilyen középkategóriás NAS meglepően gyors tud lenni.

Nagy Péter

Bő 30 kilométer? (100000 ft az 30480m) Ez az egyik... (A magyar fizetőeszköz, azaz a Forint rövidítése Ft) A másik, hogy nem mindenkinek, nem minden alkalmazásra kell a hálózati elérhetőség mellett a redundancia. Ha a "Két lemezes RAID1 az, ami alatt nem lenne értelme (azaz szabad) ilyeneket árulni." javaslatodat továbbgondolod, akkor JBOD vagy RAID0 tudást sem lenne szabad NAS-ban implementálni.

Szerintem ezt a láb témát engedd el :)

Én ha nas-t (így kisbetűvel remélem nincs vmi más értelmezése) vennék, azt a rendelkezésreállás miatt venném, és azért a pénzért amiből egy kis használt skylake-es ITX gépet is be lehet állítani, a nas ha nem tud redundanciát mert csak 1fiókos, az kidobott pénz. De nyilván ezzel csak én vagyok így, különbennem lenne synology-nak se annyi féle 1fiókos doboza annyi pénzért amennyit kérnek azokért.

Hát olyan adatot tárolsz rajta, aminél fontos a magas rendelkezésre állás és az adatbiztonság, akkor ott legalább 2 lemezes NAS-t érdemes venni. De ha mondjuk fontos neked, hogy egy lakástűz után is meglegyen minden adatod, vagy akkor is legyen mentésed, ha a rablók elviszik otthonról a NAS-t, akkor a nyaralóba / szülőkhöz / nagyszülökhöz is érdemes venni egy második NAS-t, és éjjelente a távoli NAS-ra készíteni egy mentést az otthoni NAS-ról. Erre a célra viszont már elegendő lehet egy egylemezes NAS is. 

Amikor megjelent az egylemezes NAS, én sem értettem, hogy mire jó; de aztán rájöttem, hogy sok helyen felesleges pénzkidobás a 2 lemezes NAS.

Nagy Péter

+1

Ismerek olyat is, aki a felhőben tárolja az adatait (Google Workspace), de egy local NAS-ra backupol. Szerintem ott is a local NAS-ba is RAID-et rakni már inkább pénzkidobás, hiszen a Google eleve redundánsan tárolja az adatokat, és emellett még mentést is készít róla, jó eséllyel soha az életben nem lesz szüksége a NAS-on tárolt adatokra. De ha egyszer mégis így alakulna, kicsi az esélye, hogy egyszerre omlik össze a google hálózata, vesznek el a google mentései, és még a NAS-ban lévő merevlemez is lehal.

Nagy Péter

( Gyuszk v | 2022. 01. 06., cs – 16:35 )

[x] Honnan tudjam? Nem ismerem a szerződés feltételeit.

( gemnon v | 2022. 01. 06., cs – 17:07 )

A felszabadult helyre már felfértek a HP(E) driverek? :D 

( uid_6201 v | 2022. 01. 06., cs – 18:24 )

Ami a témanyitó információi alapján látható, több esemény együttes láncolata vezetett a végleges adatvesztéshez.
Volt bármiféle információbiztonsági irányítási rendszer bevezetve? Ha nem, vagy csak papíron, akkor eddig valójában nem volt fontos a felsővezetésnek az adat.
Ha volt, akkor pedig valójában sokkal több felelőse van, mintsem az incidenst kiváltó mérnök. Itt egy csomó előírás és kontrollfolyamat régebb óta sérült/hiányzott, amit az incidens hozott felszínre.

A szomorú az, hogy ha körülnéztek, valójában a legtöbb cég még mindig így működik. Ez pedig addig nem gáz, amíg a szerencse a cég oldalán áll. Sőt végülis addig olcsóbb.

Ez mindig ilyen, több esemény együttes láncolata, de ez felelősségkenegetésre jó csak. A lényeg, hogy fel kell készülni mindig ez ellen, ha más nem backup-pal. Másik oldalról viszont 28 tera adat ilyen egyetemi, szuperszámítógépes méretekben nem olyan sok, csak nekünk tűnik óriásinak átlagosabb user szemével. Kevésnek se kevés, de nem egy világmegváltó adatmennyiség.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

( khiraly | 2022. 01. 06., cs – 19:04 )

hol van ilyenkor az amazon glacier mentes?

:)

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Szerintem 3,5 hónapnál sokkal hosszabb idő alatt keletkezett az a 77 TB. 

Illetve ha rövid időn belül kell letölteni azt a 77 TB-ot, akkor az elég sokba kerül Amazon glacierrel. Általában ez a jellemző eset, lassan csorognak fel a napi adatok és ha valami megreccsen akkor minél hamarabb kell mind vagy jelentős részük. 

“Az ellenség keze betette a lábát”

Mi lenne a kontra érved? A Google hibája, hogy nem csönget a szerelőjük egy órával az enterspájz szerződés aláírása után a 10 Gbps csomaggal? Vagy rossz az egész cloud mert lassú és az is marad? 

Utóbbira azt tudom mondani, hogy 1 Gbps jelenleg Magyarországon magánszemélyek számára is kínált sávszélesség, nem mindenhol de elég sok címen. Ezzel világviszonylatban elég jól állunk. A Kiotói egyetem számára ennél sokkal nagyobb sávszélesség áll rendelkezésre és média tanszéket leszámítva nemhogy két nap de két félév alatt sem keletkezik ennyi adat náluk. A helyi szalagos archiválás természetesen gyorsabb, de a földrajzilag eltérő redundáns tárolás már bonyolítja a saját kézben tartott backup és archiválási stratégia megvalósítását. Pláne ha kihagyjuk belőle az adatok interneten való továbbítását. Szokás még teherautón utaztatni adatokat, aminek mint tudjuk jelentős a sávszélessége? :-) Ha viszont interneten küldjük át az archiválandó adatokat földrajzilag más helyre, máris ugyanott vagyunk mint felhős szolgáltatóval. Igen a letöltés a másik irány ha megreccsent valami. Biztos vagyok benne, hogy van ott 10Gbps sőt annál sokkal gyorsabb kapcsolat is és nem a letöltés lesz a leghosszabb művelet a helyreállításnál. 

“Az ellenség keze betette a lábát”

( harlequin | 2022. 01. 06., cs – 19:08 )

Nem tudom ki a hibás, de ha a HPE mérnöke a hibás, akkor a HPE a hibás :)

“Any book worth banning is a book worth reading.”

De még 20 éve is, amikor szalagra mentettünk :-)  Aztán ha éjjel elaludt az operátor, és nem cserélt szalagot, akkor reggel úgy nyitottunk, hogy a kutya se tudta, hogy az előző napiból az egyetlen szalagra éjjel mi került... adatok, vagy csak a nullák, vagy esetleg fehérzaj...

( uid_4656 v | 2022. 01. 06., cs – 21:48 )

Történt egyáltalán valami baj?

( st3v3 v | 2022. 01. 06., cs – 23:08 )

szerintem egyértelmű: a kutatók a hibásak, hogy a storage-re kutatási adatokat termeltek! :)

dombon ülő fűcsomó legyek ha értem mi felelőssége lenne a gyártó/üzemeltető/support-nak ;). By default a user a hibás!

( Aadaam v | 2022. 01. 06., cs – 23:14 )

Szerkesztve: 2022. 01. 06., cs – 23:15

Ilyenkor remélem, hogy a 3-4 féle storage rendszer amik párhuzamosan futnak, tényleg megment…

Ahogy írják, volt egy rakás fájl, ami eleve nem annyira lényeges, hogy legyen róla backup, mások igazából újrafuttathatóak… nyilván sz.pó, meg nálunk is ezért vannak eltérő backup rendszerek egymással párhuzamosan, amik ugyanazt lementik máshogy… de mi nem dolgozunk terrákkal egyszerre.

UX-ben az összes ilyen hibavédelemnél az a kérdésünk, mennyi idő alatt generálható újra az adat, ezt elképzelhető, hogy ki lehet terjeszteni sysops-ra…

10mp alatt semmiféle védelmet nem alkalmazunk: ha valami elszállás esetén 10mp alatt újraírható, írd újra.

1-2 perces adatoknál alkalmazunk ilyen “nem mentetted, biztos jó neked?” dolgokat, esetleg undo-t.

10 perces adatmennyiségeknél már van automatikus mentés és tsai, ha valami 10 perc alatt hozható vissza, minimum van egy lomtár.

a következő lépés a másfél óra környékén van, ott már látható egy verziókezelés, többféle backup van, elég nehéz tökön szúrni magadat.

egy munkanapnál meg már kérjük a rendszergazdákat, hogy legyen napi mentés és a support érje el 30 napig a backupot.

de nyilván ezek a nettó, kézzel belepakolt időkre vonatkoznak. Amikor “csak” gépidő megy, ott lehetnek mások a skálák, főleg azért, mert a kézi adatnál - pl. ez a komment - simán az van, hogy ha elszáll, az új, amit írnék helyette, már nem lenne pont ugyanolyan, míg ha gép generál valahonnan valamit compile jelleggel, az újrafuttatva is kb. ugyanaz lesz.

( Caro | 2022. 01. 07., p – 07:06 )

Azt hogy ki a hibás, majd az ügyvédek meg a bíróság eldöntik a szerződés alapján.

Én nagyon lekorlátoznám, hogy egyáltalán mennyi felelősséget lehessen szerződés alapján továbbhárítani.
Csak kimondottan biztosítási szerződés mentén tenném lehetővé eszmei kár megtérítését, azt is csak a szerződésbe előre belefoglalt dolgokra kiterjedően és értékhatárig.
Fontosnak tartom, hogy a felelősséget minél kevésbé lehessen kiszervezni, ugyanis az csak contradictory interest-ekhez vezet, és végül valakinek a hazárdírozásán fog múlni az egész szarkupacnak a sorsa.
Egy olyan rendszerben, ahol erősen korlátozottan hárítható csak át a felelősség, a résztvevőknek muszáj komolyabb assessment-et csinálni és megalapozottabb döntéseket hozni. Vagy pedig biztosítási árfekvésben szerződni, így talán üzleti alapon kigazdálkodható lenne egy esetleges kártérítés.

a résztvevőknek muszáj komolyabb assessment-et csinálni és megalapozottabb döntéseket hozni

És már kezdünk is elmozdulni arra, ami az információbiztonsági irányítás témaköre. Felmérés, kockázatelemzés, adatvagyon, arányos intézkedések... szóval jó az irány. Bárcsak ezzel előre tisztában lennénk és nem utólag menne a tűzoltás.

És ha már a felelősség kiszervezésnél tartunk: Azure, AWS, Google, stb. felhőszolgáltatásnál vagy akár VPS szolgáltatásnál milyen mértékben biztosít minket a felhő-/VPS szolgáltató? Ennek ellenére miért nem csinálunk az ott futó céges szolgáltatásokról megfelelő szintű rendszeres biztonsági másolatot? Végülis az adatkezelő még mi maradtunk, a szolgáltató vagy adatfeldolgozó vagy még az sem. Bármikor kiszállhat a képből. Azaz az adatainkért a legfelsőbb felelősség valójában rajtunk marad, minket fog adatvesztés érni.

Ugyan miért kellene ilyen korlátozás? Ez egy storage rendszer. Hadd vállaljon a gyártó amit akar. Akármilyen biztonságú rendszernél is mindig lesz adatvesztés, csak egyre kevesebb. Ha ő ennyire bízik a termékében, akkor ezt a kockázatot vállalnia kell, és akkor fizetnie kell.

Más nem nyúlt bele az ő rendszerébe. Az ő saját munkavállalója nem tartotta be az eljárást. Ha ő adatgaranciát vállalt, akkor ezt igenis fizesse meg.

Ha nem vállal adatgaranciát, akkor mivel ad ő többet, mintha én csinálnám? A logóját? Akkor én is építek storage rendszert, petákokból hozzá képest. Aztán ha szétesik, majd ugyanúgy szétteszem a kezem, hogy bocsi.

Ezt a felelősség áthárítás korlátozást nem igazán lehet értelmezni. A felelősség lényegében pénz. Nem lehet megtiltani, hogy akár beperelje a beszállítót kár esetén. Azt viszont jól látod, hogy sokszor a nagy nevű (és nagyképű) cégek mögött alvállalkozói lánc áll, ahol mindenki fele pénzért továbbadja a munkát addig a pontig, amíg már nincs aki kevesebbért elvállalja. Aztán a papír sokmindent elbír, meg a nagy cég nem konkrét személyt, hanem munka kapacitást ad és így lehet arra hivatkozni, hogy nincs olyan, hogy valaki lebetegszik vagy netán meghal és oda a projekt. A valóságban viszont sok feladatnál ugyanúgy egyetlen személyen múlik, mert nem alkalmaznak több személyt egy feladatra, hogy legyen tartalékos ember. Nem tud egyik napról a másikra más beugrani a helyére, ha kiesik. Hazárdíroznak, hogy általában nincs baj, vagy ha beüt, majd kimagyarázzák. Ezért veszik fel a nagy lóvét.

A szerződésekben lehet olyan korlátozás, hogy nem lehet a munka elvégzését kiszervezni alvállalkozónak. Más kérdés, hogy tényleg betartják-e. 

A felelősség pénz, igen. De nagyon nehéz megállapítani, hogy mennyi.
Ezt csak tevékenységi körbe tartozó jogi entitásnak (pl. biztosító) engedném meg árusítani, mint szolgáltatást.
A továbbhárítás intézménye számomra nem szimpatikus. Megy a hazárdírozás, ahogy Te és mások is írják.
Én eleve nem számláznék olyan cégre, amin van asset. Basszák meg. Nem fogok azért csődbe menni, mert valami elfosta magát.

A szerződésekben lehet olyan korlátozás, hogy nem lehet a munka elvégzését kiszervezni alvállalkozónak. Más kérdés, hogy tényleg betartják-e. 

Ohoho, mentem én úgy magyar állami ügyfélhez projecten dolgozni, h. egy nagy amerikai multi hazai leányvállalata alkalmazottjaként lettem bemutatva a hazai leány alkalmazott projectmanagere által. Aki előtte 2 nappal kért el a valódi echte kkv gazdáimtól sos, mert nagy volt a szar és kellett nekik sürgősen ember, akár külsős is. Csak erről az apróságról a magyar állami üffélnek 1 szót se! Kaptam volna még kamu nagymultis emailcímet is, de arra végúl nem volt szükség.

jajj ez de ismeros... nekem is van mar tucatnyi kamu email cimem olyan cegektol akik nevebe valaha dolgoztam az o ugyfeleiknek...  mondjuk volt ahol neztek nagyot hogy elozo heten meg mas ceg neveben jartam naluk :)

meg ismerek olyat is, aki egy nepszeru specialis szoftver egyeduli magyar tudora/supportosa, es tok mindegy melyik ceget bizzak meg, mindig o megy ki az ugyfelhez telepiteni...  meselte hogy volt mar hogy elegedetlenek voltak vele ezert legkozelebb mas ceget biztak meg, sokkal dragabban raadasul, aztan megis o ment csak mas neven :)

volt mar hogy elegedetlenek voltak vele ezert legkozelebb mas ceget biztak meg, sokkal dragabban raadasul, aztan megis o ment csak mas neven :)

És elégedettek voltak? :) 

Nálunk volt olyan, hogy az ügyfélnek félévente pontoznia kellett a kapcsolattartót is (tehát engem), valamiért az értékelés pontszáma és a szerződésben szereplő összeg kivétel nélkül egyenesen arányos volt.

( dyra | 2022. 01. 07., p – 08:11 )

Ilyenkor szokta Terike elvinni a balhét, aki nem vette észre, hogy egy számlát visszadobott az automata rendszer és emiatt nem lett időben befizetve a szolgáltatás havi díja.

( uid_16313 | 2022. 01. 07., p – 08:14 )

Szerkesztve: 2022. 01. 07., p – 08:15

Ha eltűnne az Interneten lévő összes adat, az emberiség visszasüllyedne a középkorba. Google nélkül tudatlanok vagyunk. Mert keresni megtanultunk, tanulni meg elfelejtettünk.

Nem rémlik, hogy az internet középkori találmány lenne.

Meg aztán a keresés csak az információszerzés első állomása. A következő lépés, hogy a találatok közül kiválaszd, hogy melyik a helyes. Az sokkal nehezebb.

Na de erre találták fel tehetséges emberek a szavazást!

Science for fun...

( Polesz v | 2022. 01. 07., p – 08:20 )

A takarítónő porszívózni akart és nem volt szabad konnektor.

Megtörtént eset, BME egyik tanszékén, első kézből.

Az épületben nem volt rendesen kialakított helyiség szervereknek (a switch elosztószobák voltak telepakolva random tanszékek random szervereivel, egymás hegyén-hátán, senki nem tudta a sajátján kívül melyik kié, összevissza kábelezés, klíma nem bírta, konstans 40C+ stb.) Ezért a tanszékünk az egyik kicsi raktár/takarítószertárat átalakított saját használatú szerverszobává. Lett klíma, rendes 3-fázisú szünetmentes, rack, normális salgópolc, meg minden.

De a takarítónéni cuccait nem volt hova tenni, ezért azok is ott maradtak a szoba egyik felében, és neki is megmaradt a bejárása oda. Ami különösen vicces volt, mert a takesznéninek voltak érdekes skilljei. Pl néha felmosta a padlószönyeget, valamint (gondolom kabalából) a vödörben sosem cserélt felmosóvizet. A szerverszoba levegőjének ezáltal volt egy jellegzetes "aromája".

Egyik nap a következő beszélgetésre lettünk figyelmesek:

[Takesznéni] - És tessék mondani, ezekben a gépekben is áramköri kártyák vannak?
[Tanszéki admin] (szeme kikerekedet): - I...igen, de miért tetszik kérdezni?
[Takesznéni] - Hát mert fiatal koromban telefonközpontban dolgoztam és az volt a feladatom, hogy ilyen szekrényekben áramköri kártyákat cseréljek
[Tanszéki admin] (halálra vált arccal): - Igen, DE ezekhez NE tessék hozzányúlni! Semmi körülmények között!

Régóta vágyok én, az androidok mezonkincsére már!

( zeller | 2022. 01. 07., p – 10:52 )

Dézsa víz... :-) Picit kisebb méretben sok-sok évvel ezelőtt hápux, rootdiszk tükrözve, ahogy kell. Egyik diszk szórta a hibákat. HP-s mérnök érkezett, elkezdte a diszkcserét - aztán a vége reinstall lett... Azt a post mortem jelentést elraktam, mert a "hogyan magyarázzuk meg..." tökéletes mintapéldája.
Na első blikkre itt is hasonló magyarázatokat olvashatunk..

( hokuszpk | 2022. 01. 10., h – 08:54 )

a Norton Antivirus :D

HUP te Zsiga !