nieodseparowane środowisko testowe i produkcyjne

Brak separacji środowiska testowego i produkcyjnego grozi wysłaniem próbnej kampanii do rzeczywistej bazy odbiorców.

Na czym polega brak separacji środowisk

Nieodseparowane środowisko testowe i produkcyjne oznacza, że aplikacja używana do prób oraz aplikacja obsługująca rzeczywisty ruch korzystają z tych samych zasobów albo nie mają wystarczająco wyraźnych granic. Wspólna może być baza danych, kolejka komunikatów, katalog plików, serwer pocztowy, konto dostępu, adres API lub zestaw zmiennych konfiguracyjnych. Czasami środowiska są uruchomione jako dwie kopie programu, lecz wskazują na ten sam system backendowy. W takiej konfiguracji napis „tryb testowy” w interfejsie nie zapewnia bezpieczeństwa, jeżeli kod nadal wykonuje operacje na produkcyjnej bazie lub wysyła żądania do produkcyjnego dostawcy.

Separacja powinna obejmować co najmniej kod, konfigurację, dane, poświadczenia i kanały komunikacji. Środowisko testowe powinno korzystać z osobnego zestawu rekordów, osobnych kluczy API, odrębnych kolejek oraz kontrolowanego mechanizmu wysyłki wiadomości. Produkcja powinna mieć własną konfigurację przechowywaną poza kodem aplikacji. Samo rozdzielenie folderów na jednym komputerze nie jest pełną separacją, jeśli oba procesy mają dostęp do tych samych plików konfiguracyjnych, katalogów danych lub usług zewnętrznych.

Jak powstaje ryzyko wysłania próbnej kampanii

Przykładowy błąd zaczyna się od skopiowania konfiguracji produkcyjnej do środowiska testowego. W pliku może pozostać adres rzeczywistej bazy odbiorców, identyfikator produkcyjnej listy mailingowej albo klucz do usługi wysyłającej pocztę. Program testowy odczytuje wtedy prawdziwe rekordy i traktuje je tak samo jak dane demonstracyjne. Jeżeli test obejmuje funkcję tworzenia kampanii, kod może zapisać jej treść w produkcyjnych tabelach, utworzyć zadanie w produkcyjnej kolejce i przekazać wiadomość do rzeczywistego serwera SMTP lub interfejsu dostawcy poczty.

Niebezpieczne są również testy automatyczne uruchamiane bezpośrednio po wdrożeniu. Test może utworzyć użytkownika, zmienić status zamówienia, wykonać migrację tabeli, wygenerować plik albo wywołać endpoint odpowiedzialny za wysyłkę. Jeżeli test sprawdza tylko kod odpowiedzi HTTP i nie ma blokady dla adresów produkcyjnych, operacja zostanie uznana za poprawną mimo skutków ubocznych. Problem może wystąpić także przy ręcznym uruchomieniu skryptu administracyjnego, gdy operator wybierze właściwy plik, ale aplikacja pobierze zmienne środowiskowe z niewłaściwego katalogu.

Kontrole techniczne przed uruchomieniem wysyłki

Podstawową kontrolą jest używanie odrębnych baz danych oraz odrębnych kont dostępowych. Konto testowe nie powinno mieć uprawnień do produkcyjnych tabel, a aplikacja testowa nie powinna znać produkcyjnego hasła ani klucza API. Dane do testów można przygotować jako sztuczny zbiór rekordów albo jako ograniczoną kopię pozbawioną rzeczywistych adresów. Ważne jest także rozdzielenie kolejek i katalogów plików, ponieważ wspólna kolejka może dostarczyć testowe zadanie do produkcyjnego procesu nawet wtedy, gdy sama aplikacja została poprawnie oznaczona jako testowa.

Wysyłka powinna być objęta bezpiecznikami działającymi niezależnie od interfejsu. W trybie testowym można kierować wszystkie wiadomości do lokalnego przechwytywacza poczty, zastępować odbiorców jednym adresem kontrolnym albo całkowicie blokować wywołanie dostawcy. Mechanizm wysyłający powinien przed wykonaniem operacji sprawdzać nazwę środowiska, adres usługi, identyfikator bazy i dozwolony zakres odbiorców. Przydatne jest wymaganie jawnego potwierdzenia dla produkcji, rejestrowanie liczby odbiorców oraz wyświetlanie docelowego środowiska przed zatwierdzeniem kampanii.

W procesie wdrażania należy sprawdzać, czy paczka, konfiguracja i sekrety pochodzą z właściwego źródła. Pipeline może uruchamiać testy na danych fikcyjnych, a wdrożenie produkcyjne powinno następować dopiero po osobnym zatwierdzeniu. Kontrola konfiguracji powinna wykrywać adresy produkcyjne w ustawieniach testowych, a testy integracyjne powinny korzystać z atrap usług zamiast rzeczywistych odbiorców. Takie sprawdzenia ograniczają ryzyko, że pozornie niewinna zmiana adresu URL, nazwy kolejki lub zmiennej środowiskowej połączy test z produkcją.

Diagnostyka skutków pomieszania środowisk

Analizę problemu należy rozpocząć od ustalenia, z jakiej konfiguracji korzystał proces w chwili wykonania operacji. W logach warto porównać czas uruchomienia aplikacji, identyfikator wersji, nazwę środowiska, adres bazy, nazwę kolejki i identyfikator zadania wysyłkowego. Należy sprawdzić, czy log zawiera liczbę przetworzonych rekordów, status odpowiedzi z usługi zewnętrznej oraz informacje o błędach częściowych. Sam komunikat „kampania wysłana” nie potwierdza jeszcze zakresu operacji; trzeba zestawić go z wpisami w bazie, dziennikiem kolejki i logiem dostawcy poczty.

Po wykryciu połączenia testu z produkcją należy wstrzymać kolejne zadania, odłączyć nieprawidłowe poświadczenia i zachować logi oraz identyfikatory operacji do analizy. Nie powinno się usuwać rekordów na podstawie samego logu aplikacji, ponieważ wpis może dotyczyć tylko utworzenia zadania, a nie jego wykonania. Konieczne jest rozróżnienie zmian już zapisanych w bazie, wiadomości przekazanych do dostawcy oraz zadań oczekujących w kolejce. Naprawa obejmuje później rozdzielenie konfiguracji, ograniczenie uprawnień, dodanie blokad wysyłki w testach i sprawdzenie, czy kolejne wdrożenie rzeczywiście korzysta z niezależnych zasobów. Jeżeli przyczyną problemów jest konfiguracja stanowiska komputerowego, a nie samej aplikacji, Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną diagnostyką i naprawą laptopów oraz komputerów PC w tym zakresie.