produkcyjne monitorowanie krytycznych aplikacji

Redukcja problemów produkcyjnych związanych z wydajnością aplikacji

Redukcja wykorzystania infrastruktury sprzętowej

Jakie jest tempo uczenia się wnioskowania na podstawie wizualizacji flopsarowej?

„Gromadzimy miliony danych o polisach, kierowcach i zdarzeniach drogowych. Zapewnienie niezawodności oraz jakości działania systemów IT realizujących statutowe działania jest krytyczne. Wybraliśmy Flopsar Suite z uwagi na intuicyjność i funkcjonalność rozwiązania. Narzędzie zostało wdrożone w kilka godzin, a jego sprawna obsługa przez zespół administratorów rozpoczęła się natychmiast po wdrożeniu. Za wyborem rozwiązania Flopsar przemawiały także koszty, poziom obsługi posprzedażnej, elastyczność i oferta usług dodatkowych rozwiązań dostawcy. Dane pozyskiwane z monitorowania jednoznacznie wskazują, gdzie powstaje problem, a co za tym idzie, kto ponosi odpowiedzialność za jego obsługę czy naprawę. Dziś informacje pozyskane z oprogramowania Flopsar używamy w wielu przypadkach jako źródła argumentacji w rozmowach z naszymi dostawcami usług  IT” – mówi Grzegorz Rymarski, dyrektor Biura Informatyki, Ubezpieczeniowy Fundusz Gwarancyjny.

produkcyjne monitorowanie systemu związanego z obsługą sprzedaży

Pełna detekcja problemów produkcyjnych (awarie, spowolnienia, błędy)

Szacowanie zapotrzebowania na moc w okresach zwiększonego procesowania danych

Flopsar Suite – kto powinien zarządzać jakością i efektywnością?

Do niedawna Flopsar Suite w Grupie Generali służył jedynie do wczesnej detekcji problemów wydajnościowych w systemach produkcyjnych. Zajmował się tym zespół odpowiedzialny za monitoring systemów i usług IT. Podczas testów wydajnościowych programiści wykorzystywali go do wykrywania nieefektywnych metod i zapytań. Wraz ze zdobywaniem doświadczeń w obszarze wykorzystania Flopsar Suite wypracowany został inny, bardziej skuteczny model monitoringu wydajności aplikacji.

Gdy przyjrzymy się bliżej specyfice narzędzia, możemy zauważyć, że trudno jednoznacznie określić, czy jest to zaawansowany system monitoringu wydajności serwerów aplikacyjnych, czy też może system raportowy do analizy efektywności operacji wykonywanych w systemie IT. W pierwszym przypadku Flopsar może być odbierany jako kolejny system monitoringu wykorzystywany w działach utrzymaniowych, w drugim jako dodatkowy system wspierający rozwój aplikacji oraz etapy szeroko pojętej fazy przekazania usług z dewelopmentu do utrzymania. Musimy uświadomić sobie jednak, że w celu osiągnięcia wysokiej sprawności w dostarczaniu wartości naszym klientom konieczna jest bardzo głęboka synergia tych obszarów. To jednocześnie otwiera szerokie możliwości w zakresie optymalizacji procesów, dzięki eliminacji elementów niepotrzebnie wykorzystujących zasoby IT, które nie dostarczają wartości odbiorcom usług.

Transformacja struktury departamentu i przejście do działania w koncepcji Dev-

-Ops pozwoliła na zastosowanie Flopsar Suite w miejscu, w którym można w pełni wykorzystać jego możliwości – w zespole odpowiedzialnym za aplikacje i usługi IT – zarówno za rozwój, jak i działania operacyjne. Istotne jest to, że użycie systemu w obu obszarach jest bardzo zbliżone, nie wymaga zmiany stylu i trybu pracy zespole ani dodatkowych szkoleń.

Teoretycznie wnioskowanie i diagnoza we Flopsar są szybkie. Jak szybko i czy w ogóle udało się je przełożyć na optymalizację procesów i produktów IT?

Zastosowanie Flopsar pozwala na znaczne zwiększenie szybkości obsługi incydentów w środowisku produkcyjnym. Czas od powstania anomalii w działającym systemie do podjęcia akcji naprawczej przez zespół jest zredukowany niemal do zera. Dawniej subiektywna informacja użytkownika końcowego o niewydajnie działającym systemie musiała przejść szereg poziomów w organizacji IT. Teraz informacja ta widoczna jest dla specjalisty dokładnie w momencie, w którym użytkownik zaczyna odczuwać spowolnienie pracy systemu. Co prawda, użytkownik nadal zgłasza problemy do service desku, ale ten już wie o nieprawidłowym działaniu systemu i o podjęciu interwencji przez specjalistów. Znacznie skraca się czas niezbędny do rozwiązania incydentu dzięki możliwości odnalezienia problematycznej metody, serwisu czy zapytania w sposób szybki i intuicyjny.

