Szkolenia powiązane z tematem artykułu
Kryzys i branża IT
Panująca obecnie pandemia wirusa COVID-19 i związana z nią społeczna izolacja przetestują jak żaden inny scenariusz plany ciągłości, skuteczność sztabów i zespołów kryzysowych i ogólne przygotowanie liczonej w tysiącach pracowników branży IT w Polsce.
Wprawdzie za późno na wprowadzanie doraźnych rozwiązań, które ułatwiłyby tę kryzysową sytuację, ale warto rzucić okiem na częste błędy i pomyłki w obszarach ryzyka, ciągłości i odporności organizacji ITSM, zapewniając – czego wszystkim życzę – większą responsywność w przyszłych kryzysach.
To nie nadmierny pesymizm ze strony autora. Kryzysy, być może nie tak kompletne jak pandemia, będą zdarzać się wciąż. Świadczenie usług (w tym informatycznych) jest działaniem ustawicznym i byłoby zwyczajnie nieodpowiedzialnym liczyć, że przestaną je zaburzać epidemie, globalne wydarzenia, wahania rynków czy katastrofy naturalne. W celu zmniejszenia impaktu tych plag na biznes, stosuje się szeregi metod z zakresu zarządzania ryzykiem czy ciągłością. Do absolutnych podstaw należą dwa komplementujące się dokumenty, które powinny być bliskie każdemu pracownikowi branży IT – ITCP, czyli Plan Ciągłości Informatycznej (IT Continuity Plan) oraz DRP, czyli Plan Odtworzenia Pokryzysowego (Disaster Recovery Plan).
Oba wspomagają w trudnej chwili, ale też oba stosuje się inaczej. O ile ITCP planuje rozwiązania, które zapewnią ciągłość usłudze informatycznej, DRP listuje metody naprawy, powrotu do normalności, tak lubianego przez nas BaU, Business as Usual. Kiedy dostawca usług stwierdza, że jakieś zdarzenie ma niekorzystny, czy też krytyczny wpływ na świadczenie, sięga w pierwszej kolejności po ITCP. Znajduje tam rzeczone zdarzenie, które z mniejszym lub większym prawdopodobieństwem przewidzieli zarządzający ryzykiem, i stosuje zapisane tam metody alternatywnego świadczenia usług.
Takie zastępcze metody czasami zupełnie odbiegają od tego, do czego jesteśmy przyzwyczajeni – pracując w środowisku Service Desk korzystałem, na przykład, z możliwości zostawienia przez użytkownika wiadomości głosowej w celu zarejestrowania zgłoszenia, jako alternatywy dla rozmowy z agentem, gdy biuro w którym pracowaliśmy traciło połączenie z Internetem lub siecią telefoniczną. Po odzyskaniu łączności, wszystkie wiadomości były skrupulatnie oddzwaniane i obsługiwane. Choć brzmi to jak lekkie oszustwo, należy pamiętać, że czym innym jest „dostępność” usługi, która ma bardzo obiektywny charakter i prostą definicję – albo da się z niej korzystać, albo nie – od pojęcia „ciągłości”, które znaczy w prostym języku nie więcej niż: wprawdzie dostępności brak, ale alternatywne metody dają obejście kryzysu i rudymentarne funkcjonalności. Negocjując z klientem warunki świadczenia usługi, a w tym słynne parametry SLA, uwzględnialiśmy dostępność odbiegającą znacznie od 100%, ale zarazem oferowaliśmy realistyczne, alternatywne metody zapewnienia ciągłości. Ceniący realizm i przygotowanie klienci byli na taki kompromis przygotowani.
Rożnice między ITCP (Plan Ciągłości) i DRP (Plan Odtworzenia Pokryzysowego)
Jako doradca i konsultant notorycznie napotykam sytuację, w której dostawcy usług skarżą się na klientów z nierealistycznie wysokimi oczekiwaniami w obszarze dostępności usługi. Powtarzam w takich okolicznościach sugestie o rozdzieleniu pojęcia „dostępności” od „ciągłości”. I chociaż zdobycze techniki przyzwyczaiły nas współcześnie do imponujących wartości „dostępności”, dobrze zaplanowana „ciągłość” wciąż jest tym, co oddziela dojrzałe IT od hurraoptymizmu. W moim doświadczeniu klient realistycznie poinformowany o możliwości utraty dostępności i związanych z tym ryzykiem punktach ITCP, jest skłonniejszy do kompromisu.
Z kolei DRP, czyli Plan Odtworzenia Pokryzysowego, powinien wejść w światła reflektorów w drugiej kolejności. Jest to dokument listujący metody i techniki naprawy sytuacji, powrotu do normalności. Jego zaawansowane wersje przyjmują często formę swoistej bazy solucji, z której korzystać mogą zarówno sztaby kryzysowe jak i praktycy procesu zarządzania incydentem. Poprawne DRP jest bowiem znacznie obszerniejsze niż ITCP i stanowi skarb doświadczonej organizacji IT. O ile ITCP listuje krótkie i szybkie scenariusze zapewnienia rudymentarnej obsługi, poszczególne punkty DRP mogą zgoła przypominać kompletne plany projektów; mogą nawet być planami projektów! Naprawa pokryzysowa jest bowiem kosztowną i precyzyjną pracą, podczas gdy rozwiązaniom z zakresu ciągłości pozwolić można na dozę tymczasowości i improwizacji.
Powrót do Business as Usual
Powrót do BaU może okazać się w praktyce wyzwaniem dla organizacji. Kiedy opada kurz i pył po wystąpieniu ryzyka, okazuje się nagle, że o ile uruchomić alternatywne rozwiązania się dało, na mozolny powrót do normalności nie ma środków, czasu lub – co najgorsze – pomysłu. Organizacji zajmującej się szeroko rozumianym procesowaniem danych, której miałem przyjemność pomagać, zdarzył się taki wypadek, kiedy w wyniku wystąpienia katastrofy naturalnej, która wręcz zniszczyła lwią część ich infrastruktury informatycznej, stracili możliwość wprowadzania nowych danych i rejestrowania transakcji tradycyjnymi metodami. Co ciekawe, dane historyczne były szeroko dostępne – praktyka przechowywania kopii zestawień i raportów w wersji papierowej była wpisana w ITCP i nie zostawiła organizacji z niczym. W przypadku utraty możliwości wprowadzania danych, istniała alternatywa wpisana w ten sam ITCP – należało rejestrować transakcje na wcześniej przygotowanej formatce w Excelu. Niestety, o ile nie utracono możliwości referowania do danych historycznych, o ile rejestrowanie nowych danych, choć utrudnione, było możliwe, nie było w DRP pomysłu na późniejsze wprowadzenie backlogu do odzyskanego systemu informatycznego. Gdyby ten backlog liczył efekt dwóch lub trzech dni pracy, byłby to opanowania. Niestety, pełną dostępność infrastruktura informatyczna odzyskała w tym wypadku dopiero… po dwóch tygodniach. Natłok danych zgromadzonych w tymczasowych „formatkach” był ogromny i tylko niezwykle kosztownym wysiłkiem, liczonym w nadgodzinach i popularnym zjawisku „crunchu”, udało się wreszcie zintegrować dane. Przez wiele miesięcy specjaliści data processing musieli pracować na fragmentarycznych danych i łączyć wiele źródeł w finansową układankę dla zaawansowanych.
Dobry Plan Odtworzenia Pokryzysowego jest na miarę złota dla nowoczesnej organizacji informatycznej. Oszczędza środki i prostuje drogi do normalności, ale powstaje w bólach. To ostatnie zresztą, dotyczy obu tych dokumentów. Często bowiem teoretyczne metody zapewnienia ciągłości i odtworzenia można przetestować jedynie w przypadku faktycznego wystąpienia ryzyka, kiedy już na korekty za późno. Ćwiczenia, które dają jako takie pojęcie o skuteczności zgromadzonych rozwiązań, są – po pierwsze – kosztowne, a – po drugie – należą do wydarzeń rozpraszających skuteczność i efektywność usług praktycznie w tym samym stopniu, co same katastrofy.
W dodatku, różniące się skalą katastrofy i kryzysy mogą szybko usunąć grunt spod nóg nawet najbardziej przygotowanym. Popularnym w dużych, międzynarodowych organizacjach sposobem zapewniania ciągłości jest umożliwianie zespołowi z jednego zakątka globu wykonywania pracy innego, w tym momencie dotkniętego kryzysem zespołu. Data processing, Service Desk i wiele innych typów wysoko powtarzalnej pracy mają zwykle takie właśnie metody mitygowania ryzyka katastrofy. Mając podobne zespoły w dwóch oddalonych od siebie krajach, można przecież zapewnić popularny cross-training i uzyskać niezwykle elastyczną ciągłość. Niestety, w przeciwieństwie do biznesu, natura ma możliwość podnoszenia stawki zakładu wysoko poza nasz kredyt – nawet takie metody zawiodą w obliczu globalnej pandemii.
I to właśnie, co dzieje się na naszych oczach, powinno postawić nasze wszelkie wysiłki w stosownej perspektywie: nawet najlepsze ITCP i DRP nie zaradzą w każdej sytuacji. W formalnych kontraktach jest wciąż miejsce na enigmatycznie brzmiącą dla laika vis maior, „siłę wyższą”, i tak samo, w najlepszym ITCP i DRP kończy się czasem skala. Komponując te dokumenty nie należy liczyć na iście globalną wszechstronność, ale warto pamiętać o kilku złotych zasadach.
Złote zasady dla ITCP i DRP
Odpowiedzialność pisze się przez duże “A”
To nie chochlik drukarski, to tylko taki zabieg przypominający o roli literki „A” w modelu RACI. Model ten uczy nas różnicy między „wykonywaniem czynności” (R), a byciem za nią w pełni odpowiedzialnym (A). Wprawdzie w polskojęzycznych wersjach metody RACI czytamy, że R (Responsible) to właśnie „odpowiedzialny”, a A (Accountable) to „nadzorujący”, lecz nie o niuanse tłumaczeń tu chodzi, a o prawdziwą przynależność do roli. Każdy punkt z ITCP i DRP, każde działanie, każdy system, każda redundancja musi mieć swojego właściciela, osobę lub rolę prawdziwie accountable. Działanie może być wykonywane przez wielu (responsible), ale to jego właściciel dba o nie w pełnym wymiarze słowa „odpowiedzialność”.
Od zabawek ważniejsza jest…wyobraźnia
Nie tylko w organizowaniu czasu milusińskim, ale również w zarządzaniu ryzykiem i ciągłością największe procenty wypłaca wyobraźnia i zdolność uogólniania doświadczeń. Skuteczny manager ds. ryzyka to człowiek obdarzony iście holistyczną perspektywą. Zdolność do zrozumienia konsekwencji podjętych (lub wstrzymanych) działań jest kluczowa i nie bez znaczenia jest też uważność na szczegóły. Plan ewakuacji, który rozważono pod kątem nie tylko architektonicznej drożności budynku, lecz także pod kątem typowych ludzkich zachowań lub przeszkód, które dynamicznie mogą pojawić się w zagrożonym budynku, przetrwa próbę generalną znacznie lepiej. Plan, który uwzględnia typowo ludzki upór, ciekawość lub skłonność do eksperymentu i błędu, będzie po prostu lepszy, sprawniejszy. Tam, gdzie wyobraźnia nie dotrze, pomoże doświadczenie i umiejętność wyciągania wniosków. Co ważne – nie ograniczona tylko do własnych przeżyć.
Padłeś? Powstań!… A Teraz powstań!
Najlepsze plany ciągłości, najlepsze rozwiązania przeciw materializacji ryzyka, powstają w ogniu licznych prób, testów i… prawdziwych wystąpień. Użycie ITCP i DRP koniecznie musi prowadzić do przeglądu, wyciągania wniosków i doskonalenia. Postawy typu „Jakoś poszło…”, „Ważne, że nikt nie zginął…” i podobne, są w obliczu przyszłych wystąpień nieakceptowalną pobłażliwością. Nawet wzorcowe przekierowanie usługi na zapasowe łącza, ewakuacja rekordowa pod względem czasu i dyscypliny, znakomity transfer odpowiedzialności pomiędzy komórkami organizacji, powinny być potraktowane krytycznym okiem i stanowić pretekst do dalszej pracy, pretekst do poprawy. Pracownicy zachodnich firm podśmiechują się troszkę, gdy na szkoleniach z LeanIT, Lean Services czy Lean Manufacturing mówię otwarcie o roli perfekcji w organizacji. Perfekcja, w oczach zachodniego specjalisty to nieosiągalny ideał. Paradoksalnie, nasi azjatyccy przyjaciele zgadzają się z tym. Różni nas jedynie fakt, że oni są skłonni w, z definicji nieskończoną, drogę ku perfekcji się wybrać, podczas gdy my sięgamy po bardziej namacalne motywacje. Dla managera ciągłości to jednak azjatycki wzorzec powinien być w mocy – perfekcji nie osiągniemy, ale każdy krok na drodze do niej to oszczędzone pieniądze, uratowane życia i utrzymana rynkowa pozycja i reputacja.
Dzisiejsza sytuacja wymyka się wszelkim estymacjom. Zaraźliwość wirusa, na którą tak podatne są systemy wentylacyjne w przepastnych biurowcach, nierychła perspektywa znalezienia skutecznego leku lub skutecznej prewencji, i wreszcie prawdopodobny kryzys służby zdrowia to – wbrew optymizmowi – dopiero początek kryzysu. Niechybnie biznes usługowy czekają teraz trudne miesiące odbudowywania relacji z klientami, kontraktów, a czasami nawet gruntowne restrukturyzacje. Te ostatnie, bez wątpienia, dotkną mojej branży, czyli doradztwa i szkoleń. Zapewne ujrzymy wzrost znaczenia internetowych kanałów komunikacji w konsultingu i nauce. Oprócz przetrwania tu i teraz powinniśmy zatem myśleć o uodpornieniu się przeciw nawet mniejszym zagrożeniom w przyszłości. Naszą tolerancję na katastrofy COVID-19 skonsumuje praktycznie w pełni, zatem dbajmy, by mniej dramatyczne „choroby” nie dokończyły dzieła zniszczenia w biznesie usług informatycznych.
Szymon Urbanowicz
