Oprogramowanie na zamówienie a obsługa IT - kto utrzymuje system po wdrożeniu

Oprogramowanie na zamówienie a obsługa IT - podział ról po wdrożeniu

Zespół, który napisał oprogramowanie na zamówienie, zwykle składa się z analityków, programistów, specjalistów od baz danych i wdrożeniowców. Ten zespół kończy pracę w dniu odbioru, a system zaczyna wtedy żyć własnym życiem: serwer wymaga aktualizacji, baza rośnie, a użytkownicy zgłaszają nowe sytuacje, których nikt nie przewidział. Obsługa IT to praca, która utrzymuje system w stanie używalnym po zakończeniu projektu.

Częsty błąd polega na założeniu, że kto napisał aplikację, ten ją również utrzymuje. Wykonawca oprogramowania odpowiada za kod i jego poprawki. Serwer oraz sieć i konta użytkowników leżą zwykle po stronie działu IT albo firmy świadczącej obsługę informatyczną. Bez zapisania tego podziału zgłoszenie „program nie działa” krąży między dwiema stronami, z których każda uważa, że problem leży u drugiej.

Tabela odpowiedzialności

Poniższy podział jest typowy, ale każda umowa powinna go potwierdzić na piśmie.

Model, w którym wszystko robi jeden podmiot, jest prostszy w komunikacji, lecz rzadko tańszy. Porównanie wariantów obsługi znajduje się w artykułach o obsłudze informatycznej i o outsourcingu informatycznym. Poniższe sekcje opisują, co trzeba uzgodnić w każdym z obszarów tabeli.

Środowisko testowe i produkcyjne

Zmiana wprowadzona bezpośrednio na serwerze, z którego korzystają pracownicy, jest najczęstszą przyczyną awarii po wdrożeniu. Dlatego system na zamówienie powinien działać co najmniej w dwóch środowiskach. Testowe służy do sprawdzania nowych wersji i poprawek, produkcyjne obsługuje pracę firmy. Osobne środowisko rozwojowe ma sens w projektach, w których zmiany są częste.

Środowisko testowe musi odzwierciedlać produkcyjne w tych elementach, które wpływają na zachowanie aplikacji: wersji SQL Server, ustawieniach sortowania bazy, wersji platformy .NET i konfiguracji integracji. Dane testowe pochodzą zwykle z kopii produkcyjnej po zanonimizowaniu pól osobowych, aby test przebiegał na realnym wolumenie, a jednocześnie nie ujawniał danych klientów.

Konfiguracja przypisana do środowiska

Ciągi połączeń oraz adresy integracji i klucze API różnią się między środowiskami, więc nie należą do kodu, tylko do pliku konfiguracji albo magazynu sekretów. Ta sama paczka aplikacji trafia wtedy na test i na produkcję, a różni je wyłącznie konfiguracja. Rozwiązanie eliminuje klasę błędów, w której wersja sprawdzona na teście zachowuje się inaczej po ręcznej zmianie ustawień na produkcji. Zmiany konfiguracji wymagają zapisu w rejestrze zmian równie skrupulatnie jak zmiany kodu, bo także one bywają przyczyną awarii.

Ścieżka wydania wersji

Każda poprawka przechodzi tę samą drogę: zmiana w kodzie, przegląd, wdrożenie na test, akceptacja przez użytkownika, wdrożenie na produkcję w uzgodnionym oknie serwisowym. Skrócenie tej drogi przy pilnym błędzie jest możliwe, ale powinno być zapisane jako procedura awaryjna, a nie zwyczaj. Warto też zachować możliwość powrotu do poprzedniej wersji, czyli kopię plików aplikacji i kopię bazy sprzed wdrożenia.

Kopie zapasowe oraz wskaźniki RPO i RTO

Kopia zapasowa jest jedynym elementem obsługi IT, którego brak ujawnia się dopiero w największym kryzysie. Dwa wskaźniki opisują wymagania wobec niej. RPO (Recovery Point Objective) mówi, ile danych firma może stracić, czyli jak stara może być kopia użyta do odtworzenia. RTO (Recovery Time Objective) mówi, jak długo system może być niedostępny. Definicje tych metryk opisuje dokumentacja Microsoft Learn o metrykach niezawodności.

