Obsługa informatyczna firm Poznań - wsparcie aplikacji po wdrożeniu

Po uruchomieniu aplikacji dedykowanej zmienia się charakter pracy IT. Zamiast projektu jest strumień zgłoszeń: błędy, prośby o zmianę i pytania użytkowników. Obsługa informatyczna firm Poznań kojarzy się zwykle ze sprzętem i siecią, ale przy własnym oprogramowaniu najwięcej pracy wymaga sama aplikacja.

Strona opisuje wyłącznie tę część: jak przyjmować zgłoszenia i odtwarzać usterki, a potem wydawać poprawki i planować rozwój. Zakres obsługi infrastruktury, w tym kopie zapasowe i parametry RPO, omawia artykuł o obsłudze informatycznej w Poznaniu od strony serwerów i backupu. Zapisy umowy o czasach reakcji rozbiera tekst o umowie SLA na obsługę informatyczną.

Obsługa informatyczna firm Poznań a aplikacja dedykowana

Ten sam objaw, na przykład brak możliwości zapisania dokumentu, może pochodzić z trzech różnych warstw. Od tego, którą warstwę wskaże pierwsza diagnoza, zależy kto dostaje zgłoszenie i jak szybko.

Podział jest istotny, gdy aplikacją zajmuje się inny podmiot niż serwerami. Bez uzgodnionej ścieżki zgłoszenie krąży między firmami, a użytkownik czeka. Aplikacja webowa składa się z klienta w przeglądarce oraz serwera z bazą danych, więc już sama jej architektura, opisana w artykule o aplikacji webowej, pokazuje, gdzie szukać przyczyny.

Reguła: zgłoszenie ma jednego właściciela w każdej chwili. Przekazanie do innej warstwy odnotowuje się w zgłoszeniu, zamiast zamykać je i zakładać nowe.

Klasyfikacja zgłoszeń po wdrożeniu

Pierwszy ruch po otrzymaniu zgłoszenia to rozstrzygnięcie, czy opisuje ono usterkę, czy prośbę o zmianę. Od tej decyzji zależy tryb rozliczenia: usterki naprawia się w ramach gwarancji lub umowy serwisowej, zmiany wyceniane są osobno.

Zgłoszenie, które da się odtworzyć

Zgłoszenie „nie działa” zabiera godzinę na dopytywanie. Formularz zgłoszeniowy powinien więc wymuszać cztery informacje, bez których wykonawca nie odtworzy usterki.

• Wersja aplikacji - numer wyświetlany w stopce lub w oknie o programie, bo usterka często dotyczy jednego wydania.
• Użytkownik i rola - konto, na którym wystąpił problem, ponieważ uprawnienia zmieniają zachowanie ekranów.
• Czas zdarzenia - moment z dokładnością do minuty, żeby znaleźć wpis w dzienniku zdarzeń.
• Opis czynności - kolejność akcji użytkownika i komunikat, który się pojawił, najlepiej ze zrzutem ekranu.

Klasy priorytetów usterek

Usterki dzieli się na klasy według wpływu na proces, a nie według tego, kto zgłasza. Klasa wyznacza czas reakcji z umowy, więc przypisuje ją osoba znająca proces, najlepiej razem z wykonawcą przy przyjęciu zgłoszenia.

Odtwarzanie usterki z dziennika zdarzeń

Usterka, której nie da się odtworzyć, jest zgadywaniem. Aplikacja zapisuje więc każdy wyjątek do dziennika razem z wersją i użytkownikiem, a użytkownikowi pokazuje identyfikator korelacji. Identyfikator trafia do zgłoszenia i pozwala odnaleźć dokładnie ten wpis.

Wyjątek jest przechwytywany po stronie serwera i zapisywany do dziennika, a użytkownik widzi komunikat bez szczegółów technicznych. Przykład w C# jest poglądowy, a nazwy klas i metod są przykładowe.

// przykładowa obsługa wyjątku z identyfikatorem korelacji
catch (Exception ex)
{
    var idKorelacji = Guid.NewGuid();
    dziennik.Zapisz(idKorelacji, wersja, uzytkownik, ex.ToString());
    return StatusCode(500, new { komunikat = "Operacja nie powiodła się.", idKorelacji });
}

W bazie wpisy trafiają do tabeli dziennika. Zapytanie poniżej zawęża wyniki do wersji, której dotyczy zgłoszenie, oraz do ostatnich 24 godzin, dzięki czemu wykonawca widzi tylko istotne zdarzenia.

