Názory k článku Nestřílejte specialisty aneb Co způsobilo rozsáhlý databázový výpadek v Alza.cz

Pracuju pro nejmenovanou firmu v oblati open-source která dodává operační systém, aplikační stack, middleware no prostě všechno, podobně jako Microsoft. Z vlastní zkušenosti mohu říct, že platící zákazník se relativně rychle probojuje až k lidem, kteří ten software píší - tedy až k softwarovým inženýrům jak se nám moderně říká. A to jsou normální zákazníci co mají obyčejný support 24/5 nebo 24/7. Vím to, protože se s nima občas vídám (máme sem tam nějaký ten bug to se stane :-) - a to máme několikaúrovňovou podporu.

Ještě jsem nikdy neznal nikoho za ta léta v IT, který by se dovolal nebo pro-emailoval k programátorovi v Microsoftu. Protože mezi zákazníkem a Microsoftem existuje tuna resellerů a aby vůbec v Microsoftu řešili nějaké tickety, člověk musí platit nehorázné peníze za "super prémium podporu". Podobnou zkušenost mám s vendory IBM nebo Tibco - pracoval jsem na "druhé straně" a snažil se dovolat z holandské mezinárodní firmy v oblasti Telco. Kdepak, problém jsem vyřešil disassemblací java bytekódu a patchem binárního souboru.

Dodavatele softwaru je třeba si vybírat také podle hlediska "až nastane průser". Bohužel se taková věc špatně vyhodnocuje předem.

Parádní článek. Probíranou problematikou se nezabývám, ale stejně sem si čtení užil !

Ráno sofistikovaně okomentuju politiku, před obědem poradím lidem co s autem, po obědě pořeším architekturu a jak lépe vyřešit dopravní stavby, pak chvilku rady ohledně zahrádky a chalupy a navečer SQL, operační systémy, případně i sítě, když jsem v náladě. Češi a diskuse, to je prostě boží.

Tuším, že podobně se už kdysi spálil i Seznam se svým freemailem.

"Nerozbitné pole", které se jaksi ehm, rozbilo.

On ten Google nebyl úplně mimo, když založil svou architekturu na komoditním hardwaru. Od té doby se zjistilo, že to byla geniální myšlenka.

Jen pro zajímavost... v době kdy Alza vznikla, jaké konkrétní jiné řešení, pro daný účel použitelné a, pokud vím, tehdy snad ještě studentem zafinancovatelné, by náš regionální svatý expert doporučil? Protože architektura systému se snadno mění v době návrhu, trochu hůř u rozjetého projektu ve výstavbě, v malé produkci už jdou změny poměrně dost ztuha, a jakmile to vyroste do rozměrů dnešní Alzy, znamená to nasypat desítky milionů do druhého datacentra, na něm rozběhat novou verzi, a pak to buď přemigrovat s odstávkou (což obchodně může dost bolet, když je dat hodně, a tady jich hodně bude), nebo to udělat tak aby nový centrum dokázalo zpracovávat objednávky, přidat nějakou formu balanceru, a data od nejčerstvějších přesypat za provozu. A tahle fáze přelívání dat může trvat klidně několik měsíců.
Jenomže udělat to tak, aby balancer mohl provoz házet na nový systém za současného provozu starého, a přitom aby to pro zákazníka vypadalo úplně stejně, je vyšší dívčí a stojí to ranec. Schůdné je to, při výchozí pozici kdy je všechno na jedné hromadě, jedině skrz roztrhání databáze na menší celky a jejich "rozestěhování", jenomže to TAKY "pár mandayů" a hromadu peněz sežere, a přitom se tím "jen" připraví pozice pro další fázi. A dokud to není HOTOVO, padají všechny ty mandaye a peníze do žumpy, a veškerý rozvoj většinou stojí, protože hrabat do původního systému vývojářům a správcům pod rukama, když mají připravit migraci do nového, je koledování si o nakládačku na firemním parkovišti.

Pral bych si, aby v nasi firme to fungovalo aspon jako v Alze. V situacim kdy tlak na uspory je takovy, ze vam meni vadne hdd za disky z druhe ruky je, prinejmensim, alarmující.

V Alze mají v MS SQL všechno. Úplně. Desítky tisíc uložených procedur, ve kterých je kompletní business logika. Až do takové úrovně, že skladník zmáčkne na svém minipočítači na ruce tlačítko a spouští se uložená procedura v MS SQL.

Viděl jsi někdy peklo? :)

Prijde mi to proste blbe navrzene. Failover cluster je dobry kdyz verite poli a neverite nodum, jinak nema smysl. Je to laciny, ale muze se to podelat a to se taky stalo a muze se to kdykoliv opakovat. Navic ten 2. nod nejspis nic nedela.
Co takhle koupit jeste jedno pole a ten server z 2. nodu k nemu pripojit a replikovat data z jedne DB do druhe. Primar RW, sekundar RO (urcite by se nasly nejake operace pro vyuziti toho sekundaru.). Pokud zdechne primar, tak se primar udela ze sekundaru a jede se dal. Vypadek v radu minut. Takhle bych to videl na Informixu nebo Oracle, MS by to asi taky umel, ne?
Samozrejme pokud je SQLServer zabugovany, tak vam stejne zadny hw nepomuze. Z toho co jsem tu cetl zas tak uplne jasne nevyplyvalo, jestli to skutecne zmrvilo to pole nebo MS.
Predpokladam, ze zaver je, ze se chtej zaruky od MS a vyrobce diskoveho pole "ze se to nebude opakovat" a tim to vadne.
Proste Alza usetrila (otazka je kde vlastne, kdyz to bylo tak drahe) a jak velka ztrata ji za tech 27 hodin vznikla.
Anebo se da udelat "pouceni z krizoveho vyvoje" a je to prilezitost jak to predelat ;-), ale spis to bude o tom modlit se, aby se to neopakovalo.

Samo že to MSSQL umí (tuším se to jmenuje Live Replikace), ale narozdíl od active-passive clusteru se všechny licence včetně CALů a Internet Connectoru platí dvojmo plus potřebuješ druhé pole. Což v případě Alzy znamená rozdíl řekněme 15 melounů v pořizovací ceně plus provozní náklady. Možná i víc. Otázkou je, jestli by druhé pole se stejnými daty nevykázalo tutéž chybu, což by znamenalo marně vyhozených ... 15 mega nebo víc. To bych na koberečku vysvětlovat nechtěl :-)

