Operationelle Resilienz, ein entferntes Schutzmechanismus nach dem anderen.
DORA Art. 11 (Reaktion und Wiederherstellung) geht darum, kritische Funktionen während einer Störung am Laufen zu halten und sich davon zu erholen: Maßnahmen zur Geschäftskontinuität und Reaktion auf IKT-bezogene Vorfälle. Für ein Finanzinstitut wird ein großer Teil dieser Resilienz im Code aufgebaut, durch Retries, Circuit Breaker, Failovers und Timeouts, die verhindern, dass der Ausfall einer Komponente einen kritischen Dienst lahmlegt. Jede dieser Entscheidungen wird in einem Pull Request getroffen.
The shapes the same control failure takes.
Resilienz geht selten durch eine einzelne dramatische Änderung verloren. Sie schwindet, wenn ein Schutzmechanismus, der Ausfälle begrenzt hat, entfernt wird, weil er überflüssig schien. Die wiederkehrenden Muster:
Ein Circuit Breaker wird entfernt
Ein Breaker, der eine fehlerhafte Abhängigkeit isoliert hat, wird entfernt, sodass ein Downstream-Fehler nun in den kritischen Dienst durchschlägt, anstatt enthalten zu werden.
Ein Retry oder Backoff wird entfernt
Ein Retry mit Backoff um einen instabilen Aufruf wird entfernt, sodass ein vorübergehender Fehler zu einem harten Ausfall wird, der den Nutzer erreicht.
Ein Failover- oder Redundanzpfad wird entfernt
Ein Fallback zu einer sekundären Instanz, Region oder einem Anbieter wird entfernt, sodass kein Pfad mehr existiert, wenn die primäre Instanz ausfällt.
Graceful Degradation wird entfernt
Ein Pfad, der es dem Dienst ermöglichte, sich zu verschlechtern (z. B. durch Bereitstellung von zwischengespeicherten oder reduzierten Funktionen), wird durch einen harten Ausfall der gesamten Funktion ersetzt.
Ein Timeout wird entfernt
Ein Timeout für einen Aufruf an eine Abhängigkeit wird entfernt, sodass eine blockierte Abhängigkeit Threads blockieren und den gesamten Dienst zum Stillstand bringen kann.
Ein Circuit Breaker wird aus einem kritischen Aufruf entfernt.
Ein Zahlungsstatus-Dienst ruft einen Downstream-Anbieter auf. Ein Circuit Breaker um diesen Aufruf hielt den Dienst reaktionsfähig, wenn der Anbieter langsam war. Eine Refaktorierung entfernt den Breaker, weil er 'nie auslöst'. Jetzt, wenn der Anbieter langsamer wird, häufen sich die Aufrufe und der kritische Dienst kommt mit ihm zum Stillstand.
- const provider = withCircuitBreaker(rawProvider, { failureThreshold: 5 })+ const provider = rawProviderconst status = await provider.getStatus(paymentId)Das Entfernen des Circuit Breakers bedeutet, dass ein langsamer oder fehlerhafter Anbieter die kritische Zahlungsstatus-Funktion zum Stillstand bringen kann, anstatt isoliert zu werden. Art. 11 (Reaktion und Wiederherstellung) verlangt Maßnahmen, die kritische Funktionen während einer Störung resilient halten. Behalten Sie den Breaker (und seinen Fallback) bei, und wenn er nie auslöst, dann erfüllt er seine Aufgabe, nicht umgekehrt.
Resilienz muss nachweisbar sein.
DORA erwartet von einem Finanzinstitut, dass es seine operationelle Resilienz nachweisen kann: Kontinuitätsmaßnahmen, die Fähigkeit, auf IKT-Vorfälle zu reagieren und sich davon zu erholen, sowie die Prüfung all dessen. Eine Änderung, die leise einen Circuit Breaker, einen Failover oder ein Timeout entfernt, verringert diese Resilienz, und das ist im Diff sichtbar. Wenn dies in der Überprüfung erkannt wird, bleibt die nachweisbare Resilienz mit der tatsächlichen Resilienz im Einklang.
Eine Überprüfung, kein Resilienzprogramm.
heygrc markiert Änderungen, die eine DORA-Verpflichtung betreffen, und verweist auf den entsprechenden Artikel, sodass die Korrektur im Pull Request erfolgt. Es führt nicht Ihr IKT-Risikomanagementrahmen oder Ihre Resilienztests durch. Es erkennt den Moment, in dem ein Schutzmechanismus, der eine kritische Funktion resilient hielt, entfernt wird, und zwar im Diff.