Utrzymanie Systemów Informatycznych

Utrzymanie Systemów IT – Czy Jest Potrzebne i Dlaczego Tak

“Geneza wszystkiego”

Pierwotnie systemy informatyczne były trudne, nieznane i dosłownie kosmicznie drogie przez co też niedostępne i zarezerwowane tylko dla wielkich odbiorców takich jak gigantyczne instytucje finansowe czy czołowe światowe mocarstwa inwestujące w systemy związane z obronnością i energetyką.

Wraz z rozwojem informatyki, systemy stały się bardziej dostępne i zaczęły usprawniać kluczowe i pracochłonne procesy w firmie, zwiększając wydajność procesów biznesowych i komfort pracy. Współcześnie coraz więcej przedsiębiorstw przez dedykowane oprogramowanie zabezpiecza kompleksowo wszystkie procesy mające miejsce w firmie takie jak Zarządzanie, Kadry i płace, Finanse i księgowość, Produkcja, Logistyka, Sprzedaż, czy Serwis. Spotykamy się coraz częściej ze stwierdzeniem, że “Firma” to “System”. Powszechnie wiadomo, że gwarantem przetrwania biznesu jest jego ciągły rozwój i doskonalenie rozwiązań, a co za tym idzie również ciągły i adekwatny rozwój systemów informatycznych, połączony z pracami konserwacyjnymi przeprowadzanymi regularnie na wszystkich elementach składowych wchodzącymi w skład środowiska produkcyjnego.

1. Co oznacza pojęcie “Utrzymanie systemu” w projektach IT?

Utrzymanie systemów it (rów. konserwacja oprogramowania, ang. Maintenance) – to najkrócej mówiąc modyfikacje oprogramowania po jego dostarczeniu mające na celu skorygowania błędów, aby poprawić wydajność lub inne własności systemów it.

Do kluczowych problemów utrzymania oprogramowania w systemach it należą problemy zarówno zarządcze, jak i techniczne. Istotnymi kwestiami zarządczymi są: dostosowanie do priorytetów klientów, odpowiedni personel utrzymujący systemy, szacowanie kosztów.

Kluczowymi kwestiami technicznymi są: ograniczone zrozumienie, analiza wpływu, testowanie, pomiar stopnia możliwości konserwacji systemu i utrzymanie infrastruktury.

2. Na czym polega utrzymanie systemów IT?

Utrzymanie systemu to głównie obsługa zgłoszeń serwisowych:

Obsługa zgłoszeń helpdesk’owych (Issues/Tickets) w systemach wspierających zarządzanie projektami it (do najpopularniejszych należą JIRA, Redmine).
Diagnostyka, potwierdzanie i identyfikacja problemów zgłoszonych przez klienta. Rozwiązywanie problemów lub nadzór nad realizacją zgłoszeń.
Kontakt z klientem i innymi członkami zespołów biorących udział w realizacji zgłoszenia. Planowanie realizacji zgłoszeń, określenie terminu i sposobu realizacji.

Czynności Serwisowe, inaczej konserwacyjne związane z utrzymaniem środowisk produkcyjnych systemów informatycznych:

Opieka nad środowiskiem systemowym (Serwery Aplikacyjne)

Analiza zajętości zasobów. Oczyszczanie przestrzeni dyskowej z niepotrzebnych plików.
Aktualizacja oprogramowania systemowego i narzędziowego.
Usuwanie awarii i rozwiązywanie problemów związanych z infrastrukturą IT.
Monitoring zasobów oraz kluczowych procesów biznesowych.
Analiza aktualnej konfiguracji i wdrożenie dobrych praktyk poprawiających wydajność i bezpieczeństwo.

Opieka nad środowiskiem bazodanowym

Administracja bazami danych.
Tworzenie i odtwarzanie backupów.
Monitoring procesów bazodanowych.
Analiza kosztów zapytań i ich optymalizacja (np. SQL Tuning).
Analiza zajętości przestrzeni dyskowej (np. redukcja zadeklarowanej przestrzeni dla różnych tablespace).