Ne, ale Alza ti automaticky nahazi zbozi do kosiku a nakoupi za tebe.

"Prispevku jsem dal "plus", nicmene okomentuji "co funguje nemen"."

V původním znění s titulky "if it ain't broken, don't fix it".
Jenomže některá (dost pravděpodobně všechna) řešení při svém růstu narazí na strop, který nelze prorazit prostým nahrnutím dalšího železa, protože prostě pro danou architekturu dostatečně výkonné železo neexistuje nebo není jak obejít úzké hrdlo. A pak je to řešitelné jenom změnou architektury, která ovšem kromě nákladů zpravidla má své vlastní v trávě nastražené hrábě, třesoucí se touhou aby na ně někdo pořádně dupl.

Aneb z h0ven do sr4ček...

A já měl vždycky za to, že failover se u DB řeší replikací. Za ten domek by těch x TB slave mohli mít plnej rack. Ale to by asi nesměli věřit obchodníkům, co se snaží prodat drahou SANku.

Otázka je, kde se opravdu stala chyba. Jestli vznikla chybou diskového pole, tak by to replikace řešila, ale jestli byla chyba již v okamžiku zápisu do transakčního logu na úrovni MSSQL, tak by se vám ta chyba pravděpodobně zapsala do všech replik.
Je těžké teď někoho odsuzovat. Sám to vidím. Jste malá firma a tak vsadíte na nějaké řešení a jak rostete, tak se vaše potřeby zvětšují a vy kupujete virtualizaci, SAN, diskové pole s mirroringem, dáte vše na failover cluster, jen tu databázi překopat na jiné řešení by bylo peklo a tak jen doufáte že výrobce databáze bude růst s vámi a zajistí dodatečnou robustnost a servis. Takový Oracle je výkonnostně určitě úplně jinde než Microsoft, jenže finančně taky. Navíc na MS produkty seženete asi nejvíc IT lidí do firmy.

Diskova pole jsou plna SPOF, je to jako davat vajicka do jednoho kosiku. Evidentne selhalo cviceni katastrof, proste jen verili a netestovali.

Hehe, s kolegou jsme kdysi v souvislosti s něčím objevili dost blbou a nepříjemnou chybu v mechanismu connection poolingu ODBC do SQL serveru, projevující se tím, že na 2000kách po nějaké době provozu (resp po nějakém objemu dat proteklých spojením) otevřená spojení skrz ODBC do MSSQL7 s aktivním connectionpoolingem prostě vytuhla a přestala vracet výsledky dotazů. Já na to narazil, zjistil jak to zreplikovat, a on vyzkoumal v čem ta chyba přesně spočívala.
Že tam ta chyba skutečně je potvrdili do 48ti hodin, ale prohlásili, že by oprava byla moc velký zásah, a že jelikož si nikdo další nestěžoval, tak že to tedy bude řešit až příští verze. A bylo to tam ještě ve 2008R2.

"Jeste take museli cely den platit zamestnance kteri nic nedelali, takova drobnost"

Což je samozřejmě nesmysl, protože by je platili tak jako tak.

"Dalsi skody pak vznikou jako nasledne - objednane zbozi prijede, nekdo jej musi prijmout, protoze dopravce nezajima ze nefunguje vas system (pripadne zaplatite pukuty za prostoje), ale to zbozi se pak bude prijimat jeste podruhe, az system fungovat bude. Dusledkem nejspis bude prescasova prace ve dnech po vypadku = dalsi stovky tisic nejmene."

Naskladnění není totéž co převzetí zboží z kamiónu. Ten nacouvá na gate, skladníci to vyloží po paletách a kontrolují čísla a počet palet. Naskladnění probíhá až POTOM, po rozbalení palet, a to rozhodně neprobíhá přímo z rampy. Právě proto, aby krátký výpadek skladového systému neohrozil vykládku. Samozřejmě je otázka, kolik toho ten retenční prostor pobere, a kolik je tedy skutečný prostoj.

"1500 zamesnancu = rekneme 4MKc/den zcela jiste. A vypadek nemusi trvat prave den, muze trvat dele, takze reseni za 15M rozhodne neni drahe."

Jak se to vezme. Výpadek trval 9/8 dne, takže škoda při tomhle výpočtu 4,5MKč (diskutabilních). Zrušených zakázek kvůli prodlení bylo jak velké procento? Troufnu si tvrdit, že do 0,5% (každá dvoustá).

Alza existuje jak dlouho? 15 let? 20 let? A kolik za tu dobu měla takovýchto výpadků?

ALes ZAoral to uz od zacatku psal na produktech MS v APS, takze cele je to dane zrejme historicky. Prepsat neco v asp je vzdy snazsi(levnejsi) zase do neceho pribuzneho.

Premiér podpora od na stojí ranec peněz a rozdíl od standard vidím jen v tom že mi dříve odpoví na email stylem náš technik na problémů pracuje a pak klidne12 hodin ticho.kdyz nemají volného inženýra, který by problém mohl resit, Ani dráha podpora problém nevyřeší.

Ne, to je konečná...
Už jsem to zažil u bývalého spolužáka, co se do takové firmy dostal a hned jsem měl práce dvě, svojí a pomoc kamarádovi ;-)
Ale stejně jim to nevydrželo a rozpustili to...

Výborně napsaný článek.

Autor v podstatě nastínil jádro problému. Jak mít odolnost ale zároveň si udržet rozumnou pořizovací cenu. Každopádně, to co autor popisuje, zejména s podporou vendora zažívám také, technik z Bangalore často o produktu ví výrazně méně než já. I když můžu ale i napsat, že jeden z velkých vendorů, má technickou podporu o celé námořní míle napřed, ale cena za podporu je samozřejmě zcela jinde a rozhodně nevolá nikdo z Indie.

Řešení jaké má Alza bych neodsuzoval, měli pro to důvod (snad důvodem výběru takového řešení opravdu nebyla jen působivá prezentace místního obchodníka).

Zkusím jiný zjednodušující pohled. Opravdu potřebujete databázi, kde je několik TB dat, na to, abyste přijali a odbavili zákaznickou objednávku?

