Przywrócić działanie firmy po awarii IT: plan działania

Awaria IT nie pyta, czy masz czas. Pojawia się rano, w środku tygodnia, kiedy masz spotkanie z klientem i pięć faktur do wysłania. Nagle serwer nie odpowiada, systemów nie ma, a ludzie stoją i czekają. Jeśli zastanawiasz się, jak szybko przywrócić działanie firmy po awarii IT, odpowiedź zaczyna się od jednej rzeczy: gotowego planu.

Mała firma traci orientacyjnie od 3 000 do 8 000 zł za każdą godzinę przestoju. W przypadku firm zatrudniających kilkadziesiąt osób wartość ta może przekroczyć 10 000 zł. To nie są liczby abstrakcyjne: to twoja faktura za brak planu.

Różnica między firmami, które wracają do działania w 40 minut, a tymi, które odtwarzają się przez dwa dni, rzadko leży w szczęściu lub lepszym sprzęcie. Leży w tym, czy ktoś usiadł wcześniej i zapisał: co robić, w jakiej kolejności, kto dzwoni do kogo. Pracuję z firmami, które taki plan mają, i z tymi, które dopiero po awarii zrozumiały, że powinny go mieć. Ten artykuł daje ci konkretny plan działania: od pierwszych minut po wykryciu problemu aż po długofalowe wnioski.

Pierwsza godzina po awarii IT: diagnoza zamiast paniki

Najdroższy błąd w pierwszej godzinie to działanie bez diagnozy. Firmy wyłączają serwery, resetują routery, przywracają systemy, nie wiedząc jeszcze, co tak naprawdę się stało. Efekt: niszczą dowody, wydłużają odtwarzanie i czasem pogłębiają szkodę. Impuls, żeby coś zrobić, jest zrozumiały. Ale zanim cokolwiek dotkniesz, musisz wiedzieć, co się zepsuło.

Potwierdź zakres, zanim zaczniesz naprawiać

Pierwsze pytania są proste: które systemy nie działają? Czy problem dotyczy jednej stacji, całego serwera, czy całej sieci? Kiedy ostatnio wszystko działało normalnie? Co się zmieniło w ciągu ostatnich 24 godzin: aktualizacja, nowy sprzęt, przenoszone pliki? Jeden niedostępny element potrafi blokować cały łańcuch zależności, więc mapa systemu jest ważniejsza niż natychmiastowe klikanie.

Sprawdź też zależności, czyli to, co od czego zależy. Przykład: program do obsługi klientów (CRM) nie ruszy bez swojej bazy danych. A baza danych to miejsce, w którym ten program trzyma wszystkie informacje, na przykład listę klientów i historię kontaktów. Nawet jeśli sam program wróci do życia, bez bazy będzie pusty i bezużyteczny. Tak samo jest z pocztą, systemem do zarządzania firmą (ERP, czyli program do faktur, magazynu i księgowości) czy udostępnionymi folderami. Każdy z tych elementów ma swoje zależności, a odtwarzanie w złej kolejności tylko wydłuży cały proces.

Aktywuj plan i rozdziel role

