Názory k článku
České poště hořelo datacentrum na Olšanské, nefungují online služby

Čuchám, čuchám, záložní datacentrum má asi zrovna dovolenou... nebo....? Ne, to snad ne, tomu nevěřím...

Celkem běžná věc DR plán je zapnutí jiného serveru v témže racku na té samé lokaci v tom samém datacentru.
Pak ještě celkem běžné že se DR plány netestuji protože business...
Že dvou startupu po akvizici vzešla otázka co je to DR plán?
Z toho důvodu je dobře schovávat si komunikaci s manazery/ekonomy kde nedílnou součástí mých komentářů je ze neneseme zodpovědnost v případě neposkytnutí penez,casu,li­di,objednavku služby, pravidelně testy atd. Lide kteří o tom rozhodují na svou odpovědnost mají krátkou paměť. Je dobré pro klidný spánek aby byl člověk z obliga, případně to nechal někomu sezrat (zařídit aby muj šéf nebo někdo z boardu zařídil že bude odejit) Mám maily 8 let dozadu.

Pořád jim ale ještě běží čas. Některé "ekonomické" DR plány počítají v řádech dnů s vypadkem.

Zažil jsem ale I situaci kdy součástí DR plánu byl přelet s paskami helikoptérou a spojení přes vsat spoj když v new Yorku radil hurikán. Mít burzovní datacentrum pod úrovní moře je geniální tah...

A co slavné https://www.datoveschranky.info/ ?

"Omlouváme se, probíhá plánovaná výluka Informačního systému datových schránek."
- zřejmě údržba žehem...

Slušná příprava na GDPR.

"Kdy se 'výkonní' političtí manažeři poučí?"

IT systemy navrhuji a zprovoznuji "politicti manazeri"??

Ne, ale platí to. A pokud máš na výběr platit druhý datacentrum, nebo ty prachy utratit za něco jinýho, přes tři prostředníky u kamaráda, není co řešit.

Kolik lidí taky ví jestli na druhém konci ta mašina je a jestli je nastavena. Jestli ji podle té powerpointove prezentace opravdu někdo rozjel... Místo toho dostal někdo na kafe a zjistí se to až při prusvihu...
Na místo se dostaví někdo z (3 pismenka), shleda že papírová dokumentace je v poradku a nebude ho zajímat že server v racku neni. Protože netuší co je datacentru, rack a nebo server. V podstatě mu člověk může ukázat blikající raspberry pi s inventarnim číslem jež papírove odpovida.

Bohužel ano. Rozpočtovým určením. Někteří radši koupí nový nábytek nebo vymalují kanceláře než pustí prachy na nový server...

Stejny problem je ale v soukromem sektoru. Jen se o tom tolik nemluvi. Manazer se pouci jedinnym zpusobem. Predeslym upozornenim technika a naslednou rozsahlou skodou kterou si uz pak nikdo dalsi nechce vzit na triko. Dalsi veci je delat pravidelne DR testy protoze technologie se meni,updatuje a nemusi fungovat stejne, servery stehuji. Manipulujeme s SW systemy ktere jsou komplexnejsi nez space shuttle.
Z praxe neni problem narazit na to ze servery ktere maji byt ve dvou oddelenych lokacich vam nastehuji po "financni optimalizaci" do jednoho datacentra (prava ruka nevi co dela leva) a pri DR testu zjistite ze vam obe strany upadly. Nasledkem je pojeb manazeru s aktualizaci interniho evidencniho systemu o polozku "musi byt v teto lokaci"/"musi byt v jine lokaci nez system ZYX" / "typ pozadovane oddelene lokace ".
A to je taky duvod proc delat DR testy. Nejen technika se otestuje ale i procesy.

BTW:Jen prosim nepouzivejte slovo "zabezpeceni" To muze mit totiz dva az tri ruzne vyznamy a nemusi jen znamenat "zabezpeceni bezvypadkoveho provozu" (omlouvam se, neznam IT pojmy nasi ukrajiny, IT jsem studoval v cechach ze zahranicnich materialu a v zahranici). Je lepsi pouzivat ustalena slova a fraze nez stravit pul dne vysvetlovanim nedorozumeni ze jsem potreboval sysadmina a ne securitaka nebo auditora. - Sorryjako ale jsem ovlivnen letectvim kde z duvodu moznych fatalnich nasledku nespravnych pojmu je nutno pouzivat schvalene pojmy a fraze).

Pokud majitel firmy rozhodne, ze v dane lokalite horet nebude, dej se vule ....

Pozadavky na tema "naprosto nutne potrebujeme provoz 24/7", aniz by dotycny dokazal vubec alespon odhadnout kolik vypadek bude stat resim opakovane. Vetsinou se pak vsichni divi, ze to stoji penize. A ve finale se z toho vyklube, ze den nebo dva vlastne nejsou zadny problem, coz je prevazne prozmenu hrube podceneni situace.

Zajimave na tom je, ze pomerne casto nastava pozdvizeni pri vypadku nepodstatne casti infrastruktury ("katastrofa, jiz 5 minut nejde internet"), ale pri vypadku jadra infrastruktury (nefunkcni erp a pod) se uzivatele ozvou klidne az po nekolika hodinach.

