ITblog

Ostatnim czasem, od kiedy zacząłem miewać problemy ze swoim dostawcą usług hostingowych, zacząłem się zastanawiać nad teorią świadczenia tego typu usług, czy też bardziej ogólnie: wszystkich usług z dziedziny telekomunikacji czy IT. Co sprawia, że serwis, z którego usług korzystamy spełnia nasze oczekiwania i jesteśmy z niego zadowoleni? Czy to tylko cena sprawia, że jesteśmy zadowoleni z serwisu, a może takie “drobnostki” jak możliwość dodzwonienia się do serwisu, “ludzki” język pomocy technicznej czy też może usługa, która “po prostu działa”?

Codziennie mam do czynienia z czynnikami, które w powszechnym mniemaniu składają się na dobre funkcjonowanie usług informatycznych. Szybkość działania, dostępność, pomoc w przypadku problemów. Tym postem chciałbym rozpocząć cykl pt. “Zarządzanie IT“, gdzie chciałbym pisać o teorii i praktyce zarządzania infrastrukturą IT, kontaktach z klientami i standardach usług, na podstawie moich doświadczeń z heldesków helpdesków, administracji IT i analizy statystyk. Może się komuś przyda.

Zacznę od SLA, które często jest mylone z czasem dostawy lub wydajnością, terminami często pokrewnymi.

SLA, czyli Service Level Agreement jest umową między klientem (usługobiorcą), a firmą świadczącą usługi (usługodawcą) określającą poziom i jakość świadczonych usług. Uwaga! Nie jest to umowa świadczenia usług, a jedynie umowa określająca ich poziom. Nie oznacza to, że SLA wchodzi w skład każdej umowy świadczenia usług, choć część dot. poziomu świadczenia tychże powinna znajdować się w każdej umowie.

Do czego stosuje się SLA? Historycznie termin ten został wprowadzony w życie w firmach telekomunikacyjnych do określania poziomu działania central telefonicznych i centrów pomocy. Do wyznaczania odpowiednich standardów i poziomów usług stosowało się tam definicje takie jak ABA – abandon rate (procent połączeń nieodebranych), ASA – average speed to answer (średni czas odebrania połączenia), FCR – first call resolution (procent problemów rozwiązanych podczas pierwszego kontaktu), TSF – time service factor (procent rozwiązanych problemów w zadanym przedziale czasowym). Wszystkie te czynniki składały się na określenie ogólnego poziomu SLA – poziomu świadczenia usług.

Wszyscy, którzy pracują w helpdeskach, call centrach, helplines i podobnych doskonale znają te wyznaczniki bo najprawdopodobniej omawiają je na wszystkich spotkaniach zespołu. Ciągły pressing na FCR, jak najkrótsze rozmowy, jak najwięcej odebranych połączeń. Żaden z tych współczynników nigdy nie osiągnie poziomu 100%, chyba że przypadkowo i przez krótki czas. Można jedynie marzyć o sytuacji, w której wszystko jest idealne, prawda?

Czy zatem jest SLA w praktyce w zastosowaniach IT? Zależy to od rodzaju usług, jakie są świadczone. Skupię się dzisiaj na firmie hostingowej.

Firma hostingowa świadczy usługi udostępniania zasobów swoich “serwerów internetowych” dla klientów. W teorii więc, klient dostaje określoną część dysku twardego, określoną część łącza internetowego, zawarty w pewnych granicach czasowych określony limit transferu i możliwość korzystania z palety usług, najczęściej WWW, DNS, email i FTP.

