Přechod do cloudu

Zřejmě málokterý objednatel si může dovolit ten luxus, aby si svou infrastrukturu bez jakýchkoliv příprav a prozatímních fází umístil do cloudu. V praxi tomu bývá právě naopak, zvláště u větších firem. Taková firma disponuje vlastním hardwarem, má sjednány složité síťové licence a obvykle má více dodavatelů IT služeb, od implementátorů systémového softwaru přes správce sítě až po dodavatele jednotlivých aplikací. Z ekonomických důvodů nebude obvykle možné vyřadit stávající hardware a přestat využívat software, který byl pořízen za částky v řádech milionů korun. Samostatnou kapitolou jsou databáze a množství dat.
Samotný přechod na cloudové řešení proto vyžaduje předchozí analýzu, samotný přechod probíhá v několika krocích. Jednou z variant je využít stávající části infrastruktury a provést migraci hardwaru a dat, jak o ní psal můj kolega Lukáš Jansa v minulém čísle 10/2011 časopisu IT Systems.
Ale i když je migrace zdárně ukončena, obvykle je nutno provést další úpravy celé infrastruktury, tuto doplnit o nový hardware a nainstalovat vybraný software včetně jeho nastavení (tentokrát již v datovém centru provozovatele), které je nezbytné pro to, aby mohl provozovatel převzít garanci za sjednanou úroveň dostupnosti služeb v plném rozsahu. Tento proces byl ve smlouvě označen jako „transformační projekt“.
V popisovaném případě byl postup následující:

1. analýza (vyústila v závěr provést migraci do datového centra a realizovat jednotlivé transformační projekty),
2. příprava smluv o migraci i o samotném outsourcingu služeb IT,
3. provedení migrace (fyzický převoz hardwaru do datového centra a jeho opětovné spuštění a vyzkoušení),
4. započetí poskytování sjednaných outsourcovaných služeb IT v přechodném režimu,
5. provedení transformačních projektů ze strany provozovatele,
6. náběh na poskytování sjednaných služeb IT v ostrém režimu, tj. s nejvyšší garantovanou úrovní dostupností ze strany provozovatele.

Smlouva, na základě které bylo vše zrealizováno (s výjimkou migrace, která byla upravena zvláštní smlouvou), musela tedy obsahovat:

• závazek provozovatele provést jednotlivé transformační projekty, což má povahu smlouvy o dílo – provozovatel se zavázal dodat ve sjednaném termínu potřebný software, případně i hardware a provést implementaci,
• závazek k poskytování sjednaných služeb, který má povahu smlouvy nepojmenované (inominátní) – provozovatel se zavázal poskytovat specifikované služby dle sjednaných parametrů úrovně dostupnosti a provádět servisní služby a řešení incidentů.

Je to cloud computing, nebo ne?