Czynności naprawcze i rozwojowe:

Nadzór, przygotowywanie i wykonywanie Aktualizacji Systemu dziedzinowego.
Aktualizacje związane z wydaniem nowych rozszerzeń (Features).
Aktualizacje związane z naprawą błędów (FiX i HotFix).
Prace serwisowe mające na celu wdrożenie zmian, poprawek błędów czy rekonfiguracji.
Dostosowanie funkcjonalności oprogramowania do nowych potrzeb (Features).
Przeprowadzanie wywiadu z klientem celem zebrania danych potrzebnych do analizy problemów zarówno rozwojowych jak i naprawczych.
Przeprowadzanie testów manualnych i automatycznych związanych ze zmianami zarówno naprawczymi jak i w zakresie nowych funkcjonalności. W zależności od zaangażowania i przyjętego modelu może to być realizacja wszystkich rodzajów testów wykonywanych w procesie produkcji oprogramowania, czyli testy jednostkowe (Deweloperskie) najczęściej w ujęciu automatyzacji jeśli jest wdrożona. Tradycyjnie testy integracyjne, Systemowe, Dymne, Akceptacyjne.

Świadczenie usług Wsparcia – jest nieodzownym elementem dobrej umowy utrzymaniowej:

Zapewnienie wsparcia użytkowników systemów it w zakresie merytorycznym (funkcjonalność).
Wsparcie techniczne świadczone przez specjalistów posiadających doświadczenie i dedykowane umiejętności, realizujących konsultacje informatyczne mające na celu pomoc w utrzymaniu, rozwiązanie problemów wymagających wiedzy specjalistycznej z zakresu IT (np.: Administracja Systemami UNIX, Windows Server, rozwiązywanie problemów sieciowych, Administracja bazami danych).
Wsparcie i wdrożenie nowych rozwiązań opartych o dedykowane narzędzia i aplikacje informatyczne.
Integracja z produktami i utrzymanie dedykowanych rozwiązań innych dostawców.
Nadzór i wsparcie nad realizacją Aktualizacji Systemowych, gdy są one realizowane przez Zamawiającego.
Analiza potrzeb klienta i doradztwo w doborze odpowiedniego narzędzia.
Realizacja konsultacji technicznych i merytorycznych związanych z różnymi dziedzinami.
Przeprowadzanie szkoleń z nowych i bieżących funkcjonalności Systemów it.
Tworzenie i rozwój dokumentacji.
Wizyty serwisowe w siedzibie klienta.

3. Dlaczego projekt wymaga umowy utrzymaniowej?

„Czemu występują błędy w systemie, który został przetestowany i odebrany?”

Każdy system od momentu wdrożenia potrzebuje “pewnej” ilości czasu, aby zacząć pracować optymalnie. Długość tego okresu zależy głównie od stopnia złożoności systemów oraz ich dziedziny i nazywa się go potocznie “wygrzewaniem”. Nawet najlepiej napisany i przetestowany program obdarzony jest tą cechą gdyż środowisko, w którym przeprowadzane są prace deweloperskie i testy nigdy nie odzwierciedla w 100% docelowego środowiska produkcyjnego, a w niektórych przypadkach mając na uwadze skale i typ danych jest to nawet niemożliwe. Mówiąc bardzo ogólnie, system został dostosowany na etapie produkcji do innego środowiska niż to, w którym będzie mu dane pracować w przyszłości.

“To już Historia…”

