heygrc
DORA - odporność operacyjna i odzysk w kodzie

Odporność operacyjna, jeden usunięty mechanizm zabezpieczający po drugim.

Art. 11 DORA (odporność operacyjna i odzysk) dotyczy utrzymywania krytycznych funkcji w działaniu podczas zakłóceń oraz odzysku po nich: środki ciągłości działania i reagowania na incydenty związane z ICT. Dla podmiotów finansowych duża część tej odporności jest budowana w kodzie - to ponawianie próby, circuit breakery, awaryjne przełączanie i limity czasu, które zapobiegają rozprzestrzenianiu się awarii jednego komponentu na krytyczną usługę. Każda z tych decyzji jest podejmowana w pull requestach.

How it shows up in a diff

The shapes the same control failure takes.

Odporność rzadko ginie w wyniku jednej dramatycznej zmiany. Zazwyczaj eroduje, gdy usuwany jest mechanizm zabezpieczający, który powstrzymywał awarię, ponieważ wydawał się zbędny. Typowe wzorce:

  • Usunięcie circuit breakera

    Circuit breaker, który izolował awarię zależności, zostaje usunięty, przez co awaria w dół łańcucha rozprzestrzenia się na krytyczną usługę zamiast zostać powstrzymana.

  • Usunięcie ponowienia próby lub backoffu

    Ponawianie próby z backoffem wokół niestabilnego wywołania zostaje usunięte, przez co tymczasowy błąd staje się trwałą awarią, która dociera do użytkownika.

  • Usunięcie awaryjnego przełączania lub ścieżki redundancji

    Przełączanie na zapasową instancję, region lub dostawcę zostaje usunięte, pozostawiając brak alternatywnej ścieżki, gdy główna ulegnie awarii.

  • Usunięcie stopniowej degradacji

    Ścieżka, która pozwalała usłudze działać w trybie degradacji (obsługiwać buforowane lub ograniczone funkcjonalności), zostaje zastąpiona przez całkowitą awarię całej funkcji.

  • Usunięcie limitu czasu

    Limit czasu na wywołanie zależności zostaje usunięty, przez co zawieszona zależność może blokować wątki i zatrzymać całą usługę.

Worked example

Usunięcie circuit breakera z krytycznego wywołania.

Usługa sprawdzająca status płatności wywołuje dostawcę zewnętrznego. Circuit breaker wokół tego wywołania utrzymywał responsywność usługi, gdy dostawca działał wolno. Refaktoryzacja usuwa circuit breakera, ponieważ 'nigdy nie ulegał aktywacji'. Teraz, gdy dostawca zwalnia, wywołania gromadzą się, a krytyczna usługa również się zatrzymuje.

payments/status.ts+1 -1
- const provider = withCircuitBreaker(rawProvider, { failureThreshold: 5 })+ const provider = rawProviderconst status = await provider.getStatus(paymentId)
heygrcDORA Art. 11

Usunięcie circuit breakera oznacza, że wolny lub awaryjny dostawca może zatrzymać krytyczną funkcję sprawdzania statusu płatności zamiast zostać odizolowany. Art. 11 (odporność operacyjna i odzysk) wymaga środków, które utrzymują krytyczne funkcje odporne podczas zakłóceń. Zachowaj circuit breakera (oraz jego awaryjne przełączanie), a jeśli nigdy nie ulegał aktywacji, to oznacza, że spełnia swoją rolę, a nie że należy go usunąć.

What an auditor does with this

Odporność operacyjną trzeba móc zademonstrować.

DORA oczekuje, że podmiot finansowy będzie mógł udowodnić swoją odporność operacyjną: środki ciągłości działania, zdolność do reagowania na incydenty ICT i odzysku po nich oraz testowanie wszystkich tych elementów. Zmiana, która cicho usuwa circuit breakera, awaryjne przełączanie lub limit czasu, osłabia tę odporność, a jest to widoczne w diffie. Wychwycenie tego podczas przeglądu sprawia, że odporność, którą można zademonstrować, odpowiada rzeczywistej odporności.

What this is, and is not

Przegląd, a nie program odporności.

heygrc sygnalizuje zmiany, które dotyczą obowiązku DORA, i podaje odpowiedni artykuł, aby naprawa nastąpiła w pull requestach. Nie prowadzi jednak ramowego zarządzania ryzykiem ICT ani testów odporności. Wychwytuje moment, w którym usuwany jest mechanizm zabezpieczający, który utrzymywał krytyczną funkcję odporną, bezpośrednio w diffie.