Nadchodzi taki moment w życiu każdego biznesu opartego na platformie internetowej, że drobna przerwa w działaniu serwisu nie jest już tylko niewygodna, ale przekłada się na realne pieniądze. Dojrzałe biznesy internetowe często zapewniają sobie tak zwane Service Level Agreement, czyli umowę definiującą poziom obsługi programistycznej i dostępności serwisu. Dowiedz się, czym dokładnie jest SLA w e-Commerce i co powinno się w nim znaleźć.

Powodem, dla którego zdecydowaliśmy się napisać ten artykuł, jest pewna wiadomość umieszczona na grupie Eksperci e-Commerce, gdzie jedna z osób poinformowała o tym, że sklep Amazona ugiął się pod ciężarem własnej promocji (w ramach tzw. Prime-day, czyli 36 godzin zniżek w serwisie) i stał się niedostępny. Tego samego dnia dowiedzieliśmy się, że również nasze rodzime Allegro padło ofiarą ruchu, ze względu na promocję telefonu komórkowego za złotówkę (dla pierwszych kupujących).

Zdarza się każdemu, jesteśmy pewni, że zarówno Amazon, jak i Allegro mają również zapewnione SLA. W przypadku Amazona jest nawet własne rozwiązanie w postaci serwerów AWS, z których sami korzystają. Pytanie jednak jaką szkodę spowodowała przerwa? Inne, być może bardziej właściwe pytanie – czy jesteś w stanie oszacować, ile kosztowałaby Ciebie? Czy jest o co walczyć?

Pomijając nawet kwestie finansowe, zastanów się, jak wpływa to na wizerunek sklepu i wiarygodność w oczach Klientów. Czy korzystałbyś równie chętnie z Google’a, jeżeli wyszukiwarka nie byłaby dostępna kilka razy w tygodniu?

SLA w e-Commerce

Tradycyjnie Service Level Agreement dotyczy dwóch rzeczy:

  1. W przypadku usług hostingowych – oznacza tzw. dostępność serwerów.
  2. W przypadku usług programistycznych – oznacza czas reakcji i szybkość naprawy błędów.

Dostępność serwerów

W momencie, kiedy wykupujesz usługę hostingową Twojego sklepu u dostawcy rozwiązań IT – on gwarantuje Ci w ramach kwoty, którą mu płacisz pewną dostępność serwerów. Oznacza to dokładnie, ile maksymalnie może być przerwy w dostępności usługi. Zazwyczaj oznacza się to procentową wartością – standardowo między 99%–99,9%, czasami jednak te wartości potrafią wykraczać poza ten zakres, zarówno w górę (np. systemy bankowe mają zapewniony znacznie wyższy współczynnik dostępności), jak i w przypadku budżetowych serwerów – niższe.

Co dokładnie oznacza ta wartość? Ile procentowo czasu serwer może być niedostępny (a Twój sklep niewidoczny dla użytkownika). W przypadku wartości 99% gwarantuje Ci to, że Twój sklep może maksymalnie zniknąć z sieci przez 7 godzin i 18 minut w ciągu miesiąca. Typowy wskaźnik 99,5% zmniejsza tę wartość o połowę do 3 godzin 39 minut.

Jeżeli chcielibyście dokładnie przeliczyć Wasze SLA, to polecamy darmowy kalkulator.

Z dostępności serwerów zwyczajowo wyłączone są planowane prace nad serwerami – nawet jeżeli przekraczają nasze SLA. Innymi słowami, jeżeli serwerownia poinformuje nas, że będzie potrzebowała 2 godzin w niedzielę w nocy, na aktualizację bibliotek na serwerze, to te 2 godziny nie zostaną uwzględnione w tych 99,9%. Pamiętajcie jednak, że każda serwerownia stara się zapewnić jak najwyższy współczynnik dostępności, inaczej nie przetrwałaby zbyt długo na rynku. Dlatego minimalizują ten współczynnik, jak tylko mogą.

