Ono bude ve finale podstatny predevsim to, co maji zakaznici ve smlouvach. Ja jsem se osobne uz nekolikrat setkal s podobnyma pindama na tema "100% garance" ... pripadne "nic se nemuze stat" ... ale jakmile sem po dotycny firme chtel, at se tedy zavaze ke smluvni pokute v radech miliony denne (prece se nic nemuze stat, tak to nikdy platit nebudou) ... tak bylo najednou vymluv, jak to nejde.
Dovolim si strelit, ze to mohlo vypadat nasledovne>
Technik zjistil, ze neco prestalo fungovat. Nejakou dobu zkoumal remote ... a kdyz zjistil, ze se na dany HW proste nedostane, tak se zved, a sel se podivat na misto. Tam chvilu vyvalene cumel, jak chcije voda ... zved telefon, a volal nejakymu tomu managorovi, ze tam chcije voda. Mozna zaroven poznamenal neco o tom, ze to bude treba cely vypnout ... nacoz mu managor rek, ze mu asi jeblo ... a ze to nepripada v uvahu ...
Mezitim dorazilo par kolegu, protoze se problemy namnozily ... a zacli tedy delat co bylo v jejich silach - nejaky ten kybl, hadry ... sehnali nekde udrzbare aby vypnul vodu ...
Lidem sedicim na telefonu se samo nereklo nic ...takze jim nezbylo nez si neco pro zakazniky vymyslet. Nefungujici switch je dobre zduvodneni naprosto cehokolil ...
jsem tam pres 10 let urcite. vzdy spokojenost maximalni a pochopil bych, ze se toto stalo. co ovsem nepochopim je, ze me na helplajne tahate za nohu, ze na tom pracujete. nepochybuji o tom, ze ano. ovsem moc dobre vite, ze takova nehoda nebude odstranena v nejake rozumne dobe. pokud bych toto vedel hned, tak jsem mohl nejake zasadni veci presunout docasne jinam a necekat, ze to "za chvili" nabehne. takze sluzby spokojenost. nehoda - za tu nemuzete. za to, ze mlzite a zakaznik se nedozvi realny stav - nazdar. pripravili jste me o nekolik hodin, co jsem to mohl resit a i o nekolik klientu.
mejte se fajn a jestli pri vypovedi vytahnete neco jako vypovedni lhuta, tak tu vypoved tam pujdu dat osobne a hezky to nebude.
byvaly zakaznik
Když pominu zjevné základní chyby jako že nikdo nevypnul elektriku v serverovně kde tekla do serverů voda a řešil to igelitem a popelnicí (takže úspěšně zvýšil míru škody na běžícím hw) , tak existují v podstatě jen dva možné důvody proč Casablanca tak dlouho vysílala z technické podpory neurčitou mlhu.
a) Jejich technici hodiny vůbec nevěděli co se děje. Potom je to případ obludné nekompetentnosti a jasný důvod změnit poskytovatele.
b) technici věděli co se děje ale manažeři rozhodli že se to pokusí nějak ututlat a utáhnout zákazníky na marketingové kecy. V tom případě je také nejvyšší čas změnit poskytovatele, protože když dodavatel takhle lže, tak těžko je pak možné věřit technickým parametrům, funkčnímu zálohování a dalším skutečnostem co si zákazník nemá moc jak ověřit.
Na stránce www.casablanca.cz/produkty/cloud bylo možné se ještě ráno dočíst že výhodou jejich "cloudu" je "100% garantovaná smluvní dostupnost" viz.: http://www.nahraj-obrazek.cz/?di=113903983332
Nyní už pro jistotu vše přesměrovávají na hlášení o poruše.
Zcela bezpochyby se jedná o podvodné jednání, neboť 100% dostupnost musí logicky zahrnovat nejen geografickou zálohu, ale také geografickou duplicitu řešení.
Osobně to mám tak že má ve dvou serverovnách dvě sady strojů lišící se z důvodu ceny pouze rychlostí diskového pole a procesorů. Záloha dat se dělá denně kompletní a co 30 minut přírustková z primárního serveru na sekundární.
Obnova dat na sekundárním stroji trvá cca 20min a stroj je udržován ve zcela stejné SW konfiguraci jako primár. Čili v podobném případě, změním DNS záznamy a během 20 minut mám provoz kompletně obnoven. Sice na pomalejším HW, ale (testoval jsem to) ten rozdíl není zas až tak markantní.
Přesto jsem si nikomu nikdy netroufl říci, že mám dostupnost 100%.
Paradoxní je, že se dokonce jeden zákazník přesouval ode mne na Casablanku...chtěl totiž od mne slyšet těch 100%.
Asi mu zavolám jak se daří........:)
Skoda, ze jste zakaznikum pri uzavirani smluv rikali neco jineho. Ale to by pak asi zase nebyli vasi zakaznici. On je rozdil, kdyz nekomu reknete, ze nekde je v podstate zrdcadlo cloudu a kdyz padne primar, tak se nic nedeje a prepoji se na ten zreplikovany a neco jineho je, kdyz mu reknete, ze nekde mate zalohu, kterou delate casteji nez je obvykle. Protoze jedno je garantem dostupnosti a druhe je max. garantem toho, ze zakaznik neprijde o sva data.
Vyjádření k tiskové zprávě:
1. Prý tomu neslo zabránit. LEŽ! Ve stropě serverovny byly tak diletantsky zakončené odpady - jen zaplněné PU pěnou. Byla to jen otázka času.
2. Okamžitě byla provedena veškerá nutná opatření aby nedocházelo k dalším škodám. LEŽ! Chtěli to ututlat a ani u serveru který byly pod vodou nevypnuli elektřinu.
3. Infolinka byla informována. LEŽ. Infolinka tvrdila ze se nic neděje a maji jen drobné problémy na switchi.
Vy jste snad insider:-)
Na Nove by to bylo asi takto: Mel to byt den jako kazdy jiny, to by ovsem nesmelo natect nekolik kbeliku tolik nebezpecne vody do elektroniky. Voda pripravila nekolik bezesnych noci stovkam lidi. Podivejte se na pokusu co se stane, kdyz nalejete vodu do obycejne zasuvky. Je jasne, ze technologie nemohla napor vody vydrzet.
Spis nez umyslne mlzeni se jednalo o obvykly pristup, tedy mlzeni dale v kombinaci se zmatkem z neocekavane situace a nedostatkem informaci mezi pracovniky, kteri museli odpovidat neco hned. Pouceni do budoucna.
Poskytovatel virtuálního serveru z logiky věci nemůže odpovídat za chování aplikací, kterou si zde zákazník nainstaluje a provozuje. Zálohuje se vlastní úložiště, poskytovatel ani nemá administrátorský přístup k vlastnímu serveru. Zodpovědnost za aplikační zálohy je především na administrátorovi systému.
A tato diskuze přímo přehlídkou těch neschopných administrátorů, co nechápou základní terminologii a fungování technologií. Normální fušeři :-)
Naprosto stejna zkusenost. Firemni politikou pod novym vedenim je zrejme lhani, coz v tomhle pripade drasticky zvedlo skody. Kdyby rovnou priznali co se deje, mohli zakaznici zacit vcas s disaster-recovery a netvrdit ze jsou jen drobne problemy na sitove infrastrukture. Navic nechali vsechny servery i v dobe kdy vedeli ze do nich tece pod proudem. Pokud by to vypnuli vcas, bylo by to jen mokry. Takhle se veskere kontakty kam se dostala voda zacaly obalovat ruznymi solemi a oxidy. Ikdyz se malou cast serveru po urputnem boji podarilo zapnout, spolehlive fungovat uz nebudou nikdy. Voda v serverovne - nejsou prvni ani posledni telehouse kterymu se to stalo, ale jsou prvni s tak tragickou kominikaci a zamernym lhanim, ktere akorat prodluzuje vypadek pro zakaznika ktery vcas nemohl zacit s obnovou - na me to pusobi jako zamerna sabotaz vlastnich zakazniku.
"Geografická záloha primárního pole slouží zejména k replikaci dat zákaznických serverů a nikoliv pro produkční provoz."
Aha, tuhle nepodstatnou drobnost ste ale zakazniku nejak zapomeli rict predem ...
Presne v souladu s porekadlem, data v cloudu ... data v coudu. Kdyby si zakaznik provozoval srv doma pod posteli ... byl by na tom o dost lip. Minimalne by totiz vedel, ze to byl jeho cokl, kdo mu do toho nach...al. A jako bonus, by si drzel nahradni zelezo, protoze by s takovou udalosti pocital.
To prece vubec nemusi lhat, proste delali kazdou hodinu snapshoot filesystemu. Jenze ten je ekvivalentni stavu disku po nasilnem vypnuti serveru, pokud v tom virtualu nebezi procesy, ktere ho po dobu snapshootu uvedou do konzistentniho stavu. Takze pokud nekdo po dobu snapshootu neudelal na mysql "FLUSH TABLES WITH READ LOCK", tak celkem ocekavane nemusi byt ty tabulky vubec konzistentni. Ale nevim jak konkretne to meli resene u nich.
A na ty podminky mate nejaky papir odsouhlaseny obema stranami?
Velmi casto jsem se (jak na strane poskytovatele, tak na strane zakaznika) potkal s tim, ze si je obe dve strany vykladaly ruzne. Coz muze byt sice fajn v okamziku, kdy podepisujete papir (protoze to setri nervy obchodnikum), ale uz je to mene fajn v pripade, kdy potrebujete vymahat nejake plneni.
Mozna mi neco unika, ale vy jste prece udelali nejakou trivialni preimplementacni analyzu, kde jste si rekli, co je jak zapojene a co to zapojeni chrani. Tu jste delali s nejakym presales inzenyrem, ze?
Vychazim z toho, ze kdysi jsem nejaky deal s Casou i dalsimi poskytovateli delal a vzdycky jsem chtel vedet, co mi vlastne poskytuji. Obcas to slo i do situaci, kdy jsem jim rikal: "Hele ja tomu nerozumim, co presne znamena XXXX? A obchod jsme neudelali, dokud mi to nebylo jasne."
Lidi od Casy i dalsich poskytovatelu se chovaji plusminus stejne, pokud jim kladete podobne otazky a pracujete s plusminus stejnymi lidmi. Kdyz se vyhnete vseobecne znamym osobam a firmam, tak jste i na ceskem "vychodnim" trhu celkem bezpecny.
Cilem obchodu by melo byt, aby obe strany vedely, co je poskytovano a co a kdy za to plati. Pokud si to jedna ze stran nezjisti, tak je to predevsim problem te strany, co si to nezjistila.
Jasne, Casa z toho ma ted PR (a casem i legal) polizanici, nicmene ten, kdo na to doplati vice, jsou jeji klienti, kteri si v tom neudelali jasno.
No k reseni se postavi tak, aby minimalizovali skody. Ze to nedelaji na Lupe a na Facebooku? Inu skody se neminimalizuji tak, ze pri vypadku zacnete ukazovat ramena ve verejne diskusi.
Stejne tak nemuzete cekat, ze nekdo bude davat kuzi na trh s tim, ze je bude chvalit. Uz jen proto, ze hlasice nepopularnich nazoru si jiste vezme nejaky kvalitni anonym "do ust".
Casa nepusobi 10 let na trhu virtualizacnich sluzeb. To, ze nekdo umi dobre vec X, jeste neznamena, ze umi dobre i Y i presto, ze X prodava dohromady s Y.
Ja mam bohuzel vyhodu, ze v pripade poskytovatelu IP sluzeb si pamatuju prakticky vsechny od doby, kdy si koupili prvni smerovac.
Chapu, ze ne vsichni disponuji tim, ze na trhu pusobi 20 let (sakra to je doba), nicmene v pripade, ze se pohybuju na trhu, ktery neznam, tak se snazim odhadnout rizika a nespoleham na product sheety. Ne vzdycky se mi to podari odhadnout spravne, ale snazim se poucit z vlastnich chyb.
Dne 20. ledna 2014 cca v 11:13 došlo ve vzdálených prostorách budovy Stimbuilding k havárii vodovodního potrubí. Bohužel voda vnikla do sálu č. 8 a poškodila nejen několik zákaznických technologií, ale i náš cloud BIG BLUE ONE. V současné době probíhá rekonstrukce cloudového datového pole a obnova uložených dat ze záložního řešení našimi specialisty ve spolupráci s expertním týmem dodavatele. Data v současné době bohužel nejsou dostupná.
Obnovu funkčnosti řešení BIG BLUE ONE předpokládáme během zítřejšího dne.
Zákaznické technologie jsou v současné době přestěhovány do sálu č. 7. Kompenzace způsobených problémů se bude řešit formou pojistné události. Celé události je nám velmi líto, nicméně nebylo v našich silách jí zabránit.
Lupa tu ma nejakou ochranu na kopirovsani odkazu.. tzn. kdyz udelate ctrl+c odkaz vypada jako http://www-.casablanca.cz/in-formace/
Takze si to opravte a funguje.
Memu klientu se uz nekolik webu rozjelo (rodina eshopů) jenze tam chybi poruznu nektera data a nekdy i cele DB tabulky jsou prazdne.. Nevim jak Casablanca poresi ta zatim neobnovena data, kdyz mezitim tam uz vesele probihaji dalsi nakupy.. no nic, budeme nuceni stehovat jinam.
Souhlas. Nerad to říkám, ale strašný mrdky. Hlavně jejich komunikace včera. Kdybych neměl schopného IT, tak se nic nedozvím. Helpline mlžila. No nic, za blbost se platí, naskočil jsem na jejich promo o 100% dostupnosti. V případě problému se to přepojí do jiné lokality a jedete dále... jejich slova. Realita je jiná.
No prave tim, ze nam nedali vedet, ze to opet nahazuji, odstartovali to samozrejme bez naseho vedomi s neuplnymi DB.. nezachytili jsme ze to vlastne spustili. A kdyz jsme to zjistili, uz tam byla halda novych dat. Vykopal bych z tech obchodu aspon indexy natvrdo pres ftypko, jenze to samozrejme predtim taky nejelo.. Fakt super komunikace..
No zálohy měli jít do distribuovaného úložiště, máme distribuované backup úložiště a rychlost obnovy je nějakých 40Gb/s a v podstatě to blokuje spíš ta technologie na kterou se to obnovuje než zdroj.
Ale všichni teď dostanou strach a zase stoupne prodej serverů :-)
Komunikace katastrofa nám chyběli dva metry a o tom že sice konkurence ale lidi co znám by ocenili to že uplně nahodou jsme dovezli 7 vetších virtualizačních serverů ale casablanca se vůbec nezachovala v zájmu svých zákazníků ale ve svém včetně naprosto záměrného lhaní.
Nám chybělo pár m tak jsme tam měli zvědy a bylo krásné sledovat jak se dusí na podpoře když mají lhát ale dělat to musí - asi zadání zhora.
hromadne oni nechteji, nejsou hlupaci
Prosíme ty klienty, jichž se situace týká, aby kontaktovali svého obchodníka, a chci je osobně ubezpečit, že jsme připraveni řešit jejich dočasnou ztrátu dat a způsobené provozní problémy vždy individuálně s co nejlepším přístupem
ten kdo ma skodu za par set tisic tak si tezko najme jeste dobreho pravnika na jednani o skode a s tema velkyma uz se nejak dohodnou :-)
hromadna je jim jedno, jedine spatne na hromadne je ze poskozeni slozi sily a tudiz daji dohromady presvedcivou argumentaci a podklady.
Vyse skody je stejne smluvni, budou pekne solit ale asi to nebude tak tragicke protoze pojistka pokryje tu skutecnou skodu a na jejich libovuli je zda vam rozdil daji nebo vas nechaji dohanet.
Sam jsem prekvapen kdo je za tuhle legraci zodpovednej. Nicmene ta pole to me fakt prekvapuje ze to neumi jednotlive provisioning pointy tj obnovit to nekam jinam. HP od toho asi da taky ruce pryc prece jenom to asi vsechna technologie umi (hp i vmware) a zbytek je pouze o rozhodnuti ze to bude takto.
ale jděte.. Jaké "trh si žadal"?? Na marketérech a specialistech záleží, aby nazývali věci pravými jmény. Vy jste se tímto přidal k taktice Casy, která teprve ex-post vysvětluje, co u nich znamená geografická záloha.
V CR nevím o komerčně poskytované cloudové službě. Všechno to je virtualizace připadně cluster.
mysql se nas netyka
celkemse tu resi zbytecna vec - resenim at uz s mysql nebo bez byla ta replikace, kde to melo nabehnout po padu primaru - pak by byla veskera debat na tema jak obnovit tabulky mysql celkem zbytecna - problem to muze byt tam kde mysql pouzivaji, pocitali s tou replikaci a ted misto toho maji nefunkcni zalohu
a vy vite co maji postizeni zakaznici ve smlouve?
Omg proc by si HP mela rvat vlasy ? HP dodalo technologii a ma pravdepodobne nejakou supportni smlouvu. Maslo na hlave ma hlavne Casablanca ktera neco tvrdila v reklamnich papirech a asi nemela prachy na to udelat to HA i geograficky. Nepochybuji ze to meli HA lokalne ale co cert nechtel voda je svinstvo. Kdyby meli druhy diskovy pole nekde vedle ( treba pres ulici ) tak problem v podstate nebyl. Jenze vsechno je o penezich.
To není pravda - MySQL runtime replikaci bez problémů umí a zvládá. Samozřejmě za cenu vyšších výkonových nároků.
A v tom je možná ten problém - pokud (a myslím tím pokud) Casablanca používá smlouvy jako toaletní papír a obchoduje s deštěm...
V každém případě - jiné zálohy nemají smysl - k čemu je snapshot se stovkou nedokončených transakcí?
Čekat pět dní na obnovu dat to je neuvěřitelný, nedokážu pochopit, že takhle vychvalovaný a robustní řešení může mít tak zásadní nedostatek. Když bych měl vlastní server, kterej budu zálohovat, tak obnovu dat provedu v řádu hodin. Můžou vychvalovat stoprocentní dostupnost, neomezený výpočetní výkon a nevim co všecko ještě, ale tenhle nedostatek to úplně přebíjí.
A kam ho budete zálohovat, aby i ta záloha přežila takovou vodu? (Primární záloha na diskovém poli ji nepřežila.) A kolik vás takové zálohování bude stát? :-)
Obnovování z pásek není moc rychlé. Na druhou stranu, taky mohli rovnou říct, že to bude několik dní trvat, aby zákazníci mohli nahodit alespoň nouzový web a mail server.
Ono je si treba uvedomit ze kdyz dela nekdo zalohu tak ji musi delat tak aby byla po srsti technologii ktera je zalohovana. Proto taky kdyz si kupujete zalohovaci reseni tak nemaly prachy date za "pluginy" pro dane technologie.
Proste musite rict MySQL/Oracle/Lotus Notes ze se je zrovna chystate zalohovat aby ta data byla v konzistentnim stavu. Nestaci tudiz vzit "aktualni stav filesystemu" ( snapshot ).
A četl jste vůbec tu smlouvu?
<blockquote>Garantovaná dostupnost Hardwarových prostředků činí 100 % měsíčně, přičemž dostupností Hardwarových prostředků se pro účely těchto Podmínek rozumí, že tyto nejsou ve stavu poruchy (tzn. byl virtualizační platformou přidělen výpočetní výkon Virtuálního serveru dle Technické specifikace). Poruchou se pro účely tohoto článku Podmínek rozumí stav, kdy Služba BBO není dostupná v důsledku úplného výpadku Služby BBO zaviněného Poskytovatelem.</blockquote>
Dělalo to snapshoty, ne kopie. Kopie je stav jednotlivých souborů ve chvíli, kdy se ten který soubor začal kopírovat, zatímco snapshot je stav celého souborového systému najednou ve chvíli, kdy byl vytvořen. Ten zásadní rozdíl, kteří mnozí rádobyadministrátoři nikdy nepochopili, je, že při kopírování se mezitím ostatní soubory mění, takže u DB pak máte tabulku z jedné doby a transakční log z jiné, což DB nezvládne. Snapshot tímhle netrpí, pro DB to vypadá stejně jako výpadek proudu (který každá normální databáze umí zvládnout) a proto se taky používá jako běžná zálohovací strategie.
a on je tu nekdo, kdo ma pocit ze BBO je dostupna, nebo se nejedna o uplny vypadek BBO zavineny poskytovatelem? to ze jim tam nateklo je jejich problem - kam si to umisti a jak to zajisti je jen jejich problem - kdyz to daji do sklepa, kam muze natect voda tak je to jejich vina - jak si to zabezpeci, zajisti atd. preci je na nich
podle vaseho vykladu by k tomu nikdy nemohlo dojit co by byla jejich vina, protoze vzdy je pricinou neco z vnejsku - kdyz nebudou mit prepetovou ochranu a vyhori jim to, tak podle vas to neni jejich vina, protoze preci prepeti nezpusobili oni ...
I při sebelepší analýze rizik a přijatých odpovídajících protiopatřeních vždy hrozí, že nastane něco nepředvídaného. Stejně tak můžete mít serverovnu třeba pod střechou v posledním patře, může přijít vichřice, střechu strhnout a máte vodu v serverovně taky, teda pokud by ta vichřice rovnou nevzala servery na výlet :-) A stejně jako teď někteří nadávají na serverovnu ve sklepě by pak ti samí nadávali na serverovnu pod střechou. Ostatně, zatopené metro v roce 2002 nikdo také nečekal a vydržet to velkou vodu mělo... :-)
Jenze AFAIK Casablanca tem lidem neprodavala "aplikacni cloud" s MySQL.
Je to stejne nedorozumeni, jake meli i vetsi hraci pri vypadcich EC2 od Amazonu. Pri designu sluzeb je treba poradne nastudovat, co mi vlastne poskytovatel nabizi. To, ze je dana vec prikryta nalepkou "cloud" jeste nemusi nic znamenat.
Doufejme, ze se (vsichni) uzivatele pouci a budou chtit po svych poskytovatelich neco jineho nez "cloud, ale levne prosim".
ale to je porad o tom kdo je vinik? proste jim do masin natekla voda - kdo za to muze? - jsou to jejich prostory, oni je monitoruji, hlidaji, spravuji, tak to je proste jejich vec, jak to maji osetrene - jak jsem psal, podle vaseho vykladu vinu nemaji nikdy, protoze to je vzdy neco z venku - i kdyz dojde k poruse na zarizeni, tak podle vaseho vykladu to neni jejich vina, proste je vadna soucastka, tedy vina vyrobce ...
ale pro nasi debatu je dulezite proc se kde kdo tak pojistuje, - protoze kdekdo pocita s tim, ze k takove situaci muze dojit a to je to o cem se bavime - ze proste s takovou situaci museli pocitat
muj osobni nazor je, ze to s pojistovnou nebudou mit lehke, protoye ta yacne yjistovat co delali proto, aby skody minimalizovali - tim nemyslim jen skody na majetku, ale i nemajetkove skody ...
takze nakonec budou mozna zakaznici celkem neprijemne prekvapeni
ale to uz je jina vec
ted je otazkou jestli to casablanca dokaze vubec obnovit
tady ale jde o to, jestli kdyz mi padne to primarni reseni, jestli mam zalozni - pokud nemam - a to oni tedy jak se vsichni ted dovedeli nemaji - tak nemuzou garantovat vubec nic - a nemusi se jim ani nikdo na nic vymocit, nebo nekam natect voda, proste jim lehne nejaka soucast a - jak je videt i ze soucasne situace - muze trvat nekolik dnu, nez ji uvedou do provozu - oni cele dny neresili ani obnovu dat a porad bojovali jen s uvedenim do provozu toho primaru - podle vaseho vykladu by vinikem nebyli, protoze proste soucast byla vadna ...
oni preci tou garanci rikaji, ze maji technicky vyresene, ze ani havarie toho primaru neznamena nedostupnost sluzby
Ale ono došlo k vyplavení celé technologické místnosti, nikoliv k poruše jedné součásti, postižen byl primár i sekundár. Takže i když asi měli vše zdvojené, nastal překvapivě problém. Garantovat, že i při výpadku poloviny diskového pole nezaznamenám problém samozřejmě je možné. Lidé si často ale pletou svá očekávání se skutečným stavem věcí. Z čeho jste dovodil, že služba bez problémů poběží i při destrukci celé serverovny?
jak jsem psal - ja smlouvy nedelam , takze to musi vyresit jini
pro me je podstatne to,ze cloud od casablanca int se ukazal proste jako nespolehlive reseni pro zajisteni vysoke dostupnosti a to ne proto, ze jim nekam natekla voda, ale proto ze tam chybi zalozni reseni - podle jejich informaci co se postupne od nich objevuji - ktere by se pouzilo v pripade ze dojde k havarii toho cloudu - proste cloud zhavaruje, tim je mimo provoz, nebezi a hotovo a dokud ho nezprovozni tak nepobezi
a podle reakci vsude mozne jejich zakaznici tu sluzbu kupovali s jinou prestavou, s predstavou ze havarie toho reseni neznamena konec pokytovani sluzby, prave naopak
Živelná pohroma se celkem blbě předpovídá, vlastní blbost také a běžně se proti pohromě a vlastní blbosti pojišťujeme. Nezodpovědné by naopak bylo, kdyby taková pojistka neexistovala.
Po bitvě je mimochodem každý generál. V kolika krizových situacích jste se pod tlakem okolností rozhodoval? A jak Vám to šlo? :-)
nezlobte se, ale pokud mate v jedne mistnosti jak primar tak zalozni reseni, tak nemate zadne zalozni reseni - to je jako mit zalohu disku na stejnem disku, ktery zalohujete
ja to nedovozoval - tak to bylo receno kdyz se do cloudu melo prechazet - nekde jinde, v jinem meste mela bezet vpodstate kopie toho cloudu na kterou by se pripadne preplo, to bylo takove to slibovane reseni ze i v pripade teroristickeho utoku blablabla. Ale asi se neco zmenilo a misto skutecneho reseni vysoke dostupnosti je tu proste jen zalohovani. Tim ten cloud samozrejme ztratil vse, cim byl zajimavy
tadz ale k zadne bitve nemelo dojit - to je ten cely problem - tady proste melo byt zalozni reseni a to tu nebylo, zalohovani neni zalozni reseni, zalohovani nema s dostupnosti sluzby nic spolecneho, zalohovani ma jen zabranit ztrate dat, to nema s dostupnosti sluzby nic spolecneho
nejde o predpovidaji pohromy, ale o to, jestli nejaka rizika jsou nebo nejsou, pokud jsou tak musi bzt takova opatreni ktera dusledky rizik eliminuji a o takovych jsem v souvislosti s timto pripadem nic neslysel
Zálohování samozřejmě existuje i bezvýpadkové (UPSky, zdvojené zdroje, RAID, mirrory serverů).
Eliminují? Rizika lze akorát snížit. Chci vás ale vidět, jak eliminujete riziko, že vás na ulici srazí auto. Kdyby rizika šlo eliminovat, proč by se potom vůbec někdo chtěl pojišťovat?
A když jsou ty Vaše představy o existenci záložního řešení takové, ověřil jste si, že užívaná služba požadovaná kritéria také splňuje? Asi ne, vy jste si jen myslel, že když to má samolepku cloud, tak to dle vašich představ tak být musí. Jenže myslet znamená hovno vědět :-) Záložní replika v jiném městě? To určitě bude za těch pár korun :-) Mercedes si z úspor na Trabanta těžko pořídíte :-)
Tak z tohoto pohledu je samozrejme zalohou kazda kopie dat, klidne i do jine slozky - jde o to co ma takova zaloha resit - pad disku - tak pak vam staci kopie na jinem disku - pad zarizeni - pak vam RAID nepomuze - kdyz nemate druhe takove zarizeni , pak mate max. nekde hromadu dat - zaloha dat neresi dostupnost sluzby . Takze proto aby nedoslo k vypadku nepotrebujete zalohu dat, ale duplicitu sluzby, zarizeni. Zaloha dat proste neresi dostupnost. Coz je videt i ze soucasne situace.
Člověče, Vy jste jojo. 100% garantovaná smluvní dostupnost neznamená 100 % vždy a za všech okolností. Je Vám to tady opakováno x-krát. Nějaké Vaše dojmy o geograficky odděleném failover, protože prý "cloud", jsou úplně vedlejší, podstatné je, co je ve smlouvě a tu evidentně ani neznáte. Když si někdo pořádně nepřečte smlouvu, tak ať si pak nestěžuje.
ja opravdu smlouvy nemam a neznam, rikam jen jaka byla situace, kdyz se rozhodovalo jestli ano nebo ne
pro fungovani je to ale stejne jedno - at uz je ve smlouvach cokoli - realita je proste takova ze sluzba je nedostupna a ic se na tom nicim nezmeni
pokud je to tak ja rikate, ze ve smlouvach nic takoveho neni, tak to jen zhorsuje muj pohled na tu spolecnost protoze vim jak to reseni bylo predstavovano
ale ja to tu uvadel, ze smlouvu neznam, protoze u te jsem nebyl, ale vim co vedlo k jejimu uzavreni - takze ano nevim, co je ve smlouve a ano vim jak byla ta sluzba nabizena
a to je vsechno - pokud je rozpor mezi tim jak byla sluzba nabizena a tim co je smluvne garantovano, tak to muj osobni pohled na tu sluzbu tezko muze vylepsit
ja uz si davno nestezuju, proste skutecnost je takova, ze sluzba neni a nikdo ani po nekolika dnech nedokaze zavazne rict, kdy dojde k jejimu obnoveni - to je realita se kterou se neda nic delat a ani ji osobne namam jak resit
Nic ve zlem, ale prakticky vzdycky se pri designu sluzby potykate s nejakymi riziky a musite delat nejake technologicke / provozni / financni kompromisy.
Delaji to firmy, ktere maji miliardove rozpocty a neni to zadna hanba (muzeme se bavit o nedostecne redundanci datovych spoju, nepovedenem slucovani dvou siti, chybejici karte v rozhrani - abych jmenoval zname konkretni pripady slovutnych poskytovatelu s obraty o jeden a vice radu vetsich nez ma Casablanca). Co je ale vzdy dulezite, aby uzivatel mel presny prehled o tom co kupuje a co muze cekat (a od toho jsou smlouvy).
Tj. uzivatel by se nemel spokojit s tim, ze neco bezi "v cloudu", ale mel by mit jak je provoz zabezpecen. Pak by se nemohl divit, ze kdyz delnici prekopnou jeden kabel u trati vedouci do Liberce, tak popada vetsina "spoju prodavanych jako redundantni".
dobrovolne priznavam, ze nemam predstavu jak si overit, ze nekde jinde v republice neco skutecne bezi, kdyz tam nemam zadny pristup,mam pristup jen do jineho konkretniho prostoru, klientum nepristupneho, takze se musim skutecne spolehnout na to co mi nakdo nabizi a rika , kdyz mi to prodava
pokud vite jak takovou vec overit, tak poradte, rad to pri pristi prilezitosti pouziju
Jako sorry, ale pokud někdo spoléhá na to, co je mu nabízeno, pak podepíše smlouvu, která má úplně jiné podmínky, a ještě navíc pak vinu svaluje na někoho jiného, tak je prostě mamlas. Radši se ani neptám, co myslíte tím "bylo nabízeno", abych se nedozvěděl, že někdo někde něco přečetl o nějakých 100 % něčeho smluvního :-)
Pokud nevíte, co se podepsalo, pak doopravdy nemůžete soudit, zda poskytovatel nedostál tomu, k čemu se smlouvou zavázal. Víc po něm chtít ani nemůžete.
Pokud máte zálohy, nic Vám nebrání vzít data a rozběhnout si to byť i provizorně někde jinde. Pokud zálohy nemáte, pak jste s prominutím... pitomec a sám byste měl vrátit peníze, které Vám někdo platí za odvedenou práci :-)
Mno .... ono i screen webu by mohl stacit, protoze je to verejne tvrzeni a prohlaseni k nejakemu parametru - tedy je to stejne, jako kdyby skodovka na webu tvrdila, ze vsechny jeji auta jezdi nejmene 300km/h ... coz muze nekoho ovlivnit ke koupi a pak jde jednoznacne o klamavou reklamu (to minimalne), za jistych okolnosti by to mohlo byt hodnoceno jako podvod.
A samo, 100% garance naprosto cehokoli je naprosto totalni kravina. Pokud se budem bavit o garancich, tak se muzem bavit o 1-6 devitkach (nikdy sem nevidel vic) ... ale pak se taky (v zavislosti na oboru) bavime o cenach v rozpeti trebas 10ti radu.
Já myslím že 100% je 100% a na tom nic žádný právník nezmění. Já nevím co dává do smlouvy Casablanca ...třeba tam má 99.7% nebo něco jiného...pak je ovšem na jejich webu klamavá reklama. Pokud ovšem i ve smlouvě bude 100% pak je z toho nikdo nevyseká.....dokonce podle nového OZ si myslím že soud vzhledem k uvedení 100% v marketingových údajích příslušnou pasáž s 99.7% ve smlouvě může prohlásit za neplatnou....jde totiž o to že Casablanca tutově má tzv adhezní smlouvy. Navíc podle těchto výkladů již i vztahy mezi podnikateli mohou právě u adhezních smluv být posuzovány podle občanského ane podle obchodního zákona.
Co takhle o ten přístup na vysněné místo jinde v republice požádat? Já si dovoluji silně pochybovat o tom, že Vám bylo nabízeno toto konkrétní řešení se zdvojenými, geograficky oddělenými serverovnami, spíš to byla od začátku Vaše neověřená domněnka. Ta smlouva není žádný tajný dokument a lze si velice jednoduše ověřit, zda domněnky odpovídají reálné skutečnosti.
uz jsem to tu psal, ze nevim co je ve smlouve, protoze u te jsem uz nebyl, rikam jen co vedlo k rozhodnuti pro tu sluzbu - ta sluzba byla predstavena tak, ze ma zabezpeceni proti vypadku vyresene tim, ze je nekde jinde v podstate jeji kopie na kterou se v pripade vypadku prepne. Proto to bylo pro nas dobre reseni. To by skutecne zajistilo vysokou dostupnost. Realne se, jak je videt, dela jen datova zaloha.
100% slibuje kdekdo v oboru, u nás i za hranicemi.
Podstatný je algoritmus výpočtu, tedy faktory, které vstupují do hodnocení. A živelná pohroma či vyšší moc velmi často bývá vyloučena - a výpadek způsobený takovou událostí není z pohledu garance brán jako nedodržení závazku dodavatele.
Veřejně dostupné smluvní podmínky hovoří v tomto duchu, takže u soudu jen těžko uspějete s tím, že někdo klamal veřejnost. Informace k dispozici byla. Hold lidé jsou líní a nečtou... ale to je jejich blbost :-)
Hlavní problém je v tom, že jejich technické řešení může podle jejich údajů garantovat tak maximálně 98.9% (obnova dat trvá 4 dny).
Vzhledem k tomu ,že existují technická řešení garantující lepší dostupnost (třeba online replikace do tří geografických clusterů) kde se dá hovořit o 99,999% dostupnosti, nebo třeba to moje kdy při vyřazení jednoho místa dojde k cca dvouhodinovému výpadku (kvůli DNS cashe) což je potom 99.97% dostzupnosti, myslím že to u soudu musej jednoznačně prohrát i kdyby se zaklínali vůbuchem bomby.
Co není čisté? Je tu popsaná osobní zkušenost, doporučeno obecně na co dát pozor, možnost osobní konzultace. Taxt akorát ukazuje, že stav jaký je, už byl hodně dávno předtím a nikdo nic s tím dosud neudělal.
On nepíše, že oni fuj a a pojďte k nám. K jakému závěru kdo dospěje, je čistě na inteligenci každého soudruha.
No ja teda nevim jak to chodi ve vasi casti planety, ale v te me, pokud nekdo tvrdi, ze neco zalohuje, tak se samosebou rozumi, ze konzistentne. => pokud ma zakaznik na necem nejakou databazi, tak by tam zaroven mel byt nainstalovan prislusny klient, ktery zajisti prave konzistenci zalohy (= zahohovac mu rekne "krles", SQLko pozastavi zapisy, udela nejakej ten flush a laduje data jen do logu ... udela se snap, a nasledne zalohovac rekne "hotovo" ...).
Samo, ne vse se konzistentne zalohovat da, ale to by mel zakaznik vedet a provozovatel by jej na to mel prosychr vyslovne upozornit. Nekdy totiz muze byt problem i nekonzistentni zaloha FS.
Tohle libovolny provozovatel resit muze, jen chtit. Samozrejme ze zalohovani KAZDE databaze probiha VZDY na aplikacni urovni. Pokud se databaze nedozvi, ze se ma zalohovat, tak jaksi nemuze byt zaloha konzistentni NIKDY, a to plati pro nasprosto vsechny databaze, nejen mysql.
Od poskytovatele sluzeb bych pak ocekaval, ze da k dizpozici svym zakaznikum prislusne nastroje, pripadne jim to za nejaky $$$ nakonfiguruje.
To ze mysql neni zrovna uzasny nastroj je sice fakt, ale konzistentne se zalohovat da - i bez replik a zastavovani.
Zase předpoklady a nějaká očekávání. Když kupuji jakoukoliv službu, tak si přece ověřím, co si tedy platím, jaké to má parametry a na co mám nárok a nestavím to na nějakých pocitech a doměnkách. Pokud budu chtít robusní službu, kterou nepoloží ani výpadek v jedné lokalitě, budu ji takto poptávat. A ne se pak divit, že něco funguje jinak. To je veřejný projev vlastní blbosti :-)
:D
Oni to tam fakt maji ...
"Garantovaná dostupnost Hardwarových prostředků činí 100 % měsíčně,"
"V případě vzniku škody na straně Uživatele v souvislosti s odpovědností Poskytovatele za vady Služeb BBO si smluvní strany dohodly s ohledem na podmínky Smlouvy omezení náhrady této případné škody vzniklé Uživateli tak, že celková náhrada škody je omezena výší 10.000,- Kč (slovy: deset tisíc korun českých) včetně ušlého zisku."
Pokud je mi znamo, zodpovednosti za zpusobene skody se nelze zrict, a to ani mezi pravnickymi osobami. Tudiz toto ujednani ted asi projde nejakym tim soudnim rozhodnutim ... ;D.
To je pořád dokola. Já se prakticky denně, a nejen v praxi, ale hlavně v diskuzích setkávám s tím, že řeknu A a někdo si z toho bůhvíjakým způsobem odvodí B, které jsem nikde netvrdil. Nevím, jak Vám bylo co představeno, jestli jste si něco přečetli na webu, nebo byl u Vás nějaký obchodník. Taky nevím, co to znamená "někde jinde", klidně to může znamenat o pár metrů vedle. Ale pořád platí, že jste tu smlouvu neměli uzavírat, pokud nesouhlasila s Vašimi představami.
Pokud provozovatel virtualu tvrdi, ze zalohuje, tak je odpovednost na nem. On ma vedet, jak co zalohovat, on ma zakaznika informovat a vybavit ho prislusnym klientem/nakonfigurovat mu to. A osobne bych si klidne od zakose nechal podepsat, ze vi jak probiha zalohovani, a ze pokud nema prislusnyho klienta spravne nastavenyho, tak ze backup bude nekonzistentni.
Mimochodem, vmware umi snapnout i RAMku ... takze se srv muze klidne vratit vcetne toho.
Ovsem toto vse jsou jen nasledky ... daleko vetsiho pruseru - neschopnosti zajistit provoz zaloznim HW. Mam tu 3x HW na vmware ... kdyz se ted zvednu, a libovolnej z nich vyrvu ze site ... tak si nikdo niceho nevsimne, protoze vse co na nem bezi se obratem presune na zbyvajici dva.
Toto se rozhodne jako bezna zalohovaci strategie nepouziva ... naprosto bezny pozadavek na libovolne zalohovani = konzistentni zalohovani.
Mimochodem, sem zvedav, co bude delat uzivatel takovyhle "sluzby" trebas s docem, ktery se zrovna v tu chvili ukladal ... a snap obsahuje 1/2 souboru ...
Jde o spojene nadoby. HP se jiste chlubili, ze jejich technologii pouzivaj, a vytahujou to jako referenci kdekoli jdou neco nabizet => v tento okamzik mozna prisli o par desitek dodavek, proste proto, ze prave na jejich technologii bezi to, co se podelalo.
A ten kdo o nakupech rozhoduje prevazne nema ani paru o tom jak co funguje, ale rozhodne si precte, kde se co komu podelalo.
Takovy pole zacinaj na statisicich - dalsi samo zalezi na rozsahu. Pole ktery to umi se da v zakladu koupit za 200k. Kompletne syncovany reseni dvou poli v kapacite +- 5TB je za cca 1M5 (bez dalsi bizu kolem).
Nemam predstavu jakou kapacitu potrebujou oni, ale financne to myslim 100M atakovat nebude (dve syncovany pole).
Součástí specifikace služby je jistě i popis zálohování. To, že si ho lidi pořádně nepřečtou, stačí jim zahlídnout slůvko záloha a dál to už moc neřeší je jejich blbost :-) Pokud někde napíší, že záloha je snapshot virtuálního disku, je pro odborníka zřejmé, co od toho můžu očekávat.
ja skutecne nevim co je ve smlouvach u toho jsem nebyl
ty funkce systemu popisovali ti co je nabizeli - jestli jsou obchodnici to nevim
neco takoveho tam ale planovaneho asi bylo, protoze casablanca vcera sama uvadi
Geografická záloha primárního pole slouží zejména k replikaci dat zákaznických serverů a nikoliv pro produkční provoz. U některých kritických systémů je jí sice relativně snadno do produkce převést, ale jen s omezeným výkonem.
tedy na to aby to tak bezelo to maji pripravene, ale nedelaji to
proc to nedelaji, jestli to tak v te dobe, kdy se k nam ta nabidka dostala jen planovali nebo skutecne provozovali taky nevim, ale toto byl duvod, proc jsme k nim do cloudu sli
az do tohoto pripadu vsecho fungovalo jak melo, takze je pro nas skoda, co se ted semlelo a musime najit nejake vlastni reseni, ktere teda bude fungovat tak, aby se v pripade vypadku dalo proste jen na prepojit na nej a tak byla dostupnost zachovana, protoze toto reseni dostupnost nezarucuje
a to je asi tak vsechno - pro nas je to pouceni, ze dostupnost proste nezajisti ani tak velka spolecnost a je potreba dostupnost resit jinak
A kdyz do serverovny chcije voda, a provozovatel to necha pod proudem, tak za to muze kdo?
Nevim jak predrecnik, ale ja osobne o nekolika naprosto vodo i vzduchotesnych serverovnach vim. Dokonce vim o takove, ktera je preventivne napumpovana plynem, aby tam nemohlo horet za zadnych okolnosti. A i pres takovato zabezpeceni ... existuje minimalne nekolik dalsich lokalit, ktere mohou naprosto kdykoli prevzit kompletne veskery provoz. A dokonce se to pravidelne dela v ramci proverovani ...
Napsat takovou pitomost jako ze raid je zaloha ... blah.
Raid resi vypadej 1-N disku. Dalsi v rade je zdvojeny radic, ktery resi vypadek jedne vetve ... a nasleduje sekundarni pole, ktere resi kompletni vypadek pole - trebas zniceneho pozarem/vodou/... Zcela standardni technologicke reseni, ktere umi i firmy ktere maji 2 racky zeleza ... I kdybych to sekundarni pole mel na primar prehazovat rucne ... tak to udelam v radu minut.
Provozovatel otevřeně informuje o tom, jak zálohuje:
"Cloud BIG BLUE ONE využívá technologii 3PAR remote-copy k vytváření geograficky oddělené zálohy dat. Data jsou tedy replikována do fyzicky vzdálené lokality, a tak je zcela eliminována možnost jejich ztráty. Tyto lokality jsou propojeny rychlostí 2 x 8Gbps pro aplikaci Disaster Recovery.
Na diskovém poli se vytvoří bitová kopie a replikují se pouze změny, takže samotný proces replikace nijak neomezuje zákaznické aplikace. Tzv. snapshot (kopie) se tvoří každých 60 minut."
To, že někteří taky-adminové nedokáží vyhodnotit, co to znamená není chyba provozovatele.
Že máte tři wmware servery je fajn - ale pokud vám vypnou z nějakého důvodu všechny, tak si toho taky asi někdo všimne :-) A i když ty tři servery schoří, obnova malého řešení bude z principu poněkud rychlejší...
Pokud se snap dělá v momentě, kdy je zapsaná jen polovina souboru na disk, tak s tím sebelepší strategie nic nenadělá. Snapshot je pouze obraz informací v nějaký konkrétní čas. Ovlivnit chování aplikace na virtuálním serveru tak, aby zapsala veškerá data z pozice provozovatele chcete prosím jak?
Nepochybne, proto taky nebudu nikdy zadnymu zakaznikovi tvrdit, ze neco 100% garantuju, a pokusim se jej upozornit, jaka rizika +- hrozi, a jak dlouho/kolik penez bude stat jejich pripadne reseni.
Z vlastni zkusenosti muzu rict, ze zakaznici se jakz takz dokazi srovnat s vypadkem 1 den (predevsim kvuli $$$, ktere by je stalo lepsi zajisteni provozu). Ale pokud bych nekomu nabizel, ze jejich HW umistim do "profi" serverovny ... kde jim do toho nachcije voda ... a budou stat tyden ... tak me budou mit za naprostyho magora.
Pokud ta synchronizace bude do geograficky oddělené lokality, tak to něco navíc stát také bude. A k tomu ta bižu kolem, servery počínaje... :-) Elektrika taky zadarmo není, housing také ne - pokud nejste ve vlastním. Pomalu se dostaneme zas k tomu, že za těch pár stovek asi někde logicky musí dojít ke kompromisu...
Nevim jak vy, ale lidi v mem okoli si alespon "kriticka" data zalohuji na externi disky - a to se bavime o desktopech. Pokud se budeme bavit o serverch ... sekundarni pole v jine mistnosti, ze ktereho navic mohu primo spustit provoz. Snapy (!!!KONZISTENTNI!!!) to dela (dle konfigurace) klidne kazdou minutu, ale je to zbytecny, nastaveno je 15. Jinak je to CDP, takze nekonzistetni data lze vysat z libovolnyho casovyho okamziku. A pokud se bavime o cene, tak se pohybujem lehce v M.
Tohle HP nebo Casablanca neumi ani za (minimalne) desitky mega???
Podotykam, ze provoz ze zalohy mam i na vlastni kuzi overeny, spusteni trvalo cca 10 minut, a to proto, ze sem si radsi vsechno kontroloval 5x, protoze sem to delal poprve. Zadny problem, o vikendu sem jednoduse povypinal servery, prekopiroval aktualni data a vratil provoz na puvodni pole (zalozni je ponekud pomalejsi). Ale nebyl by problem mit dve zcela totozna pole. Dokonce neni zadny problem pouzivat obe pole zaroven ... rozlozit na ne zatez, a v pripade vypadku jen prevest docasne kompletni provoz na jedno.
Upřímně - další náklady navíc a tohle řešení s geografickým zrcadlem na méně výkoném HW pro moje účely dostačuje. Zákazníci vědí co je čeká když vybouchne celej barák a dokáží se s takovým výsledkem vyrovnat.
BTW DNS servery mám ještě úplně jinde - u registrátora.
Zákazníků nemám tolik a IP adres stejně jenom 32 takže to jde uřídit.
Navíc vždycky jde zákazníkům dodat obsah hosts souboru který zafunguje okamžitě.
BTW asi bych měl dodat to, že se nejedná o žádné veřejné weby, ale o hostované IS por konkrétní okruh uživatelů.
Třeba to dělají jen pro ty, kteří jsou ochotni si takovou službu skutečně zaplatit :-) To že se při obchodním jednání zmíní maximální možnosti služby ještě neznamená, že zákazník je ochocen platit nějaký obnos a v rámci debaty o možnostech snížení ceny dojde i na omezení rozsahu funkčních požadavků ze strany zákazníka. Holt, když chce někdo moc ušetřit, někde se to projeví...
podle toho, ze casablanca mela vcera potrebu vysvetlovat jak to zalohovani nyni funguje, tak zrejme vetsi pocet jejich zakazniku mel informace, ze to ma fungovat jinak a sami si to asi nevymysleli - a ze jich nejspis neni malo je zrejme z toho, ze casablanca tom zvlast informovala, kdyz jinak byla na cokoli ohledne toho problemu skoupa
takze to oznacovani za hlupaky beru jako takovy diskuzni ritual
vzhledem k tomu, ze casablance stalo za to o tom zvlast vcera informovat, jak ze to vlastne funguje, tak asi pomerne dost jejich zakazniku melo informace o tom, ze to funguje jinak, tezko si casablanca rekla - nemame k vypadku co rict, tak co jim napsat neco o zalohovani primaru ...
jak co bylo nebo ma byt uz musi vyresit jini
Jestli jste si nevšimnul, tak problémem není absence dat jako takových, ale rychlost, jakou obnova probíhá. A asi jste si také nevšimnul, že se zde nebavíme o dvou serverech. Provozovat větší cluster s geografickou redundancí taková sranda také už není, jak se rádoby-odborníkům se dvěma servery na stole zdá :-)
Ten nápis na střeše jim nesvítí už cca půl roku, možná i více, takže to tak bude pravděpodobně myšleno, ne porucha. Byl jsem si v prosinci pro novou kartičku do housingu v 2. patře na podpoře a mají nový svítící nápis na stěně.. řešíte docela ho**a, myslím, že potopa je přece jen větší problém.
Zákazník podepsal a platí garanci 100% dostupnosti služby za jakékoliv situace - včetně živelné pohromy? To asi ne, co? Ano, jeho aplikace neběží, ale ve smlouvě je jasně upozorněn, že existují nějaké situace, kdy něco takového nastat může. Jestli si to pořádně při podpisu nepřečetl, tak je pitomec :-)
Mam za to, ze Casa zakaznikum tohle nenabizela :-)
Aspon kdyz me pred dvema lety nabizeli nejake takove sluzby, tak o vode a nekolikadenni odstavce nebylo ani slovo.
Mimochodem, staci nejaky "silnejsi vetricek" a bourka a v hodne profi serverovnach muze nastat problem s vodou. Jde jen o to, ze si musite byt vedom rizik a nepodlehat kouzlu slova cloud.
Jistě, ve svém komentáři jsem zákazníkem myslel toho, kdo si železo zakoupil a něco na něm provozuje (tedy Casablanca). Chválit HP za to, že dodrželo, co si (pravděpodobně) Casablanca koupila, mi připadá, že bych musel přistoupit na pravidla Kcourkova, podle kterých obchodník může napovídat jménem firmy, kterou zastupuje, cokoliv a nikdo se nediví, že realita je pak jiná.
Je pekne a mile, ze me tak pekne rozebirate. Evidentne budete nejaky investigativec. Zkuste se pro zacatek podepsat, dodate tak jiste duveryhodnosti svym tvrzenim.
Stale jeste existuji zeme, kde k uzavreni staci podani ruky a je to i CR a ja to u nekterych obchodnich partneru taky uplatnuji. Protoze papir neni smluvni vztah. Nicmene pred tim, nez si s nekym podam ruku, tak chci vedet, jake sluzby mi poskytuje. Takze si nepodavam s nikym ruku na zaklade marketingoveho papiru. Ja vim, ze je to nepopularni, nudny a staromodni ...
Je mi celkem jedno, zda klienti od Casablancy odejdou nebo ne. Nemam na uspechu ci neuspechu jejich obchodu zadny zajem ani prospech. Nicmene co je dulezite, je fakt, aby si z toho vzali ponauceni klienti. Aby se jim nestalo, ze podobnou zkusenost udelaji za dva mesice s nekym jinym.Dokonce bych rekl, ze to je zdaleka nejdulezitejsi vec z cele kauzy.
Chybami se clovek uci a je hloupost chybu opakovat. Ostatne sam jsem jich take par napachal.
Podobná rizika hrozí u většiny mráčků v ČR :-) A z marketingových papírů to nevyčtete.
A to že spousta lidí naivě přežívá z neověřených dojmů, kterým říkají informace a nikoliv z daných skutečných faktů také není nic neobvyklého. Holt takový přístup vede k tomu, že dotčení jsou pak nemile překvapeni.
Jsem naprosto zděšen jak mám odlišné vnímání psaného textu. Pro mne je 100% smluvní dostupnost parametr, že smlouva SLA bude končit u 100%. Což má málokdo, většina končí někde u 99,95%, alespoň v oboru kde se pohybuji já.
Tedy někdo kdo garantuje 100% smluvní dostupnost musí nabídnout parametr vzorce výpočtu sankce v případě i vteřinového výpadku.
Proboha, proto tam byva ta tabulka, aby se podle realne delky vypadku vypocitala sankce, co to je za jiny mentalni matrix? To by mě zajímalo kde je chyba, protože tolik hloupých lidí tady snad ani být nemůže, doufam ze jsem nejde neudelal chybu ja.
Přece si nikdo nemůže myslet, že všechno lze zabezpečit na 100%, to by přece pak vybuchl vesmír, ani 100 geografických redunadací nic takového zabezpečit nemůže, ani atomová elektrárna, nic. To je proti fyzice, zdravemu rozumu, uplne vsemu co jsem se kdy ucil. Ten marketing je v poradku, tedy predpokladam ze maji opravdu smluvni 100% dostupnost (ne technickou), SLA jsem nevidel.
Oni jsou ale hlupáci především proto, že si pořádně nepročetli smlouvu a specifikaci služby - i když spousta detailů je zřejmá i z webových stránek. Že se nepídili po detailech o tom, jakým způsobem se dosahuje oněch proklamovaných 100 procent, jestli jejich služba je schopna běhu skutečne z více lokalit. Nic. Oni si prostě jen mysleli.
Odejdou a co se stane. Vlezou na jiné podobné řešení u jiného operátora. Dopustí se stejných chyb, opět budou jen něco automaticky očekávat. Aniž by se ujistili, že jejich očekávání skutečně někdo nabízí naplnit. A budou se tvářit, jak jinde jsou spokojeni. Dokud se tam jinde nestane jiná nehoda :-)
Tak nějak nechápu to, že si nechali vyplavit celou serverovnu. Vždyť větší průsak vody lze zjistit velice rychle. Monitoringem vlhkosti v jednotkách minut (cca 3 minuty), správně položenými detekčními kabely v jednotkách sekund. Pokud by měli správně realizovaný monitoring tak by měli dost času na reakci.
Pro provozovatele jakýchkoliv kritických systémů by měla být norma IEC 61508 přímo biblí.
Ve všeobecných podmínkách je u položky konektivita definována dostupnost 99,95%, oněch 100% se týká jen dostupnosti hardwaru - a i tam jsou vyjmenované okolnosti, kdy toto neplatí. Garance odolnosti při výbuchu vesmíru nikde nepadla - to jen někteří zákazníci si jí ve své bujné fantazii domysleli :-)
Půjdete vychovávat trh i za hranice ČR? Oněch 100% garantují i některé zahraniční služby.
Spíše než kultivovat dodavatele je treba kultivovat zákazníky - aby si laskavě uvědomili, že je dobré se seznámit s tím, co se za těmi 100% skrývá. A vynechali z hodnocení své dojmy nemající oporu ve smlouvách.
IEC 61508 rizika kategorizuje mimo jiné podle pravděpodobnosti jejich vzniku a ty se posuzují podle konktétního místa. Vodopád pravděpodobně nikdo v těch místech nepředpokládal. Když praskne voda - tak je to dost často o sekundách, voda v serveru je problém ihned. Voda je potvora a silný živel a cestu si najít umí často i místy, které se zdají až nemyslitelné :-)
Zákazníků nemáte tolik. To bude ono :-) Ono s menšími objemy dat a menšími požadavky na výkon a s menším počtem zákazníků se tahle problematika řeší vždy o dost jednodušeji.
Řešení s hosts je vtipné, zvlášt když se na podobné úpravy u někoho zapomene a po pár měsících se změní IP :-)
To že jej ale nikdo nepředpokládal je ale dost hloupé. Když je to jeden ze statisticky nejčastejších důvodů selhání IT infrastruktury. Nějakou dobu se totiž živým vývojem přístrojů které se mimo jiné používají pro monitoring prostředí serveroven. Někde u konkurence (myslím že to byl Avtech) jsem viděl hezkou statistiku.
Uz nejaky ten rok provozujeme a prodavame IaaS cloudove reseni na vCloudu - kompleni virtualizace site pomoci vxlanu, dve vybavene lokality, moznost replikace mezi nimi, stejne ci nezavisle internetove adresni rozsahy v lokalitach + totez pro ASka, nabidka konsistetniho zalohovani na aplikacni urovni z vnitrku VM nebo pomoci snapshotu VM, atd... To, co by si clovek vzdycky pral, ale sam si to vetsinou jen tezko muze dovolit postavit.
Vsem nabizime tyto moznosti, ale nenutime zakazniky to pouzivat - stoji to nejakou korunu, ale radove mene, nez si to investovat domu.
A myslite, ze vetsina uzivatelu tohle resi a pouziva? NE, NE, NE a NE
Lokalne je sice vse redundatni, ale jak redundance muze nahradit pravidelnou zalohu a verzovani? Sam za sebe bych byl stasny, kdyby kazdy uvazoval o BCP/DR, zalohoval, testoval zalohy a provadel testovaci obnovu. Jak je to v dnesnim virtualni svete jednoduche. A jak by se providerum podobnych sluzeb lepe spalo a provadelo nutne zasahy do infrastruktury a konfigurace kdyby vedeli, ze vsechna data jsou realne dostupna jeste vedle...
Ale neni to tak, Clovek se uci chybami, ale bohuzel negativni zkustenost je nepredatelna a rekl bych, ze se i rychleji a rado zapomina - uz jen proto, ze se treba usetri nejaka ta petka mesicne za neco, co stejne nebude nikdy potreba.
Je to smutny a pokud jedinym rozhodujicim kriteriem pro vyber bude cena, nebude to nikdy lepsi.
Vase prispevky maji hlavu a patu a da se s tim souhlasit. ovsem pro me jako klienta je dulezite to, ze:
- v materialech maji, ze sleduji i pritomnost vody v serverovne - asi ne dobre
- kdyz doslo k vypadku z daneho duvodu, tak vsem muselo byt jasne, ze to za hodinu nahoru nedaji - klientum se sdelovalo, ze to je zavada na switchy a podobne bludy. pokud by bylo hned jasne receno, co se stalo, mel by kazdy na vyber a k situaci mohl resit ihned
- ze jsem si od uterniho rana jiz 3x vyslechl "prave jsme daly dohromady nove pole a startujeme obnovu ze zalohy"
.. a jeste par drobnosti by se dalo.
takze si tu muzeme hrat se slovy a analyzovat smlouvu jak chceme. ono je to ted uplne jedno. proste lhali a lzou do ted - viz. "prave jsme odstartovali obnovu....."
jen pro info - zalohy jsem mel jinde (clovek pocita s tim, ze se zvojtit muze cokoliv) a uz bezim z jine lokality.
osobne uz me zajima jen to, zda-li se za par dni neprovali, ze jsou ta data (nebo jejich cast) v hajzlu. vubec bych se nedivil.
stat se muze opravdu cokoliv, ale postavit se k tomu tak, jak se postavila casa je ostuda. jejich pristup jen zvysil skody vsem.
nahle hodne? se tam protrhla prehrada? normalne tam chcala voda, casa to nechala bezet a postupne shoret nejen sobe, ale i klientum.
jeste vecer me lakovali, ze to je jen drobna zavada. tak jsem tomu cloveku na lince rovnou rekl, at si to necha a rovnou me rekne, co s tim chteji delat - abych se podle toho zaridil. jeste druhy den rano zatloukali. tak jsem zavolal obchodnika a ten jediny me poctive sdelil jak na tom jsou.
Žádné čidlo není dokonalé, z toho nejde dělat závěry. Co kde prasklo nevíme, ale voda umí být poměrně rychlá :-)
Informace v kritických situacích bývají často zmatečné, lidé odbavující hovory klientů i samotní technici jsou v čase výpadku vystaveni nemalému stresu - ostatně životnost lidí na podporách nijak velká také nebývá. Informace obvykle zpočátku hodně drhnou - ale zbytečně si to děláme sami, tím tlakem. Protože hned chceme znát dopodrobna detaily. A z operátora je taháme už v momentě, kdy ani není znám rozsah poškození.
Těch možných záloh dat mají očividně více. Ta, co by pomohla rychlejší obnově asi nezafungovala dle očekávání (i to se stává se sebelepší technikou), zpětně se snadno soudí postup - kdyby začli rovnou u té pomalejší, lidi by stejne brblali, že to trvá dlouho a rýpali by, proč se nezkusila ta rychlejší varianta. Odstartovat proces obnovy ještě neznamená, že tento je úspěšně dokončen - problém se vyskytnout prostě může.
Doba je neuvěřitelně uspěchaná. A nesmyslně uspěchaná. Podle toho to ale kolem nás vypadá. Přitom by stačilo zvolnit.
Kdo dnes vzpomene na výpadek u Seznamu, kde také obnova trvala několik dní? :-)
Trochu bych upřesnil ten vztah cloudu a zálohy. Záloha je potřeba v každém případě, bez ohledu na spolehlivost infrastruktury produkčního prostředí. Třeba proto, že ani sebelepší infrastruktura vás nezachrání před chybou aplikace. Pro velké objemy dat ale obnova ze zálohy trvá hodně dlouho (jak můžeme momentálně u Casablancy sledovat). Cloudy mají zmenšit pravděpodobnost toho, že bude nutné data obnovit ze zálohy.
Pořadí zavádění by tedy rozhodně nemělo být nejdřív cloud, a pokud chci ještě větší spolehlivost, přidám zálohování. Právě naopak -- nejprve zálohování, a teprve když zjistím, že obnova ze zálohy je příliš drahá, budu se její pravděpodobnost snažit zmenšit např. cloudem.
Ono stačí, kdyz praskne nějaká stoupačka a nějak neštastně se to rozleje. Voda se může někde nahromadit a když je jí v prostoru hodně, někde se něco provalí a je vymalováno :-)
Dostat z jakéhokoliv helpdesku informaci o skutečném dopadu problému bývá složité. Ono doopravdy nějakou dobu trvá, než se vyhodnotí skutečné dopady incidentu.
Kverulant píše: "Žádné čidlo není dokonalé, z toho nejde dělat závěry. Co kde prasklo nevíme, ale voda umí být poměrně rychlá :-)"
Mohu Vám nabídnout exkurzi u nás ve firmě. Rád Vás seznámím s tím, že čidla jsou velice dokonalá (nejen od náš ale i konkurence má kvalitní přístroje). Sám je vyvíjím takže opravdu tuto problematiku znám. Zajímavé, že jeden z největších ICT integrátorů v Evropě si to nemyslí a ročně od nás kupuje stovky těchto přístrojů.
omluvte mě, ale co to melete? mě je ta technika prakticky ukradená. co si tam nastrkali, co prezentují a co si troufnou prodávat. 12h po tom, co tam ta voda natekla technik mluvil o tom, že jsou problémy se switchem a podobně. 24h po nehodě - když už hodiny na netu kolovaly fotky a kdy každý druhý mluvil s někým, kdo tam fyzicky byl - to technik stále nechce přiznat. to za 24h netušili rozsah poškození? a ono i kdyby netušili, služba nejela a tak podstatnou věc, jako že tam plavou servery klient musí vědět, aby měl možnost se rozhodnout co dál.
tím lidi připravili o čas i klienty.
to tu obhajujete neobhajitelné dobrovolně?
Kvalita odvedené práce je jedna věc. Ale mnohem více rozhoduje objem finančních prostředků, který je na dané řešení k dispozici a to se odvíjí od oběmu peněž, které jsou ochotni zákazníci za služby platit. Na to se rádo zapomíná :-) Lidi si platí službu za pět stovek měsíčně - ale chovají se, jako kdyby investovali stokrát víc.
to už je fakt fraška :)
tedy:
vody bylo málo - to by sakra dohled mohl nějak pořešit a dobře vyřešená serverovná zvládnout bez tak fatálního výpadku
vody bylo hodně - tudíž s tím nemohli nic dělat. pak by ovšem i debil pochopil, že je to v řiti a měl by přiznat barvu
v prvním případě mohu říct - byla nehoda, je tam voda, ale jsme kluci šikovní a snad to dáme
v druhým případě mohu říct - byla nehoda, je tam fakt moře vody, dá se předpokládat velký rozsah škod
zákazník si to může přebrat....
predpokladam, ze technik co tam sedi v 11.45 h ve vsedni den zvedne prdel a pujde se do serverovny podívat. narazi na vodu a udela shutdown.
nenarazi na vodu tak zkontroluje cidla.
tak a ted muzete psat neco o tom, jak si technik pri kontrole tekouci vody nevsiml, protoze tekla skryte....
Osobně bych nemohl mít dobrý pocit z odfláknuté práce. Pokud hrozí nějaké nebezpečí plynoucí z provozu nějakého přístroje nebo služby tak je slušností o tom zákazníka informovat. Např. u jednoho z přístrojů který jsem vyvinul vím, že v roce 2036 dojde k přetečení NTP času (protože je tam 16bit CPU). Zákazníka o tom informuji v manuálu.
Pokud provozuji seriózně nějaký hosting tak musím mít vypracovanou analýzu rizik (minimálně při uzavírání pojistky). A nebojím se tuto analýzu nechat veřejně dostupnou.
já to neumím. já si to dal k profesionálum do casablanky :)
(a dělal jsem si naštěstí zálohy)
dle fotek bylo vody hodně - o to spíš to měl klient vědět.
ne jaký je rozsah škod - ten mohou zjišťovat hodiny - ale že tam natekla voda a že rozsah škod patrně nebude malý - když tam jak píšete vody nateklo hodně...
co prosím na tom není jasné?
Problém je, že zákazníci tyhle věci moc nečtou. I z této diskuze je zřejmé, že si ani pořádně nepřečetli smlouvu a všeobecné podmínky. To pak můžete informovat jak chcete... stejně pak přijde nějaký pitomec, co bude řvát, že to nefunguje jak on čekal a nějakých 16 bitů ho zajímat nebude, protože ani nebude vědět, co to je :-)
Který hosting z té nepřeberné nabídky na trhu zveřejňuje analýzu rizik? :-)
Třeba jen nechtěli šířit informace založené na slovíčku patrně, když sami nevěděli. Třeba měli nějaké indicie, že by se to mohlo možná rozběhnout v nějakém omezeném rozsahu dříve. Třeba jen nechtěli šířit zbytečnou paniku. Nevíme, jaká byla motivace. Ale na soudce si hrajeme :-)
S chladnou hlavou jde pochopit ledacos. Z pozice jednoho nasraného to také bude vypada jinak, než v kůži člověka, kterého bombardují stovky lidí. Co na tom není jasné prozměnu Vám? :-)
Zákazníků nemáte tolik. To bude ono...
Není to pravda to není jenom o počtu zákazníků. Moje řešení je mnohem silnější než řešení Casablanky a to bez ohledu na počet zákazníků.
Při mém řešení by stejná havárie Casablanky znamenala výpadek v řádu jednotek hodin a né jednotek dnů jako je to nyní....ale spíše jde o to, že Casablanca to své řešení vydávala za geograficky replikovaný cloud což byla lež jako věž!
Samozřejmě vše se může porouchat, ale pokud je to správně realizováno tak poruchu detekuje a informuje o ní. Falešné poplachy při správném návrhu lze též v podstatě eliminovat. Stačí třeba si přečíst jak se navrhují přístroje do výbušného prostředí (ATEX Zóna 0). Tam i tři různé poruchy v jednom přístroji nesmí způsobit výbuch. Použití součástek pro Industry rozsah teplot je snad samozřejmé.
To jestli německá pobočka T-Systems se napakovává na státní správě nevím, ale příliš bych to nepředpokládal.
Je ten cloud 3×ČR+1×SR odolný i proti problémům na páteřní síťové infrastruktuře? Třeba při velké povodni v Praze, kdy by to postihlo infrastrukturu více operátorů. Zajímalo by mne, zda jde opravdu mít i na takhle malém území opravdu 4 síťově nezávislé lokality, nebo zda ta infrastruktura přeci jen není někde společná.
jako jeden z největších zákazníků můžu zodpovědně prohlásit že si za to můžou sami. My jsme měli dohodou podchyceno chování v těchto případech, stejně závazek nedodrželi.
Z 50% je to CHYBA komunikace když to zjistili byla už stejně voda na zemi -> mohli minimálně firmy jako Hosting90 poškodit o méně jak desetisíce za to když to pak dělali v panice s časovým mankem, nehledě na to že by jim si ostatní firmy pomohli. My máme jen na casa minimálně 40 fyzických serverů VOLNYCH, ano často jsou to quadcory s 16GB ale pořád lepší než nic. Plus asi desítku 2cpu 32 jader, 128GB/256GB s 8/16 pozicema volných které mohli mít k dispozici do 10 minut od zjištění ale všichni mlčeli a lhali. Veěřím totiž že solidarita se každému jen vrátí zvlášť když my máme v HC8 150 serverů od kterých se to zastavilo jen 2m. snažíme se držet servery v rovnoměrném poměru HC6/HC/HC8 jenže jak pořád rosteme tak sice na počet to sedí ale samozřejmě hustota dat a instalovaný výkon je v nových rack stojanej výrazně vyšší než v těch co se osazovali před 2 lety.
A plně si uvědomuju že je dobře teď do casy kopat, prospěje to všem jim nezbyde než to prostě vyřešit i za cenu že bude vidět že nahoře je udělaná konstrukce z plexi která chrání ten prostor studené uličky. Není to totiž první problém - ano není to problém casy ale budovy, ale rozhodnutí budovat další sály udělala casa sama.
Navíc kdyby vypli elektřinu tak se mohlo těch na
Nicméně já jako technik a administrator pokud budu nějaké řešení dělat v rámci zaměstnanecké pozice jako odborný vedoucí nemohu udělato to, že vedení (které nemusí mít o techice žádný pojem) řekne "udělej cloud za 10mega pro sto tisíc virtuálů" tak MUSÍM říct - NE za ty peníze to NEJDE a ne že půjdu a udělám nějaký paskvil.
To samé vůči zákazníkům ... nemůžu tvrdit že mám 100% dostupnost, když technické řešení není plně duplicitní.
HC8 má asi 30 stojanů, 6 jich máme ty a 15 jich zůstalo nedotčeno. Myslím že hlavní problém je jinde, Naskládali to do jednoho míst aby bylo co ukazovat kdyby tam dali místo 80U technologií třeba jen 12 vypadalo by to jako že je to nějkej vtip - ale to je věc marketingu vysvětlit lidem že to mají v 10 stojanech sami u sebe ve vlastním.
A o vodě dobře vědí, např my jsme měli v jednání dodatek jenže právě tekoucí vodu neřešil (jejich pojišťovna) tak jsme to museli pojistit jinde nicméně po včerejšku jde pojištění na 100% hodnoty extra pro nás za nimi. Mám totiž pocit že plnou smrt (tj např požár) by pojistka neustála. Kdysi jsme tam měli dva firewally pro zákazníka každý za 3,5M a už tehdy byl problém že všechny servery zákazníků v budově stojí víc než pojistka kterou má casa uzavřenou.
A to Vaše skvělé řešení je jak moc rozšiřitelné škálovatelné? Předpokládám, že se nepotýkáte s problémy typu plný stojan pevných disků :-)
A kde jste vyčetl informaci o geograficky replikovaném cloudu? Už to padlo i zde v diskuzi, že se na webových stránkách hovořilo o jednom datacentru.
ale zase je to sice jedna tektonická deska ale díky NIXu se dá domluvit nixovej backup za pár šušňů a když se cukají dohodnout VPN a pak je zřejmé že je to komunikace dvou nod a nic jiného nejde tak to není ani nix.
Jeden z našich x dodavatelů to řeší protokolárním sondováním, tj (tvrdí) že dělá sampling těch dat a zkoumá jestli jich je 90% mezi těmi danými rozsahy (tj dvě datacentra) - myslím že to nedělají a veří nám, ale prostředky mají jak to z netflow vytáhnout. Pak neni ani potřeba budovat nějaké jiné trasy nebo nějaká speciální řešení.
Důvod koncentrace je jedinej ekonomika, vždy když poptáváme v rámci failoveru 1-2 stojany tak je to katastrofa když jich poptáme a osadíme 20 je cena jinde (klidně i 1/4). takže by o tom měli markeťáci zapřemýšlet.
ne nezjišťovala, můžou vám dát nějakou drobnou slevičku ale sám mám pojištěných 1500 serverů (nejsou všechny moje ale i zákazníků) jako soubor svěřených věcí a technické řešení ani nic jiného je nezajímalo - pojišťovny pracují ze statistikou plnění tj vědí jak je daná věc riziková statisticky. nebudou zkoumat jestli když vám dávají zodpovědností pojistku děláte pravidelně zálohy a navíc geografické čímž riziko plnění minimalizujete - ano dají vám za to 5-10 procent ale ve zbytku se vezete s ostatními lidmi v dané pojišťovací skupině (tj daný obor, ict soubory, stavební firmy, právní firmy)
no a pak mají stanovenou míru rizikovosti, peníze pro záložnu, peníze pro zajišťovatele, rezervy a ZISK od toho odvozují pojistné NE od toho jak moc se snažíte s riziky bojovat (právě proto že vám tam někdo namočí).
A ta sranda pak stojí kolik? Rozumím tomu, že na zařízení do výbušného prostředí se kladou jiné nároky, ale to jsme předpokládám také zpět u financí. Nehledě na to, že datacentrum výbušným prostorem opravdu není. Všimněte si prosím, že sám užíváte slova "vpodstatě". Úplnou jistotu nemáte nikdy. Technická dokonalost je úžasná věc - bohužel peníze rozhodují vždy a o všem a jsou tvrdou limitou pro dokonalá řešení.
nemáte pravdu, píšou o 100TB to jest bratru 40kkč měsíčně při tom kdyby to byl denně 1/5 flow (tj 20TB denně) (tj že by aktuální zálohy delali každou hodinu a např ty starší by mazali po 48 hodinách tak že by nechali vždy jen jednu ze dne tj by bylo např 24 záloh (inkrementů) po dobu 2-3 dnů (kvůli víkendu) a např 28 záloh po dnech.
Mj měl jsem za to že zálohovali pro sebe právě pro případ jako je tento aby data dokázala vrátit, diletantství některých zákazníků co svěřili zálohu jen case nepotřebuej komentář měli jsme několik větších objednávek (5k měsíčně víc) na virtuály a všichni svorně tvrdili že čekají až jim casa vydá data. a to to byli lidi s 50Gb dat tj 20-100kč měsíčně za backup
Třeba takový teploměr do zóny 0 stojí tak kolem 10k. U toho ATEXu jsem chtěl jenom demonstrovat, že jdou udělat skoro bezchybné přístroje.
Samozřejmě nikdy úplnou jistotu nemáš. Ale jde o snížení rizika. Doporučuji si něco přečíst o TMR (=triple modular redundancy). Jakýkoliv přístroj pro monitoring úniku kapalin, který je správně nainstalován dokáže rizika velice snížit. Alespoň technik dohledu bude vědět že mu teče do racku...
1200TB distribuovaného uložiště nás stálo asi 2,8M investičně, dál 900 tisíc na vývoji provozne je to měsíčně asi za 160 tisíc korun za hw a asi 35 interně za rozvoj a udržbu. Pokud by to nepoložilo poskytovatele tak to těch 800gb/s dá. Bohužel se předpokládá geolokace takže to dá 40 protože by to nedali uplinky žádného z dc.
takže problém bude že se replikovalo z pole na pole a ne virtuál pro virtuálu. to by aspoň mohli dát img zákazníkům ať si to pustí jinde - jenže to by byla smrt.
Musí teď jednat chladnokrevně když data pustí ven a neprovedou zdlouhavou replikaci tak přijdou o většinu zákazníků - takto bude výpadek a po výpadku to pojede to už bude fuk jestli to pojede od casa nebo jinde. A na to sází. JIné vysvětlení nemám, my máme totální kolaps firmy vyřešen tak, že prostě 100% dat jsme schopni zákazníkům vydat do 5ti minut (začít jistě to nekde stáhnout naráz) říci sorry padl na 5 Dc z šesti co používáme meteorit (nebo 3 meteority a dva boeingy podle chuti) a my nemáme jedinej server. Data máte k dispozici OKAMZITE tady, přejeme hodne štěstí u konkurence.
ťuk ťuk, snad se to nikdy nestane.
Jak uz bylo zmineno, takovy prusvih by mnoho lidi pochopilo, pokud by se prvni hodiny nezametal pod koberec, protoze kdyby rekli, ze se tam dostala voda ve velkem, resilo by se to hned a ne az po nekolika hodinach - precejenom nebudete desitky serveru hned obnovovat jinde, kdyz vas uklidnuji, ze je pouze zavada na datovem ulozisti :-(
už to nehul, nám přímo ohrozili podnikání a to ne tím že se voda zastavila na tom plexi nahoře 2m od našich 150 serverů v přesně v té místnosti ale to že jsem se to dozvěděl od zákazníka co k nám migroval z BBO z důvodu výkonu a chtěl to popohnat.
Jenže ještě nejméně dvě hodiny nám nic neřekli ale to už jsme mohl mít zvědy v Abacusu, Composu, At computers s balíkem peněz prosit o co nejvíc serverů co mi prodají. Dokonce věřím ž v Abacusu by mi je dali i na sekyru kdyby nějaké měli. jako plán B byl CZC/ALZAC a rozjet to v bedně za 600 z desktopovejch věcí a když už by selhalo všechno tak začít komplet recovery z backupu formou sdílení zdrojů ve vitualizační platformě (std děláme vše nejen z vyhrazenými zdroji ale ještě z rezervou).
Takže 2 hodiny které mohli znamenat rozdíl mezi 500K škoda na kompenzacích pro naše klienty a 3,5M škoda na majetku. Nemít vlastní zdroje informací a být někde z třince tak ještě druhý den v 9:05, kdy volal obchodní a marketingový ředitel v reakci na náš $$$ stop stav směrem k jejich firmě do uplného vyřešení , jsem si myslel že je závada na switchi.
A to přesto že informace byly závazně vyjednány v podmínkách na rok 2014. Dokonce i z náslechů hovorů x krát uznali problém na helplince tj věděli že mají sekyru v komunikaci. To kurva posrali přitom šlo o max 10 zákazníků kterým stačilo přiznat barvu.
Martine tuhle jsem byl na nejake startupove prednasce (tusim na Pioneer festivalu v Praze), kdy Zdenek rikal, ze diky nekolikadennimu vypadku CDN77 prisel o dva svoje klicove zakazniky ... Trosku me to prekvapilo, proto si to pamatuji. Tak nevim, jak je to s tou redundanci.
Uplne nerozumim slovum "CDN je plne cloudove". CDN ma dve casti - transakcni a distribucni. U distribucni casti je nesmysl pracovat s nejakym "rich cloudem". U transakcni casti ma smysl nejaky geograficky cluster, ale pokud nejste Akamai, tak objem dat nebude nijak dramaticky.
ANo je a důvody jsou samozřejmě ekonomické je to 2x Praha jednou Brno nejsou to různé sály jednoho isp jsou to samostatní ISP.
A důvod je jednoduchej ta firma je moje a je příliš malá na to aby ustála žaloby o např 50M škody takže musíme makat. Navíc máme zákazníka co má u nás několik set (jeho) serverů a to je firma co to dělá do světa a opravdu dobře takže na tyto technologie slyší resp nedovoli by nám to pravidelně musíme předkládat analýzu rizik a zoučasně roadmapu našeho "cloudu" protože oni tomu uzpůsobují verzování svých aplikací které na tom provozují a musí se to potkat. Samozřejmě se pak vede debata kdy mají navrch (jejich R&D je samozřejmě nákladnější tj my musíme naše řešení přizpůsobit jejich problémům).
A finančně na tom asi win-winují obě strany, pro ně je ekonomicky naprosto opodstatnitelné mít na to dodavatele kterj to pak může prodávat jinde než kdyby celej R&D táhli sami pro sebe. Už teď jsou náklady výrazně pod 10% aws, a samozřejme když k nám někdo pošle 100Gbit/S DDoS bude problém a útoky chodní pravidelně a s tím se cloud snadno popere ) find targetem většinou je to utok na konkrétního zákazníka a ne na infrastrukturu tudíž stačí "půlením" přesněji setinkováním intervalu rozložit projekty z daného serveru mezi 20 rezervních serverů a po chvíli víte proti komu útok jde takže např do 3-4 hodin už máte téměř jistotu ale hned po 10 minutách se utok netýká 80 procent projektů v daném node po 30 už 90 a pak se precizuje hledání cíle nebo se prostě IP blackholuje a aplikace se stím popere.
Společná je jen v nepoužívání různých hw dodavatelů, mixují se paměti disky ale servery jsou pořád stejné Supermicro - raději 13x supermicro než 10x dell/hp v cloudu najde 13 serverů vetší uplatnění než 10. TO by mohl být problém pouze v případě nějaké hodně specifické chyby ala scada (IPMI běží za firewallem) ale u některých serveůr bývalo sdílené takže teoretická chyba může existovat.
Přijdte se podívat v tomto případě není o nějakém cloud hype je to o tom že při instalovaných stovkách serverů se prostě privátní cloud VYPLATÍ ekonomicky.
A vidíte, jsou lidé, co pod napětím běžně pracují. V datacentrech běžná věc, už vidím, jak zákazníci jásají, když kvůli výměně jističe schazujete polovinu serverovny :-)
§10 říká, že máte znalosti předpisů nutné na projektování a předpisů souvisejících s projektováním, ale narozdíl od ostatních vyšších kvalifikací (§5-§9) dle odkazované vyhlášky zde není kladen důraz na odborné vzdělání v oboru ani na praktické zkušenosti s prací pod napětím (požadované u §6-§9).
Tušíte něco o funkci online UPS, které se používají v datacentrech? Víte například o tom, že výstupy UPS se běžně vybavují proudovými chrániči, ktere vybaví již při nepatrném rozdílu proudů mezi P a N vodičem, tedy v momentě, kdy proud teče jinudy, než by měl? :-)
jestě doplním, jedná se o mraky instalací té samé app proto je ten cloud realizovatelný kdyby to měl být cloud ala aws kde by instanace byli zákaznické vps byl by problém 100x větší a rozhodně si co do kvality netroufám cokoliv s azure/aws srovnávat.
Ale pro specifickou štíhlou aplikaci kterou používají desítky milionů zákazníků se opravdu napsat "custom" řešení vyplatí.
pro nás je to témeř stejně levné, stejně jsme měli vždy v Brně z hist důvodů vývoj (jsem brňák sice už 18 let pražská naplavenina) tj prostě trávím 2 dny v týdnu v brně a vedu dvě izolované jednotky (dohled je centrální z prahy tady se jen fyzicky manipuluje s disky a to stačí 1x denně protože se s tím infrastruktura popere - se selháním serveru).
NAvíc je dobré že se jedná o globální projekt takže nejsou peaky zatížení nodů je mnohem mnohem plošší než české projekty a tudíž je dokonce jedno že se z hw manipuluje ve dne.
Myslím že je v celku jasné čí appky to jsou a asi se dá snadno ověřit kde všude to běží (včetně aws/azure)
No nebo ne. Obcas je to jen o ochote vypadnout ze zajetych koleji :-)
Ale samozrejme jsem obvykle dost protivny, protoze odmitam prikyvovat davu, ktery chce videt krev (moji nebo cizi). To popularite neprida. Pak taky moc neverim na quickfixy a kdyz clovek opakuje do omrzeni, ze problem XXX nevyresim ted tim, ze do systemu nasypu YYY, ale ze se to ma predelat na ZZZ, tak to neni dobre.
Coz samozrejme vede k tomu, ze kdyz se mi povede nejaky quickfix provest, tak mi to kolegove dost dlouho a dost usilovne otloukaji o hlavu (napriklad jeden postarsi Thumper od Sunu mi byl omlacen o hlavu asi milionkrat). A zaslouzil jsem si to.
Ano já hovořím o přístupu k zákazníkovi tj jakej efekt to má pro něj a u cdn se dá celkem dobře zajistit jak provoz tak neztratit ta data. Např my tam prostě nemáme raid data fyzicky nakopírujeme na 3-4 lokality a navíc ty exponovaná do sebe natahají ty cacheovací nody.
CDN je plne cloudove, no tím chci říci že se dá napsat tak že buckety jsou zcela izolované tj nehrozí nic jako nutnost týden něco obnovovat obnoví se co chybí a neexistuje nic jako celek. Jako celek funguje jen administrace (cloudově prostě se zaloguje vyberese mu noda kde běží administrace a tam si to lokálně pytlíkuje přes api s cdkou) a billing a to ještě tak že se "mergeují" data z jednotlivých popů a platí že 1% data loss není problém prostě když se stratí záznam že proběhl z popu download tak to zákazníka postíhne tak že zaplatí o 1% méně a nijak jinak.
což je ale jiná situace kdy existuje nějakej iSCSI volume 50TB velikej a pak se děj vůle boží - to by bylo peklo.
A osobně si myslím a vsadím na to krk že ten výpadek se týkal těch zahraničních node a tam je problém že nemá fyzicky lidi ve všech bodech kde to kupuje takže prostě selhal někdo jiný (podrobnosti neznám). Ale vsadil bych na to že to byli tech/kapacitní problémy.
Buď soudnej, kolikrát si před 10 lety dal takticky a technicky pojeb různým technikům mini isp (zrovna tady na lupě) a v době kdy to jeli na PCčkách (routery) jsi jim vysvětlovat že si mají koupit box kterej je sice 50x dražší ale problémy které oni řešili nemají.
A u nich to nebylo o kolejí ale o tom že prostě nešlo konkurovat např GTS které tehdy nasypalo do datacentra peníze a bum podalo se jednou, to samé contactel atd - prostě jim nemohli konkurovat někde v horní dolní by to byla finanční sebevražda a ty jsi je vůbec nešetřil.
Já jsem s tebou 100 a jedenkrát nesouhlasil a říkal to se mu to kecá když to neplatí ze svého a to jsem se snažil takže nějakej typickej majitel/participant hornidolnifreenet.cz tě musel fakt miliovat.
To samé distribuce obsahu a videa zvlášť, diskuze o HW enkodérech videa mi tak nějak utkvěla v paměti.
hlupák nehlupák, po bitvě je každý... nevím jak velká to je firma, jestli má vlastní IT a někoho komu se dá věřit a umí.
Ale tak třeba na tomhle případu, to by mě fakt zajímalo, jak probíhalo výběrko na tohle, co rozhodovalo, jestli cena nebo známosti, nebo co, přeci pokud vidím firmu nalezlou jen v jednom baráku, tak mi musí být jasný, že když barák vyhoří/vytopí/bouche plyn, tak končíme a na smlouvě může být co chce. Taky trochu selskýho rozumu to chce.
Deset malých polí bude finančně opět někde jinde než jedno velké. Diskové pole nejsou jen ty šuplíčky s diskama :-)
O ICT ve Škodovce nic netuším, ale takový Seznam.CZ prováděl obnovu po výpadku také několik dní. Holt skleróza je prevít, lidé rychle zapomínají, že ty obnovy v případě průseru proste nejsou za pár minut. Stačí zapátrat na internetu. A to přesto, že peněz mají více než dost :-)
Jo uz vim, o cem mluvis. Ja tomu jen nerikam cloud ale CDN - ze jsou jednotlive nody atomizovane, je vlastnost CDNky :-) Jako cloud je nasaditelny ten prostredek (tj. predevsim iridici vrstva) - protoze i ten musi nejak skalovat.
Souhlasim, ze zecloudovatet nejakej filesystem s blokovym pristupem (v ve vzdalenejsich lokalitach) je seriozni problem.
Nevim, jak a kde to ma ZC nasazeno, faktem je, ze pronajem virtualnich stroju nebo appliance na nich neni zadna rocket science. To je dneska komodita. A urcite to nema moc souvislost s tim, zda jsou nekde lidi. Spis to ve me budilo dojem, ze se to proste sesypalo (v prednasce moc konkretni nebyl, nebylo pro to ani publikum).
Jiste jiste ... pujdu vybagrovat tu pripojku, pripadne si necham rozebrat celou serverovnu, aby se presvedcil, ze to co pisou je ve skutecnosti pravda ... a pak zavolam tomu bagristovi, aby to prekop ... a ja se moh presvedcit o tom, ze to vazne pobezi ....
Boze takovyho kretena potkat ....
Casablanca není v jednom baráku, však proto jim to taky tak trvá, protože tu zálohu tahají bůhví odkud. A protože jim na ničem nezáleží víc, než na spokojenosti klienta, tak to tahaji 2x1Gbitem, takže při těch cca 100TB mají prostor zaujmout klienta na nějakých 50 hodin. Použít něco rychlejšího a zkrátit tak dobu třeba na 15 hodin, tak se s klientem skoro vůbec neužijí. :-)
To mas jiste pravdu. Ale kazdy se s tim musi nejak vyrovnat.
Ja jsem take jen smutne koukal, kdyz jsem zjistil, ze za cenu dvouleteho reseni (vcetne nejakeho vyvoje), ktere jsme vysoutezili u nejmenovane televize, by to Akamai v promo cenach dokazala poskytovat jeden mesic behem nejake sportovni akce - a nebyla by to schopna v dane dobe odbavit kvuli kapacite linek do CR a kapacite jejich POPu v CR. Zivot neni pericko.
Diskusi o koderech videa si uz nevybavuju, ale asi bych si ji mel obcerstvit, kdyz se ted trochu motam kolem softwaroveho kodeku :-)
jeden nas zakaznik co prisel pri povodnich o dost penez naz doted nuti jednou za cas "na zavolani" obnovit pred nim data v jim dodanem prostoru a sleduje ze jsou ze zaloh tj povoli nam komunikaci pouze do zaloh (dame mu id blobu v zalohach a on je stahne aby se presvedcil ze to netahame z produkcnich masin) a my to musime poskladat.
tj nechapu proc si nekdo proste nenechal jednou za ctvrt roku ty zalohy zpristupnit aby si je poslal. v nasem distribuovanem ulozisti (na zalohy) ma kazdej klient moznost bezplatne vytahat si pres http rozhrani kolik chce zaloh (okamzite) a overit si ze v zaloze je co tam je. obcas to nekdo udela casto sleduji jen velikost te zalohy ale jsou puntickari co to udelaji - a my jsme za to radi, kontrola je dulezita.
Ze je nekdo vestec jako ty a z pouzityho SW usuzuje ze jde o nekonzistetni zalohy ... to teda lol.
Vis, nekteri narozdil od tebe zalohovani pomoci snapovani disku a prenosu rozdilovych dat zcela bezne pouzivaji ... a kupodivu maji zcela bezne zcela konzistetni zalohy nejen databazi, ale i vsech FS, ktere to umi. A dokonce to umi daleko castejs nez toto velke "reseni".
Kéž by to takto v životě fungovalo. Divil byste se, jaké mnohem horší paskvily vznikají všude možně kolem nás. A často je vyrábí lidé, co na základě zkušeností s dvěma servery v garáži vymýšlí řešení velkého systému s technologiemi, které neviděli ani z rychlíku. A ono to nějak dopadne :-)
Pokuď jde o onu duplicitu - opět jsme u toho, jakým způsobem je duplicita komponent realizována. I umístěním redundantního zařízení do sousedního racku duplicita vznikne. Posuzovat můžete robusnost, ale nikoliv namítat, že duplicita neexistuje.
Ale i z pohledu všech těch fňukálků tady - řeší své obrovské obraty a ztráty, klíčovou závislost jejich byznýsku na svých serverech, ale nejsou ochotni řádně řešení navrhnout, když je to tedy tak moc kritické. Přečtou si jeden papírek, kde se zaleskne 100% a to jim ke štěstí stačí - zjišťovat, co za tím je netřeba. Nepřemýšlí o rizicích, o tom, co garance skutečně pokrývá. Že nastala chyba už v návrhu jejich systému si prostě nepřipouští. Pokuď je to tak háklivé, tak přece nenacpu věci do nějakého cloudu, ale v několika serverovnách běžím dedikované servery. Inu, dobře jim tak :-)
asi nechápu co píšete, bavím se o to že je logistickej problém sehnat za den 150 serverů tj bychom nemohli poskytovat služby takže kompenzací myslím součet pokut a výpadek přijmů.
A o cimře asi není co dodat casa tam měla 100% svého cloudu my sotva 8% a to máme mít těch dodavatelů 60? Umíte si to představit.
A hlavně ekonomicky je rack jediná smysluplná jednotka když použiju PDU pro 22 serverů je cena 800 per port když tam dám jeden tak 17000, když koupím dva switche je cena fullracku 1200 za port když tam dám jeden bude to 30k/port. Pak ješte monitoring prostředí, firewall (často mikrotik v bridge modu co jen chrání management karty přes tím aby bylo volně přístupné z internetu)
takže jestli je box v ceně 100k umístěnej se setup fee 2500 nebo 80000 je sakra rozdíl. Nehledě na to že když by to vypadlo tak IP jinde nepustíte (ani s multihomingem) takže jich tam musí být vždy 21 produkčních a jedna spare záloha.
Mj jeden z hostingů který tu zde diskutuje udělal v den výpadku v Abacusu objednávku za MILION korun takže pokud jednali o cenách pod tlakem a brali cokoliv aby to bylo co nejdřív tak jen škoda na tom že si to nepoptali nevysoutěžili standartně půjdou do desítek tisíc.
nevidím jako problém prodávat hosting za 20k, jako problém pro trh vidím ho při ceně 20k zaplavovat neustálejma slevama a akceme a tudíž udělat letadlo (mít u 80% zákazníků peníze teď ale závazek službu prodávat ještě dva-tři roky).
Ale považuji to za zcela regulérní obchodní model. A sorry BBO nebyl z nejlevnějších , zvlášť kvůli tomu poli. Zbytek byli žiletky kvůli efektivitě a VM které si může koupit kdokoliv. A není to mnoho pokud nemáte platit stovky licencí.
Toto je vyrovnávací paměť vyhledávače Google pro adresu http://bigblueone.cz/common/?vop. Je to snímek stránky, tak jak se zobrazila 29. prosinec 2013 00:59:39 GMT. Aktuální stránka se mezitím mohla změnit. Další informace
Tip: Chcete-li na této stránce rychle najít hledaný výraz, stiskněte klávesy Ctrl+F nebo ⌘-F (Mac) a použijte lištu Najít.
Pouze textová verze
Všeobecné podmínky
pro poskytování služby BIG BLUE ONE
společnosti CASABLANCA INT s.r.o.
verze 2.0, účinná od 1. 12. 2012
1. Úvodní ustanovení
1.1. Společnost CASABLANCA INT s.r.o., IČ: 25079832, se sídlem Praha 5 - Košíře, Plzeňská 183/181, PSČ 150 00 je oprávněna k poskytování služeb elektronických komunikací, a to na základě osvědčení č. 365 vydaného Českým telekomunikačním úřadem a v souladu s ustanoveními § 63 zákona č. 127/2005 Sb., o elektronických komunikacích vydává tyto Všeobecné podmínky pro poskytování služeb elektronických komunikací – služba BIG BLUE ONE (dále jen „Podmínky“).
1.2. Tyto Podmínky stanovují technické, provozní, organizační a obchodní předpoklady, vzájemná práva a povinnosti smluvních stran vznikající ze Smlouvy uzavřené mezi Poskytovatelem a Uživatelem, zejména podmínky týkající se:
předmětu a rozsahu poskytovaných služeb;
podmínek pro jejich objednávání a zřizování;
cen a platebních podmínek, práv a povinností uživatelů Služby BBO a Poskytovatele služby;
stanovení důsledků v případě neplacení či zneužití Služby BBO;
způsobů podávání a vyřizování stížností a reklamací na případně nekvalitní poskytnutí Služby BBO a na účtované ceny.
1.3. Podmínky jsou Uživateli dostupné v provozovně Poskytovatele nebo na Webové stránce Poskytovatele http://www.casablanca.cz nebo na http://www.bigblueone.cz. Na uvedených Webových stránkách je dostupný i ceník služeb, výkonů, resp. jakýchkoli jiných plnění, které Poskytovatel poskytuje za úplatu, popř. bezúplatně. Tyto podmínky, stejně jako Ceník, jsou v jejich aktuální verzi, jakož i ve všech verzích dříve učiněných Poskytovatelem, dostupné i v provozovně Poskytovatele.
2. Výklad použitých pojmů
2.1. Kromě pojmů, uvedených v § 2 zákona č. 127/2005 Sb., se pro účely těchto Podmínek rozumí:
Adresa Poskytovatele – adresa elektronické pošty uvedená v rámci Uživatelského účtu, určená pro komunikaci Uživatele s Poskytovatelem v záležitostech týkajících se Smlouvy a poskytování Služby BBO;
Adresa Uživatele – adresa elektronické pošty zadaná Uživatelem v Uživatelském účtu;
Ceník – dokument Poskytovatele zveřejněný na internetových stránkách https://online.bigblueone.cz, který obsahuje jednotkové ceny dílčích služeb Poskytovatele zahrnuté ve Službě BBO, s výjimkou paušální ceny za provoz Služby BBO;
Cenová kalkulačka – technický prostředek přístupný každému zájemci o uzavření Smlouvy na Webových stránkách určený k výpočtu (určení) ceny Služby BBO dle parametrů, především týkajících se rozsahu, povahy a délky trvání poskytovaného plnění, které nastaví (vybere) Uživatel z nabídky Poskytovatele; cena stanovená prostřednictvím Cenové kalkulačky vychází z jednotkových cen uvedených v Ceníku a zahrnuje rovněž paušální cenu za provoz Služby BBO;
Konektivita - způsob připojení Služby BBO do sítě Internet
Kredit – cena uhrazená Uživatelem ve formě předplatného za podmínek uvedených v čl. 9 podmínek;
Odstávka - předem oznámené krátkodobé přerušení poskytování Služby BBO v důsledku nezbytné kontroly nebo úpravy technologického zařízení, údržby či výměny hardware, nebo nastavení či upgrade počítačových programů souvisejících s provozováním Služby BBO, popř. předem oznámené přerušení poskytování Služby BBO provedené na příkaz oprávněných státních orgánů v době mimořádných opatření či z jiného důležitého obecného zájmu;
Poskytovatel – CASABLANCA INT s.r.o., společnost zapsaná v obchodním rejstříku, vedeném Městským soudem v Praze, oddíl C, vložka 47894, dnem 2. října 1996, pod spisovou značkou Firm 50443/96 se sídlem Plzeňská 181/183,150 00 Praha 5 a IČ: 25079832, registrovaná provozovna Vinohradská 184, 130 52 Praha 3;
Podmínky - tyto Všeobecné podmínky pro poskytování služeb elektronických komunikací – služba BIG BLUE ONE;
Smlouva – Smlouva o poskytování služby BIG BLUE ONE uzavřená s Uživatelem;
Služby elektronických komunikací - služby, jejichž poskytování spočívá zcela nebo převážně v přepravě informací pomocí elektronických komunikačních zařízení;
Služba BBO – služba elektronických komunikací BIG BLUE ONE spočívající v pronájmu Hardwarových a Software prostředků a v zajištění připojení těchto prostředků do sítě Internet, kdy se její vlastnosti odvíjejí od nastavení provedených Uživatelem, blíže specifikovaná ve Smlouvě a na Webových stránkách;
Technická specifikace – obecná specifikace plnění Poskytovatele poskytovaných v rámci Služby BBO, uvedená během registračního procesu v rámci Cenové kalkulačky na stránkách http://www.bigblueone.cz, nebo během konfigurace nového serveru nebo při změně konfigurace stávajícího serveru, přičemž Uživatel má přístup k aktuální technické specifikaci v rámci svého Uživatelského účtu;
Virtuální server – část výpočetního výkonu provozovaného na Poskytovatelem přiděleném hardwaru;
Uživatel - fyzická nebo právnická osoba, které je poskytována služba elektronických komunikací na základě Smlouvy;
Uživatelský účet – uživatelské rozhraní na internetové adrese https://online.casablanca.cz/ a/nebo https://online.bigblueone.cz, prostřednictvím kterého může registrovaný Uživatel zejména provádět správu nastavení (charakteristik) Služby BBO a správu údajů o své osobě;
Webové stránky – internetové stránky Poskytovatele www.bigblueone.cz.
3. Uzavření a platnost Smlouvy
3.1. Návrh na uzavření Smlouvy, učiní Uživatel za použití prostředků komunikace na dálku, a to elektronicky ve formě odeslání vyplněného registračního formuláře umístěného na stránce Poskytovatele http://www.bigblueone.cz/ (dále jen „Žádost o registraci“). Ještě před odesláním registračního formuláře Uživatel zvolí požadované parametry Služby BBO. Údaje uvedené Uživatelem v Žádosti o registraci jsou považovány pro účely jednání o uzavření Smlouvy i Podmínek za správné.
3.2. Po doručení Žádosti o registraci (návrhu na uzavření Smlouvy) Poskytovateli zašle Poskytovatel na adresu elektronické pošty určené Uživatelem v Uživatelském účtu informace nezbytné ke zprovoznění Uživatelského účtu (dále jen „Akceptace“). Doručení Akceptace Uživateli je odsouhlasením Žádosti o registraci (přijetím návrhu na uzavření Smlouvy Poskytovatelem) a tímto okamžikem je Smlouva uzavřena. Ke zprovoznění Uživatelského účtu je Poskytovatelem vyžadováno zadání informací zaslaných Uživateli na Adresu uživatele v rámci Akceptace.
3.3. Poskytovatel započne s poskytováním Služby BBO bez zbytečného odkladu poté, co Uživatel uhradí Kredit dle čl. 9.2 Podmínek. Poskytování Služby BBO, resp. plnění Smlouvy, může Poskytovatel zajišťovat také prostřednictvím třetích osob. V takovém případě odpovídá za řádné poskytování Služby BBO, jako by ji poskytoval sám.
3.4. Podmínkou pro odeslání Žádosti o registraci dle čl. 3.1 je odsouhlasení těchto Podmínek, které jsou nedílnou součástí Smlouvy uzavřené mezi Poskytovatelem a Zákazníkem a upravují vzájemná práva a povinnosti smluvních stran ze Smlouvy.
3.5. Pokud není ve Smlouvě výslovně uvedeno odchylné ujednání nebo platnost některých ustanovení těchto Podmínek není Smlouvou nebo jiným výslovným ujednáním mezi Poskytovatelem a Uživatelem vyloučena nebo jinak modifikována, platí v ostatním pro vzájemné vztahy mezi Poskytovatelem a Uživatelem tyto Podmínky.
3.6. Uživatel bere na vědomí, že Poskytovatel není povinen uzavřít Smlouvu (může odmítnout registraci (návrh Uživatele na uzavření Smlouvy), a to zejména s osobami, které dříve podstatným způsobem porušily své smluvní či jiné povinnosti vůči Poskytovateli nebo jsou v prodlení s plněním závazků vůči Poskytovateli, a to bez ohledu na právní důvod vzniku takovéhoto závazku.
3.7. Smlouvu lze uzavřít v českém a anglickém jazyce; je-li byť jen část smlouvy v anglickém jazyce pak bez dalšího platí, že třetí osoba, která činí Poskytovateli návrh na uzavření Smlouvy, ovládá anglický jazyk v takovém rozsahu, že zcela rozumí všem ustanovením Smlouvy, která jsou v anglickém jazyce a je schopna v anglickém jazyce činit právní úkony.
3.8. Uživatel souhlasí s použitím komunikačních prostředků na dálku při uzavírání Smlouvy. Náklady vzniklé Uživateli při použití komunikačních prostředků na dálku v souvislosti s uzavřením Smlouvy (např. náklady na připojení k internetu) si hradí Uživatel sám.
4. Předmět Smlouvy a charakteristiky Služby BBO
4.1. Na základě uzavřené Smlouvy se Poskytovatel zavazuje poskytovat Uživateli Službu BBO v rozsahu dle Technické specifikace a Uživatel se zavazuje za to platit Poskytovateli cenu, jejíž výše se odvíjí od nastavení Služby BBO provedené Uživatelem.
4.2. V rámci Žádosti o registraci, a poté kdykoliv v rámci Uživatelského účtu, si Uživatel může nastavit a měnit charakteristiky Služby BBO v rámci limitů nabízených Poskytovatelem, konkrétně se jedná o nastavení/určení:
4.2.1. počtu, rozsahu anebo kapacity hardwarových prostředků, které má Uživatel zájem v rámci Služby BBO využívat (mít pronajato), a to nastavení počtu procesorů (CPU), rozsahu využívané operační paměti (RAM), velikosti prostoru na pevném disku (HDD a možnosti bezpečnosti (např. IPS)(dále společně jen jako „Hardwarové prostředky“);
4.2.2. objemu datových přenosů směřujících z pronajatých Hardwarových prostředků do sítě Internet (dále jen „Datové přenosy“), jež má Uživatel zájem v rámci Služby BBO využít;
4.2.3. počítačových programů, které chce Uživatel na pronajatých Hardwarových prostředích užít (dále jen „Software“).
4.3. Maximum Hardwarových prostředků a Datových přenosů, které může Uživatel v rámci Služby BBO v konkrétním okamžiku využívat, vyplývá z Cenové kalkulačky a je uvedeno v rámci Uživatelského účtu. Uživatel bere na vědomí a souhlasí s tím, že v případě, kdy má zájem provést změnu charakteristiky Služby BBO směřující k využívání mimořádně vysoké kapacity Hardwarových prostředků, nemusí být požadované Hardwarové prostředky bezprostředně k dispozici.
4.4. Je-li tak Uživatelem nastaveno v Uživatelském účtu, poskytne Poskytovatel Uživateli Smlouvou oprávnění k výkonu práva užít počítačový program společnosti Microsoft Corporation, se sídlem One Microsoft Way, Redmond, WA 98052¬6399, Spojené státy americké (dále jen „společnost Microsoft“) specifikovaný Uživatelem v rámci Uživatelského účtu (dále jen „software Microsoft“), přičemž odměna za poskytnutí licence k Software Microsoft je součástí ceny sjednané prostřednictvím Cenové kalkulačky (čl. 8.2.1). Další práva a povinnosti stran ohledně užití Software Microsoft Uživatelem se řídí příslušnými obchodními podmínkami a licenčními podmínkami společnosti Microsoft, s nimiž je Uživatel seznámen ještě před odesláním Žádosti o registraci (dále jen „licenční podmínky společnosti Microsoft“). Uživatel bere na vědomí, že licenční podmínky společnosti Microsoft mohou být společností Microsoft jednostranně změněny; Poskytovatel bude v takovém případě informovat o změně prostřednictvím Uživatelského rozhraní, přičemž čl. 15.5 Podmínek se užije přiměřeně.
4.5. Užití ostatních počítačových programů Uživatelem (jiných než Software Microsoft), nabízených v rámci Služby BBO, se řídí licenčními podmínkami vydávanými příslušnými nositeli práv k těmto počítačovým programům (zpravidla obecná veřejná licence GNU GPL – General Public Licence); Poskytovatel není distributorem takových počítačových programů a pouze zprostředkovává možnost jejich užívání, za které si neúčtuje žádnou odměnu ani provizi.
4.6. Uživatel bere na vědomí, že předmětem Smlouvy a Služby BBO jsou pouze plnění Poskytovatele uvedená ve Smlouvě popř. v Technické specifikaci. Předmětem závazku Poskytovatele ze Smlouvy není mj. provádění archivace dat ani jejich umístění na Hardwarové prostředky v rámci Služby BBO, které provádí Uživatel na vlastní nebezpečí (riziko) a vlastní odpovědnost.
4.7. Uživatel bere na vědomí, že Poskytovatel nenese odpovědnost za nastavení (charakteristiky) Služby BBO provedené Uživatelem prostřednictvím Uživatelského účtu (např. reset přidělených Hardwarových prostředků nebo vypnutí bezpečnostních aplikací Secure Cloud, pokud bylo provedeno Uživatelem).
5. Uživatelský účet a doručování
5.1. Přístup k Uživatelskému účtu je podmíněn registrací Uživatele provedenou na Webové stránce Poskytovatele.
5.2. Uživatelský účet Uživatele bude zprovozněn po uzavření Smlouvy a provedení registrace Uživatele na Webové stránce, tj. poté, co Uživatel vyplní všechny údaje požadované v rámci registračního formuláře. Poskytovatel provádí ověřování totožnosti Uživatele a jím zadaných údajů prostřednictvím SMS zaslané na číslo mobilního telefonu zadané Uživatelem v registračním formuláři.
5.3. Údaje uvedené v Uživatelském účtu je Uživatel při jakékoliv jejich změně povinen aktualizovat. Údaje uvedené Uživatelem v Uživatelském účtu jsou Poskytovatelem považovány za správné, neboť za jejich správnost a aktuálnost odpovídá bez dalšího Uživatel. Poskytovatel si vyhrazuje právo ověřit totožnost či aktuálnost údajů zadaných v Uživatelském účtu.
5.4. Každá osoba může mít pouze jeden Uživatelský účet. Uživatel není oprávněn umožnit využívání Uživatelského účtu třetím osobám.
5.5. Přístup k Uživatelskému účtu je zabezpečen uživatelským jménem (adresou elektronické pošty) a heslem. Uživatel je odpovědný za uživatelská hesla, která mu byla Poskytovatelem přidělena a je povinen tato hesla chránit popř. provést/požadovat jejich změnu, jakmile má podezření na možnost jejich prozrazení třetím osobám a možné zneužití. Za případné zneužití přístupových hesel třetí osobou je odpovědný Uživatel, ledaže by prokázal, že jejich prozrazení prokazatelně zavinil výlučně Poskytovatel.
5.6. Poskytovatel může Uživateli znemožnit využívat Uživatelský účet (a Službu BBO), a to zejména v případě, kdy Uživatel poruší své povinnosti ze Smlouvy (včetně těchto Podmínek).
5.7. Uživatel bere na vědomí, že Uživatelský účet nemusí být dostupný nepřetržitě, a to zejména s ohledem na nutnou údržbu hardwarového a softwarového vybavení Poskytovatele. Stav, kdy nebude Uživatelský účet dočasně dostupný, nepředstavuje poruchu ve smyslu čl. 6.3 popř. 6.4 Podmínek a nezapočítává se do měření dostupnosti Služby BBO.
5.8. Uživatel bere na vědomí a souhlasí s tím, že s ohledem na vznik Smlouvy za použití prostředků komunikace na dálku mohou být veškerá oznámení, výzvy, upozornění, faktury, výpovědi Smlouvy, odstoupení od Smlouvy i další písemné úkony související se smluvním vztahem vzniklým na základě Smlouvy učiněna prostřednictvím elektronické pošty; Poskytovatel je však povinen zaslat je na poslední Adresu Uživatele, jak byla uvedena v Uživatelském účtu.
5.9. Uživatel je zodpovědný za to, že kontaktní údaje v Uživatelském účtu jsou aktuální a dále je odpovědný za správné nastavení své e-mailové schránky, její funkčnost i za to, že nemá e-mailovou schránku plnou. V případě dlouhodobé nepřítomnosti příslušné osoby je Uživatel povinen přesměrovat si Adresu tak, aby byl zajištěn příjem elektronické pošty a reakce na ni.
5.10. Uživatel je rovněž oprávněn činit úkony dle čl. 5.9 Podmínek za použití prostředků komunikace na dálku, a to prostřednictvím elektronické pošty zaslané na Adresu Poskytovatele. Nebude-li v rámci Uživatelského účtu uvedena jiná Adresa Poskytovatele, zřídil Poskytovatel pro řešení záležitostí vztahu vzniklého ze Smlouvy tyto adresy elektronické pošty:
- info@casablanca.cz (obchodní záležitosti – např. uzavření Smlouvy, změny Smlouvy, vyúčtování),
- tech@casablanca.cz (technická podpora – např. oznamování poruch, reklamace kvality).
5.11. S ohledem na to, co bylo uvedeno shora v čl. 5.9 až 5.11 Podmínek, se veškeré písemné úkony, oznámení, výzvy či faktury považují za doručené nejpozději do 10 pracovních dnů ode dne odeslání e-mailu Poskytovatelem na Adresu Uživatele, resp. Uživatelem na Adresu Poskytovatele. Uživatel není v prodlení, pokud prokáže, že mu nebyl příslušný e-mail doručen z důvodů na straně Poskytovatele. Poskytovatel není v prodlení, pokud byl příslušný e-mail odeslán na jinou adresu elektronické pošty, než je Adresa Poskytovatele uvedená v rámci Uživatelského účtu.
6. Povinnosti Poskytovatele, garantovaná úroveň Služby BBO
6.1. Poskytovatel se zavazuje poskytovat Službu BBO v rozsahu a kvalitě podle Smlouvy a nepřetržitě, pokud tomu nebrání okolnosti, vyjmenované v obecně závazných právních předpisech (např. nemožnost plnění ve smyslu § 352 Obchodního zákoníku, okolnosti vylučující odpovědnost Poskytovatele dle § 384 Obchodního zákoníku nebo omezení a povinnosti vyhlášené na základě ústavního zákona č. 110/1998 Sb., o bezpečnosti České republiky).
6.2. Poskytovatel se zavazuje udržovat zařízení ve stavu způsobilém pro řádné používání Služby BBO. Poskytovatel odpovídá za řádný provoz, kontrolu a údržbu svého technologického zařízení určeného k zajištění poskytování sjednaných služeb elektronických komunikací. Poskytovatel se zavazuje zajišťovat garantovanou dostupnost Služby BBO, která sestává z garantované dostupnosti Hardwarových prostředků (čl. 6.3 Podmínek) a z garantované dostupnosti Konektivity (čl. 6.4 Podmínek).
6.3. Garantovaná dostupnost Hardwarových prostředků činí 100 % měsíčně, přičemž dostupností Hardwarových prostředků se pro účely těchto Podmínek rozumí, že tyto nejsou ve stavu poruchy (tzn. byl virtualizační platformou přidělen výpočetní výkon Virtuálního serveru dle Technické specifikace). Poruchou se pro účely tohoto článku Podmínek rozumí stav, kdy Služba BBO není dostupná v důsledku úplného výpadku Služby BBO zaviněného Poskytovatelem. Výpočet dosažené dostupnosti Virtuálního serveru probíhá následovně:
6.4. Garantovaná dostupnost Konektivity činí 99,95 % měsíčně, přičemž dostupností Konektivity se pro účely těchto Podmínek rozumí, že Konektivita není v důsledku zaviněného porušení povinností Poskytovatele ve stavu poruchy, tzn. Virtuální server odpovídá na ICMP dotazy. O poruchu Konektivity se nejedná, pokud Virtuální server neodpovídá na ICMP dotazy v důsledku
6.4.1. blokování monitoringu serveru ze strany Uživatele (např. blokování prostřednictvím firewallu nebo Uživatel nepovolí odpovědi na ICMP), a/nebo
6.4.2. v důsledku toho, že byl Virtuální server Uživatelem vypnut/restartován, následkem čehož neběžel operační systém.
Výpočet poruchy Konektivity probíhá následovně:
6.5. Za poruchu ve smyslu těchto Podmínek není považována předem oznámená Odstávka. Doba Odstávek není započítávána do výpočtu dosažené dostupnosti Služby BBO dle čl. 6.3 ani 6.4 Podmínek.
6.6. Při poruše je Poskytovatel povinen okamžitě zajistit její odstranění tak, aby byla doba trvání poruchy co nejkratší. Při odstraňování poruch bude Poskytovatel a Uživatel organizovat nezbytnou součinnost mezi Uživatelem a servisní skupinou Poskytovatele.
6.7. Poskytovatel se zavazuje informovat Uživatele vhodným způsobem (například prostřednictvím elektronické pošty) předem nebo bez zbytečného odkladu o nepravidelnostech v poskytování Služby BBO nebo nedodržení sjednaných vlastností Služby BBO, nejméně v rozsahu podle zákona (např. § 377 Obchodního zákoníku). Poskytovatel je povinen uvědomit Uživatele o jakýchkoliv plánových Odstávkách, které by mohly dočasně přerušit nebo omezit provoz Služby BBO.
6.8. K ohlášení poruch udržuje Poskytovatel telefonickou a/nebo e-mailovou podporu. Kontakty jsou uvedeny na Webových stránkách Poskytovatele.
6.9. Poskytovatel neodpovídá za vznik poruch nebo jiných závad nebo nefunkčností, došlo-li k těmto stavům
6.9.1. v důsledku kterékoliv okolnosti uvedených v čl. 6.1, 6.2, 6.4.1 nebo 6.4.2 Podmínek,
6.9.2. následkem neodborného nebo neoprávněného zacházení Uživatele (např. chybným zásahem do konfigurace síťového rozhranní, poškozením systémových souborů, apod.),
6.9.3. v důsledku vady IT infrastruktury Uživatele (např. nefunkčnost či vady datové sítě nebo programového vybavení Uživatele), popř. v důsledku vady nebo nedostupnosti služeb třetích osob (např. nefunkčnost veřejné datové sítě).
6.10. Doba poruch zapříčiněných kteroukoliv z okolností uvedených v čl. 6.9 Podmínek není započítávána do výpočtu dosažené dostupnosti Služby BBO dle čl. 6.3 ani 6.4 Podmínek.
6.11. Není-li v příslušném měsíci dosažena garantovaná dostupnost Služby BBO v důsledku poruchy zaviněné Poskytovatelem, náleží Uživateli za každou započatou hodinu trvání poruchy v poskytování Služby BBO náhradní Kredit na poskytování Služby BBO ve výši 10% z průměrné měsíční výše ceny zaplacené Uživatelem Poskytovateli za období od uzavření Smlouvy do konce kalendářního měsíce předcházejícího kalendářnímu měsíci, kdy došlo ke vzniku nároku na poskytnutí náhradního Kreditu, maximálně však do výše průměrného měsíčního Kreditu. Náhradní Kredit bude Uživateli poskytnut na základě písemné reklamace zaslané Uživatelem elektronickou poštou s tím, že v takové žádosti musí Uživatel specifikovat, kdy došlo k poruše (poruchám) Služby BBO zakládajícím nárok na poskytnutí náhradního Kreditu. Náhradní Kredit má povahu slevy z ceny.
6.12. V případě, že k přerušení v poskytování Služby BBO došlo z důvodů na straně Uživatele, zavazuje se Uživatel uhradit Poskytovateli náklady na odstranění tohoto přerušení. V jiných případech nese náklady spojené s odstraňováním přerušení v poskytování Služby BBO Poskytovatel.
6.13. Poskytovatel je oprávněn používat obchodní firmu, název či jméno Uživatele pro marketingové účely jako tzv. reference, a to ve všech druzích propagačních materiálů (bez ohledu na formu těchto propagačních materiálů či formu, kterou jsou sdělovány).
7. Práva a povinnosti Uživatele
7.1. Práva Uživatele
7.1.1. Uživatel je oprávněn umožnit užití Služby BBO také třetím osobám. Uživatel se zavazuje zajistit, že třetí osoba, které Uživatel umožnil užití Služby BBO, bude při využívání Služby BBO dodržovat povinnosti Uživatele vyplývající ze Smlouvy a z obecně závazných právních předpisů, přičemž za porušení těchto povinností odpovídá Uživatel Poskytovateli, jako by je porušil sám. V případě, že tato třetí osoba způsobí Poskytovateli škodu, zavazuje se Uživatel tuto škodu poskytovateli nahradit.
7.1.2. Uživatel odpovídá za uhrazení ceny ve stanoveném termínu a v účtované výši, a to i v případě, že označil za plátce jinou osobu.
7.2. Povinnosti Uživatele při užívání Služby BBO
7.2.1. Uživatel nesmí při využívání Služeb BBO zasahovat do systému Poskytovatele jiným, než dohodnutým způsobem.
7.2.2. Přístup ke Službě BBO je zabezpečen uživatelským jménem a heslem. Uživatel je povinen zachovávat mlčenlivost ohledně informací nezbytných k přístupu k Službě BBO.
7.2.3. Uživatel nesmí využít Službu BBO k přenosu informací, jejichž obsah by byl v rozporu s dobrými mravy nebo právními předpisy, obecně závaznými v České republice a EU, popř. s právními řády dalších států, ve kterých budou data přístupná, a s předpisy mezinárodního práva.
7.2.4. Uživatel nesmí generovat neúměrnou zátěž sítě elektronických komunikací.
7.2.5. Uživatel nesmí v rámci Služby BBO ukládat informace, jež nápadně připomínají služby nebo aplikace třetích osob, za účelem zmatení či uvedení v omyl uživatelů internetu (phishing).
7.2.6. Uživatel nesmí v rámci Služby BBO šířit počítačové viry.
7.2.7. Uživatel dále nesmí
7.2.7.1. rozesílat prostřednictvím Služby BBO nevyžádaná obchodní sdělení (spam) ve smyslu zákona č. 480/2004 Sb., o některých službách informační společnosti;
7.2.7.2. používat a šířit nástroje, které by ohrožovaly servery Poskytovatele nebo bezpečnost sítě internet;
7.2.7.3. provádět na serverech Poskytovatele zátěžové testy nebo spouštět skripty, které by mohly způsobit zpomalení či znepřístupnění některých služeb serveru Poskytovatele.
7.2.8. Uživatel nesmí při využívání Služby BBO používat mechanismy, nástroje, programové vybavení nebo postupy, které mají nebo by mohly mít negativní vliv na provoz zařízení Poskytovatele, bezpečnost Internetu či uživatelů Internetu. Uživatel nesmí Službu BBO využívat tím způsobem, který by mohl vést k přetížení Internetu nebo datové sítě Poskytovatele, mající za následek snížení rychlosti přenosu dat nebo částečný nebo úplný výpadek těchto sítí. Webovou stránku, Uživatelský účet a Službu BBO je možné využívat jen v souladu s jejich určením a v rozsahu, který je smluvený a který není na úkor práv ostatních Uživatelů.
7.2.9. Uživatel zejména nesmí:
7.2.9.1. měnit MAC adresu síťových rozhraní, přičemž Uživatel smí používat pouze jemu přidělenou IP adresu/adresy;
7.2.9.2. provozovat DHCP server;
7.2.9.3. jakkoli zasahovat do činnosti hypervizoru spravujícího virtuální servery, zejména pokoušet se o změnu omezení Služby BBO (jemu přidělených systémových prostředků) nebo se pokoušet tato omezení (limity) překračovat;
7.2.9.4. počínat si tak, že by došlo k porušování licenčních podmínek u počítačových programů provozovaných na Virtuálním serveru, včetně licenčních podmínek operačního systému;
7.2.9.5. odinstalovávat paravirtualizované ovladače z předinstalovaného operačního systému
7.2.9.6. mít v rámci Služby BBO nekorektně spuštěnou a nenainstalovanou aplikaci VMware Tools.
7.3. Odpovědnost za obsah
7.3.1. Poskytovatel tímto zdůrazňuje, že se žádným způsobem nepodílí na tvorbě obsahu internetových stránek, aplikací Uživatele ani jiného obsahu provozovaného Uživatelem v rámci Služby BBO a není povinen dohlížet na obsah informací ukládaných na jeho serverech Uživatelem a není rovněž povinen vyhledávat skutečnosti a okolnosti poukazující na protiprávní obsah takových informací. Dozví-li se Poskytovatel o protiprávní povaze obsahu uloženého Uživatelem prostřednictvím Služby BBO, neprodleně pozastaví poskytování Služby BBO, popř. protiprávní obsah odstraní (čl. 7.4 Podmínek).
7.3.2. Uživatel je povinen zajistit nezávadnost obsahu provozovaného v rámci Služby BBO. Protiprávním obsahem se pro účely těchto Podmínek rozumí zejména obsah,
7.3.2.1. kterým dochází k šíření pornografie, zejména pak sexuálních praktik, které naplňují skutkovou podstatu trestného činu šíření pornografie (např. dětská pornografie, zoofilie);
7.3.2.2. kterým by byla naplněna skutková podstata trestného činu nebo kterým by došlo k porušení autorských práv (např. provozování download serverů, warez, gamez, crack servery, zpřístupnění či rozšiřování nelegálních MP3, zpřístupnění či rozšiřování fotografií a jiných děl užitých bez souhlasu autora) či průmyslových práv (např. ochranná známka) nebo který by k takovému porušení nabádal či napomáhal;
7.3.2.3. který napomáhá nebo nabádá k obcházení technických prostředků ochrany autorských práv;
7.3.2.4. kterým se dopouští podněcování či schvalování trestné činnosti, hanobení národa, etnické skupiny, rasy a přesvědčení nebo propagace hnutí směřujících k potlačení práv a svobod člověka, zejména formou šíření názorů extrémní pravice či extrémní levice;
7.3.2.5. kterým je protiprávně zasahováno do osobnostních práv třetích fyzických osob či do dobré pověsti právnické osoby;
7.3.2.6. prostřednictvím kterého se Uživatel dopouští nekalosoutěžního jednání;
7.3.2.7. kterým dochází k šíření či propagaci jakýchkoliv dalších nezákonných či trestněprávních aktivit.
7.3.3. Uživatel bere na vědomí, že Poskytovatel nenese odpovědnost za obsah informací ukládaných Uživatelem v rámci Služby BBO. Uživatel bere dále na vědomí, že Poskytovatel neodpovídá za protiprávní úkony Uživatele učiněné v rámci Služby BBO (např. porušení práv k ochranným známkám, práv k obchodní firmě/názvu), ovšem může být povinen odstranit protiprávní obsah uložený Uživatelem či jinými osobami v souvislosti se Službou BBO, dozví-li se o jeho protiprávnosti.
7.4. Právo Poskytovatele pozastavit poskytování Služby BBO
7.4.1. V případě, že aplikace Uživatele, kterou provozuje Uživatel v rámci Služby BBO, vykazuje technickou vadu (např. chybu v kódu) a Uživatel je na tuto vadu Poskytovatelem upozorněn, je Uživatel povinen tuto vadu neprodleně odstranit, a to nejdéle do 24 hodin od doručení oznámení. Není-li Uživatel schopen v této lhůtě odstranit vadu, je povinen odstranit celou aplikaci obsahující vadu. Nedojde-li ze strany Uživatele k nápravě, je poskytovatel oprávněn pozastavit poskytování Služby BBO Uživateli, a to až do doby odstranění vady. V případě, že aplikace Uživatele, kterou provozuje Uživatel v rámci Služby BBO, vykazuje technickou vadu (např. chybu v kódu), která způsobuje přetížení serveru Poskytovatele nebo jinou abnormalitu v chodu serveru Poskytovatele, je poskytovatel oprávněn ihned pozastavit poskytování Služby BBO Uživateli, a to až do doby odstranění této vady.
7.4.2. Poskytovatel je dále oprávněn pozastavit poskytování Služby BBO, jakmile se dozví o protiprávním obsahu ve smyslu čl. 7.3.2 Podmínek, který je Uživatelem uložen či provozován v rámci Služby BBO. Poskytovatel je následně povinen svůj postup Uživateli odůvodnit a uvést, z jakého zdroje se dozvěděl o protiprávnosti obsahu Uživatele.
7.4.3. Pozastavení Služby BBO Poskytovatelem dle čl. 7.4.1 nebo 7.4.2 Podmínek není poruchou či vadou Služby BBO, ani se nepovažuje za Odstávku; doba pozastavení Služby BBO není započítávána do výpočtu doby dostupnosti Služby BBO dle čl. 6.3 ani 6.4 Podmínek.
7.4.4. Poskytovatel neodpovídá za škodu způsobenou pozastavením Služby BBO (a znepřístupněním přístupu Uživatele k datům uloženým prostřednictvím Služby BBO) z důvodu uvedeného v čl. 7.4.1 Podmínek, popř. z důvodu zjištěného nebo ohlášeného protiprávního obsahu ve smyslu čl. 7.4.2 Podmínek, a to ani v případě, kdy Uživatel prokáže, že obsah uložený či provozovaný v rámci Služby BBO nebyl protiprávní (předložením rozhodnutí soudu či jiného státního orgánu nebo dohody s osobou, která původně tvrdila, že je obsah závadný).
7.5. Autorská práva
7.5.1. Uživatel bere na vědomí, že počítačové programy tvořící Webovou stránku jsou chráněny autorským právem. Uživatel se zavazuje, že nebude vykonávat žádnou činnost, která by mohla jemu nebo třetím osobám umožnit neoprávněně zasahovat či užívat počítačové programy, k nimž je vykonavatelem majetkových práv či oprávněným uživatelem Poskytovatel.
7.6. Odpovědnost Uživatele za škodu
7.6.1. Uživatel odpovídá v plném rozsahu za škodu způsobenou Poskytovateli v souvislosti s umístěním protiprávního obsahu na servery Poskytovatele nebo porušením jiných povinností uvedených ve Smlouvě nebo těchto Podmínkách.
7.6.2. V případě nároků třetích osob vzniklých v souvislosti s umístěním protiprávního obsahu je Uživatel povinen tyto nároky na vlastní náklady vypořádat, včetně případných nároků uplatněných v této souvislosti třetími osobami vůči Poskytovateli.
7.7. Sankční ujednání
7.7.1. V případě, že Uživatel poruší kteroukoliv z povinností stanovených shora v čl. 7.2 nebo 7.3.2, těchto Podmínek, vzniká Poskytovateli nárok na smluvní pokutu ve výši 10.000,- Kč za každé jednotlivé porušení povinností. Tímto není dotčen nárok na náhradu případné škody vzniklé porušením povinnosti, na kterou se vztahuje smluvní pokuta, ani ostatní nároky Poskytovatele (např. na pozastavení Služby BBO dle čl. 7.4 Podmínek).
7.7.2. Smluvní pokuta je splatná na základě písemné výzvy (též ve formě e-mailu zaslaného na Adresu Uživatele) k úhradě smluvní pokuty, a to do 15 dnů ode dne doručení výzvy Uživateli. Poskytovatel je povinen ve výzvě uvést důvod vzniku nároku na smluvní pokutu.
7.7.3. Nárok na zaplacení smluvní pokuty je Poskytovatel oprávněn odečíst z Kreditu Uživatele (čl. 9 Podmínek). Nebylo-li možné nárok Poskytovatele na smluvní pokutu zcela uspokojit z Kreditu Uživatele, je smluvní pokuta či její zbývající část splatná na výzvu Poskytovatele, a to bezhotovostně na bankovní účet Poskytovatele.
8. Cena
8.1. Za poskytování Služby BBO náleží Poskytovateli denní cena ve výši uvedených dále v čl. 8.2. Cena je odečítána z Kreditu Uživatele (započítává se na něj) způsobem a za podmínek uvedených níže.
8.2. Cena se sjednává jako trojsložková, sestávající
8.2.1. z ceny za pronájem Hardwarových prostředků, Datových přenosů a Software, která je stanovena na základě aktuálního Ceníku,
8.2.2. z paušální ceny za provoz Služby BBO, která zahrnuje provozní náklady Poskytovatele spojené se zajišťováním provozu infrastruktury nezbytné k poskytování Služby BBO, zajištění uživatelské podpory a náklady případných dalších dílčích služeb,
8.2.3. z ceny za Konektivitu, která je stanovena na základě aktuálního Ceníku.
8.3. Cena dílčích služeb uvedených v čl. 8.2.1 a 8.2.2 je stanovena v závislosti na nastavení parametrů Služby BBO Uživatelem prostřednictvím Cenové kalkulačky, a to během vyplňování Žádosti o registraci, popř. později prostřednictvím Uživatelského účtu. Jednotkové ceny za dílčí služby či licence uvedené shora v čl. 8.2.1 a 8.2.3 jsou uvedené v Ceníku. Paušální cena za provoz Služby BBO není stanovena jako jednotková cena a není součástí Ceníku.
8.4. Nárok na cenu za pronájem Hardwarových prostředků vzniká Poskytovateli za každou započatou minutu čerpání Služby BBO. V případě, že k započetí využívání Hardwarového prostředku Uživatelem dojde v průběhu kalendářního měsíce, náleží Poskytovateli cena stanovená poměrně (podle počtu hodin zbývající do konce období).
8.5. Za zajištění datových přenosů nad rámec maximálního objemu datových přenosů náleží Poskytovateli cena ve výši stanovené v Cenové kalkulačce Poskytovatele, jež je určena v závislosti na Uživatelem realizovaném objemu datových přenosů.
8.6. Objedná-li si Uživatel Software (zejména software Microsoft), který Poskytovatel poskytuje v rámci Služby BBO za úplatu, je v ceně dle čl. 8.2.1 zahrnuta odměna za takový Software vždy za celý kalendářní měsíc. Nárok na odměnu za poskytnutí licence k Software za kalendářní měsíc vzniká Poskytovateli vždy 00:01 hodin prvního kalendářního dne měsíce, za který je odměna placena. V případě, že k započetí či k ukončení využívání Software Uživatelem dojde v průběhu kalendářního měsíce, nemá tato skutečnost vliv na výši odměny Poskytovatele za poskytnutí licence k Software za tento kalendářní měsíc (Poskytovateli náleží plná měsíční odměna za poskytnutí licence k Software za tento kalendářní měsíc). Pro účely tohoto článku je rozhodující středoevropský čas (GMT +1:00). Tímto článkem není dotčeno ustanovení čl. 8.7 Podmínek.
8.7. Odměna Poskytovatele za poskytnutí licence k Software nazvanému „Microsoft Windows 2008 Server Datacenter“, je zahrnuta v rámci ceny dle čl. 8.2.1 stanovené prostřednictvím Cenové kalkulačky.
8.8. Ceny za Službu BBO jsou uvedeny vždy bez DPH. K cenám se připočítává DPH dle platných právních předpisů. Výše kreditu je Uživateli po zaplacení připočtena ve výši po odečtení DPH.
8.9. Případné slevy z ceny za Služby BBO poskytnuté Poskytovatelem Uživateli jsou jednorázové a nelze je přenášet na další období či je vzájemně kombinovat.
8.10. Na pohledávku Poskytovatele na uhrazení Kreditu či na zaplacení ceny není Uživatel oprávněn provést započtení pohledávky za Poskytovatelem, jíž je Uživatel věřitelem, a to ani částečně.
8.11. Poskytovatel je oprávněn jednostranně změnit ceny dílčích služeb uvedené v Ceníku, popř. vybrané jednotkové ceny tam uvedené. V takovém případě se Poskytovatel zavazuje minimálně jeden měsíc předem písemně informovat Uživatele o skutečnosti, že Ceník Služby BBO bude změněn a současně zveřejnit na internetových stránkách https://online.bigblueone.cz pozměněný Ceník a uvést, od kdy je nová verze Cenku účinná. Uživatel je v takovém případě oprávněn vypovědět Smlouvu způsobem a ve lhůtě dle čl. 13.3.2 Podmínek. Za dostatečnou informaci Uživatele o chystaných změnách Ceníku se považuje rovněž zveřejnění této informace prostřednictvím Uživatelského účtu. Počínaje dnem účinnosti pozměněné verze Ceníku Služby BBO vzniká Poskytovateli nárok účtovat si za Služby BBO cenu, která je zvýšená popř. snížená v souladu s pozměněnou verzí Ceníku, a to i v případě změn ceny dílčích služeb či licencí uvedených v čl. 8.2.1 popř. 8.2.2 Podmínek.
8.12. Uživatel potvrzuje souhlas se zněním aktuální verze Ceníku pokaždé, když se přihlásí ke svému Uživatelskému účtu. Neakceptuje-li změnu Ceníku a nevypoví-li Smlouvu, je Poskytovatel oprávněn Smlouvu vypovědět způsobem uvedeným v čl. 13.3.3 Podmínek.
9. Kredit a vyúčtování Služby BBO
9.1. Cena Služby BBO je Uživatelem hrazena ve formě předplatného hrazeného ve formě Kreditu. Poskytovatel průběžně v rámci Uživatelského rozhraní vyúčtovává cenu za užívání Služby BBO, přičemž Uživatel má v Uživatelském rozhraní rozpis jednotlivých vyúčtovaných služeb či transakcí, které mu byly ze strany Poskytovatele poskytnuty. Aktuální zůstatek předplatného je dále uváděn jako „Výše kreditu“.
9.2. Kredit lze hradit:
9.2.1. převodem na bankovní účet poskytovatele;
9.2.2. prostřednictvím platební a kartové brány „PayU“, provozované společností PayU Czech Republic s.r.o.;
9.2.3. prostřednictvím platebního systému „PayPal“ provozovaného společností PayPal (Europe) S.à r.l. & Cie, S.C.A.
9.3. Přesné údaje týkající se platby převodem na účet (zejména číslo účtu a variabilní symbol platby) obdrží Uživatel písemně na Adresu Uživatele. Uživatel je povinen hradit platby v souladu s pokyny Poskytovatele. V případě, že Uživatel uvede chybný variabilní symbol platby, variabilní symbol platby neuvede či uhradí částku v jiné výši, než je povinen, náleží Poskytovateli poplatek ve výši 100,- Kč (slovy: sto korun českých) jako úhrada nákladů spojených s vyřizováním těchto plateb, a to za každý takovýto případ.
9.4. Uživatel je oprávněn začít čerpat Službu BBO až po uhrazení Kreditu, tzn. Poskytovatel není povinen započít s plněním svých závazků ze Smlouvy dříve, než je Kredit řádně uhrazen. Možnost čerpání Služby BBO může být Poskytovatelem pozastavena nebo odložena, až do okamžiku, kdy je částka Kreditu skutečně připsána na účet Poskytovatele. V případě, že je Kredit hrazen prostřednictvím platební karty a částka nebude fakticky připsána na účet Poskytovatele, je Uživatel povinen Kredit uhradit neprodleně (k čemuž může být Poskytovatelem vyzván), nejpozději však do sedmi (7) dnů od objednání Kreditu prostřednictvím platební karty v rámci Uživatelského účtu. V případě, že k uhrazení Kreditu Uživatelem podle předchozí věty nedojde, bude Kredit, který nebyl zaplacen, Uživateli odečten a Poskytovatel je oprávněn Smlouvu vypovědět nebo od ní bez dalšího odstoupit. Tímto není dotčen nárok Poskytovatele na úhradu ceny, na kterou mu vzniknul nárok na základě Smlouvy (čl. 8 Podmínek).
9.5. Minimální Výši kreditu se rozumí částka rovnající se ceně Poskytovatele za zajištění Služby BBO dle nastavení provedeného Uživatelem v Uživatelském účtu po dobu jednoho (1) dne.
9.6. Daňový doklad - fakturu zašle Poskytovatel v elektronické podobě na Adresu uživatele, a to vždy až poté, kdy je částka Kreditu skutečně připsána na účet Poskytovatele.
9.7. Nevyčerpá-li Uživatel předplacený Kredit uhrazený na základě Smlouvy, která již zanikla (např. v důsledku výpovědi), je Uživatel oprávněn požádat o vrácení zbývajícího Kreditu, a to ve lhůtě 14 dnů od zániku Smlouvy. Toto neplatí pro Kredit poskytnutý Uživateli pro testování Služby BBO nebo pro Kredit, který Uživatel obdržel jako bezplatný bonus.
10. Minimální Výše kreditu
10.1. V případě, že systém Poskytovatele zaznamená takový pokles Výše kreditu, kdy je zřejmé, že Kredit bude v nejbližších sedmi (7) dnech vyčerpán, zašle Poskytovatel na Adresu uživatele (tzn. elektronicky ve formě e-mailu) upozornění na vzniklý stav. Není-li Kredit uhrazen ani jeden den přede dnem, kdy je zřejmé, že Výše kreditu poklesne pod Minimální výši kreditu, zašle Poskytovatel opakované upozornění na Adresu Uživatele a kromě toho zašle upozornění rovněž na číslo mobilního telefonu, který má Uživatel uveden ve svém Uživatelském účtu.
10.2. V případě, že Výše kreditu klesne pod minimální Výši kreditu, dojde k automatickému omezení Služby BBO tím způsobem, že Hardwarové prostředky (kromě pevného disku), Datové přenosy a Software nebude možné ze strany Uživatele využívat. Po doplnění (uhrazení) Kreditu Uživatelem, tedy po uhrazení Kreditu alespoň v takové výši, aby Výše kreditu dostačovala na úhradu ceny Poskytovatele za zajišťování Služby BBO po dobu jednoho (1) dne (pro tento účel se vychází z ceny Služby BBO stanovené v závislosti na posledním nastavení parametrů Služby BBO Uživatelem prostřednictvím Cenové kalkulačky), dojde k obnovení Služby BBO.
10.3. V případě, že je Kredit Uživatele zcela vyčerpán, dojde prvního (1) kalendářního dne následujícího po dni, kdy došlo k vyčerpání základní Výše kreditu, k automatickému pozastavení Služby BBO a do sedmi dnů dojde ke smazání dat uložených v rámci Služby BBO Uživatelem, což bere Uživatel na vědomí a souhlasí s tím.
10.4. Uživatel bere na vědomí, že v případě bezhotovostní platby na účet Poskytovatele je Uživatel povinen zadat správný variabilní symbol. Poskytovatel neodpovídá za škody způsobené Uživateli v důsledku automatického pozastavení Služby BBO, a to ani v případě, kdy Uživatel doplní (uhradí) Kredit na základě výzvy dle čl. 10.1 Podmínek včas, avšak zadá špatný variabilní symbol.
10.5. Uživatel bere na vědomí, že odpovídá za úhradu ceny – Kreditu ve stanoveném termínu, a to i v případě, že označil za plátce jinou osobu.
11. Odpovědnost za vady, reklamace
11.1. Práva a povinnosti smluvních stran ohledně odpovědnosti Poskytovatele za vady Služeb BBO se řídí příslušnými obecně závaznými právními předpisy. Uživatel má právo uplatnit reklamaci vyúčtování Služby BBO nebo neposkytnutí výkonu v dohodnutém množství, kvalitě, rozsahu a ceně v zákaznickém oddělení Poskytovatele bez zbytečného odkladu, nejpozději do 2 měsíců od doručení vyúčtování ceny za poskytnutou Službu BBO. Po uplynutí této doby právo uplatnit reklamaci zaniká. Podání reklamace nemá odkladný účinek vůči splnění povinnosti uhradit sjednanou cenu za poskytování Služby BBO; Poskytovatel je přes podání reklamace oprávněn čerpat z Kreditu uhrazeného Uživatelem.
11.2. V případě, že dojde k chybnému vyúčtování platby Uživatele, má Uživatel právo na reklamaci vyúčtované ceny. Takovouto reklamaci platby vyřídí Poskytovatel bez zbytečného odkladu, nejpozději však do 30 dnů a o výsledku reklamace vyrozumí Uživatele ve formě písemného vyjádření zaslaného na Adresu uživatele.
11.3. V případě, že má Uživatel právo na vrácení přeplatků cen, je Poskytovatel povinen příslušnou částku zúčtovat ve prospěch Uživatele v nejbližším vyúčtování poplatků za Službu BBO.
11.4. Námitku proti vyřízení reklamace může Uživatel vznést u Českého telekomunikačního úřadu (místně příslušného oblastního odboru), jehož adresu je Poskytovatel povinen uvést ve sdělení Účastníkovi o negativním vyřízení reklamace.
11.5. Reklamaci na poskytovanou Službu BBO je Uživatel oprávněn uplatnit bez zbytečného odkladu, nejpozději do 2 měsíců ode dne vadného poskytnutí služby, jinak právo zanikne. V případě uznání reklamace a přiznání přiměřené slevy z ceny je Poskytovatel oprávněn takovou slevu poskytnout způsobem uvedeným v čl. 11.3 Podmínek.
11.6. Uživatel bere na vědomí, že Poskytovatel nenese odpovědnost za vady, výpadky či omezení Služby BBO vzniklé v důsledku zásahů třetích osob do Uživatelského účtu nebo v důsledku užití Uživatelského účtu či Služby BBO v rozporu s jejich sjednaným nebo obvyklým použitím. Poskytovatel dále neodpovídá za vady, výpadky či omezení Služby BBO vzniklé v důsledku chování Uživatele popsaného v čl. 6.9 Podmínek.
11.7. Uživatel dále bere na vědomí, že není-li smluveno jinak, Poskytovatel nenese odpovědnost za funkčnost datové sítě Uživatele, funkčnost veřejné datové sítě, za stav programového vybavení Uživatele a za případné zásahy třetích osob do programového vybavení Uživatele.
11.8. Není-li smluveno jinak, neprovádí Poskytovatel archivaci dat Uživatele a není odpovědný za škody způsobené případnou ztrátou nebo poškození dat Uživatele.
11.9. V případě vzniku škody na straně Uživatele v souvislosti s odpovědností Poskytovatele za vady Služeb BBO si smluvní strany dohodly s ohledem na podmínky Smlouvy omezení náhrady této případné škody vzniklé Uživateli tak, že celková náhrada škody je omezena výší 10.000,- Kč (slovy: deset tisíc korun českých) včetně ušlého zisku.
11.10. Poskytovatel dále není povinen nahradit Uživateli škodu, jež převyšuje škodu, kterou v době vzniku Smlouvy mohl Poskytovatel předvídat jako možný důsledek porušení svých povinností ze Smlouvy, např. umožní-li Uživatel užití Služby BBO třetí osobě, popř. zpracovává-li za využití Služby BBO data třetích osob, jejichž poškození nebo ztráta jsou způsobilé způsobit značné škody a Poskytovatel nebyl informován o povaze těchto dat ani o osobách, pro které Uživatel taková data zpracovává.
12. Ochrana informací, osobních údajů a další práva a povinnosti smluvních stran
12.1. Ochrana osobních údajů
12.1.1. Smluvní vztah o poskytování Služby BBO je spojen se shromažďováním, zpracováním, uchováním a zpřístupňováním informací o Uživateli (dále jen „Informace“). Ochrana Informací je vymezena zejména těmito zákony:
č. 101/2000 Sb., o ochraně osobních údajů, ve vztahu k získaným osobním údajům vyplývajících ze smluvního vztahu;
č. 127/2005 Sb., o elektronických komunikacích předpisy souvisejícími, ve vztahu ke jménům, adresám a číslům komunikujících stran a obsahu zpráv přenášených elektronickými komunikačními zařízeními a sítěmi (§ 87 a násl. tohoto zákona);
č. 89/1995 Sb., o státní statistické službě ve vztahu k činnosti jiných subjektů v sítích elektronických komunikací a jejich statistickému zjišťování;
č. 480/2004 Sb., o některých službách informační společnosti.
12.1.2. Uzavřením Smlouvy vyjadřuje Uživatel souhlas se zpracováním svých osobních údajů. Uživatel je oprávněn zadávat při registraci popř. pozdějších změnách registračních údajů kontaktní a osobní údaje fyzických osob (především zaměstnanců) pouze s jejich výslovným souhlasem.
12.1.3. Poskytovatel zpracovává a užívá kontaktních údajů Uživatelů výlučně za účelem komunikace s Uživatelem popř. za účelem zasílání obchodních sdělení za podmínek uvedených dále v čl. 12.4 Podmínek, tyto údaje nejsou zpřístupňovány ani poskytovány třetím osobám, s výjimkou případů, kdy to bude nezbytné ke splnění zákonné povinnosti.
12.1.4. Osobní údaje budou zpracovávány po dobu trvání Smlouvy, popř. do doby úplného vypořádání všech práv a povinností ze Smlouvy. Osobní údaje budou zpracovávány v elektronické podobě automatizovaným způsobem nebo v tištěné podobě neautomatizovaným způsobem.
12.1.5. Poskytovatel neshromažďuje o Uživateli resp. kontaktních osobách identifikovaných v rámci Uživatelského účtu žádné citlivé údaje ve smyslu zákona č. 101/2000 Sb., o ochraně osobních údajů.
12.1.6. Každý subjekt údajů má právo požádat Poskytovatele o vysvětlení, popř. požadovat odstranění osobních údajů z databází a systémů Poskytovatele, pokud má za to, že Poskytovatel zpracovává jeho osobní údaje v rozporu se Smlouvou (je-li zároveň Uživatelem) či právními předpisy. Poskytovatel vyřídí žádost subjektu údajů ve lhůtě 30 dnů ode dne jejího doručení.
12.1.7. Uživatel se shora uvedeným zpracováním osobních údajů zadaných jím při registraci souhlasí a je povinen zajistit souhlas kontaktních osob, které při registraci uvedl.
12.1.8. Poskytovatel je registrován jako správce dat u Úřadu pro ochranu osobních údajů pod registračním číslem: 00033605.
12.1.9. Nesjednají-li Poskytovatel a Uživatel výslovně na základě zvláštní písemné smlouvy, nezpracovává Poskytovatel pro Uživatele osobní údaje třetích osob.
12.2. Zásady nakládání s Informacemi
12.2.1. Při shromažďování dat, jejich zpracování, ukládání do údajové základny, zveřejňování, ochraně, zabezpečení přenosu dat, archivování a skartaci včetně procesu výmazu Informací v elektronické formě postupuje Poskytovatel ve smyslu zásad uvedených níže v tomto čl. 12.2 Podmínek.
12.2.2. Poskytovatel přijal náležitá technicko–organizační opatření za účelem zabránit neoprávněnému nebo nahodilému přístupu k Informacím.
12.2.3. V rámci organizačních opatření Poskytovatel disponuje mj. certifikací ISO 27000 a implementoval vnitřní procesy a pravidla nakládání s Informacemi a daty uloženými v rámci Služby BBO. Poskytovatel dále zavazuje vlastní zaměstnance povinností mlčenlivosti. Využívá-li Poskytovatel v rámci poskytování Služby BBO služeb třetích osob, ověřuje, jakým způsobem jsou u těchto třetích osob aplikována technicko-organizační opatření.
12.2.4. Poskytovatel dále při poskytování Služby BBO využívá taková technická opatření, aby byla ochrana Informací a dat uložených v rámci Služby BBO v souladu s aktuálním stavem technických znalostí.
12.2.5. Poskytovatel seznamuje s technicko-organizačními opatřeními své zaměstnance a provádí pravidelná školení.
12.2.6. Poskytovatel se v souvislosti s nakládáním s Informacemi zavazuje
12.2.6.1. využívat dat, získaných v rámci poskytování Služby BBO a provozovat systém takto získaných Informací pouze k účelu, pro který byly získány,
12.2.6.2. soustřeďovat data přiměřeně účelu, neshromažďovat nadbytečné údaje; je zakázáno získávat Informace pod tímto krytím k jiným účelům,
12.2.6.3. zajistit archivování, skartaci a proces výmazu v elektronické formě v souladu se zákonem č. 499/2004 Sb., o archivnictví a předpisů souvisejících
12.2.6.4. učinit opatření, aby po skončení pracovního nebo i obdobného poměru mezi fyzickou osobou a Poskytovatelem nemohly být Informace touto osobou využity
12.2.6.5. uchovávat Informace pouze po dobu nezbytně nutnou
12.2.7. Uživatel může sám přijmout svá opatření k ochraně a utajení svých přenášených dat, například šifrováním nebo kódováním. Musí to však učinit způsobem kompatibilním s komunikačním systémem Poskytovatele.
12.2.8. Poskytovatel neručí za újmu na celistvosti a důvěrnosti přenášených dat, pokud k ní dojde mimo jeho systém, nebo poruchou mimo jeho systém. Neručí rovněž za případné škody, vzniklé Uživateli omezením, znemožněním nebo zrušením přístupu.
12.2.9. Uzavřením Smlouvy dává Uživatel souhlas s tím, aby Poskytovatel v souvislosti se Smlouvou vedl o fyzických nebo právnických osobách Informace při zachování podmínek podle článků 12.1 a 12.2 Podmínek.
12.2.10. Uživatel potvrzuje, že poskytnuté osobní údaje jsou přesné a že byl poučen o tom, že se jedná o dobrovolné poskytnutí osobních údajů. Uživatel prohlašuje, že byl poučen o tom, že souhlas se zpracováním osobních údajů může ve vztahu k Poskytovateli odvolat písemným oznámením doručeným na adresu Poskytovatele. V takovém případě je Poskytovatel oprávněn vypovědět Smlouvu způsobem uvedeným v čl. 13.3.3 Podmínek.
12.3. Data Uživatele a povinnost mlčenlivosti
12.3.1. Data Uživatele budou umístěna zejména v datovém centru Poskytovatele v lokalitě Vinohradská 184, Praha 3. Poskytovatel se zavazuje veškerá data Uživatele umisťovat pouze na serverech umístěných v Evropské unii nebo v zemích, zajišťující ochranu osobních údajů způsobem rovnocenným s ochranou zajišťovanou právními předpisy České republiky (tzv. safe harbor). Další povinnosti Poskytovatele vyplývající z příslušných právních předpisů na ochranu osobních údajů či jiných dat regulovaných právními předpisy, nejsou tímto ujednáním dotčeny.
12.3.2. Poskytovatel je oprávněn přistupovat v souvislosti s poskytováním Služby BBO dle této Smlouvy k databázím či datům, osobním nebo jiným údajům Uživatele pouze v takovém rozsahu a v takových případech, je-li toto nezbytně nutné k poskytování Služby BBO či odstranění poruch a závad.
12.3.3. Smluvní strany považují za důvěrné všechny Informace o druhé smluvní straně, které vyplývají či jsou známé v důsledku uzavření Smlouvy, nebo které získaly či získají v souvislosti s jejím uzavřením nebo plněním, a tyto Informace nesdělí třetí osobě bez písemného souhlasu druhé smluvní strany. Závazek mlčenlivosti platí i po zániku závazků ze Smlouvy, a to bez ohledu na právní skutečnost rozhodnou pro tento zánik. Porušením tohoto závazku není, poskytne-li kterákoli strana smlouvy Informace orgánům činným v trestním řízení či jinému orgánu, je-li pro to zákonný důvod, popř. tak stanoví rozhodnutí státního orgánu, které je v právní moci.
12.4. Obchodní sdělení
12.4.1. Poskytovatel je oprávněn zasílat ve formě e-mailu obchodní sdělení obsahující informace o novinkách ve Službách dle Smlouvy, ale rovněž o jiných službách Poskytovatele nebo o službách či produktech třetích osob. Tato obchodní sdělení je Poskytovatel oprávněn zasílat na Adresu Uživatele, který s tímto vyjadřuje souhlas uzavřením Smlouvy.
12.4.2. Uživatel je oprávněn kdykoliv zastavit zasílání obchodních sdělení, a to bezúplatně a bez jakýchkoliv sankcí.
12.4.3. Uživatel bere na vědomí a souhlasí s tím, že Poskytovatel je oprávněn zasílat ve formě e-mailu na Adresu uživatele rovněž informace technické povahy – tzv. technické aktuality (zejména upozornit jej na připravované Odstávky, na změny nastavení Uživatelského rozhraní, nutnost stáhnout si opravné patche software třetích osob apod.). Tyto informace technické povahy nejsou obchodním sdělením, slouží pouze k zachování všech funkcí Uživatelského účtu a zvýšení bezpečnosti jeho provozu popř. k informování o Odstávkách a Uživatel není oprávněn zasílání těchto informací technické povahy zamezit po dobu, po kterou trvá smluvní vztah založený Smlouvou. Po zániku Smlouvy Uživateli informace technické povahy zasílány nejsou.
13. Trvání smlouvy
13.1. Doba trvání smlouvy, účinnost
13.1.1. Smlouva nabývá účinnosti jejím uzavřením.
13.1.2. Není-li smluveno jinak, Smlouva je uzavřena na dobu neurčitou.
13.2. Zánik smlouvy
13.2.1. Smlouva zaniká
na základě výpovědi kterékoliv ze smluvních stran (tedy Poskytovatele nebo Uživatele);
odstoupením od Smlouvy
13.3. Výpověď
13.3.1. Kterákoliv smluvní strana (tj. Poskytovatel i Uživatel) může Smlouvu bez udání důvodu vypovědět. Výpověď je účinná okamžikem doručení druhé smluvní straně. Výpovědní lhůta činí 2 měsíce a začíná běžet prvního dne kalendářního měsíce následujícího po měsíci, v němž byla výpověď doručena.
13.3.2. Zveřejní-li Poskytovatel informaci o jednostranné změně Ceníku (čl. 8.11 Podmínek), popř. zveřejní-li Poskytovatel informaci o změně Podmínek (čl. 15.5 Podmínek), je Uživatel oprávněn vypovědět Smlouvu, přičemž výpovědní lhůta činí 15 dní a počíná běžet prvním dnem následujícím po dni, kdy byla výpověď doručena. Uživatel je oprávněn Smlouvu z důvodu změny Ceníku nebo Podmínek vypovědět pouze před nabytím účinnosti příslušných změn Ceníku nebo Podmínek, ledaže Poskytovatel nezveřejnil informaci o jednostranné změně Ceníku nebo Podmínek včas nebo způsobem uvedeným v těchto Podmínkách.
13.3.3. Odvolá-li Uživatel souhlas se zpracováním osobních údajů (čl. 12.2.10 Podmínek), popř. neakceptuje-li změnu Ceníku (čl. 8.11 Podmínek), popř. neakceptuje-li změnu Podmínek (čl. 15.5 Podmínek), je Poskytovatel oprávněn vypovědět Smlouvu, přičemž výpovědní lhůta činí 15 dní a počíná běžet prvním dnem následujícím po dni, kdy byla výpověď doručena.
13.4. Odstoupení Uživatele
13.4.1. Uživatel je oprávněn od Smlouvy odstoupit pouze pro podstatné porušení povinností Poskytovatele sjednaných ve Smlouvě nebo Podmínkách, popř. za podmínek uvedených níže v čl. 13.4.2 Podmínek.
13.4.2. S ohledem na to, že Služby BBO jsou Poskytovatelem aktivovány dnem, kdy je Uživatelem uhrazen Kredit, může Uživatel, který je v postavení spotřebitele ve smyslu § 52 odst. 3 občanského zákoníku, od Smlouvy odstoupit i bez udání důvodu ve lhůtě 14 dnů ode dne uzavření Smlouvy (§ 53 odst. 7 občanského zákoníku), pouze však do okamžiku zprovoznění Služby BBO (čl. 3.3 Podmínek). Jakmile je Služba BBO v souladu se Smlouvou aktivována, nemůže Uživatel – spotřebitel od Smlouvy odstoupit podle § 53 odst. 7 občanského zákoníku.
13.5. Odstoupení Poskytovatele
13.5.1. Poskytovatel je oprávněn od Smlouvy odstoupit pouze pro podstatné porušení povinností Uživatele sjednaných ve Smlouvě nebo Podmínkách, zejména
13.5.1.1. v případě, že Uživatel bude provozovat nebo ukládat prostřednictvím Služby BBO protiprávní obsah ve smyslu čl. 7.3.2 Podmínek,
13.5.1.2. v případě porušení povinností Uživatele dle čl. 7.2.5, a/nebo 7.2.6 Podmínek,
13.5.1.3. v případě porušení povinností Uživatele dle čl. 7.2.7, a/nebo 7.2.8 Podmínek.
13.6. Důsledky zániku Smlouvy
13.6.1. Do 7 dnů po zániku Smlouvy dojde ke smazání dat uložených v rámci Služby BBO Uživatelem, což bere Uživatel na vědomí a souhlasí s tím.
13.6.2. Poskytovatel je v souvislosti se zánikem Smlouvy povinen vrátit Uživatel poměrnou část již uhrazené ceny (Kreditu) pouze v případě, že Uživatel oprávněně odstoupil od Smlouvy pro podstatné porušení povinností Poskytovatele (čl. 13.4.1 Podmínek), popř. v případě, kdy byla Smlouva vypovězena dle čl. 13.3 Podmínek.
13.6.3. V případě odstoupení od Smlouvy Poskytovatelem pro její podstatné porušení ze strany Uživatele (čl. 7.2) nemá Uživatel nárok na vrácení již uhrazené úplaty (cena, případné poplatky) ani její poměrné části.
14. Užívání Webové stránky Poskytovatele
14.1. Uživatel či jiná osoba využívající Webovou stránku Poskytovatele bere na vědomí, že bez předchozího písemného souhlasu Poskytovatele není oprávněn k užití textů, grafických děl či jiných předmětů chráněných autorským právem nacházejících se na Webové stránce Poskytovatele.
14.2. Uživatel či jiná osoba využívající Webovou stránku bere na vědomí, že Webová stránka nemusí být dostupná nepřetržitě, a to zejména s ohledem na nutnou údržbu Hardwarového a Softwarového vybavení Poskytovatele.
14.3. Uživatel není oprávněn při využívání Webové stránky (serveru) Poskytovatele používat mechanismy, programové vybavení nebo jiné postupy, které mají nebo by mohly mít negativní vliv na provoz Webové stránky či serveru. Webovou stránku a Uživatelský účet je možné využívat jen v souladu s určením Služby BBO, v rozsahu, který je smluvený a který není na úkor práv ostatních Uživatelů.
15. Závěrečná ustanovení
15.1. Uživatel není bez předchozího písemného souhlasu Poskytovatele oprávněn práva a povinnosti ze Smlouvy postoupit na třetí osobu.
15.2. Není-li dohodnuto jinak, Poskytovatel není ve vztahu k Uživateli vázán žádnými kodexy chování.
15.3. Je-li některé ustanovení těchto Podmínek neplatné nebo neúčinné, nebo se takovým stane, namísto neplatných ustanovení nastoupí ustanovení, jehož smysl se neplatnému ustanovení co nejvíce přibližuje. Neplatností nebo neúčinností jednoho ustanovení není dotknuta platnost ostatních ustanovení. Změny a doplňky Smlouvy či těchto podmínek vyžadují písemnou formu.
15.4. Kontaktní údaje Poskytovatele: adresa CASABLANCA INT s.r.o., Vinohradská 184, 130 52 Praha 3, adresa elektronické pošty info@casablanca.cz (obchodní záležitosti), tech@casablanca.cz (technická podpora).
15.5. Tyto Podmínky mohou být v průběhu platnosti smlouvy Poskytovatelem upravovány. Změna Podmínek je Uživateli sdělována prostřednictvím Webových stránek Poskytovatele nejméně 1 měsíc před datem, kdy bude změna účinná. Pokud Uživatel během této doby podá výpověď Služby BBO z důvodu změny Podmínek v jeho neprospěch, platí po dobu výpovědní lhůty Podmínky původní. Uživatel potvrzuje souhlas se zněním aktuální verze Podmínek pokaždé, když se přihlásí ke svému Uživatelskému účtu. Neakceptuje-li Uživatel změny Podmínek nebo kterékoliv přílohy Smlouvy, je Poskytovatel oprávněn Smlouvu vypovědět způsobem uvedeným v čl. 13.3.3 Podmínek).
15.6. Uživatel je povinen se seznamovat s aktuálním obsahem Podmínek, a to minimálně každých 30 dnů, v provozovně Poskytovatele a/nebo na Webových stránkách Poskytovatele. Není-li zde do 10 dnů ode dne změny Podmínek žádného úkonu ze strany Uživatele, pak platí, že Uživatel se změnou bez výhrad souhlasí. Poskytovatel po dobu 10 dnů od provedení změn barevně zvýrazní provedené úpravy z důvodu přehlednosti.
15.7. Tato verze 2.0 Podmínek nabývá platnosti dnem zveřejnění na Webových stránkách Poskytovatele a účinnosti dnem 1.12.2012.
V Praze dne 31.10.2012
CASABLANCA INT s.r.o.
nj ... jenze lecjaka pojistovna s vama prave tohle zacne resit expost - kdyz prijde na pripadne plneni. A pak se vam klidne muze stat, ze pojistovna jednoduse konstatuje, ze jste neprijal rozumna a ocekavatelna opatreni k minimalizaci skod a tudiz ze vam nic nezaplati, pripadne, ze vam vyplati castku, kterou odhadnou jako skodu, ktera by vznikla, kdybyste to delal.
V tomhle pripade muze casa pekne dojet na to, ze nevypli elektrinu, protoze tim zcela zjevne skody znasobili. Sem zvedav, jak z nich pak postizeni budou pacit $$$ za zpusobene skody.
To je sice strašně fajn, ale to samo o sobě nestačí. I když budu mít kompletní snapshot virtuálního stroje, pořád mám problém například se síťovýma věcma. Navázané spojení tam do druhého dne vydržet nemusí, stejně tak může dojít k nekonzistenci už jen díky tomu, že ten snapshot není nikdy běžící pro všecko zaráz. Víme prd, jaké aplikace tam komu běží - nejde na vše koukat jako na triviální LAMP all-in-one servery. Ale závěry děláme :-)
pochopitelně, systém má asi 6GB ten se zálohuje zvlášť sice to o 30 minut zdrží obnovu ale zase se to dá verifikovat injectem konfigurace . rozbalíte to automatizovaně vnutíte tomu jinou IP oveříte funkčnost backimportujete data a nepotřebujete nějakou Chaos Monkey .
A hlavně když máte "vlastní řešení" tak vám záleží na tom kolik do toho zákazník sype peněz tak se udělají dvě menší vpsky ve dvou lokalitách (upraví se app aby běžela ze dvou míst buď master slave replikací db nebo se proste ta aplikace upraví, odstraní se server side autorizace aby v případě výpadku nevypadla session a zůstal přihlášenej). A dvě lokality byli problém snad jen v roce 2007 ale brno-praha to řeší elegantně. Poste 1+1=3 přínos dvou datacenter je hyperbolický nikoliv jen lineární.
U záloh v PDS máme funkcni context protector tj pro jeden backup existuje klíč té zálohy (každá vps, každej hosting, každej systém, každá db) má jinej UUID takže ulozistě zajistí, že dnešní záloha bude 99% jinde (v jiném disku jiná noda) než včerejší.
takže pokud zálohujete denně, tak při 30 dnech záloh máte 99,999999999999% (je to 12 devítek) šanci že když nedostanete poslední, tak dostanete předposlední (je jinde) nebo předpředposlední(je jinde než ta předchozí a jinde než ta předtím) tj data nebudou starší než 48 hodin. Samozřejme dva dny jsou nahovno takže šance že dostanete tu poslední je mnohem nižší někde okolo 99,99999% ale můžete ji zvednout počtem kopií kolik si platíte třeba na 10.
a pak je to o nutnosti rychlosti jestli 1x denně full, a hodinove inkrementaci nebo zvolit např pro databázi repliku která je ONLINE a offsite backup pouze pro případ pádu té db softwaerově (pro mysql nic překvapivého)
Pokud se bavime o tom blbovi o post vejs, tak vyplaveni z vodovodu neni zivelna pohroma ani ve snu. Dokonce ani vyplaveni od deste deravou strechou neni zivelna pohroma a zadna pojistovna na to v tomto rezimu plneni neposkytne.
Ostatne, kazda normalni domacnost se pojistuje prave na vyplaveni ... sousedu, prave vodou z vodovodu. Tudiz kazdy i hodne podprumerne inteligentni ovcan predpoklada, ze se to stat muze (a taky se to celkem bezne deje).
Takze si dovolim tvrdit, ze na toto se 100% garance vztahuje (leda by jeste mohli tvrdit, ze slo o ohalseny vypadek ...). Jeste zajimavejsi to pak bude s temi, kterym znicili jejich HW ... specielne v ripade, ze k jeho zniceni doslo uz ve chvili, kdy se o vode vedelo ... a bylo zapricineno tim, ze to nechali pod proudem.
mě technik sdělil, že budu rád, když v pátek. tak jsem mu poděkoval za upřímnost, popřál mnoho štěstí a ať už mu to peklo konečně skončí s tím, že už mě je víceméně jedno kdy, ale aby vůbec někdy - že si jen dosypu drobné rozdíly co nemám ve vlastní záloze, protože jsem byl nucen to rozject jinde.
no je to škoda. celou dobu jsem tam byl spokojený. tak uvidíme, co pan obchodník na to, že to chci obratem zabalit. pokud nebude dělat problémy, tak se v dobrém rozloučíme a půjdeme každý svou cestou - nic netrvá věčně. pokud bude řešit 3 měsíční výpovědní lhůtu, tak se už budu opravdu bránit. to by byla drzost maximální.
Opět a zase. Vy sem zkopírujete podmínky a nejste si je ani schopen pořádně přečíst, přitom je to jeden odstavec, konkrétně 6.3:
Garantovaná dostupnost Hardwarových prostředků činí 100 % měsíčně, přičemž dostupností Hardwarových prostředků se pro účely těchto Podmínek rozumí, že tyto nejsou ve stavu poruchy (tzn. byl virtualizační platformou přidělen výpočetní výkon Virtuálního serveru dle Technické specifikace). Poruchou se pro účely tohoto článku Podmínek rozumí stav, kdy Služba BBO není dostupná v důsledku úplného výpadku Služby BBO zaviněného Poskytovatelem.
Fakt je to tak těžké pochopit?
A kolik vteřin času administrátora měsíčně na podporu mých problémů s webhostingem je v těch 20 korunách zahrnuto? :-) A může následovat podotázka, kolik ten administrátor dostává plat měsíčně - z toho půjde i odvodit, jak zkušený bude.
Koupit si může kdokoliv cokoliv. BBO je kombinace dostupných komečních řešení a je psáno jakých.
Když už jste tak akuratní, tak to berte tak, že poskytovatel porusil bod 6.2 té smlouvy a bude se vam lépe spát. :-)
Poskytovatel se zavazuje udržovat zařízení ve stavu způsobilém pro řádné používání Služby BBO.
Nebo máte pocit, že zařízení je ve stavu způsobilém pro řádné používání Služby BBO ?
1+1=3? V kontextu keců tady kolem těch garantovaných 100% to působí komicky. Sčítat se učí už na základní škole, ze dvou serverů tři prostě neudělám, i když ten druhý bude u protinožců.
Ve skutečnosti jen další marketingový kec, kterými se zákazníkům vymývá mozek :-) Už se nedivím fakt ničemu. Apropos, jaké že máte kapacity mezi těmi dvěmi lokalitami? A jde o vyhrazené trasy pro potřeby replikace, nebo to honíte po stejných linkách, jako běžnou konektivitu, co se při nějakém DDoSu dají dobře a lacino ucpat? Ono se to pak nabaluje.
Ale ano...i tohle jsem si přečetl - jinak já u Casablanca nic nemám, cca před 1/2 rokem jsem byl přizván k testování nějakého řešení založeného na BIG BLUE ONE a po testech se to zamítlo, protože i když dělali psí kusy, zaklínali se SSDéčovým polem tak to prostě na disku bylo pomalý a proto se to zamítlo mimo jiné i ta cena byla dost vysoká. Vím že tenkrát ten potenciální zákazník byl přesvědčen o záruce 100% dostupnosti a jak je vidět mají to i v těch všeobecných podmínkách....vzhledem k tomu, že jsem to nekupoval tak jsem se na sankce nedíval.
Nicméně napsat, do podmínek že dostupnost je 100% a že pokutou je jedna koruna za jeden případ a že maximální náhrada škody může být 10 korun (to tam níže taky mají ale tedy max 10000 Kč) je bezesporu pěkná sviňárna a za to Casablanca poprávu musí zkrachovat a jak zákazníci tak poskytovatelé se z toho musí poučit.
M(an)agor, který posuzuje 100% podle nabytého pocitu z marketingového letáku je špatný :-) To tam rovnou může sedět blondýna z pomocné školy.
Velké storage vám prodá třeba i IBM. Příběhy o tom, jak se to sesypalo specielně jim oborovými kruhy též kolují :-) Obnova velkých úložišť trvající desítky hodin neni nic neobvyklého, ale to jouda, který má ty své tři jednaúčka asi nepochopí :-)
To viszejo ... par cidel za par tisicikorun, ktere zavolaji technika/iniciuji shudown .... to sou nedosazitelny naklady.
Ty samozrejme jako retardovanej negramot nedokazes pochopit ze tu pisou i lidi ,kteri tam maj trebas i desitky serveru ze ... a rozhodne nejde o majetek a skody za stokoruny ....
Apropos ... cidla v serverovne mi predloni shodila servery, protoze chcipla klima ... diky tem cidlum doslo k naprosto korektnimu shutdownu. V opacnem pripade by se povypinalo zelezo ... stale jeste "HW korektne" na vlastnich cidlech. Rozhdone ale necekam, az tam zacnou plapolat plaminky ... a nemam napady jako casa a TY, pochcat horici srv pod proudem ...
Presne, jako admin se snazim zakaznika upozornit na vsechna byt jen potencielni rizika ... a ocekavam od nej, ze to veme na vedomi. Neocekavam ze bude vsechna rizika chtit eliminovat, protoze to se proste neda. Samo, obcas dojde na vyjednavani typu "potrebuju aby to jelo 24/7" ... nacez je reakce OK, na 99,99% ... to bude stat XYZ MKc. nacez zakaznik zjisti, ze mu vlastne hodina, dve ... trebas i 20 hodin vypadku vlastne az tak moc nevadi, a ze to prezije.
http://www.levny-hosting.cz/hosting-mini
můžu mluvit jen za sebe 300kč ročně což je podobné. A dost to je stejné jako z čeho se platí helpdesk u registrátora kterého technicky provozujeme když nám zavoláte a deset minut se ptáte když trh děla nulovou nebo pětikorunovou marži ROČNĚ na doméně.
Ale je to agregované prostě a jednoduše:
1. nevolají všichni nikdy nezavolají všichni zaráz
2. roste delay, prostě když se zákazník za 30 kč zadá požadavek a je to ve špiččce tak trvá klidně dvě hodiny než se udělá. Když pošle dotaz (technický, obchodní má zodpovězen hned :-) ) tak prostě musí počítat že jeho dotaz zodpovíme např do 24 hodin během bežného dne
3. výpadky, tam to má naprosto std prioritu prostě je to v first-todo-frontě
tj je o ogregaci, nepřísluší mí hodnotit prodejní a cenové praktiky konkurence ale pokuď těch domén máte 300.000 (to my nemáme ale asi oba víme o kom je řeč) tak z toho máte 800.000 ročně, pak jim zpoplatníte cokoliv nestd (např obnovu ze zálohy).
za 20 kč se jedná prostě o distribuované freemium tj provozovatel počítá balík tržeb a ne jen jednotlivou doménu. Tedy ano za 20kč se dá hosting dělat (jeden subjekt na trhu ukazuje že i opravdu agresivním/aktivním marketingem i úspěšně). Ad plat administrátora - nesmíte dělat jen hosting za 20. Std máme ceník 400/600 za helpdesk (účtováno po minutách) a 800/1200 za administrátora (den noc) a tam se prostor na odpovídající plat najde, pochopitelně co si nedomluvíte to vám těžko zaměstnavatel dá. V tom ovšem zastávám názor že čr je konkurence schopná a po roce 2008 se reálně potřeby většiny uchazečů usadili na reálnou míru.
V situaci kdy si často zákaznící nedají řící a dimenzují výkon serveru pod své potřeby mají volbu buď platit admina kterej to řeší nebo prostě zvednout zdroje, a často bývá útok hrubou silou (zvlášť v případě apache-php s mysql) efektivnější než optimalizovat pitvat aplikaci ale záleží to na nich.
Je to jinak, tu službu (BBO nevyjímaje) dělá právě to zázemí, prostě když chcete zajistit 24/7/365 tak máte několik set tisíc offset za mzdy takže to nemůžete dělat pro pět serverů - to je ekonomická sebevražda. takže tu je prostor pro administraci serverů v rozsahu 2500-5500 /měs. Při dnešních výkonech se správou za 4500 dáte na danej server třeba 800 hostingů to máte 6kč za webhostingovou část, 4kč za hardware (vps/vsp), 1kč zálohování.
Pak 3,75 za mailserver sw, 3kč za hardware (vps/vsp) a jste na 18kč/měs za hosting. a to máte jen 800 klientů v 10.000 jste ani ne na polovině a pokud se o to staráte (tj jste provozovatel ne že si to platíte) máte to zase uplně jinde. Takže myslím že za 20kč dokážete provozovat plnohodnotný hosting s 10% marží. takže stačí aby jste sehnal 100 klientů a máte 250 tisíc měsíčně brutto ale marketing zvládnete v jednom člověku.
A pak nastupuje marketing a reklama a zjistíte že to stejně nemá cenu, webhosting je passé je to fakt mela o zákazníka. Už jsou subjekty které vám jen za to že přejdete dají dvojnásobek toho co máte zaplaceno jinde, tj někde zaplatíte a jinde si to odbydlíte (je to podmíněno platbou na rok dopředu) tj je to reálně 70 procent sleva na hosting.
O jakém narychlo schánění serverů je řeč? Smyslem redundance přece je to, že nic narychlo shánět nemusím. A samozřejmě mám pokryté i dodávky náhradního hardware s dodavatelem. Schánět železo, až když nastane průser je.... Váš průser, když se tváříte, jak to máte dobře navržené a odolné :-)
Provoz jedné IP z více lokalit technicky vůbec žádný problém není, stačí správně navrhnout svoji síťovou infrastrukturu.. Jen to samozřejmě také stojí pár korun navíc.
nechcete to chápat tak to nechápete. to 1+1=3 je vyjádření že mezi jednou lokalitou a jednou kopií je propastnej rozdíl v dostupnosti ne že to je tři. Porovnejte pravděpodobnost ztráty dat na dběžném disku a ztráty dat na RAID-1. Tj chápejte kontext, prostě nemít žádnou redundanci je naprostej hazar mezi 3-4 kopiemi už není takovej rozdíl jak mezi jednou a dvěma!
Ad lokality, vy tady čtete něco co nikdo nenapsal neprovozujeme cloud jako je BBO nad dvěma fyzickými lokalitami. Tj to co píšete je nesmysl, zálohování není mnoho je to cca 400mb/s kontinuelně IN/OUT tj 800mbit/s per datacentrum. Žádná replikace POLE tam neprobíhá, když už replikují se db/kód a to se bavíme o jednotkách Mb. Jak psal michal udělat distribuovatejnej např iSCSI volume je netriviálni záležitost.
Ad DDoS míří proti dostupnosti služby nikoliv proti ztrátě dat. Tj mluvíte do 100% dostupnosti služby kterou tady ovšem operujete pouze vy (nikdo ani já to netvrdí). Řeč byla o bezpečnosti dat, kde je růst spolehlivosti méně ekonomicky náročnější.
Geograficky systémem více izolovaných nod provozujeme službu coby subdodavatel pro jednu velmi velmi neoblíbenou firmu co podojila stát o pěkných pár miliard, a při 4 bodech se za x let nestalo že i přes DDoS by to nesplnilo parametr 99,9996 dostupnosti.
A ad dostupnost vůbec jsem tady nesledoval smlouvy (nejsem zákazníkem BBO) ale my zákazníkům "nic negarantujeme" pouze je nastaveno 99,9996 garantována dostupnost a v případ nesplnění smluvní pokuta , víc nejde zaplatit žádným SLA víc jde zajistit pouze tím že si těch nod/systémů pro svůj systém nasekáte víc (2,3,4). Tj je to dostupnost apliakce jako celek ne jednotlivých subsystémů. Žádné peníze ani SLA nezajistí totiž ani náznakem vyšší dostupnost s porovnáním se skutečně důslednou analýzou rizik a aplikace.
Problém proč lidi slyší na ty "rádoby cloud" virtualizace jsou jednoduché, uprava apliakce aby běžela třeba z pěti bodů není triviální zvlášt když řada aplikací je buď PHP/MYsql nebo dotnet2/MSSQL. A pak nahrajete na jednom bodu data a oni nejsou okamžitě na jiném. Musí se udělat interní push mechanismus kde soubor nahrajete php do /tmp a nikam ho nepřesouváte ale rovnou cpete do que mechanismu co ho rozdistribuuje (tj taková pseudocdn prostě tam přes api narvete soubor a ono to vrátí že je to OK). to samé cookies, autorizace, ssl, post - jakmile to lidi vidí často na aplikaci ani nesáhnout a chtěj ten "cloud" kde vše zázrakem jede samo a 100% dostupně - jak to dopadá řešíme celej večer tady v diskuzi.
A zcela mimo možnosti j když dotyčným řeknete ať si přes api forkují nody dynamicky, to většinou uplně zabije jejich snahy upravovat aplikaci.
Mrknou na SLA u Amazonu - http://aws.amazon.com/ec2/sla/
To jsou ale kurvy, co? Co si to dovolují... :-)
věřil bych, naše bezi take
zas bych v te záplave hate postu ktere jsou úplne mimo mísu mírně ubral, cesi mají radi tragedie a jsou neradi když konci, takže tu je halda "uchylu" který se vyžívají v cizím nestesti
co se týká casablany, jejich připojeni k netu mame pres 10 let, funguje a nepadá, nedá se srovnat s předchozím
co se týká teto pohromy, posralo se to > obnovilo se to > trvalo to dlouho > sem zvědav co za to dostanene
nám to bylo ve finále jedno, jeli jsme behem chvíle pres lokal v kanclu
Takže mi v podstatě chcete říct, že pokud se majitel domu zavazuje udržovat byty ve stavu vhodném k bydlení, na barák spadne letadlo a zbude hromada sutin, tak pan domácí porušil podmínky, protože byty nejsou vhodné k bydlení...
Ještě jednou opakuji: provozovatel udržoval zařízení, tedy hardware, ve stavu schopném provozu, to zařízení se neporouchalo neúdržbou. Tento bod tedy neporušil.
Ano, porusil podminky. Nicmene prave pro tyto pripady je ve smlouvach institut "vyssi moci".
Co se tyce pripadneho plneni a pripadnych pokut. Nemeli bychom zapominat na odpovednost majitele/provozovatele baraku. Tj. i v pripade, ze nejaky arbitr dojde k tomu, ze je treba plnit, je tu jeste pojistka majitele baraku.
mate pravdu ale:
u globalni sluzby vas nix netrapi a u backupu to resi ten distribuovanej pds system( rikejme mu cloud) ten ma za ukol data ulozit tak aby jedna kopie byla geograficky jinde a druha jinde nez prvni a ne v lokalite originalu. tj v pripade padu nixu proste vzroste delay a pojede to tranzitem. navic to amneco jako qos tak ro prvni udela ve stejne lokalite aby existovala kopie a tranzitem to vytlaci mezi mistama - pouze to dele potrva.
a unceskych skuzeb je to sumak, za dostupne se dle vop webhostingy povazuji v pripade kdy funguje vice jak80 procent nixovych tras. nemuzeme rucit ze nejaky isp treba z olomouce bude mit funkcni nix a nekdo nezavola ze se nemuze na neci stranky dostat - za toto neruci nikdo je dostupňost infrastruktury a sitova kde je tolik faktoru ze muzeme rucit jen za ty objektivne ovlivnitelne. stejne tak nemuzeme financne platit za to ze napr mailserver komercky neodmitne vas mail - proste to nejde ovlivnit jak vyhodnoti protistrana obsah.
Právě na to „pojede to tranzitem“ jsem myslel. Zda je to „jen“ v této rovině představy, jak by to asi mělo v případě výpadku fungovat – a nebo zda i tohle je ošetřené nějak smluvně a vy máte garantované, jaké bude spojení mezi ISP1 a ISP2, pokud to půjde tranzitem. Případně zda se to i ověřuje. Je mi jasné, že jde především o peníze, ale zajímá mne, zda v ČR vůbec něco takového existuje, nebo zda „nezávislí ISP a pak už to nějak dopadne“ je ta nejvyšší spolehlivost, které lze dnes v ČR na síťové infrastruktuře dosáhnout.
Plácáte kraviny. Jste jeden z těch co tu říkají čtěte smlouvy, tak čtěte. Prostě si měl provozovatel najmout lepší právníky, když to sedpisoval. Teď má na krku nepodmíněný závazek, který nesplnil. Jo milej zlatej, co si myslel je jedno, platí co je ve smlouvě.
A k vašemu příkladu - je o nečem jiném - důsledky technické závady na TZB nejsou ani katastrofou, ani nejakým zásahem shůry - tedy ničím vyjímečným, neočekávatelným, je to jen a pouze provozní porucha,provozní závada.
Závada, porucha TZB a dalšího technického zařízení není žádný zásah vyšší moci, ani nic podobného. Je to běžná provozní závada, nic mimořádného. Nepřipravenost na takovou závadu samozřejmě zvyšuje škody. Nicméně, to že je někdo nepřipraven, je jen jeho problém a nic se tím na smluvním ujednání nemění.
Pořád tu všechny poučujete jak mají číst smlouvy, tak ji čtěte. Ten závazek není ničím omezen. Pokud nemáte v té smlouvě uvedeno,že se závazky v té smlouvě učiněné podmiňují tím či oním, tak závazek platí. Jinak řečeno - to že se nekde u poruchy zříkate odpovědnosti za ně, za nedostupnost nemá vliv na toto ustanovení, to nereší tento závazek. A co provozovatel myslel je jedno. Ve smlouvě je závazek, který nesplnil.
zapomínáte na fakt že tu diskutují i postižení kteří nejsou zákaznící BBO a přesto jim voda udělala škodu. pro mě za mě ať si svoje technologie ničí casa sobě jak chce ale ať to nedělá vlastním zákazníků.
takže když by těm co jim pustili vodu na servery řekli rovnou že je v prdeli hw serverů a nelhali tak by byli škody menši. A např hosting90 to ustál myslím celkem ze ctí běhěm 8 hodin komplet jeli.
jsou to aplikační servery 400 hitů/sec negeneruje ani 4 mbit na server tj tranzit je problém pro operátora (stojí výrazně více narozdíl od flatového nixu) tedy pro nás zákazník to většinou nepozná (i když o tom samozřejmě ví).
Dnes za peníze dostanete cokoliv, jestli chet mít jistotu tak si pořidťě vlákno z bodu a do bodu B. Což je v našem případě ekonomický nesmysl vznikne permutace spojů A-B A-C A-D D-C a to je bambilion. Tj zálohování jede normálně nixem, neprobíhá tam žádnej sync filesystému ale jen replikace aby byla data vždy v replice konzistentní.
Technik, který má v rukou kýbl s vodou a tvrdí, že má problémy se switchem, má dostat výpověď. Manažer, který ho ty blbosti nutí říkat, taky.
Co na tom nechápete?
Samozřejmě, že je po bitvě každý generál. Minimálně by mělo vzniknout poučení "z krizového vývoje", vyházet lemply, nelhat lidem, co vám nosí peníze a živí vás, a tak.
Já se nesmál té společnosti. Mě rozesmálo jak se tu asi dva nebo tři diskutéři už několik dnů snaží přesvědčit ostatní, že šlo o událost nepředvídatelnou, padaly tu výrazy jako zásah vyšší moci apod. No a ta společnost sama uvádí, že takovou událost předvídá, že si je vědoma, že k něčemu takovému může dojít a snaží se proti tomu nějak zajistit.
Jak její řešení fungovalo nebo ne teď musí společnost sama analyzovat - jestli je problém v tom monitoringu nebo v následném postupu.
Diky Martine :D Ale bylo to behem 4 hodin. Viz nase vyjadreni primo na webu a na facebooku. Voda nam protekla rackem stejne jako casablance jejich BBO.
Vyjádření k výpadku služeb ze dne 20.1.2014
Krátce před polednem začalo do serverovny HC8 našeho poskytovatele housingových služeb stropem protékat velké množství vody, která ihned začala protékat všemi našimi fyzickými servery umístěnými v tomto sále. V důsledku toho došlo k okamžitému výpadku služeb běžících na těchto serverech.
Ihned po tomto zjištění jsme začali pracovat na obnově dostupnosti služeb. První služby byly obnoveny již během 1,5 hodiny, 4 hodiny po začátku výpadku byly dostupné všechny námi poskytovaně služby.
O příčinách a zamezení opakování podobných havárií budeme nadále jednat s naším poskytovatelem housingových služeb Casablanca INT s.r.o. Oficiální vyjádření provozovatele housingu http://www.casablanca.cz/informace/
Souhlasim s tim, ze prodavac housek tohle resit nema. Ale je zrovnatak asi nestaci si vzit samotne IaaS reseni, ktere z principu jen nahrazuje fyzicke zelezo v urcite pozici a ma usetrit starosti o HW. Porad tu mame nejaky SW, ktery si prece ten prodavac housek take sam neresi. Bohuzel dnes je "trendy" mit z ICT infrastruktury slepovanku od vseho kousicek - kde se problematika neresi komplexne a casto leva ruka ani nevi, co dela prava.
Z monitoringu prostredi se dozvim, ze tam ta voda vnikla. Predikci toho, ze nekde praskne stoupacka z monitoringu nedostanete. Nicmene, take uz peknych par let je take vseobecnym trendem cokoliv over IP :-) Lehne-li pak switch, do ktereho je pripojen monitoring over IP, tak jedine, co vite vite je, ze nic nevite. Respektive vite jen to, ze mate mrtvej switch :-) Samozrejme, existuji i jina reseni, ale to je o penezich. Stejne to je treba s ethernetem, ktery svou cenou vytlacil drazsi (byt v mnoha aspektech mozna promyslenejsi) sitove technologie nebo treba i s videem, ktere dnes kdekdo tlaci pres HTTP, i kdyz mame vhodnejsi protokoly na tento ucel :-) Ten tlak ale prichazi i od zakazniku, kteri vse chteji levne, levneji a jeste levneji. To se prece nekde musi odrazit :-) Kdyz budu setrit na cementu, tak to na stavbe baraku take poznam. V ICT na to radi zapominame.
Říkáte hlouposti. Datasály patří poskytovateli a on je zodpovedný za to, co se v nich děje. To že optření v tomto případě nebyla dostatečná nebo funkční, je problém poskytovatele. Jediné pro co je důležité, kdo vodu pustil, je případná náhrada škody mezi poskytovatelem a tim původcem.Ale nic to nemění na tom, že za nefunkčnost nese odpovědnost piskytovatel. Vodovodní havarie je běžná technicka porucha, nic nepředvídatelného - poskytovatel sám uvádí, že má monitoring vlhkosti a zsplavení. To že to je v jeho případě nedostatečné, je právě tou jeho chybou.
Zaplaveni vodovodem je vzdy vina toho, kdo v dane lokalite neco poskytuje => zavinili to oni tim, ze mistnost neni nalezite vybavena. To oni garantuji protoz a aoni jsou zodpovedni za jeho nalezite zajisteni. Absolutne pred zadnym soudem neuspeje to, ze ze neco podobneho neda predpokladat - da, naprosto vsichni to predpokladaji. Proto se zcela bezne instaluji cidla, aby se alespon vse vyplo, kdyz uz nic jinyho.
obvolat 10 zákazníků a zeptat se na postup (tj na čem trvá). Stejně si myslím že hazardovat se životem techniků a majetkem zákanzíků byla prasárna a prostě si to těd vlastní vinnou casa vyžere.
Sice se tu řešilo že tu zákazníci neprdndají, jiste žw ne většina by musela přiznat jak to podcenili ale myslím že za tenhle fail jsou jim obchodníci všech konkurenčních firem vděční a to nejen pro teď ale ještě nekolik let.
Jenze majiteli baraku by se nejdriv musel prokazat, ze neco zanedbal. K prasknuti vody muze dojit i v pripade, ze nic nezanedbal. Je to zcela bezna vec.
Navic zaroven plati, ze majitel/provozovatel nejakeho majetku (trebas tech serveru) je povinen svuj/svereny majetek nalezite zabezpecit.
Kuprikladu, pokud budete mit ve standardnim byte obrazy za stovky mega, a nekdo vas vykrade, tak vam pojistovna neda nic. Proste proto, ze jste vzhledem k povaze a hodnote majetku mel provest daleko zasadnejsi zajisteni. To plati i v tomto pripade.
Pokud mate pojisteni domacnosti, tak jiste vite, ze trebas na elektroniku se v zakladu pojistka vztahuje jen do nejake castky, a protoze predpokladam, ze toho mate doma vic (jako vsichni lidi od IT), tak musite byt pripojisten.
Provozovatel nezajistil zabezpeceni provozu proti zcela bezne okolnosti jako je vniknuti vody => nesplnil smluvni ujednani.
Je to presne totez, jako kdyby nemel funkcni UPS/agregat/..., on prece taky nemuze za to, ze CEZ nedoda elektrinu, ze ... a je to presne totez, jako kdyby nefungovala konektivita ... protoze oni prece taky nemuzou za to, ze nekde nekdo nese do sberu kus optiky ...
Přečtěte si prosím nač o reagujete smrt 5/6 serveru je fuč 87% výpočetního výkonu.
Pro tyto situace skutečně nemáme plnou 1:1 redundanci, nedí důvod máme jeden záložní asi na 13-17 serverů (bere se to tak že těch top serverů je méně protože záloha by měla dokázat poskytnout stejný né-li větší výkon) Tj bez problému ustojíme ztrátu tak 7-10 racků tj do 200 serverů.
Jenže něco je to technicky ustát a něco je obratem zaplatit za 200 serverů 18-25M korun a pak doufat že to pojišťovna zaplatí.
Plán B je ovšem mít DATA a SYSTEMY i systém a kdyby se stalo (ťuk ťuk) tak prostě nakoupíte ty systémové zdroje jinde a vyjde vás to levněji než se na to zajišťovat hardwarem. U Amazonu a v MS máte 200 serverů naklikáno za dvě a půl hodiny. Stát vás to bude pár set dolarů za hodinu a to na ty dva dny dáte. Nelhledě na to že v čechách vám rád ledaskdo pomůže ať hw nebo vám nakliká vps které budou sice výrazně pomalejší než ty produkční ale pořád je to lepší než když to stojí.
Takže kdyby bylo fakt začně se čistit zálohování třeba do S3/Glacieru nebo se prostě zastaví zálohování a nasypou se data na ty cpu boxy pro zálohování a pustí se to na tom.
zbytečná řeč, jeden z jejich zákazníků tam zařval asi za 40 serverů takže i kdyby to nakrásně ustál tak poteřebuje obratem do několika dní aspoň 40 serverů protože v té době redundanci nemá.
Nelze to dimenzovat redundantně na již redundatní řešení, a tu v diskuzi (ne já) je pár lidí kteří si mákli a ukázali case záda . tj že se os své klienty perfektně postarali. Můžu mít k nim profesně jakékoliv výhrady ale tohle zvládli lépe než casa.
Moje domaci "devka pro vse" bezi bez vetsich potizi na hardware pres sest let starem a jedine proc uvazuju o vymene je spotreba energii. Disaster-recovery plan je o nakupu v Alze a pretazeni dat zalohovanych mimo domov, pokud se sesypou vsechny disky v RAIDu. Ale nedovolil bych si srovnavat svoje domaci reseni pro me samotneho na par stovek GB dat s nejakou urovni spolehlivosti s tim, co se provozuje na komercni sluzbe pracujici s objemy v jinych radech :-)
No pokud je to HW z popelnice tak nebude tak extra slozite to nahodit zpatky. Promin, ale delate tady ze sebe blbce pac ukazujete sve elementarni neznalosti. Jeste jednou rikam, ze neresim fakt, ze jim nateklo do serverovny a uz vubec ne to, jestli nekdo lhal a sliboval to co nemuze dodrzet! Resim to, ze tady diskutujete o tom, jak je mozne, ze ta obnova provozu trva tak dlouho. Ta velka pole jsou stavena tak, ze pokud odejde nejaka komponenta, nebo komponenty, tak neni problem za provozu tyto soucasti menit a je jedno jestli je to disk, nebo zdroj. Dokonce i firmware muzete updatovat bezvypadkove aniz by to melo dopad na dostupnost sluzby. Ale pokud tim protece hektolitr vody, tak to hotswap uz nevyresi. Tak a kdyz dojde k takove destrukci, ze se musi pulka komponent vymenit, tak neni jina volba, nez pole odstavit, veskery HW nahradit novym a spustit ten cirkus cely znova. Uvedomte si, ze to neni TV kterou vypnes kdyz jdes vecer spat a rano si ji znovu zapnes. Spusteni takoveho systemu jde pres X vrstev a nez je to schopne znovu pracovat trva to hold dlouho. No a posledni vec - ta obnova dat za zalohy. Ku...a jak dlouho trva prekopirovat treba terovej hard?! A tady to jsou takova kvanta, ze jste to nikdo z vas v zivote nevidel. Vykaslete se uz na reseni toho, ze to trva dlouho, vzdyt mlatite dokola prazdnou slamu! Hlavne panove fakt jste vsem k smichu.
Zamestnanec ma ze zakona moznost odmitnout vykonat praci, pokud to znamena treba ohrozeni jeho zivota. A je to dospely clovek, mel by umet se sam rozhodovat. S tim obvolavanim nevim - ale sam jsem byl svedkem mnoha situaci, kdy za zdanlive logicky a racionalni postup zakaznik poskytovatele serval, kdyz zakaznik nebyl informovan predem :-)
už jste někdo řešil výpověď a 3 měsíční výpovědní lhůtu? server už jsem byl nucen obnovit jinde - do teď mě to casa nenahodila a čekat na to už nešlo.
docela bych to tam rovnou ukončil a ne že jim za tu parádu ještě budu platit 3 měsíce za něco, co tam už ani mít nebudu.
to by mě fakt dorazilo :)
Nejsem si vubec jistej, zda vubec nekdo v teto diskusi stavi casu do role postizeneho.
Jen se tu par lidi snazi naznacit nekolika "spravedlive rozhorcenym obcanum" (nekteri z nich budou pravdepodobne zakaznici), ze pokud budou spolehat na marketingove letaky, tak muzou u jineho poskytovatele "cloudovych sluzeb" dopadnout za par mesicu ci let stejne.
Diskuse o tom, kdo, jak a komu bude platit, je zajimava, ale de facto k nicemu.
Nedelam si iluze ... ale pokud me skleroza neklame ... v defaultu se pojistka vztahovala na elektronicky kramy do 20-25kKc ... coz je tak jedna TV pripadne 2-3 telefony ... . A tohle preleze hodne domacnosti uplne vpohode. ... Hlavne ze tam bylo zlato za 200k ... ;D prej nejlepsi zpusob pri kradezi, jak z pojistovny dostat $$$.
Takže na tom přirovnání k nigerijskému dopisu opravdu trváte???
Pokud k nakupovné službě přidám svoje služby a prodávám jako celek, tak si musim prověřit nakupovanou službu detailněji, než když ji používám pro vlastní potřebu, kde jsou mi známa rizika, která podstupuju, pokud nakupovaná služba selže.
To kdo a kde pustil nejakou vodu je uplne jedno. Jedine co je dulezite pro posouzeni jestli podle tech vop za to casa zodpovida, je jakym zpusobem ma zajistene ,aby technicka zavada nekde v objektu kam sve zarizeni umistila nenarusila chod toho zarizeni. A to nema nebo ma spatna opatreni. Proste - kde bude zarizeni provozovat, je jeji rozhodnuti a pokud se objekt rozhodla sdilet s jinymi subjekty, pak ho sdili i s riziky s tim spojenymi. Je to jako bydlet v panelaku, nebo rd. Kdo jde do panelaku, musi pocitat s tim, ze dum sdili s dalsimi obyvateli a jejich chyby a nehody proste budou ovlivnovat i bydleni jeho samotneho.
Jasně nepostavil byznys, jinak se budete chovat, pokud budete za využití této služby poskytovat svoje služby stovkám zákazníkům s nimiž sepíšete vlastní SLA (je Vám jasné, že i když něco pokazí ten předchozí článek, problém máte především vy, jako poskytovatel koncovému uživateli, otázky náhrad za škody na Vašich zákaznících, které uplatníte u předchozího článku jsou v oblasti šedivá teorie), ale co když chci dát někam server pro vývoj, takový výpadek znamená jen určité nepohodlí, ale kdyby mi uvedli do podmínek, že to není 100% ale obyčejných 99,9%, tak bych si je nevybral. Nikdo je nenutil nabourat obecné zvyklosti na trhu, pokud to udělali kvůli marketingovým důvodům, tak je mi jich líto, ale za nespokojené zákazníky si tak mohou sami.
Presne ... kdo bydli pod strechou, pocita s tim, ze strecha muze protekat, kdo bydli niz, pocita s tim, ze jej lide nad nim mohou vytopit. Ti lide proti tomu budou pojisteni, ale pokud ma dotycny doma neco, na cem voda zpusobi skody za desitky ci stovky mega ... tak to pujde za nim, protoze to nema nalezite zajisteno.
Přesně jak píše Michal.
Casa samozřejmě poškozená byla, byli poškozeni i zákazníci. Už jsem psal, že minimálně komunikaci Casa hrubě nezvládla a být já na místě těch, co tam měli servery, tak by mě to taky nadzvedlo ze židle.
To ale nic nemění na tom, že nelze spoléhat na své domněnky nebo marketingové materiály a pak se rozčilovat, když jsou věci poněkud jinak.
Ta analogie je hezka, lec od poskytovani IP sluzeb k poskytovani einfrastruktury je IMHO dal nez od motorky ke ctyrkolce.
Podobne nemam pocit, ze by casa mela za sebou 15 let super povesti v IP sluzbach (inu, kazdy nejak zacinal) - premyslim, zda je vubec na trhu nekdo z takovou povesti :-)
Takze to bude asi ten rozdilny pohled. Mozna si obecna podnikatelska verejnost mysli, ze poskytovani IP je totez co poskytovani nejakych komplexnich sluzeb VPS. Podobne uz jsem se potkal s tim, ze si spousta lidi mysli, ze poskytovani video sluzeb je totez, co poskytovani IP sluzeb.
Pokud pro vas znamena vypadek jen nejake nepohodli, tak nebudete sermovat stovkami tisic ztrat.
Navic mam za to, ze kdyz nekde rozjizdite vyvojovy image, tak ho mate nekde zazalohovany a udelate deployment jinde prakticky kdykoliv.
Jinak se budete muset smirit s tim, ze reklama je navonena mrtvola, marketing vladne svetu a musite cist i ty vety petitem a spolehat na radu pravnika, pripadne se poradit s nekym, kdo tomu rozumi. Ja vim, stoji to cas a penize, ale zivot neji pericko.
Aha, takže firma, která provozuje víc než 10 let serverovnu si neumí představit, že to zařízení v ní může takovým způsobem selhat? To, co viděli a řešili se zákazníky, co u nich měli server během té doby, bylo kvůli tomu, že to ti zákazníci dělali blbě a oni mají know-how, jak to dělat dobře? Nezlobte se, ale jsem si jistý že know-how na to, že se zařízení kazí a jak se kazí a jak se obnovuje pak ze zálohy, měli. Pokud byste měl pravdu Vy, tedy, že si firma jako casablanca nemohla umět představit k čemu dojde, tak opravdu nelze v tomto oboru věřit nikdy ničemu.
Bavíme se už v obecné rovině, která už se asi nedotýká případu Casablanca.
I způsobené nepohodlí je nepříjemné a dokáže zle nazlobit. Přesně jak říkáte, život není peříčko, takže ten, kdo nepohodlí způsobí, by se měl snažit nabídnout podstatnou satisfakci i s ohledem na fakt, že vyvolal dojem, že má služba nějaké parametry, účtoval si za to roky peníze a pak, když přijde nějaká krize, nestačí jen vysvětlovat, že jste mu vlastně platil za něco jiného a že je to Váš problém. Předpokládám, že peníze zpětně vracet nebude.
Samozrejme bezna virtualizacia ako ju nazyvaju cloudom teraz, lebo je to moderne a pritahuje pozornost tak clud nieje.
Cloud nieje ani cluster.
Sluzby ako amazon a gmail vyuzivaju distribuovane ulozisko napriec viacerymi datacentrami. Nieje to zdaleka tak, zeby niekde lezat centralny storage ktory moze umriet.
Co ludskych schopnosti uspravovat celok vetsi ako 4 servery, zrejme mate velke medzery v aktualnych technologiach. Nieje problem v teame 4 ludoch uspravovat a mat prehlad co sa deje na radovo stovkach serverov. Je to len o pouziti dostupnych technologii a nepristupovat k sprave sposobom ako sa to riesilo pred 20 rokmi.
Ok, jsem rád, že si začínáme rozumět. Zkrotit obchodníka si firma musí sama, já jako zákazník nenesu za jejich obchodníka zodpovědnost (protože to by byl zase Kocourkov, že ano?!), takže tohle dělení obchodník vs někdo jiný z firmy neberu, je alibistické. Firma těží z práce obchodníka, takže od něj nemůže dávat ruce pryč v situaci, kdy se ukáže, že sice přinesl spoustu zakázek, na kterých firma vydělala, ale lhal o tom, co nabízená služba opravdu poskytuje. (Nebavíme se teď konkrétně o casablance, mluvím obecně o vztahu obchodník zbytek firmy, jakékoliv i té Vaší).
Že se to tak obecně dělá, ještě neznamená, že je to v pořádku.
Tady s vama naprosto nemuzu souhlasit databaze se pouzivaji prave proto ze tohle samozrejme ZVLADA. Existuje neco cemu se rika transakcni log a libovolna transakce se do tohoto logu pise a okamzite zapisuje na disk (pokud je db dobre nastavena samozrejme lze tento log drzet i v ramce ale to musi udelat DBA a je to na jeho zodpovednost pak ziskame vetsi propustnost za cenu moznosti ztraty dat)
dokud transakce neni potvrzena v transakcnim logu tak je to to same jako by se nestala. Tzn DB je schopna se obnovit do konzistentniho stavu. To ovsem za predpokladu ze se udelal SNAPSHOT filesystemu, pokud se zaloha delal prostym kopirovanim souboru tak to tak samozrejme neni jelikoz zatimco sme skopirovali transakcni log tak se jinde mohli zmenit data na pozadi
Jenze oni vam negarantuji dostupnost dat ... ale funkcost !fyzickeho! HW, a to uplne vpohode zajisti i pri totalce. Proste do hodiny ci dvou dorazi nakladak plny polic s diskama. Samo, pokud si takovy servis zacaluje zakaznik.
Pokud budu chtit zajistit 99% na data na tom poli, tak pri velikosti stovek TB ... si holt ta pole budu muset poridit minimalne dve, a kazde dat do jine, rozumne vzdalene (alespon jina ctvrt) budovy.
Vrele doporucuju vyzkouset v praxi ... a teprv pak o tom nekam neco psat. Pravdepodobnost, ze databaze neco takoveho vydejcha je tak nekde kolem 50% ... takze nic moc. Ostane, viz vejs, trebas cache FS = system (i databaze) vidi data zapsana => do transakcniho logu klidne potvrdi., ale data ve skutecnosti zapsana nejsou ... jsou jen v cache.
Dtto, kazdy jeden disk ma vlastni cache. Dalsi cache muze mit radic a i kdyz ma baterku, tak ta je mu jaksi khownu, kdyz vyhori ptotoze do nej nachcala voda.
Udelat bezpecny zapis dat na disk neni vubec jednoduche, a je to etremne narocne na vykon - je totiz nutne odstavit veskere cachovaci mechanismy, coz snizuje vykon klidne o nekolik radu. Takze se to defakto nepouziva, a spoleha se na jine zajisteni - UPS a pod.
A samo, pokud chci udelat snap, delam snap konzistetni => potrebuju dat systemu/databazi vedet, ze ten snap chci udelat. Dela se to naprosto bezne. Umi to kazdej blbej zalohovaci soft za par tisicove ...
Vsak ano. Pokud dodavatel i HW proklamuje 100% dostupnost, nevidim problem s tim, aby poskytovatel sluzby proklamoval 100%, coz se myslim i delo. Ale ani 100% dostupnost HW reseni neimplikuje, ze nemuze nastat situace, pri ktere to proste tyden nepojede. To, ze nekteri lidi si do proklamovane dostupnosti HW mezi radky vlozili dostupnost sluzby je vec jina.
Drtiva vetsina DC u nas je v budovach, ktera pro tento ucel projektovana puvodne nebyla. Muzeme to nazyvat diletanstvim, ale na druhou stranu je potreba rict, ze zakaznici nejsou zrovna ochotni platit za to, ze nekdo postavi barak s parametry vhodnymi pro DC. Pokud je pozadavek na co nejlevnejsi sluzbu, tak se to musi nekde odrazit.
Je to stejne jako s kvalitou jidla na kramech. Vsichni na to ted nadavaji, ale uz zapominaji, ze svoji poptavkou takove prostredi sami vytvorili.
Takze kdyz tam vjede kamion z ulice, muze za to provozovatel salu? :-) Fajn. Asi jde postavit barak tak, aby se takovy "utok" ustal. Ale bude to stat nejakou tu korunu navic a i z pozice zakaznika na prvni pohled poznam, ze ten problem dany prostor ustoji. Je to o tom, ze jako uzivatel zhodnotim rizika, ktera mi hrozi.
Monitoring zaplaveni poda inforaci o tom, ze tam voda uz je (muzeme debatovat o jeho funkcnosti). Ne o tom, ze voda za chvili bude a ze technologie je ohrozena. V momente, kdy uz voda protece pocitacem je z pohledu dopadu stejne jedno, ze mi monitoring sdeli, ze tam voda protekla.
Read it again - píšu že kdyby na 5 míst ze 6 it (geolokace, byť třeba praha - praha) spadne meteorit (tj na 5 míst současně) tak to prostě nejde dělat. Stejně tak o těch serverech, 1/13-15 je počet volných prázdných serverů kde NIC není čekají na smrt jiného. Raději to budu stavět na SM než na IBM a budu mít poměr 1/13 než s IBM 1/35.
Na 100% redundanci to nejde nadesignovat vždy existuje pravděpodobnost a hypotetická šance že se něco pokazí. Proto jsem psal že exitová strategie koupit výkon jinde (tj mít data tak backup systému a konfigurace) je ekonomicky opodstatněná (jinak by muselo být poměr serverů třeba 1/4 - 1/2)
Treba maji. Ale ta replika jsou pasky v trezoru na druhe strane prahy no a to je ten cloud! Clovece nejste vy z 15teho stoleti? Verit obchodnikovi. Mate to pisemne? Mate zaznam? Mate to ve smlouve?
Musite umet spravne lhat. Pak to nekam dotahnete a ne jako my plebs co delame s tou technikou.
Resi se to z duvodu treba z politickych duvodu jako zabaveni infrastruktury statnim organem.
Vysvetlujte to zakaznikovi odnekud z tramtarie...
Nemusite delat nic spatneho. Staci jen kdyz si na vas nekdo ukaze ze je to ten co podporuje terorismus/prodava zakazane xy/siri zakazane xy/dela xy ktere je zakazane a hon na carodejnici muze zacit.
Pak se hodi mit zalohy v jinych statech ci na blize neurcenych mistech.
Mezi mene obvykle veci patri treba: revoluce,stavka zamestnancu, kradez paliva z dieselagregatu. A jak obhajis zasah vyssi moci zalezi na tve srajtofli. Have fun!
Prominte, ale vidim to z jine stranky.
0.Technik ktery objevil problem ma sam okamzite pruser a proto ho zatluce, protoze by to musel opravovat nad ramec sve prace. Problem ktery objevil muze byt sveden na nej a byt z toho vyvozeny dusledky. Navic nevi do ktere kolonky to momentalne napsat. Proto se na to radeji prijde potom jako vypadek infrastruktury a dalsi vyjezd.
Je to smutne ale je to dane mistni kulturou.
V zahranici se s timto nesetkate. Tam je pozorny udrzbar i odmenen.
1.Vedouci nenastavi spravne procesy. Technik kdyby mel kazdeho od hotline,pres nadrizeneho sefa, sveho technickeho sefa a zakazniky informovat, tak cely den nic neudela. Potrebuje jeden bod kontaktu. Od tohoto bodu se muzou ostatni dozvedet. Staci kratka zprava o tom co se deje a ne vyplnovat tisice fornularu typu: Myslite si ze byl zakaznik nastvany? A jak moc myslite ze je nastvany? Jaka byla velikost bot zakaznikovy babicky za svobodna? Tohle delaji magori co sedi cely den na zadku v kanclu a nikdy nebyli v terenu s technikem.
2. Je nutne kontaktovat hotline? Nema se hotline nahodou ptat na dohledu a dohled komunikovat s techniky? Technik pak vytvori nake info a preda ji aby si to mohli precist vsichni.
3. Platy. Ano L1 support ma obvykle nizke platy. Lepsi je to pokud vladne vice jazyky.
Vzhledem k vysoke rotaci na techto pozicich se ani vetsinou neplanuje investice do teto casti. Muzu ale rici ze zamestnavatel ktery univerzalne kasle na L1 si zavira sam dvere k vychove dlouhodobych zamestnancu kteri muzou v budoucnu prevzit L2 ci po studiu L3. Neni lepsiho cloveka do vyssich pozic ktery zna potize nizsich pozic a vnitrofiremni procesy. Chovejme se k L1 dobre a sami nas prekvapi. Rada studentu ktera zacinala na prvni urovni podpory se ve firmach vypracovala na pomerne vysoke pozice.
technik není od toho aby informoval každého od hajzlbáby po hotline. naopak je to hotline kdo když zjistí problémy uživatelů , míá kontaktovat techniky se žádostí o nápravu. A mimochodem, vím, že příjde li technik s tím že je průser, jediné na co se nadřízení zmohou, je seřvat ho.
V tomto se nas postoj asi nelisi. Budu-li paranoidni, sva data a sluzby nebudu mit na jednom miste. Naopak, budu diverzifikovat - mezi vice sluzeb. Ale fakt nebudu spolehat na to, ze nahranim do cloudu docilim toho, ze data pred podobnym organem ochranim ;)
Spousta lidi si "cloud" vyklada tak, ze ten problem s diverzifikaci vyresi za ne. Ale ono to neni pravda...
Ona by to pravda byla, kdyby to byl cloud. Spousta lidi si neservisuje auto, proste proto, ze tomu nerozumi, pripadne ocekavaji (naivne samo), ze kdyz daji auto do servisu, tak ze tam sou lidi, kteri tomu rozumi (nejsou, v zadnem).
Stejne tak spousta lidi proste ocekava, ze pokud sva data/sluzby/... sveri firme, ktera se tim zabyva, ze se ta firma postara o jejich zajisteni.
Jenze technik ma nejdriv a prioritne zajistit minimalizaci skod - a to predpoklada sdeleni informace, pokud mozno co nejpodrobnejsi, co se deje a jak dlouho se to bude +- resit. To je totiz vetsinou daleko dulezitejsi, nez vzit hadr a zacit honit vodu.
Predevsim prave proto, ze je problem kazda minuta, je pak nutne zakazniky co nejdriv a co nejrelevantnejs informovat - protoze pak se da nejak reagovat a nejak resit. Pokud zakaznika taham 2 dny za fusekli s tim, ze "za hodku to pojede" ...
(mi prijde jak CD, to je to samy ... zpozdeni 5minut ... za 5 je tam 10 ... a takhle klidne do 4 hodin ....)
Bud bude drzet v ruce kladivo nebo telefon. Oboji zaraz jde blbe, bud bude skutecne makat, nebo se vykecavat :) Debatovat muzeme o tom, co je dulezitejsi.
Ono je to v mnoha oborech dost podobne - nekdy je slozite sdelit presnou informaci hned ze zacatku, kdyz to vypada, ze staci opravit urcitou komponentu a bude to v pohode. Ale on s opravou jedne vyskoci dalsi problem, ktery predtim neslo diagnostikovat a minuty naskakuji.
Ano, zvednout telefon a zavolat na jedno cislo asi problem neni. Obvolat treba desitky (natoz stovky?) zakazniku, to uz takova sranda neni. Je to na vsech telehousech podobne, personal je redukovany (pochopitelne, zakaznici tlaci na ceny...).
Jsem rad, ze zminujete ty povodne. U tech pred skoro dvanacti lety lide byli soudnejsi, nez jsou dnes. A take byl s distribuci informaci nemaly problem, kolabovalo kdeco... a tech nekolik dni (pripadne i tydnu) se prekouslo. Dnes lidi sili i kvuli pul hodine....
Vážení zákazníci,
rádi bychom Vám upřesnili, jak funguje geografická záloha primárního pole a tím i osvětlili nastalou situaci.
Geografická záloha primárního pole slouží zejména k replikaci dat zákaznických serverů a nikoliv pro produkční provoz. U některých kritických systémů je jí sice relativně snadno do produkce převést, ale jen s omezeným výkonem.
Tato asynchronní záloha se provádí zhruba jedenkrát za hodinu a nyní, jakmile bude dokončena oprava primárního pole, je třeba data zreplikovat zpět.
Toto je důvod proč Vaše servery nyní neběží, každopádně o svá data ale nepřijdete.
Děkujeme za trpělivost a o dalším průběhu Vás budeme informovat na facebooku či na již zprovozněných stránkách http://www.casablanca.cz/informace/
Od nás dostali včera jasnou msg, z našich 5+ mega ročně od včerejška nedostanou nic dokud se to nevyřeší a závěr byl že ano jen co se to rozjede tak uvidíme. Nám v HC8 hrozili tak 3,5 milionu ale o 2m se to zastavilo ale např v Abacusu měli dneska dle slov z montáže víc než paniku.
Technologicky je primy spusteni z backupu naprosta trivka ... samo je to otazka vykonu, ale v tomhle pripade bych ocekaval, ze budou mit dve stejna pole (a samo prislusnej dalsi HW), ktery se zrcadlej ... => centralne se to jen shodi, presmeruje a zase nahodi => operace na ... hodinu (nez vse znova nastartuje)?
Navic vmware - pokud by to bylo komplet virtualizovany - toto umi udelat i za pochodu => nikdo z venku si ani nevsimne, ze se neco podelalo.
Navic to neni zadna kosmicky draha technologie, protoze i pro malou firmu je dneska proste uz problem obnovovat TB dat, proste proto, ze to trva.
Palec nahoru. O tom tu presne pisu. Takze ted jsou ve fazi "Disaster Recovery" a holt to budou z pomaly paskovy knihovny obnovovat 4 dny. Vse je o penezich.
Kdyby to melo byt geograficky HA tak zaplatej radove vic penez. Ona i ta zaloha resp. recovery muze byt hodne rychla ale zase prachy. Predpokladam ze tam nezalohujou na Oracle/Sun/Storagetek SL8500.
Obnovit data z disku jednoho serveru bude časově asi jinak náročné, než obnova nám neznámého a zřejmě asi ne zrovna malého počtu disků v té virtualizační platformě. Když těch serverů budete mít pětset, asi to taky nebudete mít zprovozněné vše za pár hodin. Je neuvěřitelné, jak dalece lidé nedokážou používat hlavu a myslet :-)
To je tak, když si někdo na letáčku přečte 100 a dál se již o znění smlouvy nezajímá, protože to považuje za zbytečné. Přímo ve všeobecných podmínkách je řečeno, co se do těch 100% počítat nebude. Nebo snad máte ve smlouvě, že Vaše služba přežije bombardování Prahy? Asi ne, co? :-)
Uvedení smluvní 100% garance není sama o sobě implikací geografického clusteru - to je pouze předpoklad, který máte na základě nějakých svých osobních pocitů. Pro určení dostupnosti je vždy stanoveno, ze kterých údajů se vypočítává. A bývá to zahrnuto ve smlouvách - ale nikdo nečte, prý je to zbytečná ztráta času. Inu, za vlastní blbost se platí :-)
Samo, bavime se o distribuci technologii tak, aby vypadek jedne lokality nesejmul cely provoz ...
Znam trebas firmy, kde to maji alespon ve 2 ruznych mistnostech na 2 ruznych vetvich rozvodu elektriky. Samo, pokud CEZ odpoji celou ctvrt, tak holt smula, ale to je vzdy o pomeru vynalozenych nakladu vs pripadny skody. Pak znam par firem, ktere proste maji zalozni reseni nekde na pobocce => kdyz chcipne cetrala, tak zajisti alespon nouzovy provoz, byt trebas s omezenym vykonem. A to nejsou zadni giganti, jsou to pidifirmy.
V tomhle pripade bych predpokladal minimalne dve ruzne budovy v ruznych castech mesta. Predpokladam, ze se prsi tim, ze maji 2+ privodu elektriny ... ale na 100% si dovolim tvrdit, ze do baraku vedou stejnou trubkou => pokud bagrista hrabne ... je po privodu.
Pokaždé když je zde na Lupě nějaký článek kde se píše o tom, že se někomu stala nepříjemná událost.
Vyskočí Krsek a začne se dotyčným vysmívat, že to jsou hlupáci když věřili VEŘEJNÝM proklamacím. A má až patologickou radost z cizího neštěstí.
Jen bych podotknul, že stále ještě existují země kde k uzavření smlouvy stačí podání ruky. A v případě podobného bugru, jako se stal Casablance není třeba několik let soudních tahanic, klienti od dotyčných prostě navždy odejdou a nebojí se veřejně o své "zkušenosti" s každým podělit.
Chcete tvrdit, že Vaše čidlo se nemůže porouchat, vyvolat například falešný alarm nebo naopak v nějaké mezní situaci problém nezjistit? Ale jděte, ani součástky v průmyslovém provedení negarantují, že nemůže dojít k problému. Někdy stačí vadná série, vada se může projevit až po čase.
Co byste si představoval? Že na základě indikace ze záplavového čidla odepne rozvodna? :-) Už vidím ty davy nasraných zákazníků a plné diskuze plamenných příspěvků v situaci, kdy to vypne zbytečně.... :-)
Předpokládám, že ten Váš ICT integrátor bude dodavatelem pro státní správu. Ano, tam se to miliony jen hemží a ty systémy také vždy nefungují jak mají - i když tam se určitě nepotýkají s tím, že by měli omezené rozpočty :-)
my jsme taky konkurence a současně i jeden z největších zákazníků a co? Všichni z vedení vědí že i kdyby se potrhali není možné u nich mít nikdy více jak 60% serverů (jsou tam i historicky starší tj kdyby byl problém odvirtualizuje se to jinde dejme tomu z 4 hodinovým spožděním).
jenže v case dlouhodobě podceňují rizika i když o nich vědí (voda byla snad ve všech sálech), UPS komplet zkolabovala taky několikrát. Myslím že jsme zákazníci přes 12 let možná i 16-17 let a prostě tento byznys vyžaduje neustále sypání peněz do technologie. Proto jsme taky v roce 2003 vzdali jakýkoliv pokus o to provozovat DC svépomocí i když jsme měli v casablance vlastní serverovnu.
blokací je marketing veřím že technici by schválili instalaci "deštníku" ale neprojde to přes sales/marketing protože by to blbě vypadalo. to považuju za největší fail.
Nic nikomu nebrani misto jednoho centralniho pole provozovat 10 mensich ... a k tomu i 10 zaloznich systemu => i obnova dat bude 10x rychlejsi. Pripadne centralizovany system nadimenzovat tak, aby z toho nebyly tydny.
Nedovedu si predstavit, ze by trebas Skodovka obnovovala zalohy mesic ... to by asi mr IT managor misto zlatyho padaku dostal kulku mezi oci.
I mamloj jako ses ty by moh pochopit takouvou trivialni asociaci, jako ze 100% garantovane reseni na HP uz 3 dny nejede ... Managora naprosto nezajima proc. Navic HP predvadi, jak se na jejich HW obnovuje zalona ... desitky hodin, a to uz s vodou nema absolutne nic spolecnyho. A jako bonus ... jsou obnovene zalohy nekonzistetni a tudiz nepouzitelne ....
Zitra bezim koupit 10racku plnych HP ... celej zhavej ... abych pozitri resil totez.
Jo mrkni níže...vyhrábnul jsem pro zajímavost všeobecné podmínky BIG BLUE ONE a je tam zcela jasně dáno že dostupnost HW=100% a dostupnost konektivity je 99.95% měsíčně. Takže si umím spočítat, že bych tedy měl mít výpadek maximálně 20 mnut měsíčně.
Nepočítají se do toho nějaké předem hlášené údržbové práce, a vyšší státní moc. Jinak by to mělo frčet fakt 100%. !!!!!
Takže tak.
No a jestli jsou všeobecné podmínky papírek co se zaleskne...pak tedy nevím.....
To jste si fakt mysleli, že ty VPP nikdo nevyhrábne ?
Rychlost obnovy je dana zvolenym resenim. Pokud mam garantovat jakoukoli rozumnou sluzbu pro kohokoli jineho nez domaciho bastlice, musim byt schopen backup opbnovit v rozumne dobe - a to kompletni backup. To zcela zjevne nejsou. Nejsou schopniz ajistit provoz ani obnovit zalohu. Tudiz zcela zjevne vubec nepocitali s tim, ze by se mohlo cokoli podelat. A je uplne jedno jestli proto, ze do toho nachcije voda nebo proto, ze sou skvrny na slunci ...
Malá připomínka k povodním z roku 2002. K celé situaci nemuselo vůbec dojít. Pokud by někdo vytvořil analýzu rizik spojených s Orlickou přehradou, tak nebude nikdy zadržovat vodu v takovém měřítku, jako se to neustále děje. Pokud by došlo ke snížení hladiny, tak by byla zadržovací schopnost mnohem větší a voda v metru by NIKDY nebyla. Jde o veliké podcenění rizik, které jsou s přehradní kaskádou spojené. Opět selhání jednotlivce nebo týmu. Situace se bude bohužel opakovat.
Naopak, celá tahle diskuse je zaspamována lidmi, kteří kupují něco na základě svých domněnek úplně mimo realitu a pak se ještě rozčilují a svou blbost svádějí na druhé. A pak tady spoustou generálů po bitvě a jedním vševědem. Já se vůbec nedivím, že se podvodníkům tak daří, když jsou lidi tupí a neověří si, co kupují nebo podepisují.
Hele geroj ... lezi mi doma v kumbale PC router, bezi na tom ruzne domaci kravovinky, funguje to jako videoserver ...
Vcera mi zacla (po cca 7mi letech nepretrzityho provozu) chcipat deska (kondiky) ... vecer sem prisel, vytah ze skrine jinou ... a vymenil to.
Ted mi vysvetli, jak je mozny, ze s HW vytazenym "z popelnice" sem schopen zajistit radove vyssi dostupnost ... nez oni s HW za desitky , mozna spis stovky milionu? A ano, nikde se neprsim, ze dostupnost je 100%. Vim ze to muze kdykoli znova zdechnout ... ale stejne tak vim, ze to do max 2 dnu zprovoznim (a to s tim, ze kdybych to chtel resit jako primarni ukol ... tak klidne do hodiny).
Kdepak asi udelali soudruzi chybu?
bezte uz s tim PR do prdele....
tady se prakticky casablanca stavi do role postizeneho.
to ze to maji zatopeny - to je smula... nemam jim to za zly.
to ze to trva .. dneska i v maly kancelar je problem najit na zalohy okno, protoze vsichni maji disky jako krava a dat jeste vic. tak taky nic proti tomu.
tohle vedeli a meli zakaznikum dat pravdivou informaci, aby ti, kteri byli na vypadak casa pripraveni, mohli zacit jednat.
co tam maji za techniku nebo ve smlouve s timto nema vubec co delat....
A k tomu působení v oboru. Očividně máte rád analogie, nabídnu jednu, abyste snáze pochopil. Představte si firmu, která prodává 15 let motorky s 99% zárukou, že dojedete do cíle, pak začne prodávat čtyřkolky a začne na ně dávat 100% záruku. Když se zjistí, že je to blbost, protože někdo musel přespat někde v lese, protože se nedovolal asistonční službě tohoto prodejce, tak se bude obhajovat, že je problém v tom, že se jedná o čtyřkolku a s nima ona to neumí, protože 4 kola místo 2.
Tuna je dolezite rozumiet technologii ktoru pouzivate, od toho sa odvija vsetko.
Casablanca podla ich vyjadrenia robila snapshot celeho diskove pola ktory odlievali do ineho datacentra. Tento snapshot ale skoro vzdy sposobi rozbitu databazu (akukolvek) pokial je tato databaza aktivne vyuzivana.
Databaza si vela dat a transakcii cachuje do ramky, zaroven pri zapise ak nieje tak nastavena cachuje data este filesystem cache. To znamena, ze sa moze udiat velmi vela zmien nez sa nieco prejavi realne na datovom ulozisku a teda v tych zalohach tie data niesu aj ked sa spravil snapshot v dobe, kedy tam tie data zapisane boli.
Databazy sa musia zalohovat vzdy este navyse inak, ako samotny filesystem. Je potreba zabezpecit konzistenciu dat z databaze a to vyzaduje aktivne kroky pred zapocatim samotnej zalohy.
Chapem sice ze vacsina ludi toto nevie, ale hold neznalost ma svoje uskalia a je nutne aby ludia vedeli na com ich data bezia, co vyzaduju a aktivne sa o to zaujimali. Inak vam samozrejme nepomoze akykolvek poskytovatel.
Pokud resim skutecne vysokou dostupnost a 87% vykonu mam na jednom miste, tak je asi neco spatne :-) Ekonomickym aspektum rozumim. Vy se rozhodujete o tom, ze mate jeden zalozni server na buhvikolik produkcnich. Ale k podobnym kompromisum dochazi vsude kolem nas :-)
Amazon se jako priklad pouziva casto, ale i ten vypadky postihly. A bud zakaznici o data prisli uplne, nebo cekali nekolik dni, nez je budou mit zpet. Ale to bud nevite, nebo to nevnimate. Lide si spojili pojem cloud s tim, ze jejich data jsou automaticky na nekolika mistech. Jenze to je moznost, kterou cloudova reseni nabizi - nikoliv automaticka vlastnost. A to je dost podstatny rozdil :-)
Jasne ... ono zvednout telefon ... rict "chcije sem voda proudem, musime to cely vypnout, skody minimalne ve statisicich ... odhad radove dny" => 10s ... to je strasnej problem.
Neni rec o psani nejakych elaboratu na 30 stran ... ale o kvalifikovanym odhadu situace, cehoz by kazdy technik na svem miste mel byt schopen.
A samo, pokud jsem presvedcenej o tom, ze neco udelam za hodku ... tak reportuju 3, prave proto, ze vim jak to chodi, a ze se muzou vyvrbit dalsi veci. Porad lepsi, kdyz po 40 minutach pak nahlasim ze je opraveno ... nez kdyz po dalsim 1/2 dnu neni videt svetlo na konci tunelu ...
Podotykam, ze informace za jak dlouho bude problem vyresen je naprosto klicova pro naprosto vsechny zakazniky - jim je uprdele jestli chipnul switch nebo vyhorel barak ... je zajima, za jak dlouho jim jejich veci pojedou. Samo, nekdy se to tezko odhaduje (povodne/zemetreseni/...) ale v takovym pripade predpokladam alespon pravidelny denni reporty o aktuali situaci.
Tohle je ten nejhorsi alibisticky nazor.
Kdyby jste to vedel hned, ze praskne potrubi nekde, tak by jste vcas byl pripraven neco delat?
Kdyby jste byl trochu soudnej, tak rozhodne zalohujete a pak neni problem behem peti minut presmerovat domeny u stejnyho poskytovatele na jinych serverech.
A obzvlaste pokud mate nejake sve zakazniky a nezalohujete, tak jste podle meho nazoru amater nejvetsiho kalibru poskytujici nebo preprodavajici sluzby, kde v takovych pripadech nejste schopen garantovat zadnou sluzbu.
Firma stále pracuje na obnově zákaznických služeb a zvažuje další právní kroky, včetně podání trestního oznámení. - no rekl bych, ze nekteri zakaznici zvazuji totez, ale vuci Casablanca INT - ono preci jen replikace cloudu a 100 % dostupnost je neco jineho nez casta zaloha a chybejici technologie pro realizaci zalozniho behu systemu. S tim asi bude nakonec souviset i postoj pojistovny k nemajetkovym skodam - usly zisk apod.
podle jejich vyjadreni na FB
Vážení zákazníci,
rádi bychom Vám upřesnili, jak funguje geografická záloha primárního pole a tím i osvětlili nastalou situaci....atd.
viz
https://www.facebook.com/CasablancaINT
replikace a 100% dostupnost v jejich podani znamena castejsi zalohovani mimo vlastni sit
jinak receno - podle jejich prohlaseni zadny zalozni cloud - funkcne totozny obraz primaru nebezi, neni a jen zakaznici jsou hlupaci, ze si jejich slova tak vysvetlovali a oni to ted v tom prispevku na FB tem hlupakum objasnuji. :-)
Já to beru ze svýho pohledu zákazníka. Pro mě je obnovení mýho jednoho serveru rychlovka v porovnání s tim jak dlouho musim čekat než se dočkam obnovy u Big Blue One. Čekal bych, že takhle vychvalovaná technologie to bude umět o dost rychleji. Takže když budou mít dvakrát víc zákazníků a dvakrát víc dat, tak místo 5 dní budu čekat 10 dní? A to že tisíc serverů bych obnovoval pomaleji to mě nijak neuklidní, protože já mam jenom jeden server a ten obnovim v řádu hodin a nemusim na to čekat 5 dní ani 10 dní.
Že musim měnit olej, dofukovat kola takové informace bych čekal v návodu v obsluze, nikoliv v marketingových materiálech. Ale to, že budu čekat pět dní na výměnu prasklé žárovky u předního světla (a nebo 10 dní pokud si auto v daném roce místo 10.000 lidí koupilo 20.000 lidí), to už je důležitá informace, která by měla být v marketingových materiálech, protože podstatně ovlivňuje moje rozhodnutí při výběru nového auta.
Vy jste viděl projektovou dokumentaci, sledoval vlastní výstavbu a jste obeznámen s detaily, že hovoříte o šlendriánu? Nebo pouze v diskuzích vynášíte soudy prostě proto, že k problému došlo? Ono bylo někde napsáno, že serverovna je vodotěsná? :-) Rád bych takovou serverovnu viděl - podle mě žádná v ČR Vaše kriteria nesplní :-)
Internet je vůbec plný chytráků, co vědí nejlépe, jak se věci mají dělat. Jen se divím, že nepodnikají v oboru, když jsou všichni tak geniální :-)
no tak i když nejsem profesionál, tak mě je jasné, že když proleju serverem vodu, tak už ho nechci. že to je drahý sem ani netahejte - snad tu máme pojišťovny a to si platíte tak jako tak.
pak mě je jasné, že je lepší vyjít s pravdou ven, protože cokoliv jiného situaci akorát zhoršuje - toto jsem zjistil již někdy na základní škole.
jsem jen malý freelancer - přesto od pondělka nepřestal zvonit mobil a chodit sms. nemám na to tým lidí - aby jeden odklonil volající, další řešil obnovu serveru a další řešil běžný provoz.
přesto se mě podařilo stabilizovat situaci.
takže prosím pohádky o tom, jak se casablanca hroutí pod dotazy klientů jsou fakt komické. ono asi těm adminům, co to tam měli nikdo nevolal?
stačilo říct pravdu bez jakékoliv prognozy. ušetřili by si hodně telefonů. minimálně od takových amatérů jako já, kteří svým laicky posoudí, že na to serou a jdou si obnovit server ze svý neprofesionální (ovšem ale konzistentní) zálohy jinam a casablancu nechají svému osudu. pak by stačilo, když obchodník pošle slušný omluvný email a třeba by se dalo uvažovat i o další spolupráci, protože co si budeme povídat nehoda se stane a ať se snažíte sebevíc, průser se může skrývat za každým rohem.
ovšem to je jen pohled amatéra... profíci to dělají patrně jinak.
Já pracuji jako operátor hotline u jednoho českého poskytovatele.
Problém je, že technici, kteří v lokalitě pracují většinou nepřikládají velkou prioritu kontaktovat hotline, že je nějaký průser. A jelikož lidi z hotline žádné jiné informace nedostanou, dozvídají se většinou vše až jako poslední, ve chvíli kdy jim to řeknou sami zákazníci.
Nestojí za tím tedy úmyslné klamání, ale naprosté sraní na informovanost hotline, které má většinou z celé firmy nejmenší prioritu co se _všeho_ týče (od platů, po informovanost, školení ale i kancelářské prostory a IT vybavení).
Ono to vypadá, že Casablanca skutečně běžně slibovala a nabízela něco jiného, než nakonec zajišťovala.
http://www.hardyn.cz/nas-casablanca-obelhala-podvedla-poskodila/
Vím, že někteří diskutující prohlásí, že je hlupák, kdo nemá ve smlouvě i rychlost blikání kontrolky, ale i tak to vypadá, že se Casablanca INT mohla dostat tam, kde solidní firma nemá co dělat.
Pracovníci Casablanca INT vystupující v anonymitě tady v diskuzi, prosím ,na příspěvek nereagujte, ať z toho není další flame.
ano atomizace je zdrobnovani problemu na venek. ale jako CELEK to beru jako cloud (plne skalovatelne, kdyz chybi vykon vypushuji se dalsi nody dle potreby, je to geograficky oddelene, nema to v distribucni fazi zadnou centralni ridici strukturu je to proste "mraky" atomizovanejch problemu)
tj neco jako kdyz kral posla 6 samostatnych poslu samostatne, stacilo kdyz z MSG dojel jeden - to byl takovej predchudce cloudu. misto aby poslal JEDNU silnou druzinu aby spolecne byla silnejsi poslal 6 malejch picmundu a doufal ze projdou.
Ale těch plus 30% je třeba částka, kterou zákazníci už nezaplatí. To je klíčový problém. U webhostingů jste si tím nesmyslným tlačením ceny dolů za každou cenu dokurvili trh už dávno. A všichni víme, že za těch pár korun se prostě nemůže z pohledu technické podpory vyplatit zákazník, co jednou za měsíc napíše, že něco potřebuje a žere čas technika :-) A samozřejmě to přenášíte i dál.
V momentě, kdy to není domácí bastl a jde o rozsáhlé datová úložiště ta obnova nějaký čas potrvá. Neustále hovoříte o přesunu bůhvíkolikaset TB dat z úložiště B do úložiště A, jako když si kopírujete fotky z dovolené.
Na kauzách Seznam či Amazon je demonstrovatelné, že několik dní není nic neobvyklého. Je to smutné, běžte jim tam honem říct, jací i tam jsou amatéři :-)
Na screenu webu najdete 100 % smluvní garance. Na to vám každý soud řekne, ať ukážete smlouvu. A tam uvidíte, na co se ta garance vztahuje.
Škoda na svém webu tvrdí „Výhodné financování s bonusem 30 000“, které platí, jen když poslední splátkou zaplatíte 30 % ceny vozu. Šup šup, vyrazte se soudit ;-)
Bohuzel mam stejnou zkusenost, zrejme jako jeden z prvnich "vytopenych". Je tomu cca dva roky zpet, kdy nase servery byli umisteny v serverovne HC2, zkrz kterou vedla stoupacka ze strechy, (vede tam do dnes) ktera slouzi jako odvod destove vody a ta samozrejme praskla (velice by me zajimalo co prasklo ted). Nam protekla voda rackem od shora dolu jako zazrakem jsme byli jedini koho to poskodilo a dalsi zazrak byl ten, ze servery to prezili bez ujmy. Co byl dalsi zazrak, ze jsem se ten den v sobotu vydal jentak zkontrolovat servery. Vsude se valel rozmoceny sadrokarton a kapala tam voda ze stropu. Zvedl jsem telefon zavolal na tech. podporu, ze jim tam tece voda a ONI O TOM ANI NEVEDELI, nebo vedeli a mlzli nevim. Prijedu druhy den vsude bordel po delnicich a servery zas**** od stuku. Mozna jsem timto sestym smyslem, kdy jsem jel do serverovny zkontrolovat servery, zachranil tenkrat HC2 od podobne katastrofy, ktera se stala v HC8, kde bych to teda ja osobne vubec necekal. Kdyz jsem je na tech. podpore serval co si jako mysli (technik byl dost arogantni), dali mi kontakt na nejakeho jejich reditele a ten mi slibil vyhodne smluvni podminky jako nahradu a presun do lepsiho salu (muzu dekovat jenom vyssi moci, ze to nebylo do HC8), ale bohuzel asi jenom jak se lidove rika "na hubu" protoze mi pak nekdo na zak. podpore rekl, ze to ani nemaji nikde vedene a radsi to poznamenaji. Nabidka byla vyhodna tak jsem o cele situaci pomlcel az do ted. Fotky z te havarie v HC2 mam, mozna proto mi vysli vstric, aby se nestalo to co se stalo ted a nikdo to nerozmazaval. Ted me to mrzi, mozna kdybych to nekde rozmaznul, nemuselo se tohle stat.
Panove kdo z vas presne vi co tam ve skutecnosti maji? Ruku na srdce, vite vubec o cem vlastne mluvite? A jake je tvoje reseni, ze takto odvazne konstatujes ze je nejlepsi? :-D A nenapadlo vas tady si uvedomit ze mit nejvetsi cloud v cechach je taky v pripade vypadku mega pruser? A ze ta obnova trva tak dlouho prave proto, ze jsou toho tera a terabajty dat? Dyt jste ku..a profesionalove v IT tak si to umite predstavit, ne? To ze se to stalo je samozrejme neomluvitelne, ale myslim, ze se do zadku urcite ted nekopou. Zamyslete se trochu!! :-(
ja zalohuju a s obnovou jsem zacal hned, jak jsem se dozvedel, ze jim nachcalo do serveru - coz nebylo po tom co jim tam nachcalo, ale za nekolik hodin. takze pripraven jsem byl a zacal jsem to resit hned, jak jsem se z jinych zdroju dozvedel, ze tam je voda. kdyby me ti zmrdi nelhali, tak jsem to mohl resit uz v poledne.
takze co tu jeste chcete za casablancu okecavat? ja pripraveny byl oni nikoliv. jen jsem si myslel, ze mam hosting u seriozni firmy a ne u bandy lharu.
Tak verim, ze nejake switche nejely :)
Jinak kdyby se ucili u zmineneho pana, tak to takhle nezvojtej.
Jen lituju tech techniku, kteri asi nemeli poslednich 24h moc klidu. Protoze i pres jejich snahu asi plno lidi odejde. Ne kvuli nehode, ale kvuli tomu, ze se casablanca stala v komunikaci neduveryhodna. Muzou podekovat tomu, kdo rozhodl o tom, ze se budou klienti krmit kravinama.
Budte radi, kdyz aspon obnovi ta data... Videli jste nekdo vubec ze by k necemu z hlediska redundance nejaky "Cloud" byl ? a vite vubec co to je vlastne Cloud ? Naprosto nesmyslne marketingovane slovo. Vsichni si to pletete s Clusterem ... Vsichni cpete data do sluzeb typu Amazon, Office 365, gmail, .... vite jaka bude sranda az spadne nektera z techto sluzeb, ktery jsou podstatne vetsi ....... 14 dni se nebude prodavat chleba....
Ja bych si do celku slozeneho z vice nez 4 serveru do 10TB max velikosti nedal nikdy nic, je nadlidsky ukon to pak v rozumnem case obnovit :-)
S těmahle tydýtama jsme loni víc jak měsíc řešili, aby laskavě přepojili gigovej uplink pro celej rack do jinýho switche, pač cokoliv ze sítě UPC jede jen 10Mbps. Furt tvrdili, že problém bude určitě jinde, a když jsme sami v zoufalství přepojili rack na záložní 100Mbps (jinej segment jejich sítě) najednou to jelo bez problémů. A stačilo přitom zvednout prd*l ze židle a věnovat tomu 5 min, místo psaní dlouhejch mailů jak to nejde.
Podle dat, ktera po obnove chybela jsme odhadli zalohu nekolik hodin pred padem. Ale jde o ty naborene MySQL tabulky.. a jestli jejich zaloha probiha na urovni filesystemu, jak se pise v prispevku nize.. tak se ani neodvazuju rikat o obnovu konkretnich tabulek.. Hodim tam vlastni zalohu ze soboty at to uz konecne jede.. a stehuju..
tak snad nemaji jen tu jednu posledni - preci musi mit predeslou - dokud nevim jestli zaloha probehla ok, tak preci nemazu tu predeslou - i kdyz tady uz je mozny cokoli
aniz bych chtel slovickarit - zaloha je to, z ceho dokazu system a data obnovit, pokud mam nejakou hromadu dat ze ktere to obnovit nejde, pak nemam zalohu, tak to proste je
Lidi nečtou, nebo nechtějí číst. Za blbost se holt platí :-)
Z webových stránek: Cloud BIG BLUE ONE využívá technologii 3PAR remote-copy k vytváření geograficky oddělené zálohy dat. Data jsou tedy replikována do fyzicky vzdálené lokality, a tak je zcela eliminována možnost jejich ztráty. Tyto lokality jsou propojeny rychlostí 2 x 8Gbps pro aplikaci Disaster Recovery.
Na diskovém poli se vytvoří bitová kopie a replikují se pouze změny, takže samotný proces replikace nijak neomezuje zákaznické aplikace. Tzv. snapshot (kopie) se tvoří každých 60 minut.
Jestli z toho textu někdo odvodil, že jeho služba má server a úložiště s geografickou redundancí, tak je pitomec on sám :-) Jasně se mluví jen o geograficky oddělené záloze.
Pak si asi ten zákazník tu smlouvu a všeobecné podmínky pořádně nepřečetl, jeho boj.... :-)
6.1. Poskytovatel se zavazuje poskytovat Službu BBO v rozsahu a kvalitě podle Smlouvy a nepřetržitě, pokud tomu nebrání okolnosti, vyjmenované v obecně závazných právních předpisech (např. nemožnost plnění ve smyslu § 352 Obchodního zákoníku, okolnosti vylučující odpovědnost Poskytovatele dle § 384 Obchodního zákoníku nebo omezení a povinnosti vyhlášené na základě ústavního zákona č. 110/1998 Sb., o bezpečnosti České republiky).
Setkal jste se někdy s pojmem vyšší moc?
Každá technologie má své výhody i nevýhody. Lidé rádi vnímají jen ty výhody, ale často zapomínají na nevýhody a rizika, které to může přinést. Samotná volba mezi vlastním fyzickým serverem a serverem virtuálním je čistě na zákazníkovi. Práce s velkým objemem dat nějaký čas prostě zabere a je dost naivní myslet si něco jiného.
Když nemáte na starosti smlouvy, jak tedy můžete vědět, co bylo skutečně jejich obsahem? Nebo zde děláte jen závěry z toho, jak si tu smlouvu někdo jiný ve vašem okolí vyložil? :-) Pak spíše doporučuji udělat si pořádek uvnitř vaší organizace, zjevně tam máte problém s předáváním přesných informací.
Oni do marketingových materiálů fakt nenapíšou, že kvůli žárovce musíte do servisu, jelikož její výměna je složitá operace, kterou amatér bez potřebného speciálního vybavení sám nezvládne a rozebere se kvůli tomu půl auta :-) Ano, i taková auta na trhu jsou a do marketingových materiálů to nenapíšou.
Účelem marketingového materiálu je produkt vychválit, ne upozorňovat na problémy. Spousta lidí to očividně má problém pochopit :-)
Zalohovani SQL databazi snapshotama je pri spravnym nasazeni zcela bezpecny a je ale technicky resitelny. MS Windows podporuji WSS a vetsina SQL databazi ma WSS API, takze hypervizor ma moznost SQL serveru oznamit ze se provadi snapshot. Stejne tak v Linuxu je podpora pro guest-fsfreeze. Spis je otazka jestli to meli v BigBlueOne spravne naimplementovany.
Pokud už se bavíme o přesném vyjádření dostupnosti, pak je u těch procent vždy potřeba uvést, za jaké období se to sleduje. Nechápu, jak může někdo šermovat devítkama a to období neuvést. 99 % ročně znamená, že to klidně nemusí běžet tři a půl dne v kuse, 99 % denně znamená, že výpadek nemůže být delší než 15 minut (ale může být každý den). Bez uvedeného období je snadné garantovat třeba 99,99 %, protože když to týden nepojede, prohlásíte, že ale příštích dvě stě let to pojede bez výpadku, a máte splněno.
Tecie im voda na servre a oni neinformovali zakaznikov! Bohuzial sme nato prisli, az ked sme tam osobne prisli a to nam medzi tym vyskratovalo 15 servrov. Preco ked im tecie voda na servre, tak ich nechaju pod prudom? Maju vobec rozum?
Mame skodu za niekolko sto tisic.
Dakujeme!
tak jsou to adaptované prostory je jasné že když je nad tím 17 pater ZTI instalací tak to může kdykoliv kdekoliv šlusnout.
Navíc Stimu to bude asi šumák protože je to prostě bežná provozní věc budovy, jen to má fatální následky na ICT ale s tím se mělo počítat.
Teoreticky by nebyla ostuda to mít zabezpečeno právě nějakou plexi záležitostí protože je tam ještě jedno patro dole tj pořád to má kam odtéct. Rozhodně by to vyšlo levněji než současná škoda, a to se bavíme o 300 tisíc vs cca dva miliony co je to bude stát na reputaci. Finanční škody jdou asi za pojišťovnou a pokuď vím tak je velké štěstí pro Casablanca INT že to nebylo větší protože limit bude asi někde jinde než 100% cena technologiíí (o škodách provozních nemluvě).
Na celé věci je pro mě nepochopitelných několik věcí:
Za prvé jsem byl informován, že poškození části diskového pole neohrozí funkčnost webových projektů. Bylo nám řečeno, že výbuch bomby neovlivní, ale kdo ano. Zde došlo k zásadnímu klamání zákazníka, protože „cloudová“ služba, kterou nám Casablanca poskytuje, k mému šokujícímu zjištění, funguje podobně jako server před deseti lety doma pod stolem. Přepětí? Vyhoření? Polití čajem? Tak koupím nový disk a obnovím zálohu... nemohu si odpustit WTF? To je služba za desetitisíce měsíčně?
Za duhé, když kompletně pominu tento archaický přístup, o kterém si všichni klienti Casablancy mysleli, že je nemožný. Přeci jen jsme byli přesvědčováni o modernosti řešení a podobně. Velmi mě zajímá, jakým způsobem bude Casablanca kompenzovat vzniklé škody? V našem připadě se jedná o ztrátu z bannerové reklamy. Pokud dostanu na tuto otázku smysluplnou odpověď nebudu Casablancu jako poskytovatele služby měnit. Věřím, že to bude dostatečným poučením.
Je to jak píšete. Jeden náš zákazník tam měl server a místo aby vypli elektriku a bránili škodám tak mu server nechali prolévat vodou pod napětím. Ještě v době kdy na netu byly k nalezení fotky uveřejněné i v článku, technická podpora tvrdila cosi o výpadku switchů a opravě do pár desítek minut.
připojím svů názor, že to není první případ,kdy společností Casablanca INT pohnuly kontroverzní události.
Prolití několika serverů vodou z rozbité klimatizace, kde došlo ke značnému zkrácení jejich životnosti, a po nějakém čase vypnutí obou nezávislých přívodů (měli jsme speciální vyžádání dvou nezávislých okruhů) do diskových polí, kde jsem během zálohování přišli nenávratně o část dat (poškození jak zdrojového, tak cílového filesystému) zapříčinilo v roce 2008 náš rázný odchod od společnosti Casablanca INT a vybudování datových clusterů zcela od začátku a především jinde.
Důvody byly následující
* chybná ochrana před podobnými škodami (špatné chlazení a zásadní chyby v procesech techniků) a vůbec fakt, že k podobnému incidentu může dojít
* neinformování zákazníka, že došlo k havárii - že rackem protéká jakási tekutina a na serverech jsou louže jsme zjistili náhodou při osobní návštěvě.
* následný problém s řešením škod a o vyčílslené částce, ketrá se tenkrát blížila 2 mil. korun, jsme si mohli nechat jen zdát (dostali jsme zanedbatelnou kompencaci v podobě slevy ,a i ta byla podmíněna odběrem dalších služeb).
Od té doby si velmi vybíráme dodavatele služeb a než podepíšeme kontrakt, provádíme kontrolu faktů v dané smlouvě. Takto jsme se vyhnuli dalším serverovnám v Praze, kde byly nabízeny služby, které následně neodpovídaly realitě.
Proto důrazně doporučuji jako jeden z faktorů při výběru nezahrnout pouze cenu,ale také kontorlu,co nastane, když ... Je také nutné se na tyto situace připravit vnitřní infrastrukturou, několika nezvislými linkami, online zálohou nejen dat,ale také produkčních technologií, tak aby výpadek jakékoliv části systému měl za následek minimální výpadek.
Věřím, že drtivou většinu z Vás tato událost poučí propříště jako nás.
Pokud má někdo zájem o podrobnosti, rád poskytnu osobní zkušenost.
Michal Ceé
Web4ce s.r.o.
Souhlasím s Vámi ve všem, co jste zde napsal. Fušeři a diletanti, kteří by za 300 měsíčně chtěli "cloud" se dvěma geograficky oddělenými serverovnami, zálohu neřeší, protože ji přece řeší poskytovatel, pro které 100 % smluvní dostupnost znamená 100 % vždy a za všech okolností, a místo, aby si přečetli smlouvu a zjistili, co že to ta smluvní dostupnost je, řídí se svými domněnkami. Jojo, kdyby hloupost nadnášela, tak je v "cloudech" poněkud přeplněno :-)
Ano máte pravdu jsem to nenapsal přesně, zákaznící to chtěli tak převlékli virtualizaci a uha byl to cloud.
Tak prijde na navstevu, je to sice privatni cloud ale jedna se o dveste serveru ve trech lokalitach kde vse bezi cloudove (proste se na dany server namapuji role a on si to vytaha z distribuovaneho uloziste) tj pokud neco spadne (vzdy bezi nejmene dva popy pro jeden projekt) a pokud jeden sezle tak nastane
- vyrazeni z DNS
- sosnuti IP neumrelym bodem
- pseudoefekt kdy diky schopnosti modernich browseru poznaji obycejnej leta proverenej round-robin a proste zkusi druhou site.
dostupnost opravdu dobra (diky dvou lokalitam).
Dal vam muzu ukazat cloudo uloziste tvorene 320 nody ve 4 datacentrech (3x cr, 1x slovensko) ktre je immunni i napr proti pozaru celeho datacentra (projevi se to jen snizenim redundance) data nejsou ulozena v raidu nebo nejakem forme pole (proto narozdil od casa jsou ta data zcela izolovana a neexistuje neco jako pad vseho nebo nehrozi ztrata metadat co tvori nejaky vetsi logicky celek) ale fyzicky jsou umistena ve vice lokalitach (nejcastejsi datovy typ je ten ze jsou 3 fyzicke kopie).
Nu abych si nehonil triko a rikal ze nase CDN je plne cloudove tak zminim primou konkurenci. www.cdn77.com a verim, ze v cechach provozuje cloud jako "rich cloud" minimalne desitka subjektu. Plus dalsich nejmene 50 (bavime se komercne tj co si muzete koupit) provozuje virtualizaci s vyrazne cloudovymi prvky (ziva migrace za chodu, distribuovany fs). Moznost poustet klony, repliky a odvozenini pre-instalovanych serveru. Myslim ze radu ceskych hosteru velmi podcenujete.
Ano skutecny cloud ala amazon aws, nebo microsoft azure neprovozuje nikdo resp neni na to poptavka, ale API controled managovani instanci ma v cechah opravdu hodne subjektu - vic nez si myslite.
A co měl udělat? Natvrdo to všechno vypnout a sestřelit elektriku natvrdo? Jste si jistý, že by pak ty škody nebyly možná í větší? :-) A kdyby měl s konzolí obíhat všechny servery a korektně je shutdownovat, má práci na celé odpoledne. Řízený shutdown větších systémů není operace na pár sekund.
Nezapomínejte, že ve veřejných datacentrech se narozdíl od firemní serverovny neprovozuje nějaký systém řízeného shutdownu, kdy UPS dokáže shodit skupinu serverů. ACPI nemusí být na serverech nakonfigurované korektně, klávesnice může být zablokovaná atd. Že voda teče vnitřkem stojanu poznáte, až když jej otevřete.
Plácat o tom, jak měl někdo jiný něco udělat je snadné :-)
Na incident se casem zapomene stejne, jako se zapomelo na desitky jinych problemu v minulosti a ponauceni si malokdo vezme.
Mraky sluzeb kolem nas jsou ve skutecnosti zavisle na jednom konkretnim baraku - a je fuk, na jake je to adrese, podstatne je, ze je to jedna konkretni fyzicka lokalita. A presto, i kdyz neslibuji celych 100%, devitkami se to v propagacnich materialech jenom hemzi, garantuji se opravy v radu minut atd. I kdyz musi byt nad slunce jasne, ze takovemu slibu dostat za vsech okolnosti proste nelze. Vinik je tezko urcitelny - poskytovatel by asi nemel slibovat nerealne, na druhou stranu ani zakaznik by nemel mit nerealne pozadavky a ocekavani. Potiz je, ze obchod na obou stranach obvykle uzaviraji ti, kteri technice do detailu nerozumi - a neni nic neobvykleho, ze obchodnik uzavira smlouvy bez konzultace s techniky. A to i na strane odberatele a vznikaji tak v budoucnu casto ne uplne mila prekvapeni pri zjisteni skutecneho obsahu plneni.
S nekompetentnosti se potkavame na kazdem kroku vsude kolem nas. Zijeme v hekticke dobe, kde dulezitejsi je spravne vypadajici prezentace subjektu nez kvalitni fakticke reseni. Podvodnik s vytunenymi webovkami uzivajici spravne moderni slovicka ma mnohem vetsi sanci na uspech. V mode je ted jednoduchost, kde projistotu skoro zadne informace nejsou :-) Spousta technologii nejsou zadnou novinkou. Pouze se oprasili stare zname koncepty a natiskla se k tomu jina nalepka. Ale zakaznici chteji tu "vytunenou" nalepku :-) Ale nezajimaji se prilis o to, co pod tou nalepkou maji. Bezhlave migruji data do cloudu a neuvedomuji si, jaka jina rizika to prinasi. Seriozni analyza rizik je vubec neco, co se v dnesnim podnikani nenosi. Prusery se resi, az kdyz vzniknou, malokdo je ochoten jim predchazet. Bohuzel nekde vznikl pocit, ze kdys se nejaka data nahraji do cloudu, tak tyto poletuji pokud mozno kolem cele zemekoule :-) Ale cloudove reseni si clovek muze postavit i v kumbale doma.
No jo, jasně. To tedy budete hodně nemocní. Co jste to tak asi nachytal za nemoc v tý Casablance :-)
Bože já se směji. Samozřejmě Kverulante aka PR Casablanca - všichni diskutující jsou pitomci a Casablanca poskytuje služby zcela v intencích které slibovala.
Tak a teď prosím další pohádku na dnešní den.
Tak znova od zacatku ... kdo ze tu slibuje !100%! dostupnost HW?
I pokud budu slibovat "smesnych" 99% dostupnosti, tak proste MUSIM byt zarizen na to, abych byl schopen tech 99% zajistit. Tudiz ... v takovem pripade, pokud se bavime o jednom mesici ... MUSIM byt schopen po zcela JAKEMKOLI i naprosto TOTALNIM vypadku obnovit provoz DO MAXIMALNE 7 hodin.
Jasne?
Zakaznika naprosto nezajima jak to udelam. On si PLATI za to ze to udelam. Je pak jen na me abych stanovil takovou cenu, ktera mi pokryje prislusne technicke zajisteni.
A paklize nejstem totalne retardovanej magor (coz v case zjevne jsou), tak moc dobre vim, ze obnovovat data odkudkoli nejak dlouho trva ... tudiz prave proto, mam druhe, treti .. nebo i ctvrte pole, kam se data replikuji prubezne, a zcela samozrejme geograficky jinde.
A pokud ta pole nemam, a vim, ze obnova dat bude trvat tejden ... tak nemuzu nabizet vic nez nejakych 70% ... ze.
Je uplne jedno kolik zaloh maji, to je principielni technologicke omezeni. MySQL nedokaze udelat bez zastaveni spolehlive pouzitelnu zalohu. A protoze zakaznici takove zastaveni tezce nesou, tak delame zalohy vzdy z replik databazi. Jenze pak se musi resit zalohy na "aplikacni" urovni, tohle zadny poskytovatel virtualnich serveru bez pristupu dovnitr virtualu vyresit nemuze.
Jinými slovy je chyba věřit, že 100% je lepší než 99,9%? To je výborná rada. :) Ne v pohodě, nic ve zlém.
Já bych uvítal, kdyby se v důsledku této zkušenosti kultivoval trh a 100% by se přestalo uvádět u služeb, které 100% nejsou. Víte, že řešení založené na jedné serverovně, je náchylné na výpadky v důsledku mnohem pravděpodobnějších událostí než prasklé potrubí.
Už mi připadne férovější přístup amazonu, který zrovna řekne, že při dostupnosti menší než 99% (měsíčně?) vrátí 25% z ceny.
Jelikož nejsem zaměstnancem, tak vyjádřím svůj názor:
1, Klamání Casablanca o plné redundanci služby
O odstavec výš píše o plné redundanci dat, tady už o službě. Zřejmě v tom nemá jasno? Zatím mi nikdo nepředložil nic, kde by se výslovně hovořilo o geografické redundanci SLUŽBY.
4, Obnova služeb z disaster recovery – bohužel databáze a její disaster recovery byly v rukou Casablanca...
Pokud vím, obnova z disaster backupu probíhá, takže disaster backup prováděn byl. Mimochodem nechávat zálohy na poskytovateli, které jsou pro případ havárií, a nedělat si své vlastní, případně si nenasmlouvat zálohy přímo VPS za příplatek (nevím, jestli toto Casa nabízí, ale bývá to běžné), je idiotství.
Hovořit tedy v tomto případě o podvodu je lhaní. Ale co se divím. Je úplně normální, že jsou lidi schopní si půjčit peníze a pak, když jsou zcela dle smlouvy účtovány nemalé poplatky z prodlení, případně přijde exekutor, tak řvou o podvodu.
ZÁMĚRNĚ nerozebírám komunikaci s helpdeskem nebo poskytování informací, ale čistě parametry služby dle smlouvy / podmínek, protože tam dávám za pravdu klientům, že Casa selhala.
Tak znova ... kdyz dodavatel tvrdi, ze na 100% garantuje, ze se nic nemuze stat, pak i miliardy v dolarech jsou prece OK ... protoze se prece 100% nic nestane. 100% = 0,00000.. rizika (nebudu hledat znak pro nekonecny rozvoj nul).
A rozhodne se nebavime ani o stokorunach ani o jednotkach tisic. V pripade kdy jsem toto resil, slo o projekty za statisice a miliony. Pricemz dodavatel tvrdil, ze po nasazeni bude vse naprosto vpohode fungovat, ale zavazat se zaplatit (alespon) provozni naklady (=mzdy, energie ...) nechtel. Samo, zakaznik by to z nich ve finale stejne vysoudil, protoze jde o prokazatelnou skodu, ale smluvni pokuta se vymaha o dost lip.