W praktyce, Jan Kowalski chce posiadać swoją stronę www, adres pocztowy i kilka megabajtów na pliki html i grafikę. Kontaktuje się więc z firmą hostingową i wykupuje podstawowy pakiet WWW, w którego skład wchodzi: darmowa rejestracja domeny, utrzymanie wpisów DNS na serwerach, 10 MB na stronę www, panel administracyjny konta, jedno konto ftp, 100MB na pocztę, 10 skrzynek w standardzie, filtr antyspamowy i 10GB transferu na miesiąc. Wszystko to, za jak to zwykle jest określane “jedynie” x euro (złotych). Ostatnią rzeczą, na którą Kowalski zwróci uwagę, będzie zapisane drobnym drukiem w umowie zdanie “usługodawca nie zobowiązuje się do utrzymania jakiegokolwiek SLA”. Kowalski i tak nie wie, co oznacza SLA, więc się tym nie przejmuje.
Po tygodniu poprawnego działania, serwer www nagle zaczyna działać bardzo wolno, na skrzynkę trafia już tylko spam, do pomocy technicznej nie można się dodzwonić bo ich numer telefonu nigdy nie był udostępniony, a ich odpowiedzi na emaile z prośbą o pomoc można streścić w jednym, krótkim zdaniu: “U nas działa”.

Co może źle działać w tak, jak może się wydawać, prostej usłudze wykupionej przez Jana Kowalskiego?

