Online je pro O2, coby klíčového hráče na českém telekomunikačním trhu, hlavní kanál, kterým chce oslovovat koncové zákazníky. Ti jsou dnes díky neustálé snaze konkurence přetahovat potenciální nespokojence náročnější, než kdykoli dříve, a to jak na služby samotné, tak na způsob, jakým jsou poskytovány. Bezproblémový chod online samoobsluhy Moje O2, kde si zákazníci mohou zkontrolovat stav svých služeb včetně vyúčtování, je proto základním předpokladem úspěchu.
Jak se na jeho zajišťování podílí nástroj pro aplikační monitoring Dynatracenasazený od roku 2014 jsme si povídali s Petrem Venerou, vedoucím dohledu nad divizí Online Systems operací ve společnosti PPF IT Services.
Když jste se rozhodovali nasadit na monitoring online samoobsluhy APM, jaká byla vaše primární očekávání?
Potýkali jsme se s komunikačním nesouladem mezi oddělením IT operation a odděleními marketingu a byznysu. Oddělení mezi sebou často diskutovala, co přesně výpadek byl, co výpadek nebyl a proč se informace o tom, že se něco děje, nedostala včas do oddělení péče o zákazníky.
Běžný, ne však ideální scénář v takových případech bývá, že si jednotlivá oddělení ve snaze o dokonalý přehled o stavu systému pořizují vlastní nástroje pro monitoring stavu systému, a pokoušejí se tak kritické situace řešit čistě po vlastní ose. Tento přístup často vede k tomu, že si jednotlivá oddělení podávají a srovnávají nesourodá data z různých monitorovacích systémů, která nemusí být vždycky nutně kompatibilní.
Namísto toho, aby se spolu domlouvala o povaze vzniklého problému, se tak celá diskuze přesouvá do roviny dohadování o kompatibilitě dat a porovnávání jednotlivých výsledků. Typický příklad je, že monitorovací nástroj byznysu zahlásí výpadek. Byznys přichází za IT oddělením, které se podívá do svých logů a prohlásí, že nešlo o výpadek, ale o selhání monitorovacího nástroje, a tak to jde dál a dál, ztrácí se čas a nevraživost mezi odděleními vzrůstá.
Naše hlavní očekávání tedy bylo získat takový nástroj, který nám umožní se dívat pouze na jedna data. Další podmínka byla, že musíme mít společný monitoring, kdy každý alert současně vidí IT, které může okamžitě začít řešit problém, a zároveň se o něm ihned dozví byznys a oddělení péče o zákazníky, a mohu adekvátně reagovat.
Rozhodli jste se nakonec pro nástroj, který toho ale umí více, než co popisujete. Co vás k tomu přimělo?
Když jsme se začali na trhu s APM softwary trochu orientovat, porovnali jsme jednotlivé možnosti a napadlo nás, že by bylo určitě škoda zůstávat u aplikace, která nám může nabídnout pouze monitoring. U samoobsluhy Moje O2 se přímo nabízelo hledat takový nástroj, který by nám rovnou umožnil analyzovat, co se vlastně stalo.
To znamená, že nás nasměruje na problém bez toho, že bychom museli zburcovat databázové experty, správce operačních systémů a aplikační administrace. Pokud bychom Dynatrace nasazený neměli, byli bychom sice schopni rychle zjistit například to, že aplikace neběží, ale již ne, proč se to děje. Jen samotná analýza toho, proč se problém vyskytl, dokáže zaměstnat čtyři až pět lidí často na mnoho hodin.
Dynatrace oproti tomu dokáže tuto fázi rychle zaměřit, takže okamžitě víme, kde problém leží a kam se máme začít dívat. Tuto funckionalitu jsme na počátku od požadovaného APM nástroje neočekávali a ukázalo se to jako opravdu značný benefit při finálním kole výběrového řízení. Byla tedy rychlá analýza a nasměrování na problém rozhodujícím kritériem pro implementaci? Řekněme, že šlo o optimální mix více rozhodovacích faktorů.
Dalším důležitým momentem byla také cena. Ze tří nástrojů, které jsme nakonec zvažovali, Dynatrace nabízel jednoznačně nejvíce a jeho cena přitom nebyla nejvyšší. Po té, co jsme se za IT víceméně rozhodli, bylo ještě třeba obhájit náš návrh před rozhodovací komisí, a to přesvědčivým případem užití. To se bez nasbíraných dat z reálného provozu dělá poněkud obtížně, ale nakonec se podařilo.
Jaké byly hlavní přínosy nasazení?
Byznys získal mnohem větší kontrolu nad funkčností aplikace Moje O2 a nám se zjednodušila analýza problémů. Vidím zde s odstupem ještě jeden velký přínos, a to pro vývojáře. Místa, která se nám dříve velice obtížně zkoumala, jsou v Dynatrace snadno dostupná pomocí dashboardů.
Pokud se například výrazně zpomalí dotazování SQL databáze, stačí se nyní podívat na dashboard a celý problém je odhalitelný doslova na dvě kliknutí. Dříve stejná práce zahrnovala procházení množství kódů. Jen analyzování logů obnášelo vybrat všechna volání na databázi, seřadit je podle doby odezvy, ty zprůměrovat, a z toho teprve udělat nějaký závěr.
Vyskytly se nějaké problémy při samotné implementaci?
Naopak nás překvapilo, jak byla celá implementace bezproblémová. Jeden den se objevil konzultant z Adastry a druhý jsme se již dívali na první data. S čím jsme původně nepočítali, byla nutnost pořídit nový serverový hardware. Tento handicap ale přinášela všechna zvažovaná řešení. Jiný problém se skutečně neobjevil?
V post-implementační fázi samozřejmě chvilku trvalo, než jsme si uvědomili, co přesně chceme měřit a kde dále lze potenciál Dynatrace efektivně využívat. Nějakou dobu jsme také strávili tím, že si všichni (zejména lidé v provozu a vývojáři) zvykali aktivně s pomocí Dyntrace problémy řešit. To jsou ale všechno spíše psychologické nuance, než problém na straně softwaru.
Využíváte dnes Dynatrace skutečně tak, jak jste si původně představovali?
Ano i ne, původní plán byl, že díky úspoře času při analýze chyb v aplikaci ušetříme čas a zaměstnance, kteří se analýzou a následným řešením zabývají. Tak to ale v praxi nefunguje, Dynatrace nám naopak odhaluje stále nové a nové kritické situace, na které bychom jinak přicházeli až mnohem později, zpravidla při nějakém závažném selhání před zákazníkem.
Objem práce je tak ve finále stejný. Rozdíl je v tom, že jsme schopni jednotlivá selhání řešit rychleji a často mnohem dříve, než se z nich stanou skutečné problémy. Možná to není na první pohled tolik vidět, ale dochází díky tomu k výraznému zkvalitnění celé aplikace, a tím služby pro cílového klienta.