Nawet jeśli to powódź, 1C powinien działać! Zgadzamy się z biznesem na DR

Wyobraź sobie: obsługujesz infrastrukturę IT dużego centrum handlowego. W mieście zaczyna padać deszcz. Strumienie deszczu przedostają się przez dach, woda wypełnia lokale handlowe po kostki. Mamy nadzieję, że Twoja serwerownia nie znajduje się w piwnicy, w przeciwnym razie problemów nie da się uniknąć.  

Opisana historia nie jest fantazją, ale zbiorczym opisem kilku wydarzeń roku 2020. W dużych firmach plan odzyskiwania po awarii lub plan odzyskiwania po awarii (DRP) jest zawsze pod ręką w tym przypadku. W korporacjach za to odpowiadają specjaliści ds. ciągłości działania. Jednak w średnich i małych firmach rozwiązywanie takich problemów spada na usługi IT. Musisz sam zrozumieć logikę biznesową, zrozumieć, co i gdzie może zawieść, wymyślić zabezpieczenie i wdrożyć je. 

Świetnie, jeśli specjalista IT może negocjować z biznesem i omawiać potrzebę ochrony. Jednak nie raz widziałem, jak firma skąpiła na rozwiązaniu do odzyskiwania po awarii (DR), ponieważ uważała je za zbędne. Kiedy zdarzył się wypadek, długa rekonwalescencja groziła stratami, a firma nie była gotowa. Możesz powtarzać, ile chcesz: „A nie mówiłem”, ale obsługa IT nadal będzie musiała przywrócić usługi.

Z pozycji architekta podpowiem Ci, jak uniknąć takiej sytuacji. W pierwszej części artykułu pokażę prace przygotowawcze: jak omówić z klientem trzy pytania dotyczące wyboru narzędzi bezpieczeństwa: 

• Co chronimy?
• Przed czym chronimy?
• Jak bardzo chronimy? 

W drugiej części porozmawiamy o możliwościach odpowiedzi na pytanie: jak się bronić. Podam przykłady przypadków jak różni klienci budują swoją ochronę.

Co chronimy: identyfikacja krytycznych funkcji biznesowych 

Przygotowania lepiej rozpocząć od omówienia z klientem biznesowym planu działań pokryzysowych. Główną trudnością jest tutaj znalezienie wspólnego języka. Klientowi zazwyczaj nie zależy na tym, jak działa rozwiązanie IT. Dba o to, aby usługa mogła spełniać funkcje biznesowe i przynosić pieniądze. Na przykład: jeśli strona działa, ale system płatności nie działa, klienci nie mają dochodów, a „ekstremiści” nadal są specjalistami IT. 

Specjalista IT może mieć trudności w takich negocjacjach z kilku powodów:

• Służba IT nie do końca rozumie rolę systemu informatycznego w biznesie. Na przykład, jeśli nie ma dostępnego opisu procesów biznesowych lub przejrzystego modelu biznesowego. 
• Nie cały proces zależy od obsługi IT. Przykładowo, gdy część prac wykonują podwykonawcy, a specjaliści IT nie mają na nich bezpośredniego wpływu.

Strukturyzowałbym rozmowę w ten sposób: 

1. Wyjaśniamy firmom, że wypadki zdarzają się każdemu, a powrót do zdrowia wymaga czasu. Najlepiej jest pokazać sytuacje, jak to się dzieje i jakie są możliwe konsekwencje.
2. Pokazujemy, że nie wszystko zależy od usługi IT, ale Ty jesteś gotowy pomóc w planie działania w swoim obszarze odpowiedzialności.
3. Prosimy Klienta biznesowego o odpowiedź: jeśli nastąpi apokalipsa, który proces powinien zostać przywrócony w pierwszej kolejności? Kto i w jaki sposób bierze w tym udział? 

   Od firmy wymagana jest prosta odpowiedź, na przykład: call center musi kontynuować rejestrację wniosków 24 godziny na dobę, 7 dni w tygodniu.

4. Prosimy jednego lub dwóch użytkowników systemu o szczegółowe opisanie tego procesu. 
   Lepiej zaangażować do pomocy analityka, jeśli Twoja firma go posiada.

   Na początek opis może wyglądać tak: call center przyjmuje zgłoszenia telefonicznie, mailowo i poprzez wiadomości ze strony internetowej. Następnie wprowadza je do 1C za pośrednictwem interfejsu sieciowego i w ten sposób produkcja je stamtąd zabiera.

