Caja Piura automatizó incidentes de infraestructura con Ansible y Zabbix

Caja Piura opera una infraestructura tecnológica distribuida entre dos centros de datos críticos. Piura funciona como nodo activo y Lima como centro de contingencia. El entorno combina servidores Dell VxRail, IBM Power 10 y sistemas centrales sobre IBM i, también conocido como AS400. Esta heterogeneidad exigía administrar componentes con características y procedimientos operativos distintos. La institución necesitaba sostener la continuidad de sus canales digitales y de las aplicaciones utilizadas por sus áreas administrativas. (Red Hat, 2026)

Antes de la implementación, la entidad registraba caídas recurrentes de su aplicación móvil. Los usuarios internos también experimentaban lentitud en el ERP, con efectos sobre Contabilidad y Recursos Humanos. El cierre mensual del sistema requería intervenciones técnicas manuales, incluso a las 6:00 a. m. Los pases a producción dependían de manuales operativos estáticos. Esta modalidad exigía coordinaciones entre equipos y dificultaba mantener criterios uniformes de validación. (Red Hat, 2026)

La respuesta a incidentes de infraestructura también dependía del personal técnico. Las alertas por consumo crítico de CPU o saturación de almacenamiento requerían una revisión manual antes de ejecutar correcciones. Según Red Hat, estas condiciones prolongaban la atención de problemas y aumentaban la exposición a errores operacionales. La falta de trazabilidad uniforme dificultaba reconstruir las intervenciones realizadas durante los cambios de producción. (Red Hat, 2026)

El problema tenía implicancias para la continuidad operativa. Una anomalía de infraestructura podía afectar aplicaciones internas o canales digitales antes de recibir atención. La necesidad de coordinar operadores, validar procedimientos y ejecutar tareas repetitivas añadía dependencia del conocimiento individual. (Red Hat, 2026) La automatización de incidentes de TI en empresas adquiere relevancia cuando esas actividades forman parte de la operación habitual de servicios críticos.

Caja Piura seleccionó Red Hat Ansible Automation Platform 2.5 para centralizar y estandarizar procedimientos tecnológicos. La implementación incorporó workflows y job templates para ejecutar operaciones repetibles y auditables. Red Hat Consulting Services acompañó el proyecto y vinculó la selección de procesos con las prioridades operativas de la institución. El alcance inicial se concentró en actividades que dependían de ejecuciones manuales frecuentes. (Red Hat, 2026)

El proyecto contempló cuatro procesos operativos: pases a producción con procedimientos de reversión, reinicios secuenciales de servicios, limpieza programada de servidores y remediación de problemas de almacenamiento y CPU. La selección permitió organizar tareas recurrentes dentro de procedimientos estandarizados. Los workflows también establecieron una base común para operaciones ejecutadas en los centros de datos de Piura y Lima. (Red Hat, 2026)

La decisión incluyó conectar la automatización con el sistema de monitoreo existente. Zabbix quedó integrado con Event-Driven Ansible para activar respuestas ante anomalías de infraestructura. (Red Hat, 2026; Red Hat, 2026) Esta integración permitió relacionar determinados eventos de rendimiento con acciones correctivas previamente definidas. La operación podía ejecutar remediaciones sin esperar que un técnico revisara cada alerta. (Red Hat, 2026)

La arquitectura separó las funciones de supervisión y ejecución. Zabbix identifica las condiciones anómalas, mientras Event-Driven Ansible procesa los eventos y activa las tareas correspondientes. (Red Hat, 2026) Esta separación facilita diseñar procedimientos específicos según el tipo de incidente y el componente tecnológico afectado. La selección de acciones automáticas requiere definir previamente qué condiciones justifican una intervención sin aprobación manual.

La arquitectura documentada comienza con los activadores de rendimiento de Zabbix. El sistema monitorea condiciones de infraestructura y genera eventos cuando identifica anomalías. Event-Driven Ansible recibe esas señales mediante webhooks y flujos de datos. La plataforma determina qué plantilla de trabajo corresponde al evento y solicita la ejecución del procedimiento correctivo. Ante determinadas condiciones críticas, como un disco lleno, Caja Piura ejecuta automáticamente un playbook de remediación. (Red Hat, 2026)

La documentación técnica de Red Hat explica el mecanismo general de Event-Driven Ansible mediante una fuente de eventos, una condición de evaluación y una acción. El controlador de decisiones utiliza reglas definidas en rulebooks para determinar cuándo corresponde activar un playbook o workflow. Esta estructura permite establecer respuestas diferentes según las propiedades del evento recibido. La guía también documenta integraciones mediante webhooks y Kafka. (Red Hat Customer Portal, 2026)

Red Hat describe Event Streams como una capacidad para incorporar autenticación y enrutamiento a los eventos recibidos por webhooks. (Red Hat Customer Portal, 2026) Esa funcionalidad pertenece a la documentación general del producto. La fuente del caso no confirma qué mecanismos específicos de autenticación o enrutamiento configuró Caja Piura. (Red Hat, 2026; Red Hat Customer Portal, 2026) Esta distinción importa al evaluar la arquitectura publicada, porque el funcionamiento documentado de una plataforma no acredita todas las configuraciones utilizadas por una organización.