Zoptymalizowane zostały również procesy rozwoju aplikacji i testów. Monitoring aplikacji w środowisku deweloperskim i testowym pozwala na wykrycie operacji, których czas wykonania nie jest akceptowalny.

Dzięki analizie liczby konkretnych wywołań w czasie jesteśmy w stanie zdefiniować wzorce aktywności biznesowej, a w konsekwencji we właściwy sposób realizować zarządzanie pojemnością, wydajnością i popytem usług IT. Właściwość ta pozwala również odpowiednio planować procesy zarządzania zmianą, w tym planowe wyłączenia systemów w celach maintenance.

Czy na podstawie wzorców i statystyk zapytań można pokusić się także o optymalizację innych procesów organizacyjnych, sposobów działania – czy może być źródłem innych innowacji?

Jeśli proces biznesowy realizowany jest w systemie IT, który analizowany jest przez Flopsar, wszystkie operacje wykonywane w systemie są rejestrowane i mogą być analizowane. Charakterystyczna wizualizacja danych pozwala na określenie, jakie czynności w ramach procesu biznesowego wykonywane są nieefektywnie.

Zazwyczaj proces biznesowy, który wykonywany jest w systemie IT, z punktu widzenia użytkownika biznesowego traktowany jest jako operacja mająca w nim swój początek i koniec. W rzeczywistości realizacja procesu obejmuje szereg operacji wychodzących poza ramy aplikacji, dotykając architektury integracyjnej, bazodanowej i innych systemów. W zaawansowanych systemach BPM monitoring aktywności biznesowej (BAM) jest dostępny i może być używany do optymalizacji procesów biznesowych. Jednak w sytuacji, gdy decydujemy się na produkcję własnych aplikacji metodami in-house development, powinniśmy dostarczyć również narzędzie monitoringu procesu biznesowego, który dana aplikacja wspiera. W sytuacji, w której nie decydujemy się na implementowanie tego typu funkcjonalności do produkowanej aplikacji, pomocne może być wnioskowanie na bazie danych, możliwych do uzyskania z systemu Flopsar.

Jak zmieniła się trafność prognoz zapotrzebowania na moc obliczeniową? Czy w ślad za tym udało się zoptymalizować wykorzystanie infrastruktury?

W obszarze optymalizacji infrastruktury pod kątem wydajności aplikacji Generali opiera się na aktywnościach w trzech filarach: monitoringu parametrów technicznych elementów infrastruktury (z wykorzystaniem protokołów SNMP, WMI itp.), optymalizacji równoważenia obciążenia, monitoringu wydajności aplikacji z wykorzystaniem Flopsar Suite.

Pierwszy i drugi filar są znane i stosowane w wielu organizacjach, dopiero badanie współzależności pomiędzy powyższymi trzema daje najlepszy obraz prognozowania mocy obliczeniowej. Jest to możliwe dzięki przełożeniu technicznych parametrów elementów infrastruktury na czas wykonania operacji w monitorowanej aplikacji.

Specyfika przygotowywanych w ostatnim okresie akcji marketingowych Generali wiązała się z tymczasowym kilkukrotnym zwiększeniem operacji w Merkury 2.0 – głównym systemie sprzedażowym wykorzystywanym przez Generali. Początkowo rozważaliśmy liniowe skalowanie elementów infrastruktury serwerowej. Podczas testów rozwiązania z wykorzystaniem Flopsar okazało się, że istnieje wiele innych aspektów, które mogą mieć znaczący wpływ na wydajność i mogą być zmodyfikowane w celu osiągnięcia wzrostu pojemności systemu. Zauważyliśmy, że standardowe techniki równoważenia obciążenia mogą wpływać niekorzystnie na czas przeprowadzenia operacji przez pojedynczego użytkownika. Warunkowanie loadbalancingu na bazie parametrów infrastruktury i systemu pozwoliły nam dostarczyć rozwiązanie, którego wydajność była taka sama dla każdego z użytkowników. Co ciekawe, przeprowadzone testy wykazały, że narzut Flopsar Suite na obciążenie środowisk nie przekracza poziomu 1–2%. Finalnie, po przeprowadzeniu szeregu optymalizacji, doszliśmy do stanu, w którym obsłużenie wzmożonego obciążenia systemu mogliśmy osiągnąć bez modyfikacji infrastruktury serwerowej. Po zakończeniu rzeczonej akcji marketingowej byliśmy w stanie zredukować infrastrukturę.