5. Następnie sprawdzamy, jakie rozwiązania sprzętowe i programowe wspierają ten proces. Dla kompleksowej ochrony bierzemy pod uwagę trzy poziomy: 
   • aplikacje i systemy w ramach serwisu (poziom oprogramowania),   
   • samo miejsce, w którym działają systemy (poziom infrastruktury), 
   • sieci (często o tym zapominają).

6. Znajdujemy możliwe punkty awarii: węzły systemu, od których zależy wydajność usługi. Osobno odnotowujemy węzły obsługiwane przez inne firmy: operatorów telekomunikacyjnych, dostawców hostingu, centra danych i tak dalej. Dzięki temu możesz wrócić do klienta biznesowego i przejść do kolejnego kroku.

Przed czym chronimy: ryzyka

Następnie dowiadujemy się od klienta biznesowego, przed jakimi zagrożeniami w pierwszej kolejności się chronimy. Wszystkie ryzyka można podzielić na dwie grupy: 

• strata czasu spowodowana przestojami w świadczeniu usług;
• utrata danych spowodowana uderzeniami fizycznymi, czynnikami ludzkimi itp.

Firmy boją się utraty zarówno danych, jak i czasu – wszystko to prowadzi do utraty pieniędzy. Zatem ponownie zadajemy pytania dla każdej grupy ryzyka: 

• Czy w przypadku tego procesu możemy oszacować, ile w pieniądzu kosztuje utrata danych i strata czasu? 
• Jakich danych nie możemy stracić? 
• Gdzie nie możemy pozwolić na przestoje? 
• Jakie zdarzenia są dla nas najbardziej prawdopodobne i najbardziej groźne?

Po dyskusji zrozumiemy, jak ustalać priorytety punktów awarii. 

Jak bardzo chronimy: RPO i RTO 

Kiedy krytyczne punkty awarii są jasne, obliczamy wskaźniki RTO i RPO. 

Pamiętam to RTO (docelowy czas regeneracji) — jest to dopuszczalny czas od chwili wypadku do pełnego przywrócenia usługi. W języku biznesowym jest to akceptowalny przestój. Jeśli wiemy, ile pieniędzy przyniósł proces, możemy obliczyć straty z każdej minuty przestoju i obliczyć akceptowalną stratę. 

RPO (cel punktu odzyskiwania) — prawidłowy punkt odzyskiwania danych. Określa czas, w którym możemy utracić dane. Z biznesowego punktu widzenia utrata danych może skutkować na przykład karami finansowymi. Takie straty można również przeliczyć na pieniądze. 

Należy obliczyć czas powrotu do zdrowia dla użytkownika końcowego: jak długo będzie mógł zalogować się do systemu. Najpierw więc sumujemy czas regeneracji wszystkich ogniw w łańcuchu. Często popełniany jest tutaj błąd: pobierają RTO dostawcy z umowy SLA i zapominają o pozostałych warunkach.

Spójrzmy na konkretny przykład. Użytkownik loguje się do 1C, system otwiera się z błędem bazy danych. Kontaktuje się z administratorem systemu. Baza danych znajduje się w chmurze, administrator systemu zgłasza problem usługodawcy. Załóżmy, że cała komunikacja zajmuje 15 minut. W chmurze baza danych tej wielkości zostanie przywrócona z kopii zapasowej w ciągu godziny, dlatego RTO po stronie usługodawcy wynosi godzinę. Nie jest to jednak ostateczny termin, dla użytkownika dodano 15 minut na wykrycie problemu. 
 
Następnie administrator systemu musi sprawdzić, czy baza danych jest poprawna, podłączyć ją do 1C i uruchomić usługi. Wymaga to kolejnej godziny, co oznacza, że ​​RTO po stronie administratora wynosi już 2 godziny i 15 minut. Użytkownik potrzebuje jeszcze 15 minut: zaloguj się, sprawdź, czy pojawiły się niezbędne transakcje. W tym przykładzie całkowity czas przywracania usługi to 2 godziny 30 minut.

Obliczenia te pokażą firmie, od jakich czynników zewnętrznych zależy okres rekonwalescencji. Na przykład, jeśli biuro zostanie zalane, najpierw musisz znaleźć wyciek i go naprawić. To zajmie trochę czasu, który nie jest zależny od IT.  

Jak chronimy: wybór narzędzi dla różnych zagrożeń

Po omówieniu wszystkich punktów klient już rozumie, jaki jest koszt wypadku dla firmy. Teraz możesz wybrać narzędzia i omówić budżet. Na przykładach przypadków klientów pokażę jakie narzędzia oferujemy do poszczególnych zadań. 

