W Suwerennym IDP pokazałem, że „exit-by-design” czyni strategię wyjścia funkcją techniczną. Dla sektora finansowego w UE to już nie jest dobra praktyka — to wymóg prawny. DORA (Digital Operational Resilience Act) zamienia odporność operacyjną z deklaracji w coś, co trzeba udowodnić i przetestować. Zobaczmy, jak warstwy platformy — IaC, GitOps, policy-as-code — przekładają się wprost na zgodność.
DORA nie pyta „czy macie dokument strategii wyjścia?". Pyta „czy potraficie ją wykonać bez przerwania działania?". To czyni z odporności właściwość architektury, nie segregatora.
To analiza techniczna, nie porada prawna. Zakres i interpretacja DORA zależą od podmiotu i nadzorcy — tu patrzymy wyłącznie na konsekwencje dla architektury platformy.
Co DORA wymaga (w skrócie technicznym)
DORA obowiązuje podmioty finansowe i ich dostawców ICT. Z perspektywy platformy liczą się przede wszystkim:
- Mapowanie zależności ICT — musisz wiedzieć (i umieć wykazać), od jakich dostawców i komponentów zależysz.
- Ryzyko koncentracji (CTPP) — zakaz nadmiernej zależności od jednego krytycznego dostawcy ICT (critical third-party provider).
- Testowalne strategie wyjścia — utrzymywane i przetestowane ścieżki migracji bez zakłócenia działania.
- Odporność operacyjna i testowanie — zdolność do przetrwania i odtworzenia po incydencie.
Kluczowe: nie wystarczy strategię opisać. Trzeba mieć operacyjną zdolność jej wykonania. A tę da się zbudować tylko przez fundamentalne odsprzężenie wytwarzania i dostarczania od konkretnego dostawcy infrastruktury.
Mapowanie wymogów na warstwy platformy
| Wymóg DORA | Mechanizm platformy |
|---|---|
| Mapowanie zależności ICT | wszystko-jako-kod w repo → zależności są jawne i audytowalne |
| Unikanie koncentracji CTPP | multi-cloud przez abstrakcję IaC + framework-agnostyczna orkiestracja |
| Testowalna strategia wyjścia | GitOps jako odtwarzalny stan → DR = wskazanie kontrolerowi nowego klastra |
| Dowody zgodności | policy-as-code jako bramki + ślad audytowy z Gita |
| Odporność/odtwarzanie | środowiska deklaratywne, reprodukowalne z repo |
Abstrakcja IaC: warunek unikania koncentracji
Ryzyka koncentracji nie da się ograniczyć, jeśli wdrożenie jest „zapieczone” w API jednego dostawcy. Dlatego infrastrukturę definiujesz w sposób cloud-agnostyczny — przez OpenTofu (lub Terraform) z modułami, które da się skierować na różnych dostawców:
# moduł sieci wołany dla różnych dostawców z tego samego kodu
module "vpc" {
source = "git::https://git.eiac.dev/eiac/modules.git//network?ref=v1.4.0"
provider = var.target # sovereign-eu | global-aws
cidr = "10.0.0.0/16"
}Ten sam moduł, dwa cele wdrożenia — to techniczny fundament tezy „nie jesteśmy nadmiernie zależni od jednego dostawcy”. Multi-cloud przestaje być hasłem, a staje się weryfikowalną własnością kodu.
GitOps: strategia wyjścia, którą da się wykonać
Skoro cały stan systemu żyje jako kod, „wyjście” przestaje być projektem migracyjnym, a staje się operacją. Kontroler GitOps (Argo CD / Flux) odtwarza środowisko z repozytorium na dowolnym zgodnym klastrze:
To jest sedno „testowalnej strategii wyjścia”: skoro DR i exit to ta sama operacja (re-point kontrolera + reconcile), możesz ją przećwiczyć — a przećwiczona migracja to dokładnie to, czego DORA wymaga. Na Kubernetes (lub lekkim k3s na zapasowej lokacji) odtworzenie jest powtarzalne i mierzalne.
Dowody zgodności jako kod
DORA wymaga wykazywania zgodności. Zamiast ręcznych audytów, czynisz reguły maszynowo egzekwowalne i samodokumentujące — policy-as-code w pipeline (np. OPA). Każde uruchomienie zostawia ślad: co sprawdzono, z jakim wynikiem.
# przykładowa reguła zgodna z wymogiem rezydencji danych
package eiac.dora
deny contains msg if {
input.resource.type == "database"
not startswith(input.resource.region, "eu-")
msg := "dane regulowane muszą pozostać w regionie UE"
}Reguła egzekwowana w CI (i ślad z Gita) jest jednocześnie kontrolą i dowodem — bez osobnego procesu audytowego.
Granica: czego platforma nie załatwi
Uczciwie: platforma spełnia techniczną część DORA. Reszta — rejestr informacji o dostawcach, raportowanie incydentów do nadzorcy, testy odporności (w tym TLPT dla większych podmiotów), zarządzanie ryzykiem na poziomie organizacji — to procesy i obowiązki wykraczające poza kod. Architektura jest warunkiem koniecznym zgodności, nie wystarczającym.
Podsumowanie
DORA przesuwa ciężar z „opisz strategię wyjścia” na „udowodnij, że ją wykonasz”. Everything-as-code daje mapę zależności, abstrakcja IaC ogranicza koncentrację, GitOps czyni z exitu rutynową operację, a policy-as-code dostarcza dowodów. To nie przypadek, że to ta sama architektura, którą opisałem jako suwerenną — odporność i suwerenność wyrastają z tego samego korzenia. Uczciwie: sam kod nie załatwi zgodności w całości; rejestr dostawców, raportowanie incydentów i procesy to wciąż robota ludzi. Ale bez tej architektury reszta nie ma się na czym oprzeć. W kolejnej części patrzę na drugą wielką regulację: AI Act a agentowy SDLC.