Cześć, dzień dobry. Witam was w podcaście IT i Biznes. Nazywam się Grzegorz Tabor i na co dzień prowadzę trzy firmy, w tym firmę programistyczną, agencję doradczo-rekrutacyjną i SaaS do monitoringu cen konkurencji dla e-commerce.Podcast IT i Biznes kieruje do właścicieli firm oraz menadżerów, którzy na co dzień współpracują w swoich firmach często i dużo z szeroko pojętym IT i chcieliby realizować owe projekty IT bardziej świadomie i skuteczniej. Odcinek 26. SLA.

Gwarancja, która chroni twój biznes. Czy kiedykolwiek zastanawiałeś bądź zastanawiałaś się, co się stanie, gdy twój system nagle przestanie działać? W dzisiejszym odcinku przyjrzymy się umowom SLA i ich kluczowej roli w zabezpieczaniu twojego biznesu online. Dowiesz się, jak odpowiednia umowa może uratować cię przed kryzysami i zapewnić szybkie rozwiązania problemów.

Dowiesz się m.in. o definicji SLA, o tym, jakie są kluczowe elementy takiej umowy, jaki powinien być zawarty w niej czas reakcji na awarię, jakie są modele rozliczeń. Zatem, nie przedłużając, serdecznie zapraszam do merytorycznej części dzisiejszego odcinka. Cześć, dzień dobry.

Witam w kolejnym odcinku podcastu, gdzie skłębiamy tematy związane z IT i biznesem. Dzisiaj porozmawiamy o SLA, czyli tzw. Service Level Agreement, czyli świadczeniu usługi zapewniającej stałą dostępność twoich systemów IT.

Dlaczego ten temat jest taki istotny? W biznesie online każda minuta przestoju może oznaczać straty finansowe i wizerunkowe, więc tutaj posiadanie odpowiednich umów, ale przede wszystkim też zespołów mogących warunki tych umów spełnić, to jest must have. Dzięki temu odcinkowi dowiesz się, czym dokładnie jest SLA, jak działa, dlaczego warto mieć umowę SLA i odpowiem też, co powinno się znaleźć w takiej umowie, jakie są kluczowe elementy. Więc słuchaj do końca, bo szczególnie jeśli działasz w e-commerce lub twój produkt czy system online obsługuje wielu użytkowników jednocześnie, to szczególnie w tych przypadkach może być to dla ciebie wiedza cenna.

Zyskasz po przesłaniu tego odcinka przede wszystkim świadomość i przygotowanie na ewentualne kryzysy, które mogą się zdarzyć w każdej chwili. Zatem zaczynamy. Zacznijmy od podstaw.

Czym właściwie jest SLA? SLA czy też umowa na SLA to jest właśnie umowa na Service Level Agreement, czyli taka formalna umowa pomiędzy dostawcą usługa klientem, która określa poziom dostępności usług, który powinien być zapewniony. Czyli ona zawiera kluczowe elementy takie jak np. czas reakcji na zgłoszenia, czas dostępności usług, czy też konsekwencje, które wynikają z tego, że ktoś mógłby nie wywiązywać się z tego typu ustaleń.

Czyli krótko mówiąc jest to taki dokument, który daje ci pewność, że twoje usługi IT będą działać na określonym przez ciebie poziomie. Ale żeby przetłumaczyć tę definicję i oprzeć ją o konkretny przykład, wyobraź sobie sytuację, w której twój zespół jest już po godzinach pracy lub jest po prostu weekend, albo twoje systemy IT np. są zarządzane przez jedną osobę, co często się zdarza w mniejszych firmach, które po prostu nie mają aż tyle dużo zadań, żeby zatrudniać dodatkowego, atatowego programistę, pracownika.

I co gorsza wyobraź sobie, że ta osoba jest akurat niedostępna z powodu np. choroby, czy też po prostu urlopu. No i teraz wyobraź sobie, że nagle przestaje działać jakaś twoja główna funkcjonalność w systemie np.

koszyk zakupowy w e-commerce. Zobaczcie, to jest przykład, którym często się posługuje, ale on jest taki najbardziej oddający, to o co chodzi. Ale np.

nie działa koszyk zakupowy, albo np. klienci nie mogą się zarejestrować. No i teraz co robisz? Jeżeli nie masz tego typu umowy na SLA, no to i twoja osoba, która się tym wszystkim zajmuje, jest niedostępna, możesz delikatnie spanikować, zdecydowanie.