Zacznijmy od pierwszej grupy ryzyk: strat spowodowanych przestojami w świadczeniu usług. Rozwiązania tego problemu powinny zapewnić dobry RTO.

1. Hostuj aplikację w chmurze 

   Na początek możesz po prostu przenieść się do chmury – dostawca przemyślał już kwestie wysokiej dostępności. Hosty wirtualizacji są łączone w klaster, zasilanie i sieć są rezerwowane, dane są przechowywane w odpornych na awarie systemach pamięci masowej, a dostawca usług jest odpowiedzialny finansowo za przestoje.

   Można na przykład hostować maszynę wirtualną z bazą danych w chmurze. Aplikacja będzie łączyć się z bazą danych zewnętrznie poprzez ustalony kanał lub z tej samej chmury. Jeśli pojawią się problemy z jednym z serwerów w klastrze, maszyna wirtualna zostanie ponownie uruchomiona na sąsiednim serwerze w czasie krótszym niż 2 minuty. Następnie uruchomi się w nim system DBMS, a za kilka minut baza danych stanie się dostępna.

   RTO: mierzone w minutach. Warunki te mogą zostać określone w umowie z dostawcą.
   Kosztować: Obliczamy koszt zasobów chmurowych dla Twojej aplikacji. 
   Przed czym Cię nie uchroni: z powodu masowych awarii w siedzibie dostawcy, na przykład z powodu wypadków na poziomie miasta.

2. Klastruj aplikację  

   Jeśli chcesz usprawnić RTO, możesz wzmocnić poprzednią opcję i od razu umieścić klastrową aplikację w chmurze.

   Klaster można zaimplementować w trybie aktywny-pasywny lub aktywny-aktywny. Tworzymy kilka maszyn wirtualnych w oparciu o wymagania dostawcy. Aby zapewnić większą niezawodność, dystrybuujemy je na różnych serwerach i systemach pamięci masowej. W przypadku awarii serwera z jedną z baz danych, węzeł zapasowy przejmuje obciążenie w ciągu kilku sekund.

   RTO: Mierzone w sekundach.
   Kosztować: nieco droższe niż zwykła chmura, do klastrowania potrzebne będą dodatkowe zasoby.
   Przed czym Cię nie uchroni: Nadal nie chroni przed poważnymi awariami na miejscu. Jednak lokalne zakłócenia nie będą trwały tak długo.

   Z praktyki: Przedsiębiorstwo handlu detalicznego posiadało kilka systemów informatycznych i stron internetowych. Wszystkie bazy danych znajdowały się lokalnie w biurze firmy. Nie myślano o żadnym DR, dopóki biuro nie zostało kilka razy z rzędu pozbawione prądu. Klienci byli niezadowoleni z awarii witryny. 
    
   Problem z dostępnością usługi został rozwiązany po przejściu do chmury. Dodatkowo udało nam się zoptymalizować obciążenie baz danych poprzez równoważenie ruchu pomiędzy węzłami.

3. Przejdź do chmury odpornej na awarie

   Jeśli chcesz mieć pewność, że nawet klęska żywiołowa na stronie głównej nie zakłóci Twojej pracy, możesz wybrać chmurę odporną na awarie.W tej opcji dostawca rozkłada klaster wirtualizacji na 2 centra danych. Stała replikacja synchroniczna odbywa się pomiędzy centrami danych, jeden do jednego. Kanały pomiędzy centrami danych są zarezerwowane i przebiegają różnymi trasami, więc taki klaster nie boi się problemów z siecią. 

   RTO: ma tendencję do 0.
   Kosztować: Najdroższa opcja w chmurze. 
   Przed czym Cię nie uchroni: Nie pomoże to w zapobieganiu uszkodzeniu danych, a także czynnikowi ludzkiemu, dlatego zaleca się jednoczesne wykonywanie kopii zapasowych. 

   Z praktyki: Jeden z naszych klientów opracował kompleksowy plan odzyskiwania danych po awarii. Oto strategia, którą wybrał: 

   • Chmura odporna na awarie chroni aplikację przed awariami na poziomie infrastruktury. 
   • Dwupoziomowa kopia zapasowa zapewnia ochronę w przypadku błędu ludzkiego. Istnieją dwa rodzaje kopii zapasowych: „zimne” i „gorące”. „Zimna” kopia zapasowa jest wyłączona, a jej wdrożenie wymaga czasu. „Gorąca” kopia zapasowa jest już gotowa do użycia i można ją szybciej przywrócić. Przechowywana jest na specjalnie dedykowanym systemie magazynowania. Trzecia kopia jest nagrywana na taśmę i przechowywana w innym pomieszczeniu. 

   Raz w tygodniu klient testuje ochronę i sprawdza funkcjonalność wszystkich kopii zapasowych, także tych z taśmy. Co roku firma testuje całą chmurę odporną na awarie. 

