Utrzymanie oprogramowania

Kiedy ta usługa pomaga

Utrzymanie oprogramowania: co mogą nam Państwo zlecić.

Uporządkowane przekazanie istniejących aplikacji
Przewidywalna obsługa aktualizacji i awarii
Połączenie utrzymania z dalszym rozwojem

Wraz z uruchomieniem produkcyjnym (go-live) zaczyna się właściwy cykl życia aplikacji. Przejmujemy monitoring, usuwanie awarii, aktualizacje bezpieczeństwa, utrzymanie zależności oraz wsparcie merytoryczne zgodnie z procesami ITIL i uzgodnionymi ścieżkami reakcji. Dotyczy to również aplikacji stworzonych przez innych producentów lub Państwa wewnętrzne zespoły, po ustrukturyzowanym przejęciu obejmującym analizę kodu i transfer wiedzy.

Co może wchodzić w zakres zlecenia

Przejęcie z analizą kodu, inwentarzem zależności, dokumentacją i transferem wiedzy
Monitoring z użyciem narzędzi Prometheus, Grafana i OpenTelemetry, alarmowanie według poziomu krytyczności
Zarządzanie incydentami i problemami zgodnie z ITIL w narzędziu Jira Service Management
Aktualizacje bezpieczeństwa i utrzymanie zależności za pomocą narzędzia Renovate, weryfikacja pod kątem znanych podatności
Regularne raporty dotyczące dostępności, incydentów i otwartych ryzyk

Konkretny zakres, odbiory i zaangażowanie Państwa strony ustalamy w ofercie.

Powiązania na pierwszy rzut oka

Eksploatacja jako zamknięty cykl doskonalenia.

01
Wykrywanie
Monitorowanie kluczowych operacji aplikacji
02
Reagowanie
Klasyfikowanie i eskalowanie awarii
03
Naprawa
Usuwanie przyczyn i sprawdzanie zmian
04
Doskonalenie
Uwzględnianie wniosków w utrzymaniu i planowaniu

Planowanie, realizacja i decyzje

Utrzymanie oprogramowania: co jest najważniejsze.

01

Przejęcie z weryfikowalnym punktem wyjścia

Zanim przejmiemy odpowiedzialność, sprawdzamy dostęp do kodu, prawa użytkowania, zależności oraz możliwość samodzielnego zbudowania wersji. Wspólnie spisujemy znane problemy, wiedzę eksploatacyjną i krytyczne procesy. Samo poprawne uruchomienie aplikacji nie wystarczy: trzeba też wyjaśnić kwestie kopii zapasowych, przywracania danych i odpowiedzialności za usługi zewnętrzne.

Efektem przejęcia jest zakres usług z otwartymi ryzykami i działaniami uszeregowanymi według priorytetów. Zaszłości, nad którymi nie da się zapanować, nie są po cichu włączane do ryczałtowego zobowiązania. Jeśli najpierw konieczna jest stabilizacja, opisujemy ją jako osobny pakiet prac.

02

Wykrywanie awarii i sensowna eskalacja

Działający serwer niewiele mówi o tym, czy użytkownicy mogą wykonywać swoją pracę. Dlatego kierujemy monitoring również na ważne operacje aplikacji i interfejsy. Powiadomienia są klasyfikowane według ich skutków; każdy alarm wymaga odbiorcy i sensownego pierwszego kroku.

Godziny wsparcia, docelowe czasy reakcji i ścieżki eskalacji są ustalane w umowie. Czas reakcji nie oznacza gwarantowanego czasu rozwiązania. W przypadku poważnych incydentów ustalamy zasady komunikacji, uprawnienia decyzyjne oraz współpracę z Państwa dostawcą infrastruktury lub oprogramowania.

03

Utrzymanie chroni kolejną zmianę

Aktualizacje są oceniane pod kątem ryzyka, pilności i kompatybilności. Utrzymujemy widoczność zależności, sprawdzamy zmiany w odpowiednim środowisku i planujemy dostarczenie ze ścieżką powrotu. Powtarzające się awarie są analizowane pod kątem przyczyn, aby eksploatacja nie sprowadzała się stale do tych samych napraw.

Regularne raporty łączą incydenty, ryzyka techniczne i nadchodzące decyzje. Drobne usprawnienia mogą być realizowane w uzgodnionym zakresie; większe rozszerzenia funkcjonalne są priorytetyzowane osobno. Z myślą o ewentualnym późniejszym przekazaniu Państwa zespołowi na bieżąco dokumentujemy wiedzę i dostępy.

Dla osób odpowiedzialnych merytorycznie i zespołów technicznych

Decyzje stojące za realizacją.

04

