Umowa SLA na utrzymanie systemu: co musi zawierać

Umowa SLA na utrzymanie systemu powinna jasno określać, co jest awarią, jak szybko wykonawca na nią reaguje i w jakim czasie ją usuwa. Do tego dochodzą zakres aktualizacji, monitoring, kopie zapasowe, raportowanie i zasady wyjścia z umowy. Jeśli któregoś z tych elementów brakuje, spór zaczyna się zwykle przy pierwszej poważnej awarii. Poniżej przechodzę przez zapisy, które sprawdzam w takich umowach, i pokazuję, na co uważać.

Tekst jest dla osoby, która właśnie odebrała system od software house’u albo negocjuje warunki opieki nad nim. Nie zastępuje porady prawnej, ale pomoże zadać właściwe pytania zanim umowa trafi do prawnika.

Czym SLA różni się od zwykłej umowy serwisowej

SLA, czyli service level agreement, to umowa o poziomie usług: zamiast ogólnego „wykonawca zapewnia opiekę” zawiera mierzalne zobowiązania i konsekwencje ich niedotrzymania. Zwykła umowa serwisowa często mówi tylko o liczbie godzin do wykorzystania w miesiącu.

Pakiet godzin to dobry sposób rozliczania drobnych zmian, ale nie odpowiada na pytanie, co się stanie w piątek wieczorem, gdy sklep przestanie przyjmować zamówienia. Dobra umowa SLA na utrzymanie systemu łączy oba elementy: gwarantowane czasy dla awarii i budżet godzin na rozwój.

Klasy zgłoszeń w umowie SLA na utrzymanie systemu

Podstawą SLA jest podział zgłoszeń na klasy według wpływu na biznes, bo od klasy zależą czasy reakcji i naprawy. Bez takiego podziału każde zgłoszenie jest dla klienta pilne, a dla wykonawcy kolejne w kolejce.

Przykładowy podział, który traktuję jako punkt wyjścia do negocjacji, a nie wzór dla każdej firmy:

Klasa	Przykład	Czas reakcji	Czas obejścia lub naprawy
Krytyczna	system nie działa, zamówienia nie wpływają, wyciek danych	do godziny, także poza godzinami pracy	obejście w ciągu kilku godzin
Wysoka	kluczowa funkcja nie działa, ale da się pracować inaczej	kilka godzin roboczych	następny dzień roboczy
Normalna	błąd w mniej ważnej funkcji	jeden dzień roboczy	według ustalonego harmonogramu
Niska	kosmetyka, drobna zmiana, pytanie	kilka dni roboczych	w ramach pakietu godzin

Wartości w tabeli są ilustracją. Właściwe czasy zależą od tego, ile kosztuje Cię godzina przestoju i ile jesteś gotów płacić za dyżur. Krótszy czas reakcji poza godzinami pracy oznacza, że ktoś po stronie wykonawcy musi być pod telefonem, a to kosztuje.

Ważne jest też, kto przypisuje klasę. Najlepiej, gdy klient proponuje klasę przy zgłoszeniu, a umowa opisuje, jak rozstrzyga się spór, na przykład decyzją osób kontaktowych obu stron w określonym czasie.

Czas reakcji a czas naprawy: dwa różne zobowiązania

Czas reakcji to moment, w którym wykonawca potwierdza zgłoszenie i zaczyna pracę. Czas naprawy to moment, w którym system znów działa. Umowa, która gwarantuje tylko reakcję, gwarantuje w praktyce szybkiego maila z informacją, że sprawa jest analizowana.

Dlatego w dobrej umowie SLA na utrzymanie systemu pojawia się trzecie pojęcie: obejście. Przy awarii krytycznej celem jest przywrócenie działania w ciągu kilku godzin, nawet prowizorycznie, a trwała poprawka może przyjść później. Takie rozdzielenie jest uczciwe dla obu stron, bo nie każdy błąd da się naprawić porządnie w jeden wieczór.

Zwróć też uwagę, od kiedy liczony jest czas. Czy od wysłania zgłoszenia, czy od jego potwierdzenia? Czy w godzinach roboczych, czy kalendarzowych? Te dwa zdania w umowie potrafią zamienić „cztery godziny” w dwa dni.

Godziny obsługi i kanały zgłoszeń

Umowa powinna wskazywać, w jakich godzinach działa obsługa, którymi kanałami przyjmuje zgłoszenia i jak zgłasza się awarię krytyczną poza tymi godzinami. Zgłoszenie wysłane na prywatny komunikator programisty nie jest zgłoszeniem w rozumieniu umowy.

• system zgłoszeń z historią i numerem sprawy jako kanał podstawowy,
• telefon alarmowy albo osobny adres do awarii krytycznych,
• lista osób po stronie klienta, które mogą zgłaszać i akceptować prace,
• zastępstwa po stronie wykonawcy na czas urlopów i choroby.

Ostatni punkt jest szczególnie ważny przy mniejszych wykonawcach. Jeśli system zna jedna osoba, umowa powinna mówić, jak wykonawca zapewnia ciągłość, na przykład dokumentacją i drugą osobą, która zna środowisko.

Aktualizacje i bezpieczeństwo w umowie SLA

Utrzymanie to nie tylko gaszenie pożarów, ale też regularne aktualizacje systemu operacyjnego, serwera aplikacji, frameworka, bibliotek i wtyczek. Umowa powinna mówić, co jest aktualizowane, jak często, kto decyduje o terminie i jak wygląda test przed wdrożeniem na produkcję.