Runbook (czytaj: „ranbuk") to po prostu spisana krok po kroku instrukcja awaryjna firmy. Kartka albo dokument, który mówi, co robić po awarii i w jakiej kolejności. Najważniejsze, żeby nie pisać go w trakcie awarii. Powinien powstać wcześniej, na spokojnie, a potem leżeć w miejscu, do którego każdy ma dostęp. Trzeba go też co jakiś czas zaktualizować i sprawdzić, bo sprzęt i programy w firmie się zmieniają.

Jeśli go nie masz, zacznij od prostej listy nazwisk: kto informuje pracowników, kto rozmawia z klientami, kto zajmuje się techniką i kto podejmuje decyzje. Trzy role, trzy konkretne osoby to absolutne minimum. W większych firmach warto dodać osobę pilnującą, komu zgłaszać problem wyżej, oraz osobę odpowiedzialną za plan ciągłości działania (po angielsku BCP, Business Continuity Plan, czyli dokument opisujący, jak firma ma działać mimo awarii).

Jak szybko przywrócić działanie firmy po awarii IT: priorytetyzacja systemów

Firmy, które próbują przywrócić wszystko naraz, zwykle nie przywracają niczego sprawnie. Zasoby, czas i uwaga są skończone. Trzeba wybrać kolejność, a wybór powinien opierać się na jednym kryterium: wpływ na biznes.

Analiza wpływu biznesowego w 15 minut

Nie potrzebujesz certyfikatu ISO ani konsultanta za 20 000 zł. Wystarczy jedna kartka z listą twoich kluczowych systemów. Dla każdego z nich odpowiedz: co się dzieje po godzinie bez tego systemu? Po czterech godzinach? Czy firma traci pieniądze, traci klientów, czy narusza przepisy? Na tej podstawie przypisz priorytety: P1 oznacza krytyczne, P2 ważne, P3 może poczekać.

Dla większości małych firm system do zarządzania firmą (ERP) i obsługi klientów (CRM) to P1. Poczta to P1 lub P2, zależnie od tego, jak bardzo zależy od niej obsługa klienta. Archiwalne raporty i narzędzia do analiz to P3, czyli mogą poczekać najdłużej. Odtwarzaj w tej kolejności i nie mieszaj priorytetów, nawet jeśli ktoś naciska.

RTO i RPO: dwie liczby, które musisz znać

Za skrótami RTO i RPO kryją się dwa proste pytania. RTO (Recovery Time Objective) to odpowiedź na pytanie: „jak długo system może nie działać, zanim zrobi się naprawdę źle?". RPO (Recovery Point Objective) to odpowiedź na pytanie: „ile danych możemy stracić bez katastrofy?", czyli jak daleko w przeszłość trzeba się cofnąć do ostatniej kopii.

Przykład: jeśli firma nie wytrzyma bez systemu obsługi klientów (CRM) dłużej niż dwie godziny, to RTO wynosi 2 godziny. Jeśli może stracić najwyżej 15 minut wpisów, to RPO wynosi 15 minut. Dla zwykłego serwera z plikami orientacyjne wartości to RTO od 8 do 24 godzin i RPO od 4 do 24 godzin. Dla najważniejszych części systemu do zarządzania firmą (ERP) jest ostrzej: RTO od 1 do 4 godzin, a RPO do 1 godziny.

Krok po kroku: przywracanie usług w odpowiedniej kolejności

Logika odtwarzania jest prosta, ale rzadko przestrzegana w praktyce. Pomyśl o tym jak o budowie domu: najpierw fundamenty, potem ściany, na końcu meble. W IT fundamentem jest infrastruktura: sieć, serwery (czyli centralne komputery firmy) i wirtualizacja (technologia, która pozwala uruchomić kilka „komputerów" na jednej maszynie fizycznej). Potem przywracasz bazy danych, czyli magazyny informacji. Dopiero na końcu programy, z których korzystają pracownicy. Odwrócona kolejność nic nie da: program się nie uruchomi, nawet jeśli dane są całe, bo nie ma na czym działać.

Infrastruktura, bazy danych, aplikacje: kolejność ma znaczenie

Jeden niedziałający element u podstawy potrafi zablokować kilkanaście kolejnych. Takie wąskie gardła trzeba znaleźć na samym początku, a nie w połowie odtwarzania. Ważne jest też, że backup (czyli kopia zapasowa danych) i replikacja (jej bieżąca kopia trzymana w drugim miejscu) to nie tylko pytanie „czy w ogóle mamy kopię", ale też „z którego momentu ją odtwarzamy i czy te dane są kompletne".

Jeśli twoje główne środowisko w ogóle nie działa, rozważ przełączenie firmy na zapasowe. Fachowo nazywa się to failover, czyli automatyczne przejście na zapas, trochę jak agregat prądotwórczy, który włącza się sam, gdy zabraknie prądu. Taką gotową „zapasową firmę w chmurze" daje usługa DRaaS (Disaster Recovery as a Service, czyli odtwarzanie po awarii w formie abonamentu). Na polskim rynku mają ją w ofercie między innymi Netia (Netia Compute DRaaS) i OVHcloud, a także inni dostawcy chmury.

Weryfikacja po przywróceniu: nie ogłaszaj sukcesu za wcześnie

To, że technicznie „wszystko wstało", nie znaczy jeszcze, że firma działa normalnie. Po odtworzeniu sprawdź, czy dane są kompletne i nieuszkodzone, czy da się normalnie zalogować i czy programy poprawnie się ze sobą komunikują. Przede wszystkim przetestuj to, co najważniejsze dla biznesu: czy zamówienie przechodzi? Czy faktura się zapisuje? Czy poczta odbiera i wysyła? Dopiero gdy te testy wypadną dobrze, możesz ogłosić zespołowi powrót do normalnej pracy.

Porównaj rzeczywisty czas odzysku z zakładanym RTO. Jeśli przekroczyłeś cel dwukrotnie, to ważna informacja na przyszłość: albo plan był nierealny, albo procedury wymagają poprawy.

Komunikacja w czasie awarii: co mówić i do kogo

Komunikacja to rzecz, którą większość firm pomija w swoich planach na wypadek awarii (po angielsku disaster recovery, w skrócie DR, czyli odtwarzanie firmy po poważnej awarii). To błąd. Złe albo spóźnione komunikaty potrafią narobić więcej szkód, i w pracy, i w wizerunku firmy, niż sama awaria techniczna.

Jak informować pracowników bez rozsiewania paniki

Wyznacz jedną osobę odpowiedzialną za komunikację wewnętrzną. Ta osoba przekazuje aktualizacje statusu w regularnych odstępach czasu: co 30 minut przy poważnej awarii, co godzinę przy mniejszych incydentach. Konkretna częstotliwość zależy od skali problemu i oczekiwań zespołu.

Treść komunikatu powinna zawierać trzy elementy: co jest niedostępne, co robimy, kiedy szacujemy powrót. Lepszy jest komunikat niepełny, ale szybki, niż perfekcyjny po trzech godzinach ciszy. Brak informacji nie uspokaja: nakręca spekulacje i frustrację.

Jak poinformować klientów i partnerów

Klientów informujesz wtedy, gdy awaria wpływa na usługi, które im świadczysz. Minimalistyczny komunikat wystarczy: co się stało, co robimy, kiedy wrócimy. Nie wchodź w techniczne szczegóły, nie obiecuj terminów, których nie jesteś pewny.

Jeśli awaria dotyczyła danych osobowych i istnieje ryzyko naruszenia praw osób, masz obowiązek zgłosić incydent Prezesowi UODO bez zbędnej zwłoki, najpóźniej w ciągu 72 godzin od stwierdzenia naruszenia (art. 33 RODO). Termin liczy się od momentu, gdy organizacja dowie się o incydencie, nie od samej awarii technicznej.

Po awarii: co zmienić, żeby historia się nie powtórzyła

Awaria bez wniosków to zapowiedź kolejnej awarii. Firmy, które traktują incydent jako zamknięty temat po przywróceniu systemów, zwykle trafiają do kolejnej sytuacji kryzysowej z tym samym brakiem gotowości.

Przegląd po incydencie: godzina, która oszczędza tygodnie

Jeden, dwa dni po awarii usiądź i spokojnie ją omów (fachowo nazywa się to post-incident review, czyli przegląd po incydencie). Nie chodzi o szukanie winnych, tylko o przyczyny i luki. Co spowodowało awarię? Czy kopia zapasowa była dostępna i aktualna? Gdzie procedury zawiodły? Gdzie ludzie nie wiedzieli, co robić? Wnioski wpisz od razu do runbooka (tej instrukcji awaryjnej) i zaktualizuj plan ciągłości działania.

Testuj backup przynajmniej raz na kwartał. Backup, którego nie testujesz, to nie backup.

Stała opieka IT kontra reagowanie po fakcie

Firmy, które mają stałą opiekę informatyczną, wracają do działania szybciej niż te, które szukają pomocy dopiero w chwili awarii. Powód jest prosty: informatyk, który zna twoją firmę od środka, ma gotowe procedury i jasno ustalone zasady reakcji (tzw. SLA, czyli umowa, która określa, w jakim czasie zajmie się problemem), nie traci godziny na samo zrozumienie, co i jak jest u ciebie skonfigurowane. Wie, gdzie są kopie zapasowe i jak zbudowane jest całe środowisko.

MeridianLayer działa właśnie w tym modelu: gotowy plan awaryjny, bieżąca znajomość firmy klienta i dostępność siedem dni w tygodniu, także wieczorami. Nie płacisz za informatyka na etacie. Płacisz za to, żeby awaria nie trwała dwóch dni.

10-punktowa checklista awaryjna

Poniższa lista działa tylko wtedy, kiedy znasz ją przed awarią. Wydrukuj, powieś w widocznym miejscu, przetestuj raz na kwartał razem z testem backupu.

Pierwsze 15 minut

1. Potwierdź awarię i określ zakres: które systemy są niedostępne, czy problem dotyczy sieci, serwera, danych czy pojedynczej stacji.
2. Uruchom plan DR i powiadom odpowiedzialne osoby: technika, osobę decyzyjną i osobę od komunikacji. Wszyscy muszą wiedzieć w ciągu kilku minut.
3. Zidentyfikuj i zabezpiecz ostatni działający backup: sprawdź datę, spójność, dostępność punktu odtworzenia.

Pierwsze 60 minut

4. Priorytetyzuj systemy według wpływu biznesowego: P1 pierwsze, bez wyjątków.
5. Uruchom odtwarzanie infrastruktury bazowej: sieć, serwery, wirtualizacja. Bez tego reszta i tak nie ruszy.
6. Przełącz na failover lub środowisko zapasowe, jeśli jest dostępne: nie czekaj na odtworzenie środowiska pierwotnego, jeśli masz alternatywę.
7. Poinformuj pracowników o statusie i tymczasowych obejściach: krótko, konkretnie, bez spekulacji.

Pierwsze 24 godziny

8. Przywróć systemy aplikacyjne w ustalonej kolejności: bazy danych, potem aplikacje, zawsze według priorytetów P1, P2, P3.
9. Sprawdź, czy dane są kompletne i czy działa to, co najważniejsze: testy biznesowe, nie tylko techniczne, czyli zamówienie, faktura, logowanie.
10. Udokumentuj przebieg incydentu i porównaj rzeczywisty czas odzysku z zakładanym RTO: to dane do aktualizacji planu, nie materiał do wewnętrznych rozliczeń.

Zanim dojdzie do następnej awarii

Awaria IT to kwestia czasu, nie kwestia szczęścia. Firmy, które przeżywają ją sprawnie, nie mają lepszych komputerów. Mają lepszy plan i kogoś, kto ten plan zna i może wdrożyć natychmiast. Szybkie przywrócenie działania firmy po awarii IT nie bierze się z przypadku, bierze się z przygotowania.

Trzy rzeczy, które możesz zrobić dziś: ustal RTO i RPO dla kluczowych systemów, przetestuj odtwarzanie z backupu, wyznacz osobę odpowiedzialną za pierwsze 15 minut następnej awarii. To nie zajmie dnia. Zajmie dwie godziny i uchroni cię przed dwoma dniami przestoju.

Jeśli wolisz mieć taki plan gotowy, zamiast budować go od zera, to właśnie na tym polega stała opieka IT. W ramach abonamentu przygotowuję runbook, ustalam z Tobą RTO i RPO oraz pilnuję kopii zapasowych, zanim cokolwiek się zepsuje. Pracuję z firmami z Dolnego Śląska oraz zdalnie z całej Polski: przyjeżdżam na miejsce, znam infrastrukturę klienta i jestem dostępny wtedy, kiedy naprawdę tego potrzebujesz, nie tylko w godzinach pracy.

Michał Maciejczyk

Założyciel MeridianLayer · Usługi IT dla firm · Strzelin, Oława, Wrocław