Jak wyglądała nauka nowego sposobu obserwacji efektywności sprzedaży, zwłaszcza umiejętności interpretacji wizualizacji rozkładów zdarzeń? Czy użytkownicy łatwo odnaleźli sposób  wnioskowania? 

Flopsar Suite jest pakietem intuicyjnym w obsłudze. System używany jest obecnie przez departament IT, ale poważnie rozważamy udostępnienie uzyskanych przez niego danych użytkownikom biznesowym, którzy na tej podstawie będą mogli optymalizować procesy biznesowe.

Trzeba jednak mieć na uwadze fakt, że użytkownicy biznesowi bardzo często wymagają do analizy danych liczbowych, a nie ich prezentacji graficznej. Flopsar, aby mógł być używany do analiz efektywności sprzedaży, warto byłoby wzbogacić o możliwość dostarczenia wyników w postaci liczbowej. Posługując się przykładem: dla departamentów odpowiedzialnych za sprzedaż istotne jest nie tylko to, jak wydajność systemu wpływa na sprzedaż produktów, ale również jak wygląda rozkład operacji wyszukiwania produktów w konkretnych godzinach, dniach miesiąca czy roku.

O nieskomplikowanej obsłudze systemu może świadczyć fakt, że Generali osiągnęło tak zaawansowany poziom wykorzystania narzędzia bez organizacji specjalistycznych szkoleń. Zauważyliśmy też, że kolejne optymalizacje wykorzystania narzędzia mogą być osiągnięte przez nabycie dodatkowej wiedzy z działania pakietu Flopsar zarówno w obszarze analizy, interpretacji wyników, jak też tworzenia rozszerzeń raportowych. Warto wspomnieć, że wszystkie dane gromadzone w bazie Flopsar dostępne są dla naszych programistów przez przeznaczone do tego celu API.

Czy złożoność procesów, czynników, jest ograniczeniem w metodzie wizualizacji wydajności aplikacji zaproponowanej przez Flopsar? Jeśli tak, jak można je obchodzić? 

Najprawdopodobniej każdy, kto zajmował się w swojej pracy optymalizacją wydajności systemów IT, spotkał się z problemem niepewności, czy w interwałach między pomiarami system zachowuje się tak jak w punktach pomiaru. To typowe dla systemów, w których wydajność mierzymy w ustalonych odstępach czasu. We Flopsar analizowana jest każda operacja w systemie. Jeśli nie zdecydowaliśmy się na filtrację konkretnych wywołań w tzw. „galaktyce“, każdy punkt prezentuje jedno z wywołań w systemie. Gdy wykonywane procesy charakteryzują się dużą złożonością, mamy sytuację, w której operujemy na znacznej liczbie geometrycznie skorelowanych punktów. Analiza danych wymaga w tym przypadku weryfikowania konkretnych wywołań spośród znacznie większej ilości wszystkich zmierzonych i zaprezentowanych. To może stanowić ograniczenie ze względu na szybkość analizy danych przez specjalistę. Może również negatywnie wpływać na obciążenie serwera aplikacyjnego pobieraniem danych przez Flopsar. Sytuacja zmienia się jednak w momencie, kiedy zastosujemy techniki wyłączenia konkretnych wywołań, które nie są obiektem naszego zainteresowania. Jest to możliwe z poziomu administracji systemem, co pozwala na przygotowanie monitoringu indywidualnie pod każdą aplikację. Innym sposobem redukcji danych, których nie chcemy analizować, jest możliwość filtracji minimalnych i maksymalnych czasów wykonania operacji w badanym systemie. Finalnie w systemach działających na wielu serwerach aplikacyjnych mamy możliwość zmiany kolorystyki prezentowanych punktów w zależności od serwera. Sądzę, że przydatną funkcjonalnością byłaby możliwość zdefiniowania kolorystyki punktów w inny, wybrany przez użytkownika sposób, np. koloru zależnego od typu wykonywanej operacji w systemie lub czasu jej wykonania.

Szczegółowe kwestie zmian związanych z wdrożeniem rozwiązania APM w Grupie Generali komentuje dla magazynu CIO Michał Zaremba, IT Infrastructure Project Manager w Departamencie Informatyki – Sekcji Wsparcia i Infrastruktury w Grupie Generali.