BIA – czyli jak uniknąć pułapek SLA

Parametry dostępności w SLA określają teoretyczną dostępność, która może być wyliczana w odniesieniu do: ryzyka biznesowego ewentualnych skutków awarii, technicznego prawdopodobieństwa ryzyka awarii lub wypadkowej czynników biznesowego i technicznego. Warto nadmienić, że część dostawców w ogóle nie prowadzi analiz ryzyka, a jedynie dostosowuje ofertę do standardów rynkowych – przez co oferowana dostępność może być jedynie deklaracją bez pokrycia (na szczęście nie dotyczy to głównych graczy rynku chmurowego).

Teoretyczna dostępność odnosi się osobno do każdego z komponentów usługi. Przykładowo, jeżeli usługa działa w oparciu o trzy elementy, gdzie dostępność wynosi odpowiednio: baza danych - 99,5%, firewall – 99,5%, serwer aplikacyjny – 99,9%, wówczas teoretyczna dostępność całej platformy wyniesie 99,5 x 99,5 x 99,9 = 98,9%. Przy 99,5%, dopuszczalna miesięczna niedostępność wynosi 3,6h (216 min) – za to przy 98,9% jest to już ponad 2x więcej (7,92h = 475 min).

Dostawcy gwarantują przywrócenie dostępności poszczególnych komponentów technicznych, a nie usług biznesowych. W szczególnych przypadkach, gdy np. w wyniku zaniku zasilania, zatrzymane zostaną wszystkie komponenty techniczne usług, przywrócenie ich dostępności nie jest równoznaczne z przywróceniem dostępności całej usługi biznesowej. Czasami konieczna może okazać się interwencja administratora, która po pierwsze może wymagać czasu na reakcję, a po drugie operacja przywracania usługi również może trwać dłuższy czas. Przywrócenie technicznej dostępności wszystkich komponentów usługi przez dostawcę w czasie określonym w SLA, niezależnie od tego, czy dana usługa na platformie dostawcy działa czy nie, wyczerpuje odpowiedzialność dostawcy.

Dostawcy (zazwyczaj) nie gwarantują bezstratnego przywrócenia komponentów usługi. Oznacza to, że dostawca może przywrócić komponent do stanu sprzed kilku - kilkunastu minut (dopuszczalna strata jest zazwyczaj określona w parametrze RPO – Recovery Point Objective). O ile dla większości serwerów aplikacyjnych taka drobna utrata danych nie ma większego znaczenia, o tyle dla np. baz danych może mieć poważne skutki biznesowe. Przykładowo, dla firmy generującej kilkaset dokumentów na godzinę (np. zamówienia, faktury, przesunięcia magazynowe, wydania z magazynu, dokumenty spedycyjno-logistyczne, itp.), wysyłanych do kanałów zewnętrznych (np. przez interfejsy do innych systemów korporacyjnych, firm spedycyjnych), niezmiernie trudne będzie dokładne ustalenie dokładnej listy dokumentów, które zniknęły z bazy danych w wyniku awarii, ale wcześniej zostały dostarczone do odbiorców (systemów zewnętrznych). Na szczęście są sposoby, żeby się przed tym zabezpieczyć (ale o tym kolejnych odcinkach blogu architektonicznego).

Kary za niedotrzymanie SLA (zazwyczaj) wyrażane są w „redukcji opłaty miesięcznej” za komponenty usługi. Należy udzielić sobie odpowiedzi na pytanie, na ile ewentualna kara zrekompensuje nam straty biznesowe, nie tylko bezpośrednie, ale również wizerunkowe, relacyjne. Redukcja opłaty miesięcznej prawie nigdy nam tego nie zapewni. Z drugiej stron, zgoda dostawcy na wyższe kary, pokrywające rzeczywiste straty biznesowe, zawsze okupiona będzie proporcjonalnie wyższą ceną usługi (dostawca przecież musi zrekompensować sobie dodatkowe ryzyko).

Ewentualny czas niedostępności jest (zazwyczaj) mierzony od momentu zarejestrowania zgłoszenia, czyli momentu skutecznego poinformowania dostawcy o zdiagnozowanych problemach. Jeżeli zgłosimy awarię np. godzinę po jej faktycznym wystąpieniu, z punktu widzenia warunków umowy, czas niedostępności liczy się od chwili zgłoszenia. Inną trudnością jest kontakt z dostawcą w chwili awarii – często jest to komunikacja jednostronna. Kto próbował skontaktować się z operatorem usługi w przypadku rozległej awarii wie, że nie jest to takie proste. O ile jeszcze wysłanie zgłoszenia najczęściej jest możliwe (ew. otrzymanie potwierdzenia mailowego przyjęcia zgłoszenia), o tyle ustalenie bieżącego statusu naprawy i przewidywanego czasu przywrócenia usługi, zazwyczaj rodzi spore trudności.

Dostawcy stosują w umowach liczne zapisy, które ograniczają ich odpowiedzialność za brak działania lub nieprawidłowe działanie komponentów usługi. Warto więc dokładnie zapoznać się z warunkami świadczenia usługi, żeby w razie awarii nie okazało się, że nie mamy ani działającej usługi, ani możliwości odzyskania danych, ani możliwości kierowania roszczeń wobec dostawcy (gdyż konsekwencje danego zdarzenia zostały wyłączone z odpowiedzialności dostawcy).

