Przejęcie istniejącej aplikacji: jak zacząć bez zgadywania

Przejęcie aplikacji często zaczyna się od pilnej listy zadań: naprawić błąd, dodać funkcję, przygotować wydanie. Zanim zespół zmieni choć jedną linijkę kodu, musi ustalić trzy rzeczy: co działa, kto kontroluje dostęp i jak poznać, że zmiana jest bezpieczna. Ten tekst opisuje kolejność, w jakiej to robimy.

Cztery kroki, od mapy systemu do pierwszej zmiany w kodzie.

1. Zbierz mapę systemu i przejmij dostępy

Poproś o repozytorium, instrukcję uruchomienia, historię wdrożeń, środowiska, konfigurację integracji i listę osób odpowiedzialnych. Sprawdź także, gdzie trafiają zgłoszenia błędów i kto może opublikować wydanie. Dostępy przekazuj zatwierdzonym kanałem. Sekretów nie wklejaj do dokumentacji ani komunikatora.

Wynikiem ma być krótka mapa: komponenty, zależności zewnętrzne, środowiska, sposób wdrożenia oraz właściciel każdego dostępu. Brak instrukcji to informacja o ryzyku. Zamiast zgadywać, zadaj pytania.

Przy zmianie wykonawcy dochodzi jeszcze jedna sprawa. Poprzedni zespół zna hasła i klucze. Dlatego po przejęciu dostępów:

• zmień hasła i klucze API do repozytorium, chmury, domeny i sklepów z aplikacjami,
• usuń konta osób, które już nie pracują przy projekcie,
• włącz uwierzytelnianie dwuskładnikowe wszędzie, gdzie jest dostępne,
• sprawdź, czy repozytorium, domena i konta w sklepach są zapisane na Twoją firmę.

Kod, projekty i konta powinny należeć do Ciebie od pierwszego dnia. Jeśli tak nie jest, to pierwsza rzecz do uregulowania, jeszcze przed technicznymi poprawkami.

2. Uruchom projekt i zapisz punkt odniesienia

Uruchom aplikację na czystym środowisku zgodnie z dokumentacją. Zapisz wymagane narzędzia i wersje, kroki konfiguracji bez wartości sekretów, czas uruchomienia oraz to, które kontrole przechodzą. Jeśli projekt nie buduje się od razu, ustal, skąd problem: z brakującego dostępu, nieaktualnych zależności, konfiguracji czy kodu.

Sprawdź kluczowe przepływy ręcznie lub w istniejących testach. Zanim poprawisz zastany problem, zachowaj jego objawy i sposób odtworzenia. Dzięki temu później da się oddzielić problemy odziedziczone od nowych.

Pracę wykonuj na środowisku testowym. Dane klientów z produkcji nie powinny trafiać na laptopy ani do narzędzi, których nie kontrolujesz.

3. Ustal ryzyka i kolejność

Sprawdź zależności, proces wydania, obsługę błędów, kopie zapasowe i możliwość odtworzenia, dostępność monitoringu oraz miejsca przetwarzania danych. Deklarowana kopia zapasowa nie jest dowodem. Dowodem jest udane odtworzenie z niej danych.

Audyt bezpieczeństwa po przejęciu

Aplikacja po poprzednim wykonawcy to zbiór decyzji, których nie znasz. Dlatego po przejęciu dostępów warto zrobić audyt bezpieczeństwa, zanim zaczniesz dokładać funkcje. Zaczynamy od skanu zależności i historii repozytorium: szukamy bibliotek ze znanymi podatnościami oraz haseł i kluczy zapisanych w kodzie. Potem sprawdzamy uprawnienia użytkowników, konfigurację serwerów i to, co widać w logach.

Pełny przebieg takiego audytu opisujemy w artykule Audyt bezpieczeństwa aplikacji: 12 rzeczy, które sprawdzamy przed wdrożeniem. Wynik trafia do tego samego rejestru ryzyk co reszta znalezisk.

Podziel znaleziska na trzy grupy

Każde znalezisko wpisz do jednej z grup: bloker wydania, ryzyko do ograniczenia albo usprawnienie. Przy każdym dopisz wpływ, dowód, właściciela i najbliższy krok. Najpierw zajmij się utratą danych, niekontrolowanym dostępem i brakiem powtarzalnego wydania. Kolejność zależy jednak od produktu.

Najpierw blokery, potem ryzyka, na końcu usprawnienia.

4. Zmieniaj jedną rzecz na raz