"Pral bych si, aby v nasi firme to fungovalo aspon jako v Alze. V situacim kdy tlak na uspory je takovy, ze vam meni vadne hdd za disky z druhe ruky je, prinejmensim, alarmující."

V tom případě by stálo za to zvážit, že nezlepšit cash-flow prodejem informací na těch discích z druhé ruky nalezených :-D

MS SQL umí replikaci od verze 6.0, tj. přes 20 let. Ale chce ji to použít :)

vidim ze je tu pametnik velmi davnych casu.. nerozbitne pole neexistuje. Ale kdyz v v IBM DS nemenite vadne disky, mate blbe udelany RAID a jeste to nechate varit mimo provozni teploty, tezko se pak divit ze to jednou spadne.. pole bylo opravene hned, ale recovery trval dlouho.

Haha, vzpominam si na situaci v jedne velke firme, kde se pripravovalo trochu riskantni nasazeni nejakych uprav kritickych systemu. A v ramci planovani nasazeni se resila i otazka, co budou delat zamestanci firmy, kdyz se nasazeni nepovede a nebudou moct normalne delat svoji praci, aby se neflakali. (No nektere napady byla fakt hodne obskurni)

V DHL maji kde co, od puvodnich cobol systemu az po moderni mongo :-)

Jojo, a bezva je, když zákazník do helpdesku hodí tiket s kritickou závažností, a popis problému vypadá, jako kdyby ho posílal přes twitter... "něco se rozbilo a něco nejde". Zavoláš tam, a ten kdo to takhle odeslal šel po šichtě domů, nikdo neví co se stalo, co mu nešlo, kdy se to stalo (takže se v logu není čeho chytit), a všem teď všechno funguje a nikdo problém nemá.

Jako DBA musim rict ze preferuju replikaci na urovni DB a ne diskovym polem. Pro ucely DR cele firmy je nicmene nutne mit i tuto moznost, vzdyt spoustu firem ma svuj byznyz zavisly i na souborech jednotlivych uzivatelu. Bohuzel to je fakt. Resil jsem korupce DB z X ruznych duvodu a na ruznych platformach a dodneska se zdraham rict jestli je lepsi Oracle, MSSQL, PostgreSQL nebo MySQL. Samotne DB systemy maji svoje bugy ktere napr. zpusobi korupci standby databaze kterou zjistite az pri pokusu o failover. To se testuje fakt dost blbe. Problemy maji samotne OS nebo jejich komponenty jako multipathing drivery apod. Lost write na storage je fakt blby a na TLogu v podstate neresitelny. Clovek se az na zaklade vlastnich zkusenosti dobere tem "spravnym" resenim. Protoze u DB plati ze verit se neda nicemu. Byt prilis optimisticky znamena ze jednou to padne na hubu. A vetsinou to schyta clovek ktery v dane firme zustal, naockovan optimismem sveho predchudce. V Alze je mozna 1 kriticka DB pro beh cele firmy a jeji nedostupnost muze nastartovat DR proceduru. Ale v korporatech je X systemu navzajem propojenych a dohromady kritickych, problem jednoho systemu DR proceduru nespusti, ale musi se resit in-place. Takze obecne rady nefunguji. Vsichni z nas kdo ctou LUPu si myslim jsou schopni sebereflexe a ze sve praxe si vybavi kde sami udelali chybu v navrhu nebo implementaci nejakeho systemu. Nekdy mam dojem ze vyse zminovani optimiste jsou ti co casto meni zamestnavatele, protoze jsou si vedomi svych lehkovaznych rozhodnuti a potencialnich problemu ktere by se mohli projevit, tak radeji "utecou" a pak tvrdi ze jejich design je ten osvedceny, protoze za jejich pusobeni (kratkeho) se u predchozich zamestnavatelu zadny problem neobjevil. Toz tak. Drzim palce vsem komu zatim jejich kriticky system nepadnul na hubu. Odpocitavani bezi...

Jsem rad, ze se tohle stalo a bude stávat nadále. Jen by to mohlo být častěji :-) Dokud si manažer kontrolující a spravující IT budget neuvědomí, že je potřeba se také podívat na to, kolik je stoji hodina výpadku (Cost of Outage) kritických systémů (pokud vědí které to jsou). Bohužel v našich podmínkách něco jako BIA (Business Impact Analyse) a posuzování rizik je věcí krajně nepopulárni a převládá zde názor "doteď se nic nestalo, tak není důvod k obavám" :-).
Faktem je, že jedno pole je krásný příklad SPOF a vždy bude. Nejde ani tak o technologii použitého HW/SW, nebo zda je to OpenSource nebo komerční produkt. Nelze totiž nikdy vyloučit lidskou chybu, třeba i záměrnou, vedoucí ke ztrátě dat. Aktualizovaný plán obnovy je tedy vždy na místě...

Návrh infrastruktury prostě musí odpovídat hodnotě toho, jakou službu zajišťuje v provozu na adekvátní úrovni. Je to disciplína jako každá jiná. Chtěl bych vidět, jak někdo z vás půjde k zubaři, který nabízí nejlevnější služby někde na ulici v zapadlé čtvrti bez pořádného vybavení. To chce hodně odvahy.... :-)

Děkuji autorovi za článek!

Premier support není řešením...a opravdu není drahý, pokud moje společnost při nefunkčním DB přijde o milion za hodinu.

Otazka je, jaka skoda realne Alze vznikla. Pokud nekdo zminuje 15 milionu za skutecne redundantni reseni, tak bych se vsadil, ze kdyz se podivaji na mesicni prodeje, tak 15 milionu v zisku neprodelali ani nahodou, to by znamenalo vypadek kolem 300 milionu obratu, mozna jeste vice. Takze mozna nakonec to rozhodnuti riskovat takovy vypadek bylo spravne.

Ono se to dela jinak, vzdy potrebujete jeste to zalozni pole. A jelikoz samozrejme nechcete co 5 let kupovat pole 2x, tak se to dela tak, ze to 5let stare, kteremu skoncil support pouzijete prave jako to pole zalozni. V pripade vypadku vam pak staci z ostreho serveru pripojit databazi ze stareho pole. I ztrata dat muze byt pomerne nicotna, pripadne i prakticky nulova, v zavislosti na tom jak to je vyreseno.

