Viability sp. z o.o.

Czy kopia zapasowa (backup) to ratunek od przestoju?

14 października 201817 listopada 2020

Po co nam usługi disaster-recovery, przecież my nie żyjemy w Ameryce. W końcu jakie jest prawdopodobieństwo katastrofalnego zdarzenia, które akurat zniszczy nasz budynek? Uwielbiam taką retorykę! A już Albert Einstein mówił: „Wyobraźnia jest ważniejsza od wiedzy, ponieważ wiedza jest ograniczona”. Proponuję zatem nieco poszerzyć nasze horyzonty i rozważyć, czy rzeczywiście w każdym przypadku dobrze wykonany backup to ratunek od przestoju.

Skojarzenie dotyczące katastrof najczęściej bierze się z rozdzielnego tłumaczenia wyrazów „disaster” i „recovery”. Wówczas krążymy wokół zdarzeń kategorii: tornado, upadek statku powietrznego, pożar czy powódź. Tymczasem już Google Translator to zestawienie wyrazów tłumaczy jako: „odzyskiwanie po awarii”. A że awaria me wiele imion i zwykle wydarzy się w najgorszym momencie, to i jest miejsce na rozważania czy ten firmowy backup to na pewno odpowiedź na każdą sytuację. Odpowiedź oczywiście jest przecząca.

Pora na konkrety. Kiedy zdecydowanie potrzebujesz usług disaster-recovery:

Jeśli przetwarzasz dane we własnej serwerowni, która nie spełnia standardu Uptime Institute Tier II lub ANSI/TIA-942 Tier 2.
Gdy nie dublujesz kluczowej infrastruktury (serwery, przełączniki) i nie stosujesz mechanizmów wysokiej dostępności (high availability).
Gdy sprzęt, którego używasz ma więcej niż 3 lata i jest już po gwarancji.
Jeśli Twój kontrakt serwisowy z dostawcą przewiduje naprawę lub wymianę w następnym dniu roboczym (np. 8x5xNBD).
Jeśli godzinna przerwa w dostępności choćby jednego serwera jest biznesowo nie do zaakceptowania.
Jeśli nie masz własnego zespołu IT lub masz tylko jednego fachowca.
Gdy nie masz ubezpieczenia typu business interruption rozszerzonego o systemy IT i dane[1].
Jeśli przywracanie z kopii zapasowej krytycznego serwera zajmuje kilka godzin.

Nawet jeśli tylko jeden z punktów pasuje do sytuacji jaką masz w firmie, powinieneś poważnie rozważyć usługi z zakresu disaster-recovery, np. DRaaS. Jeśli pasujących punktów jest więcej (wyłączając oczywiście pkt. 5 i 7), wówczas ryzyko wystąpienia przestoju jest bardzo wysokie. Kopia zapasowa jest niezbędna, jednak nie przywróci normalnego funkcjonowania, gdy pojawi się problem sprzętowy. W takiej sytuacji potrzebny jest szybki start na innym sprzęcie np. w zapasowej lokalizacji lub w chmurze publicznej dostawcy nawet w ciągu 15 minut.

[1] na dzień pisania tego artykułu w Polsce nie znalazłem takiej oferty.

Planowanie odtwarzania po awarii – 7 grzechów głównych

10 maja 201817 listopada 2020

Jako samozwańczy „ewangelista” z zakresu ciągłości działania – czuję się usprawiedliwiony sięgając po katechizm 😉 Nie będę jednak prawił kazań. Opowiem tylko o typowych błędach jakie towarzyszą planowaniu odtwarzania po awarii, pamiętając przy tym o lekkostrawnej formie.