1. Rejestracja domeny – firma powinna określić w jakim czasie domena zostanie zarejestrowana (24h czy 48h) , kto jest rejestratorem domeny, powinna istnieć opcja ukrycia prywatnych danych (whois privacy), chociażby adresu email; inne ważne informacje, to kto jest kontaktem technicznym, do kogo zwracać się z prośbą o zmianę delegacji, dodanie poddomeny, dodanie nowego rekordu MX
2. DNS – firma powinna poinformować na ilu i na jakich serwerach będą przechowywane informacje dot. domeny, innymi słowy – jakie są serwery NS DNS i jakie są ich adresy IP (najlepiej jeśli nie znajdują się w tej samej podsieci), w jaki sposób użytkownik może modyfikować swoje wpisy w plikach strefy, jak często serwery DNS odświeżają swoją pamięć cache
3. Powierzchnia dyskowa – co się stanie, jeśli zostanie przekroczona, czy logi serwera www wchodzą w skład powierzchnia zajmowanej przez klienta, czy oddzielnie jest ujmowana powierzchnia na pocztę i na www, czy jest możliwość zmiany właściciela plików (chown) i ich dostępności (chmod), czy istnieje opcja backup, jeśli tak to w jakiej cenie, jak długo backup jest przetrzymywany, w jakich warunkach;
4. Dostęp do zmiany konfiguracji usług – co zawiera strona administracyjna a czego nie zawiera, czy istnieje możliwość zdefiniowania dodatkowych uprawnień dostępu do panelu administracyjnego i określenie rangi dostępu, czy panel konfiguracyjny znajduje się na innym serwerze, czy istnieje możliwość zmiany plików użytkownika poprzez panel administracyjny, czy istnieje możliwość dostępu do danych finansowych (płatności, informacje o karcie kredytowej), kto z firmy hostingowej ma dostęp do tych danych, w jakich językach dostępny jest panel administracyjny
5. FTP – czy można posiadać serwer ftp w poddomenie, czy jest to osobny serwer, ile może być jednoczesnych połączeń jednego użytkownika do serwera, ile można założyć kont ftp, jak zakładać konta, jak zmieniać hasła, czy transfer FTP wpływa na wykupiony transfer
6. Poczta – max. ilość skrzynek pocztowych, całkowita wielkość miejsca na pocztę, maksymalna wielkość jednej skrzynki, dostęp poprzez webmail, POP3, IMAP, czy jest dostępny serwer SMTP, czy jest autoryzacja, czy jest SSL, maksymalna wielkość wiadomości przychodzącej i wychodzącej, maksymalna ilość wysyłanych wiadomości/odbiorców jednej wiadomości, opcja newsletter, filtr antyspamowy: blacklisting, graylisting, whitelisting, FMX, email validation
7. www – jaka jest technologia serwera www, czy mogę stosować PHP/ASP/Ruby/Frontpage extensions, czy jest możliwość stosowania plików .htaccess, .htpasswd, jaka jest dostępna pamięć dla PHP, czy mogę wyłączyć zmienne globalne, czy jest SSL (https), czy mam dostęp do logów serwera WWW, jak często logi są archiwizowane, jaka jest maksymalna ilość jednoczesnych połączeń
8. baza danych – jaka jest technologia bazy danych, jaki jest limit ilości baz, miejsca na bazy, ilości połączeń na godzinę, ilości równoczesnych połączeń, czy baza jest dostępna “z zewnątrz”, czy istnieje możliwość kopii bazy, przywracania kopii bazy, jak modyfikować dostęp do bazy, hasła, jak zakładać nowe bazy, jak dowiedzieć się na jakim serwerze baza działa, czy mogę mieć bazę na tym samym serwerze co www, czy są dostępne logi serwera
9. Transfer – jak jest naliczany, dla jakiego ruchu, kiedy jest resetowany, czy jest wyrażony w kB (1024 bajty) czy w KB (1000 bajtów – jak w przypadku sprzedaży dysków twardych, gdzie 1GB = 1000 MB), czy istnieje możliwość sprawdzenia aktualnego stanu wykorzystanego pasma, jak często jest ta statystyka odświeżana, co się dzieje w przypadku przekroczenia limitów, ile kosztuje MB po przekroczeniu limitu
10. Ogólne – jakie są zabezpieczenia serwera, czy jest firewall, jaki ruch jest filtrowany, czy są zabezpieczenia przed (D)DoS, jakie jest zasilanie serwera, jakie są łącza, jaka jest pamięć i procesor serwera, jak szybkie są dyski (IDE, SATA, SCSI), czy jest dostępny RAID (mirror, RAID5, RAID10), backup, jak często wykonywana jest kopia, co się dzieje w przypadku awarii sprzętu czy oprogramowania, co się dzieje w przypadku awarii łącza/łączy, na jakim systemie działa serwer
11. Pomoc techniczna – czy działa 24/7/365, czy jest dostępny numer telefonu, czyj jest to numer darmowy, lokalny czy premium (extra płatny), ile jest darmowych ticketów pomocy technicznej, jaki jest czas reakcji pomocy technicznej, jak długo się czeka na telefonie by porozmawiać z inżynierem, jakie dane są wymagane przy kontakcie z pomocą, w jakich językach można rozmawiać z pomocą techniczną, kto może kontaktować się z pomocą w moim imieniu, czy jest adres email do PT (pomocy technicznej), jak szybko mogę spodziewać się odpowiedzi na email, jak szybko mogę spodziewać się rozwiązania problemu, czy jest dostępna strona ze statusem działania serwera, czy jest dostępna strona ze statusem mojego problemu, czy PT może do mnie zadzwonić, czy PT monitoruje działanie serwera, jeśli tak – jak często i co jest monitorowane

Jak widać, problemy są wszędzie. Doskonale wiem, że nie udało mi się wymienić wszystkich możliwych problemów i wszystkich pytań jakie można zadać przed zakupem, ale warto mieć świadomość co mieści się ramach usługi, którą wykupujemy.

Wróćmy więc do zagadnienia SLA. Niech firma hostingowa w porozumieniu z klientem w ramach SLA zobowiązuje się do 99.8% uptime, stworzenia ticketu pomocy technicznej w ciągu 20 minut i rozwiązania każdego problemu (oczywiście poza problemami niezależnymi od firmy, jak pożar, powódź i inne akty boskie) w ciągu 24 godzin.

