Cześć, dzień dobry. Witam was w podcaście IT i Biznes. Nazywam się Grzegorz Tabor i na co dzień prowadzę trzy firmy, w tym firmę programistyczną, agencję doradczo-rekrutacyjną i SaaS do monitoringu cen konkurencji dla e-commerce.Podcast IT i Biznes kieruje do właścicieli firm oraz menadżerów, którzy na co dzień współpracują w swoich firmach często i dużo z szeroko pojętym IT i chcieliby realizować owe projekty IT bardziej świadomie i skuteczniej. Odcinek dwudziesty drugi. Disaster recovery plan.

Jak poradzić sobie z katastrofą w projekcie IT? Wyobraź sobie, że twój system albo sklep działa, działa poprawnie, wszystko jest w porządku, aż tu pewnego dnia budzisz się i okazuje się, że strona główna nie działa, generalnie nic nie działa i jest to spowodowane na przykład pożarem w serwerowni. Inny przypadek, że na przykład coś nie działa, a ty nie masz dostępu do serwera, bo osoba je posiadająca jest nagle niedostępna lub zwyczajnie nie chce ci tych dostępów przekazać lub co gorsza zadziałała na twoją szkodę i zwyczajnie usunęła pliki z serwerów. Obie sytuacje wydają się czysto hipotetyczne, ale obie zdarzyły się naprawdę.

Jedna w roku 2016, gdzie cała firma hostingowa spoczywała w rękach jednego administratora, a finalnie gdy administrator odszedł z tej firmy, nie przekazując danych dostępowych, stało się coś takiego, że ktoś zalogował się na serwer i skasował 12 lat działania firmy hostingowej i co gorsza dane klientów, czyli dane na temat stron internetowych, kod, bazy danych, co stało się ogromną katastrofą dla owych firm, gdyż tych danych nie udało się odzyskać z dysków lub udało się odzyskać, ale jedynie częściowo, więc firmy musiały polegać na swoim backupie, co gorzej, kiedy go po prostu nie miały. Drugi przypadek to 2021 rok i znana firma hostingowa, w której spłonęła duża część serwerowni. I tutaj również, mimo szczerych chęci, no najzwyczajniej w świecie nie udało się odzyskać danych z dysków, które uległy uszkodzeniu z powodu pożaru.

I tu również wydarzyła się ta katastrofa dla firm klientów tej serwerowni. No i mimo tego, że były zastosowane różne zabezpieczenia, no to była serwerownia bardzo duża, więc tych zabezpieczeń też było sporo, no to po prostu w pewnym momencie któreś nie zadziałało, pojawił się pożar, no i ogromna, masakra katastrofa dla firm. W dzisiejszym odcinku opowiem o tym, czym jest Disaster Recovery Plan i w jaki sposób odpowiada on na to, jak poradzić sobie w momencie, kiedy pojawia się taka mało realna, ale bardzo trudna w skutkach, katastrofa jak w podanych przykładach.

Serdecznie zapraszam. Cześć, dzień dobry. Witam Was serdecznie w odcinku 22.

Poruszamy temat, który zacząłem w poprzednim odcinku, gdzie opowiadałem o tym, czy zachowywać działania prewencyjnie, czy reagować na awarie. Jeżeli go jeszcze nie przesłuchałeś, bądź nie przesłuchałaś, to serdecznie zachęcam, aby z nim także się zapoznać. I dzisiaj w ramach kontynuacji skupimy się na działaniu prewencyjnym, ale takim, które pomaga znacząco w działaniu wystąpienia jakiejś dużej awarii, którą nazywam na potrzeby tego odcinka kryzysem, zareagować sprawnie i szybko, aby zminimalizować straty, które mogłyby z tego powodu wyniknąć dla Twojego biznesu.

Disaster Recovery Plan. Czym jest? Jest to właśnie taka odpowiedź na pojawiający się kryzys. Czyli pojawia się jakaś sytuacja kryzysowa, coś przestaje działać, nagle Twój system nie funkcjonuje.

