Planowanie ciągłości działania najczęściej zawodzi nie w trakcie kryzysu, ale w trakcie poprzedzającej go oceny. Organizacje przeprowadzają analizy wpływu na biznes, dokumentują cele czasu odzyskiwania, tworzą kompleksowe podręczniki odzyskiwania, a następnie, w najgorszym możliwym momencie, odkrywają, że pozornie niekrytyczna, starsza usługa uwierzytelniania jest pojedynczym punktem awarii dla całej platformy e-commerce, że program wsadowy COBOL, który wszyscy uważali za niskopriorytetowy, zasila usługę walidacji płatności w czasie rzeczywistym lub że dwie aplikacje przypisane do tego samego poziomu odzyskiwania mają nieudokumentowaną zależność, która uniemożliwia sekwencyjne odzyskiwanie. Ocena została przeprowadzona. Zależności nie.
Ocena krytyczności aplikacji to proces przypisywania każdej aplikacji w portfolio organizacji ilościowej lub wielopoziomowej miary ważności, która określa jej priorytet odzyskiwania, poziom inwestycji w redundancję, wymagania dotyczące kontroli zmian oraz jej pozycję w sekwencjonowaniu odzyskiwania po awarii. Ocena oparta wyłącznie na ankietach dotyczących wpływu na biznes i wywiadach z właścicielami aplikacji odzwierciedla to, co ludzie sądzą o działaniu aplikacji. Oparta na analizie strukturalnej tego, co aplikacje faktycznie robią, kto do kogo dzwoni, jakie dane przepływają przez które programy, które współdzielone komponenty znajdują się na ścieżce krytycznej wielu systemów o wyższym priorytecie, odzwierciedla rzeczywistość operacyjną.
Rozdźwięk między wiarą a rzeczywistością to punkt, w którym plany ciągłości działania przedsiębiorstwa zawodzą.
Sekwencje odzyskiwania odzwierciedlające rzeczywiste zależności
SMART TS XL identyfikuje każdy program na ścieżce krytycznej Twoich aplikacji Tier 1 — w każdym języku w Twoim portfolio.
DOWIEDZ SIĘ WIĘCEJ…Co tak naprawdę mierzy ocena krytyczności aplikacji
Krytyczność nie jest jednowymiarowa. Aby określić wynik krytyczności aplikacji korporacyjnej, można wziąć pod uwagę opinie użytkowników, aby ocenić krytyczność lub wagę aplikacji korporacyjnej, w tym największy wpływ na strategiczne potrzeby biznesowe, wpływ na partnerów biznesowych, interakcje z klientami i wpływ na inne aplikacje korporacyjne. Każdy z tych wymiarów odzwierciedla inny aspekt znaczenia słowa „krytyczny”:
Wpływ na biznes , czyli ile organizacja traci w każdej godzinie przestoju. Utrata przychodów to najbardziej widoczny aspekt: system przetwarzania płatności, który obsługuje 10 milionów dolarów na godzinę, generuje wymierny koszt każdej minuty przestoju. Jednak wpływ na biznes wykracza poza przychody, obejmując ryzyko regulacyjne (jakie obowiązki związane z przestrzeganiem przepisów powoduje awaria?), szkody wizerunkowe (czy klienci są bezpośrednio dotknięci?) oraz kary umowne (czy umowy SLA powodują klauzule karne?).
Zależność operacyjna – ile innych systemów lub procesów zależy od tej aplikacji. Aplikacja o niskim bezpośrednim wpływie na biznes może mieć wysoki poziom krytyczności, ponieważ znajduje się na ścieżce zależności aplikacji o wysokim bezpośrednim wpływie. Usługa uwierzytelniania, która umożliwia działanie każdej innej aplikacji skierowanej do klienta, jest bardziej krytyczna, niż sugeruje jej własna funkcja.
Złożoność odzyskiwania – stopień trudności i czasochłonności przywracania aplikacji. Aplikacja o umiarkowanym wpływie na działalność firmy i 48-godzinnym czasie odzyskiwania może wymagać większych nakładów na redundancję niż aplikacja o większym wpływie na działalność firmy i 2-godzinnym czasie odzyskiwania, ponieważ całkowite ryzyko przestoju jest większe.
Obowiązek regulacyjny , który dotyczy aplikacji podlegających wymogom ciągłości regulacyjnej. Instytucje finansowe podlegające ustawie DORA muszą wykazać, że krytyczne lub istotne funkcje są w stanie wytrzymać określone scenariusze zakłóceń. Organizacje opieki zdrowotnej podlegające ustawie HIPAA muszą chronić dostępność systemów zawierających chronione informacje medyczne. Wymiar regulacyjny może mieć pierwszeństwo przed oceną wpływu na działalność biznesową w przypadku określonych aplikacji.
Wynik krytyczności jest wypadkową wszystkich czterech wymiarów, ważonych na podstawie konkretnej tolerancji ryzyka organizacji, otoczenia regulacyjnego i modelu biznesowego.
Standardowe poziomy krytyczności
Większość portfeli aplikacji korporacyjnych wykorzystuje czteropoziomowy model krytyczności. Kategorie krytyczności w macierzy krytyczności aplikacji to: misja krytyczna, biznes krytyczny, działalność operacyjna i administracja. Poniższe definicje odzwierciedlają aktualną praktykę branżową zgodną z normą ISO 22301 (Systemy zarządzania ciągłością działania) oraz Wytycznymi Dobrych Praktyk Instytutu Ciągłości Działania:
Poziom 1, aplikacje o znaczeniu krytycznym , których awaria natychmiast wstrzymuje podstawowe operacje biznesowe lub stwarza niedopuszczalne ryzyko regulacyjne lub bezpieczeństwa. Cel czasu odzyskiwania (RTO): zazwyczaj 0–4 godziny. Cel punktu odzyskiwania (RPO): zazwyczaj 0–1 godzina. Przykłady: przetwarzanie transakcji w bankowości centralnej, systemy handlu w czasie rzeczywistym, systemy dyspozytorskie, interfejsy sterowania przemysłowego, systemy autoryzacji płatności. Aplikacje te uzasadniają największe inwestycje w infrastrukturę: redundancja typu „aktywny-aktywny”, replikacja bez RPO, automatyczne przełączanie awaryjne i najbardziej rygorystyczna kontrola zmian.
Poziom 2, aplikacje o znaczeniu krytycznym dla biznesu, których awaria znacząco utrudnia działalność biznesową, ale nie powoduje jej natychmiastowego zatrzymania. Docelowy czas odzyskiwania: zazwyczaj 4–24 godziny. Docelowy punkt odzyskiwania: zazwyczaj 1–4 godziny. Przykłady: systemy CRM, moduły ERP, zarządzanie zamówieniami, systemy HR w okresach rozliczeniowych, systemy raportowania w okresach składania wniosków regulacyjnych. Aplikacje te uzasadniają infrastrukturę o wysokiej dostępności, regularne testowanie przełączania awaryjnego oraz priorytetową sekwencję odzyskiwania.
Poziom 3, Aplikacje operacyjne biznesowe , które wspierają działalność biznesową, ale których tymczasową niedostępność można obejść za pomocą ręcznych obejść. Docelowy czas odzyskiwania: zazwyczaj 24–72 godziny. Docelowy punkt odzyskiwania: zazwyczaj 4–24 godziny. Przykłady: wewnętrzne narzędzia do współpracy, raportowanie niedostępne dla klientów, portale administracyjne, platformy szkoleniowe. Standardowe procedury tworzenia kopii zapasowych i odzyskiwania są odpowiednie.
Poziom 4, aplikacje administracyjne obsługujące funkcje administracyjne bez bezpośredniego wpływu na działanie. Docelowy czas odzyskiwania: zazwyczaj ponad 72 godziny. Docelowy punkt odzyskiwania: ponad 24 godziny lub ostatnia kopia zapasowa. Przykłady: wewnętrzne wiki z dokumentacją, nieistotne narzędzia programistyczne, raportowanie historyczne. Przywracanie z kopii zapasowej w zależności od potrzeb.
Przypisanie poziomu nie jest stałe. Aplikacja, która przez większość roku jest na poziomie 3, może stać się poziomem 2 podczas zamknięcia miesiąca, okresów sprawozdawczych lub szczytów sezonu handlowego. Krytyczność dynamiczna, w której przypisanie poziomu zmienia się w zależności od kalendarza operacyjnego, to udoskonalenie wdrażane przez organizacje z dojrzałymi programami BCP po ustaleniu bazowej struktury poziomów.
Metodologia punktacji: Przekładanie wymiarów na liczby
Ustrukturyzowana metodologia punktacji przekształca cztery wymiary krytyczności w wynik liczbowy, który obiektywnie, a nie na podstawie polityki organizacyjnej, wyznacza poziom przydziału. Poniższe podejście generuje wynik łączony w skali 0–100, wykorzystując kryteria ważone:
Wymiar 1: Wpływ na biznes (waga: 35%)
| Wpływ na przychody na godzinę przestoju | Wynik |
|---|---|
| > 1 mln dolarów za godzinę | 35 |
| 100 tys.–1 mln dolarów za godzinę | 28 |
| 10–100 tys. dolarów za godzinę | 21 |
| 1–10 tys. dolarów za godzinę | 14 |
| < 1 tys. dolarów za godzinę | 7 |
| Brak bezpośredniego wpływu na przychody | 0 |
Wpływ regulacji (obowiązki zgodności z DORA, HIPAA, PCI-DSS, SOX wywołane awarią) dodaje 10 dodatkowych punktów do tego wymiaru.
Wymiar 2: Zależność operacyjna (waga: 30%)
| Fan-In: Zastosowania zależne od tego zastosowania | Wynik |
|---|---|
| > 20 zależnych aplikacji | 30 |
| 10-20 zależne aplikacje | 24 |
| 5-9 zależne aplikacje | 18 |
| 2-4 zależne aplikacje | 12 |
| 1 zależna aplikacja | 6 |
| Brak osób na utrzymaniu (samodzielnie) | 0 |
Liczba wejść fan-in to w tym przypadku liczba zależności strukturalnych, czyli liczba aplikacji wywołujących tę aplikację, odczytujących jej dane wyjściowe lub zależnych od jej danych, a nie liczba użytkowników ani postrzegane znaczenie. Ten wymiar jest najczęściej błędnie obliczany w ankietach, ponieważ właściciele aplikacji nie znają wszystkich swoich odbiorców końcowych.
Wymiar 3: Złożoność odzyskiwania (waga: 20%)
| Szacowany czas odzyskiwania bez wstępnie utworzonego odzyskiwania po awarii | Wynik |
|---|---|
| > 72 godzin | 20 |
| 24-72 godzin | 16 |
| 8-24 godzin | 12 |
| 2-8 godzin | 8 |
| <2 godz | 4 |
| Automatyczne przełączanie awaryjne < 15 minut | 0 |
Wymiar 4: Wrażliwość danych i obowiązek regulacyjny (waga: 15%)
| Klasyfikacja danych i wymagania regulacyjne | Wynik |
|---|---|
| Regulowane informacje PII / PHI / CHD z wyraźnym zobowiązaniem dotyczącym czasu odzyskania | 15 |
| Dane regulowane bez określonego obowiązku czasu odzyskiwania | 12 |
| Wrażliwe dane wewnętrzne (tajemnice handlowe, dokumentacja finansowa) | 9 |
| Wewnętrzne dane operacyjne | 6 |
| Dane wewnętrzne niebędące danymi poufnymi | 3 |
| Brak zapisanych danych | 0 |
Mapowanie wyniku łącznego na poziomie:
| Wynik kompozytowy | Przypisanie poziomu |
|---|---|
| 75-100 | Poziom 1, misja krytyczna |
| 50-74 | Poziom 2, Krytyczny dla biznesu |
| 25-49 | Poziom 3, Operacje biznesowe |
| 0-24 | Poziom 4, Administracyjny |
Problem zależności: dlaczego punktacja oparta na ankietach jest błędna
Wymiar zależności operacyjnej jest tym, który jest najbardziej podatny na błędne oszacowanie i ma największe konsekwencje, jeśli jest błędny. Pozornie niekrytyczna, starsza usługa uwierzytelniania może być pojedynczym punktem awarii dla całej platformy e-commerce, a jej awaria może zatrzymać wszystkie transakcje generujące przychody. Ten proces wykracza poza abstrakcyjne zagrożenia, obejmując konkretne, mierzalne skutki dla umów o poziomie usług (SLA).
Właściciele aplikacji znają swoje bezpośrednie zależności nadrzędne, systemy, które wywołują. Rzadko znają swoje pełne zależności podrzędne, systemy, które je wywołują. Wewnętrzna usługa uwierzytelniania użytkowników może być uznana przez jej właściciela za mało krytyczną (nie generuje przychodów, jest prosta i rzadko ulega awariom), podczas gdy od niej zależy dwanaście aplikacji skierowanych do klientów, wszystkie z poziomu 1. Rzeczywista krytyczność usługi uwierzytelniania to poziom 1, nie ze względu na jej własną funkcję, ale ze względu na jej pozycję w grafie zależności systemów wyższego poziomu.
Ocena krytyczności oparta na ankietach systematycznie generuje ten błąd. Ankieta dla właścicieli aplikacji pyta: „Jak krytyczna jest ta aplikacja?”. Właściciel usługi uwierzytelniania odpowiada „od niskiej do średniej” na podstawie funkcji samej usługi. Dwunastu zależnych właścicieli aplikacji nie odpowiada na tę ankietę dotyczącą usługi uwierzytelniania, lecz na temat swoich własnych aplikacji. Relacja zależności nigdy nie jest rejestrowana.
Konsekwencja pojawia się w sekwencjonowaniu odzyskiwania: BCP definiuje kolejność odzyskiwania na podstawie wyników krytyczności uzyskanych z ankiety, a usługa uwierzytelniania jest planowana do odzyskiwania poziomu 3. Podczas rzeczywistego incydentu aplikacje poziomu 1, które powinny odzyskać dane jako pierwsze, nie mogą tego zrobić, ponieważ usługa uwierzytelniania, od której zależą, nie została przywrócona. Sekwencja odzyskiwania kończy się niepowodzeniem w punkcie najbardziej krytycznej zależności.
Trzy typy zależności, które stale pomijane są w badaniach:
Ukryte współdzielone komponenty. Wewnętrzny program COBOL, który obsługuje konwersję walut dla trzech oddzielnych procesów biznesowych, z których żaden nie został zidentyfikowany w ankiecie jako współdzielący komponent, stanowi ukrytą zależność, która wpływa na odzyskiwanie wszystkich trzech. Jeśli program konwersji walut jest w warstwie 3, a którykolwiek z trzech procesów biznesowych jest w warstwie 1, efektywna krytyczność programu konwersji walut wynosi poziom 1.
Zależności w potokach danych. Aplikacje pobierające dane przetwarzane wsadowo z innych aplikacji mają zależność czasową, a nie w czasie rzeczywistym. Ryzyko nie polega na jednoczesnej awarii, ale na sekwencyjnej: aplikacja podrzędna odzyskuje dane, ale jej źródło danych nie zostało przywrócone do tego samego punktu odzyskiwania, co sprawia wrażenie poprawnego działania na nieaktualnych danych. Ten rodzaj zależności nie pojawia się na mapach topologii sieci ani w analizie grafów wywołań, dopóki sam przepływ danych nie zostanie prześledzony.
Współdzielona konfiguracja i zależności schematów. Aplikacje współdzielące schematy bazy danych, usługi konfiguracyjne lub dostawców tożsamości mają niejawne zależności, nawet jeśli nigdy nie wywołują się bezpośrednio. Zmiana schematu we współdzielonej bazie danych może wpłynąć na wiele aplikacji. Odzyskiwanie jednej aplikacji po uszkodzeniu schematu bez odzyskiwania wszystkich aplikacji współdzielących ten schemat powoduje niespójny stan w całym portfolio aplikacji.
Integracja BCP: Jak wyniki krytyczności wpływają na decyzje dotyczące odzyskiwania
Wynik krytyczności stanowi dane wejściowe do sześciu konkretnych decyzji projektowych BCP:
1. Definicja sekwencji odzyskiwania. Aplikacje odzyskują się w kolejności krytycznej, warstwa 1 przed warstwą 2 przed warstwą 3, ale w obrębie warstwy kolejność określa graf zależności. Aplikacje bez zależności przychodzących (żadna inna aplikacja nie jest od nich zależna) mogą odzyskiwać się w dowolnej kolejności w ramach swojej warstwy. Aplikacje z wysokim poziomem zależności przychodzących muszą odzyskiwać się przed aplikacjami od nich zależnymi, niezależnie od ich względnych wyników w ramach warstwy. Sekwencja odzyskiwania wygląda zatem następująco: kolejność warstw zastosowana do podsekwencji ograniczonej zależnością w każdej warstwie.
2. Wyznaczanie docelowych wartości RTO i RPO. Wskaźnik krytyczności kalibruje docelowe wartości RTO i RPO. Maksymalny dopuszczalny czas przestoju (MTD) i cel punktu odzyskiwania (RPO) dla każdej aplikacji produkcyjnej stanowią techniczną podstawę całej strategii ciągłości działania. MTD to maksymalny czas, przez jaki firma może tolerować niedostępność aplikacji. RTO musi być mniejsze niż MTD. Margines między RTO a MTD stanowi bufor bezpieczeństwa. Aplikacje poziomu 1 o dużym wpływie na działalność firmy na godzinę przestoju mają wąskie marginesy MTD/RTO i wymagają infrastruktury zaprojektowanej z myślą o szybkim, zautomatyzowanym odzyskiwaniu.
3. Kalibracja inwestycji w infrastrukturę. Wyniki oceny krytyczności bezpośrednio wpływają na decyzje inwestycyjne w infrastrukturę DR. Aplikacje warstwy 1 uzasadniają redundancję wieloregionową w trybie aktywny-aktywny. Aplikacje warstwy 2 uzasadniają tryb aktywny-pasywny z przetestowanym przełączaniem awaryjnym. Aplikacje warstwy 3 uzasadniają regularne tworzenie kopii zapasowych z udokumentowanymi procedurami przywracania. Aplikacje warstwy 4 mogą opierać się na standardowych zasadach tworzenia kopii zapasowych. Bez wyników oceny krytyczności decyzje inwestycyjne w infrastrukturę domyślnie prowadzą do równomiernego przeinwestowania (kosztownego) lub równomiernego niedoinwestowania (ryzykownego).
4. Wymagania dotyczące kontroli zmian. Aplikacje o wyższych wynikach krytyczności wymagają bardziej rygorystycznej kontroli zmian: dłuższych okien zamrożenia zmian, większej liczby osób zatwierdzających, bardziej rozbudowanych testów przed wprowadzeniem zmian, bardziej konserwatywnych procedur wycofywania zmian. Stosowanie kontroli zmian poziomu 1 do aplikacji poziomu 4 marnuje czas inżynierów. Stosowanie kontroli zmian poziomu 4 do aplikacji poziomu 1 stwarza niedopuszczalne ryzyko.
5. Częstotliwość testowania i walidacji. BCP wymaga okresowego testowania procedur odzyskiwania, ćwiczeń symulacyjnych, testów awaryjnych na poziomie komponentów oraz pełnych symulacji odzyskiwania po awarii. Częstotliwość testowania określają wartości krytyczne: aplikacje poziomu 1 wymagają kwartalnych testów odzyskiwania po awarii; aplikacje poziomu 4 wymagają testów rocznych. Testowanie każdej aplikacji z tą samą częstotliwością nie jest ani praktyczne, ani konieczne.
6. Wymagania SLA dostawcy. W przypadku aplikacji zależnych od usług zewnętrznych, współczynnik krytyczności określa wymagania SLA, które muszą być zawarte w umowach z dostawcą. Aplikacja Tier 1 z 4-godzinnym RTO wymaga umowy SLA od dostawcy, która gwarantuje dostępność zgodną z tym RTO. Aplikacja Tier 4 nie wymaga takiej umowy.
Komplikacja systemu legacy
Starsze systemy komplikują ocenę krytyczności w sposób, którego nowoczesne ramy zarządzania portfelem aplikacji nie uwzględniają w wystarczającym stopniu. Standardowa ocena krytyczności zakłada, że właściciele aplikacji wiedzą, co robią ich aplikacje i kto od nich zależy. W przypadku starszych systemów, programów COBOL, które były utrzymywane przez wiele pokoleń programistów, strumieni zadań JCL, których zależności zostały ostatnio udokumentowane w 2008 roku, programów RPG generujących pliki wyjściowe wykorzystywane przez procesy, których nikt obecnie nie napisał w organizacji, to założenie nie jest spełnione.
Rzeczywista struktura zależności starszego systemu jest widoczna tylko w samym kodzie. Program COBOL, który zapisuje do zbioru danych odczytywanego przez dwanaście programów podrzędnych, ma dwanaście zależności podrzędnych, ale fakt ten może nie być znany właścicielowi programu COBOL, który widzi jedynie funkcję programu (przetwarzanie codziennych transakcji), a nie jego rolę strukturalną (generowanie zbioru danych, który umożliwia działanie dwunastu innych procesów).
W przypadku starszych systemów, wymiar zależności w ocenie krytyczności wymaga analizy kodu, a nie ankiet przeprowadzanych wśród właścicieli. Liczbę wejść fan-in dla programu COBOL można uzyskać jedynie poprzez zbadanie wszystkich innych programów w środowisku i określenie, które z nich odwołują się do wyjściowych zestawów danych, konwencji wywołań lub współdzielonych kopii pierwszego programu. Tę analizę oferują platformy do strukturalnej analizy kodu, a bez niej wymiar zależności w ocenie krytyczności przypisanej do starszego programu jest w najlepszym razie uzasadnionym przypuszczeniem.
Konsekwencje błędnej oceny krytyczności starszych aplikacji są szczególnie dotkliwe, ponieważ starsze systemy są zazwyczaj zarówno wysoce krytyczne (często zawierają podstawową logikę biznesową, która narastała przez dekady), jak i słabo punktowane (ich właściciele nie potrafią jasno określić, co od nich zależy, więc przyznają zachowawcze oceny). W rezultacie starsze programy, którym przypisano poziom 3, w rzeczywistości znajdują się na ścieżce krytycznej procesów biznesowych poziomu 1 – dokładnie taki tryb awarii, jaki pojawia się w sekwencjach odzyskiwania po awarii podczas rzeczywistych incydentów.
W jaki sposób SMART TS XL Zapewnia dowody zależności dla oceny krytyczności
SMART TS XL bezpośrednio zajmuje się wymiarem zależności w ocenie krytyczności aplikacji w przypadku tej klasy aplikacji, w której podejścia oparte na ankietach są najmniej niezawodne.
Funkcja mapowania zależności aplikacji tworzy kompletny graf zależności dla każdego języka w środowisku: każdego programu COBOL, który wywołuje każdy inny, każdego kroku zadania JCL, który generuje dane przetwarzane przez programy podrzędne, każdego współdzielonego repozytorium, który tworzy niejawne zależności między programami, które nigdy nie wywołują się bezpośrednio, każdego zbioru danych przepływającego między programami producenta i konsumenta. Ten graf stanowi strukturalną bazę dowodową dla wymiaru zależności w ocenie krytyczności, liczbie wejść, identyfikacji współdzielonych komponentów oraz ukrytych zależności w potoku danych, których ankiety nie są w stanie wiarygodnie uchwycić.
Możliwość analizy wpływu sprawia, że graf zależności jest możliwy do odpytania na potrzeby planowania ciągłości działania (BCP): dla dowolnej aplikacji w portfolio należy wyliczyć wszystkie inne aplikacje, które zależą od niej bezpośrednio lub przechodnio, a zatem dziedziczą jej wymagania dotyczące dostępności. Program w języku COBOL z trzema bezpośrednimi elementami zależnymi i dwudziestoma przechodnimi elementami zależnymi (programami zależnymi od bezpośrednich elementów zależnych) ma krytyczność efektywną, która odzwierciedla dwadzieścia trzy programy, w których znajduje się na ścieżce krytycznej, a nie tylko jego własną funkcję.
Funkcja statycznej analizy kodu wydobywa strukturalne metryki złożoności, które określają wymiar złożoności odzyskiwania: złożoność cyklomatyczną, metryki sprzężenia, odsetek martwego kodu oraz wskaźniki długu technicznego, które przewidują czas i ryzyko odzyskiwania każdej aplikacji. Aplikacja o wysokiej złożoności i gęstym sprzężeniu jest droższa w odzyskiwaniu, a jej wynik złożoności odzyskiwania w wymiarze 3 jest wyższy niż w przypadku aplikacji o równoważnych funkcjach i czystej architekturze.
Funkcja wyszukiwania w przedsiębiorstwie umożliwia przeszukiwanie pełnego spisu zależności w całym cyklu życia BCP: znajdź każdy program uzyskujący dostęp do określonego zestawu danych (identyfikując wszystkie programy zależne od jego dostępności), każdy program współdzielący określony copybook (identyfikując wszystkie programy, których dostępność jest zależna od jego dostępności), każde zadanie JCL uruchomione w określonym oknie wsadowym (identyfikując wszystkie programy, które muszą zostać przywrócone przed rozpoczęciem okna). Ta funkcja wyszukiwania obsługuje coroczny przegląd wyników krytyczności, proces aktualizacji, który utrzymuje aktualność wyników w miarę rozwoju portfolio aplikacji.
Dla organizacji prowadzących modernizacja dziedziczna programy towarzyszące rozwojowi BCP, SMART TS XLAnaliza spełnia obydwa cele jednocześnie: mapa zależności informująca o ocenie krytyczności określa również sekwencję migracji, a metryki złożoności informujące o ocenie złożoności odzyskiwania określają również szacowanie nakładu pracy na modernizację.
Aktualizowanie wyników: cykl przeglądu rocznego
Ocena dojrzałości ciągłości działania powinna pomóc Ci w trzech kwestiach: zrozumieniu obecnego stanu, zidentyfikowaniu najważniejszych luk oraz opracowaniu realistycznej ścieżki rozwoju. To właśnie sprawia, że ocena dojrzałości przekształca się w lepszy program.
Wyniki krytyczności aplikacji oddalają się od rzeczywistości wraz ze zmianami w organizacjach. Dodawane są nowe aplikacje. Stare aplikacje są wycofywane, ale nie całkowicie wyłączane z eksploatacji. Integracje są tworzone między aplikacjami, które wcześniej nie były od siebie zależne. Procesy biznesowe ulegają zmianom, a wraz z nimi aplikacje, na których polegają. Wymagania regulacyjne ewoluują i nakładają nowe obowiązki odzyskiwania danych.
Roczny cykl przeglądu wyników krytyczności powinien obejmować:
Ponowna analiza strukturalna. Ponownie uruchom mapowanie zależności, aby zidentyfikować nowe zależności wprowadzone od czasu ostatniego przeglądu. Aplikacje, które były autonomiczne, mogą teraz mieć zależności, które zwiększają ich krytyczność. Aplikacje, od których istniało duże zapotrzebowanie, mogły zostać poddane migracji użytkowników do nowszych systemów, co zmniejszyło ich krytyczność.
Ponowna ocena wpływu na działalność. Dane dotyczące przychodów i wpływu operacyjnego zmieniają się wraz z rozwojem firmy i ewolucją jej portfolio aplikacji. Aplikacja, która trzy lata temu obsługiwała 1 dolarów na godzinę, może teraz, po rozwoju firmy, obsługiwać dziesięciokrotnie więcej.
Uwzględnienie wyników testów odzyskiwania. Testy odzyskiwania ujawniają rozbieżności między zakładaną a rzeczywistą złożonością odzyskiwania. Aplikacja, która uzyskała niski wynik w teście złożoności odzyskiwania w początkowej ocenie, mogła uzyskać słabe wyniki w ćwiczeniu symulacyjnym, co sugeruje podwyższenie wyniku.
Przegląd zmian regulacyjnych. Nowe przepisy lub zmiany w istniejących przepisach mogą nakładać nowe obowiązki dotyczące czasu odzyskiwania danych na określone aplikacje. Na przykład wymogi dotyczące odporności operacyjnej określone w rozporządzeniu DORA dla instytucji finansowych UE nałożyły określone obowiązki dotyczące RTO na „funkcje krytyczne lub ważne”, które mogły nie zostać uwzględnione w wynikach oceny krytyczności sprzed wprowadzenia DORA.
Organizacje z dojrzałymi programami BCP traktują ocenę krytyczności nie jako jednorazowe ćwiczenie, lecz jako ciągły proces: oceny są aktualizowane, gdy zachodzą istotne zmiany w zależnościach aplikacji, wpływie na działalność biznesową lub obowiązkach regulacyjnych, a następnie co roku są weryfikowane w ramach ustrukturyzowanego przeglądu.
Wynik jest tak dobry, jak dowody zależności
Ocena krytyczności aplikacji jest najbardziej wartościowa, gdy jej wymiar zależności opiera się na dowodach strukturalnych, a nie na ankietach. Wymiary wpływu na działalność firmy i obowiązków regulacyjnych można wiarygodnie ocenić poprzez wywiady i analizę procesów biznesowych. Wymiar zależności operacyjnej nie jest jednak w stanie tego zrobić, ponieważ wymaga on wiedzy o tym, co zależy od każdej aplikacji, a właściciele aplikacji systematycznie niedoceniają swoich odbiorców końcowych.
Tryb awarii jest przewidywalny: sekwencja odzyskiwania oparta na wynikach krytyczności uzyskanych z ankiety zawodzi w przypadku ukrytych zależności. Starsza usługa uwierzytelniania przywraca dane z opóźnieniem. Program do konwersji walut w języku COBOL jest offline, gdy aplikacje od niego zależne próbują go odzyskać. Współdzielony schemat bazy danych znajduje się w innym punkcie odzyskiwania niż aplikacje, które go odczytują. Każdej z tych awarii można zapobiec dzięki dowodom zależności, jakie zapewnia analiza strukturalna, a każda z nich jest kosztowna, gdy występuje podczas rzeczywistego incydentu, a nie podczas ćwiczenia symulacyjnego.
Metodologia punktacji jest ustalona. Ramy istnieją. Luka, którą ma większość organizacji, nie leży w ramach punktacji, ale w bazie dowodowej dla jej najważniejszego wymiaru. Należy wypełnić tę lukę za pomocą analizy strukturalnej, zanim kolejny incydent będzie wymagał działania planu ciągłości działania.