Možná jste zaznamenali, že jsem zatím pojem cloud používal velmi sporadicky. Namísto toho se v textu objevuje často pojem outsourcovaná IT služba. S ohledem na specifika celého popisovaného procesu jsme i při tvorbě smlouvy samotné naráželi často na problém, jakou terminologii používat, abychom se nedopouštěli užívání zavádějících pojmů. S ohledem na nutnost využít stávající hardware i systémový software objednatele proto nejde v první fázi o „čistokrevný“ cloud, nýbrž skutečně o outsourcing (a možná od každého trochu). Provozovatel totiž v daném případě jednak poskytuje správu a servis k hardwaru objednatele (má jej ve svém datovém centru) a garantuje přitom sjednanou úroveň jeho dostupnosti, zároveň však poskytuje objednateli i další infrastrukturu pro provoz jeho aplikací, a to za užití virtualizace a vlastního hardwaru, popřípadě hardwaru třetích osob.
Plnění dle prvního bodu je tedy spíše klasickým outsourcingem, ve druhém případě už služba nese rysy IaaS. Během toho, co životnost hardwaru objednatele bude průběžně končit, bude mít objednatel možnost zvolit, zda si pořídí nový hardware, nebo bude požadovat převedení kapacity příslušného hardwaru do režimu IaaS. Na výše položenou otázku tak lze odpovědět šalomounsky „ano i ne“, ovšem fakt, že značná část plnění poskytovatele nenese ani znaky IaaS, jsme se rozhodli tento pojem ve smlouvě neužívat s tím, že jsme jej použili až pro případný cílový stav, kdy bude možné přenést celou infrastrukturu včetně systémového softwaru, ale i vybraných aplikací do režimu tzv. privátního cloudu, v němž bude objednatel hradit služby na principu pay as you go, tedy skutečně jako platbu na uživatele, která se bude pohybovat měsíc od měsíce v závislosti na jejich počtu (dle stávající smlouvy je cena kalkulována jednotkově za jednotlivá dílčí plnění – služby).
Náběh do privátního cloudu je zatím natolik vzdálen, že jsou ve smlouvě zachyceny pouze určité jeho rysy. Zpřesnění celého procesu by mělo průběžně probíhat v rámci project managementu, zatím není ani natolik konkrétní, aby bylo možné jej zakotvit například ve formě smlouvy o smlouvě budoucí.

Předmět smlouvy

Jak je patrné z předchozí části, vymezení předmětu smlouvy vyžaduje, aby i právník měl povědomí o celém procesu a účastnil se příslušných jednání. Teprve poté může mít smlouva logickou stavbu, neobsahuje zavádějící terminologii a pokrývá rizika smluvního vztahu (ačkoliv všechno předvídat pravděpodobně nelze).
Nemenší pozornost musí být věnována i příloze, která přesně specifikuje jednotlivá plnění provozovatele. Musím říci, že v průběhu sjednávání smlouvy vznikla řada verzí specifikace předmětu – docházelo k řadě upřesnění, vysvětlování a odstraňování nedorozumění. Prakticky lze říci, že kdyby celý proces tvorby specifikace předmětu smlouvy (a také jednání o ceně) neměli na straně objednatele pod kontrolou nezávislí a zkušení konzultanti z oboru, vykazovala by specifikace předmětu plnění množství nedostatků a nebyla by úplná.
Provozovatel byl nucen upřesnit řadu dílčích plnění, jejichž výklad by v opačném případě byl nejasný nebo nedostatečný. Praktický každý dílčí proces v rámci provozování infrastruktury objednatele je v příloze rozebrán na jednotlivé dílčí kroky či plnění a přesně se stanoví, zda za tyto konkrétní dílčí kroky odpovídá objednatel nebo (častěji) provozovatel.
Jakkoliv vypadá takový postup jako samozřejmost, v praxi je řada specifikací plnění nedotažených. Není-li povinnost objednatele jednoznačně sjednána, dává mu objednatel možnost vyvinit se z odpovědnosti. Nedostatky ve specifikaci plnění umožňují provozovateli vymluvit se na nedostatek součinnosti ze strany objednatele (čímž mu nevznikne odpovědnost za škodu nebo její část) nebo plnění třetích stran. Objednatel se pak často s údivem dozvídá, že měl takovou součinnost zajistit.

Úroveň dostupnosti