W e-commerce być może to platforma sprzedażowa po prostu nie sprzedaje, bo nie działa. Następuje właśnie brak działania usług, ale mamy na to gotowy plan, jak te wszystkie usługi uruchomić, na nowych serwerach, skąd te serwery będą, kto to będzie uruchamiał, w jakim czasie te systemy przede wszystkim wrócą do pełnej sprawności. Dlaczego to jest ważne dla biznesu? Każda godzina takiego przestoju, jeżeli to jest faktycznie ważny system, czyli na przykład taka platforma sprzedażowa, no to każda taka godzina przestoju generuje straty, więc im lepiej jesteśmy przygotowani na jej odnowienie, na uruchomienie na nowo tych usług, tym mniejsza ta strata będzie.

No i przede wszystkim, mając wdrożony disaster recovery plan, jesteśmy świadomi tego, że taka sytuacja może się pojawić, więc jesteśmy na nią przygotowani, mamy odpowiednie kopie zapasowe, mamy odpowiedni zespół i mamy odpowiednie procedury, żeby zareagować. No i właśnie ten DRP, który będę tak już skrótowo tutaj nazywał, opisuje ryzyka, jakie mogą się pojawić i czytelną taką zrozumiałą instrukcję działania, aby w danej sytuacji nie ustalać takiego planu tak na bieżąco i nie tracić też tego czasu, żeby mieć świadomość, jak do kogoś się dodzwonić, czy w jaki sposób zgłosić tego typu awarię, czy być może jakiś system zgłosi taką awarię i aby mieć przygotowane właśnie zasoby, w tym na przykład backupy w innym miejscu, czy po prostu zasób w postaci kontaktu czy ustalonej formy kontaktu do kogoś, kto jest w stanie ten system nam odtworzyć. To, co jest ważne to to, że DRP powinno obsługiwać jak najwięcej ryzyk, które tak naprawdę mogą występować i przykładami tych ryzyk może być awaria sprzętu, czyli w tym wypadku chcielibyśmy po prostu móc włączyć inny serwer, na którym tę daną usługę, dany system postawimy.

To mogą być ataki cybernetyczne, czyli też instrukcja, jak im przeciwdziałać, co robić, jeżeli się dzieje jakiś rodzaj określonego ataku, jakie systemy załączyć, co wyłączyć, jak to spowodować, żeby te straty dla biznesu w tym wypadku były jak najmniejsze, żeby ich nie było w ogóle. To jest na przykład utrata kontaktu z zespołem, czy jakaś forma, że coś się wydarza i z jakiegoś powodu nie mamy możliwości skontaktowania się z zespołem, a system pada i trzeba go odzyskać, więc też, żeby mieć jakąś metodę, w jaki sposób ten system można odzyskać wraz z innym zespołem, to mogą być na przykład błędy ludzkie, czyli po prostu ktoś podmienia coś ważnego. Przychodzi mi do głowy taki przykład, gdzie w e-commerce następuje zmiana cen na zbyt niskie względem rynkowych, na przykład z powodu jakiegoś błędu no i pojawia się niekontrolowana fala zamówień o zaniżonej wartości, co dla biznesu jest ogromnym problemem, no bo trzeba te zamówienia odkręcić, skontaktować się z klientami, część zamówień być może wysłać, no a z drugiej strony też trzeba tym ryzykiem, problemem w jakiś sposób zarządzić.

Fajnie jest mieć plan na tego typu rzeczy, żeby po prostu reagować sprawniej i też jeszcze takim jednym ryzykiem, które sobie wypisałem to wyciek danych, czyli po prostu, to też jest sytuacja oczywiście mocno hipotetyczna, no bo nikt nie planuje tego, że z jego systemu dane wyciekną, ale można zaplanować działania, które należy podjąć w przypadku pojawienia się tego typu sytuacji, która jest trochę na pograniczu RODO, trochę na pograniczu zaufania klientów do sklepu, no i po prostu zaplanować jak w takiej sytuacji się zachować, zarówno w kontekście tym prawnym, w kontekście RODO, jak i też jak się zachować w kontekście komunikacji z klientami. No i teraz jak sprawdzić, czy Twój dostawca ma taki plan? Po pierwsze oczywiście zapytać. Jeżeli zadeklaruje, że ma to poprosić o jego przesłanie, udostępnienie tak, żeby można było się z nim zapoznać.