La automatización de Caja Piura abarcó infraestructura local y sistemas heredados. Red Hat documentó operaciones sobre Dell VxRail e IBM Power 10. También identificó tareas automatizadas en instancias de IBM DB2, servidores Apache Tomcat y aplicaciones Red Hat JBoss EAP. La implementación incorporó conectividad con procesos asociados a IBM i. Los workflows permitieron estandarizar tareas de despliegue y mantenimiento entre los centros de datos de Piura y Lima. (Red Hat, 2026)

La ejecución de reinicios secuenciales y procedimientos de reversión formó parte de los procesos automatizados. La estandarización buscaba reducir diferencias entre las operaciones realizadas por distintos turnos y equipos. (Red Hat, 2026) Para un jefe de TI, este diseño plantea la necesidad de conservar dependencias entre servicios, condiciones de ejecución y criterios de validación. Cada procedimiento debe identificar el estado esperado antes de actuar y la evidencia necesaria para confirmar su recuperación.

Red Hat publicó el estudio de caso el 14 de octubre de 2026. (Red Hat, 2026) Al momento de su publicación, la solución llevaba aproximadamente 10 meses en producción. (Red Hat, 2026; Red Hat, 2026) El fabricante informó mejoras de rendimiento del 75 %, 80 % y 83 % en la ejecución de procesos operativos críticos. El documento presenta esos porcentajes como resultados asociados a la velocidad de ejecución. (Red Hat, 2026)

El estudio no identifica qué porcentaje corresponde a cada proceso automatizado. Tampoco publica los tiempos absolutos anteriores y posteriores ni explica el método utilizado para calcular esas mejoras. (Red Hat, 2026) Por tanto, las cifras no permiten determinar una reducción porcentual del tiempo medio de resolución de incidentes. Tampoco representan indicadores de disponibilidad de aplicaciones ni porcentajes de disminución de fallas.

Red Hat informa que determinadas remediaciones, como la corrección de una condición crítica de almacenamiento, pueden ejecutarse en segundos y sin intervención humana. También atribuye al proyecto una menor dependencia de tareas manuales durante los cierres mensuales del ERP. El fabricante reporta una reducción de la variabilidad operativa entre turnos y equipos, junto con menos errores humanos. (Red Hat, 2026)

La publicación señala una mayor disponibilidad de la aplicación móvil y del canal web. Asimismo, comunica una mejora de estabilidad en los sistemas administrativos. Sin embargo, estos beneficios se presentan de manera cualitativa. El estudio no proporciona porcentajes de disponibilidad anteriores y posteriores ni una serie histórica de incidentes. (Red Hat, 2026) La evidencia publicada permite identificar las mejoras declaradas por el proveedor, pero resulta insuficiente para calcular su magnitud operacional con indicadores independientes.

El caso ofrece un criterio para seleccionar procesos candidatos a la automatización: identificar tareas repetitivas con procedimientos conocidos y resultados verificables. El inventario inicial debe registrar la aplicación afectada, el componente técnico, la señal de monitoreo y la acción correctiva autorizada. También conviene establecer dependencias entre servicios para evitar que una remediación aislada interrumpa otros procesos. La evaluación debe incluir los permisos necesarios y las condiciones que obligan a escalar el incidente a un operador.

El diseño de los flujos requiere distinguir las alertas informativas de las condiciones que autorizan una ejecución automática. Un procedimiento puede incorporar validaciones previas, límites de ejecución y mecanismos de reversión. Las tareas con impacto sobre datos o servicios críticos necesitan controles de cambio específicos. Las pruebas deben comprobar el resultado de la remediación y su comportamiento ante errores. El registro de ejecución debe conservar la alerta original, la acción realizada y el estado posterior del servicio.

La continuidad introduce obligaciones adicionales para las entidades financieras comprendidas en la regulación. La Resolución SBS N.° 00814-2025 establece tiempos objetivos de recuperación de hasta 3 horas para empresas con concentración de mercado y 5 horas para las demás empresas de su alcance, respecto de los servicios digitales priorizados que identifica la norma. También exige monitoreo, pruebas anuales y registros centralizados de interrupciones superiores a 30 minutos para los servicios comprendidos. (Superintendencia de Banca, Seguros y AFP (SBS), 2025) La automatización debe integrarse con esos procedimientos de continuidad y con las responsabilidades de gestión de incidentes.

En septiembre de 2026, la SBS publicó para consulta un proyecto de procedimiento único de reporte de incidentes operacionales significativos. La propuesta incluye fallas de sistemas, interrupciones operativas y otras categorías de incidentes. Plantea un plazo inicial máximo de 5 horas para las cajas municipales comprendidas en ese supuesto. Estas disposiciones correspondían a un proyecto normativo y no deben tratarse como obligaciones aprobadas. (Superintendencia de Banca, Seguros y AFP (SBS), 2026)

Para evaluar resultados, el área de TI necesita conservar una línea base de tiempos de detección, atención y recuperación. También debe registrar los incidentes recurrentes, las ejecuciones automáticas fallidas y las intervenciones que todavía requieren aprobación humana. La comparación posterior debe utilizar el mismo alcance de servicios y criterios de medición. El registro resultante permite reconstruir qué alerta activó cada procedimiento, qué acción ejecutó la plataforma y si el servicio recuperó su estado esperado.