Poprawki bezpieczeństwa wymagają osobnego trybu. Gdy pojawia się informacja o luce w używanym komponencie, czekanie na comiesięczne okno serwisowe bywa zbyt ryzykowne. W umowie warto zapisać, w jakim czasie wykonawca ocenia wpływ takiej luki na system i wdraża poprawkę.

Osobną sprawą są większe aktualizacje, na przykład przejście na nową wersję frameworka. To zwykle projekt, a nie rutynowa obsługa, więc umowa powinna rozróżniać aktualizacje w cenie od tych wycenianych osobno. Inaczej wykonawca nie ma interesu w ich robieniu, a system po kilku latach zostaje na wersjach bez wsparcia.

Monitoring i kopie zapasowe

Wykonawca powinien wiedzieć o awarii wcześniej niż Twoi klienci. Dlatego w umowie opisuje się, co jest monitorowane, kto dostaje alarmy i co się dzieje po alarmie poza godzinami pracy.

Minimum, którego oczekuję w monitoringu, to dostępność aplikacji, kończące się miejsce na dysku, ważność certyfikatów, działanie zadań cyklicznych i integracji. Przy integracjach, na przykład gdy sklep internetowy jest zintegrowany z ERP, monitoring powinien łapać też sytuację, w której połączenie działa, ale dane przestały płynąć.

W części o kopiach zapasowych szukam odpowiedzi na kilka pytań:

1. Co jest kopiowane: baza danych, pliki, konfiguracja, kod.
2. Jak często i jak długo kopie są przechowywane.
3. Gdzie leżą kopie: czy poza serwerem produkcyjnym i poza kontem, na którym działa system.
4. Ile danych można stracić w najgorszym przypadku i w jakim czasie system wraca do działania.
5. Jak często wykonawca sprawdza odtworzenie z kopii i jak dokumentuje ten test.

Kopia, z której nikt nigdy nie odtworzył systemu, jest nadzieją, a nie zabezpieczeniem. Szerzej o tym, jak chronić dane firmy, piszę w tekście o zabezpieczaniu danych firmowych.

Raporty, kary umowne i przegląd umowy

Raport miesięczny powinien pokazywać liczbę zgłoszeń w każdej klasie, dotrzymane i przekroczone czasy, przestoje, wykonane aktualizacje i zużycie pakietu godzin. Bez raportu nie da się ocenić, czy SLA działa, a rozmowa o jakości opiera się na wrażeniach.

Konsekwencje przekroczenia czasów mogą mieć formę kar umownych albo obniżenia opłaty abonamentowej. Uważam, że ważniejsze od wysokości kary jest to, żeby była realnie egzekwowana i żeby powtarzające się przekroczenia dawały prawo do wypowiedzenia umowy.

Dobrą praktyką jest też coroczny przegląd, w którym umowę SLA na utrzymanie systemu porównuje się z raportami z minionego roku. System się zmienia, rośnie liczba użytkowników i integracji, a warunki sprzed lat przestają pasować do rzeczywistości.

Wyjście z umowy: co musisz dostać na koniec

Najważniejszy zapis w umowie SLA na utrzymanie systemu dotyczy jej końca: co wykonawca przekazuje, w jakim czasie i w jakiej formie. Bez tego zmiana dostawcy zamienia się w odtwarzanie systemu z tego, co uda się wydobyć.

• aktualny kod w repozytorium, do którego masz dostęp przez cały czas trwania umowy, a nie tylko na koniec,
• dokumentacja wdrożenia, konfiguracji i integracji,
• dostępy do serwerów, domen, kont usług zewnętrznych i kluczy, najlepiej od początku na kontach firmy,
• okres przejściowy, w którym dotychczasowy wykonawca wspiera nowego,
• przekazanie albo usunięcie danych, które wykonawca przetwarzał.

Ostatni punkt wynika wprost z prawa, gdy system przetwarza dane osobowe. Zgodnie z art. 28 rozporządzenia RODO umowa z podmiotem przetwarzającym musi przewidywać, że po zakończeniu usług usuwa on lub zwraca dane i usuwa ich kopie. Firma utrzymująca system z danymi klientów jest zwykle takim podmiotem, więc obok SLA potrzebna jest umowa powierzenia przetwarzania danych.

Na co uważać przy czytaniu SLA

Kilka zapisów, przy których zawsze dopytuję, bo w praktyce odwracają sens umowy:

• „dołożymy wszelkich starań” zamiast konkretnego czasu,
• czasy liczone od potwierdzenia, bez limitu na samo potwierdzenie,
• wyłączenia odpowiedzialności obejmujące wszystko, co dotyczy hostingu lub usług zewnętrznych,
• brak różnicy między awarią a zmianą, przez co awaria zjada pakiet godzin,
• brak zapisu o dostępie do kodu i serwera po stronie klienta.

Koszt utrzymania warto też zestawić z kosztem budowy już na etapie wyboru wykonawcy. Piszę o tym w tekstach o tym, od czego zależy koszt systemu dedykowanego, oraz jak wybrać software house.

Jeśli masz już system w produkcji, a umowa SLA na utrzymanie systemu jest u Ciebie jedną stroną ogólników albo nie ma jej wcale, zacznij od prostego rachunku. Spisz, ile kosztuje Cię godzina przestoju i kto dziś reaguje na awarię. Z tą wiedzą łatwiej wynegocjować konkretne czasy, a projekt umowy możesz przejrzeć z kimś, kto zna obie strony, na przykład w ramach współpracy przy utrzymaniu systemów.