02 listopada 2011

Czy warto być przygotowanym na najgorsze?

Dlaczego?


Dzisiejsze systemy to nie tylko kod źródłowy, to przede wszystkim niezawodność i dostępność. Programiści/projektanci odpowiadają w pewnej mierze za te atrybuty systemów, które implementują. Muszę przyznać, że zagadnienie planu ciągłości działania (dalej DR,  ang. disaster recovery plan) było dla mnie czymś zupełnie nowym i abstrakcyjnym. Jakiś czas temu miałem okazję pracować z moim zespołem nad przygotowaniem planu DR. Chciałbym wytłumaczyć się co nas skłoniło do przygotowania i przetestowania takiej procedury i jakie korzyści odnieśliśmy z takiej inwestycji.

Do rozwiązania problemu biznesowego zaproponowaliśmy architekturę, która ze swej natury (używała replikacji MS SQL Server'a) była bardzo podatna na błąd użytkownika. Użytkownikiem mógłbyć niewyspany administrator, nadgorliwy programista czy zmęczony inżynier wsparcia. Najbardziej obawialiśmy się destabilizacji całego produkcyjnego systemu, którą można było osiągnąć np. poprzez usunięcie jednego wiersza w jednej z 10 baz danych. Jeżeli rozwiązanie oparte o mechanizm replikacji okazałoby się zbyt mało bullet-proof, to mogliśmy w pewnym sensie wydać na siebie wyrok skazujący.


Przygotowanie Disaster Recovery



Wydawałoby się, że administrator, ludzie od infrastruktury będą w całości odpowiedzialni za przygotowanie planu "gaszenia pożarów". Taki scenariusz nie zawsze ma racje bytu, spora część wiedzy o meandrach systemu jest w posiadaniu programistów. W naszym przypadku najwięcej pracy wykonaliśmy wspólnie z zespołem administratorów baz danych.

Na wstępie wyodrębniliśmy dwa scenariusze "katastrof", które w sumie pokryły większość kombinacji nieszczęśliwych wypadków. Wypisaliśmy też przykładowe kroki, które miały służyć do przywrócenia systemu do działania. Po zakończeniu testowania, z oryginalnej listy kroków, został tylko jej ogólny zarys. W zderzeniu z rzeczywistością teoretyzowanie nie miało szans. Dlatego plan DR bez testowania jest jak babcia bez wąsów.


Testowanie planu DR


W czasie testowania planu DR okazało się, że system wcale nie jest taki odporny na wszelkie możliwe kombinacje backup'ów, modyfikacji itd. Na bieżąco naprawialiśmy pojawiające się problemy i notowaliśmy co ważniejsze zmiany które należało zaimplementować.

Istotnym elementem był całkowity czas przywrócenia systemu. Mierzyliśmy czas wykonania dla każdego kroku.  Skrupulatnie zapisywaliśmy czasy kopiowania backup'ów, wykonywania czynności administracyjnych itd.

Wymiana doświadczeń z administratorem bazy danych okazała się bardzo cennym doświadczeniem. Wzajemnie wymyślaliśmy scenariusze, które trzeba obsłużyć. Obecność osoby spoza zespołu zapobiegała "zamiataniu pod dywan" pojawiających się problemów i wymuszała szybkie ich rozwiązywanie.

Po przygotowaniu i przetestowaniu
  • posiadaliśmy solidne przekonanie, że nowa wersja systemu działa
  • mogliśmy spać spokojnie, gdyż wiedza o przywróceniu systemu do działania została spisana i przetestowana
  • naprawiliśmy kilka błędów
  • zastosowaliśmy kilka cennych modyfikacji, które przyczyniły się do większej stabilności systemu


Czy warto?


Decyzję czy warto przygotować przygotować plan ciągłości działania dla systemu, który rozwijacie lub utrzymujecie pozostawiam Wam drogim czytelnikom. W przypadku mojego zespołu miało to znaczący wpływ na komfort psychiczny przy wdrażaniu nowej wersji systemu opartego na MS SQL Server replikacji.

Któregoś dnia wróciłem z urlopu, podszedł do mnie szef i mówi, że w czasie weekend'u padł dysk na serwerze i coś tam z systemem IO poszło nie tak. System zastygł, aczkolwiek ze strony szefa pełen spokój. Wyciągnął z szuflady plan DR, spojrzał, który scenariusz pasuje do zainstniałej sytuacji i rozesłał dokumenty do ludzi z insrastruktury. Wszystko poszło jak po maśle :). Ta sytuacja, IHMO, była dla mnie namacalnym dowodem potwierdzającym sensowność spędzonego czasu nad planowanie ciągłości :).

2 komentarze:

  1. Zawsze warto mieć taki plan, ciekawi mnie tylko co w takim planie się znajduje, do jakich wniosków doszliście?
    Pozdrawiam
    Sławek B.

    OdpowiedzUsuń
  2. Cześć Sławek,

    Wnioski były takie, że plan uratował nas w momencie awarii sprzętu i czas zainwestowany w przygotowanie planu DR całkowicie się zwrócił. W innym przypadku skończylibyśmy z downtime'em całego systemu na kilka dni, a tak przywróciliśmy działanie w kilka godzin.

    Plan DR pozwolił nam też ustalić też kto jest potrzebny (DBA, Network Admin, Support) do przywrócenia działania systemu w przypadku awarii. Nie ma wtedy chaosu i nerwów.

    Plan zawierał następujące elementy
    - zakres (czyli na jaki scenariusz jesteśmy gotowi)
    - listę jakich scenariuszy ten plan nie dotyczy
    - listę ról (DBA, Support etc) zaangażowanych w przywrócenie systemu
    - Listę kroków potrzebnych do przywrócenia systemu, każdy krok miał przypisaną rolę która była odpowiedzialna za jego wykonanie.

    Taki plan trzeba uaktualniać i testować po każdym większym releasie systemu.

    Całe przedsięwzięcie jest dosyć kosztowne, ale to już kwestia jak krytyczny jest ten system, który wspieramy.

    OdpowiedzUsuń

Uwaga: tylko uczestnik tego bloga może przesyłać komentarze.