Praktyczne ITSM w małej organizacji — incydenty, problemy, zmiany i wiedza

ITSM kojarzy się z rozbudowanym katalogiem usług, narzędziem klasy enterprise i formalnym wdrożeniem ITIL. Mechanizmy zarządzania usługami są jednak potrzebne również tam, gdzie nie ma osobnego service desku: trzeba przywracać działanie, usuwać przyczyny powtarzalnych problemów, bezpiecznie wprowadzać zmiany i zachowywać wiedzę o rozwiązaniach.

W firmie edukacyjnej odpowiadałem za środowisko około 60 laptopów, aplikacje używane podczas zajęć, lokalne usługi sieciowe, dostęp zdalny, dokumentację i wsparcie instruktorów. Skala była mniejsza niż w banku czy centrum danych, ale sprzęt i usługi były wykorzystywane operacyjnie: niedziałające stanowisko bezpośrednio wpływało na prowadzenie zajęć.

Usługa, nie pojedyncze urządzenie

Jednostką zarządzania nie był dla mnie „laptop”, lecz możliwość przeprowadzenia zajęć: właściwy system, aplikacje, materiały, wersje środowiska, połączenie sieciowe i instrukcja dla prowadzącego. Takie spojrzenie zmienia sposób rozwiązywania problemów. Naprawa jednego komputera nie wystarcza, jeśli ta sama przyczyna może wystąpić na pozostałych urządzeniach.

Obsługa incydentu

Praktyczny przepływ zgłoszenia wyglądał następująco:

zebranie od instruktora objawów i wpływu na zajęcia;
ustalenie, czy problem dotyczy jednego stanowiska, lokalizacji czy całej usługi;
sprawdzenie łączności, konfiguracji, wersji, logów i możliwości odtworzenia problemu;
przywrócenie działania albo zastosowanie bezpiecznego obejścia;
weryfikacja z użytkownikiem, że potrzebna funkcja rzeczywiście działa;
zapisanie rozwiązania lub aktualizacja instrukcji, jeżeli problem może wrócić.

Zdalny dostęp przez bezpieczną sieć prywatną, SSH i pulpit zdalny umożliwiał diagnozę bez fizycznego przewożenia każdego urządzenia. Procedury obejmowały także wariant awaryjny na wypadek niedostępności podstawowego kanału.

Od incydentu do problem management

Jednym z przykładów był serwer aplikacyjny, który odmawiał startu mimo zainstalowanej właściwej wersji środowiska Java. Samo ponowne uruchomienie procesu usuwałoby objaw tylko chwilowo. Analiza wykazała, że dołączony skrypt sprawdzał nazwę polecenia jak ścieżkę do pliku, dlatego poprawne środowisko było błędnie uznawane za niedostępne.

Poprawiłem sposób wykrywania polecenia, a zmianę dodałem do skryptu provisioningowego tak, aby była nakładana bezpiecznie zarówno na nowe, jak i wcześniej przygotowane urządzenia. Zaktualizowałem też opis przyczyny i procedurę uruchamiania. Jedna analiza problemu usunęła więc potencjalną klasę kolejnych incydentów.

Change management na przykładzie migracji floty

Migracja stanowisk na Linux nie była jedną operacją instalacyjną. Zmiana obejmowała wymagane aplikacje, dwie wersje Javy, ustawienia systemowe, lokalne serwery, reguły zapory, zdalne wsparcie, aktualizacje i instrukcje dla pracowników.

Proces zmiany zawierał:

analizę wykorzystywanych funkcji i zależności;
przygotowanie urządzenia testowego oraz testy na realnym sprzęcie;
identyfikację ryzyk i punktów wymagających ręcznej kontroli;
zmianę planu, gdy test wykazał brak obsługi automatycznej instalacji przez wybrany system;
idempotentny provisioning, który można uruchomić ponownie bez nadpisywania danych użytkowych;
test końcowy aplikacji, sieci i usług;
dokumentację wdrożenia, diagnostyki, aktualizacji i obsługi zgłoszeń.

Automatyzacja skróciła czas przygotowania stanowiska o około 90%. Ważniejszy był jednak powtarzalny stan: ten sam proces można było zastosować na kolejnych urządzeniach, a poprawkę wprowadzić centralnie zamiast ręcznie na każdym komputerze.

Knowledge management jako część usługi

Rozwiązanie techniczne bez dokumentacji tworzy zależność od osoby, która je wdrożyła. Dlatego procedury diagnostyczne, kroki wdrożenia, znane ograniczenia, sposoby aktualizacji i rozwiązania powtarzalnych problemów trafiały do bazy wiedzy. Materiały były pisane tak, aby pracownik mógł wykonać typową czynność samodzielnie, a osoba techniczna mogła szybko przejść do właściwego poziomu diagnozy.

Jak mierzyłem usprawnienia

W małej organizacji nie budowałem rozbudowanego katalogu SLA. Korzystałem z mierników bezpośrednio związanych z pracą:

czas przygotowania nowego stanowiska;
liczba ręcznych kroków i miejsc możliwej pomyłki;
odsetek konfiguracji możliwych do powtórzenia automatycznie;
możliwość rozwiązania typowego problemu na podstawie instrukcji;
wpływ incydentu na możliwość przeprowadzenia zajęć.

Granice doświadczenia

Nie przedstawiam tego projektu jako formalnego wdrożenia ITIL ani pracy w ServiceNow lub BMC. Jest to dowód wykonywania tych samych podstawowych działań w środowisku operacyjnym: rozpoznawania usług, obsługi incydentów, analizy przyczyn źródłowych, kontrolowania zmian, automatyzacji, dokumentowania i ciągłego doskonalenia.