Resiliencia operativa, un salvaguarda menos a la vez.
El Art. 11 de DORA (respuesta y recuperación) trata sobre mantener las funciones críticas en funcionamiento durante una interrupción y recuperarse de ella: medidas de continuidad del negocio y respuesta ante incidentes relacionados con las TIC. Para una entidad financiera, gran parte de esa resiliencia se construye en el código, con los reintentos, circuit breakers, conmutaciones por error y tiempos de espera que evitan que el fallo de un componente derribe un servicio crítico. Cada una de esas decisiones se toma en una solicitud de extracción.
The shapes the same control failure takes.
La resiliencia rara vez se pierde en un cambio drástico. Se erosiona cuando se elimina una salvaguarda que contenía un fallo porque parecía redundante. Las formas recurrentes:
Se elimina un circuit breaker
Se suprime un circuit breaker que aislaba una dependencia con fallos, por lo que ahora un fallo aguas abajo se propaga en cascada al servicio crítico en lugar de contenerse.
Se elimina un reintento o retroceso
Se suprime el reintento con retroceso en una llamada inestable, por lo que un fallo transitorio se convierte en un fallo crítico que llega al usuario.
Se elimina una ruta de conmutación por error o redundancia
Se suprime la conmutación a una instancia, región o proveedor secundario, dejando sin ruta cuando falla el principal.
Se elimina la degradación controlada
Se reemplaza una ruta que permitía al servicio degradarse (servir contenido en caché o con funcionalidad reducida) por un fallo crítico de toda la función.
Se elimina un tiempo de espera
Se suprime el tiempo de espera en una llamada a una dependencia, por lo que una dependencia bloqueada puede bloquear hilos y paralizar todo el servicio.
Un circuit breaker eliminado de una llamada crítica.
Un servicio de estado de pagos realiza una llamada a un proveedor aguas abajo. Un circuit breaker alrededor de esa llamada mantenía el servicio receptivo cuando el proveedor era lento. Una refactorización elimina el circuit breaker porque 'nunca se activa'. Ahora, cuando el proveedor se degrada, las llamadas se acumulan y el servicio crítico se paraliza con él.
- const provider = withCircuitBreaker(rawProvider, { failureThreshold: 5 })+ const provider = rawProviderconst status = await provider.getStatus(paymentId)Eliminar el circuit breaker significa que un proveedor lento o con fallos puede paralizar la función crítica de estado de pagos en lugar de aislarse. El Art. 11 (respuesta y recuperación) exige medidas que mantengan las funciones críticas resilientes durante una interrupción. Mantén el circuit breaker (y su conmutación por error), y si nunca se activa, es porque está haciendo su trabajo, no una razón para eliminarlo.
La resiliencia es algo que hay que poder demostrar.
DORA espera que una entidad financiera pueda demostrar su resiliencia operativa: medidas de continuidad, la capacidad de responder y recuperarse de incidentes de TIC y las pruebas de todo ello. Un cambio que elimina silenciosamente un circuit breaker, una conmutación por error o un tiempo de espera reduce esa resiliencia, y es visible en el diff. Detectarlo en la revisión garantiza que la resiliencia que puedes demostrar coincida con la que realmente tienes.
Una revisión, no un programa de resiliencia.
heygrc marca los cambios que afectan a una obligación de DORA y cita el artículo para que la corrección se realice en la solicitud de extracción. No ejecuta tu marco de gestión de riesgos de TIC ni tus pruebas de resiliencia. Detecta el momento en que se elimina una salvaguarda que mantenía resiliente una función crítica, en el diff.