Wednesday, June 17th, 2009...11:23 pm

A co gdy plan zawiedzie …

Jump to Comments

Paweł napisał ostatnio o potrzebie ciągłego sprawdzania swoich procedur awaryjnych na przykładzie z rzeczywistego życia. “Great minds think alike” ktoś powiedział … ale nie zrównujmy Pawłą do autora tegoż tekstu …

Faktem jest, że ostatnio w sytuacji całkiem “nie komputerowej” miałem podobną myśl w kontekście procedur awaryjnych. Myśl zdarzyła się w windzie i spowodowana była tą oto procedurą awaryjną (przepraszam ze zdjęcie nieczytelne ale tyle udało mi się wydusić z HTC w tych warunkach):

W dużym skrócie, w przypadku awarii  pasażer(owie) powinien skontaktować się z obsługą przez “interkom” i oczekiwać na przybycie kawalerii (swoją drogą pytanie co powinni robić w dźwigu bez instalacji interkomowej ;)?).

To czego ta instrukcja nie uwzględnia, i czego nie uwzględniał prawie żaden z dokumentów tego typu, które widziałem to pytanie “A co gdy to nie zadziała?” W większości, działania w takich przypadkach sprowadzają się do improwizacji. Rzeczony pasażer windy może przecież w przypadku braku komunikacji przez interkom krzyczeć POMOCY, czy też HELP lub HILFE w wybranym języku. Czy go ktoś usłyszy to już inna sprawa (o tym czy zrozumie nie dyskutujemy, zakładam że w sytuacji głosu dochodzącego z windy zadziała tak zwany zdrowy rozsądek),

Wracając jednak na grunt informatyczny warto byłoby w tworzonych planach odzyskiwania usług przewidzieć takie scenariusze sytuacje takie jak:

  • Procedura X nie zadziałała … osoba ją wykonująca (założenie że zawsze będzie to osoba znająca się doskonale na temacie może być błędne), w przypadku braku innych instrukcji w takim wypadku zacznie improwizować. Czy nie lepiej byłoby w ramach procedur wskazać jednak jaki jest alternetywny sposób podejścia do tematu?
  • Pomimo że odnosimy same sukcesy nadal jesteśmy na pustyni … czyli nasze procedury działają, wdrażamy je dzielnie jeden dzień …. i drugi … i trzeci się szykuje … a to co mają przywrócić (czyli na przykład nasza krytyczna aplikacja) nadal nie jest dostępna. Pytanie co wtedy …. kontynuować próby zastosowania naszych wypracowanych w pocie czoła i laboratorium procedur czy też podjąć akcje alternatywną? Pytanie podstawowe tylko …. czy wiemy jaką akcję alternatywną możemy podjąć. Jeżeli tak, to może dobrze byłoby tą alternatywę opisać również w naszym dokumencie DR?

Jak dotąd w różnego rodzaju dokumentach opisujących tego typu zagadnienia element ten był raczej pomijany. Często w przypadku dokumentcji DR spotykam się z podejściem, w którym dokument taki traktowany jest tylko jako spis procedur technicznych mających na celu przeprowadzenie odpowiedniego zadania (na przykład jak odtworzyć konkretny obiekt). A to tylko jeden z aspektów procesu zapewnienia możliwości odzyskania danych czy usługi.  Ale temat tego co w takiej dokumentacji powinno się znaleźć to trochę szerszy temat.

Tak że tworząc procedury awaryjne warto może czasami zastanowić się … a co będzie gdy …

… pozostawiając do rozważenia :).

1 Comment

  • Nie dasz rady przewidzieć wszystkiego. Jeśli przetestowana procedura nie działa, to oznacza to tylko tyle, że stan początkowy założony w procedurze i stan początkowy realny są różne. Wyjścia masz wtedy dwa:
    1) próbować zmienić zastany stan początkowy (w przypadku windy naprawić interkom)
    2) zmienić procedurę (w przypadku windy zmienić sposób komunikacji)

    Dobry dokument DR powinien dokładnie opisywać założony stan początkowy oraz samą procedurę. Jeśli stan początkowy jest niezgodny z założonym to należy poszukać dokumentu opisującego w jaki sposób przywrócić stan początkowy. Dodatkowo powinien uwzględniać wszystkie znane (na przykład z historii) błędy i konsekwencje odstąpienia od procedury (walenie w windę w celu wywołania hałasu może spowodować jej blokadę). I oczywiście powinien być regularnie poprawiany poprzez uwzględnienie wszystkich czynników które wychodzą w praniu…

Leave a Reply