Nadie sabía quién aprobó el cambio: anatomía de un incidente evitable

En sistemas empresariales complejos, los incidentes técnicos rara vez son el resultado de un solo error. La mayoría de las interrupciones graves en producción ocurren cuando una serie de pequeñas decisiones muchas veces invisibles se combinan en el momento equivocado.

Uno de los factores más comunes detrás de estos incidentes no es tecnológico.

Es organizacional.

Y suele aparecer cuando nadie puede responder una pregunta aparentemente simple:

¿Quién aprobó este cambio?

Esto ocurrió en una empresa del sector telecomunicaciones que operaba múltiples plataformas digitales utilizadas por millones de usuarios. Su infraestructura estaba compuesta por aplicaciones distribuidas, microservicios desplegados en contenedores y entornos cloud híbridos que combinaban recursos on-premise con servicios en AWS.

La organización había crecido rápidamente, incorporando nuevos equipos de desarrollo, proveedores externos y múltiples herramientas de integración.

Desde el punto de vista técnico, el sistema funcionaba.

Pero el gobierno del cambio no estaba claramente definido.

Cada equipo gestionaba sus repositorios de código de forma independiente. Algunos utilizaban pipelines automatizados para despliegues, otros realizaban despliegues manuales desde servidores de integración.

Las aprobaciones de cambios se realizaban en algunos casos mediante revisiones de código, en otros mediante mensajes internos o tickets en sistemas de gestión.

No existía una autoridad clara dentro del proceso.

Durante meses, el sistema operó sin incidentes significativos.

Hasta que un viernes por la noche ocurrió algo inesperado.

Una actualización menor en un servicio de autenticación comenzó a generar errores intermitentes en el proceso de inicio de sesión de los usuarios. El problema no afectaba a todos los clientes, pero provocaba fallos aleatorios en distintos puntos de la plataforma.

El equipo de operaciones comenzó a investigar el incidente.

Los logs mostraban que el servicio había sido actualizado horas antes.

Sin embargo, cuando se intentó rastrear el origen del cambio surgió el verdadero problema.

El código había sido modificado en un repositorio que no estaba vinculado al sistema central de despliegues. El pipeline utilizado para esa aplicación no registraba aprobaciones formales, y la actualización había sido realizada directamente desde un entorno de integración.

Nadie sabía con certeza quién había autorizado el cambio.

La investigación tomó varias horas.

Mientras tanto, el equipo de operaciones tuvo que revertir manualmente versiones del servicio para estabilizar la plataforma.

El incidente no fue causado por una vulnerabilidad crítica ni por una falla de infraestructura.

Fue causado por la ausencia de control sobre el proceso de cambio.

Después del incidente, la empresa decidió rediseñar completamente su modelo de gobierno DevOps.

El primer paso fue centralizar el control del ciclo de desarrollo utilizando una plataforma unificada de gestión de repositorios y pipelines basada en GitLab.

Todos los repositorios de código se integraron dentro de una misma estructura organizacional, y cada cambio debía pasar por un proceso formal de revisión mediante Merge Requests.

Este mecanismo garantizaba que ninguna modificación llegara al código principal sin una revisión técnica documentada.

El segundo cambio fue establecer pipelines obligatorios para los despliegues.

Cada actualización debía ejecutarse a través de procesos automatizados que registraban quién iniciaba el despliegue, qué versión del código se implementaba y en qué entorno se realizaba la operación.

Este enfoque creó una trazabilidad completa del ciclo de desarrollo.

Además, se implementaron políticas de control que impedían desplegar cambios directamente en producción sin cumplir con las validaciones definidas por la organización.

Estas políticas incluían revisiones de código, pruebas automatizadas y controles de seguridad antes de permitir que el pipeline avanzara.

El resultado fue un sistema mucho más disciplinado.

Los equipos continuaron trabajando con rapidez, pero ahora dentro de un marco de control claro donde cada cambio quedaba registrado y era verificable.

La experiencia dejó una lección fundamental.

En entornos tecnológicos complejos, la velocidad del desarrollo no es el único factor importante.

La trazabilidad del cambio es igual de crítica.

Cuando un incidente ocurre, la capacidad de reconstruir qué sucedió quién cambió qué, cuándo y por qué puede marcar la diferencia entre una interrupción controlada y una crisis operativa.

En AIT LATAM ayudamos a las organizaciones a diseñar modelos de gobierno DevOps donde los pipelines no solo automatizan despliegues, sino que también actúan como mecanismos de control y trazabilidad del ciclo completo de desarrollo.

Porque en sistemas empresariales, la pregunta más importante después de un incidente no es qué falló.

Es si la organización puede explicar exactamente cómo ocurrió.