La résilience opérationnelle, une sauvegarde supprimée à la fois.
L'article 11 de DORA (réponse et reprise) traite du maintien des fonctions critiques en cas de perturbation et de la reprise après celle-ci : mesures de continuité d'activité et de réponse aux incidents liés aux TIC. Pour une entité financière, une grande partie de cette résilience est intégrée dans le code, via les relances, les disjoncteurs, les basculements et les délais d'attente qui empêchent la défaillance d'un composant de faire tomber un service critique. Chacune de ces décisions se prend dans une pull request.
The shapes the same control failure takes.
La résilience ne se perd rarement en un seul changement spectaculaire. Elle s'érode lorsqu'une sauvegarde qui contenait une défaillance est supprimée parce qu'elle semblait redondante. Les schémas récurrents :
Un disjoncteur est supprimé
Un disjoncteur qui isolait une dépendance défaillante est retiré, donc une défaillance en aval se propage désormais dans le service critique au lieu d'être contenue.
Une relance ou un délai d'attente est supprimé
La relance avec délai d'attente autour d'un appel instable est supprimée, donc une perturbation temporaire devient une défaillance définitive qui atteint l'utilisateur.
Un basculement ou un chemin redondant est supprimé
Un repli vers une instance, une région ou un fournisseur secondaire est retiré, ne laissant aucun chemin lorsque le principal tombe en panne.
La dégradation gracieuse est supprimée
Un chemin qui permettait au service de se dégrader (servir des données en cache ou des fonctionnalités réduites) est remplacé par une défaillance totale de la fonction.
Un délai d'attente est supprimé
Un délai d'attente sur un appel à une dépendance est supprimé, donc une dépendance bloquée peut bloquer des threads et paralyser l'ensemble du service.
Un disjoncteur supprimé d'un appel critique.
Un service de statut de paiement appelle un fournisseur en aval. Un disjoncteur autour de cet appel maintenait le service réactif lorsque le fournisseur était lent. Une refactorisation supprime le disjoncteur car il 'ne se déclenche jamais'. Maintenant, lorsque le fournisseur se dégrade, les appels s'accumulent et le service critique se bloque avec lui.
- const provider = withCircuitBreaker(rawProvider, { failureThreshold: 5 })+ const provider = rawProviderconst status = await provider.getStatus(paymentId)Supprimer le disjoncteur signifie qu'un fournisseur lent ou défaillant peut bloquer la fonction critique de statut de paiement au lieu d'être isolé. L'article 11 (réponse et reprise) exige des mesures qui maintiennent les fonctions critiques résilientes en cas de perturbation. Gardez le disjoncteur (et son repli), et si celui-ci ne se déclenche jamais, c'est qu'il fait son travail, pas une raison de le supprimer.
La résilience est quelque chose que vous devez pouvoir démontrer.
DORA attend d'une entité financière qu'elle puisse démontrer sa résilience opérationnelle : mesures de continuité, capacité à répondre et à se remettre des incidents liés aux TIC, et tests de tout cela. Un changement qui supprime discrètement un disjoncteur, un basculement ou un délai d'attente réduit cette résilience, et cela est visible dans le diff. Le détecter lors de la revue permet de maintenir la résilience que vous pouvez démontrer en accord avec celle que vous possédez réellement.
Une revue, pas un programme de résilience.
heygrc signale les modifications qui concernent une obligation DORA et cite l'article afin que la correction ait lieu dans la pull request. Il ne gère pas votre cadre de gestion des risques TIC ni vos tests de résilience. Il détecte le moment où une sauvegarde qui maintenait une fonction critique résiliente est supprimée, au niveau du diff.