Witam wszystkich, nazywam się Igor Tyukaczow i jestem konsultantem ds. ciągłości działania. W dzisiejszym poście czeka nas długa i żmudna dyskusja na temat powszechnych prawd.Chcę podzielić się swoim doświadczeniem i opowiedzieć o głównych błędach jakie popełniają firmy opracowując plan ciągłości działania.
1. RTO i RPO losowo
Najważniejszym błędem, jaki widziałem, jest to, że czas odzyskiwania (RTO) jest wzięty z powietrza. No cóż, znikąd - są na przykład jakieś numery sprzed dwóch lat z SLA, które ktoś przywiózł z poprzedniego miejsca pracy. Dlaczego to robią? Przecież zgodnie ze wszystkimi metodami należy najpierw przeanalizować konsekwencje dla procesów biznesowych i na podstawie tej analizy obliczyć docelowy czas odzyskiwania i akceptowalną utratę danych. Ale wykonanie takiej analizy czasami zajmuje dużo czasu, czasami jest kosztowne, czasami nie jest zbyt jasne, jak to zrobić – podkreśl, co należy zrobić. Pierwszą rzeczą, która przychodzi wielu na myśl, jest: „Wszyscy jesteśmy dorośli i rozumiemy, jak działa biznes. Nie marnujmy czasu i pieniędzy! Weźmy plus lub minus tak, jak powinno być. Wyjdź z głowy, używając proletariackiej pomysłowości! Niech RTO będzie trwało dwie godziny.
Do czego to prowadzi? Kiedy przychodzisz do zarządu po pieniądze na działania mające na celu zapewnienie wymaganego RTO/RPO przy określonych liczbach, zawsze wymaga to uzasadnienia. Jeśli nie ma uzasadnienia, pojawia się pytanie: skąd to wziąłeś? I nie ma na co odpowiadać. W rezultacie traci się zaufanie do swojej pracy.
Poza tym czasami te dwie godziny rekonwalescencji kosztują milion dolarów. A uzasadnienie czasu trwania RTO to kwestia pieniędzy, i to bardzo dużych.
I na koniec, kiedy przedstawisz swój plan BCP i/lub DR wykonawcom (którzy w momencie wypadku tak naprawdę będą biegać i machać rękami), zadają podobne pytanie: skąd wzięły się te dwie godziny? A jeśli nie potrafisz tego jasno wyjaśnić, nie będą mieli zaufania ani do Ciebie, ani do Twojego dokumentu.
Okazuje się, że to kawałek papieru dla kawałka papieru, rezygnacja z subskrypcji. Nawiasem mówiąc, niektórzy robią to celowo, po prostu po to, aby spełnić wymagania regulatora.
Cóż, masz to
2. Lek na wszystko
Niektórzy uważają, że plan BCP ma na celu ochronę wszystkich procesów biznesowych przed wszelkimi zagrożeniami. Ostatnio na pytanie „Przed czym chcemy się chronić?” Usłyszałem odpowiedź: „Wszystko i jeszcze więcej”.
Ale faktem jest, że plan ma na celu jedynie ochronę konkretny kluczowych procesów biznesowych firmy z konkretny zagrożenia. Dlatego przed opracowaniem planu należy ocenić występowanie ryzyk i przeanalizować ich konsekwencje dla biznesu. Ocena ryzyka jest konieczna, aby zrozumieć, jakich zagrożeń boi się firma. W przypadku zniszczenia budynku będzie jeden plan ciągłości, w przypadku nacisku sankcji – inny, w przypadku powodzi – trzeci. Nawet dwie identyczne lokalizacje w różnych miastach mogą mieć znacząco różne plany.
Nie da się zabezpieczyć całej firmy za pomocą jednego BCP, zwłaszcza dużej. Przykładowo ogromna Grupa X5 Retail zaczęła zapewniać ciągłość dwóch kluczowych procesów biznesowych (pisaliśmy o tym ). A zamykanie całej firmy jednym planem jest po prostu nierealne, to z kategorii „odpowiedzialności zbiorowej”, kiedy wszyscy są odpowiedzialni i nikt nie jest odpowiedzialny.
Norma ISO 22301 zawiera koncepcję polityki, od której tak naprawdę rozpoczyna się proces ciągłości w firmie. Opisuje, co i przed czym będziemy chronić. Jeśli ludzie przybiegną i poproszą o dodanie tego i tamtego, na przykład:
— Dodajmy do BCP ryzyko, że zostaniemy zhakowani?
Lub
— Niedawno podczas deszczu zalane zostało nasze ostatnie piętro – dodajmy scenariusz, co robić w przypadku zalania?
Następnie od razu skieruj ich do tej polityki i powiedz, że chronimy konkretny majątek firmy i tylko przed konkretnymi, wcześniej uzgodnionymi zagrożeniami, bo to one są teraz priorytetem.
A nawet jeśli propozycje zmian rzeczywiście są właściwe, to zaproponuj uwzględnienie ich w kolejnej wersji polityki. Ponieważ ochrona firmy kosztuje dużo pieniędzy. Zatem wszystkie zmiany w planie BCP muszą przejść przez komisję budżetową i planowanie. Zalecamy dokonanie przeglądu polityki ciągłości działania firmy raz w roku lub bezpośrednio po znaczących zmianach w strukturze firmy lub uwarunkowaniach zewnętrznych (niech czytelnicy mi to wybaczą).
3. Fantazje i rzeczywistość
Często zdarza się, że opracowując plan BCP, autorzy opisują jakiś idealny obraz świata. Na przykład „nie mamy drugiego centrum danych, ale napiszemy plan tak, jakbyśmy mieli”. Albo firma nie posiada jeszcze jakiejś części infrastruktury, ale pracownicy i tak będą ją dopisywać do planu w nadziei, że pojawi się ona w przyszłości. A potem firma naciągnie rzeczywistość na plan: zbuduje drugie centrum danych, opisze inne zmiany.
Po lewej stronie infrastruktura odpowiadająca BCP, po prawej infrastruktura rzeczywista
To wszystko jest błędem. Napisanie planu BCP oznacza wydawanie pieniędzy. Jeśli napiszesz plan, który w tej chwili nie zadziała, będziesz płacić za bardzo drogi papier. Nie da się z tego wyjść, nie da się tego przetestować. Okazuje się, że jest to praca dla pracy.
Plan można napisać dość szybko, jednak budowanie infrastruktury zapasowej i wydawanie pieniędzy na wszelkie rozwiązania zabezpieczające jest długie i kosztowne. Może to potrwać dłużej niż rok. A może się okazać, że masz już plan, a infrastruktura do niego pojawi się za dwa lata. Dlaczego taki plan jest potrzebny? Przed czym Cię ochroni?
To także fantazja, kiedy zespół programistów BCP zaczyna przed ekspertami zastanawiać się, co powinni zrobić i w jakim czasie. Pochodzi z kategorii: „Kiedy zobaczysz niedźwiedzia w tajdze, musisz skręcić w kierunku przeciwnym do niedźwiedzia i pobiec z prędkością przekraczającą prędkość niedźwiedzia. W miesiącach zimowych trzeba zatrzeć ślady.”
4. Wierzchołki i korzenie
Czwartym najważniejszym błędem jest uczynienie planu albo zbyt powierzchownym, albo zbyt szczegółowym. Potrzebujemy złotego środka. Plan nie powinien być zbyt szczegółowy dla idiotów, ale też nie powinien być zbyt ogólny, żeby skończyło się na czymś takim:
Ogólnie na łatwym
5. Dla Cezara - co jest Cezarem, dla mechanika - co jest mechanikiem.
Następny błąd wynika z poprzedniego: w jednym planie nie można uwzględnić wszystkich działań na wszystkich poziomach zarządzania. Plany BCP są zwykle opracowywane dla dużych firm o dużych przepływach finansowych (nawiasem mówiąc, według naszych (średnio 48% dużych rosyjskich firm napotkało sytuacje awaryjne pociągające za sobą znaczne straty finansowe) oraz wielopoziomowy system zarządzania. Dla takich firm nie warto próbować zmieścić wszystkiego w jednym dokumencie. Jeśli firma jest duża i ustrukturyzowana, plan powinien składać się z trzech odrębnych poziomów:
- poziom strategiczny – dla wyższej kadry kierowniczej;
- poziom taktyczny – dla menedżerów średniego szczebla;
- oraz poziom operacyjny – dla osób bezpośrednio zaangażowanych w tę dziedzinę.
Przykładowo, jeśli mówimy o odtworzeniu uszkodzonej infrastruktury, to na poziomie strategicznym podejmowana jest decyzja o uruchomieniu planu naprawczego, na poziomie taktycznym można opisać procedury procesowe, a na poziomie operacyjnym pojawiają się instrukcje dotyczące uruchomienia określonych elementy wyposażenia.
BCP bez budżetu
Każdy widzi swój obszar odpowiedzialności i powiązania z innymi pracownikami. W chwili wypadku każdy otwiera plan, szybko odnajduje swoją część i się jej trzyma. Idealnie byłoby, gdybyś pamiętał na pamięć, które strony otworzyć, ponieważ czasami liczą się minuty.
6. Odgrywanie ról
Kolejny błąd przy sporządzaniu planu BCP: nie ma potrzeby podawania w planie konkretnych nazwisk, adresów e-mail i innych danych kontaktowych. W samym tekście dokumentu należy wskazać jedynie role bezosobowe, rolom tym przypisać nazwiska osób odpowiedzialnych za określone zadania, a ich kontakty wymienić w załączniku do planu.
Dlaczego?
Obecnie większość ludzi zmienia pracę co dwa, trzy lata. A jeśli zapiszesz w tekście planu wszystkich odpowiedzialnych i ich kontakty, wówczas będzie trzeba go stale zmieniać. A w dużych firmach, zwłaszcza rządowych, każda zmiana w jakimkolwiek dokumencie wymaga mnóstwa zatwierdzeń.
Nie wspominając już o tym, że jeśli zdarzy się sytuacja awaryjna i będziesz musiał gorączkowo przeglądać plan w poszukiwaniu odpowiedniego kontaktu, stracisz cenny czas.
Life hack: kiedy zmieniasz aplikację, często nawet nie musisz jej zatwierdzać. Kolejna wskazówka: możesz skorzystać z systemów automatyzacji aktualizacji planów.
7. Brak wersjonowania
Zwykle tworzą plan w wersji 1.0, a następnie wprowadzają wszystkie zmiany bez trybu edycji i bez zmiany nazwy pliku. Jednocześnie często nie jest jasne, co zmieniło się w porównaniu z poprzednią wersją. W przypadku braku wersjonowania plan żyje własnym życiem, którego nie można w żaden sposób śledzić. Na drugiej stronie każdego planu BCP należy wskazać wersję, autora zmian oraz listę samych zmian.
Nikt już nie jest w stanie tego odgadnąć
8. Kogo mam zapytać?
Często w firmach nie ma osoby odpowiedzialnej za plan BCP i nie ma osobnego działu odpowiedzialnego za ciągłość działania. Tę zaszczytną odpowiedzialność przypisuje się CIO, jego zastępcy, czyli w myśl zasady „ty zajmujesz się bezpieczeństwem informacji, więc tu w dodatku BCP”. W rezultacie plan jest opracowywany, uzgadniany i zatwierdzany od góry do dołu.
Kto jest odpowiedzialny za przechowywanie planu, aktualizację i weryfikację zawartych w nim informacji? To nie może być przepisane. Zatrudnianie do tego osobnego pracownika jest marnotrawstwem, ale obciążenie jednego z istniejących dodatkowymi obowiązkami jest oczywiście możliwe, bo wszyscy teraz dążą do wydajności: „Zawieśmy na nim latarnię, żeby mógł w nocy kosić”, ale czy to konieczne?
Poszukujemy osób odpowiedzialnych za BCP już dwa lata po jego powstaniu
Dlatego często dzieje się tak: opracowano plan i włożono do długiego pudełka, aby pokrył się kurzem. Nikt tego nie sprawdza ani nie utrzymuje, że jest to istotne. Najczęstsze zdanie, które słyszę, gdy przychodzę do klienta, to: „Jest plan, ale został opracowany dawno temu, nie wiadomo, czy był testowany, istnieje podejrzenie, że nie działa”.
9. Za dużo wody
Istnieją plany, w których wstęp ma pięć stron i zawiera opis przesłanek oraz podziękowania wszystkim uczestnikom projektu, informację o tym, czym firma się zajmuje. Zanim przejdziesz do dziesiątej strony, na której znajdują się przydatne informacje, Twoje centrum danych jest już zalane.
Kiedy próbujesz przeczytać do tej chwili, co powinieneś zrobić, jeśli Twoje centrum danych zostanie zalane?
Umieść całą firmową „wodę” w osobnym dokumencie. Sam plan musi być niezwykle konkretny: osoba odpowiedzialna za to zadanie robi to i tak dalej.
10. Na czyj koszt jest bankiet?
Często twórcy planów nie mają wsparcia ze strony najwyższego kierownictwa firmy. Istnieje jednak wsparcie ze strony kierownictwa średniego szczebla, które nie zarządza lub nie ma niezbędnego budżetu i zasobów do zarządzania ciągłością działania. Na przykład dział IT tworzy plan BCP w ramach swojego budżetu, ale CIO nie widzi pełnego obrazu firmy. Moim ulubionym przykładem są wideokonferencje. Kiedy wideokonferencja dyrektora generalnego nie zadziała, kogo wypatroszy? CIO, który „nie zapewnił”. Co zatem z punktu widzenia CIO jest najważniejsze w firmie? Za co ludzie zawsze go „kochają”: wideokonferencje, które natychmiast zamieniają się w system o znaczeniu krytycznym dla biznesu. A z biznesowego punktu widzenia - cóż, nie VKS, pomyśl, porozmawiamy przez telefon, jak za Breżniewa...
Poza tym dział IT zazwyczaj uważa, że jego głównym zadaniem na wypadek katastrofy jest przywrócenie działania korporacyjnych systemów informatycznych. Ale czasami nie musisz tego robić! Jeśli istnieje proces biznesowy w postaci drukowania kawałków papieru na strasznie drogiej drukarce, to nie należy kupować drugiej takiej drukarki jako zapasowej i stawiać jej obok niej w przypadku awarii. Może wystarczyć chwilowe ręczne pokolorowanie kawałków papieru.
Jeśli budujemy ciągłą ochronę w IT, musimy pozyskać wsparcie wyższej kadry kierowniczej i przedstawicieli biznesu. W przeciwnym razie, po przepoczwarczeniu w dziale IT, możesz rozwiązać pewien zakres problemów, ale nie wszystkie niezbędne.
Tak wygląda sytuacja, gdy plany DR ma tylko dział IT
10. Żadnych testów
Jeśli istnieje plan, należy go przetestować. Dla osób niezaznajomionych ze standardami nie jest to wcale oczywiste. Na przykład wszędzie wiszą znaki „wyjście awaryjne”. Ale powiedz mi, gdzie jest twoje wiadro, hak i łopata? Gdzie jest hydrant? Gdzie powinna znajdować się gaśnica? Ale każdy powinien to wiedzieć. W ogóle nie wydaje nam się logiczne, aby wchodząc do biura, szukać gaśnicy.
Być może o konieczności przetestowania planu należałoby wspomnieć w samym planie, ale jest to decyzja kontrowersyjna. W każdym razie plan można uznać za skuteczny tylko wtedy, gdy został przynajmniej raz przetestowany. Jak wspomniałem powyżej, bardzo często słyszę: „Jest plan, cała infrastruktura jest przygotowana, ale nie jest faktem, że wszystko będzie tak, jak jest zapisane w planie. Bo tego nie testowali. Nigdy".
Na zakończenie
Niektóre firmy mogą analizować swoją historię, aby zrozumieć, jakiego rodzaju problemy mogą się wydarzyć i jakie jest prawdopodobieństwo ich wystąpienia. Badania i doświadczenie podpowiadają, że przed wszystkim nie jesteśmy w stanie się uchronić. Gówno prędzej czy później przydarza się każdej firmie. Inną kwestią jest to, jak będziesz przygotowany na tę lub podobną sytuację i czy będziesz w stanie na czas przywrócić swój biznes.
Niektórzy uważają, że ciągłość polega na eliminowaniu wszelkiego rodzaju zagrożeń, tak aby się nie zmaterializowały. Nie, chodzi o to, że ryzyko się zmaterializuje i będziemy na to gotowi. Żołnierzy uczy się nie myśleć podczas bitwy, ale działać. Podobnie jest z planem BCP: pozwoli Ci on na jak najszybsze przywrócenie działalności.
Jedyny sprzęt, który nie wymaga BCP
Igor Tyukaczow,
Konsultant ds. ciągłości działania
Centrum Projektowania Systemów Obliczeniowych
„Systemy informacyjne odrzutowca”
Źródło: www.habr.com