Pomiar celów usługowych z perspektywy użytkowników

Aplikacja może być dostępna, a mimo to nie przetwarzać zamówień. Dlatego wybieramy punkty pomiarowe dla istotnych procesów użytkownika i rozróżniamy dostępność, poprawne przetwarzanie oraz czas odpowiedzi. Cel usługowy wymaga okresu pomiaru, źródła danych i zasad postępowania w przypadku brakujących pomiarów. Dopiero wtedy można w sposób możliwy do zweryfikowania ocenić, czy uzgodniony stan został osiągnięty.

Pozostałe odchylenie od celu można wykorzystać jako budżet błędów, aby wyważyć stabilizację i dalszy rozwój. Wspólnie ustalamy, jakie konsekwencje ma jego przekroczenie. Nie zastępuje to ani umownych uzgodnień dotyczących usług, ani oceny pojedynczego poważnego incydentu. Dashboardy i alarmowanie mają wspierać decyzje: kto reaguje, jaka diagnostyka następuje i kiedy trzeba poinformować osoby odpowiedzialne merytorycznie?

05

Testowanie kopii zapasowych, przywracania i zależności

Pomyślnie zakończone tworzenie kopii zapasowej nie dowodzi jeszcze, że dane da się przywrócić. Ustalamy, jaka maksymalna utrata danych byłaby akceptowalna i jak długo może trwać przestój. Z tego wynikają wymagania dotyczące częstotliwości tworzenia kopii, okresu ich przechowywania i ponownego uruchomienia. Do aplikacji oprócz bazy danych często należą pliki, konfiguracja, klucze i usługi zewnętrzne; jeśli brakuje jednego z elementów, technicznie odczytywalna kopia zapasowa może mimo to okazać się bezużyteczna.

Ćwiczenia z przywracania sprawdzają uzgodniony proces w odpowiednim środowisku. Dokumentowane są przy tym czas trwania, wymagane dostępy, kroki manualne i merytoryczna weryfikacja danych. Przywrócenie danych pojedynczego dzierżawcy lub przypadkowo usuniętego rekordu może wymagać innej ścieżki niż całkowita awaria. Wyniki przekładają się na konkretne usprawnienia. Stwierdzone luki nazywamy wprost, zamiast przedstawiać niesprawdzoną wartość docelową jako zagwarantowaną zdolność.

06

Aktualizacje bezpieczeństwa, analiza przyczyn i przewidywalne zakończenie współpracy

Zgłoszenie dotyczące podatnej biblioteki jest oceniane w kontekście aplikacji: która wersja jest wykorzystywana, czy podatna funkcja jest osiągalna i jakie środki ochrony istnieją? Pilność i techniczne ryzyko zmiany rozpatrujemy łącznie. Dla aktualizacji niemożliwych do natychmiastowego wdrożenia potrzebne są udokumentowane środki tymczasowe oraz termin ponownej oceny. Nowe wersje przechodzą odpowiednie testy i uzgodnione wdrożenie.

Po powtarzających się lub poważnych awariach badamy przyczynę, sposób wykrycia i reakcję. Powstają z tego działania uszeregowane według priorytetów, z przypisanymi osobami odpowiedzialnymi, a nie tylko zamknięte zgłoszenie (ticket). Dokumentacja, runbooki i zestawienia dostępów są aktualizowane na bieżąco. Przygotowujemy też późniejsze przekazanie Państwa zespołowi lub innemu dostawcy usług: wraz z repozytorium, instrukcją budowania, otwartymi ryzykami i uporządkowanym przekazaniem dostępów. W dłuższej perspektywie usługa jest trwała, gdy wiedza pozostaje przejrzysta.

Przejrzyste rezultaty prac

Co trafia w Państwa ręce.

Rezultat 01

Katalog usług ze ścieżkami reakcji i zakresami odpowiedzialności

Rezultat 02

Monitoring z alarmowaniem i dashboardami

Rezultat 03

Raporty z eksploatacji obejmujące incydenty i ryzyka

Przykładowy przebieg projektu

Tak może wyglądać realizacja.

Aplikacja specjalistyczna opracowana wewnętrznie ma zostać przekazana zespołowi zewnętrznemu. Po analizie kodu i uzyskaniu odtwarzalnego buildu najpierw sprawdzane są monitoring i przywracanie danych. Następnie rozpoczyna się utrzymanie z uzgodnionymi godzinami serwisowymi i listą zaszłości uszeregowanych według priorytetów.

Scenariusz poglądowy, nie referencja klienta ani gwarancja rezultatu.

To ułatwia start