-- przykładowa tabela dziennika błędów aplikacji
CREATE TABLE dbo.DziennikBledow (
    Id              BIGINT IDENTITY(1,1) PRIMARY KEY,
    Czas            DATETIME2(0)     NOT NULL DEFAULT SYSUTCDATETIME(),
    WersjaAplikacji VARCHAR(20)      NOT NULL,
    Uzytkownik      NVARCHAR(100)    NULL,
    IdKorelacji     UNIQUEIDENTIFIER NOT NULL,
    Komunikat       NVARCHAR(MAX)    NOT NULL
);

SELECT TOP (50) Czas, Uzytkownik, IdKorelacji, Komunikat
FROM dbo.DziennikBledow
WHERE WersjaAplikacji = '2.4.0'
  AND Czas >= DATEADD(HOUR, -24, SYSUTCDATETIME())
ORDER BY Czas DESC;

Dziennik ma własną politykę przechowywania: zbyt krótka utrudnia analizę usterek zgłaszanych z opóźnieniem, zbyt długa zajmuje miejsce i może zawierać dane osobowe w komunikatach. Okres należy zapisać w umowie razem z zakresem danych, które wolno logować.

Dane produkcyjne w diagnozie

Odtworzenie usterki bywa możliwe tylko na danych zbliżonych do produkcyjnych. Wykonawca pracuje wtedy na kopii bazy, a dane osobowe w niej zastępuje się wartościami zamaskowanymi. SQL Server oferuje do tego mechanizm dynamicznego maskowania opisany w dokumentacji Microsoft, ale kopię do diagnozy można też przygotować skryptem, który podmienia wartości na stałe. Zasady dostępu do danych i ich powierzenia wykonawcy zapisuje się w umowie, a jej stronę prawną warto omówić z prawnikiem.

Poprawka awaryjna i wydanie planowane

Nie każda usterka zasługuje na poprawkę poza harmonogramem. Poprawka awaryjna omija zwykły cykl wydań, więc niesie większe ryzyko i uruchamia się ją tylko wtedy, gdy koszt czekania przekracza koszt ryzyka.

Poprawka powstaje w osobnej gałęzi odchodzącej od wersji, która działa na produkcji, a nie od bieżącego kodu rozwojowego. Dzięki temu na produkcję nie trafiają zmiany, które jeszcze nie przeszły testów. Numeracja wydań i znaczniki wersji są opisane szerzej w artykule o wersjach i wydaniach oprogramowania.

git switch -c poprawka/blokada-zamowienia v2.4.0
# zmiana i test usterki
git commit -am "Blokada zamówienia po edycji: zwolnienie rezerwacji"
git tag -a v2.4.1 -m "Poprawka: blokada zamówienia po edycji"

Plan wycofania powstaje przed wydaniem, a nie po pierwszej awarii. Obejmuje kopię bazy wykonaną tuż przed zmianą, poprzedni pakiet aplikacji i kryterium, po którym podejmuje się decyzję o powrocie. Skrypty zmieniające schemat bazy piszą się tak, by dało się je cofnąć, albo poprzedza je kopia, z której przywraca się dane. Bez takiego planu wdrożenie poprawki w godzinach pracy jest zakładem.

Testy regresji przed wydaniem

Poprawka jednej funkcji potrafi zepsuć inną, więc przed wydaniem uruchamia się testy regresji, czyli zestaw scenariuszy potwierdzających, że wcześniej działające ścieżki nadal działają. Im więcej scenariuszy zapisano jako testy automatyczne, tym krótszy czas między zgłoszeniem a wdrożeniem poprawki. Wykonawca, który wydaje poprawki bez regresji, przenosi ryzyko na użytkowników. Kryteria dobrego procesu wytwórczego zebrano w artykule o testach i wersjach w tworzeniu aplikacji.

Wydajność bazy danych po wdrożeniu

Aplikacja, która działała szybko na danych z testów, zwalnia, gdy w tabelach przybywa rekordów. Nie jest to usterka kodu w ścisłym sensie, ale zgłoszenie „wolno się otwiera” wpada do obsługi po wdrożeniu i wymaga diagnozy po stronie bazy SQL Server.

Pierwszym sprawdzeniem jest fragmentacja indeksów. Poniższe zapytanie wybiera indeksy o dużej fragmentacji w tabelach większych niż tysiąc stron, czyli takie, w których przebudowa ma sens.