Jedno z dalších témat k jednání bylo upřesnění úrovně dostupnosti. Vedle sjednané úrovně dostupnosti (ta byla sjednána ve třech kategoriích, protože pro určité služby bude dostatečná nižší úroveň dostupnosti) byly u vybraných dílčích plnění provozovatele přesně specifikovány i jednotlivé komponenty, u nichž je dostupnost měřena.
Diskuse se vedla samozřejmě o jednotlivých parametrech úrovně dostupnosti a také o tom, co všechno bude podléhat výluce z měření dostupnosti. Jednou z výluk je stav, kdy sjednané úrovni dostupnosti nebude dosaženo v důsledku dodržování vnitřních směrnic přijatých objednatelem po uzavření smlouvy. Pouze však tehdy, pokud provozovatel na takový důsledek objednatele upozornil.
Samotné měření úrovně dostupnosti provádí ve smlouvě specifikovaná aplikace, smlouva zahrnuje i způsob reportingu. Předpokládá se pravidelné vyhodnocování dosahované úrovně dostupnosti na schůzkách v rámci projektového managementu.
V této souvislosti jsem si nemohl nevzpomenout na některé až komické smlouvy, s nimiž jsem se v praxi setkal, a které obsahovaly jako by mimochodem závazek poskytovatele/provozovatele k „dosažení 99% dostupnosti v kalendářním měsíci“, a to bez jakéhokoliv dalšího upřesnění. I s ohledem na shora uvedené je zřejmé, že takto formulovaný závazek je v podstatě neplatný z důvodu neurčitosti.

Servis, incidenty

Součástí plnění provozovatele je samozřejmě řešení incidentů, které zde nebudu blíže popisovat. S ohledem na dosti citelné sankce v případech překročení doby reakce na (řádně) ohlášený incident, a zejména překročení doby na vyřešení incidentu se provozovatel obával velkého počtu „planých“ incidentů, které budou činit jednotliví uživatelé ať už z neznalosti, nebo dokonce šikanózním způsobem.
Bylo proto sjednáno jednak dvojstupňové ohlašování incidentů, které koncoví uživatelé hlásí příslušnému oddělení objednatele, jež je vyhodnotí a případně postoupí provozovateli. Objednatel dále přistoupil i na menší sankci za případy většího počtu takových planých oznámení v jednom kalendářním měsíci.

Kalkulace smluvních pokut a slevy z ceny

Toto bylo jedna z nejsložitějších pasáží smlouvy a zejména přílohy obsahující kalkulaci ceny a smluvních pokut. Oproti prvním verzím smlouvy se finální podoba naprosto zásadně lišila. Potenciální objednatele je třeba upozornit na to, že první návrhy provozovatele sice na první pohled vypadaly dobře a srozumitelně, ovšem na základě rozboru provedeného společně s nezávislými konzultanty jsme dospěli k jednoznačnému závěru, že jsou neurčité a v řadě případů by vůbec nebylo možno určit výši smluvní pokuty či slevy, ani to, zda na ni vzniknul nárok.
Přitom sjednání jasných a dobře doložitelných sankcí je pro objednatele mimořádně důležité, protože u smluv se složitým plněním skládajícího se z desítek menších dílčích plnění, navíc vyžadujících součinnost objednatele, může být téměř nemožné domáhat se peněžitých kompenzací prostřednictvím náhrady škody.
Uplatnění náhrady škody si lze představit vcelku dobře při absolutnímu výpadku infrastruktury zajišťované provozovatelem. Ovšem v případě dílčích výpadků jednotlivých plnění, například dlouhých dobách odezvy jednotlivých aplikací v důsledku nesprávně fungující infrastruktury, bude pro objednatele velice obtížné prokázat skutečnou škodu, nebo dokonce ušlý zisk takto způsobený – musel by totiž přesně vyčíslit jednotlivé škody a prokázat jejich jednoznačnou příčinnou souvislost s nedosažením garantované úrovně dostupnosti příslušné služby.
S touto situací jsem se nesetkal zdaleka poprvé a rozhodně se netýká jen smluv upravujících cloudová řešení. Doporučuji vždy zejména objednateli, aby se pokusil namodelovat si dle návrhu smlouvy předložené jakýmkoliv dodavatelem nějakou událost, která představuje závažné porušení jeho povinnosti. Jsou stanoveny jasně podmínky, za nichž nárok objednateli vznikne? Je schopen dopočítat se jednoznačně smluvní pokuty?
Možná taková zkouška povede k překvapivým výsledkům. Odlišné výsledky mohou znamenat přehlédnutí někoho z počítajících, ale také mohou být důsledkem neurčitosti kalkulace smluvní pokuty – ta může být neurčitá, i když je sazba pokuty (obvykle procentuální) zcela jasná. Do složitějších smluv je proto vhodné vložit i modelovou kalkulaci smluvní pokuty.