W SQL Server możliwości odzyskiwania zależą od modelu odzyskiwania bazy. Przy modelu SIMPLE dziennik transakcji jest okresowo obcinany, więc odtworzenie sięga tylko do ostatniej kopii pełnej. Przy modelu FULL możliwe są kopie dziennika transakcji i odtworzenie bazy do wybranego punktu w czasie. Przegląd kopii opisuje dokumentacja SQL Server.

Zapis harmonogramu nie wystarcza. Kopia, której nigdy nie próbowano odtworzyć, pozostaje założeniem. Dlatego plan obsługi powinien zawierać cykliczny test odtworzenia bazy na osobnym serwerze oraz kontrolę, czy kopie faktycznie powstają.

Reguła: RPO i RTO ustala zamawiający na podstawie kosztu przestoju. Strategię kopii spełniającą te wartości dobierają wykonawca i dział IT.

Retencja kopii

Kopie przechowuje się w kilku generacjach: dobowe przez kilka tygodni, miesięczne dłużej, zgodnie z potrzebami firmy i wymogami dotyczącymi danych. Kopia na tym samym dysku co baza nie chroni przed awarią dysku, dlatego jedna generacja trafia na osobny nośnik lub do innej lokalizacji. Kopie zawierające dane osobowe podlegają tym samym zasadom ochrony co baza, więc powinny być szyfrowane, a dostęp do nich ograniczony.

Kontrola wieku ostatniej kopii

Prostą kontrolę można oprzeć na tabeli historii kopii w bazie msdb. Poniższe zapytanie jest przykładowe i pokazuje pięć ostatnich kopii wybranej bazy wraz z ich typem.

SELECT TOP (5)
       database_name,
       type,                -- D = pełna, I = różnicowa, L = dziennik
       backup_finish_date
FROM   msdb.dbo.backupset
WHERE  database_name = N'PrzykladowaBaza'
ORDER BY backup_finish_date DESC;

Zadanie SQL Agent może uruchamiać takie zapytanie regularnie i zgłaszać alarm, gdy najnowsza kopia jest starsza niż uzgodniony próg. Wtedy brak kopii ujawnia się po godzinach, a nie w dniu awarii.

Monitoring i reakcja na incydenty

Monitoring odpowiada na pytanie, czy system działa, zanim zapyta o to użytkownik. Aplikacja na zamówienie powinna udostępniać punkt kontrolny, na przykład adres, który zwraca stan aplikacji i jej połączenia z bazą. Framework ASP.NET Core ma do tego wbudowany mechanizm kontroli stanu opisany w dokumentacji Microsoft Learn.

Alarmy wymagają progów dobranych do rzeczywistego obciążenia. Zbyt czuły alarm generuje wiadomości, które po tygodniu przestają być czytane, a zbyt łagodny reaguje dopiero wtedy, gdy użytkownicy zdążyli już zadzwonić. Progi warto przeglądać po pierwszych miesiącach pracy systemu, kiedy widać zwykły rytm obciążenia w ciągu dnia i miesiąca.

Zgłoszenie serwisowe i jego priorytet

Zgłoszenie bez danych diagnostycznych wydłuża naprawę, bo pierwsza rozmowa służy tylko ustaleniu, co się stało. Dobre zgłoszenie zawiera cztery informacje.

• Opis objawu - co użytkownik robił i co zobaczył zamiast oczekiwanego wyniku.
• Kroki odtworzenia - kolejność czynności prowadząca do błędu, jeśli błąd jest powtarzalny.
• Wersja i czas - numer wersji aplikacji oraz dokładna godzina zdarzenia, potrzebne do przejrzenia dziennika.
• Skutek dla pracy - liczba osób i procesów dotkniętych błędem, według której ustala się priorytet.

Priorytety oraz czasy reakcji ustala umowa serwisowa, której kryteria oceny opisuje artykuł o dostawcy oprogramowania na zamówienie.

Aktualizacje platformy i zgodność aplikacji

Aplikacja działa na platformie, która ma własny cykl życia. Windows Server oraz SQL Server i platforma .NET mają daty końca wsparcia, po których producent nie publikuje poprawek bezpieczeństwa. Przegląd zasad wsparcia opisuje strona Microsoft Learn o końcu wsparcia SQL Server. System na zamówienie, który działa na wersji po końcu wsparcia, jest podatny na błędy, których nikt już nie naprawi.

Aktualizacja platformy wymaga testu regresji, czyli sprawdzenia, czy funkcje aplikacji działają po zmianie. Wykonawca oprogramowania przygotowuje listę scenariuszy krytycznych dla procesu, a dział IT wykonuje aktualizację najpierw na środowisku testowym. Bez takiego układu aktualizacja bywa odkładana, aż przestaje być możliwa bez przepisania części kodu.

