Resilienza operativa, un salvaguardia rimossa alla volta.
L'Art. 11 del DORA (response and recovery) riguarda il mantenimento delle funzioni critiche durante un'interruzione e il recupero da essa: misure di continuità operativa e risposta agli incidenti ICT. Per un ente finanziario, gran parte di questa resilienza è costruita nel codice, con retry, circuit breaker, failover e timeout che impediscono a un guasto di un componente di compromettere un servizio critico. Ogni decisione di questo tipo è una scelta nella pull request.
The shapes the same control failure takes.
La resilienza non si perde quasi mai in un cambiamento drammatico. Si erode quando una salvaguardia che conteneva un guasto viene rimossa perché sembrava ridondante. Le forme ricorrenti:
Un circuit breaker viene rimosso
Un breaker che isolava una dipendenza guasta viene eliminato, quindi un guasto a valle ora si propaga nel servizio critico invece di essere contenuto.
Un retry o backoff viene rimosso
Un retry con backoff intorno a una chiamata instabile viene rimosso, quindi un problema transitorio diventa un guasto permanente che raggiunge l'utente.
Un failover o percorso di ridondanza viene rimosso
Un fallback verso un'istanza secondaria, una regione o un provider viene eliminato, lasciando senza alternative in caso di guasto del primario.
Un degrado controllato viene rimosso
Un percorso che permetteva al servizio di degradarsi (servire contenuti cache o funzionalità ridotte) viene sostituito da un guasto completo della funzione.
Un timeout viene rimosso
Un timeout su una chiamata a una dipendenza viene rimosso, quindi una dipendenza bloccata può occupare thread e bloccare l'intero servizio.
Un circuit breaker rimosso da una chiamata critica.
Un servizio di stato dei pagamenti chiama un provider a valle. Un circuit breaker intorno a quella chiamata manteneva il servizio reattivo quando il provider era lento. Un refactoring rimuove il breaker perché 'non scatta mai'. Ora, quando il provider si degrada, le chiamate si accumulano e il servizio critico si blocca insieme a esso.
- const provider = withCircuitBreaker(rawProvider, { failureThreshold: 5 })+ const provider = rawProviderconst status = await provider.getStatus(paymentId)Rimuovere il circuit breaker significa che un provider lento o guasto può bloccare la funzione critica di stato dei pagamenti invece di essere isolato. L'Art. 11 (response and recovery) richiede misure che mantengano le funzioni critiche resilienti durante un'interruzione. Mantenere il breaker (e il suo fallback) è necessario, e se non scatta mai, significa che sta svolgendo il suo compito, non che debba essere rimosso.
La resilienza è qualcosa che devi essere in grado di dimostrare.
Il DORA si aspetta che un ente finanziario possa dimostrare la propria resilienza operativa: misure di continuità, la capacità di rispondere e recuperare dagli incidenti ICT e il test di tutto ciò. Un cambiamento che rimuove silenziosamente un circuit breaker, un failover o un timeout riduce questa resilienza, e questo è visibile nel diff. Rilevarlo durante la revisione assicura che la resilienza dimostrabile corrisponda a quella effettivamente presente.
Una revisione, non un programma di resilienza.
heygrc segnalerà le modifiche che interessano un obbligo DORA e citerà l'articolo in modo che la correzione avvenga nella pull request. Non gestisce il framework di risk management ICT né i test di resilienza. Intercetta il momento in cui una salvaguardia che manteneva resiliente una funzione critica viene rimossa, direttamente nel diff.