To muselo být ohromné neštěstí, že půl hodiny nešla Alza. Taková UniCredit Bank už nefunguje 9. den a italští soudruzi se vůbec nevzrušují. Nasraným klientům odpovídá chatbot a vymalováno. :-P
Podle vyjadreni Master spadla jen jedna napajeci vetev. Coz je stale jeste bezny provozni stav v DC. Pokud vsak nekdo nema dvou-zdrojove zarizeni, tak at pote nefnuka, ze mu to spadlo.
Dokud klienti budou tlacit poskytovatele DC do dvou napajecich vetvi (idelane aktivnich) a nakonec si pripoji svuj HW jen pres jeden zdroj, tak verte tomu, ze nikdy nebudou oblibenym klientem.
RadekM
To je docela síla. To je ta část, co byla v Naganu ještě po Volným? Měli jsme tam taky servery a problémy s elektrikou byly tradiční!
Teď jsem už pár let v Masteru... A co myslíte? https://twitter.com/MasterDC/status/918331317430956033
Jo dekuju. Stačí drobet kvůli spammerum přetáhnout bounce rate a odpojí zakosovu firmu komplet od mailu. Podpora co tomu nerozumí. Napytel. Málem se mi z toho zhroutila část tymu. A neuděláš nic. Jses úplně zavislej.
Těch hostingu moc po světě není a chybí bezpečnostní certifikace. Obecně nedůvěra zákazníků.
Za ty slaboulinky instance dáš za rok tolik co za dedikovany hw se správou v datacentru. A neresis kolísání výkonu ve sharovanym prostredi.
Dedikovany hw od AWS je totálně mimo mísu. Tam už se snad vyplatí I vlastní datacentrum při těch cenach.
AWS. Cloudove řešení z minulého století, ceny řešení ze století příštího.
A jestlipak ho chlapci pravidelně testují? A copak dělá servis? To si ho zvou aby ho natočili klikou? Nevysosnul zas někdo naftu a zvedl plovak? Já jen že by to nebyl v českých luzich a hájích ojedinělý pripad:)Vypadá to že manažer je asi jen pajdulak na stížnosti a nemůže nic.
Asi jako já když mi neschvali budget. Musím to pak dát někomu dostatečně sezrat když nastane pruser... říká se tomu odpálení padajiciho exkrementu nahoru...
Za ty ceny očekávám že ten geocluster rozjedou sami a dostanu basu piv jako pozornost zakaznikovi.
Tohle klikání má akorát uklidnit zákaznické dildo a poskytnout falešnou jistotu že rozumím tomu jak to funguje a ze s můžu nastavit redundanci. Jinými slovy že ziskavam dojem operativnosti.
AWSko je zbytečné složité a zbytečně se musíš učit fůru "vendor specific" veci ktere v jiném cloudovem řešení těžko uplatnis.
Pak budeš chtít zmigrovat a zbydou ti oči pro pláč. To že alternativy umí taky S3 API ti je k ničemu protože musíš zahodit know how.
Chlapcům asi teče mliko po bradě že se nepoucili z velkých vendor locku v IT...
Rollback asi dost těžko jde dělat po skoro dvou týdnech v prostředí, kde neustále nabíhají transakce. Jinak na FB lidi stále řvou, že se nedostanou do mobilního bankovnictví, včera nefungovaly platební karty, peníze mizí z účtů a zase se objevují, příkazy odcházejí a neodcházejí podle počasí... opravdu "odborníci". Ale vem to čert, nicméně ta katastrofální komunikace a krizový management, to je teda něco. Na FB odpovídá nějaký najatý dement, co ani neumí česky, na infolinku se nedá dovolat a na pobočkách nevíme, neděláme, neumíme, nic vám neřekneme a v pátek si zavřeme v 16.00 a hurá na víkend. Při tomhle průseru. WTF.
A ano, z tohohle fiaska by rozhodně byl zajímavý článek.
V zasade jde o to, ze pro jakkoukoliv stavbu od luxusni kadibudky pres RD po technologicke budovy existuji tri pristupy:
a) nejdriv se navrhnou inzenyrske site a plan jejich rozsirovani a potom podle nich budova samotna
b) jak se uci u nas betonove hlavy - nejdriv ten barak postavime a pak se resi jak protahnout dalsi VN kabel jak pest z druhe strany budovy kdyz mame dirku jak palec. Jak nacpeme dalsi svazek NN kabelu tam kde mel puvodne vest jen jeden.
c) pouzije se agilni pristup kdy se vetsina veci ve zjisteni pruseru napatla nesourode na sebe a ono to "nejak" funguje. Do te doby nez potrebujem resit inovaci a zavadu.
Pro postup a) existuji i specialni stavebni postupy jak resit budovu tak aby byla rozsiritelna a existujici vedeni nevyzadovalo hluboke stavebni upravy. Uz jen resit to aby se daly privest dalsi kabely v budoucnu a nebo predelat dispozice budovy - napr. odnimatelne steny mezi prickami.
Postup b) zpusobuje velke naklady na postupne prizpusobovani budovy vnitrnim i vnejsim rozvodum. I takova banalita jako pruraz na dalsi NN nebo opticke kabely z vnejsku muze zpusobit zatopeni budovy pripadne kabelovny spodni vodou.
Postup c) byl zrejmne pouzit u casablancy...
Proto si Amazon programuje napájecí systémy sám. Generátory mívají nějaké ochrany proti přetížení, které mají tendenci možná až příliš opatrně chránit generátor. Obecně ale rozumný risk ztráty generátoru od nějaké velikosti poskytovatele není finančně tak bolestivý jako výpadek provozu datacentra.
Zajímavé ale je, že provoz nepřevzali jiné datacentra, které obchod typu alza.cz určitě bude používat. Sázka na jedno data centrum by bylo typické české škudlení, kde se ušetří koruna a ztratí 10...
Telehouse je tak slozity mechanismus, ze chyba se vzdycky nekde najde. Ale pokud nekdo na zacatku setri a postavi barak vcetne nejak splacane elektriky a chlazeni za par supu, tak at se nedivi, ze mu to bude padat. A pak mozna jeste vice zalezi na tom, kdo se o to provozne stara - pokud v nedokonalem baraku budu mit nedokonale lidi v provozu, tak je prusvih zarucen. Muzu mit klidne 1000 servisnich smluv s SLA tvrdym jak pest. Ale stejne to neroschodim.
Idealne je to, ze to dobre navrhnu, dobre nakoupim, optimalne provozuju, a dam k tomu lidi co vedi jak to provozovat a opravovat. Ano, stoji to sice na zacatku mnohem vice investic, ale nepada to. A to vubec nepisu nic o profylaxich, vymene komponent, ochytrovani lidi atd.
A co se tyka zakazniku - tak vsichni chteji super kvalitu za 10kc, ale platit by chteli jen 1,50kc.
Kvalitu si muze dovolit jen nekdo, ale ten nekdo potom nema problemy.
Radek
Ten problém Unicreditu nemá s Alza a vlastně ani tím SAPem ŠA nic společného. U Unicreditu nešlo o nečekaný technický výpadek, ale o předem plánovanou (a předem korektně avizovanou) akci, která se jaksi nepovedla. Slušná ostuda, i když není tak docela pravda, že to nejede 9 dní, já minulý týden nějaké příkazy dělal a vše OK, šlo spíš o "díry" - na začátku týdne nejelo mobilní bankovnictví, ale z počítače vše OK, pak tam byly jiné zmatky, nicméně tvrzení, že někdo nemohl týden podat příkaz, bych označil za dost nadsazené.
Každopádně dost poučné a téma na samostatný článek, zatímco Alza je o závislosti na providerovi, tak Unicredit zase o rizicích aktualizací a zřejmě slušně nezvládnuté přípravě podobné akce...
Ten bankovni vypadek je daleko zajimavejsi nez Alza. Krasne poukazuje na tragedii soucasne implementace SW - "funguje to = je to OK". Domnivam se, ze to meli i otestovano - ve 2-3 lidech. Ale jaksi pozapomeli, ze tech lidi co budou chtit aplikaci zaroven vyuzivat bude spise 20 - 30 tisic. A nejspis nepredpokladali, ze "novinka" bude 10x, mozna 100x narocnejsi na HW nez puvodni aplikace.
Znam nekolik lidi kteri se opravdu minimalne cely tyden nedostali k tomu, aby neco odeslali. Vzdy jim to nekde cestou ukoncil timeout.
Smutne je, ze se velmi podobne chova "nove a uzasne" bankovnictvi RB. Misto funcionality spousta animaci, plovouci okna, ze kterych nelze skopirovat text, informace o jedinem platebnim prikazu pres 2 stranky, a odezvy v destitkach sekund.
V (hypoteticky) spravne fungujici firme existuje pro kazdou variantu pripraveny scenar. Tzn - zmena se nasadi a vse bude fungovat, pripadne se zmena nasadi a objevi se dilci potize, ... az po "nastane konec sveta a fungova nebude nic".
Kazdy takovy scenar ma urceno, co se za dane situace bude dit a kdo co bude delat, ale predevsim, u kazde varianty se predpoklada navrat do puvodniho stavu. Nebot i v pripade ze vse funguje, se vam muze stat, ze napriklad zakaznici zmenu naprosto odmitnou.
U kritickych aplikaci (za jakou bych si dovolil povazovat nektere casti bankovnicvi) se pak cela vec (v te hypoteticke firme) resi tak, ze se po nejakou dobu vsechny operace provadeji jak v novem tak starem systemu, a porovnava se, zda maji oba stejne vysledky.
Pokud pak jde pouze o potize UI, coz ale vzhledem k tomu jak se to chova je spise nepravdepodobne, je navrat k puvodnimu primitivne trivialni. Blizsi informace se nejspise nedozvime, nebot mluvci (prelozeno - placeny lhar) se racil vyjadriti v tom smyslu, ze je to prilis slozite a koho ze by neco takoveho zajimalo.
Podle meho nazoru by mnohem vhodnejsi bylo cele bankovnictvi proste vypnout, nez situace, kdy se lidem (tedy dle mluvciho jednotlivcum) zobrazuji naprosto nesmyslne udaje.
Oni taky ten rollback měli udelat hned a je jasne, ze po skoro 2 týdnech je to uz asi i nemozne. Myslim, ze hrube nezvladnuty change managment a procesy co když... . A s tim názorem na clanek nanejvýše souhasim je to jiste zajimava situace, která by si zaslouzila samostatny clanek. Ale kdy, kde, co, jak a proc to se asi nedozvíme :)
tak v AWS nesmíš mít data v jednom DC, jinak to je k ničemu. Pokud jsi závislý na zásahu techniků a čekáš na ně, není aws pro tebe, je to o tom, že pokud mám nějaký problém, neřeším, místo odstavených nastartuji nové servery.
Opravdu na provoz jednotek serverů je AWS velice špatná volba, výpadky a problémy s HW má velice časté a není to žádná záruka.
Předběhl jsi mne:) Při takové provozní neporadnosti s to zaslouží. Kdejaka 1U entry level blatotlacka ma dva oddělené zdroje v zakladu.
Zas hodme sutrem kdo je bez viny. Bordel v napájení, bordel při vedení opravných práci a ze dvou větví je jedna. Presouvani hw a servisak to zapojí oba kably do jedné vetve protože nové kably nejsou oznaceny. Uz jsem dal brigadnikum za úkol ověřit jestli se naměřené hodnoty napájení na obou zdrojích máš v jedné části datacentra od sebe dostatečně lisi... Tak silná byla nedůvěra v indickou kvalitu práce zapojení na vetve a planovani.
Tady se asi jedná jen o typicky bordel v české firme. Kdy se příliš předpokládá, nikdo nenastavi kontrolní procesy a vše se řeší ukvapene a bez planu.