Historycznie w 1969 roku zostaje przez Meira M. Lehmana sformułowane pojęcie konserwacji i ewolucji aplikacji wchodzących w skład systemów it . Kolejne dwadzieścia lat badań w tym obszarze doprowadziły do sformułowania prawa Lehmana (Lehman 1997) które definiuje, że utrzymanie systemów it jest tak naprawdę rozwojem ewolucyjnym aplikacji i że decyzje związane z utrzymaniem systemów są wspomagane przez zrozumienie tego co dzieje się w systemie (i oprogramowaniu) na przestrzeni czasu. Lehman wykazał, że systemy ewoluują w czasie. Wraz z ewolucją stają się coraz bardziej złożone, chyba że podjęte zostaną pewne działania, takie jak refaktoryzacja kodu w celu zmniejszenia jego złożoności.

Dwóch mężczyzn pracuje nad błędami informatycznymi

4. Utrzymanie a rozwój

Problemy dotyczące tematu utrzymania systemów informatycznych mają zasadniczo dwa główne źródła. Pierwsze to te powstałe w wyniku normalnego użytkowania, jak również te powstałe w skutek licznych czynności mających na celu zmiany, naprawy i rekonfigurację systemu. Wszystkie te działania prowadzą w sposób naturalny do powolnej degradacji systemu informatycznego jak i innych elementów zależnych, wchodzących w skład środowiska produkcyjnego. (Tu przykład: źle wprowadzone czy uszkodzone dane, archiwalne logi z działania aplikacji pracujących w ramach rozwiązania, stare niepotrzebne pliki i inne “śmieci” pozostawione przez użytkowników).

Drugim źródłem jest doświadczenie wynikające z ewolucji rozwiązania zaimplementowanego w aplikacjach wymuszona postępem i zmianami czynników zewnętrznych. Oprogramowanie musi się ciągle zmieniać, by móc się dostosować do nowych wymagań.

Z uwagi na bardzo dynamiczny postęp, który jest nieuchronny i najbardziej odczuwalny w obszarze IT, nie należy zbyt długo zwlekać z dostosowywaniem systemu do nowych wymagań, gdyż zaniedbania mogą doprowadzić do sytuacji, gdy nie opłaca się dostosowywać rozwiązania, gdyż zasięg refaktoryzacji jest tak ogromny, że taniej jest stworzyć system od nowa. Tworzenie nowego oprogramowania to nie kupno nowego auta z szybką i łatwą przesiadką.

Koszt wytworzenia, wdrożenia i utrzymania nowego rozwiązania, które będzie bazowało na starych danych, często trzeba migrować do nowego modelu. Migracja danych może okazać się bardzo problematyczna i ryzykowna. Dodatkowo trzeba brać pod uwagę wdrożenie nowego rozwiązania, szkolenia personelu, szkolenia dla klientów i często też zakup nowego sprzętu, a czasami nawet zatrudnienie specjalistów do jego obsługi. Przykładem może być stara baza danych, która jest już niewspierana przez producenta. Rodzi to problemy z bezpieczeństwem i brakiem możliwości integracji z nowszymi systemami.

Po aktualizacji bazy danych na nowszą lub zupełnie inną wersję innego producenta okazuje się, że oprócz problemów z migracją danych stał się konieczny zakup nowych urządzeń sieciowych, stacji roboczych i serwerów z nowymi systemami operacyjnymi, które nie są już kompatybilne z technologiami użytymi pierwotnie w procesie wytwarzania aplikacji, którego baza była najważniejszą częścią. Firma nagle po paru latach zaniedbań w obszarze rozwoju i utrzymania systemu, staje nad przepaścią, musi jednorazowo wyłożyć bardzo duże środki, ponieść ryzyko związane z migracją danych, a czasami nawet utratą danych. Wdrażanie kompleksowo olbrzymiej ilości zmian, które mogą przez dłuższy czas bardzo negatywnie wpływać na pracę personelu przez ograniczoną dostępność kluczowych funkcjonalności systemu, często wpływa na spadek produktywności, skuteczność zarządzania i wyników finansowych.

