- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Ki a hibás?
A backup stratégia kiot(l)ói!
- A hozzászóláshoz be kell jelentkezni
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”
- A hozzászóláshoz be kell jelentkezni
> Ki a hibás?
Soros! Gyurcsany! Tesla! Apple!
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
volt magyar egyetem is par eve ahol a HP cucca frissites vagy mi miatt elvesztette az adatokat,
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
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…
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
kozbeszben (KEF, mostmar DKU) nagyon ritkan kapni azt, amire szukseg lenne, ellenben vannak nagyon draga cuccok meg a piaci arnal is dragabban... es azokbol KELL valasztani :(
- A hozzászóláshoz be kell jelentkezni
Nem tudom ez mennyire új keletű, szerintem ez mindig is így volt.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
igy van. nem is allitottam az ellenkezojet :)
es pont ezert vettek sok egyetemen a 2000-es evekben EVA-t mert azt lehetett csak.
(es volt akkoriban egy EU palyazat ahol 100-200 milliokat kaptak az egyetemek IT fejlesztesre)
- A hozzászóláshoz be kell jelentkezni
Szóval a mostaniak sem jobbak...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
> az a cucc amit hasznaltak backupra az ahelyett hogy backupolt volna inkabb kitorolte a fajlokat
Nem osztogatnak...
fosztogatnak!
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ez milyen típus? A TS-431P2 esetében tapasztaltam ilyet, de az nagyon belépő-szintű modell.
A TS-873A viszont simán kibírja azt is, ha egyszerre 5 gép ment rá (mind gigabiten, amit a kliensgép elbír)
Nagy Péter
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
december 3, 17:32 utan keszult/modositott fajlokat erinti a dolog
Valamint tudjuk, hogy 77TB-ot toroltek. Ebből nagyjából kijön, hogy napi ~2.5TB adat keletkezett átlagolva decemberben.
- A hozzászóláshoz be kell jelentkezni
1 vagy 1,5 éve néztem, synology EGY diszkes NAS is már majdnem 100 ezer ft volt. Egy diszkes NAS, ezt ízlelgesse az informatikus ember. Azaz a lófasz kategória. Két lemezes RAID1 az, ami alatt nem lenne értelme (azaz szabad) ilyeneket árulni.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
"Szerintem ezt a láb témát engedd el" Az ft az a láb, a Ft az a forint. tessék megtanulni.
"a nas ha nem tud redundanciát mert csak 1fiókos, az kidobott pénz." - Neked a helyben adott redundancia fontos - másnak meg ez pont nem.
- A hozzászóláshoz be kell jelentkezni
30480m
a mértékegységet hogy kell írni, erre nincs valami pro tipp? :)
- A hozzászóláshoz be kell jelentkezni
Egy diszkes NAS, ezt ízlelgesse az informatikus ember.
Mi a baj vele? Ha nincs lóvé, kettő ilyen elhelyezve fizikailag messze egymástól tőbbet ér mint egy darab kétlemezes szinte minden szempontból.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
+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
- A hozzászóláshoz be kell jelentkezni
Kérdés mi fordul elő sűrűbben: megdöglik 1 diszk, vagy az egész NAS elszáll és ezért kell belőle 2?
- A hozzászóláshoz be kell jelentkezni
A RAID az nem backup. Ha verziozva mentel egy tavoli NAS-ra, akkor az egesz jo backup lehet (pl. ransomware ellen). RAID1 adta magas rendelkezesreallas nem feltetlen szempont otthoni kornyezetben.
- A hozzászóláshoz be kell jelentkezni
[x] Honnan tudjam? Nem ismerem a szerződés feltételeit.
- A hozzászóláshoz be kell jelentkezni
A felszabadult helyre már felfértek a HP(E) driverek? :D
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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....
- A hozzászóláshoz be kell jelentkezni
Ott a pont. :-D
- A hozzászóláshoz be kell jelentkezni
Miért is lenne ez olyan jó megoldás? 10TB ~40 dollár havonta. Enterspájz Google előfizetéssel meg 20 dollár a korlátlan gdrive, és még órákat sem várni az adataidra.
“Az ellenség keze betette a lábát”
- A hozzászóláshoz be kell jelentkezni
Ott viszont van napi upload limit, 750 GB / nap / user. Soknak hangzik, de a cikkben említett 77 TB-ot kb 3,5 hónap feltölteni egy drive account alá.
Nagy Péter
- A hozzászóláshoz be kell jelentkezni
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”
- A hozzászóláshoz be kell jelentkezni
Mire lejön klódból még Gbit WAN esetén is ilyen 10-20TBnyi adatok, az ember haja kinő.
- A hozzászóláshoz be kell jelentkezni
Nálad az internetszolgáltatóval lesz baj. 850-900 Mbps sebességgel jönnek le az adatok gdriveról, ennél lényegesen gyorsabbat gigabites kapcsolattal nehezen lehetne elérni.
“Az ellenség keze betette a lábát”
- A hozzászóláshoz be kell jelentkezni
Ha 1Gbit/sec letöltés megy 100% stabilan, az mondjuk 18TB-os letöltésnél kb 48 óra.
- A hozzászóláshoz be kell jelentkezni
szerintem sokan irigyelnek ha neked 2 nap alatt kino a hajad :)
- A hozzászóláshoz be kell jelentkezni
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”
- A hozzászóláshoz be kell jelentkezni
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.”
- A hozzászóláshoz be kell jelentkezni
A 21. század a hibás.
100 éve ilyen biztosan nem történhetett volna meg.
Régen minden jobb volt.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
hat 20 eve is volt mar tape loader...
- A hozzászóláshoz be kell jelentkezni
De, például LTO
- A hozzászóláshoz be kell jelentkezni
De még 20 éve is, amikor szalagra mentettünk :-)
A mai napig mentek szalagra. Is. :)
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Történt egyáltalán valami baj?
- A hozzászóláshoz be kell jelentkezni
Pontosan. Ha nem tudják reprodukálni azokat a kutatásokat, akkor eleve nem voltak tudományosak :-)
- A hozzászóláshoz be kell jelentkezni
Aha... Na, akkor rerodukáld a holdra szállást!
De aztán tudományosan! ;-)
- A hozzászóláshoz be kell jelentkezni
6-szor reprodukálták. Aztán már nem volt érdekes egy 7. reprodukálás.
Az elmúlt évtizedben ismét előkapta a politika a témát.
- A hozzászóláshoz be kell jelentkezni
Na ja. De mennyibe is fájt az a reprodukálás?
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
en is ismerek olyat, aki regi filmeket digitalizal, naponta tobb 10TB-ot termel a raw adatokkal, amit aztan feldolgoz, de backup nuku. ha elszall, akkor kezdheti elolrol...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
de mi nem dolgozunk terrákkal egyszerre.
Abban biztos vagyok :D tera lesz az!
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Azt hogy ki a hibás, majd az ügyvédek meg a bíróság eldöntik a szerződés alapján.
- A hozzászóláshoz be kell jelentkezni
Idejétmúlt felfogás. A mai modern korban ilyesmiről online szavazáson döntenek. :D
- A hozzászóláshoz be kell jelentkezni
Idejétmúlt felfogás. Majd az MI eldönti:
- A hozzászóláshoz be kell jelentkezni
De online szavazáson :)
“Any book worth banning is a book worth reading.”
- A hozzászóláshoz be kell jelentkezni
É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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
gondolom nem azert draga mert annyira megbizhato, hanem mert annyira gyors, es/vagy tud olyan featuret amit a petakokbol barkacsolt hazistorage sose.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Jaja, bűnbak a szakszerű neve. Hogy Rodolfót idézzem: csak a kezemet figyeljék, mert csalok.
Ez nem más, mint a figyelem elterelése a valódi problémáról.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
Az mekkora lenne.... Mennék libapásztornak, boldog lennék
- A hozzászóláshoz be kell jelentkezni
Liba van most is...
- A hozzászóláshoz be kell jelentkezni
A takarítónő porszívózni akart és nem volt szabad konnektor.
- A hozzászóláshoz be kell jelentkezni
Ja, egyik számítógéphálózatos cég, ahol réges-régen dolgoztam, ezért számlázott ki sürgősségi kiszállást egy intézménynek.
A takinéni tudta, hogy abban a konnektorban biztosan van áram. A központi switch konnektora volt az.
- A hozzászóláshoz be kell jelentkezni
De volt is benne áram! :)
- A hozzászóláshoz be kell jelentkezni
Haverom remote desktopon harcolt a local userrel, hogy ne kapcsolja ki, mert epp szeretne tavolrol frissiteni/debugolni a gepet :) De a kurzor konzisztensen haladt a Start menu gombja fele, meg a kikapcsolasra :)
- A hozzászóláshoz be kell jelentkezni
90-es evekben en is hallottam olyan sztorit hogy egyik novell szerver minden hajnalban 3kor ujraindul, es nem talaljak az okat. aztan meglett: oda dugtak a porszivot :)
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
(gondolom kabalából) a vödörben sosem cserélt felmosóvizet.
A fekete kakas áldozás megelőző rítusa: az éltető füstöt bent tartja a titokzatos zömmögő fém dobozokban :).
- A hozzászóláshoz be kell jelentkezni
normális salgópolc
nagyon aranyos megfogalmazás :))
- A hozzászóláshoz be kell jelentkezni
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..
- A hozzászóláshoz be kell jelentkezni
Egyértelmű.., a soros!
- A hozzászóláshoz be kell jelentkezni