V mnohych pripadech pak mohou firmy doslova poradat exkurze pro archeology, nebot jejich infrastruktura je souborem vykopavek.

Stále udržujeme ultrasparc II mašiny pro elektroinfras­trukturu v US. Několik AS/360 stále odbavuje letenky. Nevím na co si ztezujes...
ČR má poměrně moderní infrastrukturu.

Jinak jak jsem již napsal výše. Je dobré chladné a profesionálně vyjmenovat rizika plynoucí z daného rozhodnutí a schovávat si komunikaci. U telefonickych diskusi dělat záznam a nebo zápis z jednani. Nemá cenu se rozčilovat nad něčím rozhodnutím. Ten cílový člověk musí nést důsledky svého rozhodnutí ale moji povinnosti jako technika je upozornit ho na rizika plynoucí z jeho rozhodnutí. Je už na něm zda-li jsou přijatelná pro business.
Pokud ne, tak vypracovat řešení s náklady nebo to přehodit na oddělení co to má technologický na starosti.
Pokud ano tak to nechat manazerovi sezrat při nejbližším incidentu nebo problemu. Tím myslím I poslat v kopii na jeho nadřízeného pokud by se vztekal.

Jak se říká. Buď odpovědný, ale jen do výše tvých povinnosti a tvého platu.

Cloud je ve státní správě sprosté slovo protože požaduje nebezpečný inovatorsky přístup což je proti duchu tradic. A taky by to bylo moc levný což je také velký problém.

1. Statni sprava rozjizdi vlastni cmoud
2. Cmoud nerovna se vyresim za vas vsechno. Vzdyt kolik cmoudovych reseni nechava redundanci na oddelenych lokacich na lidech kteri to ovladaji. Stejne to nekdo musi schvalit a zaplatit. Takze akorat prekladame vice efektivneji pacienta na plicni.
3. Nektere aplikace nikdy nesmi byt a nebudou cmoudove. A jejich komunikace bude probihat po linkach ktere vlastni stat a vedou nekam do podzemnich bunkru na neznamem miste.
4. Cmoud nerovna se vyresim redundanci a georeplikaci pripadne cely DR plan. Je to jen abstraktni zahrnuti urciteho setu sluzeb pod nejake administrativni rozhrani pripadne x rozhrani ktere umoznuje rychle deploynout a rozhodovat se. Ano muzu deploynout prostredi behem par minut na sdilene infrastrukture, ktere bude splnovat tyto pozadavky. Stejne tak muzu deploynout i na dedikovane infrastrukture kdy masiny jen cekaji v racku/boardy v backplane. Ale to porad neresi rozhodovani.
5. Statni sprava nebude mit zcela cmoudove aplikace takze to bude muset bezet stejne nekde po VMkach a ne jako servisy/mikro­servisy. Jestlize u vetsich firem ktere maji na starosti kritickou infrastrukturu to muze trvat tak 10-15 let, tak u statni zpravy 2x tak dlouho. Nekdo to musi naplanovat,za­platit,prepsat a deploynout za behu stavajiciho systemu. To neni startup s vymastenymi gelousi co dostali par milionu na kafe. Jen zkuseny vyvojar vyjde na milion rocne.

A to jsme v inovaci technologii mnohem lepsi nez treba USA, kde nektere IT technologie ve statnim sektoru jsou i 50 let stare. Duvodem je to, ze jeste stale nahrazujeme papirovou agendu agendou elektronickou. V minulosti byl totiz i nedostatek IT technologii u nas, telefonnich linek o datovych spojich nemluve. Coz se pochopitelne odrazilo na "historicky zaprdenem" procesnim chapani lidi ve statni sprave nebot paterni datovou komunikaci statni zpravy jeste na pocatku 90tych let byl listovni styk, pokud byl tak telefon,v mensi mire dalnopis, pripadne prevoz disku,disket a nebo sjetin...
Po technologicke strance je to supr nebod zaciname znova, lepe. Po lidske strance je to katastrofa, protoze procesni chapani politiku i vyssich uredniku je na urovni Rakouska-Uherska, kde vznikl system komunikace mezi urady jejimz komunikacnim mediem je obcan, ktery predava lejstra mezi uredniky. Tak to funguje dosud, namisto toho aby si urednici predavali lejstra mezi sebou. To je procesni vec a nikoliv technologicka. Uvedomte si ze se nase statni zprava resi procesni i technologickou revoluci paralelne.
Veci jako ze jakmile sezenete urednika s odbornosti a tento je nasledne po volbach vyhozen a nahrazen nekompetentnim hlupcem ponechavam bez komentare. Dobre to jde videt na stavebnich uradech nebo na odborech dopravy.

V prispevku vyse se dozadujes, aby lidi pouzivali ustalenou terminologii a pak to tady rozjedes se slovem cmoud. Coz samozrejme neni ustaleny termin a i kdyz bys pouzil termin cloud, tak by v takovem pripade tvuj prispevek taky postradal hlavu i patu.