SELECT OBJECT_NAME(ips.object_id) AS tabela,
       i.name AS indeks,
       ips.avg_fragmentation_in_percent AS fragmentacja
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') AS ips
JOIN sys.indexes AS i
  ON i.object_id = ips.object_id AND i.index_id = ips.index_id
WHERE ips.avg_fragmentation_in_percent > 30
  AND ips.page_count > 1000;

Według dokumentacji Microsoft o reorganizacji i przebudowie indeksów fragmentację od kilku do trzydziestu procent leczy się reorganizacją, a powyżej trzydziestu przebudową. Jeśli indeksy są w porządku, następnym krokiem jest plan wykonania zapytania, które użytkownik zgłasza jako wolne. Może się okazać, że brakuje indeksu albo że filtr zmusza silnik do przeglądania całej tabeli.

Aktualizacje platformy i wsparcie producentów

Aplikacja stoi na platformach, których producenci publikują daty końca wsparcia. Po takiej dacie nie powstają poprawki bezpieczeństwa, więc obsługa aplikacji obejmuje także plan aktualizacji składników, na których ona działa. Na przykład SQL Server 2008 jest poza wsparciem producenta, co opisuje strona Microsoft Lifecycle. Aplikacja na takiej bazie nadal działa, ale każda luka zostaje bez łatki.

Migracja bazy na nowszą wersję nie kończy się na uruchomieniu kopii. Poziom zgodności bazy decyduje o zachowaniu optymalizatora zapytań, więc jego podniesienie następuje dopiero po testach na kopii danych, a nie razem z przeniesieniem plików. Poniższe polecenia pokazują bieżący poziom i jego zmianę na wartość odpowiadającą SQL Server 2019.

SELECT name, compatibility_level
FROM sys.databases
WHERE name = DB_NAME();

ALTER DATABASE CURRENT SET COMPATIBILITY_LEVEL = 150;

Aktualizacja platformy jest osobną pozycją w backlogu z własną wyceną, bo rzadko mieści się w zwykłej poprawce. Firma, która planuje ją z rocznym wyprzedzeniem, unika sytuacji, w której migracja rozpoczyna się w dniu, gdy wsparcie już wygasło.

Rozwój aplikacji i backlog zmian

Zgłoszenia zakwalifikowane jako zmiany trafiają do backlogu, czyli uporządkowanej listy prac rozwojowych. Backlog prowadzi wspólnie zamawiający i wykonawca, a kolejność wynika z wartości dla procesu, nie z tego, kto zgłosił zmianę głośniej.

• Opis potrzeby - zdanie o problemie użytkownika, a nie gotowe rozwiązanie techniczne.
• Wpływ na proces - kogo dotyczy zmiana i ile czasu lub błędów może zaoszczędzić.
• Wycena pracy - liczba godzin z zakresem niepewności, uzgodniona przed rozpoczęciem prac.
• Zależności - integracje i moduły, których zmiana dotyka, wraz z wpływem na testy regresji.

Rozwój można rozliczać jako pulę godzin w abonamencie albo zlecenie osobne dla większych zmian. Pula zapewnia szybszy start prac, a zlecenie osobne daje przejrzystość kosztu. Rachunek rocznych kosztów utrzymania aplikacji pokazuje artykuł o utrzymaniu programów tworzonych dla firm, a zakres nadzoru nad środowiskiem opisuje tekst o utrzymaniu dedykowanych aplikacji webowych.

Zmiana, która dotyka integracji z innym systemem, wymaga uzgodnienia z jego właścicielem. Zasady wymiany danych między aplikacjami, od uwierzytelniania po format komunikatów, przedstawia artykuł o integrowaniu aplikacji webowych.

Raport miesięczny i przegląd współpracy

Raport miesięczny pokazuje zamawiającemu, co zrobiono, a czego nie zdążono. Rzetelny raport zawiera liczbę zgłoszeń według rodzaju i klasy oraz czasy reakcji i naprawy względem umowy. Uzupełnia je lista wydanych wersji ze stanem backlogu.

Raz na kwartał warto zestawić raporty z planem rozwoju: czy usterki dotyczą tych samych modułów, czy któryś ekran generuje nieproporcjonalnie dużo pytań użytkowników. To one wskazują, gdzie inwestycja w poprawę interfejsu lub dokumentacji obniży liczbę zgłoszeń. Firmy, które porównują różne modele współpracy, znajdą opis zakresu i SLA w artykule o outsourcingu IT w Poznaniu, a praktyki wytwórcze wykonawcy opisano w tekście o firmie programistycznej od strony warsztatu. Ogólny opis usług dostępny jest na stronie usług SoftwareStudio.