„Nie daj się zaskakiwać awariom!”

Data: 2014-12-15
Autor: Sebastian Konkol
„Nie daj się zaskakiwać awariom!”

Poziom złożoności charakteryzujący współczesne systemy ICT czyni je coraz mniej deterministycznymi, a coraz bardziej stochastycznymi. W coraz większej liczbie „okoliczności” ostateczne zachowanie systemów raczej „wyłania się” (jak w teorii złożonych systemów adaptacyjnych, Complex Adaptive Systems), niż jest projektowane lub programowane. Próby przewidzenia zachowania systemów to dzisiaj działalność profesji przepowiadaniu pogody, niż inżynierii systemowej. Możemy zakładać stabilność i determinizm działania systemów co najwyżej do pewnego stopnia, oceniając go probabilistycznie. Zaskoczenia i niespodzianki są nieuniknione. Kropka.

Głosząc takie tezy często spotykam się z sarkastycznymi odpowiedziami, „No to poczekajmy, aż się wywróci!”. Czysto teoretycznie, jest to jedna ze znanych taktyk zarządzania ryzykiem – akceptacja. Jednak jestem daleki od proponowania takich rozwiązań. Między „robieniem nic” a „utopią” (wiarą w zdolność do perfekcyjnego zaplanowania wszystkiego) jest całkiem spory wachlarz innych możliwości. Wiele z nich (jeśli nie wszystkie) może być zidentyfikowanych dzięki architektonicznemu podejściu do zagadnienia. Skoro nie można przewidzieć problemu, trzeba umieć obserwować symptomy i podejmować adekwatne akcje w przypadku występowania niebezpiecznych symptomów.

Takie terminy jak OSS (Operational Support Systems), O&M (Operations and Maintenance), nadzór (Systems Monitoring), czy autodiagnostyka (Self-diagnosis) i wiele pokrewnych mają swoje miejsce w świecie IT, choć zakorzenione są w świecie telekomunikacji, gdzie złożoność współpracujących systemów sięgnęła poziomu stochastycznego już dziesięciolecia temu. Niestety, w większości przypadków świata systemów IT, rozwiązania takie są nisko wartościowane, a ich stosowanie jest traktowane jako dodatek zamiast obowiązkowo. Wiele, wiele razy doradzałem w sytuacjach, w których nadzór kluczowych biznesowo systemów IT ograniczał się wyłącznie do podstawowych zagadnień utylizacji zasobów (przestrzeń danych, wykorzystanie procesora, transfer sieciowy). Żadna z tych „miar” nie ma wartości dla opisu stanu usługi, jaką dany system świadczy, a im więcej wirtualizacji w rozwiązaniach IT, tym nawet techniczny związek z usługą jest bardziej iluzoryczny. Specjaliści IT są nadal uprawnieni do budowy ogromnej różnorodności systemów, interfejsów, protokołów – ogólnie mówiąc technologii – bez zapewnienia jej interoperacyjności. Istniejący już „bałagan” powiększa jedynie swoją skalę. Czy to sytuacja patowa? Zdecydowanie nie, a z pomocą przychodzi właśnie architektura korporacyjna (EA, Enterprise Architecture).

Jak wiadomo, skuteczność nadzoru systemów opiera się na posiadaniu „wbudowanych” w konstrukcję systemów kilku podstawowych zdolności:

  • analiza zdarzeń w czasie „rzeczywistym” – zdolność obserwacji zachowania systemów oraz identyfikacji zdarzeń, które mogą być symptomami nadchodzących problemów;
  • topologia systemów – posiadanie aktualnego opisu struktury systemów i ich komponentów oraz powiązań między nimi i usługami przez te systemy świadczonymi;
  • wzbogacanie informacji – zdolność zautomatyzowanego wykonywania prostych czynności (filtrowanie, korelacja, zbieranie dodatkowych informacji);
  • wizualizacja – możliwość prezentacji wzbogaconej informacji o stanie systemów na kanwie ich topologii;
  • integracja procesowa – zdolność do automatycznego inicjowania procesów obsługi określonych problemów.

Gdzie znajduje się EA w tym zestawieniu? Wszędzie! Istnieją dobrze udokumentowane wzorce architektoniczne określające reguły budowania systemów, które mają posiadać zdolność raportowania swego stanu w czasie „rzeczywistym”. Istnieją wzorce architektoniczne i rozwiązania realizujące bardzo złożone algorytmy wzbogacania informacji o stanie systemu. Powszechnie znane są wzorce integracji nadzoru systemów z narzędziami klasy Workflow and Workforce Management. Istnieje wiele rozwiązań – zarówno komercyjnych, jak i Open Source – pozwalających na wizualizację nadzoru systemów. Najważniejsze jednak – topologia systemów – to EA w swej najczystszej postaci: architektura techniczna zapewniająca możliwości działania architektury logicznej realizującej cele architektury biznesowej. Naturalnie, im lepszy opis topologii, tym precyzyjniejszy i skuteczniejszy nadzór systemów.

Wiele można także napisać o pętlach sprzężenia zwrotnego zapewniających zdolność samo-uczenia się nadzoru systemów i samodoskonalenia procesów obsługi. Ulokowane są one zarówno w każdym z obszarów powyżej wymienionych. W efekcie, poprawnie zdrożone mechanizmy – rozwiązania, procesy i modele kompetencyjne – zapewniają nie tylko skrócenie czasu obsługi pojawiających się problemów. Zapewniają zdolność do identyfikacji tych problemów, którymi trzeba zająć się w pierwszej kolejności. Wbudowują zdolność do adaptacji w sytuacjach nowych rozwiązań podlegających monitoringowi, czy nowych warunków, w jakich pracują posiadane już systemy. Uwrażliwiają na określone sytuacje już na etapie budowy systemów.

Złożoność rozwiązań ICT będzie rosła, a tempo wzrostu także będzie przyspieszać. Jakiekolwiek „ustępstwa” w dziedzinie zdolności do nadzoru systemów sprawiają, że – już dziś defensywna – postawa nadzoru systemów IT sprowadzać się będzie do podejmowania coraz bardziej chaotycznych akcji, z coraz większym opóźnieniem. Oś czasu biznesu, czyli powód dla posiadania rozwiązań IT, jest jednak coraz „gęstsza”. W konsekwencji ta sama awaria dzisiaj kosztuje firmę więcej, niż 5 lat temu. Czy naprawdę można sobie na to pozwolić?

Pozostaw komentarz