Innym przykładem będzie system sprzedażowy przeznaczony do obsługi klientów pewnej firmy produkcyjnej. W 2001 roku firma mieściła się w baraku i zatrudniała 10 pracowników. Wydawało się, że liczba kontrahentów nigdy nie przekroczy 10 tyś. a przetwarzanie danych w chmurze i interakcja z platformami sprzedażowymi, reklamowymi i rozliczeniowymi innych firm wydawało się jakimś S-F.

W przeciągu 20 lat rozwoju firmy wymagania dotyczące funkcjonalności zmieniały się kilkukrotnie. Bez ciągłego i systematycznego rozwijania i dostosowywania, system stałby się bardzo szybko przestarzały i w znaczącym stopniu spowalniał, a nawet uniemożliwiał dalszy rozwój biznesu.

„it’s not a bug, it’s a feature”

Uważa się, że utrzymanie systemów it obejmuje tylko usuwanie błędów w systemie. Jednak jedno z badań wskazuje, że większość, tj. ponad 80% nakładów konserwacyjnych, ponoszonych jest na wszelkie prace nie naprawcze (Pigosky 1997). To poczucie utrwalane jest przez użytkowników składających zgłoszenia problemów, które w rzeczywistości okazują się rozszerzeniami funkcjonalności systemów it (żargonowe: „it’s not a bug, it’s a feature”).

5. Co to jest SLA i jakie są jego warunki?

SLA (z ang. Service Level Agreement) – to umowa o gwarantowanym poziomie świadczenia usług. To dokument szczególny, określający na jakim minimalnym poziomie dostawca świadczyć będzie określone usługi klientowi. Dla odbiorcy usług, SLA powinna być najważniejszym elementem porozumienia z dostawcą.

Co powinno zawierać SLA ?

Dobrze skonstruowana umowa o gwarantowanym poziomie świadczonych usług powinna zawierać następujące elementy:

Wymagany poziom dostępności – zapewnienie poziomu dostępności jest zwykle określany jako procent czasu dostępności usługi w ciągu roku. Zakres należy go dostosować do realnych potrzeb klienta wynikających z analizy procesów biznesowych w danej organizacji.
Sposób i formę zgłaszania problemów z działaniem usługi – na przykład konkretne adresy email bądź telefony, które należy wykorzystać do kontaktów z dostawcą w sytuacjach awaryjnych. W tym miejscu powinny być też godziny, w jakich możesz zgłaszać problemy. Przykładowo, jeżeli Twoja firma nie pracuje w nocy, być może wystarczy zakres od godziny 8 do 18.
Czas reakcji i rozwiązania problemu – to określenie po jakim czasie dostawca ma obowiązek zająć się zgłoszonym problemem oraz ile ma czasu na rozwiązanie go. Pamiętając o koszcie za minutę niedostępności, im ten czas jest krótszy, tym lepiej i tym niższe straty dla firmy. Zwróć też uwagę, że jest to czas maksymalny – zwykle dostawca będzie dążył do jak najszybszego usunięcia awarii.
W uzasadnionych przypadkach mogą wystąpić wyjątki, zwykle dotyczą one działania tzw. siły wyższej.
Proces monitorowania i raportowania poziomu usługi – czyli sposób prowadzenia nadzoru nad funkcjonowaniem usługi, zbieranie statystyk, co pozwala na dostęp do statystyk przez dedykowane aplikacje wspierające proces zarządzania ewidencjonujące pracę w ramach organizacji.
Niedopełnienie warunków umowy – gdyby dostawca nie wywiązał się z wymagań, jakie stawia przed nim SLA, poniesie konsekwencje. Mogą one obejmować prawo klienta, do zerwania umowy, lub otrzymania odszkodowania za straty poniesione w wyniku niedostępności usługi. Jest to Twoja polisa ubezpieczeniowa na wypadek, gdyby Wykonawca narażał Zamawiającego na straty przez swoje zaniedbania czy luźne podejście do koncepcji “obsługa klienta”.

Certyfikaty

* * *

Powrót