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

Usługa, nie pojedyncze urządzenie

Nie pilnowałem laptopów, tylko tego, żeby dało się poprowadzić zajęcia: system, programy, materiały, wersje środowiska, sieć i instrukcja dla prowadzącego. To zmienia sposób naprawiania rzeczy. Naprawienie jednego komputera nic nie daje, jeżeli ta sama przyczyna czeka na pozostałych.

Obsługa incydentu

Zgłoszenie prowadziłem tak:

pytam instruktora, co widzi i czy da się prowadzić zajęcia;
ustalam, czy to jedno stanowisko, jedna lokalizacja czy wszystko;
sprawdzam sieć, konfigurację, wersje, logi i próbuję powtórzyć błąd;
przywracam działanie albo daję bezpieczne obejście;
potwierdzam z użytkownikiem, że rzecz naprawdę działa;
zapisuję rozwiązanie albo poprawiam instrukcję, jeżeli problem może wrócić.

Dzięki bezpiecznemu dostępowi zdalnemu mogłem szukać przyczyny bez przewożenia sprzętu. Na wypadek niedostępności tego kanału procedura opisywała drogę awaryjną.

Od incydentu do problem management

Jednym z przykładów był serwer aplikacyjny, który odmawiał startu mimo poprawnie zainstalowanego środowiska. Samo ponowne uruchomienie procesu usuwałoby objaw tylko chwilowo. Przyczyną było błędne wykrywanie zależności przez dołączony skrypt.

Poprawiłem wykrywanie polecenia i wpiąłem tę zmianę w skrypt provisioningowy tak, żeby bezpiecznie nakładała się i na nowe, i na wcześniej przygotowane maszyny. Opisałem przyczynę i poprawiłem procedurę uruchamiania. Jedno dojście do sedna zdjęło z głowy całą serię przyszłych zgłoszeń.

Change management na przykładzie migracji floty

Przeniesienie stanowisk na Linux to nie była jedna instalacja. Trzeba było uwzględnić programy, zależności, ustawienia systemu, lokalną infrastrukturę, zasady dostępu, aktualizacje, wsparcie i instrukcje dla pracowników.

Po kolei:

sprawdziłem, z jakich funkcji naprawdę korzystają i co od czego zależy;
przygotowałem maszynę testową i testowałem na prawdziwym sprzęcie;
wypisałem ryzyka i miejsca, w których ktoś musi zajrzeć ręcznie;
zmieniłem plan, kiedy test pokazał, że wybrany system nie obsłuży instalacji automatycznej;
napisałem provisioning idempotentnie, żeby dało się go puścić drugi raz bez kasowania danych użytkownika;
przetestowałem na koniec programy, sieć i usługi;
opisałem wdrożenie, diagnostykę, aktualizacje i obsługę zgłoszeń.

Konfiguracja stała się powtarzalna, a poprawkę wprowadzało się w jednym miejscu zamiast klikać po kolei na każdym komputerze.

Knowledge management jako część usługi

Rozwiązanie bez dokumentacji uzależnia firmę od osoby, która je zrobiła. Dlatego do bazy wiedzy trafiały procedury diagnostyczne, kroki wdrożenia, znane ograniczenia, sposoby aktualizacji i gotowe odpowiedzi na powtarzalne problemy. Pisałem je tak, żeby zwykły pracownik poradził sobie z typową czynnością sam, a ktoś techniczny od razu wiedział, gdzie zacząć szukać.

Jak mierzyłem usprawnienia

Nie budowałem rozbudowanego katalogu SLA, bo w tej skali nie miałby sensu. Patrzyłem na rzeczy, które widać w pracy:

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ęć.