Usługi informatyczne - standardy jakości i procesy ITIL

Usługi informatyczne - standardy jakości w praktyce

Standard jakości usługi informatycznej to zapisany i mierzalny sposób postępowania, a nie przymiotnik w ofercie. Firma może ocenić dostawcę po tym, co dostawca mierzy i dokumentuje, a nie po deklaracjach w prezentacji. Ten tekst opisuje pojęcia ogólne, które pojawiają się w umowach o usługi IT, i nie zawiera deklaracji certyfikatu żadnej firmy.

Najczęściej wskazywane ramy to ITIL i norma ISO/IEC 20000-1. ITIL jest zbiorem praktyk zarządzania usługami, a certyfikat ITIL dotyczy osób, a nie organizacji. Norma ISO/IEC 20000-1 określa wymagania wobec systemu zarządzania usługami i pozwala na certyfikację organizacji. Ta różnica ma skutek praktyczny: zapis „usługi zgodne z ITIL” oznacza przyjęcie praktyk, a nie potwierdzenie przez audytora.

Reguła: standard jest wiarygodny tylko wtedy, gdy wskazuje mierzalną wartość i sposób jej odczytu z rejestru zgłoszeń.

Incydent a problem - różnica w praktyce

Za incydent uznaje się nieplanowane przerwanie działania usługi albo pogorszenie jej jakości. Celem jest szybkie przywrócenie działania, choćby rozwiązaniem tymczasowym. Problemem nazywa się przyczynę źródłową jednego incydentu lub wielu podobnych. Jego celem jest usunięcie przyczyny, aby zgłoszenia przestały wracać.

W przykładzie z serwerem plików technik zamyka pierwszy incydent, wstrzymując zadanie kopii, a rejestr rejestruje problem: harmonogram kopii pokrywa się z godzinami pracy. Trwałe rozwiązanie wymaga zmiany harmonogramu, więc problem kończy się dopiero wtedy, gdy zmiana zostanie wdrożona i przez kilka tygodni nie pojawią się nowe zgłoszenia.

Wykrywanie problemów w rejestrze

Problemy wykrywa się na podstawie powtarzalności. Zapytanie do rejestru zgłoszeń grupuje wpisy według kategorii i wskazuje te, które w ostatnich miesiącach pojawiły się wielokrotnie. Próg, na przykład pięć zgłoszeń, dobiera się do wielkości firmy. Nazwy tabeli i kolumn są przykładowe.

SELECT Kategoria,
       COUNT(*) AS LiczbaZgloszen
FROM dbo.Zgloszenie
WHERE Zgloszono >= DATEADD(MONTH, -3, SYSDATETIME())
GROUP BY Kategoria
HAVING COUNT(*) >= 5
ORDER BY LiczbaZgloszen DESC;

Kategoria z listy dostaje rekord problemu i właściciela. Analiza przyczyny źródłowej opiera się na pytaniu „dlaczego” zadawanym do skutku albo na diagramie przyczynowo-skutkowym. Wynikiem jest zmiana konfiguracji albo poprawka aplikacji, a nie kolejna instrukcja dla użytkownika.

Zarządzanie zmianą w środowisku IT

Większość poważnych awarii ma początek w niekontrolowanej zmianie: aktualizacji uruchomionej bez testu albo modyfikacji reguły zapory wykonanej z pamięci. W ITIL 4 praktyka ta nazywa się change enablement i polega na tym, że każda zmiana ma ocenę ryzyka i plan wycofania, a przed wykonaniem uzyskuje zatwierdzenie. Nie chodzi o biurokrację, lecz o zapis, który pozwala ustalić po fakcie zakres i termin zmiany.

Zmiana normalna przechodzi przez ocenę ryzyka, którą wykonuje osoba niezależna od wykonawcy. Rejestr zmiany zawiera pola pozwalające na późniejszy audyt. Dla aplikacji dedykowanych ta sama zasada obowiązuje przy wdrażaniu poprawek kodu, o czym mówi materiał o dedykowanych aplikacjach webowych a obsłudze IT.

• Opis zmiany - co jest zmieniane, na jakich systemach i w jakim celu.
• Ocena ryzyka - skutki niepowodzenia dla użytkowników i lista zależnych usług.
• Plan wycofania - kroki przywracające stan sprzed zmiany oraz czas, w którym się je wykonuje.
• Okno wdrożenia - termin uzgodniony z właścicielem usługi, najlepiej poza szczytem pracy.

Reguła: zmiana bez planu wycofania nie trafia na środowisko produkcyjne.