Ukončení smlouvy

Asi se budu opakovat, ale ukončení smlouvy a důsledkům s tím spojeným by měl především objednatel věnovat maximální pozornost. Chybět nesmí přesný výčet činností, které je provozovatel povinen bez nároků na úplatu povinen provést. Pokud tuto oblast objednatel před uzavřením smlouvy zanedbá, může po ukončení smlouvy zaplatit provozovateli značné částky, k čemuž určitě přispívá časová tíseň a s tím spojený stres.

Shrnutí

Jak vyplývá už z názvu, není tento článek v žádném případě úplným popisem všech náležitostí smlouvy na poskytnutí služeb IaaS. Opravdu jde spíše o postřehy, z nichž ale vyplývá, jak náročný je celý proces přechodu do režimu IaaS nejen pro objednatele, ale také pro provozovatele. Řadu závěrů shora uvedených lze vztáhnout nejen na IaaS, ale obecně na přechod do režimu cloud computingu.
Koneckonců už samotné užívání pojmu cloud computing a jeho jednotlivých kategorií (SaaS, IaaS, PaaS a dalších) může být v praxi o dost komplikovanější oproti jednoznačným definicím těchto kategorií v literatuře.
Zvažuje-li objednatel přechod do cloudu, dovolil bych si závěrem několik rad, které se dotýkají právní stránky celé věci. Objednatel by měl:

1. využít služeb nezávislých konzultantů z oboru IT, kteří mají praktické zkušenosti s přechodem do cloudových služeb a jejich poskytováním – jejich zkušenosti umožní objednateli lépe zformulovat vlastní požadavky a očekávání, ovšem především pomůžou odhalit slabá nebo nedostatečně ošetřená místa ve specifikaci předmětu plnění provozovatele,
2. trvat na tom, aby jeho právníci či advokáti úzce spolupracovali při tvorbě smlouvy s konzultanty dle bodu 1 – právník může těžko odhalit nepřesnosti a neúplnosti ve specifikaci plnění provozovatele, stejně tak je vhodné, aby měl právník možnost ověřit si způsob měření úrovně dostupnosti a kalkulaci smluvních pokut a sankcí u nezávislé osoby (každý dodavatel samozřejmě vždy tvrdí, že jeho smlouva je perfektní a že „není problém“),
3. ještě před zveřejněním záměru přejít do cloudu projít stávající smlouvy s dodavateli (zhotoviteli softwaru, správcem sítě) a provést přípravu – zvážit rizika vyplývající z uzavřených smluv, například možnosti jednotlivých dodavatelů brzdit či blokovat celý proces, ověřit si, zda disponuje veškerou dokumentací, přístupovými hesly atd., popřípadě vyzvat dodavatele k jejich doplnění a předání (ne každý stávající dodavatel uvítá přechod do cloudu),
4. nechat si zhotovit smluvní dokumentaci od právníků či advokátů, kteří mají prokazatelné zkušenosti v oboru – stejně jako u jiných konzultantů umožňuje zkušenost i právníkům lépe rozpoznat rizika a účinně jim předcházet.

Je zřejmé, že především pro velkou firmu představuje celý přechod do cloudu nutnost přesně naplánovat celý proces, provést analýzy a smluvně ošetřit řadu rizik, která jsou s ním spojena. Pokud však objednatel nepodcení tuto přípravu, je velká pravděpodobnost, že celý proces proběhne úspěšně a výsledek naplní jeho očekávání. A pokud přeci jen s úrovní služeb nebude spokojen, splní smlouva roli pojistky pro tento případ.

Petr Otevřel
Autor působí v advokátní kanceláři Jansa, Mokrý, Otevřel & partneři v.o.s., kde se zabývá zejména smluvní úpravou v oblasti informačních technologií, autorským a obchodním právem.