Warto zaznaczyć, że serwerownie zazwyczaj gwarantują jakąś dostępność bez podpisania dodatkowej umowy SLA – sprawdź stronę Swojego dostawcy i zobacz czy wartość ta jest wystarczająca. Być może nie musisz do niej dopłacać.

Czas reakcji i szybkość naprawy błędów

Wydaje się trochę nieintuicyjne, że płacąc SLA, można jakkolwiek przyspieszyć naprawę błędu – tak jednak jest. Wykupując miesięczne pakiety utrzymaniowe u agencji internetowej, zapewniamy sobie dwie rzeczy:

  1. Priorytetowe traktowanie zgłaszanych zadań;
  2. Dostępność programistów poza godzinami pracy (agencja internetowa musi ich zapewnić oraz upewnić się, że mają rozstawione środowisko);

Standardowa umowa SLA w e-commerce podpisywana z software housem zawiera dwie wartości i trzy typy błędów. Wartości to: czas reakcji i czas naprawy. Typy błędów to: krytyczny, pilny, standardowy.

Czas reakcji – oznacza, jak szybko agencja przyjmie nasze zgłoszenie i skontaktuje się z nami. Przyjmijmy taki scenariusz: zgłaszamy błąd przez wyznaczony system, a następnie otrzymujemy telefon, z pytaniem o więcej szczegółów, albo z informacją, że już się zajmują błędem. Czas między zgłoszeniem a telefonem to właśnie czas reakcji.

Czas naprawy – to, jak sama nazwa wskazuje, maksymalny czas, jaki agencja może wykorzystać na naprawienie błędu. Pojawiają się tutaj dwa problemy. Pierwszy z nich wynika z samej natury usług programistycznych – często błąd naprawia się poprzez zmianę kilku znaków w kodzie, ale znalezienie przyczyny błędu (tzw. debuggowanie), może jednak zająć wiele godzin, jeżeli nie dni. Jest to jednak ryzyko, jakie bierze na siebie agencja podpisująca umowę SLA. Drugim problemem może być definicja, jak dokładnie mierzony jest czas. W zależności od sformułowania umowy, finalny czas naprawy będzie równy “czasowi naprawy”, albo “czasowi naprawy” + “czasowi reakcji”.

Zwyczajowo czas reakcji jest krótszy niż czas naprawy, ale może to mieć znaczenie przy późniejszym domaganiu się swoich praw.

Jak czytać tabelę SLA w e-commerce?

Przykładową tabelę znajdziecie poniżej:

 

Czas rekacji Czas naprawy
Błąd krytyczny 2 godziny 4 godziny
Błąd pilny 4 godziny robocze 8 godzin roboczych
Błąd standardowy 8 godzin roboczych 40 godzin roboczych

 

Jak widzicie, w zależności od typu błędu przyjmuje się inne wartości czasów reakcji i naprawy. Z tego powodu bardzo ważne jest zdefiniowanie co dokładnie jest błędem krytycznym, pilnym i standardowym. Często definicja jest narzucana przez agencję internetową, ale zazwyczaj jest zbliżona do jednego z zapisów jak poniżej:

  1. Za błąd krytyczny uznaje się błąd, który powoduje brak możliwości wykonania jednego z głównych procesów w sklepie (dodania do koszyka, przejścia do kasy, złożenia zamówienia, przeglądania katalogu lub brakiem strony głównej);
  2. Za błąd krytyczny uznaje się dowolny błąd występujący u min. 50% użytkowników;

Drugą rzeczą, na którą warto zwrócić uwagę, to fakt, że błędy pilne i standardowe rozwiązywane są tylko w ramach godzin roboczych. Oznacza to, że zgłoszony błąd może w rzeczywistości zająć znacznie dłużej, niż by się pierwotnie wydawało. Wszystko jest jednak kwestią negocjacji z agencją.

Obejście