Poprawki systemowe i zgodność z rejestrem

Rejestr zmian odpowiada na pytanie, co zaplanowano, a stan serwera pokazuje, co zostało wykonane. Rozbieżność między nimi jest sygnałem, że ktoś zmienił środowisko poza procedurą albo że zmiana nie została zakończona. Proste porównanie zaczyna się od listy zainstalowanych poprawek systemowych, którą administrator zestawia z planem aktualizacji na dany miesiąc.

Get-HotFix |
    Sort-Object InstalledOn -Descending |
    Select-Object -First 10 HotFixID, Description, InstalledOn

Polecenie zwraca dziesięć ostatnich poprawek na komputerze, z datą instalacji. Brak poprawki z planu oznacza zmianę niewykonaną, a poprawka spoza planu wymaga wyjaśnienia w rejestrze. W większych środowiskach to samo robi konsola zarządzania aktualizacjami, ale zasada porównania planu ze stanem pozostaje ta sama.

Żądania usługi i katalog usług

Nie każde zgłoszenie jest incydentem. Prośba o założenie konta, dostęp do folderu lub instalację programu to żądanie usługi, czyli zdarzenie z góry przewidziane i wykonywane według procedury. Rozdzielenie żądań od incydentów porządkuje raporty: awarie mierzy się osobno, a żądania rozlicza według czasu realizacji i kosztu.

Katalog usług zbiera wszystko, co dostawca oferuje użytkownikom, wraz z zasadami zamawiania. Każda pozycja ma opis i właściciela oraz czas realizacji z zasadami zamawiania. Dobry katalog skraca rozmowy przy zamówieniach i ułatwia porównanie ofert kilku dostawców.

Modele realizacji żądań

Żądania realizuje się według jednego z dwóch modeli. W pierwszym technik wykonuje czynność ręcznie, zgodnie z listą kontrolną. W drugim proces jest zautomatyzowany: po zatwierdzeniu żądanie uruchamia skrypt, który zakłada konto i przypisuje grupy, a wynik zapisuje w rejestrze. Automatyzacja skraca czas realizacji i eliminuje pomyłki, ale wymaga utrzymania skryptu przy każdej zmianie struktury katalogu.

Inwentarz elementów konfiguracji

Praktyka zarządzania zasobami prowadzi rejestr elementów konfiguracji, czyli serwerów i aplikacji wraz z licencjami oraz zależnościami. Gdy zbliża się zmiana, administrator odczytuje z rejestru, które usługi zależą od zmienianego elementu. Zakres takiego inwentarza w umowie o obsługę pełną opisuje tekst o obsłudze informatycznej pod klucz, w tym podział ról między firmą a dostawcą.

Mierniki jakości i przegląd usług

Jakość usługi opisują wskaźniki, ale sposób ich liczenia bywa zwodniczy. Średni czas rozwiązania ukrywa zgłoszenia najdłuższe, bo jedna skrajnie długa sprawa podnosi średnią, a kilka szybkich ją obniża. Bezpieczniejszy zapis SLA opiera się na percentylu, czyli na wartości, poniżej której mieści się określony odsetek zgłoszeń.

SELECT DISTINCT Priorytet,
       PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY DATEDIFF(MINUTE, Zgloszono, Rozwiazano))
           OVER (PARTITION BY Priorytet) AS P90_Minuty
FROM dbo.Zgloszenie
WHERE Rozwiazano IS NOT NULL;

Zapytanie zwraca dla każdego priorytetu czas, w którym rozwiązano dziewięćdziesiąt procent zgłoszeń. Taki wskaźnik można wpisać do umowy jako cel, na przykład „dziewięćdziesiąt procent zgłoszeń o priorytecie drugim rozwiązanych w uzgodnionym czasie”.

Uzupełnieniem wskaźników twardych jest ocena użytkowników. Krótka ankieta po zamknięciu zgłoszenia, z jedną oceną i polem na uwagę, pokazuje, czy zgłoszenie zamknięte formalnie rozwiązało problem w odczuciu osoby, która go zgłosiła. Niska ocena przy dobrym czasie rozwiązania zwykle wskazuje na słabą komunikację, a nie na błąd techniczny.

Przegląd usług z klientem

Wskaźniki zmieniają się w decyzje dopiero na przeglądzie. Dostawca i klient przeglądają je co kwartał, porównując z celami z umowy, a następnie ustalają działania. Jeśli cel jest stale przekraczany, zwykle warto zmienić cel albo zakres usługi, a nie oczekiwać, że sytuacja poprawi się sama.