Dostawcy (zazwyczaj) nie odpowiadają za bezpowrotną utratę danych. Zabezpieczenie danych przed utratą (uszkodzeniem, naruszeniem integralności), jest w zasadzie zawsze wyłączone z zakresu usług – to w naszej gestii jest takie zaprojektowanie architektury usług, aby zabezpieczyć się przed bezpowrotną utratą danych. Wyjątek stanowi usługa nadzorowanych kopii zapasowych (ang. managed backup), gdzie możemy precyzyjnie uzgodnić parametry RTO (maksymalny czas przywrócenia usługi) i RPO (maksymalną, akceptowalną utratę danych), a także (co jest bardzo zalecane) zobowiązać dostawcę do prowadzania regularnych testów odtworzeniowych (co oczywiście kosztuje). Należy mieć również świadomość ograniczeń technologicznych. Backup zawsze zakłada RPO<0, czyli mniejszą lub większą stratę danych (część operacji/danych zostanie utracona – dla kopii zapasowych dziennych, strata może wynieść nawet 24h). Ponadto odtworzenie danych z kopii zapasowej wymaga czasu – na przygotowanie platformy oraz na przywrócenie danych, co w przypadku dużych zbiorów danych kilkaset GB może trwać kilka godzin, a kilku - kilkudziesięciu TB – nawet kilkadziesiąt godzin (czas ten można znacząco skrócić, jeżeli właściwie zostanie zaprojektowana architektura usługi – o czym w kolejnych odsłonach naszego bloga). Należy także pamiętać, że w trakcie odtwarzania usługi są niedostępne.

Rzadko negocjuje się umowy z dostawcami chmury. W przypadku globalnych operatorów chmury, jedynie najwięksi klienci instytucjonalni lub korporacyjni mają możliwość negocjacji parametrów SLA. Mniejsi operatorzy chmury są bardziej elastyczni w zakresie dopasowania oferty (SLA) do szczegółowych wymagań klientów. Niestety nawet w tym przypadku znakomita większość klientów w pierwszej kolejności kieruje się ceną usług – przyjmując „domyślne” parametry SLA, często lepiej zabezpieczające interes dostawcy niż klienta.
Jak widać, pułapek jest wiele. Pojawia się więc pytanie, jak się przed nimi zabezpieczyć? Jednym ze sposobów jest przeprowadzenie analizy podatności i skutków braku dostępności lub utraty poszczególnych usług na działalność biznesową – w skrócie BIA (Business Impact Analysis).

W analizie BIA, dostępność usług powinna być postrzegana z perspektywy ich dostępności dla użytkowników biznesowych, którzy z nich korzystają, a nie teoretycznej dostępności technicznej. To, że po awarii dostawca uruchomił ponownie wszystkie serwery wirtualne, wcale nie musi oznaczać, że wszystkie usługi biznesowe będą działały poprawnie. Z tego powodu, w ramach planowania ciągłości działania, usługi biznesowe powinny zostać zdekomponowane na krytyczne elementy architektury IT – te komponenty, których uszkodzenie (niedostępność) może doprowadzić do przerwania dostępności usługi biznesowej.

Prawo Murphy’ego głosi, że jeżeli coś w teorii może zawieść, to w krytycznym momencie na pewno zawiedzie. Dlatego podczas przewidywania ewentualnych skutków awarii, warto wziąć pod uwagę „najczarniejszy” scenariusz, który będzie miał dla nas najbardziej poważne skutki, np. całkowite zniszczenie centrum danych (np. na skutek pożaru) w trakcie świątecznego szczytu zakupowego.

Architekturę usług należy więc projektować w taki sposób, aby przywrócenie dostępności usług mogło nastąpić w czasie akceptowalnym przez biznes, gdzie dostępność usług powinna być postrzegana w kontekście najbardziej krytycznego okresu w roku/miesiącu, czyli okresu, gdy potencjalne konsekwencje niedostępności usług będą najbardziej bolesne dla biznesu (np. okres przedświąteczny w przypadku firm handlowych lub spedycyjnych). Dla wszystkich komponentów krytycznych należy ustalić parametry: oczekiwanej dostępności (ew. akceptowalnej niedostępności) oraz akceptowanego poziomu utraty danych (konsekwencji biznesowych utraty operacji/transakcji, np. z ostatniej doby, ostatniej godziny, minuty).

Na koniec należy zaprojektować adekwatne zabezpieczenia dla każdego krytycznego elementu infrastruktury, w wymiarze: ochrony przed utratą dostępności usługi oraz bezpowrotnej utraty danych (całkowitej utraty lub utraty danych np. z ostatniej godziny/doby). Adekwatne zabezpieczenia to takie, których koszt wdrożenia nie przekracza kosztów ewentualnych skutków biznesowych awarii (braku dostępności i utraty danych), ale które równocześnie zapewniają zakładaną dostępność usługi biznesowej oraz jej integralność (czyli akceptowalną biznesowo utratę danych). W kolejnych artykułach naszego blogu postaramy się przybliżyć zabezpieczenia techniczne i organizacyjne, które można zastosować, aby lepiej zabezpieczyć nasze usługi biznesowe.

Podsumowując, kluczem do zapewnienia bezpieczeństwa kluczowych usług biznesowych w zakresie ich dostępności (ciągłości działania) oraz integralności (bezpowrotnego uszkodzenia lub utraty danych) jest zrozumienie architektury IT. Dopiero, gdy rozpoznamy i zrozumiemy architekturę naszych usług, będziemy w stanie wypracować adekwatne środki techniczne i organizacyjne, aby właściwie zabezpieczyć się na wypadek różnego rodzaju awarii.