1. Pycha. Nam się nic nie przytrafi. Zadziwiająco często spotykam menadżerów którzy jak mantrę powtarzają: „Przecież nigdy się to nie zdarzyło, po co więc chronić się przed takim ryzykiem?” Wtedy zalecam BIA (Analiza wpływu na biznes), która wprost odpowiada na pytanie czy warto czy też nie.
2. Chciwość. Ta inwestycja nie przyniesie pieniędzy. Biznes nie lubi inwestować gdy nie widzi policzalnych zwrotów. Ciągłość działania porównać można do polisy ubezpieczeniowej, gdzie nakłady to koszt. Niestety, nie wiadomo, czy zaangażowane środki się zwrócą – czyli czy na przykład dzięki nim uratujemy organizację od przestoju. Pozostaje chłodna analizy ryzyk i ich wpływu na biznes oraz kosztów przestoju.
3. Nieczystość. Nadmiarowość to nie odtwarzanie po awarii. Posiadanie klastra wysokiej dostępności, wyeliminowanie pojedynczych punktów awarii infrastruktury czy świetnie zabezpieczone centrum danych to solidny fundament ciągłości działania. Nie jest to jednak ochrona przed każdym ryzykiem. Przeciętny informatyk wyrwany ze snu bez wahania wskaże kilka scenariuszy, które zatrzymają IT Twojego przedsiębiorstwa.
4. Zazdrość. Pomijanie właścicieli procesów. Zapominamy, lub co gorsza nie chcemy włączyć do planowania wszystkich interesariuszy. To strzał w kolano. Bez ich wiedzy nie będzie skutecznego odtworzenia po awarii.
5. Nieumiarkowanie. Wszystko jest krytyczne. Klasyka. Zwykle, gdy zespół IT arbitralnie decyduje o tym, jakie zasoby mają być zabezpieczone na wypadek awarii, mamy sytuację, w której zasoby centrum zapasowego równe są zasobom centrum podstawowego.
6. Gniew. Dlaczego działa tak wolno? Aspekt wydajności środowiska zapasowego jest częstym zarzewiem konfliktów wewnętrznych i zewnętrznych. Pamiętajmy, że to proteza, niezbędna do czasu powrotu stanu normalnego. Mamy podtrzymać procesy krytyczne. Poza tym testujmy praktycznie nasz plan odzyskiwania po awarii.
7. Lenistwo. Zbytnie zaufanie do dostawcy DRaaS. Odtwarzanie po awarii jako usługa wymaga zaangażowania każdej strony umowy. Dostawca odpowiada za technologię i zasoby po swojej stronie. My natomiast, zadbajmy o uruchomienia testowe czy też cykliczne aktualizujmy plan odtwarzania po awarii. Przy okazji, zmianie może ulec zapotrzebowanie na zasoby dostawcy.

Nie ma świętości Panie i Panowie. Awaria nie zaczeka!

27 marca 201717 listopada 2020

Prędzej czy później każdy sprzęt zawiedzie. Dlaczego? Bo steruje nim napisane przez ludzi oprogramowanie. Może to trochę obrazoburcze, ale w tej kwestii trudno będzie mnie przekonać. Tempo zmian jest już tak duże, że wyprodukowanie aplikacji bez błędów graniczy z cudem. Pośpiech jest, jak wiadomo, zabójcą dokładności. Jeśli dodać do tego, stale rosnącą liczbę funkcji, i że teraz „każdy może programować”, to przyszłość w kontekście niezawodności jawi się w czarnych barwach. Spoko, jest i na to rada, ale pamiętajcie, awaria nie zaczeka na człowieka!

Zawsze trafiam na najtrudniejsze przypadki. Zawieszony iPhone tak, że trzeba cierpliwie czekać aż bateria się wyczerpie, router sieci domowej, który nie wiedzieć czemu „przyjmuje” tylko połączenia wifi ze smartfonów, a na koniec zawieszający się Polar V800 właśnie wtedy gdy zaczynam trening, grrr! W rezultacie myślę, że gdy ja dzwonię na help-desk techniczny producenta lub dostawcy usług, to wszyscy w tym momencie biegną schronić się do toalety 😉 Tradycyjnie mój przypadek jest nikomu nieznany, a przez to pomoc nigdy nie nadchodzi. Zwykle muszę sam, metodą prób i błędów, zdiagnozować problem i zapanować nad trudną materią. Kosztuje mnie to sporo czasu i nerwów, ale przez to już dawno pogodziłem się z faktem, że nie ma rzeczy/systemów bezawaryjnych. I jeszcze jedno, tak samo jak zakup drogiego auta leczy z przeświadczenia, że drogie i markowe się nie psuje, tak samo powinno myśleć się o swojej własnej serwerowni. Czyż nie?

W dodatku, wszystko zaczyna komunikować się ze sobą nawzajem, a to, plus wszechobecne bezpieczeństwo, jeszcze powiększa złożoność serwowanych nam ekosystemów informatycznych.

Zawsze hołduję nadmiarowości i namawiam Was do tego by, planując zasoby IT, zarówno własne jak i chmurowe, pamiętać o redundancji. Poza tym biznesowo, dla procesów krytycznych musi być wcześniej opracowana „ścieżka awaryjna”. Chcesz działać mimo awarii, przygotuj się na to zawczasu. Nie licz na inteligencję swojej organizacji i że jakoś to będzie. Gdy coś się wydarzy nie będzie czasu na wymyślanie, wtedy trzeba szybo działać by minimalizować przestój.

Zachęcam do zapoznania się z tekstem: „Czy mojej firmie potrzebne jest zapasowe centrum danych (w domyśle – DraaS)?”