Was DORA-Prüfer von Ihrem Lasttest erwarten

Unter DORA sind Nachweise für Last- und Leistungstests Teil der Resilienzprüfung.

Für Compliance- und Engineering-Teams bei EU-Finanzinstituten, die nachweisen müssen, dass ihre Systeme einem Volumen standhalten.

Das Digital Operational Resilience Act (DORA) der EU gilt seit dem 17. Januar 2025 für Finanzinstitute. Es legt ein Regelwerk fest, wie Banken, Versicherer, Investmentfirmen und ihre kritischen IKT-Anbieter digitale Dienste trotz Störungen am Laufen halten. Digitale operationale Resilienztests sind eine seiner fünf Säulen (neben IKT-Risikomanagement, Vorfallberichterstattung, Drittanbieterrisiko und Informationsaustausch), und diese Säule umfasst direkt Ihr Last- und Leistungstestverfahren.

Eine erste Klarstellung, da das Akronym mehrfach verwendet wird. Dieser Artikel behandelt die EU-Verordnung. Es geht nicht um die DevOps-“DORA-Metriken” (Bereitstellungshäufigkeit, Durchlaufzeit usw.). Ganz andere DORA.

Artikel 25 der Verordnung listet die Testmethoden auf, die ein Resilienzprogramm anwenden sollte. Leistungstests und End-to-End-Tests stehen neben Schwachstellenbewertungen und Penetrationstests auf dieser Liste. Wenn also ein Prüfer Ihre Resilienztests überprüft, ist die Vorlage von Nachweisen aus Last- und Stresstests legitim.

Die meisten Online-Berichte zu DORA konzentrieren sich auf bedrohungsorientierte Penetrationstests. Dieser Artikel behandelt die leisere Verpflichtung: nachzuweisen, dass Ihre Systeme unter Last reaktionsfähig bleiben, Belege zu liefern, die ein Prüfer tatsächlich sehen möchte, und dies mit einem dafür geeigneten Tool zu tun. LoadView ist eine cloudbasierte Lasttestplattform mit echtem Browser, und die folgenden Abschnitte ordnen jede Position auf der Checkliste eines DORA-Konformitätsprüfers der LoadView-Funktion zu, die sie erzeugt.

Was Dieser Leitfaden Abdeckt

1. Wo Lasttests in DORA Einzuordnen Sind
2. Die Prüfungsnachweise, die ein DORA-Prüfer Erwartet
3. Wie LoadView DORA-Tests zur operationellen Resilienz Unterstützt
4. Warum Protokollbasierte Lastzahlen bei einer Prüfung Nicht Ausreichen
5. Wie Man DORA-Geeignete Testnachweise Erstellt
6. Das Fazit
7. Häufig Gestellte Fragen

Wo Lasttests in DORA Einzuordnen Sind

DORA ist risikobasiert und macht keine Vorgaben zu Tools. Es heißt nicht „Führen Sie jedes Quartal einen Lasttest mit 500 Nutzern durch.“ Es verlangt, dass die IKT-Systeme, die kritische oder wichtige Funktionen unterstützen, regelmäßig getestet werden und dass auf die Ergebnisse reagiert wird.

Zwei Artikel tragen den Großteil der Belastung für die Leistungstests:

• Artikel 24 stellt die allgemeinen Testprinzipien auf. Finanzinstitute testen die IKT-Systeme und Anwendungen, die kritische oder wichtige Funktionen unterstützen, mindestens einmal jährlich und anhand eines risikobasierten Ansatzes.
• Artikel 25 listet die Methoden auf, die das Programm nutzen kann. Leistungstests und End-to-End-Tests werden explizit genannt.

Für eine Handelsplattform, eine Zahlungs-API oder ein Online-Banking-Portal bedeutet „Störungen aushalten“ auch Störungen durch Last: ein Ansturm bei Markteröffnung, ein Spitzenwert am Zahltag, eine Aktion, die den Checkout-Verkehr verdreifacht. Wenn der Dienst unter Volumen langsamer wird oder ausfällt, besteht eine Lücke in der operationellen Resilienz. Und DORA erwartet, dass Sie diese vor dem Produktiveinsatz gesucht haben, weshalb Lasttests für Finanzdienstleistungen ihren Platz im Programm verdienen.

Hier geht es um praktische, nicht nur prozessuale Bedeutung. Aufsichtsbehörden können von einem Institut verlangen, Resilienzlücken zu beheben, die sie finden; eine Prüfung, die ein ungetestetes kritisches System aufdeckt, führt also oft zu ungeplanten Aufgaben im Regulierungszeitplan statt im Ihren.

Die Prüfungsnachweise, die ein DORA-Prüfer Erwartet

Prüfer arbeiten mit Beweismaterial, nicht mit Absichten. Im Rahmen einer Überprüfung Ihrer Resilienztests sollten Sie damit rechnen, dass sie nach folgenden Artefakten suchen:

In der ersten Reihe verlieren Teams die meisten Punkte. Ohne dokumentierte Leistungs-SLAs hat ein Lasttest keine Bestehen/Nichtbestehen-Linie, und ein Prüfer sieht ein Diagramm ohne zugrunde liegenden Maßstab. Schreiben Sie die Zielwerte zuerst auf: P95-Antwortzeit pro kritischer Transaktion, Deckenfehlerquote und die maximale Last, die jedes System bewältigen muss.

Die Reihen zwei und drei betreffen den Zeitpunkt und die Schwere. Einen Lasttest vor jeder Produktionsfreigabe durchzuführen zeigt, dass das Volumen geprüft wird, bevor Kunden die Software nutzen, und die Einbindung dieser Prüfung in Ihre Release-Pipeline sorgt für Konsistenz. Stresstests gehen über einen reinen Lasttest hinaus, indem sie Prognosespitzen überschreiten, bis etwas versagt – so ist der Brechpunkt eine bekannte Zahl statt eine Überraschung am Markteröffnungstag.

Die vierte Reihe ist der Nachweis, mit dem Prüfer am meisten arbeiten. Ein Bericht mit Antwortzeit-Perzentilen, Fehlerquoten und dem Lastprofil, das sie erzeugt hat, bildet den Kernnachweis. Er braucht ein Datum und eine Version, damit er einem bestimmten Release zugeordnet werden kann.

Die fünfte Reihe verbindet den Test mit einer Prognose. Kapazitätsplanungsdokumente geben an, wie viel Puffer der letzte Test gemessen hat und wann das Wachstum ihn aufbrauchen wird. Die Reihen sechs und sieben unterscheiden ein reales Programm von einem Papierprogramm. Wenn ein Test einen Engpass aufdeckt, will der Prüfer die Nachverfolgung sehen. LoadView-Berichte zeigen, dass genaue Leistungsengpässe die Maßnahme konkretisieren: Welcher Teil war langsam, was wurde geändert, und wie verlief der Nachtest.

Wie LoadView DORA-Tests zur operationellen Resilienz Unterstützt

Jede Zeile dieser Nachweisliste entspricht einer Funktion, die LoadView direkt bereitstellt. Die Tabelle unten ordnet das vom Prüfer geforderte Dokument dem LoadView-Feature zu, das es erzeugt, sodass Anforderung und Tool-Funktion eins zu eins übereinstimmen.

Zwei LoadView-Merkmale erledigen hier den Großteil der Arbeit. Erstens laufen die Tests in echten Browsern, sodass die Zahlen in Ihrem Bericht die Zeiten widerspiegeln, die ein Kunde tatsächlich erlebt, was den Bericht als Resilienznachweis glaubwürdig macht. Zweitens ist der gesamte Ablauf als Nutzerreise (User Journey) und nicht nur als Satz roher Anfragen skriptiert, sodass ein End-to-End-Test nach Artikel 25 DORA Login, Transaktion und Bestätigung genau so abdeckt, wie es eine echte Sitzung tut. Die nächsten zwei Abschnitte behandeln diese jeweils.

Warum Protokollbasierte Lastzahlen bei einer Prüfung Nicht Ausreichen

Ein Lasttest, der rohe HTTP-Anfragen abschickt, kann hohe Durchsatzwerte melden. Für einen kundenorientierten Finanzdienst beschreiben diese Zahlen aber nur den Server, nicht das Kundenerlebnis. Sie überspringen das JavaScript, die Betrugsprüfung durch Dritte, die Weiterleitung zum Single-Sign-On und den dargestellten Bestätigungsbildschirm.

Ein Prüfer, der wissen möchte, ob Kunden unter Last Transaktionen durchführen können, will Beweise zur Kundenerfahrung, nicht nur zur Anfragerate am Ursprungsserver. Echter Browser-Lasttest führt den Test in tatsächlichen Chromium-Instanzen durch, sodass im Bericht die Antwortzeiten die sind, die der Kunde tatsächlich sieht. Einfach gesprochen lädt der Test die Seite so, wie der Browser des Kunden dies tut – mit ausgeführten Skripten, Weiterleitungen und Rendering – und pingt nicht nur den Server an.

Für eine Bank oder einen Zahlungsdienstleister ist das der Unterschied zwischen „die API antwortete in 200 ms“ und „der Login-Bestätigungsprozess dauerte neun Sekunden, weil der Betrugsscoring-Aufruf wartete“. Letzteres beeinträchtigt den Service. Genau das sucht eine Resilienzprüfung, weshalb Transaction Concurrency Testing, also das Testen gleichzeitiger Transaktionen in der realen Nutzerstrecke, stärkere Nachweise liefert als bloße Protokoll-Durchsatzzahlen.

Ein Tool, das „100.000 Anfragen pro Sekunde“ meldet, ohne die Seite auszuführen, misst HTTP-Durchsatz, nicht die Kundenerfahrung am Login-Bildschirm. Ein Prüfer, der Resilienz von Kundendiensten überprüft, verlangt die zweite Zahl.