Ale w takiej sytuacji po prostu kluczowe jest to, aby mieć pewność, że wiesz do kogo się zgłosić, zanim z awarii już stanie się naprawdę ogromny pożar, no lub jeżeli nawet się stał ten ogromny pożar, to że tym bardziej wiesz, do kogo możesz z tym tematem uderzyć. I teraz w takich momentach właśnie SLA staje się takim twoim ratunkiem, bo zamiast biegać, szukać jakiejś pierwszej, lepszej firmy, czy dzwonić do jakichś innych znajomych, to po prostu masz już ustaloną procedurę i w jaki sposób w tego typu sytuacji się odnaleźć. I teraz przejdziemy sobie do takiego bloku, w którym opowiem, jakie są elementy SLA i pójdziemy sobie dalej.

I w SLA kluczowe są określone poziomy usług, takie jak na przykład czasy reakcji na awarię, czy też dostępne kanały kontaktowe. Dodatkowo SLA powinno zawierać szczegółowo informacje dotyczące poziomu usług, które mówią na przykład o tym, jak szybko dostawca zareaguje na różne problemy. Warto tutaj zwrócić uwagę na powiedzmy takie KPI, czy postawić sobie takie KPI, czyli tutaj rozumiem jako takie wskaźniki wydajności, które będą pomagały mierzyć skuteczność usług.

Czyli na przykład, czy twoja umowa zawiera informacje o dostępności systemów, czy o średnim czasie naprawy, czy też na przykład o liczbie zgłoszeń obsłużonych w danym czasie. I to, co jeszcze ważne, często w umowach SLA pojawia się zapis o tak zwanej opłacie dyżurowej, czy też opłacie za dyżur, czyli taka stawka, za którą ktoś będzie dostępny pod telefonem i obsłuży awarię na przykład o godzinie 21. No bo w przypadku dobrego SLA powinniście mieć ten czas reakcji w waszych godzinach szczytu najlepiej dopasowany.

I teraz, jeżeli ten ruch jest taki na przykład w waszym systemie, że on jest największy w godzinach 8-16, bo na przykład macie jakąś platformę learningową i w tym czasie najwięcej ludzi właśnie odbywa lekcje w waszej platformie, no to wtedy warto zadbać o to, żeby tutaj szczególnie ten czas reakcji na awarię był niski w tych konkretnych godzinach. Natomiast jeżeli na przykład macie system, który właśnie szczególnie w weekend generuje obciążenia i cały weekend, no to warto wtedy zadbać o to, żeby umowa SLA obsługiwała też czasy reakcji i awarie weekendowe. I tak naprawdę im więcej takich szczegółów i tego typu informacji zawartych będzie w umowie na SLA, też tym większa po prostu pewność, że usługi będą realizowane na odpowiednim poziomie.

I teraz przechodząc do wątku czasu reakcji i generalnie właśnie takiego wsparcia w przypadku awarii, to różni dostawcy świadczą usługę SLA na różnych poziomach i warto zweryfikować, czy ten czas reakcji właśnie odpowiada twoim potrzebom, to jest dokładnie to, co właśnie wam teraz przedstawiłem i warto też bazować na konkretnych przykładach, więc powiem ci, jak to działa u nas. Czas reakcji na awarię krytyczną u nas to maksymalnie dwie godziny jako taki punkt do odniesienia i to oznacza, że w przypadku poważnych problemów można liczyć na szybką interwencję, czyli w kontekście na przykład e-commerce'u czy platform e-learningowych, czy generalnie jakichkolwiek e-usług jest niezwykle ważne. I teraz taki poziom reakcji otrzymuje się u nas w godzinach 8.00-22.00 bez dodatkowych opłat, po prostu będąc naszym stałym klientem, czyli to też jest bardzo ważne, bo tak jak wspomniałem o tej opłacie dyżurowej u nas w godzinach 8.00-22.00 po prostu tej opłaty dyżurowej nie ma, w przypadku kiedy mamy stałą ramową umowę o współpracę i według niej działamy.

To, co my także zapewniamy, to jest support nocny, czyli tutaj jak najbardziej możemy też reagować na jakieś awarie dziejące się w nocy, czy w jakieś dni wolne zupełnie, natomiast wtedy pojawia się też ta dodatkowa niewielka opłata za dyżur, ta tak zwana dyżurowa, ale tylko w godzinach 22.00-8.00, czyli tych takich typowo nocnych. I teraz w ramach usług SLA, nawiązując współpracę, określa się, czy my też określamy istotne dla ciebie i twojego biznesu takie punkty krytyczne, czyli co to oznacza, że twój biznes przestaje działać i na jakie rzeczy powinniśmy reagować, w jakim trybie. I teraz my w umowie SLA dzielimy sobie to na dwa aspekty.