Alternativne jeste existuje moznost, ze zalohujete nikoli "databaze", ale jejich soubory (samozrejme ve spolupraci s databazi, jinak by to nebylo konzistentni) a potom muzete provest primo attach databaze prave z uloziste kam zalohujete. Otazka 2 minut. To pole mozna nebude tak vykone, ale zajisite docasny provoz do odstraneni problemu.

Protoze i kdyz vam nekdo posle tech letacku plnych vysmatych rodinek vagon, nic to nemeni na tom, ze cokoli selze. A zadny support vam nezajisti, ze vas problem bude vyresen. Natoz v nejake lhute.

Taky delam s Oracle a musim rict ze se mi podobna vec stala i na 9i. SGA memory corruption, crash databaze, poskozene redo-logy. Databaze segfaultovala behem media recovery. Jako reseni se nabizelo full restore, preskoceni media recovery & dump dat do nove db. Kvulil casovemu presu a hrozicim ztratam, jsme nakonec jen preskocili media recovery, rebuildovali indexy jelo se dal.

já sem tedy jen obyčejny BFU PC uzivatel, ale co je to velikosti mnoha TB? 10? 20? 100TB? vic? jak dloho trva na rychle diskovem serveru zkopirovat 10TB? proboha co je to za databazi ktera ma desitky nebo sdnad stovky TB? Nekdo tu zminoval ze databaze obsahuje fotky produktu? to jako vazne? to neni tak ze v databazi je "adresaulozis­te/fotoproduk­t1.jpg"? Ale rovnou cela fotka? jako vazne?

U msft se to jmenuje logshipping nebo mirroring, podle latence jakou si prejete. Oboji technologie vic nez 10 let stara.

Především jsem nenapsal, že kdyby byl proveden RAP tak k této situaci nedošlo. RAP kromě jiného umožňuje srovnat nastavení konkrétní aplikace se zkušenostmi, které MS získal s danou aplikací na celém světě. Dále umožňuje posoudit architekturu aplikace a především výstup z RAP dobrý pro vedení a majitele firmy. Dále RAP velmi striktně trvá na nejen na dokumentaci systému (což umožní rychlejší obnovu), ale díky němu se většinou podaří nastavit také interní procesy, takže je jasné a jednoznačné kdo o čem a kdy rozhoduje. Tím je šance, že se například zkrátí čas na proces think time. Není možné aby do procesu řešení "technického" problému zasahovalo zasahoval každý vrcholový manažer jen proto, že si myslí, že IT rozumí. Každý musí mít jasně definovanou odpovědnost a své kolegy, manažery, by měl nechat řešit jejich problémy. Jinak vzniká chaos. Možná někdy někde se díky chaosu něco vyřešilo rychleji než řízeným procesem, ale na to spoléhat nelze.
Co se týká architektury, tak odvolávat se finanční náročnost, je také z jisté části jen alibismus. Firma velikosti Alzy, tedy obrat v desítkách miliard Kč, čistý zisk jistě v miliardách, by si měla svých dat vážit víc.
Nicméně, pokud si kdokoli myslí, že má architekturu systému takovou, že pád jím spravovaného systému je vyloučený, tak je hodně naivní. Stačí se po světě podívat po pádech velkých systémů. O středních a malých firmách nemluvě. Proto je důležité mít připravené scénáře jak postupovat když dojde k nejhoršímu. A z tohoto pohledu si myslím, že je velmi důležité nebránit se pohledu na systém odborníků, kteří nejsou zatíženi vazbou na managment firmy nebo historií vývoje systému. Takovýto pohled může systém zlepšit, rozhodně ho nezhorší.

pěkné, setkání s enterprise procesy na vlastní kůži.

Na českém trhu existuje řada integrátorů MS technologií, škoda, že jste více nerozhodili sítě, MS si běžně najímá subdodavatele a půjčuje si lidi, není problém jít přímo, pár lidí bylo k dispozici, někdy i oprava je možná.

Raid pole jsou peklo, extrémně uzavřené technologie a neřešitelné problémy. Na DR zpravidla není přenosová kapacita, tenhle svět znám :)

s tim bych mirne souhlasil, z toho co jsem cetl je jasne, ze tady by to chtelo primy pristup k vyvojarum

spis me ale napadlo, ze podle dostupnych informaci se to teoreticky muze stat kdykoli znovu - alespon jsem tam nedekodoval informaci, ze SW problem radice byl potvrzen a hlavne opraven!

Takze Alza vlastne zadne DR nemela (a nejspis nema). Tohle co popsal, je absolutne neuveritelne, spolehaji na to, ze to proste pojede a nestane se nic neocekavatelneho. A to jsem doted myslel, ze naprosty zaklad je db replikovat online nekam jinam, ukladat logy a sem tam udelat dump/snapshot. No, nevadi, evidentne nemaji zadne IT, jen lidi, co (nejak) pisou kod.

Záleží, jestli se zprasí už před odesláním k uložení do replik, nebo až při fyzickém zápisu na médium. V případě a) jseš na tom jak Baťa s dřevákama, v případě b) by služby v clusteru měly dál běžet proti zdravému nodu a na nemocném si to opravíš replikací ze zdravého. Ale pokud máš dvě identická pole a řadič má chybu ve firmwaru, která se manifestuje v důsledku toho co přiteče k uložení, jseš slušně řečeno v hajzlu, protože se to zapíše do obou replik a systém o tom vůbec neví, dokud se tam znova nekoukne, načež zjistí že zdravá kopie neexistuje a celý to padne na hubu.

"Co je ale nezajímavější je, že takoví amatérští rádcové v průměru neradí o moc hůře než specialisté.
A někde jsem četl, že specialisté s pletou vůbec nejvíc, chybí jim nadhled a selský rozum."

Nassim Nicholas, Černá Labuť. Zajímavé čtivo, i když se sám několika vlastním pastem v původním vydání nevyhnul a právě těmto svým chybám se věnuje v dodatku, který má rozsah skoro poloviny prvního vydání.

"Nebo jej nenapadlo, že by mohl být dobrý nápad, starší data již uzavřených objednávek uchovávat v jiných tabulkách, aby obnova funkčnosti na které závisí provoz byla rychlejší, když nebude vidět historie po několik dní nikomu to celkem vadit nebude."