Zdarza się też również, że błędy mogą zostać “pomniejszone”(np. krytyczny stać się pilnym, pilny standardowym), jeżeli jest dostępny tzw. workaround (czyli obejście). Przykładowo: nie działa dodawanie produktów do kasy z poziomu katalogu, jednak można dodać produkt z poziomu produktu – jest dostępne obejście, więc nie jest to błąd krytyczny.

Z takim podejściem jednak warto uważać, ponieważ definicja obejścia nie jest jednoznaczna. Przykładowo: w sklepie nie działają paczkomaty, ale Klient może zamówić paczkę kurierem, albo odebrać w salonie. Czy to jest obejście?

Zmiany

Jednym problemem działającym w drugą stronę, jest częste niezrozumienie przez właściciela sklepu tego, jak działa SLA. Ono dotyczy błędów, a nie zmian w serwisie. Nie można oczekiwać, że zadanie, które normalnie programiście zajęłoby tydzień na wdrożenie, zostanie wykonane w 8 godzin.

Typowym problemem jest też zgłaszanie zmian, jako błędów. Czasami granica jest płynna – przykładowo: czy to, że system nie spełnia biznesowych założeń, chociaż zostały przekazane inne wymagania na etapie projektowania, jest błędem czy zmianą? Dla właściciela sklepu – błędem, dla właściciela agencji – zmianą. Są tutaj ewidentnie odrębne interesy.

SLA w e-commerce – komunikacja

Dobrze skonstruowana umowa SLA powinna zawierać też zdefiniowany sposób komunikacji. Kto kontaktuje się z kim, w jaki sposób.

Przykładowo: część agencji wymaga, żeby błędy krytyczne były zgłaszane telefonicznie – daje im to pewność, że mogą zareagować natychmiastowo. Część jednak ma do tego celu specjalne systemy ticketowe.

Ważne jest też zdefiniowanie eskalacji, tj. co robić, jeżeli nikt nie odbiera telefonu, albo platforma do składania błędów nie działa.

Kary

Potwornie istotną w tej relacji kwestią dla właściciela sklepu jest zapewnienie sobie odpowiednich kar umownych za niedotrzymanie terminu. SLA często kosztuje od kilku do nawet kilkunastu tysięcy złotych miesięcznie. Ma to gwarantować Twoje bezpieczeństwo, więc jeżeli tego nie robi, to należy się kara.

Standardowo przyjmuje się ją za każdą przekroczoną godzinę lub dzień roboczy. Ważne jednak, żeby zdefiniować, ile dokładnie agencja musi zapłacić za każdą godzinę opóźnienia. Żeby to zrobić, należy wrócić do eksperymentu myślowego na początku artykułu i zastanowić się nad tym ile ta godzina jest dla Was warta. Kara powinna pokrywać ten koszt przynajmniej częściowo.

Monitorowanie systemu

Podstawą każdej umowy SLA jest narzędzie do mierzenia dostępności, które zawiadomi Cię o ew. problemie, ale też na koniec miesiąca pozwoli sprawdzić, jaki był sumaryczny poziom dostępności. Ważne, żeby umowa SLA (w przypadku umowy hostingowej) definiowała takie narzędzie, bo później może dojść do nieporozumienia – jeden system może nam pokazać inne wartości niż drugi (standardowo systemy działają w taki sposób, że raz na kilka minut wysyłają zapytanie do sklepu i jeżeli nie otrzymują odpowiedzi, to zgłaszają błąd). Warto jednak narzędzie to “przypiąć” w kilku miejscach na stronie, np. stronie głównej, kasie, katalogu produktów. W przypadku sklepu przerwa może dotyczyć tylko części systemu.

Pamiętajmy też, że jeżeli dbamy o uptime (dostępność) serwerów, to nie chodzi tylko o reagowanie, ale też o przewidywanie i skalowanie serwerów. Powinniśmy oczekiwać, że agencja będzie wykrywała zbliżanie się do górnej granicy zasobów serwerowych, np. jeżeli zużycie RAM lub procesora przekroczy 80%. SLA jest po to, żeby nie było problemów z dostępnością, jak do tego dojdziemy to już kwestia umowna.