Disponibilidad 24/7: Observabilidad y Resiliencia en el Core
- WAU Marketing
- 28 abr
- 4 min de lectura
Actualizado: 23 jun
El cliente de tu banco no duerme. Hace una transferencia a las 2 de la mañana, paga a las 11 de la noche, revisa su saldo en domingo. Muchos cores, en cambio, fueron diseñados para un mundo que cerraba a las cinco de la tarde. Esa distancia se paga en caídas.
La banca cambió de horario sin avisarle a su tecnología. Los pagos instantáneos lo dejaron claro: en Brasil, PIX procesó más de 63 mil millones de transacciones en 2024, operando los 365 días sin pausa, según los datos del Banco Central de Brasil. La expectativa del cliente ya no respeta la ventana de mantenimiento nocturna que el core legado da por sentada. Y cuando un sistema pensado para procesar por lotes de madrugada tiene que estar de pie a toda hora, las grietas aparecen.
El costo de caerse, en números
Una caída no es una molestia: es una factura. En la banca, el costo de una hora de inactividad supera con frecuencia los cinco millones de dólares, según la encuesta anual de costo de inactividad de ITIC, que ubica a la banca entre los sectores donde el promedio rebasa esa cifra. En el Reino Unido, un estudio de la consultora GFT (proveedor) cifró la caída promedio de un banco de inversión en más de 600,000 libras por hora, según reportó IBS Intelligence. Y el Uptime Institute encontró que más de la mitad de los operadores reportó que su última caída seria costó más de 100 mil dólares, y uno de cada cinco, más de un millón, en su Annual Outage Analysis 2024.
El caso más revelador es público. Datos entregados al Comité del Tesoro del Parlamento británico mostraron que nueve de los mayores bancos del Reino Unido acumularon más de 803 horas de caídas no planeadas —más de 33 días— en apenas dos años, repartidas en 158 incidentes, según el Treasury Committee de la Cámara de los Comunes. Entre las causas más citadas por los propios bancos están las fallas de proveedores externos y los sistemas heredados: el riesgo de concentrar todo en una infraestructura vieja y opaca.
Qué significa "estar siempre disponible"
Vale la pena ponerle número a la promesa. La disponibilidad se mide en "nueves":
99.9% suena bien hasta que lo traduces: son casi 9 horas de caída al año.
99.99% baja a unos 52 minutos al año. Es el estándar que se espera de pagos y autenticación.
99.999% son apenas 5 minutos al año, el terreno de los sistemas más críticos, según el cálculo de TechTarget.
Cada nueve adicional cuesta un orden de magnitud más de ingeniería, y no se alcanza con un core monolítico al que se le pide aguantar. Se alcanza con arquitectura.
Las dos capacidades que lo hacen posible: observabilidad y resiliencia
Aquí está el corazón técnico. Un core que opera 24/7 necesita dos cosas que el legado no trae de fábrica.
La primera es observabilidad: la capacidad de saber qué está pasando dentro del sistema en todo momento. Se apoya en tres pilares —los registros (logs), las métricas y las trazas distribuidas—. Las métricas te avisan que algo se rompió, las trazas te muestran por dónde, y los logs te dan el contexto para arreglarlo. Sin observabilidad, una caída a las 3 de la mañana es una llamada de pánico a ciegas; con ella, es un incidente que se diagnostica y se contiene.
La segunda es resiliencia: la capacidad —en la definición del Comité de Basilea— de entregar las operaciones críticas a través de la disrupción, como la establecen los Principios de Resiliencia Operativa del BCBS. No se trata de no fallar nunca; eso es imposible. Se trata de que cuando un componente falla, el sistema siga de pie. Netflix lo llevó al extremo con su famoso "Chaos Monkey", que apaga servidores al azar en producción a propósito, para obligar al sistema a ser tolerante a fallos por diseño, según documenta el propio proyecto Simian Army de Netflix. La idea de fondo aplica a un core: una pieza puede caer sin arrastrar al resto.
Seamos honestos en un punto que se suele vender mal: partir el monolito en microservicios no te hace resiliente por arte de magia. De hecho, mal hecho, añade complejidad y nuevas formas de fallar. La resiliencia real viene del paquete completo: diseño tolerante a fallos, observabilidad nativa y la disciplina de probar las fallas antes de que ocurran. No es solo trocear; es adoptar un modelo operativo.
El regulador también lo exige
No es solo buena práctica. El Banco de México opera SPEI bajo el concepto de ciberresiliencia y exige que los participantes mantengan su infraestructura tecnológica disponible y operando, conforme a la Circular 14/2017. La CNBV obliga a tener un Plan de Continuidad de Negocio actualizado al menos cada año, que contemple desde desastres naturales hasta ciberataques, según el Anexo 67 de la Circular Única de Bancos. Y a nivel internacional, los Principios de Resiliencia Operativa del Comité de Basilea marcan la pauta. La disponibilidad 24/7 dejó de ser una aspiración de marketing; es una expectativa regulatoria.
Cómo lo vemos en WAU
En WAU construimos cores para operar sin pausa: observabilidad nativa —logs, métricas y trazas desde el primer día—, arquitectura tolerante a fallos donde una pieza puede caer sin tumbar el sistema, y la disciplina de resiliencia que convierte el "ojalá no se caiga" en "está diseñado para no caerse". Tu cliente opera 24/7; tu core debería también.
Si tu core todavía piensa en horario de sucursal y cada caída te cuesta sueño y dinero, hablemos. Te mostramos qué hace falta para estar siempre de pie. 👉 Agenda una conversación con nuestro equipo.
Fuentes
ITIC — 2024 Hourly Cost of Downtime Report (banca >$5M/hora) (2024)
IBS Intelligence — Caídas de TI en bancos del Reino Unido y costo de GFT por hora (2025)
UK Parliament, Treasury Committee — 803 horas de caídas en 9 bancos, 158 incidentes (2025)
TechTarget — Disponibilidad de cinco nueves y minutos de caída por año (2024)
BCBS / BIS — Principles for Operational Resilience (mar 2021)
Banco de México — Circular 14/2017, Reglas del SPEI (ciberresiliencia)
Comentarios