Jasně, ale tenhle úklid mívá až překvapivě vysokou režii, takže pokud s tím není počítáno v původním návrhu, jeho pozdější zavedení do velké databáze může být bez velké modernizace neproveditelné. Takže se s tím pak čeká na "nové železo, které to už zvládne levou zadní". Viděl jsem to víc než jednou.

"Zde např. specialista neslyšel o naprosto běžné možnosti klonování databáze za chodu."

Ale notak, autor píše že slyšel, ale z nějakého důvodu (tipuju finančního) tato cesta zvolena nebyla. Protože s ohledem na nutnost platit licence dvojmo (u MSSQL se u active-passive platí jen za aktivní node, zatímco u active-active za oba včetně CALů a Internet Connectoru), což v kombinaci s druhým polem a druhou sadou SSD vychází, ve velmi konzervativním odhadu bez dalších podrobností, tak na 15 mega minimum plus provozní náklady.
A jelikož, pokud jsem články pochopil správně, za těch 27 hodin neselhávaly objednávky, nýbrž "jen" odbavování zakázek a tedy doručení, což znamená že škody z neuzavřených obchodů nevznikly za celou dobu výpadku, nýbrž jen v nějakém zanedbatelném procentu, dá se předpokládat že to byly VELMI rozumně uspořené náklady. Protože s ohledem na obvyklé marže, jak už tu někdo psal, by muselo dojít k výpadku cca 300+ megaKč obratu. Což, pokud se správně pamatuju, je v případě Alzy kompletní výpadek na cca 2 měsíce.

Chmmmmm. No zrovna na Lupe vetsinou "radi" lidi, co tomu alespon trochu rozumi nebo to dokonce delaji.
Na rozdil od diskuzi pod clanky "denniho tisku" se z diskuzi na Lupe obcas mohu neco uzitecneho dozvedet.

A kdo ten jejich kód, který je na MS SQL založený, přepíše?! A za jak dlouho?

hromadu zbylého bordelu nasypat do NoSQL

Jojo, tenhle buzzword nám tady ještě chyběl. :-P

https://forum.root.cz/index.php?topic=14052.0

A průběžná replikace databáze za chodu? Vždyť to přece umí i 10 let stará mysql a používá to kde jaký amatér. Nebo je to o tom, že alza chtěla ušetřit za další licenci?
Pokud máte replikaci, není úplně nutné aby to běželo na tak drahém hardwaru, tedy dal se ušetřit barák za Prahou. Nebo spíše za stejné či menší peníze můžete mít několik aktuálních kopií všech dat. Navíc číst lze pak v některých případech z vždy aktuálních replikací, čímž se sníží zátěž hlavního serveru.
A v případě havárie hlavního serveru je jen vypnete a jako hlavní databáze začne sloužit nějaká replika. Ostatní klony překonfigurujete tak, aby klonovali od jinud.
Spoléhat se jen na noční zálohy a že se nikdy nestane žádná vážnější chyba mi přijde fakt amatérské.
Ale když má někdo nutkání utrácet u Microsoftu, který ani u SQL není jedničkou, asi mu je fakt těžké pomoci.

ja to cetl prave jako problem radice, ktery sql serveru "neohlasil" chybu pri ulozeni

Znam velke firmy, ktere nektere pomerne kriticke databaze maji take jen jednou. A to na zaklade racionalniho vypoctu nakladu selhani a nakladu na redundantni databazi. (Je fakt, ze zrovna tahle databaze nema primy dopad na klienty firmy, takze nasrani pri vypadku by byli hlavne zamestnanci.)

> Nassim Nicholas, Černá Labuť.

pak ale musim zminit jeho novejsi knihu "Skin in the game"... my tady vsichni kecame, ale nebyli jsme tam a nemeli zodpovednost :D

Pokud jsem článek dobře pochopil, tak finální problém byl v poškození redo logů a nemožnost provést recovery.
SQL server má možnost provádět redo log repliku (i když do SQL server 2012 jen sériově), od 2016 dokonce paralel redo.
Pro takto kritická řešení se používá uložení redo logů odděleně od datových souborů db na jiné fyzické disky, ideálně na jiném stroji, a pak ještě replika redo logů (někdy i vícenásobná), opět na jiném stroji (jiných strojích). Otázkou jsou samozřejmě rozpočtová omezení...

A z te vasi zakazky vyrobite objednavku smerem k dodavateli jak? Pak z toho vyrobite prijem? A vydej? A faktury? Takze se da rici, ze vy nechapete, ze proces prodeje nejsou zdaleka jen nejake objednavky od zakazniku. Pominul jsem pochopitelne spousty dalsich veci - reklamace, vraceni zbozi atd atd. To vse musi mit navaznost do ucetnicvi, skladu ...

no neviem ci pracujes v hornej dolnej, ale engineer sa bezne hovori technickemu supportu v Oracle alebo Microsoft. Podpora Microsoft je velmi zla,ked clovek najde bug v sql serveri... ma casto smolu.

Což je právě ten kámen úrazu - především očekávají a komentář p. Kubečka na to poukazuje.

Kdyby si přečetli podmínky smlouvy, nemuseli by být nemile překvapeni ve svém očekávání.

Kolegové si zaplatili gold support u sunu (tenkrát) a byli nemile překvapeni, že se to řeší až v pracovní hodiny.
A v podmínkách skutečně bylo, že reakce supportu je do jedné hodiny, ale řešení v pracovní hodiny.

60MKc obratu za den pri hyperoptimistickem zisku 10% dela 12MKc za 2 dni vypadku.
Porovnejte to s cenou 15MKc (+- desne moc) za reseni s nutnou obnovou cca kazdych asi 5 let. Takze pokud se Alze nestane podobny vypadek vice nez jednou za 5 let, je to ekonomicky nesmysl.
Ale to jsou hausnumera. Ten usly denni zisk je silne prestreleny, na druhou stranu tu nejsou ztraty ze ztraty duvery.

"já sem tedy jen obyčejny BFU PC uzivatel, ale co je to velikosti mnoha TB? 10? 20? 100TB? vic? jak dloho trva na rychle diskovem serveru zkopirovat 10TB? proboha co je to za databazi ktera ma desitky nebo sdnad stovky TB? Nekdo tu zminoval ze databaze obsahuje fotky produktu? to jako vazne? to neni tak ze v databazi je "adresaulozis­te/fotoproduk­t1.jpg"? Ale rovnou cela fotka? jako vazne?"

