„Muszę mierzyć SLA!”

Data: 2015-01-12
Autor: Sebastian Konkol
„Muszę mierzyć SLA!”

W odstępach kilku lat dają się zaobserwować fale zainteresowania pomiarami poziomu jakości usług. Skorelowane jest to głównie z nowymi regulacjami prawnymi lub – szerzej – obowiązkami narzucanymi przez organy nadzorcze firm i branż. Takie przedsięwzięcia odnoszą się do zagadnień jakości usług (QoS, Quality of Service), umów o jakości usług (SLA, Service Level Agreement), zarządzania poziomem jakości usług (SLM, Service Level Management) lub podobnych terminów. W cudowny sposób większość z tych inicjatyw udowadnia, że wszystko jest w najlepszym porządku lub wręcz oczekiwania są przekraczane. Czasami okazuje się to być obiektywnie prawdą, lecz – według moich doświadczeń – raczej rzadko. Nikt nie lubi odsłaniać swoich słabości.

Mimo powtarzających się fal zainteresowania, dostrzegam dwa niezmienne powody, dla których inicjatywy serwisowo-jakościowe ponoszą klęskę. Pierwszy powód dotyczy definicji usługi. Jeśli parametry oceny jakości usługi określone są w ściśle techniczny sposób (np. czas odpowiedzi „serwera” usługi), związek takich miar z odbiorem usługi przez jej użytkowników jest – w większości przypadków – co najwyżej luźny. Drugi powód odnosi się do obiektywizmu samej oceny. Im bardziej interpretowalny jest wynik pomiaru, tym więcej „odcieni szarości” może on ukryć. W obu przypadkach raczej niezasadnym jest oczekiwanie, że inicjatywa serwisowo-jakościowa tak określona przyniesie jakąkolwiek wartość biznesową (o innych „wartościach” nie ma co tu wspominać). Ostatecznie, What you pay for is what you get, staje się obłudną rzeczywistością. Zła metryka jest, w najlepszym przypadku, bezużyteczna, jednak w przypadkach skrajnych może po prostu wprowadzać w błąd.

Zaprojektowanie odpowiednich metryk oceny jakości niesie elementy nauki i sztuki. Niemalże nigdy nie udaje się tego zrobić „przy okazji”, na bazie posiadanych już danych. Z jednej strony musi być to osadzone w samej technologii, dając podstawę dla rzetelności i transparentności pomiaru oraz jednoznaczności i obiektywizmu interpretacji. Z drugiej strony, musi być to wyrażane w terminologii mającej znaczenie dla użytkowników. Akt pomiaru nie jest celem – jest nim zdolność podejmowania właściwych działań na podstawie wyniku.

Pracując nad takimi przedsięwzięciami opieram się, co nie powinno zaskakiwać, na podejściu architektonicznym. Jako kanwę dla opracowania rozwiązania pomiaru QoS / SLA przyjmuję architekturę rozwiązania świadczącego określone usługi. Na tej kanwie szkicuję proces realizacji usługi i ustalam miejsca pomiaru parametrów, jakie są istotne z punktu widzenia odbiorców usługi. Następnie określam reguły transformacji i przeliczeń gromadzonych w ten sposób danych, aby uzyskać zarówno zdolność pomiaru jakości usługi, jak i identyfikacji tych elementów „stosu technologii”, które mogą ujawniać symptomy problemów. Praca architektoniczna przebiega więc w następujący sposób:

  1. Identyfikuję i definiuję usługę (w jej znaczeniu biznesowym), która jest na tyle istotna, aby uzasadniać pomiar jej parametrów jakościowych, szczególnie w trybie on-line. W tym celu wykorzystuję (lub „odkrywam”) architekturę biznesową świadczenia takiej usługi.
  2. Określam proces realizacji usługi i komponenty architektury uwikłane w przebieg tego procesu. Tu opieram się na architekturze aplikacji, często zdekomponowanej do dość szczegółowego poziomu modułów aplikacyjnych.
  3. Dla każdego komponentu architektury systemu informacyjnego (aplikacje i dane) identyfikuję sposób ich interakcji z innymi komponentami lub „zewnętrzem” architektury. Dzięki temu oznaczam „ścieżki wykonania” usługi przez „stos technologiczny”, w którym poszczególne punkty interakcji stają się kandydatami do dokonywania pomiarów.
  4. Analizuję „stos technologiczny” (lub, znacznie częściej, „odkrywam jego szczegóły”), aby odnosić się nie tyle do dość abstrakcyjnych pojęć aplikacyjnych, ile do rzeczywistych elementów infrastruktury realizującej usługę. Dla realizacji tego zadania używam architektury technicznej i powiązań komponentów architektury technicznej z architekturą systemu informacyjnego.
  5. Na koniec określam zasady agregacji danych pomiarowych. Osadzam punkty pomiaru w architekturze technicznej, a znaczenie pomiaru odnoszę do procesu realizacji usługi. W ten sposób uzyskuję obiektywne miary wyrażające sposób postrzegania usług przez ich użytkowników.