Nejde rozlisit, jestli cmoud = IaaS, PasS nebo SaaS. Kdyz to vsechno zmotas dohromady, tak z toho jde odvodit, ze cloud ve statni sprave nema, co delat. Kdyz se na to podivas jednotlive, vysledek uz bude opacny.

Cmoud je sarkasmus,ironie. Zapomel jsem ukázat sheldonovi cedulku...

Pojmy IaaS, PaaS nebo SaaS neřeším. V rozsáhlých infrastrukturach je těžko můžu vymezit nebo oddělit, protože je to vzájemná interakce a prolínání. Podívej já reším konkrétní nasazení konkrétních technologií, jejich vývoj a nasazení a prusery z praze + komunikaci. Protože většina interakci v mém zaměstnání je inhouse a nikomu to prodávat nemusím. Od toho mám jiné a velmi kvalifikované lidi. Resim konkrétní praci. Můžeš říci že jsem jen technik s rozhodovacimi pravomocemi.

Stejně tak neřeším Web 2.0 ale konkrétní nasazení konkrétní aplikace. Takových buzzwordu už jsem za ta léta v IT zažil.

Mým úkolem je řešit problémy. Ne buzzwordit a dělat prd. Na to neberu dost peněz, nejsem český manažer a mám jen jedno Ferrari... na sekání zahrady.

Ufff, jenom datacentrum? Tak to bylo o fous! Hlavně, že nevyhořel sklad losů, punčocháčů, prošlých vitamínů, slušivých reklamních kloboučků apod. To by byla ČP vyřízená.

https://www.postaonline.cz/ už funguje, tak klid :-)

Jak je vidět, tak nějak záložní plán mají a měli...

Vyfoukali ze serveru saze a natáhli kabely z vrátnice?

na webu se objevily fotky z zásahu v té "serverovně".
Bez komentáře
http://www.hzscr.cz/clanek/pozar-v-serverovne-napachal-skodu-za-300-tis-kc.aspx

>V datovém centru České pošty na ulici Olšanská v Praze dnes dopoledne došlo k požáru.
To nebylo datacentrum, tam jim vyhořel suterén. Datacentrum má SHZ.

"....Pomocí proudu s CO2 se hasičům podařilo objekt prozkoumat, snížit teplotu a uhasit požár u záložních zdrojů. "
OK, tohle chapu, vidim tam vyhorelou UPSku

Nicmene tohle je fakt sila:
"Sdělení ostrahy, že se v budově nikdo nenachází, se ukázalo jako mylné, v pravé části budovy bylo 9 osob, které byly vyvedeny."

V budove, kde bezi datacentrum bych ocekaval mnohem lepsi zabezpeceni a prehled o pohybu osob.

A nebo zmatene pobihali po budove a hledali vhodne hasici pristroje... ;-)

Doufam, ze se objevi detailnejsi informace. Zajimalo by me zda ty sluzby opravdu nejely nebo jen nebyly dostupne pres web.
Nevite nekdo zda behem vypadku jelo http://www.bezpecneuloziste.cz/ ?

Dle soucasnych informaci nehorela serverovna ale jen jeji oddelena cast starajici se o napajeni. Mistnosti kde bezi realne servery mivaji pripravene natlakovane lahve s hasicim plynem. Vzhledem ke sluzbam, ktere diky tomu nebyly dostupne usuzuji, ze tam bezi "bussiness critical" aplikace. Coz me stejne jako mnoho ostatnich privadi k otazce. Je mozne aby opravdu nemeli funkcni pravidelne testovane DR ve forme dalsiho geograficky oddeleneho datoveho centra, ktere v pripade vypadku prevezme chod sluzeb ? Pripadne co zabranilo tomu aby se ty sluzby prehodily ???

Pokud se domenka neexistujiciho DR reseni potvrdi pak je od reality odtrzeny hlavne management...

DR je vždy o ceně a o možných rizicích. Není to lék na vše, předpokládám, že nějaký krizový plán mají, to odpovídá i tomu, že byly schopní to rychle zprovoznit do 24h.

Služby přestaly být funkční až po informaci od hasičů, že tam zasahují, vypadá to spíše na umělé omezení/vypnutí pro potřeby kontroly a výměny. Předpokládám, že mají stovky serverů a takové množství nastartovat bez problémů během 24h by byl dobrý výsledek, spíše to vypadá, že servery celou dobu běžely a pouze došlo k nouzové údržbě infrastruktury nebo konektivity. Odhaduji.

Také bych ocenil podrobnější informace.

Nešlo to 24 hodin. To je pořád DR plán na 24hodin a stále přijatelné RTO.
DR plán může byt cokoliv. Vcetne toho že technik po tom co mu povolí hasiči přesune masinu/pole do jiného DC a poprepojuje a změní zaznam v DNS ( protože balancer buď není a nebo byl jen jeden a v tom samém DC:))).
V některých případech je to přijatelnější než platit provoz clusteru a support.

ztratili wifi spojeni se serverem a tak bezradne bloudili budovou... hledali signal