Przegląd wersji platformy

Raz w roku warto wykonać przegląd, który obejmuje listę serwerów i wersje systemu oraz SQL Server. Do tego dochodzą data końca wsparcia każdej wersji oraz plan migracji z wyprzedzeniem. Dzięki temu koszt aktualizacji da się zaplanować, zamiast reagować na pilną potrzebę. Wykonawca oprogramowania dopisuje do przeglądu informację o zgodności aplikacji z nowszymi wersjami platformy.

Hosting i wirtualizacja

Miejsce działania systemu wpływa na zakres obsługi. Serwer własny wymaga opieki nad sprzętem i zasilaniem, maszyna wirtualna w chmurze przenosi część tych zadań do dostawcy. Dostawca usługi chmurowej nie przejmuje jednak obsługi aplikacji ani bazy. Mechanizmy wirtualizacji opisuje artykuł o programach na zamówienie w chmurze i VMware.

Uprawnienia i bezpieczeństwo w utrzymaniu

Utrzymanie systemu wymaga dostępu do serwera i bazy, a każdy taki dostęp jest ryzykiem. Zasada najmniejszych uprawnień oznacza, że konto aplikacji oraz konta administratora i programisty wykonawcy mają tylko te prawa, które są potrzebne do ich zadań. Konto, którego aplikacja używa do połączenia z bazą, nie powinno być administratorem SQL Server. Wystarczy rola z uprawnieniami do odczytu i zapisu w schemacie aplikacji.

CREATE ROLE rola_aplikacji;
GRANT SELECT, INSERT, UPDATE ON SCHEMA::dbo TO rola_aplikacji;
ALTER ROLE rola_aplikacji ADD MEMBER konto_aplikacji;

Przykład pokazuje jedynie mechanizm ról. Zakres uprawnień w rzeczywistym projekcie wynika ze specyfikacji, a ich opis znajduje się w dokumentacji uprawnień SQL Server.

Dostęp wykonawcy do środowiska produkcyjnego

Programista wykonawcy potrzebuje czasem wglądu w dziennik lub dane, aby zdiagnozować błąd. Dostęp nadaje się na czas zgłoszenia, na koncie imiennym, z zapisem w rejestrze zmian, a po zakończeniu prac cofa. Wspólne hasło administracyjne, znane kilku osobom, uniemożliwia ustalenie, kto wprowadził zmianę.

Model obsługi - dział wewnętrzny czy firma zewnętrzna

Firma z kilkoma osobami w dziale IT może utrzymywać większość systemów samodzielnie, ale specyficzną aplikację na zamówienie zna dobrze tylko jej twórca. Rozsądnym układem jest podział: dział wewnętrzny obsługuje infrastrukturę i pierwszą linię wsparcia, a wykonawca odpowiada za kod i poprawki wykraczające poza to, co dział IT jest w stanie rozpoznać.

Kryterium wyboru nie powinno być wyłącznie ceną. Ważna jest zdolność do przejęcia zgłoszenia w krytycznym momencie i dostęp do dokumentacji, którą wykonawca przekazał przy odbiorze, opisany w artykule o dedykowanym oprogramowaniu na zamówienie i przekazaniu kodu.

Systemy logistyczne i produkcyjne

Wymagania obsługi zależą od rodzaju systemu. Oprogramowanie logistyczne na zamówienie, na przykład do zarządzania zapasami, planowania tras transportu albo zamówieniami odbiorców, często pracuje przez całą dobę, więc okno serwisowe i dyżur muszą to uwzględniać. Mapę takich systemów pokazuje artykuł o oprogramowaniu logistycznym. Program do planowania produkcji może mieć dłuższe przerwy nocne, ale wymaga większej ostrożności przy zmianach w danych w godzinach zmiany roboczej.

Wybór między własnym systemem a rozwiązaniem gotowym wpływa na koszt obsługi, ponieważ systemy masowe przenoszą część utrzymania na producenta. Kryteria decyzji opisuje tekst o oprogramowaniu dedykowanym i rozwiązaniach masowych, a rolę wykonawcy w okresie uruchomienia - strona o wsparciu wdrożenia systemu. Warunki współpracy przy utrzymaniu można omówić z SoftwareStudio, korzystając z oferty usług lub numeru +48 533 322 626.