Viability sp. z o.o.

Od kogo DRaaS w Polsce? Lista dostawców DRaaS

31 lipca 201820 grudnia 2021

Od pierwszego zestawienia dostawców DRaaS w Polsce minęły ponad 3 lata. Od tego czasu, przybyło nowych usługodawców, a lista doczekała się 3 aktualizacji. Najnowszy wpis z 19 grudnia 2021 znajdziecie tutaj.

Poniżej oryginalny artykuł z 31 lipca 2018.

Lista ta powstała w bólach. Znalezienie polskiego dostawcy DRaaS gotowego do natychmiastowego świadczenia usługi nie jest łatwe. Najpierw trzeba odszukać tych, którzy wiedzą o czym mówią. Następnie wyłuskać nielicznych, którzy mają gotowe usługi. Chwilami z badacza zmieniałem się w detektywa. W efekcie lista jest krótka, a na dodatek wcale nie miała powstać…

Klient wrzucił mnie na minę. Zostałem poproszony o wsparcie w procesie wyboru dostawcy DRaaS (Disaster Recovery as a Service). Szczerze, od razu podałem kandydata. Klient jednak chciał sam dokonać wyboru. Potrzeba trzech dostawców. Pomyślałem, że to banał. A potem zaczęła się jazda. I tak, niejako mimochodem, powstał pomysł sporządzenia listy dostawców DRaaS w Polsce.

Ważna rzecz – kryteria wyboru. Prowadzony projekt dostarczył mi inspiracji. Oto klient chciał by dostawcy byli krajowi oraz by zastosowanie miało nasza polska legislacja. Najważniejsze jednak, aby przetwarzanie danych było w granicach RP – czyli DRaaS w polskiej chmurze. Drugie kryterium to gotowość do świadczenia usługi. Tylko dostawcy, którzy deklarowali, że są w stanie w ciągu 48h udostępnić usługę do testów trafili na listę. Chodziło o to by wyłonić usługodawców mających gotowe środowisko w architekturze wielu najemców. Oferty takich firm istotnie różnią się cenowo od propozycji dostawców projektowych.

Dla porządku muszę też napisać, że praktycznie każde centrum danych może zaoferować usługę centrum zapasowego (DRC, DR Site), a czasem także wirtualnego centrum zapasowego (VDRC). Ten zakres usług to jednak nie SaaS (poziom aplikacji), czyli nie DRaaS. To w zasadzie wynajęcie miejsca w szafach (kolokacja), transmisja danych oraz najem sprzętu, i/lub licencji. To tradycyjne podejście do odtwarzania po awarii, podejście kosztowniejsze.

Nie wszystko złoto co się świeci. Proszę się nie dziwić, że w zestawieniu nie ma wielu rynkowych graczy. Owszem, o usługach z zakresu Disaster-recovery piszą prawie wszyscy, jest to jednak bardziej działanie policzone na zyskanie ruchu organicznego w wyszukiwarce Google (SEO), niż faktyczna oferta. W internecie znaleźć można też dostawców, którzy niefrasobliwie miksują definicje (o tym tutaj), niestety to także utrudnia zadanie poszukującym dostawcy konkretnej usługi.

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.

Chmura publiczna czy własne zasoby IT? A może to i to, czyli hybryda?

31 października 201717 listopada 2020

Prędzej czy później każdy stanie w obliczu wyboru – wynajmować czy kupować. Ciekawe, że decyzje zwykle zapadają w oparciu o różne obliczenia. Pytanie tylko, czy całkowity koszt posiadania (TCO) powinien być jedynym kryterium wyboru? Poza tym, czy aby na pewno dobrze porównujemy koszty, a więc czy porównujemy „jabłka do jabłek”? Na koniec, czym jest właściwie hybryda w przypadku chmury?

Decyzja o tym co wybrać, zawsze zależna powinna być od kontekstu, czyli od zadań jakie stawiamy przed systemami IT. Przykładowo, jeśli priorytetem jest szybki dostęp do bazy danych lub aplikacji dla potrzeb dużego zespołu lokalnego, a architektura rozwiązania jest sprzed kilku lat (najczęściej klient-serwer), wówczas trzymanie serwerów w siedzibie firmy ma uzasadnienie. Inaczej jest w przypadku zastosowań Internetowych. Jeśli do naszych systemów mają sięgać rozproszeni terytorialnie pracownicy, klienci albo partnerzy. Jeśli metodą dostępu będzie przeglądarka internetowa lub aplikacja na smartfona, wówczas umiejscowienie serwerów czy też wirtualnych maszyn w centrum danych operatora, jest lepszym rozwiązaniem.

