Aplikacja działa. Czy następca potrafi ją utrzymać?

Wspólnik zmyślonej kancelarii mówi: „Przecież wszystko działa”. Aplikacja obsługuje sprawy od czterech lat. Jej wykonawca kończy współpracę i przygotowuje kod do przekazania. Dopiero przy rozmowie z następcą okazuje się, że nikt inny nie uruchamiał systemu ani nie publikował poprawki.

To dobry moment, żeby ustalić, co pozostaje tylko w pamięci odchodzącej osoby. Przekazanie utrzymania powinno skończyć się próbą następcy, a nie samym odebraniem plików. Ma on wykonać uzgodnione zadanie na podstawie dokumentacji i z własnym dostępem, bez niezapisanych podpowiedzi poprzednika.

Co właściwie przejmuje nowa firma?

Utrzymanie serwera, poprawianie kodu i pomoc użytkownikom mogą mieć różnych wykonawców. Nazwij te zakresy przed ustaleniem daty. Nowa firma może przejąć środowisko bez migracji, a rozwój aplikacji może pozostać u innego zespołu. Zmiana dostawcy nie oznacza automatycznie zmiany hostingu.

Sprawdź z osobą odpowiedzialną za umowę warunki przekazania kodu, danych i dokumentacji. Czy następca może korzystać z materiałów i wprowadzać zmiany? Które licencje i usługi trzeba zachować lub zastąpić? Sam fakt posiadania kopii kodu nie rozstrzyga tych ustaleń.

Nie musisz samodzielnie czytać kodu ani ustawiać serwera. Następca zbiera informacje techniczne i wskazuje luki; Ty zatwierdzasz zakres, koszty i proces, który musi działać po przejęciu. Przekazanie poczty i komputerów opisaliśmy osobno w poradniku o zmianie informatyka. Poproś o koszt rozpoznania, prac wszystkich wykonawców i ewentualnej migracji. Szerszy budżet opisuje poradnik o kosztach własnej aplikacji.

Karta, która prowadzi do wyniku

Poproś poprzednika oraz każdego wykonawcę odpowiedzialnego za część obsługi po zmianie o uzupełnienie karty. Wpisz u góry: aplikacja, przekazujący, odpowiedzialni po zmianie według obszarów, osoba decydująca po stronie kancelarii i data przejęcia. „Następca” w karcie oznacza wykonawcę odpowiedzialnego za dany obszar po zmianie.

Przy każdej pozycji zapisz lokalizację, odpowiedzialnego i wynik: „potwierdzone”, „brak” materiału lub dostępu, „usterka” czynności albo „nie sprawdzono”. Jeśli obszar należy do innego wykonawcy, wpisz kogo; ta osoba także potwierdza wynik. „Nie dotyczy” wymaga uzasadnienia, nie zastępuje przypisania obowiązku. Przy kontach wskaż administratora danej usługi, który wykona zmiany dostępów.

Dla braków dopisz działanie, osobę, termin i ponowną próbę. Uzupełnienia od poprzednika zaplanuj przed końcem współpracy; późniejszą pomoc uzgodnij osobno. Jeśli jest niedostępna, ustal z następcą możliwość, koszt i ograniczenia przejęcia. Kartę i instrukcje zachowaj w miejscu dostępnym kancelarii także po zmianie.

Microsoft w zaleceniach dotyczących utrzymania podkreśla wykonalne kroki procedur oraz aktualizowanie dokumentacji razem z systemem i zespołem. Instrukcja „zrestartować aplikację” nie mówi następcy, którego elementu dotyczy, jak potwierdzić wynik ani co zrobić przy błędzie.

Poprzednik pokazuje, następca wykonuje

Następca przygotowuje chronione miejsce próby, a Ty zatwierdzasz sprawdzany proces. Przed próbą następca wyłącza prawdziwe wysyłki, płatności i zapis do działających systemów. Opiekun kodu potwierdza, że wersja odpowiada produkcji i uwzględnia ręczne poprawki. Opiekun środowiska uruchamia tę wersję i wykonuje uzgodniony proces, np. tworzy fikcyjną sprawę i dodaje dokument. Następnie publikuje tam testową zmianę przygotowaną przez osobę odpowiedzialną za kod. Osoba z kancelarii sprawdza, czy rezultat odpowiada zadaniu.

