Kontrakt na usługi Cloud

Data: 2016-09-19
Autor: Sebastian Konkol
Kontrakt na usługi Cloud

W przypadku usług chmurowych tradycyjne opcje build / reuse / buy redukują się wyłącznie do buy. Domykając już chyba mini serię o Cloud Computing, kilka porad na temat konstrukcji umowy z dostawcą usług chmurowych.

Dla każdego, kto kupuje usługę SaaS / PaaS / IaaS po raz pierwszy – a nawet dla części z tych, którzy już takich zakupów dokonywali – poważnym zaskoczeniem są konsekwencje faktu kupowania usługi, a nie produktu. I nie chodzi tu o to, że kupując usługę wykorzystujemy OPEX, a nie CAPEX. Chodzi tu raczej o to, że przyzwyczajeni do kupowania produktów stawiamy duże wymagania na weryfikację produktu zanim za niego zapłacimy. W przypadku usług nie zweryfikujemy niemalże niczego przed rozpoczęciem korzystania z usługi, czyli zaciągnięciem zobowiązania finansowego. Musimy więc umieć weryfikować działanie usługi w trakcie korzystania z niej. „To przecież oczywiste” – ja też tak uważam. Tylko dlaczego tak rzadko wykorzystywane w realnych przypadkach?

Jeśli kupujesz usługę IaaS, to myślisz o elastycznym ekwiwalencie serwera i skupiasz się zwykle na tym, że zapłacisz wyłącznie za wykorzystane zasoby takiego uelastycznionego serwera. W przypadku usług IaaS fakt, że zapłacisz wyłącznie za wykorzystane zasoby nie oznacza, że będą dostępne one w takim zakresie, w jakim będą potrzebne. Co Ci po tym, że dostaniesz 30 jednostek (np. mocy obliczeniowej) i zapłacisz za te 30 jednostek, jeśli do robienia Twojego biznesu potrzebowałeś 50 jednostek? Rzecz jasna, odpowiedzią jest SLA, które – poza tradycyjnymi wymogami dotyczącymi wydajności, dostępności czy czasu odpowiedzi – powinno określać także zagadnienia skalowania zasobów i stabilności działania. Skalowanie jest potrzebne po to, aby znać charakterystykę odpowiedzi dostawcy usługi IaaS na wzrost (lub zmniejszenie) obciążenia. Powinien się dostosowywać szybko, bo inaczej Twój biznes będzie cierpiał. Stabilność działania jest potrzeba po to, żeby dostawca usług IaaS nie „obcinał Ci” zasobów w sytuacji, w której takich zasobów potrzebujesz i je wykorzystujesz. Takie SLA – jako uzupełnienie do definicji usługi IaaS – to podstawa kontraktu. Na takim SLA daje się określać realnie egzekwowalne kary umowne.

Jeśli kupujesz usługę SaaS, to myślisz o funkcjonalności aplikacji dostępnej w modelu subskrypcji. Co Ci jednak po subskrypcji, w ramach której otrzymasz usługę o funkcjonalności działającej błędnie? Ponieważ to usługa, nie masz możliwości „pogrzebania” wewnątrz systemu świadczącego tę usługę. Jedyne, co możesz zrobić, to odnieść SLA do efektów biznesowych realizacji usługi – wpływu na Twój biznes. Na tym oprzyj kary umowne.

Zapisanie czegokolwiek w SLA to jedno, a zdolność identyfikacji sytuacji złamania SLA – to drugie. Jeśli nie będziesz w stanie obiektywnie identyfikować sytuacji naruszenia SLA, całe Twoje kary umowne będą nic nie wartymi zapisami. Potrzebujesz monitorowania usług i możliwości mierzenia parametrów określających jakość usługi. Idealnie jest, kiedy taki pomiar wykonywany jest u Ciebie, na podstawie możliwie jak najbardziej podstawowych danych od usługodawcy. Nie zawsze jest to jednak możliwe – czasami monitoring usługi dostarcza także dostawca usługi monitorowanej. Co do zasady nie jest to złe wyjście, o ile będziesz w stanie „wywołać” naruszenie SLA. Powinieneś je stosować trochę jak „tajemniczego pacjenta” do badania standardów obsługi w placówkach medycznych – indukujesz naruszenie SLA i patrzysz, czy zostanie zaraportowane.

