Úvod
Níže uvedený příspěvek se Vás bude týkat ve dvou případech, pokud ve Vaší společnosti:
1) existuje BI/DWH řešení a vy pracujete s jeho výsledky
2) zatím BI/DWH řešení neexistuje ale v krátké době Vás čeká jeho příprava
Ostatním lze nabídnout informace k zamyšlení nad jejich stávajícími systémy, protože to, co je zde prezentováno se ve velké míře týká i klasických OLTP systémů a reportingových řešení.
Pro ty z Vás, kteří se potýkají s nízkým výkonem existujících BI/DHW řešení je primárně určena tato první část, v které jsou nastíněny potenciální příčiny problémů, které vedou ke stavu, kdy se znehodnocuje Vaše investice do BI/DWH řešení. V závěru je navrženo několik kroků kudy ven z tmavého lesa.
Druhá část je zaměřena na prevenci, protože ta je samozřejmě klíčová. Nejen proto, že je výrazně levnější než úprava existujícího řešení, ale má největší vliv na celkovou životnost a provozovatelnost řešení.
Část I: Existující BI/DWH řešení
Když Váš pracovní den začíná přibližně takto:
Chcete si otevřít přehledové reporty, které Vám jednoduše prozradí, jak je na tom Vaše firma, resp. Vaše oddělení….a reporty se včerejšími daty nejsou připravené.
Když pátrátr po příčině dostává se Vám odpovědi…."Reporty budete mít až zítra, když se zadaří, v noci jsme měli problém a teď to pracuje pomalu...Oracle databáze nestíhá...hodně dat….chce to pořádnou databázi…víc s tím udělat neumíme"
Na Vaši připomínku, že stejnou odpověd Vám dávají poslední dva měsíce dostáváte odpověď:
"Data v datovém skladu rostou rychle, stávající řešení nezvládá nárůst dat, datový sklad začíná pravidelně dobíhat až odpoledne..."
Na Váš oprávněný dotaz, jestli s tím zkoušeli něco dělat odpovídá IT „mantrou“:
"Aplikační administrátoři hledali příčinu, ale vše se tváří že běží, bude to v nízké rychlosti databáze. Databázoví administrátoři koukali na databázi, a ta jede, parametry jsou stále stejné, žádná změna nebyla, čeká se na I/O. Systémáci koukali na server, ten má zatížení CPU jen 30% v serveru to není. Administrátor diskového pole hlásí průměrné zatížení diskového pole, při poslední kontrole ze strany automatických ladících mechanismů pole nebyly žádné návrhy na zlepšení. Dodavatel řešení navrhuje upgrade řešení s rozpočtem jednotek milionů.Howgh“
Když se obrátíte na dodavatele HW (servery, disková pole) a poskytovatele SW, rádi Vám nabídnou upgrade na lepší HW (pár GB paměti navíc, výkonnější CPU, případně dodavatel SW pár dalších licencí a další featurky databáze....ovšem s detailem, že vy na to musíte sehnat rozpočet....
V tomto případě pokračujte ve čtení, protože se pravděpodobně stáváte obětí „kolektivní nezodpovědnosti“.
Kolektivní nezodpovědnost
Kolektivní nezodpovědností je nazýván stav, kdy nelze jednoduše ukázat prstem na jednu příčinu „pomalosti“ řešení resp. na jednoho člověka, který je odpovědný za aktuální problémy provozovaného IT řešení (a kterého lze po právu ztrestat), která když je vyřešena, tak je zase vše v pořádku. Je to souhra několika faktorů a částečné odpovědnosti více pracovníků v době přípravy řešení a jeho následného provozu, což v důsledku znamená právě kolektivní nezodpovědnost.
Pro čtenáře, které trápí problémy stávajícího BI/DWH řešení zde uvádíme tabulku potenciálních příčin problémů týkající se provozu řešení:
Tab 2: Klíčové faktory v období provozu řešení
| Faktor | Popis | Odpovědnost |
| P.1 | Struktura a nastavení odpovědnosti jednotlivých oddělení IT provozu | IT manager |
| P.2 | Motivace IT provozu ke komplexní péči o řešení | Board/IT manager |
| P.3 | Podpora IT oddělení při zavádění komplexní péče | Business vlastník |
Faktor P1: Struktura IT Operations
Schéma č.1 znázorňuje standardní architekturu informačních systémů a její mapování na klasickou organizační strukturu IT.
Objasněme si velmi stručně, jaké jsou odpovědnosti jednotlivých rolí ve vazbě na řešení:
| Role | Náplň role |
| Správce reportingové platformy | - Správa uživatelských účtů a profilů - Přístup k reportům - Deployment nových reportů - Správa distribučních kanálu pro reporty |
| Správce datového skladu | - Zajištění chodu datového skladu a aktualizace jeho dat - Monitoring procesů aktualizace DWH, detekce chyby, opravné spuštění - Reakce na nestandardní stavy (výpadky zdrojových systémů, opravné dávky, atd) - |
| Databázový administrátor | - Správa databází (databázových instancí) - Správa uživatelských účtů v DB - Správa prostředků databáze (role, systémová práva, tablespaces, využití prostoru atd.) - Konfigurace a provádění zálohování databází ve spolupráci se systémovými administrátory - Zajištění obnovy databáze po poruše HW |
| Systémový administrátor, (Správce serveru) | - Správa operačního systému - Správa uživatelů na úrovni OS - Monitoring zatížení serveru - Zálohování serveru - Aplikace patchů operačního systému |
| Administrátor SAN infrastruktury | - Konfigurace a přidělení úložné kapacity v rámci SAN podle požadavků IT - Monitoring diskových polí - Monitoring požadavků na úložnou kapacitu v rámci SAN |
Pozn. SAN – Storage Area Network
Kde je potenciální problém ?
- Každý tým si obhospodařuje pouze svěřenou část infrastruktury
- Úzké zaměření týmů – systémový administrátor toho ví velmi málo o databázích a naopak. Stejně tak aplikační administrátor ví málo o fungování technologií.
- Náplň práce představuje rutinní udržování systémů v chodu, které je dost často díky divokým kombinacím použitého software časově náročná
- Odpovědnost resp. hodnocení IT je zaměřené na udržení systémů v chodu, případně na výkonnostní ukazatele jednotlivých součástí infrastruktury
Závěr:
- Chybí komplexní pohled na řešení skrze jednotlivé prvky infrastruktury – jak nastavit diskové pole, servery, operační systém a databázi tak, aby byla infrastruktura nastavena na optimální výkon nejen pro řešení typu BI/DWH
- Neinvestuje se do průběžného ladění a drobných vylepšení, které mohou mít zásadní vliv na nárůst výkonu řešení
- Chybí investice do know-how pracovníků IT (školení, užší spolupráce s dodavatelem řešení za účelem pochopení potřeb řešení, proškolení IT pracovníků z pohledu funkcionality BI/DWH řešení a nároků kladených na infrastrukturu)
- Velmi často není využíváno možností infrastruktury nakoupené za vysoké finanční částky (typicky disková pole, využití paměti serveru atd)
Faktor P2: Motivace IT provozu ke komplexní péči o řešení
Pokud je dodavatelem řešení solidní firma se zkušenostmi v dané oblasti je v rámci projektu definována role Technical Solution Architect (TSA), někdy také pojmenovaná Technology Solution Architect. Tato role představuje párovou dvojku k roli Business Solution Architekta.
Business solution architekt zodpovídá za obsahovou správnost řešení tj. aby bylo v souladu s business požadavky. Technology solution architect zodpovídá za technickou úroveň řešení, zajištění požadovaného výkonu a začlenění řešení do IT infrastruktury zákazníka dle požadavků.
Do doby předání řešení do provozu zodpovídá za architekturu řešení dodavatel.Po akceptaci je řešení převzato do provozu.
A od té doby představuje toto řešení víceméně sirotka, který roste „jako kůl v plotě“. V typické BI/DWH řešení objem dat roste, provádí se dílčí změny funkcionality na základě změnových řízení, zkrátka se jedná o mnohem dynamičtější systém než standardní transakční aplikace.
Protože toto řešení nemá po předání do provozu rodiče, který by se o něj s péčí starali, stává se z něj často divoký nevychovaný výrostek, který vám v důsledku může provádět hodně nepříjemné věci (nekontrolovatelný nárůst objemů dat, výkonnostní degradace, zahlcování infrastruktury, vynucení upgrade HW atd).
IT provoz je zodpovědné pouze za zajištění provozu, ne za komplexní péči o řešení. Stávající úroveň péče se s ohledem na možnosti a znalosti oddělení redukuje na základní kontroly běhu a v případě závažných chyb pak na snahu o opravu této chyby a opětovné zprovoznění.
Komplexní péčí rozumíme:
- Revize návrhu architektury a sizingu v době definice řešení a vyjasnění si sporných otázek s dodavatelem řešení
- Pravidelná výkonnostní profylaxe ve formě sledování trendů a jejich predikce
- Průběžný výkonnostní monitoring a ladění
- Používání možností infrastruktury k dosažení nutného výkonu
- Vyhodnocení navrhovaných funkčních změn na celkový výkon řešení
- Vytvoření budgetu na komplexní páčí v rámci výpočtu TCO nákladů na řešení
Z výše uvedeného seznamu je zřejmé, že je to činnost náročná na znalosti i na čas, a to nejen technologické. A typické IT oddělení na tyto činnosti nemá kapacitu a bohužel ani budget.
Business vlastník investuje vysoké částky do pořízení infrastruktury a řešení. Pokud řešení typu BI/DWH nemá po přechodu do produkce zajištěnu komplexní péči, dochází k postupnému znehodnocení této investice. V některých případech se jedná o velmi rychlé znehodnocení do 1 roku provozu. V horším případě na business vlastníka čeká jednání o úpravách systému a případný upgrade infrastruktury, aby alespoň v minimální míře byl schopen toto řešení používat.
Faktor P3: Podpora IT oddělení při zavádění komplexní péče
Nemysleme si, že IT oddělení je skupina sabotující Váš business. Tito lidé velmi často ví, kde systém pálí pata, ale nemají možnost s tím něco udělat. Proto se budou dál snažit udržet zahlcující se systém, vždyť jde i o jejich profesionální čest.
Je třeba si ale uvědomit už na počátku návrhu řešení, že právě tito lidé se budou muset o Váš systém starat a je třeba s nimi o připravovaném řešení mluvit a diskutovat, aby bylo navržené řešení akceptovatelné pro obě strany.
Co je vhodné komunikovat:
| Od business vlastníka k IT | Od IT k business vlastníkovi |
| Varianty technického řešení, hledání shody | Nové technologie znamenají potřebu školení, když začleníme do nákladů projektu, jsme schopni akceptovat danou technologii |
| Jaké jsou odhadované náklady na zajištění komplexní péče, které máme zahrnout do rozpočtu (náklady na práci IT, zaškolení IT pracovníků atd) | Komunikovat rozumné odhady a nestažit se tlačit za každou cenu na pilu. |
| Jakou formu a rozsah dokumentace potřebujete pro zajištění komplexní péče | |
| Jako business vlastník řešení by jste měli být připraveni na náklady spojené s komplexní péči o řešení. | Potřebujeme provést změny v běžícím systému, podpořte náš požadavek na budget. |
Bohužel pravidlem je, že místo aby business a IT táhlo za jeden provaz, tak v převážné většině velkých společností je to právě naopak. Velmi často pracuji v roli, kdy plním roli posla a vyjednavače mezi business vlastníkem a IT oddělením. Setkávám se s názorem businessu, že IT brzdí jejich business, protože ten a ten systém nestíhají zavést a přitom je to tak jednoduché, jak říkal jeho distributor resp. prodejce. Z druhé strany zase zaznívá nelichotivé vyjádření o technických schopnostech business oddělení.
Nevím, zda je to dáno historickým vývojem, ale vím jistě, že je třeba to změnit, protože dobře a kooperativně fungující IT v dněšní době představuje přímou konkurenční výhodu a možnou výraznou úsporu v celkových nákladech na IT.
Závěr
Na závěr této části uvádím pár rad, jak se vyhnout problémům se zajištěním provozu systému:
1. Věnovat čas a úsilí v době návrhu řešení tomu, aby byla vybrána kombinace technologií, které bude plnit potřebné cíle dané business zadáním, ale nebude znamenat „vykradení“ budgetu na projekt.
2. Trvat důsledně na zavedení a dodržování procesů komplexní péče při provozování BI/DWH řešení včetně vyčlenění budgetu na tuto činnost.
3. Definovat v rámci projektu výkonnostní ukazatele, které budou klíčové pro provoz řešení
4. Realisticky pohlížet na možnosti technologií, obchodník s nimi není ten nejvhodnější člověk, který vám popíše reálné možnosti a omezení daných technologií.
5. Využít možnosti nezávislého auditu řešení již ve fázi návrhu řešení, což v důsledku může ušetřit vysoké náklady na jeho případnou změnu v provozu.
6. Vyjednávání typu Win-Win při tvorbě technické architektury řešení mezi dodavatelem, business vlastníkem a IT oddělením.
Praxe:
Na základě zkušenosti s laděním a audity BI/DWH řešení v ČR bych zde rád uvedl TOP 5 příčin problémů s výkonem BI/DWH řešení realizovaných s využitím databáze Oracle. V tabulce je uvedena definice problémové oblasti, typický projev problémů, četnost počet jejich výskytu (celkový počet auditů 6). Četnost výskytu je ovlivněna tím, že se téměř vždy jednalo o řešení vykazující nějaký problém, takže byl vyžádán audit řešení:
| Oblast | Projev | Bližší popis projevu | Četnost výskytu |
| Nevhodně připravené reporty resp. datový model | Dlouho trvající reporty resp. odezva datového skladu | Nutnost redefinice reportů pro problematickou část řešení (zdrojový dotaz), případně redefinice datamartů a agregátů, optimalizace datového modelu | 6 |
| Konfigurace infrastruktury (servery a diskové pole) | Neadekvátně dlouhá doba odezvy na vyladěné dotazy, výskyt vysokého počtu čekání databáze na prostředky operačního systému resp. přístupu k datům, nízká I/O propustnost databáze | Nevhodná konfigurace parametrů operačního systému pro potřeby databáze, nutnost redefinice úložišť na diskovém poli, nejčastěji spojeno s oblastí nevyladěné databáze. | 5 |
| Nevyladěná databáze Oracle | Dlouhá doba odezvy na vyladěné dotazy | Optimalizace parametrů databáze, redesign databázových úložišť (tablespaces, mountpointy), optimalizace ETL procesů s využitím vlastností databáze | 5 |
| Sizing řešení | I přes veškerou optimalizaci a ladění není zajištěn požadovaný výkon | Podcenění nárůstu objemu dat v DWH | 2 |
| Nevhodná architektura řešení (nevhodná kombinace technologií) | Dlouho trvající aktualizace dat, dlouho trvající reporty, celkové zahlcování řešení, nepomáhá ani vyladění infrastruktury a databáze | Špatně nadefinované vrstvy datového skladu, nevhodně udělané historizace v normalizované vrstvě, nevyužívání možností databáze, redesign ETL procesů Pozn. Datový sklad realizován několika obecnými tabulkami s parametrizací obsahu dle parametrů | 1 |
Několik perliček z praxe, aneb vybrané výsledky z auditních zpráv:
- Zákazník používá enterprise server s 24GB RAM. Operační systém a databáze májí ale nastaveny parametry, které i při špičkovém zatížení neumožňují alokovat více jak 8GB paměti pro potřeby databáze (cena 1GB paměti v takové třídě serveru představuje tisíce EUR)
- Zákazník používá enterprise diskové pole – pro databázi je ale vytvořen jeden mountpoint, kde jsou všechna data, logy a řídící souboru databáze. Celková I/O propustnost je max. 10MB/s (typicky lze dosáhnout zhruba 10 násobné průchodnosti. Na užaslý dotaz proč je to takto, odpovídá IT tím, že je to enterprise pole, které to zvládne a dobře se to tak zálohuje. Krásný příklad plýtvání investicemi, když i váš disk v notebooku má průchodnost 30MB/s
- Zákazník používá Oracle a hlásí, že už bude muset přejít na jinou platformu pro DWH, že to Oracle nezvládá s objemem dat. Výsledek ? Nevhodně nastavené parametry databáze, konfigurace diskového pole obdobná jako v předchozím případě, ale osobně bych rád dostal do ruky člověka, který psal nad tímto skladem dotazy v reportech :o)
- Zákazník chce provozovat datový sklad o objemu řádově 1TB s dynamickým růstem na 4xdualcore 64bit serveru s 12 GB RAM, kde jsou instalovány 32-bitové windows a 32-bitový oracle….tomu se v branži říká nezřízený optimismus
- Zákazník používá databázi Oracle DB a ETL Informatica powermart. Deklaruje nízký výkon databáze resp. dlouhou dobu loadu…výsledky ukázaly, že naráží na limit ETL platformy (snaží se v krátkém čase vyhodnocovat změny pomocí plného porovnání dvou snímků zdrojové tabulky se 100miliony záznamů). Vyřešeno pomocí diferenčních view na úrovni databáze a vyladění databáze.
Bohužel praxe ukazuje stav, který je známý i z jiných oblastí techniky. Zákazník resp. IT si velmi často pořizuje infrastrukturu a software s vysokou investiční náročností, kterou pak ale nevyužívá vhodným způsobem, takž dochází k plýtvání investičními prostředky. Jako když si koupíte mobilní telefon typu Smart, který má operační systém a desítky dalších vlastností, ale vy s ním jen telefonujete a píšete textové zprávy. Když se Vás pak ale někdo zeptá, jaký máte telefon, s hrdostí ukazujete a odpovídáte. To že z jeho možností využíváte 10% není v tu chvíli důležité. Bohužel ale v tomto případě nejde o telefon, ale investice v řádu milionů, které musel zaplatit business vlastník řešení.
Žádné komentáře:
Okomentovat