Prawda, że proste? Tak to wygląda w skrótowym opisie. Jeśli architekci korporacyjni wykonali uprzednio swoją pracę dobrze, takie zadanie staje się miłym przedsięwzięciem, choć intelektualnie stanowi ono zwykle wyzwanie. W przypadkach słabych dokumentacji architektury korporacyjnej (EA, Enterprise Architecture), takie zadanie staje się żmudnym „spisem z natury” i jest trudniejsze – nie jest jednak niewykonalne.

Pomiary mają służyć zdolności do (szybkiego!) określenia powodów zachwiania jakości świadczonej usługi. W przypadku takiego incydentu powinno „dawać się zejść” do poziomu komponentów infrastruktury, jakie wprowadzają zaburzenia do jakości usługi. Służby utrzymania systemów IT nie są zwykle zdolne do sensownego działania bazując na informacji o incydencie – są jednak zdolne do skutecznego eliminowania problemów wyrażonych w kryteriach technicznych. Tak to po prostu już jest. Im bardziej jednoznaczna identyfikacja potencjalnie zawodzącego komponentu technicznego, tym szybciej można uruchomić właściwe procedury techniczne diagnozy i usunięcia problemu. W konstrukcję miar jakości usług i reguł agregacji danych pomiarowych wbudowuję takie mechanizmy. W efekcie wystąpienie incydentu jakościowego niemal zawsze ujawnia miejsce potencjalnego występowania problemu. W ponad 80% przypadków jest to wystarczające dla usunięcia problemu w ramach pierwszej akcji służb utrzymania.

To podstawowy powód, dla którego monitorowanie QoS i SLA uważam za inną stronę utrzymania systemów IT. W tym obszarze konieczne jest utrzymanie równowagi między obserwacją zyliona parametrów technicznych systemów i parametrów jakości realizacji usług biznesowych. Ostatecznie, tylko te ostatnie się liczą – reszta ma służyć ich zapewnieniu. Celem jest dostrzeżenie i usunięcie problemu jakości świadczenia usługi, zanim jej użytkownik dostrzeże ten problem.

W jednym z moich projektów, realizowanym dla dużej firmy działającej na rynku usług medycznych, opisane powyżej podejście pozwoliło na wprowadzenie pomiaru usługi umówienia pacjenta na wizytę lekarską. Usługa ta, jak się okazuje, determinuje postrzeganie firmy medycznej przez jej klientów. Było więc o co walczyć. Ustalenie reguł pomiaru jakości tej usługi przebiegało następująco:

  • Ustaliliśmy usługę biznesową (umówienie wizyty) wraz z procesem jej realizacji. Ustaliliśmy także miary oceny jakości, zarówno on-line (średni i maksymalny czas realizacji) jak i analityczne (trendy), a także uwarunkowania realizacji usługi (dostępność, wolumetria).
  • Ustaliliśmy komponenty architektury uczestniczące w realizacji usługi (identyfikacja pacjenta, profil usług medycznych, dobór specjalisty, grafik usług, rezerwacja wizyty) wraz z punktami interakcji z pacjentem (rejestracja on-line) i obsługą pacjenta (rejestracja telefoniczna).
  • Ustaliliśmy stos technologiczny realizacji ścieżki wykonania usługi i określiliśmy punkty pomiaru istotne w przebiegu procesu (21 takich punktów). Na tej podstawie zdefiniowaliśmy zarówno reguły agregacji danych pomiarowych wskazujące na odstępstwa od zakładanych parametrów jakościowych świadczenia usługi jak i reguły identyfikacji elementów infrastruktury będących potencjalnymi źródłami zawirowań jakościowych.
  • Opracowaliśmy reguły wizualizacji parametrów jakościowych usługi, zarówno w wymiarze zarządczym (dashboard) jak i utrzymaniowym (ścieżka przebiegu realizacji usługi). Wskazaliśmy także procedury utrzymaniowe, jakie powinny być wykonane w przypadku identyfikacji określonej klasy problemów utrzymaniowych. Na tej podstawie możliwy był zarówno bieżący monitoring jakości usługi jak i inicjowanie działań naprawczych.

W efekcie tej pracy udało się nie tylko zapewnić zdolność organizacji IT do wcześniejszego wykrywania incydentów jakościowych najbardziej widocznej dla pacjentów usługi, ale udało się ustalić mechanizmy wczesnego wykrywania narastającego pogarszania jakości obsługi pacjenta (w godzinach szczytu, w sezonach chorobowych), jakie były wykorzystywane przez obsługę pacjenta dla optymalizacji obsady stanowisk obsługi.

Całość zagadnienia monitorowania jakości usług i zarządzania nią niemalże zawsze angażuje dwie strony zagadnienia – ludzi i technologię. Wymaga więc analizy zagadnienia z szerokiej perspektywy. To właśnie jest naturalnym dla EA środowiskiem działania. Architektura korporacyjna jest skuteczną i bardzo wdzięczną kanwą identyfikacji symptomów i powodów problemów jakości usług – nie tylko w sferze systemów informatycznych, także ludzi i procesów. Zapewnia przy tym spójność i skuteczność podejmowanych działań. Co jednak najważniejsze, tworzy środowisko prac nad jakością usług, które pozwala na skupienie się na zagadnieniach merytorycznych, łagodząc lub eliminując efekt obawy przed obwinianiem za takie problemy.

Pozostaw komentarz