Bez względu na to, jak monitorujesz usługę, sytuacja błędnego działania może się pojawić. Dla takich sytuacji powinieneś być wyposażony kontraktowo w możliwość zgłoszenia błędu i oczekiwania naprawienia go. Zarówno błędy jak i oczekiwania naprawy powinny być wyrażone w odniesieniu do biznesu wspomaganego przez usługę chmurową, nie do funkcjonalności usługi. W takich warunkach konsekwencje biznesowe błędów powinny być odzwierciedlone w karach umownych wynikających z błędów działania usługi. Do tego powinieneś także dysponować wszystkimi procesami obsługi usługi, znanymi choćby z ITIL: incydent, zmiana, komunikacja o awariach i planowanych przerwach, rekonfiguracja usługi na Twoje żądanie i zmiany funkcjonalne usługi chmurowej, które po prostu zachodzą.

Oddzielną sprawą są zagadnienia bezpieczeństwa – od danych, przez ciągłość biznesu, aż po zgodność z prawem. W sferze bezpieczeństwa danych sugeruję nakazać kontraktowo stosowanie odpowiednich standardów oraz opisać w kontrakcie zasady i procedury zapewnienia bezpieczeństwa danych wraz z uprawnieniem do okresowej weryfikacji (audytu) szczelności systemu zabezpieczeń. Audyt wykazujący nieszczelności = kary umowne. Ciągłość działania – tak samo, jak funkcjonalność usługi – powinny być oceniane wyłącznie na poziomie konsekwencji biznesowych realizacji usługi. Zarówno określenie sposobu oceny ciągłości biznesu jak i stanu odtworzenia po zaburzeniu ciągłości powinny być wyrażone w kategoriach wpływu biznesowego, a parametry określające proces odtworzenia (RPO, RTO) powinny odnosić się do efektów biznesowych, nie funkcjonalności usługi. Zgodność sposobu świadczenia usługi chmurowej z prawem to temat dla prawników specjalizujących się w nieuczciwej konkurencji, danych osobowych i wrażliwych, czy własności intelektualnej. Szczególnie wartościowym byłoby przeniesienie odpowiedzialności za bezpieczeństwo danych i ich przetwarzania (osobowe, wrażliwe, tajemnica przedsiębiorstwa) na grunt prawa zamawiającego usługę, a nie świadczącego ją. Poza zapisami określającymi zobowiązanie do przestrzeganie takich praw (zarówno legislacja PL jak i UE), warto zapisać zobowiązanie do zapewnienia zgodności ze zmianami legislacji, jakie będą zachodzić podczas obowiązywania kontraktu.

Na koniec zagadnienie licencyjne – korzystanie z usługi chmurowej. Warunki licencyjne zwykle mogą się zmieniać, więc warto określić zasady, na jakich jest to możliwe. Szczególnie w sferze cenników warto ograniczyć możliwość wzrostu cen z powodu przybywania nowych, „lepszych” wersji usługi. Warto także obwarować rozszerzenie funkcjonalne zgodą użytkownika usługi – takie częste rozszerzenia mogą wprowadzić stan permanentnego uzależnienia usługobiorcy od usługodawcy, uniemożliwiające mu wyjście z kontraktu. Poza tym obowiązują wszystkie zasady robienia zdrowego biznesu – jeśli umawiasz się na dłuższy okres, oczekuj więcej od usługodawcy.

 

Skorzystasz z tych porad, czy nie skorzystasz – zastanów się nad Twoim kontraktem chmurowym. Choć nie wyczerpują one listy zagadnień i są – siłą rzeczy – dość ogólne, być może natchną Cię jakąś ważną myślą w odniesieniu do Twojego kontaktu chmurowego. Bez wątpienia, kontraktowy diabeł tkwi w kontraktowych szczegółach.

Pozostaw komentarz