Wybierz małą zmianę, której efekt da się sprawdzić. Zachowaj dotychczasowy sposób walidacji, dodaj brakujące sprawdzenie dla nowego zachowania i przygotuj plan cofnięcia. Po wdrożeniu obserwuj właściwy sygnał, na przykład liczbę błędów lub czas odpowiedzi, oprócz kodu sukcesu z procesu wdrożenia.

Pracuj w krótkich cyklach. U nas są to dwutygodniowe sprinty z demo na końcu i środowiskiem testowym, które jest zawsze dostępne. Widzisz, co się zmieniło, i możesz zatrzymać pracę po każdym etapie.

Najczęstsze pułapki przy przejęciu

Większość kłopotów powtarza się w kolejnych projektach. Warto znać je z góry.

• Konta na osobę, nie na firmę. Sklep z aplikacjami, domena czy chmura założone na prywatny adres byłego programisty. Odzyskanie dostępu bywa wtedy długie.
• Brak środowiska testowego. Zmiany sprawdza się na produkcji, więc każda poprawka jest ryzykiem dla użytkowników.
• Zależności bez aktualizacji. Biblioteki, których nikt nie dotykał od lat, zwykle mają znane podatności i blokują aktualizację systemu.
• Wiedza tylko w głowie. Nikt nie spisał, jak wygląda wdrożenie, co robią zadania nocne i skąd biorą się dane w raportach.
• Przebudowa od zera jako pierwszy ruch. Kusi, bo stary kod bywa nieczytelny. Najpierw jednak trzeba wiedzieć, co system faktycznie robi, bo inaczej odtworzysz te same błędy w nowym kodzie.

Żadna z tych pułapek nie wymaga drogich narzędzi. Wystarczy zapisać stan rzeczy i podjąć decyzję z danymi w ręku.

Jak wygląda przejęcie w Hindbrain

Przejęcie mieści się w naszym standardowym procesie. Na początku jest bezpłatna rozmowa, około godziny, na której ustalamy, co masz i co chcesz osiągnąć. Potem w fazie onboardingu, która trwa 1 do 2 tygodni, robimy mapę systemu, punkt odniesienia i audyt ryzyk. Efektem jest zakres, harmonogram i stała wycena dalszych prac.

Dalej działamy w sprintach, a przed każdym większym wydaniem robimy audyt bezpieczeństwa. Po starcie przechodzimy w utrzymanie: monitoring, aktualizacje, łatanie podatności i miesięczny raport. Koszty utrzymania opisujemy w artykule Aplikacja działa, więc po co ją utrzymywać. Po każdym etapie decydujesz, czy idziemy dalej, a kod i konta zostają Twoje.

Lista kontrolna przed pierwszym wydaniem

• Dostępy i ich właściciele są znani, a hasła i klucze po poprzednim wykonawcy zostały zmienione.
• Sekretów nie ma w repozytorium ani w jego historii.
• Skan zależności został wykonany, a krytyczne podatności mają plan naprawy.
• Aplikację można uruchomić z opisanej konfiguracji.
• Istnieje punkt odniesienia dla testów i krytycznych przepływów.
• Proces publikacji i cofnięcia jest zrozumiały.
• Kopię można odtworzyć w sprawdzonym środowisku.
• Otwarte ryzyka mają wpływ, właściciela i decyzję o akceptacji.

Co zrobić dziś

Zrób jedną listę: każde miejsce, w którym aplikacja ma dostęp (repozytorium, chmura, domena, sklepy z aplikacjami, poczta transakcyjna, płatności) i obok nazwisko osoby, która może się tam zalogować. Jeśli któraś z tych osób należy do poprzedniego wykonawcy, zacznij od niej.

Jak możemy pomóc

Jeśli zmieniasz wykonawcę albo odziedziczyłeś aplikację, zaczynamy od audytu startowego: mapa systemu, punkt odniesienia i lista ryzyk z priorytetami. Dostajesz ją w formie dokumentu i decydujesz, czy idziemy dalej. Szukasz nowego wykonawcy? Sprawdź, jak wybrać software house. Opowiedz o swojej aplikacji.

Wniosek: Bezpieczne przejęcie zaczyna się od wiedzy o systemie i dowodów. Szybka przebudowa może poczekać. Najpierw odtwórz stan i przejmij dostępy, potem zmieniaj aplikację małymi krokami.

Dalsza lektura: Zobacz, jak informacje diagnostyczne mogą uzupełnić zgłoszenie problemu, w projekcie Hindbrain Reflex.