Warto byłoby taki plan też odtworzyć raz na jakiś czas, czyli zasymulować w pewien sposób niedziałanie usługi czy wystąpienie jakiegoś ryzyka. Oczywiście w zależności od tego ile takich ryzyk zostałoby zebranych, które zostaną oszacowane, że faktycznie mają szansę wystąpić bardziej niż mniej, to czy to raz na kwartał czy nawet raz na pół roku takie odtworzenie tego planu i według jakichś określonych kroków sprawdzenie jak by to było odtwarzać usługę. Jeżeli to zrobimy, no to potem jeżeli pojawia się rzeczywiście tego typu sytuacja, to dzieje się to po prostu zdecydowanie szybciej.

No i przede wszystkim odtwarzając taki plan, czyli nie tylko go mając gdzieś na papierze, w jakimś doksie, natomiast też odtwarzając go co jakiś czas, mamy pewność, że ten proces działa i przede wszystkim wiemy też ile on czasu zajmuje, czyli jaka będzie też maksymalna niedostępność tych usług w czasie, gdyby coś się wydarzyło. Można też w ramach takiego uniezależnienia się od obecnego zespołu jako też potencjalnego ryzyka po prostu spróbować odtworzyć te systemy z inną firmą, która byłaby takim planem B w razie wystąpienia ryzyka no właśnie związanego z brakiem obecnego zespołu z jakiegoś powodu. Teraz jak wdrożyć taki plan, czyli co w ramach DRP powinno zostać spisane, zawarte.

Oczywiście to wszystko trzeba dostosować w kontekście danej firmy i zrobić to mocno zdroworozsądkowo. Natomiast spisałem takie pięć najważniejszych rzeczy, którymi chciałbym się tutaj z Wami podzielić. No i przede wszystkim zacząłbym po pierwsze od tego, aby spisać wszelkie ryzyka, jakie przychodzą nam na głowy.

Po drugie to jaki jest ich wpływ na nasz biznes. No i tutaj też wyznaczyłbym priorytety dla owych ryzyk, czyli zastanowiłbym się, które są bardziej prawdopodobne, które mniej. Te bardziej prawdopodobne, czy wydające się jako faktycznie prawdopodobne po prostu bym je weryfikował częściej.

To dla nich bym przygotował to odtworzenie usługi szczególnie. Dla tych bardzo krytycznych, ale też i bardzo mało, mało prawdopodobnych, że tak to ujmę, no to też bym zaplanował ich odtworzenie, ale po prostu rzadziej. No bo to tego nie trzeba robić nawet raz na kwartał, jeżeli ten system może nie działać kilka godzin.

Grunt, żeby to było faktycznie dolne kilka godzin, a nie nagle awaria na 2-3 dni i problem z odtworzeniem backupów, bo na przykład baza danych jest za duża. Stąd na początek ten opis ryzyk. Po drugie opisałbym architekturę systemów i ich priorytetyzację, czyli który system jest najważniejszy.

To w kontekście tego, że odtwarzając te systemy też robi się to z reguły w jakiejś kolejności, bo jeżeli dany system jako cała platforma, cały ekosystem składa się z kilku jakichś aplikacji, kilku mikroserwisów być może, to może się okazać, że nie każdy jednak ma taki sam priorytet, tylko są oczywiście ważne i ważniejsze i te ważniejsze chcielibyśmy odtwarzać jako pierwsze, w związku z czym warto do tego tak podejść. Przykładem tutaj jest to, że właśnie dla e-commerce'u ważniejsze będzie przywrócenie platformy sprzedażowej, aby już sprzedaż działała, klienci mogli dokonywać zakupów. To będzie ważniejsze niż na przykład odtworzenie wewnętrznego systemu do wystawiania faktur, no bo faktury zawsze można wystawić nieco później, a w przypadku poważnej katastrofy, kiedy kompletnie wszystko przestało działać, no to lepiej jest przywrócić sprzedaż, a potem przywrócić formalności typu wystawianie faktur.

Tak bym do tego podszedł. W trzecim punkcie myślę, że sposób reakcji na dane ryzyko, czyli właśnie to, że już mamy ryzyka, wiemy co się może wydarzyć, wiemy też jakie są systemy, no to chcielibyśmy też wiedzieć, w jaki sposób te systemy przywracać w przypadku danego ryzyka, czyli właśnie z kim, w jaki sposób się skontaktować, jak to zgłosić, jak to dalej przetwarzać. W czwartym punkcie plan komunikacji kryzysowej, czyli coś, o co trzeba zadbać, to jest to, kto będzie zarządzał tym kryzysem, w jaki sposób będzie to komunikował, jak będą przebiegały procesy i kto będzie odbierał te wszelkie platformy, systemy po tym, jak one zaczną już działać.