Aspekt działania ad hoc w razie awarii, czyli zapisujemy właśnie na przykład informacje o czasie reakcji, o którym tutaj wspomniałem, o dostępności usług, czyli takim gwarantowanym poziomie dostępności, czyli na przykład, że system powinien być dostępny dla użytkownika na przykład minimum 99,9% czasu w skali miesiąca. Mówimy o na przykład też wydajności, czyli na przykład maksymalne ustalenie czasów odpowiedzi systemu na żądanie użytkownika. I te kryteria są tak naprawdę, w zależności od tego na czym najbardziej zależy klientowi, to takie staramy się też dopasować.

Ale oprócz takich działań ad hoc i kryteriów z tym związanych, my też dodajemy często informacje o działaniach prewencyjnych, czyli na przykład, co jaki czas systemy będą aktualizowane, bo to też wpływa na realizację ogólną usługi SLA, czyli tego, żeby usługi były wysoko dostępne, czyli przez większość czasu. Co jeszcze z działań prewencyjnych, na przykład weryfikacje czynników zewnętrznych, zdarza nam się na przykład weryfikować zmiany na portalach zewnętrznych typu Allegro, od których zależą na przykład e-commerce'y, które utrzymujemy i rozwijamy. No i wtedy też my weryfikujemy jakie zmiany się pojawiają, na bieżąco dostosowujemy systemy naszych klientów do tych zmian.

Na to też mamy jakieś określone czasy reakcji, ale to mogą być też inne usługi dopasowane typowo do specyfiki przedsiębiorstwa. Tak naprawdę tutaj warto się zastanowić, które aspekty będą takie najbardziej istotne dla Was. W ramach umowy SLA z reguły dostajesz dodatkowy numer kontaktowy do człowieka, który w razie awarii uruchomi całą procedurę naprawczą.

Mogą to być też inne metody, bo zdarza się po prostu metoda, gdzie dodaje się jakiś ticket, jakieś zadanie. Z mojej perspektywy dodawanie zadania plus ten telefon to jest zawsze taka najlepsza forma zgłoszenia, jeżeli chodzi o zgłoszenie od użytkownika, a taką już zupełnie idealną formą, jeżeli już w ogóle coś się wysypuje, to zgłoszenie systemu monitoringu oczywiście, które dzieje się w zupełności automatycznie. O tym, żeby systemy monitorować, jak to robić, wspomniałem w odcinku 24 pod tytułem Dlaczego monitoring Twoich systemów to podstawa? Także jeśli jeszcze nie przesłuchaliście tego odcinka, to po wysłuchaniu tego obecnego serdecznie zapraszam do odcinka 24.

Wracając jednak do wątku podstawowego, kiedy już mamy ten numer kontaktowy do człowieka, który uruchomi całą procedurę naprawczą, no to to jest właśnie fajne, bo dzięki temu wiemy, kto dokładnie się zajmie problemem, w jakim czasie zareaguje na ten problem no i po prostu wiemy, że zgłoszenie trafiło w odpowiednie ręce. To co jeszcze w umowie jest istotne, to ona powinna zawierać oczywiście, oprócz standardowych rzeczy typu opis przedmiotu umowy, to też opis kategorii błędów i tego, w jaki sposób te błędy będą zgłaszane, w jaki sposób one będą usuwane. No i teraz w kontekście SLA ważne jest zrozumienie różnicy między błędami krytycznymi, niekrytycznymi, no i też usterkami, bo z reguły takie trzy pojęcia się pojawiają, czyli błędy krytyczne, niekrytyczne i usterki.

I teraz każda z tych kategorii wymaga z reguły trochę innego podejścia, no i też z reguły na nią są określane per kategoria różne czasy reakcji. I teraz błędy krytyczne z reguły rozumiane są jako te, które całkowicie uniemożliwiają korzystanie z systemu lub mają poważny wpływ na jego funkcjonowanie. Tu może być przykładem sytuacji, w której właśnie ten Twój koszyk zakupowy czy jakiś system rejestracji po prostu przestaje działać, a klienci nie mogą finalizować swoich zakupów.

Czyli to jest ten moment, kiedy przestaje działać taki najważniejszy proces biznesowy, który nagle właśnie np. odcina biznes od sprzedaży. Super krytyczne, trzeba to rozwiązać natychmiast, czyli od ręki.

