Migracja aplikacji medycznej: specyfikacja i plan wycofania

Migracja aplikacji na nową infrastrukturę jest bezpieczna tylko wtedy, gdy przed przeniesieniem istnieje spisana specyfikacja tego, co dziś działa, oraz plan wycofania na wypadek, gdyby po przełączeniu coś zachowało się inaczej, niż zakładano. Bez tych dwóch dokumentów hasło przenosimy jeden do jednego jest obietnicą, której nikt nie potrafi sprawdzić. Piszę o tym na tle platformy telemedycznej w USA, przy której przejściu do chmury pracowałem.

Tekst jest dla właściciela albo kierownika IT, który zleca przeniesienie systemu i chce wiedzieć, o co zapytać wykonawcę, zanim ktokolwiek ruszy serwery.

Kontekst: platforma telemedyczna i wymagania HIPAA

precisiontelemed.com to platforma telemedyczna działająca w USA. Pracowałem przy jej przejściu na AWS. Aplikacja przetwarza informacje o zdrowiu pacjentów, więc obowiązują ją przepisy HIPAA, czyli amerykańskie zasady ochrony danych medycznych.

Dla decydenta najważniejsza jest tu jedna rzecz: dostawca infrastruktury, który przechowuje albo przetwarza takie dane w imieniu firmy, podpisuje z nią umowę BAA (Business Associate Agreement). To odpowiednik naszej umowy powierzenia przetwarzania danych z RODO. Dlatego przy takiej migracji wybór miejsca docelowego zaczyna się od pytania, czy umowę BAA da się zawrzeć i które usługi obejmuje. Usługa spoza tego zakresu nie powinna dotykać danych pacjentów, nawet jeśli technicznie byłaby wygodniejsza. Szerzej o samej decyzji o przejściu do chmury piszę w tekście o tym, czy warto inwestować w chmurę.

Dlaczego migracja jeden do jednego rzadko nim jest

Przeniesienie bez zmian jest możliwe tylko wtedy, gdy wiadomo, co dokładnie przenosimy. Sam kod aplikacji to tylko część obrazu. Równie ważne jest środowisko, w którym ten kod przez lata działał, a ono zwykle nie jest nigdzie opisane, bo konfigurowano je stopniowo, przy kolejnych poprawkach.

Zanim ruszy przenoszenie, warto spisać stack w postaci, którą da się porównać z nowym środowiskiem punkt po punkcie:

• Serwer WWW: jaki, z jakimi modułami, regułami przekierowań i limitami wielkości żądań.
• PHP: dokładna wersja, rozszerzenia, ustawienia pamięci, czasu wykonania i wysyłki plików.
• Cache: co jest buforowane, gdzie, na jak długo i jak się go czyści po wdrożeniu.
• Baza danych: silnik i wersja, kodowanie znaków, strefa czasowa, zadania cykliczne i kopie.
• Otoczenie: poczta wychodząca, zadania cron, certyfikaty, integracje z usługami zewnętrznymi i adresy dopuszczone po ich stronie.

Każdy z tych punktów potrafi zmienić zachowanie aplikacji bez żadnej zmiany w kodzie. W teorii wygląda to tak: inna strefa czasowa bazy przesunęłaby godziny zapisanych wizyt, niższy limit wysyłki zablokowałby dodawanie dokumentów, a nowy adres serwera, którego partner nie ma na swojej liście, zerwałby integrację. Specyfikacja na piśmie zamienia zdanie u nas działało w listę rzeczy do sprawdzenia. Jak myśleć o takim opisie szerzej, pokazuję w tekście o projektowaniu skalowalnej architektury systemów.

Plan wycofania: kto i kiedy decyduje o powrocie

Plan wycofania to opis, jak wrócić do starego środowiska, jeśli po przełączeniu aplikacja nie działa poprawnie. Musi powstać przed migracją, bo w trakcie problemu nikt nie ma głowy do wymyślania procedur.

Dobry plan odpowiada na cztery pytania:

1. Jakie objawy oznaczają decyzję o powrocie i kto ją podejmuje.
2. Do kiedy powrót jest prosty, czyli zanim w nowej bazie pojawią się dane, których nie ma w starej.
3. Co zrobić z danymi zapisanymi po przełączeniu, jeśli jednak wracamy.
4. Jak długo stare środowisko zostaje włączone i nietknięte po udanym przeniesieniu.

Ostatni punkt bywa pomijany z oszczędności. Wyłączenie starego serwera zaraz po przełączeniu odbiera jedyną drogę odwrotu, a błędy w rzadziej używanych funkcjach często wychodzą dopiero po kilku dniach.

Plan warto też przećwiczyć. Próbne przeniesienie na kopii danych pokazuje, ile naprawdę trwa każdy krok, które polecenia trzeba poprawić i czy powrót do starego środowiska działa tak, jak zapisano. Lepiej odkryć brakujący krok na próbie niż w noc przełączenia, kiedy rano użytkownicy mają umówione wizyty.

Przełączenie poza godzinami ruchu

Przełączenie robi się wtedy, gdy z aplikacji korzysta najmniej osób, a zespół jest dostępny i wypoczęty. Przy platformie działającej w USA oznacza to pracę w innej strefie czasowej niż polska, co trzeba uzgodnić z osobami po stronie klienta, które w tym czasie odbiorą telefon.

Przed oknem przełączenia warto mieć gotowe:

• skrócony czas życia rekordów DNS, ustawiony odpowiednio wcześniej,
• komunikat dla użytkowników o przerwie technicznej,
• ostatnią synchronizację danych i wstrzymanie zapisów na czas przeniesienia,
• listę kontaktów: kto po stronie klienta, dostawcy infrastruktury i wykonawcy jest pod telefonem.

Testy po migracji aplikacji

Testy po migracji aplikacji sprawdzają nie tylko, czy strona się otwiera, ale czy działają procesy ważne dla użytkowników. W aplikacji medycznej to rejestracja, logowanie, umówienie i odbycie wizyty, przesłanie dokumentu, powiadomienia i płatności.

Listę scenariuszy dobrze jest przygotować przed migracją i przejść dwa razy: na starym środowisku, żeby wiedzieć, jak wygląda poprawny wynik, i na nowym, zaraz po przełączeniu. Do tego dochodzi przegląd logów błędów, kontrola zadań cyklicznych i wysyłki poczty oraz porównanie wybranych danych w obu bazach. Dopiero gdy cała lista jest odhaczona, przeniesienie można uznać za zakończone. Kto i na jakich warunkach opiekuje się systemem później, najlepiej zapisać w umowie SLA na utrzymanie systemu.

Jeśli planujesz migrację aplikacji, zwłaszcza takiej, która przetwarza dane wrażliwe, zacznij od dwóch dokumentów: spisu obecnego środowiska i planu wycofania. Bez nich trudno ocenić ryzyko i rzetelnie porównać oferty wykonawców. Jeżeli chcesz przejść przez nie z kimś, kto zajmuje się takimi przeniesieniami, napisz do mnie przez formularz kontaktowy.