4. Zorganizuj replikację do innej lokacji 

   Inna opcja uniknięcia globalnych problemów na stronie głównej: zapewnienie rezerwacji geograficznej. Innymi słowy, utwórz kopie zapasowe maszyn wirtualnych w lokalizacji w innym mieście. Nadają się do tego specjalne rozwiązania dla DR: w naszej firmie korzystamy z VMware vCloud Availability (vCAV). Za jego pomocą możesz skonfigurować ochronę pomiędzy kilkoma witrynami dostawców usług w chmurze lub przywrócić dane do chmury z witryny lokalnej. Opowiadałem już bardziej szczegółowo o schemacie pracy z vCAV tutaj. 

   RPO i RTO: od 5 minut. 

   Kosztować: droższe niż pierwsza opcja, ale tańsze niż replikacja sprzętu w chmurze odpornej na awarie. Na cenę składa się koszt licencji vCAV, opłaty administracyjne, koszt zasobów chmurowych oraz zasoby rezerwowe według modelu PAYG (10% kosztu zasobów roboczych dla wyłączonych maszyn wirtualnych).

   Z praktyki: Klient trzymał 6 maszyn wirtualnych z różnymi bazami danych w naszej chmurze w Moskwie. Początkowo ochronę zapewniały kopie zapasowe: część kopii zapasowych była przechowywana w chmurze w Moskwie, a część w naszej lokalizacji w St. Petersburgu. Z biegiem czasu bazy danych rosły, a przywracanie z kopii zapasowej zaczęło zajmować więcej czasu. 
    
   Do kopii zapasowych dodano replikację w oparciu o dostępność VMware vCloud. Repliki maszyn wirtualnych przechowywane są na stronie zapasowej w St. Petersburgu i aktualizowane są co 5 minut. Jeśli w siedzibie głównej wystąpi awaria, pracownicy samodzielnie przełączają się na replikę maszyny wirtualnej w St. Petersburgu i kontynuują z nią pracę. 

Wszystkie rozważane rozwiązania zapewniają wysoką dostępność, ale nie chronią przed utratą danych na skutek wirusa ransomware lub przypadkowego błędu pracownika. W takim przypadku będziemy potrzebować kopii zapasowych, które zapewnią wymagany RPO.

5. Nie zapomnij o kopii zapasowej

Każdy wie, że trzeba tworzyć kopie zapasowe, nawet jeśli masz najfajniejsze rozwiązanie odporne na awarie. Przypomnę więc pokrótce kilka punktów.

Ściśle mówiąc, kopia zapasowa nie jest DR. I własnie dlatego: 

• To długi czas. Jeśli dane są mierzone w terabajtach, odtworzenie zajmie więcej niż godzinę. Musisz przywrócić, przypisać sieć, sprawdzić, czy się włącza, sprawdzić, czy dane są w porządku. Możesz więc podać dobry RTO tylko wtedy, gdy jest mało danych. 
• Dane mogą nie zostać przywrócone za pierwszym razem i należy zarezerwować czas na powtórzenie czynności. Na przykład czasami nie wiemy dokładnie, kiedy dane zostały utracone. Załóżmy, że stratę zauważono o godzinie 15.00, a kopie wykonywane są co godzinę. Od 15.00 sprawdzamy wszystkie punkty odzyskiwania: 14:00, 13:00 i tak dalej. Jeśli system jest ważny, staramy się minimalizować wiek punktu przywracania. Jeśli jednak świeża kopia zapasowa nie zawierała niezbędnych danych, przechodzimy do następnego punktu - jest to dodatkowy czas. 

W takim przypadku harmonogram tworzenia kopii zapasowych może zapewnić wymagane RPO. W przypadku kopii zapasowych ważne jest zapewnienie rezerwacji geograficznej na wypadek problemów z witryną główną. Zaleca się przechowywanie niektórych kopii zapasowych osobno.

Ostateczny plan odzyskiwania po awarii powinien zawierać co najmniej 2 narzędzia:  

• Jedna z opcji 1-4, która zabezpieczy systemy przed awariami i upadkami.
• Kopia zapasowa chroniąca dane przed utratą. 

Warto zadbać także o zapasowy kanał komunikacji na wypadek awarii głównego dostawcy Internetu. I - voila! — DR przy płacy minimalnej jest już gotowy. 

Źródło: www.habr.com