1) netvrdím že to tak skutečně mají
2) právě pro ukládání obecných dat (třeba právě obrázků, videa. audia) do databází slouží typ BLOB (a ne, s Kaplického chrchlem to nesouvisí)
3) databáze je v tomto kontextu chápána jako "báze dat". V Alze jsem nikdy nedělal, takže nevím, jestli to konkrétně oni mají jako monolit, nebo konglomerát více databází, případně jako mix n databází a hromady souborů, ale viděl jsem spoustu řešení, kde např. záznamy z kamer byly ukládány jako BLOBy přimo do databáze. Bylo to kvůli tomu, aby se snížila režie souborového systému. Celkem kontraintuitivně, čím byly ty soubory menší a početnější, tím byl výkonový přínos větší.

Tak vymlouvat se na podporu výrobce databáze při opravě transakčního logu je jen okraj ledovce, po kterém to řešení klouže celé dolů. Zvlášť , kdy jde o MS, který funguje transparentně a jejich technologie pro eCommerce zrovna určeny nejsou. Po prohrané bitvě se generál nenajde..... většinou. Spíš se naleznou vykladači, kteří hledají příčiny a následky a v zásadě se většinou neshodnou. Technická příčina na úrovni poli je jistě jen obětní beránek, protože jinak je vše úplně v pořádku. A toto se nám stává pouze jednou za 10 let :-). Pokud největší ecommerce poskytovatel spoléhá na to, že má zřejmě veškerá uživatelská a produktová data v jedné obří databázi (lhostejno v kolika schématech a instancích), na kterou spoléhá, že nemá SPOF, je špatně něco někde jinde. Pokud se zastaví celá společnost díky výpadku jediné databáze, je to pravděpodobně jev. který má vést majitele k poznání, že současná vývojová cesta, přílišná agilita a obdobné řešení může společnosti způsobit nejen obří ztráty, ale i způsobit ztrátu reputace. Možná je čas na změnu, nejen architektury, ale i it organizace. Kdo z nás by nějaký výpadek Alza už na vlastní kůži nezažil. Zastaví se mobilní aplikace, sklady, logistika....­.tramvaje. A peníze netečou!

Doufám, že to uvedené databázové architekty vede k úvaze, že se nevyplatí myslet izolovaně na úrovni jedné technologie, ale, že celé monolitická struktura řešení je špatná vize a je třeba navrhnout smysluplnou architekturu, což neznamená jen povýšit verzi programovacího jazyka.

ked neviem o com hovorim radsej mlcim. Keby kupili rovnaky storage v druhej lokalite (neveim ze maju svoje datacentrum, pouzivaju verejne), mozu zacat zrkadlit absolutne bez odstavky. Ak by chceli potom automaticky failover, je to mozno o kratsej odstavke a rekonfiguracii clustru, ale nic velke

ci db replikacia alebo SAN je vec vksusu. Ms sql always on group je hodne shitty. Ono mozno alza rozmyslala o aspon DB replikacii, ked autor pise o bugu ALWAYS ON, ale asi to nestihli.

Takže všude jinde jsou ty diskuze věcné, odborné, slušné, ... :-) Svým příspěvkem přesně potvrzujete, jak to s těmi diskuzemi je. Máte pocit, že je rozumný, věcný, protože patříte k těm rozumným a on je přitom naprosto mimo. A samozřejmě si to vymluvit nenecháte. Docela by mě zajímalo, jak diskutují Švédi, Noři, Albánci, Iránci, Portoričané, ... člověk se nesmí uzavírat a nepochybně máte tuny zkušeností. Počtěte si, jak třeba v Norsku řešili hejtery. A to by člověk myslel, že jsou jen tady, že. Já osobně to vidím s píše tak, že jsou lidé znalí a ví to, jsou lidé znalí a neví to a nebo se bojí to dát najevo, lidé, co si myslí, že jsou znalí, lidé, co ví, že jsou neznalí, ... no a tak je to všude a zvláště ta třetí varianta je problematická. Většinou z těch se rekrutují blbci různého ražení. A tak bych prosil, nenalepkujte mě, nenálepkujte Čechy, nenálepkujte žádný národ, protože to pak zase nemá daleko k různým ideologiím, které nakonec nejsou přátelské ani k původním zastáncům. V historii je příkladů dost.

1-5% obratu je hezka vec. Jenze kdyz vam v silne konkurencnim prostredi bude dychat na zada konkurence, ktera dava jen 0.5% nebo mene, tak vas prevalcuje.
Ano, je velka pravdepodobnost, ze se konkurenci neco podela a odpadne. Ale kdyz tech konkurentu je vic, tak pravdepodobnost, ze se minimalne jednomu z nich zadari a prezije to bez poruchy velika, je to prakticky jistota.
PS: tim se tohoto setreni nezastavam, jen je uvadim do realneho sveta.

Stručně, údajně největší eshop opět "ušetřil na správném místě" :-)

Ono se to nezdá, ale dost pravděpodobně jo. Ke každému artiklu jsou fotky, popisy, spousta dalších dat (dodavatel, historie cen, čísla smluv a dodávek), plus je potřeba držet podklady k sortimentu i hluboko do minulosti kvůli náhledům z historie zakázek, když se zákazník bude chtít mrknout, co si to vlastně před lety koupil a čím to dneska nahradit.
Aby zákazníci měli přístupnou celou svoji historii, musí taky celá být v databázi.
Pokud je to všechno v jedné databázi na jednom serveru, jen rozházené do tabulek, určitě to není z dnešního pohledu šťastné řešení, ale dovedu si představit, že k tomu na začátku byl důvod (např. nasazení i pro komerční použití bezplatného SQL Express, tehdy MSDE, který měl vždycky omezení na počet obsluhovaných databází a počet příchozích spojení nebo souběžně zpracovávaných dotazů, což se časem samozřejmě měnilo a rostlo) a dokud byla Alza malá problémy bylo řešit modernizací hardwaru, asi to stačilo a hlavně to muselo být řešení v začátcích ufinancovatelné.
Ale změna, byť by to mělo být jen rozházení monolitické databáze do dílčích a rozestrkání na víc instancí databázových serverů, není tak jednoduchá jako vymyšlení jak to udělat líp.