Porównanie TCO, to następny krok. Dlaczego chmura publiczna w arkuszu kalkulacyjnym kosztuje więcej niż własne zasoby IT? W tym miejscu zazwyczaj umyka nam, że chmura publiczna to cały szereg składowych. Nie pamiętamy o nich, bo nie przypisujemy ich do operacji IT. Porównując TCO, uwzględnijmy zatem następujące koszty:

zaangażowanego kapitału (inwestycja);
utrzymania, konserwacji i napraw sprzętu sieciowego i serwerowego;
licencji oraz opłat utrzymaniowych;
pracy własnego zespołu lub usług obcych związanych z utrzymaniem sprzętu oraz administracji warstwą wirtualizacji czy systemów operacyjnych;
utrzymania serwerowni, w tym:

utrzymanie, konserwacje i naprawy systemu zasilania awaryjnego,
konserwacje i naprawy klimatyzacji,
zużycie energii elektrycznej przez sprzęt IT oraz urządzenia infrastruktury serwerowni,
ubezpieczenie majątku.

A co z gdyby połączyć jedno z drugim? Czyli, nadal utrzymywać trochę zasobów informatycznych u siebie lokalnie, szczególnie tych do których dostęp musi być bardzo szybki. Równolegle korzystać z wybranych usług chmury publicznej, np.: w zakresie ciągłości działania (DRaaS, BaaS), czy kolokacji albo najmu wirtualnych serwerów (IaaS)? Jak się okazuje, to częsta praktyka, która być może stanie się standardem. Zgodnie z definicją, to chmura hybrydowa, czyli połączenie własnego środowiska informatycznego (serwerów) z chmurą publiczną usługodawcy.

Cena dostępności, czyli ile kosztuje DRaaS?

13 kwietnia 201717 listopada 2020

Pytanie o cenę DRaaS pada najczęściej od razu, „bez gry wstępnej”. Niestety, aby odpowiedzieć, potrzebujemy zmiennych. W tym krótkim artykule zastosuję zatem fortel i sam wymyślę parametry usługi. Innymi słowy, na podstawie serii założeń stworzę przykładową ofertę. W efekcie pokażę, ile kosztuje DRaaS w Polsce.

Najpierw trochę teorii. DRaaS ma trzy stany: gotowości, tryb awaryjny (failover), powrót po awarii (failback). Piszę o tym, bo dwa pierwsze stany kształtują cenę usługi. W trybie gotowości zachodzi stałe replikowanie serwerów, danych i ustawień do centrum danych usługodawcy. To bardzo ważna część zadania i mamy jej konsekwencje w wycenie. Wartość usługi musi uwzględnić: transmisję, składowanie danych oraz tzw. stos technologiczny obsługujący te procesy. W trybie awaryjnym, nasze środowisko IT uruchamiane zostaje u dostawcy DRaaS. Wówczas pojawiają się dodatkowe zmienne, gdyż to, co dotąd było tylko „uśpioną” repliką, staje się pełnowartościowym serwerem. Uruchomienie tych maszyn powoduje, że dostawca zechce rozliczyć się z nami z zaangażowanej mocy obliczeniowej oraz będzie musiał uiścić stosowne opłaty licencyjne, np. do Microsoft.

Pozostaje jeszcze ważny parametr czasu. Przed uruchomieniem DRaaS trzeba zdecydować jakiej długości przestój w następstwie poważnej awarii jesteśmy w stanie zaakceptować – to tzw. RTO (Recovery Time Objective). Niestety, musimy też od razu przyjąć z jaką utratą danych możemy się pogodzić, czyli niejako, o ile cofniemy się w czasie, gdy nasze serwery i dane ulegną zniszczeniu – mowa o RPO (Recovery Point Objective). Uwaga, jeśli Twoja organizacja nie może zaakceptować jakiejkolwiek utraty danych, potrzebna jest wyższa półka rozwiązań i na mój nos, nie ma innej drogi niż zdublowanie zasobów informatycznych.

Dobra, a teraz mięsko 😊. Firma XYZ posiada następujące zasoby informatyczne:

Zestawienie zasobów krytycznych do wyceny DRaaS w Polsce

Przy takim środowisku, miesięczna wartość abonamentu za DRaaS dla RPO/RTO 15 min, wynosi 1430 zł netto. Jeśli wymagane będzie przełączenie w tryb awaryjny, wówczas poniesiemy dodatkowy koszt 4737 zł (za 30 dni). Ciekawostka, jeśli tryb failover zdarzy się nie częściej niż raz na kwartał, a czas przełączenia nie przekroczy 10 dni, koszt spadnie do 1 100 zł netto (u rzetelnych dostawców). Czy to drogo, czy tanio? To zależy od kosztu przestoju.

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)?”