Tu chodzi o taką komunikację zarówno wewnętrzną w zespole, żeby wewnętrznie się sprawnie komunikować i po kolei odhaczać punkty z planu, czy one są faktycznie zrealizowane, ale tu chodzi też o komunikację zewnętrzną, czyli na przykład, kto będzie informował klientów o tym, że nastąpiła jakaś poważna awaria, no ale ona rzeczywiście zostaje lub została rozwiązana, no i też co po kolei się dzieje, tak żeby klienci mieli też taką informację. To szczególnie dla takich usług, gdzie no to zaufanie jest ważne, czyli to może być na przykład firma produktowa, która udostępnia jakiś system i ten system jest dla klientów ważny. Wówczas warto taką informację dawać, to przynajmniej w kontekście takiego kryzysu uspokaja tego klienta, że jakby sytuacja, mimo że się wydarzyła, mimo że jest powiedzmy negatywna, to troszeczkę ocieplamy tym, że ta komunikacja jest na bieżąco i klient przynajmniej wie, jak ta sytuacja jest zarządzona, co się dzieje i kiedy jego system przede wszystkim wróci do normy.

I punkt piąty, to jest sposób przeciwdziałania na co dzień danemu ryzyku. To też warto spisać, że jeżeli da się przeciwdziałać, czyli da się na przykład zainstalować monitoring w tych konkretnych usługach, da się zainstalować na przykład cykliczne backupy czy kopie zapasowe, które będą realizowane na serwer na przykład w innej lokalizacji niż tam, gdzie nasze główne usługi działają czy na przykład to, że z jakiegoś powodu będzie utrzymywany kontakt z dodatkowym zespołem, który w razie czego może też wesprzeć w przypadku tego typu kryzysu czy awarii, no to to są rzeczy, które myślę, że w ramach DRP też warto uwzględnić. Czyli tutaj podsumowując, opis ryzyk, opis architektury systemów, jak będzie zareagowana na dane ryzyko, czyli kto, kiedy i co będzie wykonywał i też w jakiej kolejności, plan komunikacji kryzysowej, zarówno wewnętrznej jak i zewnętrznej no i sposób przeciwdziałania na co dzień danemu ryzyku.

Te pięć rzeczy myślę, że warto w ramach takiego podstawowego planu DRP mieć i to swoje założenie, czyli to, żeby zareagować szybko w przypadku awarii, żeby zminimalizować stratę zwyczajnie się sprawdzi. Podsumowując dzisiejszy odcinek, jeżeli twój biznes jest oparty o dany system, bez którego nie mógłby funkcjonować, to z pewnością warto zadbać o wdrożenie disaster recovery planu. Jeżeli chciałbyś bądź chciałabyś omówić ze mną ryzyka dla twojego biznesu, które mogą wynikać z niedostępności twoich systemów, to chętnie w ramach darmowej konsultacji omówię z tobą owe ryzyka i chętnie też zaproponuję ci możliwe działania w ramach właśnie takiego disaster recovery planu.

Dzięki za wysłuchanie dzisiejszego odcinka. Zachęcam do zostawienia łapki w górę i subskrypcji w miejscu, gdzie aktualnie mnie słuchasz. Chyba, że aktualnie prowadzisz na przykład samochód.

To oczywiście wtedy, kiedy zaparkujesz. I spoilerując kolejny odcinek, będzie to odcinek o tytule refactoring kodu. Dlaczego czasem warto modernizować zamiast budować od nowa.

To będzie odcinek, w którym przyjrzę się zaletom refactoringu kodu, ale przede wszystkim od strony biznesowej. Omówię, jak modernizacja istniejącego systemu może być bardziej opłacalna niż jego całkowite przebudowanie. Chętnie też podzielę się tam przykładami, jak skutecznie przeprowadzić refactoring, aby poprawić wydajność i skalowalność aplikacji, ale też, żeby od strony biznesowej tym refactoringiem faktycznie zarządzić.

Dzięki raz jeszcze za wysłuchanie dzisiejszego odcinka. Do usłyszenia za tydzień we wtorek. Cześć.