Błędy niekrytyczne to takie, które nie wpływają na podstawowe funkcjonowanie systemu, ale mogą wprowadzać utrudnienia dla użytkowników. Tu może być przykładem niewłaściwy wyświetlający się obrazek, albo jakaś niepoprawna informacja w formularzu, albo np. koszyk, który działa trochę wolniej niż zazwyczaj.

Czyli to na pewno będzie wpływało na konwersję, ale to niekoniecznie będzie krytyczne, bo niekoniecznie wpłynie w taki sposób, że zatrzyma kompletnie wpływ zamówień. Z kolei usterki to sytuacje, które niekoniecznie są błędami, ale mogą wpływać na komfort korzystania z systemu. Mogą to właśnie być jakieś problemy z wydajnością, może być jakieś wolne ładowanie strony, ale mogą być też takie rzeczy, które wpływają na działanie systemu i też przez to zniechęcają użytkowników do korzystania z serwisu.

Czyli takie rzeczy, które teoretycznie nie wpływają na pierwszy rzut oka na system w sposób krytyczny czy nawet niekrytyczny, ale można je potraktować jako usterkę i tak też należałoby je zrealizować, czyli też w odpowiednio dłuższym czasie na reakcję. Teraz bardzo ważne jest, aby w SL-a określić, jak będą te usterki monitorowane, kto będzie dokonywał zgłoszeń, czy będą prowadzone jakieś regularne raporty np. dotyczące wydajności lub też czy będą prowadzone jakiekolwiek inne działania, które będą wspomagały ten proces uświadczenia usługi SL-a.

No i tutaj jest tak naprawdę, jeżeli chodzi o samą realizację tej usługi i też rozliczenia tej usługi, tutaj jest różnie, bo w ramach umowy SL-a mogą występować różne poziomy usług, które będą obejmowały nie tylko reakcje na błędy, ale też np. właśnie monitoring i utrzymanie infrastruktury IT, bo w dobrze zorganizowanej umowie SL-a czy usłudze SL-a ten monitoring też powinien być zapewniony. Z reguły usługodawca określa jakąś liczbę roboczych godzin miesięcznie i na tej podstawie proponuje stałą opłatę po prostu za ten monitoring i utrzymanie.

Sama kwestia reakcji na błędy krytyczne i niekrytyczne, tak jak u nas do tego podchodzimy, to jest po prostu realizacja i rozliczenie za przepracowany czas, ale to powoduje, że w przypadku awarii następuje od ręki reakcja i problem jest rozwiązywany, więc de facto płaci się po prostu za rzeczywiście naprawiony problem. To co ważne, staramy się zawsze kiedy jakieś problemy się pojawiają po czasie też zastanowić się w jaki sposób można by im było zapobiec czy zapobiegać na przyszłość i z tego też planować działania utrzymaniowo-rozwojowe, żeby danej awarii przynajmniej unikać długoterminowo, żeby ona się nie powtarzała. No i co, chyba to wszystko na dzisiaj.

Mamy wyjaśnione czym jest SL-a, wiesz na jakie elementy zwrócić uwagę w umowie, wiesz jaki czas reakcji na przykład my oferujemy, jak wygląda kwestia dyżurów, jak wygląda kwestia monitoringu i że powinno się na to też zwrócić uwagę, więc to są takie najważniejsze aspekty, a gdybyś chciał bądź chciała dowiedzieć się więcej na ten temat, to serdecznie zapraszam do kontaktu, chętnie pomogę Ci ustalić w jaki sposób powinieneś bądź powinnaś zadbać o SL-a, jakie rzeczy uznać jako krytyczne, jakie można uznać jako niekrytyczne i jak to zorganizować, czy to z naszą firmą, czy z jakąkolwiek inną. Jestem otwarty na tego typu konsultacje czy wsparcie, także serdecznie zapraszam. No i to już wszystko na dzisiaj.

Dzięki bardzo za wysłuchanie tego odcinka. Pamiętajcie, że odpowiednie zabezpieczenia mogą uratować Was przed niejednym kryzysem i dajcie znać co myślicie o tym odcinku i też jakie macie Wy doświadczenia z umowami SL-a, no i jakie tematy chcielibyście poruszyć w przyszłości. Jeżeli chodzi o spoiler następnego odcinka, poruszymy temat techniczny związany z architekturą systemów, jak ona wpływa na rozwój biznesu, czyli to bezpośrednie przełożenie nazwijmy to trudnej rzeczy technicznej, którą podejmuje się z reguły zasobami technicznymi, jaki to ma impact faktycznie na biznes.

Dzięki raz jeszcze za odsłuchanie 26 odcinka mojego podcastu i do usłyszenia w następnym 27 odcinku w przyszły wtorek. Dzięki i cześć.