Co oznacza 99.8% uptime? Oznacza to, że w ciągu 365 dni działania usługi firma zobowiązuje się do poprawnego działania usługi przez 364.27 dni w roku. Oznacza to, że firma może sobie pozwolić na 17.52 godzin niedziałania usługi na dowolny cel, który uzna za stosowny bądź konieczny: instalacja oprogramowania, instalacja uaktualnień, zmiana sprzętu, naprawa sprzętu, oprogramowania. 99.8% oznacza czas w jakim nasza usługa będzie działała zgodnie z założeniami. Te 0.2% to czas, jaki dopuszczamy na awarię.
I tutaj wkrada się problem i haczyk: firma zobowiązała się do naprawy każdego problemu w ciągu 24 godzin jednocześnie dając sobie 17.52 godzin na naprawy. Uważajcie co podpisujecie!

Dobra umowa definiuje w jaki sposób uptime jest mierzony: ping, monitorowanie działania konkretnych usług (httpd, vsftpd, postfix, etc)? W przypadku zwykłego ping’a monitorowanie nie jest takie skomplikowane, w przypadku konkretnych serwisów wymaga to już odpowiednich narzędzi. Firma powinna się też zobowiązać do odpowiedniego pasma gwarantowanego – nietrudno sobie wyobrazić, że 99.8% SLA może być zachowane dla ping’a 100ms jak i dla 3000ms, ale dla klienta końcowego czas 30 sekund na otwarcie strony www oznacza ewidentne problemy z działaniem usługi, mimo że strona po tym czasie otwiera się poprawnie, a SLA jest zachowane. Taki drobny szczegół w umowie.

20 minut na reakcję pomocy technicznej to zazwyczaj czas jaki jest potrzebny do przypisania odpowiedniego numeru sprawy do komunikatu od klienta (telefonicznego czy emailowego). W razie zgłoszenia problemu powinniśmy znać numer referencyjny i imię i nazwisko osoby, z którą rozmawialiśmy (czasami dobrze jest bezpośredni kontakt do technika, ale to już zależy od polityki podejścia do klienta, reguła zazwyczaj jest taka: lepszy serwis to spersonalizowany serwis). 20 minut to czas, w którym nikt do systemu jeszcze nie zajrzy, czy bardziej – nie naprawi systemu. To jedynie czas poświęcony na wysłanie pierwszego emaila, odpowiedź na telefon: “dziękujemy za zgłoszenie problemu, numer sprawy to XYZ”. Nie należy tutaj oczekiwać nic więcej!

24 godziny na rozwiązanie problemu – to jest ta trudna część. W jaki sposób rozwiązać wszystkie problemy w 24h? Kosztowne rozwiązanie – posiadanie zapasowego serwera, który można użyć po prostu zamieniając dyski, mniej kosztowne ale dłuższe – posiadanie części, które można wymienić. W przypadku awarii dysku – najlepiej gdyby firma posiadała szybki backup/restore, albo RAID5 z dyskami w hotswap.

Cała filozofia trudu, jakim jest SLA polega na odpowiednim dobraniu możliwości i szybkości działania w przypadku awarii do oczekiwań klienta. Każda dziesiąta część procenta to koszt, jaki firma musi ponieść w celu zagwarantowania działania usługi wykupionej przez klienta, czy jest to zmiana części, całego serwera, odzyskania danych z taśmy, restartu maszyny czy zakupu kosztowego firewalla “chroniącego” przed DDoS. Wszystko kosztuje, a to w jaki sposób menedżer odpowiedzialny za kształtowania działań IT w firmie hostingowej będzie operował tymi kosztami jest miarą sukcesu firmy. Nie jest trudnym reklamowanie 99.9% uptime, jeśli w rzeczywistości będzie to ledwie 80% tylko w pierwszym miesiącu działania usługi, prawdziwym sukcesem jest zagwarantowanie 80% przy rzeczywistym poziomie 99.9%!

Jeśli ten post wydaje się komuś nudnym, to ostrzegam że będzie więcej. W następnych odcinkach napiszę kilka słów o pomocy technicznej – jak działa, jak działać nie powinna, jakie są dobre praktyki i wzorce.