S problémy, které čas od času nastávají například v bankovních aplikacích si dokáže poradit aplikační monitoring. „Díky němu vidíme, jak dlouho, co a kde v rámci aplikačního běhu trvá. Umíme to provázat s metrikami z logů, s metrikami infrastruktury, s cloudem, prostě se vším, co v dnešním moderním IT najdeme. Ale hlavně umíme jít až na úroveň kódu, což potom pomůže vývojářům problém opravit,” vysvětluje Jiří Kurejko, který pracuje v Adastře jako expert na aplikační monitoring.
- Kdy nasadit aplikační monitoring?
- Proč se bankám vyplatí aplikační monitoring před spuštěním nového internetového bankovnictví?
- Jak ve firmách snížit počet stížností adresovaných IT na fungování systémů?
- Proč mají někteří zákazníci technické problémy, a jiných se nedotknou?
Poslechněte si podcast
Přečtěte si podcast jako rozhovor
Ivana Karhanová: Reálný příklad z praxe. Každý den v 10 hodin a 30 minut se v jedné české bance zpomalil interní systém tak, že back office nemohl pořádně pracovat. Několik měsíců si nad tím lámal hlavy tým těch nejseniornějších lidí, ale na nic nepřišli. Záhadný problém 10:30 trval dál. Každý den na několik desítek minut mohl jít back office na kafe. Se mnou dnes ve studiu sedí muž, který ten problém vyřešil. Jiří Kurejko, expert na aplikační monitoring v Adastře. Ahoj, vítej ve studiu.
Jiří Kurejko: Ivo, díky za pozvání.
Ivana Karhanová: V čem byl zakopaný pes?
Jiří Kurejko: Já bych ještě upřesnil, že jsem to nevyřešil jenom já, ale pracoval jsem na tom společně s týmem lidí. Zakopaný pes byl v tom, že se tam zkřížily nějaké logy, když to řeknu netechnicky. Ta aplikace nějak logovala svůj běh a něco se tam pokřížilo tak, že pro kolegy v té bance opravdu nebylo úplně snadné najít ten problém.
Ivana Karhanová: Dobře, ale proč oni nebyli schopní po několik měsíců rozpadnout ty logy, projít to a zjistit, kde se to blokuje?
Jiří Kurejko: Oni do toho neviděli takhle hluboko, protože ten monitoringový svět, který už dneska máme, je tak složitý, ty systémy jsou tak velké, že jenom analyzovat tohle všechno z logů prostě nestačí. Občas tam ty informace vůbec nejsou, nebo jsou zakopané pod spoustou dalších informací a dostat se k nim a všechno provázat mezi sebou je strašně složité.
Ivana Karhanová: A jak jsi to ty se svým týmem vyřešil? Co se stalo, že jste najednou viděli, v čem je chyba?
Jiří Kurejko: My jsme jim nasadili na jejich aplikaci Dynatrace, což je řešení pro aplikační monitoring, které umí problémy, které se v aplikacích stanou, rozpadnout až na úroveň kódu. A tam potom vidíme, jak dlouho, co a kde v rámci aplikačního běhu trvá. Umíme to provázat s metrikami z logů, s metrikami infrastruktury, s cloudem, prostě se vším, co v dnešním moderním IT najdeme. Ale hlavně umíme jít až na úroveň kódu, což potom pomůže vývojářům to nakonec opravit.
Ivana Karhanová: Pojďme laicky popsat, co se vlastně v té bance dělo. Co způsobovalo, že v 10:30 si mohli všichni dát nohy na stůl, protože neměli na čem pracovat?
Jiří Kurejko: V tom systému pracují řádově tisíce lidí, kteří v něm dostávají úkoly v rámci back office a musí je do nějakého času splnit. Pak dostanou další úkol a v tom systému se úkoly logují tak, že když je úkol splněný, tak se někam zaloguje číslo toho úkolu a číslo člověka, který ho splnil. Lidé začali pracovat od osmi devíti hodin a objem práce se postupně zintenzivňoval. Když přišla desátá hodina nebo 10:30, logy se v rámci logování událostí v tom systému navzájem zamkly. Aplikace logovala jeden úkol a nemohla zalogovat další úkoly, které tam čekaly ve frontě. Pak se to mezi sebou vlastně zamklo a ta aplikace začala zpomalovat. Fronty úkolů, které čekaly na zalogování, nakonec způsobily kolaps.
Ivana Karhanová: Jak pak bylo těžké ten problém odstranit?
Jiří Kurejko: Bylo to strašně jednoduché, stačilo se na dvě hodiny zamyslet nad tím, jak je to logování napsané a neudělat ho synchronně, ale nějak asynchronně. Zní to velmi jednoduše, když se to řekne, ale ve chvíli, kdy jsou v tom systému tisíce uživatelů, desítky serverů, navazuje to na desítky dalších bankovních systémů, tak najít tu jehlu v kupce sena je strašně složité. Člověk pak hledá dny týdny měsíce a může hledat opravdu dlouho, pokud tam je hodně systémů provázaných.
Ivana Karhanová: Zmínila jsem, že oni na tom pracovali nebo hledali příčinu toho problému několik měsíců. Jak dlouho pak trvá aplikačnímu monitoringu, než je schopen ukázat, kde v tom kusu kódu je chyba nebo který kus kódu ji způsobuje?
Jiří Kurejko: My jsme strávili pár dní s týmem analýzou toho problému, pobavili jsme se o tom, kdy se to stává, proč, jestli tam není nějaký trigger. Do toho jsme vlastně instalovali Dynatrace, ale potom, jakmile bylo nainstalováno a jakmile jsme pochopili ten problém, tak to bylo v řádu pár hodin, kdy jsme jim to pomohli rozkrýt a ukázat, jak se ty transakce postupně zpomalují a jak narůstá čas, který se tráví v zámcích a v tom logování.
Ivana Karhanová: Zůstaňme i s dalším příkladem v bankovnictví. V další bance, ve které jste právě nasazovali aplikační monitoring, bylo v podstatě účelem odhalit kritická místa, která mohla ohrozit ostrý provoz nového internetového bankovnictví. V čem je konkrétně v tomto případě síla aplikačního monitoringu?
Jiří Kurejko: Na první pohled to vypadá, že aplikační monitoring je hlavně pro produkční monitoring, ale to je obvyklý omyl, který se snažíme rozptýlit. Když ten problém odhalíme už v rámci vývoje nebo testování s aplikačním monitoringem, tak je to samozřejmě pro tu firmu levnější. Opravit problém na produkci a opravit ho v testu stojí úplně jiné peníze. A banka, se kterou jsme spolupracovali, si toho byla moc dobře vědoma. S dodavatelem nového internetového bankovnictví spolupracovala samozřejmě dlouho, a spolupracovali nějakou dobu i s námi. My jsme ty systémy znali a byli jsme schopní se dohodnout na tom, že to pomůžeme odladit ještě před tím, než se to dostane do produkce. Oni sami chtěli zajistit, aby start nového internetového bankovnictví, do kterého vkládali samozřejmě spoustu peněz, spoustu marketingu a spoustu investic, byl co nejhladší.
Ivana Karhanová: My jsme se spolu bavili i o tom, že v podstatě pokud to nasazujeme na konkrétní produkt, tak jsme schopni poměrně jednoduše říct, kde je konkrétní chyba. A vlastní dodavatel s klientem se nemusí dohadovat, kde tu chybu mají hledat.
Jiří Kurejko: Je to tak. Ti dodavatelé ne vždy úplně vědí, kde ten problém je. Když to nevědí a nemají třeba lidi, kteří se tomu můžou věnovat, protože jsou na jiných projektech nebo mají spoustu práce, tak častokrát můžou říct: Ten problém není u nás, je v infrastruktuře toho zákazníka, prostě je někde jinde. Ty systémy už jsou tak složité, a když tam není třeba jenom jeden dodavatel, ale je tam interní IT dodavatel, další dodavatel, cloud provider, a ti všichni mají participovat na provozu té aplikace, tak už se tam dohodnout nastavit vztahy, kdo za co zodpovídá, SLA a podobné věci, není úplně snadné. A pak to ještě odměřit je další legrace.
Ivana Karhanová: A když si tam nasadí aplikační monitoring, tak jestli tomu dobře rozumím, tak aplikační monitoring je schopen už v testu poměrně přesně ukázat, kde celá ta aplikace třeba vázne.
Jiří Kurejko: Určitě. Spolupracujeme se zákazníky, kteří pravidelně testují své aplikace. Před každým releasem je samozřejmě praktické testovat aplikaci, než půjde do ostrého provozu. Zákazníci si potom píšou nějaké třeba i automatizované testy, které jim tohle kontrolují na provedené bázi, aby měli porovnání s tím, co se dělo. Historicky jim tam pomáháme velmi rychle a přesně určit, kde ta aplikace má nějaká slabá místa, porovnat to třeba s tím, co se tam dělo v předchozích releasech a automaticky dát třeba tomu vývojáři zpětnou vazbu: Hele, tady voláš dvakrát tolik databázi, než jsi jich volal předtím. Když je v předchozím releasu 20 volání databáze a najednou jich je tam 50, tak když se to nasadí do ostrého systému, kde je najednou tisíce těchto volání a desetitisíce nebo miliony zákazníků, tak to může tu databázi položit. My pomáháme vidět i tyhle věci, které se odehrávají na pozadí, odhalit v rámci testování regrese, které se v rámci releasů občas podaří udělat ne třeba vědomě. Ne úplně kvůli tomu, že to někdo chce rozbít, ale proto, že třeba byznys má požadavek, aby se v rámci něčeho v té aplikaci volalo víc.
Ivana Karhanová: Na druhou stranu, pokud jsme schopni přesně určit kus kódu, který je potřeba opravit nebo na který je potřeba se podívat, tak v podstatě se nemusí mezi sebou v tu chvíli – v dobrém slova smyslu – dohadovat dodavatel s klientem nebo dodavatelé mezi sebou, kdo to má udělat, protože je úplně jasné, komu ten kus kódu patří.
Jiří Kurejko: Je to tak, to je to velká úspora. Zákazníci říkají, že jim to šetří 80 až 90 procent času, který by se normálně věnoval troubleshootingu a nacházení příčin. Dynatrace jim šetří opravdu velké množství času. Důležité je také si uvědomit, že troubleshooting nedělají ve firmách junioři, ale ti nejseniornější lidé, kteří jsou nejdražší a místo troubleshootingu by mohli dělat nové kusy kódu, nové inovace a automatizaci. Kromě toho jsou většinou frustrovaní z toho, že musí dělat troubleshooting, tedy hrabání se v logu, v nějakých metrikách. Nedělají to prostě úplně rádi. Provoz aplikací je obecně velmi stresová oblast, co si budeme povídat. Znamená to provoz 24/7, být na telefonu, ve 4 hodiny vás někdo vzbudí a musíte to do pěti minut opravit, jinak je to průšvih. A potom se ještě nořit a hrabat v logu, to bývá pro spoustu těch lidí frustrující.
Ivana Karhanová: Pojďme od bankovnictví jenom o kousek vedle, do pojišťovnictví. I tady jste řešili spoustu případů. Část z nich má společný jmenovatel, a to, že vlastní interní systémy bývají pomalé, což blokuje samozřejmě obchod a byznys si pak může stěžovat, že ty aplikace nefungují tak, jak by měly. To znamená, že výkon v tom byznysu nemůže být tak vysoký, jak by se očekávalo. Jak se tohle řeší standardně?
Jiří Kurejko: Standardně se to řeší tak, že se potkávají čím dál vyšší šarže jednotlivých oddělení, tedy vedení obchodu a vedení IT. Každý si přinese svoje grafy a dívají se na to, co je špatně, proč neprodáváme. IT se v té chvíli musí bránit nařčení, že byznys neprodává tolik, kolik by mohl, protože nefungují IT systémy tak, jak by očekávali.
Ivana Karhanová: Co s tím ale IT může dělat?
Jiří Kurejko: IT v té chvíli potřebuje nějaká data, která neměří, typicky zkušenost reálných uživatelů v internetovém bankovnictví. Tam je to vcelku pochopitelné, že potřebujeme měřit, jak funguje internetové bankovnictví u interních systémů. Tam se občas říká, že jsou to přece naši zaměstnanci, oni počkají, nebo si to napíšou někam na papír. Ale i v pojišťovnictví se byznys samozřejmě dost změnil. Už se všechno neřeší na pobočce, spousta pojišťoven prodává přes zprostředkovatele, brokery, a ti mají nabídek, které můžou takhle prodat, celou řadu. Takže když jeden z těch systémů nefunguje, tak prostě přejdou do jiného, prodají to v danou chvíli u jiné pojišťovny. To znamená, že odezva těch systémů a zákaznická zkušenost se už netýká jenom interních zaměstnanců, ale obecně celého toho řetězce.
Ivana Karhanová: Přece na druhou stranu ale i IT musí mít od konkrétních lidí spoustu požadavků typu teď mi to nefunguje, tady to mi nejde zavřít/otevřít, tohle se mi neukládá. Předpokládám, že zaměstnanci píšou na support, když jim něco nefunguje.
Jiří Kurejko: Určitě ano, píšou na support, obracejí se na helpdesk, když jim něco nefunguje. Spousta toho samozřejmě bývá subjektivní. Když se to opravdu neměří, tak se někomu může zdát, že ten systém je třeba ráno pomalý, rozhlásí to všem kolegům v kanceláři a všichni to mají najednou pomalé. Bývá tam hodně dojmů.
Ivana Karhanová: To jsi schopný vyčíst z dat.
Jiří Kurejko: Jsme schopní vyčíst právě to, jak každému z těch uživatelů systém funguje rychle, nebo pomalu, ve které lokalitě, ze kterého zařízení, jakou má konektivitu v dané chvíli, jestli je na rychlém, nebo pomalém připojení. A jsme schopní říct, kteří uživatelé používají třeba zastaralý prohlížeč, proto jim to funguje pomalu. A bylo by asi dobré doporučit jim, aby si pořídili nějaký novější prohlížeč. Tyhle věci jsme schopní z těch dat vyčíst, což se týká i té subjektivity. Když někomu ten systém funguje stejně rychle jako jiným, ale subjektivně se mu zdá, že to je pomalé, tak i tohle jsme schopní podchytit a nějak s tím potom pracovat. Zákazník pak může se svým týmem nějak pracovat, edukovat ho a tak dále.
Ivana Karhanová: Také jsi říkal, že poté, co jste nasadili v této pojišťovně aplikační monitoring, tak pokles incidentů byl neuvěřitelných 90 procent. Čím to, že incidenty téměř vymizely?
Jiří Kurejko: Samozřejmě to bylo jednak tím, že u té aplikace potom, co jsme jí tam nasadili Dynatrace, se udělaly nějaké optimalizace. Ta aplikace se poměrně hodně zrychlila, stabilizovala se a lidem bylo komunikováno, že se nasadil nový systém, který sleduje, jak ta aplikace funguje, a že když to mají pomalé, tak už si nemusí stěžovat, že to IT vidí, a začne to proaktivně řešit. Takže hodně z těch stížností bylo: já to tam radši napíšu, aby o tom IT vědělo, ale oni to stejně nevyřeší, protože ani neví, kde to je, a tak podobně. Byla tam spousta zažitých vzorců, ale ti lidé si opravdu občas stěžovali jenom proto, že se jim zdálo, že to bylo pomalé, ale ve skutečnosti tam byl třeba nový release. Tak si stěžovali, že to zpomaluje ten nový release. Byla tam spousta takových dojmů a pojmů.
Ivana Karhanová: Prostě zatěžovali helpdesk, aniž by s tím mohl efektivně cokoliv dělat.
Jiří Kurejko: Ano. Tam pak počet stížností klesl takhle dramaticky. Osmdesát devadesát procent šlo opravdu dolů.
Ivana Karhanová: Pojďme vzít ještě jeden příklad, který je v IT světě také častý. U mobilního operátora si někteří zákazníci stěžovali, že se nemohli přihlásit do webové samoobsluhy, ale v podstatě podle IT všechno fungovalo naprosto v pořádku. Jeden z typických úkazů, kdy IT na svých dashboardech vidí, že všechno je OK, a přesto si protistrana stěžuje. Co s tím?
Jiří Kurejko: Samozřejmě je to dané tím, co se na těch dashboardech měří. Když se na serverech neměří reálná uživatelská zkušenost, ale měří se tam třeba CPU, tak to může opravdu blikat zeleně, ale když se tam neměří odezva, jakou ten uživatel skutečně má v té aplikaci, tak tam ten problém IT opravdu neuvidí. Všechny databáze a servery sice svítí a blikají zeleně, ale pokud se to nesleduje z aplikační roviny, tak tam ten problém opravdu nemusí být vidět.
Ivana Karhanová: Co tedy bylo příčinou toho, že některým zákazníkům samoobsluha opravdu nefungovala?
Jiří Kurejko: Těch příčin byla celá řada, od nějakých neoptimálních volání v rámci kódu, ale i třeba od nějakých produktových nebo byznysových rozhodnutí. Třeba to, že někteří zákazníci měli na sobě navázaných hodně smluv, hodně čísel a například při přihlášení se jim opravdu všechny jejich smlouvy, faktury a čísla hned vylistovávaly, což u některých zákazníků trvalo poměrně dlouho.
Ivana Karhanová: A možná nebylo v tu chvíli ani třeba, ne?
Jiří Kurejko: Ano, možná stačilo to načítání přesunout do nějaké záložky. A když toho zákazníka zajímá rozpad, tak by si to tam mohl prokliknout. Byly to tedy z uživatelského pohledu poměrně elementární věci, ale taky třeba špatně optimalizované databázové dotazy nebo špatně optimalizovaný kód té aplikace, který se tam historicky už tak nějak zavedl a vlastně to nikdo nepovažoval za nějakou možnou příčinu nebo problém.
Ivana Karhanová: Měli bychom zmínit, že těch zákazníků v podstatě bylo zhruba pět procent z celkového počtu, což znamená relativně málo. Přesto jejich uživatelská zkušenost byla v tu chvíli velmi špatná a mohla ovlivnit i další.
Jiří Kurejko: Určitě. Netýkalo se to třeba všech zákazníků najednou, nebyl to obrovský výpadek, který položí celý systém. O takových výpadcích samozřejmě kolegové z IT vědí a řeší je. Tohle se ale týkalo občas nějakého zákazníka, a právě proto tam bylo velmi složité najít souvislost, proč zrovna se to děje tomuto zákazníkovi, a ne jiným, nebo podobným zákazníkům. Je to právě připojením, které ten zákazník má. Je na mobilním Edge připojení někde na chatě, a proto se mu to načítá pomalu. Nebo je to tím, že má hodně smluv, starý prohlížeč… Anebo je to tím, co máme v té aplikaci napsané tady pro tohoto konkrétního zákazníka, co má ve smlouvě. Takže tam těch příčin zase byly řádově stovky tisíc, co IT muselo prozkoumat. A říkali, že předtím, než jsme začali spolupracovat, to trvalo v řádově týdny, než na tyhle problémy přišli. Každý tiket, který přišel z helpdesku, že volal zákazník, že se přihlašuje dvacet třicet vteřin, řešili řádově týdny zase ti poměrně seniorní vývojáři, seniorní lidé od dodavatele. Potřebovali to vyřešit, protože byznys na to pochopitelně tlačil, že tohle není akceptovatelné. Potom, co jsme nainstalovali Dynatrace a rozběhli ho na té aplikaci, tak kolegové z IT, kteří tu aplikaci znají důvěrně, byli hned schopní tam vidět, kde je příčina, co říct tomu dodavateli, aby opravil. Ti dodavatelé byli potom hlavně hrozně šťastní, že už nemusejí věnovat dlouhé dny a týdny hledání těch jehel v kupce sena, ale během pár hodin to vlastně byli schopní opravit a mohli se věnovat třeba práci na nových funkcích té aplikace.
Ivana Karhanová: Pojďme popsat řešení, o kterém celou dobu mluvíme. O tom, jak vlastně funguje aplikační monitoring, v tomto případě konkrétně Dynatrace?
Jiří Kurejko: Dynatrace je softwarová platforma, která pomocí agentů, kteří se instalují do aplikací, které chceme monitorovat, sbírá spoustu dat. Hodně se teď mluví o konceptu observability nebo visibility, tedy vhledu do těch aplikací. Takže nasbírám spoustu metrik z aplikací a nad nimi se potom i v nějakém kontextu dívám na to, jak ta aplikace funguje. A samozřejmě tím, že těch dat a těch metrik teče v moderních aplikacích strašná spousta, tak je nad tím potřeba poměrně rozsáhlá automatizace, abych se ten monitoring nemusel s každou změnou aplikace konfigurovat a aby se sám adaptoval, sám se učil, co je v těch aplikacích dobré a co je ne tak úplně dobré. A běží tam nad tím samozřejmě nějaká sada algoritmů, která vychází ze zkušeností s provozováním těch aplikací. Dynatrace na tomto poli působí řádově desítky let a je to hlavní byznys firmy Dynatrace. Má tedy poměrně dost know-how, jak ty věci sledovat, jak je vyhodnocovat a jak určovat, co je dobře a co je špatně. Takže ten systém funguje na principu know-how a algoritmů, které pomáhají zjednodušovat a zrychlovat práci.
Ivana Karhanová: Jakým zákazníkům se typicky vyplatí nasazovat toto softwarové řešení?
Jiří Kurejko: Typicky se to vyplatí zákazníkům, kteří mají nějakou velmi kritickou aplikaci. Většinou jsou to větší firmy. Mezi naše zákazníky patří spíše větší enterprise zákazníci, velké banky, pojišťovny, telco operátoři, ale nejen oni, protože v dnešní době už kritické aplikace pro byznys má i spousta firem z dalších odvětví. Typicky ta aplikace musí být opravdu klíčová pro byznys té firmy. A je potřeba, aby tam ideálně byla vyčíslená nějaká cena toho, když ta aplikace třeba nebude fungovat. Kolik nás to stojí peněz, kolik nás to stojí reputačně, což se samozřejmě vyčísluje hůř, ale třeba i to, kolik peněz stojí ten byznys, když to hodinu dvě nebude fungovat.
Ivana Karhanová: O jaké investici se potom bavíme?
Jiří Kurejko: Dynatrace se licencuje prostřednictvím subscription licencí. Pohybuje se to řádově ve statisících milionech korun ročně v závislosti na velikosti té aplikace, té infrastruktury. Ale jsme tam určitě schopní vyrobit nějaké množstevní slevy a podobné věci.
Ivana Karhanová: Jak dlouho vám trvá u zákazníka, než to rozběhnete do podoby, kterou si zákazník může převzít?
Jiří Kurejko: Trvá to v řádu dnů. Dávno pryč jsou už doby, kdy jsme s těmi řešeními trávili měsíce nebo roky vlastně zadrátováním monitoringu těch systémů. Na to už není čas. A tím, jak je Dynatrace automatizovaný, tak nám to trvá řádově pár hodin nebo pár dnů, udělat instalaci, a potom se věnujeme třeba tvorbě nějakých dashboardů, analýze metrik, výstupů, které z Dynatrace chodí, a hodně se věnujeme integraci do zákazníkových procesů, systémů, aby to bylo úplně hladké, aby do té organizace Dynatrace zapadl a mohl okamžitě začít přinášet přidanou hodnotu.
Ivana Karhanová: Zákazníci jsou schopní potom si spravovat ten systém sami, nebo k tomu potřebují pořád ještě tvůj tým?
Jiří Kurejko: Zákazníci si to většinou spravují sami a my jsme v takové roli přítele na telefonu. Když je potřeba se s někým o něčem poradit, něco konfigurovat něco přenastavit, tak se na nás obrací o radu nebo o pomoc. Spíš jsme v roli konzultantů, než že bychom reálně provozovali monitoring u zákazníka. Ten si většinou zajišťují sami.
Ivana Karhanová: Napadá mě logická věc: když nasadíte další aplikaci nebo platformu, aby monitorovala ty aplikace, nezpomalí je ve skutečnosti?
Jiří Kurejko: Ne. Jednak je ta technologie vyvíjená už nějakou dobu, a jednak je velký cíl Dynatrace jako firmy, aby ten software neovlivňoval aplikaci, kterou chceme monitorovat, protože to jde přesně proti principu a proti misi, kterou Dynatrace s tím softwarem má, tedy aby ty aplikace fungovaly rychleji a stabilněji. Samozřejmě to funguje na principu agentů, je tam nějaký výpočetní výkon, který ti agenti potřebují, ale na velkých systémech a obrovských serverech, na kterých většinou ty klíčové aplikace běží, je to do jednoho procenta výkonu. Takže ten server prakticky nepozná, že tam agent běží. Zákazníci si samozřejmě několikrát velmi detailně testovali, jak moc jsme v tomhle opravdu neprůstřelní. Vždycky jsme vyšli s tím, že nebyli schopní poznat, že tam ten agent běží. Na grafech, které si potom malovali v různých systémech, nebyli schopni určit, kde ten agent běží nebo neběží. Zjistili, že zpomalení je opravdu takové, jaké říkáme, nebo třeba ještě nižší.
Ivana Karhanová: Několikrát jsme zmínili user experience, zákaznickou zkušenost uživatelů koncových aplikací. Přesto by ale korporace podle tebe měly brát v potaz developer experience, developerskou zkušenost. Proč?
Jiří Kurejko: V dnešní době, kdy je značný nedostatek kapacit na trhu IT a IT expertů, je velká snaha si zkušené klíčové lidi udržet. A není nic horšího, než když zkušení vývojáři, kteří znají ty systémy, umí je rozvíjet, spravovat a tak dál, jsou frustrovaní nějakými manuálními úkoly, které se dají automatizovat. To ty lidi většinou frustruje opravdu hodně. S Dynatrace se dá spousta úkolů, které se týkají třeba analýzy provozu troubleshootingu, ale i nějaké proaktivní péče o aplikace, zautomatizovat. Zkušení seniorní vývojáři potom mají daleko víc času na inovace, na zlepšování automatizace a tak dále, což je většinou baví daleko víc, než se donekonečna hrabat v logách, a třeba tam nakonec ani nenajít tu příčinu, protože jednoduše v tom logu ani není zalogovaná.
Ivana Karhanová: Říká Jiří Kurejko, človek, který je v Adastře expertem na aplikační monitoring. Díky za dnešní povídání a za návštěvu ve studiu. A někdy na viděnou.
Jiří Kurejko: Díky za příjemné povídání.