Škodu Auto trápí výpadek databáze, ne samotného SAPu
Včera v pozdních odpoledních hodinách přinesla mainstreamová média informaci o výpadku informačního systému SAP německého softwarového giganta SAP AG v mladoboleslavské automobilce Škoda Auto. Jak se nám však podařilo zjistit, nejednalo se ve skutečnosti o výpadek v samotném systému, ale došlo k selhání jedné z databází.
Zajímavé na celé události je, že tak velká společnost jako je Škoda Auto nemá pro podobné technologické potíže připravený adekvátní Disaster recovery plán, tedy pokud v něj nepočítáme zoufalou snahu o „ruční expedici“, díky níž bylo včera z areálu odesláno několik set aut.
"Naši odborníci pracují na odstranění softwarové chyby. V tuto chvíli máme dobrý předpoklad, že to bude v nejbližší době odstraněno," vydala k události prostřednictvím svého tiskového mluvčího Rudolfa Dreithalera oficiální prohlášení společnost Škoda. "Samotná výroba běží a dokonce běží i expedice. Není pravda, že by expedice stála," brání společnost dále mluvčí.
Škoda auto dodala za první tři kvartály zákazníkům 741 800 vozů, což je meziročně o 16,2 procenta více než v předchozím roce.
Komentáře
#1
Zda se, ze autor nema zkusenosti s rozsahlymi systemy pro zakaznika takovych rozmeru jako je Skoda Auto.
V pripade zavleceni sw chyby do jedne casti tak obrovskeho mnozstvi systemu (navzajem tesne propojenych) se velice tezko dela recovery, protoze je treba zachovat spravna data a jen opravit "chybna".
Tohle neni o hw vypadku, kdy switch do zalozniho centra je "rutinni" zalezitosti pro adminy.
Ty ses zase chytrej co??? Gigant jako Skoda Auto ma mit primarne recovery site, kam se da presmerovat provoz po doby vypadku hlavni site (sice nebude mit pro praci nejspise posledni verzi dat, ale apon muze pracovat).
Nechapem preco sa takto navazas do komentujuceho. Ja plne suhlasim s jeho komentom. Recovery site je bezne pouzivana vec a v databazovom svete sa bez problemov da nastavit "oneskorenie". Inak povedane na primary site mam aktualne data a na standby napr o 24 hodin neskorsie ... ale tu uz prichadza ten samotny problem. Vies si predstavit manualne zadavat vsetko znova za 24 hodin ? Popripade fakt, ze si vcera objednal auto a uz dnes neexistuje tvoja objednavka ? ... nie vzdy ja to pouzitelne riesenie a realne som nevidel oneskorenie viac ako 8 hodin medzi databazami ... tu podla popisu prislo k najhorsiemu a to poruche na urovni sofwaru, ktora vniesla logicke chyby do databazy. Presne ako bolo spomenute, to uz nie je vymena disku, prepnutie clustra, alebo nahrada switchu ... k sw poruche mohlo kludne dojst aj niekolko tyzdnov dozadu a ani 48 hodin oneskorenie by ti v tom pripade nepomohlo ...
Recovery site je vice-mene k prdu. Dneska vetsina DR scenaru pocita s tim, ze nejaka komponenta shori jasnym plamenem. Pokud se ale nejaka soucast systemu zacne chovat "divne" tak je vymalovano. Vzpominam si na jeden incident, kdy jsme meli v Oracle DB vice jak 5 let corrupted blok. RMAN si toho celou dobu pri zaloze nevsimnul, a najednou zacala databaze padat protoze zvenku opakovane prichazel pozadavek na aktualizaci toho konktetniho zaznamu.
Pokud mate v systemu takovouhle tikajici bombu tak jsou vsechny DR scenare k nicemu. Zvlast pokud je problem v integrite dat nebo vubec v cele vnitrni logice.
Zrovna SAP umí něco jako decentralizované databáze (je tam nějaké cachování), takže by nebyl problém zapisovat do "lokální" databáze a pak data přenést do původních dat. Otázka je, jak to mají v tomto konkrétním případě napsané a jak mají nastavené firemní procesy.
Vzhledem k tomu, ze nemaji ani aktualni platne zalohy, jsou to vazne amateri. Jeste ze jejich IT odbornici nedelaji treba na letisti.
EUR
USD
JPY