PS: u Oraclu je paralel redo od verze 8, tj. cca rok 2000 :-)

jiste jde vkladat primo obrazkt ale na aplikacni urovni (web) to bude fungovat jak?

Např. :-P

V praci pouzivame clustery postave na DB od Oraclu Tj. active main app server, db a aux server. To same v passive. Data putuji z active main na db server, kde bezi wrapper, ktery data propise do aktive DB a zaroven je posila na stanby wrapper, ktery je propisuje do stanby db. Aplikacni failover v plnem vytizeni u cca 200GB DB trva radove 15-20 minut. Samotny DB failover bude mnohem rychlejsi.

To si pamatujete spatne, Alza ma pry obrat 21G rocne, tzn cca 60M/den.

https://ekonomika.idnes.cz/alza-rocni-obrat-rekord-0v5-/ekonomika.aspx?c=A180131_102419_ekonomika_are

Dělám v Tietu pro IF (severská pojišťovna) a DR plány se testují a aktualizují minimálně jednou ročně pro všechny systémy. Koneckonců musí být součástí RaaSu a bez nich MS neodsouhlasí audit systému. Berou to tam docela vážně.

"A co se replikace týká, taky není všemocná - nám třeba selhalo primární i záložní datacentrum současně."

Tak to jste krutě amatérsky zanedbali terciární datacentrum ;-) Měli jste určitě zvážit i off-site zálohu na Měsíci.

Ja bych prozmenu mohl prihodit desitky konkretnich pripadu, kdy support dostal daleko vic, nez vubec mel narok zadat, ma primy pristup k zakaznikovi, do logu, databazi atd, a presto neudelal vubec nic, reseni nakonec zustalo na IT dotycneho zakaznika.

Zrovna nedavno se mi stalo, odpoved placeneho supportu "to delate spatne" .. .a jak je to spravne? "to si najdete v dokumentaci" ... nakonec se mi podarilo pres vlastni kontakty najit cloveka (ktery s dodavatelem ma spolecneho jen to, ze je take "stastnym" uzivatelem jejich produktu), ktery jen potvrdil, co jsem vedel - ze zadna takova dokumentace neexistuje, ale poradil mi, protoze narazil na stejny problem - a stravil nekolik dnu reverznim inzenyrsvim a zkoumanim toho, v cem je zakopany pes.

Takze si ten vas vykrit strcte vite kam, nebot ten kdo je placen je ten kdo ma odvadet to za co je placen. Zakaznik neni od toho, aby resil to, co ma resit onen support, a kdyz neresi, neni duvod jej platit.

Pouzivat vobec MS SQL server pre taku mission crtical aplikaciu... No ale proti gustu..

By ma celkom zaujimalo co bol ten “enteprise class storage”. Anway v dnesnej dobe kde sa kladie priorita na realse verzii novych funkcionalit, aj naozaj enteprise pole typu EMC VMAX, IBM DS8000 alebo HITACHI je proste SPOF. Aj pre tieto technologie sa predavaju mirroring funckionality, kde storage replikuje (moze aj synhronne) data na storage v druhej lokalite.

Za kolko alza zarobi na skutocne DR riesenie? Myslim ze za toto by mal letiet COO/CIO/CTO ci aku funkciu tam maju aj s auditorom. Klasika hlavne ze maju High Availability, ale na DR nemysli nikto.
Je mozny aj sync mirroring na urovni MS SQL, samotnyn autorom spomenute Always On Groups, aj ked je to dost zla napodobenina Oracle Data Guard (ktory je sam o sebe nic moc technology).

Snad to bude aspon na cas vystrahou podobnym firmam, ktorym je luto mat riesene v dvoch nezavislych DataCenters na dvoch roznych storage... (a idealne mat aj tretiu pre quorum clustra).

Na druhej strane za posledny rokmje aj dost vypadkov v cloudoch... a tiez parkrat nezafungovalo DR

Při sw chybě pole vám primár rozbije sekundár a máte po srandě.

Jsem obyčejný devopák, ale kolem pár systémů jsem prošel a vždy byla limitujícím faktorem cena/čas. Když firma začíná s nějakým vývojem, tak neví, zda bude vůbec úspěšný. Během vývoje se z nezkušenosti nebo čistě z časového pressu udělají rozhodnutí, které jsou nekompatibilní s růstem služby. Nakonec skončíte s kódem za desítky, možná stovky milionů, který je závislý na jediném připojení k databázi. Interně je systém přes knihovny, frameworky, optimalizace i špatná rozhodnutí tak propojený s jednou databází, že není možné ho upravit, aby používal nějaké více failure friendly řešení. Máme databáze, které byly navrženy kolem replikačních algoritmů jako CouchDB nebo Hadoop, ale kód je tak prolezlý vazbami na jednu konkrétní databázi, že bez obrovských investic není možné s tím hnout. V týmu k tomu většinou ani není vůle a když už se někdo pokusí, dřív nebo později narazí a sám to nezvládne. Nakonec se prostě s nějakými problémy počítá. Když se to komunikuje správně, tak to moc škody neudělá.

Prispevku jsem dal "plus", nicmene okomentuji "co funguje nemen".

Pointa je v tom, že by pak možná nemusela být použita ta drahá "nerozbitná" SAN vůbec. Takže by to nakonec mohlo celé, včetně licencí, vyjít levněji. Čím hlouběji se FO řeší, tím to bývá dražší (o řády).

oracle redolog multiplexing je tak doby proti user chybe (takze je pekne ked ma db dve kopie) a na nejakom lokalnom serveri s malou DB. Vyzera ze im naozaj padol storage controller a nestihol zapisat data z cache na disky, cim vznikol takzvany lost write a to je smrt. Ked sa to stane, kedze do transakcneho loku pise db skoro da sa povedat nepretrzite. Keby mali multipliexing na rovnakom storage, zrejme to chyti oba zapisy (ktore databazova instancia vykonava paralelne) a su tam kde boli...

AS400 ale nie je mainframe

samozrejme, vy a zbytek sveta:D

To je paráda, ale i tak robustnější řešení vychází jako ekonomický nesmysl.

ja bych to vyresil ... jsem expert