Repozytorium, licencje i dostępy techniczne
Dokumentacja, znane incydenty i obecni dostawcy usług
Oczekiwane godziny serwisowe i krytyczność biznesowa

Brak dokumentów nie wyklucza rozpoczęcia współpracy. Wspólnie ustalamy, jakie informacje należy pozyskać w pierwszej kolejności.

Państwa przedsięwzięcie w szczegółach

Utrzymanie sprawności biznesowej i technicznej oprogramowania po jego uruchomieniu.

Przejmujemy uzgodnione zadania w zakresie utrzymania, obsługi zakłóceń i dalszego rozwoju. Zakres jest dostosowany do Państwa aplikacji i organizacji eksploatacji, tak aby wsparcie i rozwój produktu mogły ze sobą współpracować.

Konkretne ustalenie odpowiedzialności i granic usługi

Aplikacja, infrastruktura i usługi zewnętrzne mogą mieć różnych operatorów. Ustalamy, kto przyjmuje zgłoszenia, analizuje przyczyny i zatwierdza zmiany. Określane są godziny świadczenia usługi, priorytety i sposób eskalacji; ogólne deklaracje typu „szybkie wsparcie” nie zastępują konkretnej umowy.

Incydent wymaga przywrócenia działania, problem wymaga analizy powracających przyczyn, a wniosek o zmianę wymaga oceny biznesowej. Te zadania są obsługiwane w sposób pozwalający je od siebie odróżnić. Dzięki temu trwale potrzebne usprawnienia nie giną wśród kolejnych doraźnych napraw.

Utrzymanie i przywracanie działania według planu

Zależności, środowiska uruchomieniowe i interfejsy ulegają zmianom. Rejestrujemy istotne komponenty i planujemy aktualizacje na podstawie ryzyka, zgodności oraz dostępnego wsparcia. Przed zmianami produkcyjnymi uzgadniane są odpowiednie testy i przebieg prac serwisowych.

Kopie zapasowe to tylko część procesu przywracania działania. Dostępne muszą być również konfiguracja, dane dostępowe i zależności zewnętrzne. Testujemy uzgodniony sposób ponownego uruchomienia i dokumentujemy pozostałe ograniczenia. Regularne analizy łączą zakłócenia, dług techniczny i planowane zmiany produktu w przejrzystą listę zadań.

Poglądowy scenariusz projektu

Jak usługa pomaga w codziennej pracy.

Przykład: powtarzające się błędy importu każdego ranka wymagają ręcznej korekty. Oprócz doraźnej naprawy analizujemy przyczynę i kontrakt danych, poprawiamy obsługę błędów i wprowadzamy ukierunkowany monitoring. Skuteczność działania oceniana jest na podstawie mniejszej liczby zakłóceń i bardziej przejrzystej ścieżki obsługi.

Ten przykład opisuje możliwy przebieg i nie jest referencją klienta.

Przed zleceniem

Utrzymanie oprogramowania: Państwa pytania.

Czy przejmują Państwo oprogramowanie stworzone przez innych?

Tak, po przeprowadzeniu weryfikacji technicznej i organizacyjnej. Potrzebujemy wystarczających praw, dostępów oraz technicznej sytuacji wyjściowej, nad którą da się zapanować. Brakującą dokumentację można częściowo uzupełnić; niedostępny kod źródłowy lub brak praw producenta mogą natomiast istotnie ograniczyć zakres.

Czy usługa obejmuje wsparcie całodobowe?

Godziny serwisowe, dyżury i docelowe czasy reakcji są wyraźnie uzgadniane. Nie wynikają one automatycznie z samego pojęcia eksploatacji aplikacji. Wymagany zakres dopasowujemy do krytyczności aplikacji i istniejącej organizacji eksploatacji.

Czy nowe funkcje wchodzą w zakres utrzymania?

Usuwanie błędów, techniczne utrzymanie i rozszerzenia funkcjonalne są rozdzielone w katalogu usług. Dla nowych funkcji uzgadniamy zakres, priorytet i odbiór. Dzięki temu jasne jest, które prace podtrzymują eksploatację, a które tworzą dodatkową wartość biznesową.

Warto połączyć

Doradztwo w zakresie oprogramowania Oprogramowanie dedykowane Portale internetowe i aplikacje Modernizacja oprogramowania Tworzenie interfejsów Testy oprogramowania DevOps i wydania

Kolejny krok

Prosimy powiedzieć nam, gdzie dziś pojawiają się trudności.

Do rozpoczęcia wystarczy krótki opis Państwa aplikacji, problemu i celu. Wybrana usługa zostanie uwzględniona w Państwa zapytaniu kontaktowym.

Zapytaj o tę usługę

Menu

Przestój nie czeka na Państwa zespół.