Poprzednik może wyjaśnić brakujący krok. Taka informacja trafia do instrukcji, po czym następca powtarza odpowiednią część próby już bez tej pomocy. Jeśli ustawienie poprawia sam poprzednik, bez zapisu i powtórki, demonstracja jeszcze nie dowodzi przejęcia.

W naszej zmyślonej kancelarii zapis mógłby wyglądać tak:

Zgodność kodu z produkcją i uwzględnienie ręcznych poprawek: „potwierdzone”. Uruchomienie i publikacja w środowisku próbnym: potwierdzone. Opis konfiguracji przypomnień: brak. Wykonanie zadania: nie sprawdzono. Publikacja produkcyjna: nie sprawdzono, następca nie ma własnego konta wdrożeniowego. Poprzednik uzupełnia opis, administrator [osoba] nadaje dostęp, następca uzgadnia termin i warunki obu czynności. Wynik odbiera [osoba], termin uzupełnienia [data].

Fikcyjne dane nie potwierdzają stanu rzeczywistej bazy ani kompletności eksportu. Następca powinien osobno zweryfikować wersje, konfigurację i uprawnienia potrzebne do istniejącej aplikacji. Pełną próbę odzyskania po awarii opisuje tekst o odtworzeniu portalu klienta. Tutaj sprawdzamy, czy nowy opiekun umie przejąć uzgodnioną pracę.

Produkcja nie jest kolejną kopią testową

Ustal, czy przekazanie obejmie kontrolowane wprowadzenie zmiany do działającej aplikacji przez następcę. Termin, dopuszczalną przerwę, warunki przerwania i sposób powrotu uzgadniają wykonawcy z kancelarią. Sam dostęp do repozytorium nie potwierdza możliwości publikacji. Jeśli jej nie sprawdzono, karta ma to pokazywać.

Przy przenoszeniu hostingu następca przygotowuje osobny plan przełączenia i zachowania pracy powstałej w trakcie zmiany, a Ty go zatwierdzasz. Powrót do starszych danych nie może po cichu zastąpić nowszej pracy kancelarii. Wynik próby w przygotowanym środowisku nie gwarantuje czasu uruchomienia aplikacji przy przyszłej awarii.

Wskaż jedną osobę prowadzącą przejęcie, kontakt do zgłoszeń i godzinę, od której nowy dostawca odpowiada za uzgodniony zakres. Umówiony test alarmu i zgłoszenia powinien potwierdzić, że docierają do właściwego odbiorcy. Następca pokazuje również dostęp do produkcji i zapisów jej działania z własnych kont. Zakres dyżuru oraz obsługi zmian musi wynikać z ustaleń, a nie z obecności numeru telefonu w instrukcji.

Dostępy zamyka się razem z zależnościami

Przeniesienie zasobu nie zawsze usuwa stare uprawnienia. GitHub opisuje, że przy transferze repozytorium pozostają powiązane sekrety i klucze wdrożeniowe. Również dostępy współpracowników wymagają sprawdzenia. Zmiana właściciela nie odcina więc automatycznie wszystkich dróg dostępu.

Administrator planuje własne konta następcy i zamknięcie praw poprzednika, w tym powiązań z jego telefonem lub adresem odzyskiwania. Zanim odbierze prawa do czynności, potwierdza działający dostęp następcy. Jeśli dostępu następcy nie da się potwierdzić przed końcem współpracy, decyzja o przejęciu musi nazwać ograniczenie i uzgodniony sposób dalszej obsługi. Brak gotowości sam nie przedłuża dostępu poprzednika. Sekrety, czyli m.in. hasła usług i klucze do połączeń, przekazuje uzgodnionym chronionym sposobem. Do karty wpisuje ich przeznaczenie i miejsce przechowywania, nie wartości.

OWASP zaleca uwzględnianie zależności, które mogą przestać działać po zmianie sekretu. Dlatego administrator planuje wymianę, sprawdza działanie połączeń i cofnięcie starych dostępów. Kluczy szyfrujących nie wolno usuwać w ciemno: mogą być potrzebne do wcześniejszych danych. Ustal z poprzednikiem, według warunków współpracy, co dzieje się z kopiami po jego stronie. Poproś o plan tych czynności z odpowiedzialnym i terminami przed końcem współpracy i zatwierdź go.

Wspólnik ze sceny nie musi nauczyć się uruchamiać aplikacji. Musi ustalić, kto zrobi to po odejściu dotychczasowego wykonawcy, i zobaczyć tę osobę przy pracy, zanim zdanie „przecież działa” znów zamknie rozmowę.