# DORA w praktyce platformy: testowalne strategie wyjścia

> DORA zamienia strategię wyjścia z dokumentu w udowadnialną zdolność operacyjną. Jak warstwy platformy — IaC, GitOps, policy-as-code — przekładają się wprost na zgodność.

URL: https://eiac.dev/blog/dora-w-praktyce-platformy
Filar: Security-as-Code
Data: 2026-04-03
Tagi: dora, sovereignty, compliance, gitops, eu

---

W [Suwerennym IDP](/blog/suwerenny-idp-exit-by-design) 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](https://eur-lex.europa.eu/eli/reg/2022/2554/oj)** (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ść.

<div class="callout">
<strong>Teza</strong>
<p>DORA nie pyta „czy macie dokument strategii wyjścia?". Pyta „czy potraficie ją <em>wykonać</em> bez przerwania działania?". To czyni z odporności właściwość architektury, nie segregatora.</p>
</div>

<div class="callout">
<strong>Uwaga</strong>
<p>To analiza techniczna, nie porada prawna. Zakres i interpretacja DORA zależą od podmiotu i nadzorcy — tu patrzymy wyłącznie na konsekwencje dla architektury platformy.</p>
</div>

## 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](/katalog/opentofu) (lub [Terraform](/katalog/terraform)) z modułami, które da się skierować na różnych dostawców:

```hcl
# 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](/katalog/argo-cd) / [Flux](/katalog/flux)) odtwarza środowisko z repozytorium na dowolnym zgodnym klastrze:

<figure>
<svg viewBox="0 0 720 132" role="img" aria-label="Exit jako operacja: wyzwalacz, provisioning klastra przez tofu apply, reconcile Argo CD z repo, odtworzone środowisko">
  <g fill="none" stroke="currentColor" stroke-width="1.5">
    <rect x="16" y="42" width="150" height="48" rx="6"/>
    <rect x="200" y="42" width="160" height="48" rx="6"/>
    <rect x="394" y="42" width="166" height="48" rx="6"/>
    <rect x="588" y="42" width="116" height="48" rx="6" stroke="var(--color-rust)"/>
  </g>
  <g stroke="currentColor" stroke-width="1.5">
    <line x1="166" y1="66" x2="194" y2="66"/>
    <line x1="360" y1="66" x2="388" y2="66"/>
    <line x1="560" y1="66" x2="582" y2="66"/>
  </g>
  <g fill="currentColor">
    <path d="M194 62 L200 66 L194 70 Z"/>
    <path d="M388 62 L394 66 L388 70 Z"/>
    <path d="M582 62 L588 66 L582 70 Z"/>
  </g>
  <g font-family="'Space Grotesk', system-ui, sans-serif" font-size="12.5" fill="currentColor" text-anchor="middle">
    <text x="91" y="62">katastrofa /</text>
    <text x="91" y="78">nakaz wyjścia</text>
    <text x="280" y="62">provisioning klastra</text>
    <text x="280" y="78">u innego dostawcy</text>
    <text x="477" y="62">Argo CD →</text>
    <text x="477" y="78">reconcile z repo</text>
    <text x="646" y="62" fill="var(--color-rust)">środowisko</text>
    <text x="646" y="78" fill="var(--color-rust)">odtworzone</text>
  </g>
  <g font-family="'Space Mono', monospace" font-size="10" fill="var(--color-muted)" text-anchor="middle">
    <text x="280" y="106">tofu apply</text>
  </g>
</svg>
<figcaption>Exit = DR jako operacja: provisioning u innego, suwerennego dostawcy, skierowanie kontrolera GitOps na nowy klaster i odtworzenie środowiska z repo.</figcaption>
</figure>

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](/katalog/kubernetes) (lub lekkim [k3s](/katalog/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](/katalog/open-policy-agent)). Każde uruchomienie zostawia ślad: co sprawdzono, z jakim wynikiem.

```rego
# 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](/blog/ai-act-a-agentowy-sdlc).