Failover cluster je v dnešní době docela levného úložiště přežitek. Kolikrát jsem se setkal s tím, že oděšlo super odolné pole (na vedoru nezáleží).
Asi jediná výhoda oproti ostatním metodám založeným na replikaci logů/dat je v rychlejším comitu transakce (zjednodušeně - není potřeba čekat na potvrzení z replikační vrstvy), ale oproti failover cluster u je zde i ohromná výhoda, failover je pak otázka pár sekund, že to aplikační vrstvu ani nemusí postihnout, protože instance s replikou jsou spuštěné s připojenou databází a tedy není potřeba čekat na přehození disků, spuštění instance jako v případě failover clusteru. I v Alze by se to dalo předělat za běhu bez nutnosti velkých investic.

A preto paranoidny maju pole aj druhy server of ineho vendor :-D

Always on ma neskutocne vela obmedzeni. A pokial pouzivas veci ako stored procedures a podobne je prerabka dost trnista. Neviem ci to fixli ale niektore MS produkty nevedeli bezat na takomto clustri.

https://www.loupak.fun/video/srandicky/19281-expert-ve-firme ? :-)

Máte pravdu v tom že Multipath je na spoustu systémech problémovej, ale v případě Windows pokud je storage od renomovaného výrobce který dodal MPIO drivery jsou funkční. Provozoval jsem storage s FC kdy jsme postupně z 8 linek degradoval až na jednu a zase postupně zprovoznil všech 8 a jak OS kde byl boot form SAN tak databáze a aplikace s úložištěm na storage vše šlapalo jak mělo ani jedno selhání jen v logu zápis o nefunkční lince a atd. Stejně stabilní to bylo u RedHat a Centos, ale u Ubuntu to bylo tak 50:50 někdy neustál ztrátu jedné linky někdy ustál ztrátu poloviny linek. Taky záleží na FC HBA kdy Qlogic se mi zdál stabilnější než Emulex.

Jenže jak Facebooku tak Googlu je uplně jedno když jim zdechne nějaká malá součást, protože v jejich strukturách je na každou malou funkcionalitu několik set počítačů v clusteru jak aplikačním tak datovým atd a když se to náhodou posere tak nefunguje třeba chat pro jeden stát, a oprava spočívá v tom že bud obnoví automaticky data ze zálohy nebo přepnou funcionalitu na jiný clustery. koukněte se na dokument o Googl Datacentrech tam prostě vemou server vyhodí ho ze systemu a zapojí jinej, přes PXE nabootuje zavaděč proběhne bezobslužná instalace a server se zařadí do clusteru a stáne si data co potřebuje. ano máj to na opensorce ale umí to i korporátní placenej software. open source neni žádnej zázrak ani spása.

Něco mi tu zasmrada. Z opačného soudku. Každý bere cache (nvram) jako něco co se smaže a zhroutí po pádu controlleru. Ale ví někdo jak to funguje? Když už byl zápis commitnuty z cache směrem k sql serveru, tak byl ok. Je pak na controlleru kdy zapíše obsah na disky. Vždy se to dělá na velkých polích tak, že ta cache je tam minimálně ve dvou kopiích a je replikovana. To aby pád controlleru neznamenal zastavení provozu. A i kdyby celé pole padlo a data zůstaly v cachich tak prvni věc je zapsat data z cache na disky, kdyby ne tak to nenajde s nějakou hlaskou a volá se vendor. Pokud by padl jeden controller a bylo by něco s nvram ve startovanem controlleru kontrola by na to přišla a opět by to stoplo, pokud ne, nvram se smaže a jede se dal, protože to obsloužil běžící kontrolér. No a při mirroringu na další pole je ten zápis hazeny na druhé pole při zápis do nvram a ne při zápisu na disky (teda očekával bych za ty dve Tesly) alespoň synchronní mirror. A v případě redologu či jiných transakcnich dat jsem měl dojem, že je vyžadováno aby byla uložena jinde, než na místě kde jsou produkční data, proboha, stačilo by i na lokálním disku odehrávanym do backup řešení. Asi tak. Musel jsem se z toho vypsat. Když už si najímají odborníky tak at to delaji z různých oblastí, může se jim to vyplatit.

Loni mela Alza obrat 21 miliard. Kdyz to vezmeme pro zjednoduseni ciste na hodiny, tak 27 hodin je u nich nejakych 65mega obratu

nestřílejte specialisty, ale člověka co tam dal SQL server od Microsoftu. Ze všech databází co znám je nejpomalejší a má nejzvrácenější logiku. Jinak se imho jedná o problém návrhu že jsou aktivní data v jedné obří databázi se starými objednávkami ale to je oproti selhani cele db detail. Btw proč nemají active-active cluster?

Jojo, a bezva je, když zákazník do helpdesku hodí tiket s kritickou závažností, a popis problému vypadá, jako kdyby ho posílal přes twitter... "něco se rozbilo a něco nejde". Zavoláš tam, a ten kdo to takhle odeslal šel po šichtě domů, nikdo neví co se stalo, co mu nešlo, kdy se to stalo (takže se v logu není čeho chytit), a všem teď všechno funguje a nikdo problém nemá.

to sa mi paci :) Ale aj IBM DS som videl vselico. Silent data corruption na DS8300, corruption dat pocas patchovania firmware a tak... A aj IBM DS ma option PPRC, abysa pekne zrkadlilo na druhe IB DS ;) Dnes mozno radsej 2x storwize s metro mirror, ako len jedno DS ako SPOFZ

ked niekto obhajuje usporu penazi ALZA, neuvedomuje si to, ze alza kludne mohla stratit niekolko hodin objednavok. Teraz zrejme storage poskodil transakcny log v case vypadku, system spadol a uz sa nedarilo recovery. Pri obnove z full zalohy a vykonani incomplete recovery sa ale mohlo stat, ze by sa podarilo recovery po cas 1-2h pred vypadkom. Tym by stratili 1-2h objednavok klientov, ktori im poslali peniaze. Muselo by to narocne parovat z billingoveho systemu a prachy posielat naspat, lebo by zrejme nevedeli za co im ich ludia poslali. Zda sa ze teraz mali stastie a stratili objednavok par, ze sa o tom ani neoplati rozpravat.
takyto system v takej velkej firme proste potrebuje syncronnu repliku do druheho DataCenter

vzdyt to tam pisu vyse, IMHO prasarna