Protokollebene-Tests messen den Server; LoadViews Tests im echten Browser messen den Login-Bestätigungsprozess, den ein Kunde durchläuft.

Wie Man DORA-Geeignete Testnachweise Erstellt

Sie benötigen keine neue Tool-Kategorie, um diese Säule zu erfüllen. Sie brauchen Tests, die zur Nachweisliste passen und einen Bericht, den Sie einem Prüfer vorlegen können. Die Vorgehensweise in LoadView ist wie folgt:

1. Schreiben Sie Leistungsanforderungen für jede kritische Funktion auf. Legen Sie Antwortzeit-Perzentile und eine Fehlerdeckelung pro Transaktion fest, lassen Sie diese absegnen und tragen Sie sie als Bestehen/Nichtbestehen-Grenzen im Test ein, sodass die Ergebnisse automatisch bewertet werden.
2. Zeichnen Sie den Test als reale Nutzerstrecke auf. Verwenden Sie den EveryStep Recorder, um die tatsächliche Nutzerreise (Login, Transaktion, Bestätigung) Klick für Klick im echten Browser zu erfassen, und spielen Sie sie dann unter Last mit Webanwendungs-Lasttests ab, anstatt nur rohe HTTP-Aufrufe zu wiederholen.
3. Testen Sie bis zur erwarteten Spitze und darüber hinaus. Konfigurieren Sie Lastkurventypen, um virtuelle Nutzer auf dem prognostizierten Spitzenwert für den Lasttest zu halten, und eine abgestufte Kurve, die für den Stresstest darüber hinausgeht, sodass sowohl „Können wir den Tag bewältigen?“ als auch „Wo brechen wir zusammen?“ beantwortet werden.
4. Führen Sie die Last aus den Regionen aus, die Sie bedienen. Wenn Ihre Kunden die EU umfassen, testen Sie aus über 30 geo-verteilten Lastinjektionszonen, damit die Leistung dort gemessen wird, wo die Nutzer tatsächlich sind, und nicht nur aus einem Rechenzentrum.
5. Bewahren Sie den Bericht auf. Exportieren Sie die Leistungstestberichte mit Perzentilen, Fehlerquoten, Lastprofil, Wasserfall und Zeitstempel und archivieren Sie sie mit den Freigabedaten. Diese Datei liest der Prüfer.
6. Wiederholen Sie die Tests nach Plan und nach Änderungen. Testen Sie mindestens jährlich für kritische Funktionen, nach jeder Freigabe, die einen kritischen Pfad berührt, und sobald das Transaktionswachstum Sie an die Kapazitätsgrenze des letzten Tests bringt. Wenn Sie die Tests planen und in Ihre CI/CD-Pipeline integrieren, erfolgt das automatisch – keine Kalendereintragung nötig.

Auf diese Weise entsteht der Nachweis als Nebenprodukt der ohnehin durchzuführenden Tests. Da LoadView vollständig cloudbasiert ist, gibt es keine Infrastruktur für Lastgenerierung, die eingerichtet oder gegenüber einem Prüfer rechtfertigt werden müsste. Die Artefakte entsprechen genau dem, was ein DORA-Prüfer verlangt, und in der Reihenfolge, in der er sie verlangt.

DORAs Geltungsbereich umfasst auch kritische IKT-Drittanbieter, auf die Sie angewiesen sind. Wenn ein Zahlungs-Gateway, Identitätsdienst oder Daten-API kritischer Pfad ist, gehört dessen Verhalten unter Last ebenfalls zu Ihrem Resilienznachweis. Daher enthält auch API-Lasttest dieser Endpunkte dieselben Nachweise für die Dienste, die Sie nicht selbst betreiben.

Sehen Sie, wie LoadView die Nachweise erzeugt, die ein DORA-Prüfer verlangt. Vereinbaren Sie eine LoadView-Demo, um einen Test für Ihre Spitzenvolumina zu dimensionieren und Berichte zu exportieren, die Ihre Prüfer sehen wollen.

Das Fazit

DORA legt keine Checkliste für Lasttests vor, aber die Säule der Resilienztests und die Methoden in Artikel 25 machen Performance- und Lasttests zu einem prüfbaren Bestandteil. Die relevanten Systeme sind diejenigen, die kritische oder wichtige Funktionen unterstützen, und das Kriterium ist, ob sie Kunden unter Last weiterhin bedienen.

Liefern Sie die sieben Artefakte, die ein Prüfer erwartet, basierend auf Ergebnissen aus echten Browsern statt Protokolldurchsatz, und führen Sie Nachtests bei steigendem Volumen durch. LoadView ist so konzipiert, dass es all diese Artefakte aus einem einzigen skriptierten Test erzeugt, sodass eine Resilienzprüfung Ihrer Leistungstestdaten einfach eine Übergabe bereits geführter Aufzeichnungen ist.

Häufig Gestellte Fragen