Zmiany w bazie danych wdrażane są przez bramkę weryfikacji przedwsadowej — i wychwyciła ona rzeczywisty problem

Dlaczego ten wpis powstał

To jest transparentny wpis ze strony operatora dotyczący sposobu, w jaki bezpiecznie wdrażamy destrukcyjne zmiany schematu bazy danych. Temat tej zmiany dotyczy dyscypliny operacyjnej, a nie nowej funkcji produktu — jednak dla kupujących ze średniego rynku w UE oceniających postawę zgodności HumanKey pytanie "jak ten dostawca unika utraty integralności mojego śladu audytowego podczas rutynowych zmian operacyjnych?" jest powtarzającym się pytaniem procurementowym. Uczciwa odpowiedź obejmuje konkretny wzorzec inżynierski oraz bramkę weryfikacyjną, która niedawno wychwyciła rzeczywistą rozbieżność, zanim jakiekolwiek dane zostały utracone.

Wzorzec w zrozumiałym języku

Kiedy musimy zmienić sposób przechowywania wrażliwego pola — na przykład zastąpić surowe wartości formami zminimalizowanymi — stosujemy podejście dwufazowe:

• Faza 1 (rozszerzenie): wdrażamy nową zminimalizowaną formę obok istniejącej formy surowej. Obie kolumny otrzymują tę samą zminimalizowaną wartość przy zapisie. Ścieżki odczytu preferują nową kolumnę z awaryjnym powrotem do starej dla wierszy, które poprzedzają zmianę. Faza ta wymaga przynajmniej tygodnia stabilnego działania przed czymkolwiek innym.
• Faza 2 (skurczenie): usuwamy starą surową kolumnę całkowicie, gdy nowa zminimalizowana forma w pełni pokryje dane.

Wzorzec ten nazywa się expand-contract w literaturze inżynierskiej. Ryzyko, które zarządza, polega na tym, że jeśli po prostu zmienicie nazwę kolumny lub upuścicie jedną w pojedynczym wdrożeniu, wszystko w locie w momencie wdrożenia może utracić dane. Wzorzec dwufazowy gwarantuje, że każda ścieżka odczytu może rozwiązać do wartości nawet podczas przejścia.

Dlaczego bramka przedwsadowa ma znaczenie

Wzorzec expand-contract działa poprawnie tylko wtedy, gdy faza podwójnego zapisu faktycznie zapisała obie kolumny dla każdego zdarzenia podczas okresu stabilizacji. Jeśli subtelny błąd spowodował, że niektóre zdarzenia zapisały tylko starą kolumnę (bez nowej zminimalizowanej formy), to upuszczenie starej kolumny po cichu utraciłoby identyfikatory tych wierszy.

Aby zweryfikować, że to nigdy się nie wydarzy, uruchamiamy automatyczny przebieg weryfikacji przedwsadowej przed każdą destrukcyjną zmianą Fazy 2:

1. Próbkujemy ostatnie wiersze post-deploy i potwierdzamy, że obie kolumny zawierają wartości równoważne pod względem parzystości.
2. Liczymy wszelkie wiersze, w których stara kolumna zawiera dane, ale nowa zminimalizowana kolumna jest pusta.
3. Inspekcjonujemy wizualnie ustaloną próbkę wierszy pod kątem zgodności formatu.

Weryfikacja produkuje jasny werdykt PASS lub FAIL. Jeśli FAIL, destrukcyjna zmiana zostaje zatrzymana i badamy sprawę przed kontynuowaniem. Żadnego "jestem dość pewien" ani "prawdopodobnie zadziałało". Udokumentowana bramka z binarnym wyjściem.

Niedawny rzeczywisty przykład

W tym cyklu rozwojowym nasza weryfikacja przedwsadowa została uruchomiona przeciwko bazie produkcyjnej i zwróciła FAIL. Werdykt wyłonił dwa odrębne problemy:

1. Garstka ostatnich zdarzeń została zapisana tylko do starej kolumny, pomijając nową zminimalizowaną kolumnę. Był to cichy błąd podwójnego zapisu wprowadzony we wcześniejszej sesji, którego żaden z naszych testów nie wychwycił (logika podwójnego zapisu była poprawna, ale ścieżka kodu edytowana później omijała ją).
2. Około stu starszych zdarzeń sprzed wdrożenia Fazy 1 rozszerzenia nadal nosiło surowe wartości w starej kolumnie bez równoważnika zminimalizowanego (oryginalne wdrożenie Fazy 1 nie wypełniło wstecznie wierszy historycznych).