Dokumentacja i audyt jakości usług

Powtarzalność usługi zapewniają procedury operacyjne, czyli opisane instrukcje dla typowych zadań, na przykład zakładania kont albo przywracania kopii. Dzięki nim jakość nie zależy od tego, który technik przyjmie zgłoszenie. Procedury przegląda się po każdej zmianie w środowisku i po incydentach, w których okazały się nieprecyzyjne.

Dla zdarzeń dotyczących bezpieczeństwa istnieją osobne zalecenia. Amerykański instytut NIST publikuje wytyczne obsługi incydentów w dokumencie SP 800-61 Rev. 3, opisujące cały cykl od przygotowania po wyciąganie wniosków. Sam dokument nie jest normą obowiązującą firmę, ale dostarcza słownika i układu procedury, który można przenieść do własnych instrukcji.

Ciągłość działania i próby awaryjne

Standard jakości obejmuje także zachowanie usługi w razie poważnej awarii. Plan ciągłości działania opisuje, które usługi wracają do pracy w pierwszej kolejności i w jakim czasie. Ogólne zasady planowania odtwarzania po awarii przedstawia dokumentacja odzyskiwania po awarii w Microsoft Learn. Próba awaryjna, wykonana raz w roku, pokazuje, czy zapisane czasy odtworzenia są osiągalne.

Audyt wewnętrzny i test odtworzenia

Jakość weryfikuje się przez kontrole niezależne od codziennej pracy: przegląd kont uprzywilejowanych, test odtworzenia kopii i sprawdzenie, czy zmiany mają komplet zapisów. Wynik audytu trafia do przeglądu usług, a odchylenia dostają właściciela i termin usunięcia. Audyt bez działań następczych szybko staje się formalnością.

Ocena dostawcy pod kątem standardów

Standard jakości trzeba przełożyć na zapisy umowy, bo tylko one dają podstawę do rozmowy o niedotrzymaniu celów. Zapis o SLA bez sposobu pomiaru i bez konsekwencji bywa deklaracją, którą trudno egzekwować. Umowa powinna więc określać źródło danych do pomiaru oraz częstotliwość raportowania, a także sposób rozstrzygania sporów o dane.

Rekompensaty za niedotrzymanie celów

Wiele umów przewiduje rekompensaty w formie obniżenia opłaty, gdy wskaźnik spada poniżej uzgodnionego progu. Mechanizm działa wtedy, gdy próg jest jasno zdefiniowany, a pomiar prowadzi rejestr dostępny dla obu stron. Wysoka kara przy niejasnej definicji wskaźnika prowadzi do sporów, a nie do poprawy jakości, dlatego lepsze są niewielkie rekompensaty przy precyzyjnych pomiarach.

Deklaracja „profesjonalne usługi” nie mówi nic o sposobie pracy, więc przy wyborze dostawcy zadaje się pytania o konkretne mechanizmy. Poniższa tabela zestawia pytania z odpowiedziami, które brzmią wiarygodnie, oraz z sygnałami ostrzegawczymi.

Model współpracy ocenia się także według alternatyw. Outsourcing IT opiera się na elastycznej opłacie za usługę i szerokim zespole ekspertów dostępnych na żądanie, natomiast własny dział ma zespół na miejscu, ale ogranicza się do zatrudnionych osób, a skalowanie wymaga rekrutacji. Czas reakcji w outsourcingu wynika z SLA, a w dziale własnym z organizacji pracy.

SoftwareStudio Group Sp. z o.o. prowadzi produkcję oprogramowania i dostarcza rozwiązania w chmurze prywatnej opartej na platformie VMware, co widać w opisie oferty na stronie usług IT. W takich układach zakres SLA obejmuje też warstwę wirtualizacji, więc pytania o standardy dotyczą platformy i aplikacji jednocześnie. Kontekst chmury prywatnej opisuje artykuł o programach na zamówienie a chmurze i VMware.

Inne strony tego serwisu rozszerzają temat o warianty usługi: bieżącą pracę zdalną omawia tekst o usługach informatycznych w Poznaniu z kanałami zgłoszeń, a projekty wdrożeniowe opisuje materiał o usługach informatycznych dla firm w projektach. Zestaw ról po stronie firmy i dostawcy opisuje strona o usługach IT dla firm w Poznaniu, a rodzaje firm branży omawia tekst o firmie informatycznej. Dla porównania zakresów ofert warto przejrzeć też stronę o outsourcingu IT w Poznaniu oraz opis software house.