Gdybyśmy pominęli bramkę przedwsadową i przeszli bezpośrednio do Fazy 2, mielibyśmy:

• Utraconą metadaną identyfikatora dla około stu starszych zdarzeń. Niekatastrofalne dla bieżących operacji, ale rzeczywiste regresję kompletności śladu audytowego, którą organ regulacyjny UE lub coroczny audyt klienta korporacyjnego mógłby zgodnie z prawem zakwestionować.
• Również utraconą metadaną identyfikatora dla ostatnich zdarzeń z asymetrią podwójnego zapisu.

Zamiast tego bramka zatrzymała destrukcyjną zmianę. Wypełniliśmy wstecznie zaatakowane wiersze, używając udokumentowanej strategii hybrydowej, która zachowała każdy wiersz, każdy znacznik czasu zdarzenia i każdy wpis w śladzie audytowym — minimalizując jedynie pole identyfikatora sieciowego w kierunku pro-prywatnym. Destrukcyjna zmiana Fazy 2 następnie przeszła bezpiecznie, gdy weryfikacja przedwsadowa zwróciła PASS.

Jak to wygląda dla regulatorów i kupujących

Zgodnie z art. 32 RODO — bezpieczeństwem przetwarzania — administrator musi wdrożyć odpowiednie środki organizacyjne w celu zapewnienia integralności danych. Udokumentowana bramka przedwsadowa, która produkuje binarny werdykt przed każdą destrukcyjną zmianą, jest dokładnie tym rodzajem środka, który spełnia ducha art. 32 w sposób, który przetrwa kontrolę audytową.

Zgodnie z art. 30 RODO — rejestrami przetwarzania — sam ślad audytowy musi być utrzymywalny. Bramka przedwsadowa, która wychwytuje rozbieżność podwójnego zapisu przed destrukcyjną zmianą, zachowuje kompletność śladu.

Zgodnie z polską Ustawą o rachunkowości art. 74 — pięcioletnią retencją zapisów finansowych — ślad musi pozostać dostępny przez pełny okres ustawowy. Bramka, która wychwytuje problemy z integralnością, zanim staną się trwałe, zachowuje obowiązek.

Dlaczego to publikujemy

Kupujący z UE prowadzący due diligence procurementowe zadają dostawcom coraz bardziej szczegółowe pytania dotyczące dyscypliny operacyjnej. "Pokażcie nam waszą procedurę destrukcyjnej zmiany" jest jednym z takich pytań, na które mniejsi dostawcy często odpowiadają machaniem rąk ("dokładnie testujemy"). Odpowiadamy konkretnie: istnieje udokumentowana procedura, przebieg weryfikacji przedwsadowej, binarny werdykt i niedawny przykład, w którym bramka zapobiegła rzeczywistej regresji.

Dyscyplina operacyjna nie tworzy ekscytującego marketingu produktowego, ale tworzy obronną postawę zgodności podczas audytów.

Czym to nie jest

• Nie magiczna siatka bezpieczeństwa. Przebieg weryfikacji przedwsadowej weryfikuje konkretne niezmienniki. Nie może wychwycić trybów awarii, o których nikt nie pomyślał, aby je zbadać. Rozszerzamy powierzchnię sondy w miarę odkrywania nowych trybów awarii.
• Nie unikatowe dla HumanKey. Expand-contract to dobrze znany wzorzec; bramka przedwsadowa to prosta dyscyplina inżynierska. To, co publikujemy, to fakt, że naprawdę to robimy i naprawdę zatrzymujemy destrukcyjne zmiany, gdy bramka zawodzi — co jest częścią, którą zespoły procurementowe trudno zweryfikować bez współpracy z dostawcą przez dłuższy czas.
• Nie substytut dla kopii zapasowych. Nasz dostawca bazy danych zachowuje kopie zapasowe punkt-w-czasie-przywróć; bramka przedwsadowa to środek obrony do przodu, a nie zamiennik możliwości przywrócenia.

Odnośniki referencyjne

• Art. 30 RODO — Rejestry czynności przetwarzania
• Art. 32 RODO — Bezpieczeństwo przetwarzania (odpowiednie środki organizacyjne)
• Polska Ustawa o rachunkowości art. 74 — Pięcioletnia retencja zapisów finansowych
• Nasza Polityka Prywatności oraz DPIA opisują kategorie danych, które przetwarzamy

---

HumanKey to oparta na UE, natywnie zgodna z RODO platforma analityczna dla wydawców i serwisów e-commerce. Operatorskie wpisy transparentne obejmują wybory dotyczące zgodności i inżynierii, które kupujący B2B oceniają podczas procurement.