Una variable de entorno derribó el sitio de ventas: qué falla cuando CI/CD no tiene guardianes

La noche en el bar que nadie quiere repetir

Estás en un bar esperando a unos amigos. Llega un mensaje urgente: el sitio de ventas está caído. No diez minutos caído — todo el día caído. Accedes por SSH desde el móvil, revisas la configuración y encuentras una variable de entorno apuntando a localhost. Una sola variable. Un día entero de inactividad.

Lo más desconcertante no es el fallo técnico. Es que nadie avisó hasta el final del día. Sí había llegado una alerta de Uptime Kuma por la mañana, pero últimamente los desarrolladores hacen push a producción sin comunicarlo, así que se asumió que era otro despliegue en curso. Se ignoró. Y el sitio siguió caído.

Este escenario no es una anécdota de un foro. Es el tipo de situación que le ocurre a equipos reales, con desarrolladores competentes y responsables de infraestructura experimentados. Y casi siempre apunta al mismo diagnóstico: el proceso está roto, no la persona.

El error técnico fue pequeño. Las consecuencias, no

Un desarrollador senior modificó variables de entorno en GitHub Actions y ejecutó un push. El pipeline se disparó, desplegó con la variable incorrecta y el sitio quedó inoperativo. Técnicamente hablando, algo equivalente a un redirect_uri apuntando a localhost en lugar del dominio real: pequeño en tamaño, devastador en efecto.

El fallo no requirió malas intenciones ni incompetencia flagrante. Requirió que una sola persona tuviera acceso de escritura a variables de entorno de producción sin ningún paso de revisión intermedio. Eso es todo.

Para cualquier negocio que dependa de su sitio web para generar ingresos, un día de caída no es un problema técnico abstracto. Es pérdida directa de ventas, es clientes que no pudieron completar sus pedidos y que quizás no vuelvan, y es la confianza en la plataforma tocada. Si hay acuerdos de nivel de servicio con clientes o partners, también hay riesgo de incumplimiento. El coste real de ese día supera con creces el tiempo que habría llevado implementar controles básicos.

La responsabilidad es compartida — y eso es útil saberlo

Una reacción común en este tipo de situaciones es buscar al responsable individual. Y parte de la comunidad que debatió este caso fue directa: el desarrollador cometió el error, sí, pero quien diseñó la infraestructura permitió que ese error tuviera consecuencias catastróficas.

Lo interesante es que el propio responsable de infraestructura lo reconoció sin rodeos: 'debería haber creado un proceso mejor'. Esa autocrítica es exactamente el punto de partida correcto. No sirve de mucho revocar accesos si el sistema subyacente sigue permitiendo que un único cambio sin revisión llegue a producción.

Revocar el acceso de una persona es un parche. Rediseñar el flujo de despliegue es la solución.

Qué significa tener un proceso roto en CI/CD

Un pipeline de CI/CD sin controles de aprobación es como una autopista sin límite de velocidad: la mayoría de las veces funciona, hasta que no funciona. Los síntomas de un proceso roto suelen ser estos:

• Cualquier desarrollador puede modificar variables de entorno de producción directamente. No hay capa de revisión.
• Los despliegues a producción se hacen sin comunicación previa al responsable de infraestructura. Las alertas pierden contexto y se ignoran.
• No hay distinción entre entornos: el mismo nivel de acceso sirve para staging y para producción.
• Las alertas de monitorización no tienen correlación con eventos de despliegue, así que cuando llega una notificación de caída, no hay forma de saber si es un fallo real o un despliegue en curso.

Cada uno de estos puntos por separado es manejable. Todos juntos crean el escenario del bar.

La solución que funciona: GitOps con ramas protegidas y approval workflows

La propuesta que más resonó en la discusión técnica sobre este caso fue implementar GitOps de forma rigurosa: el repositorio es la única fuente de verdad. Ninguna variable de entorno se edita directamente en producción ni en la consola de GitHub Actions. Todo pasa por el repositorio y todo despliegue requiere una merge request revisada y aceptada.

El flujo concreto que funciona en entornos reales tiene esta estructura:

• Los desarrolladores trabajan en ramas desechables (feature branches). Pueden hacer push libremente ahí.
• Para llegar a staging o producción, la rama debe mergearse mediante una MR que requiere al menos una revisión aprobada.
• La rama principal de producción está protegida: nadie puede hacer push directo, ni siquiera el responsable de infraestructura. Solo el pipeline puede escribir en ella tras la aprobación.
• Las variables de entorno se construyen automáticamente desde los pipelines, a partir de secretos gestionados de forma centralizada. Los desarrolladores no tienen acceso de escritura directo sobre ellas en producción.

Con este esquema, el fallo descrito al inicio del artículo simplemente no puede ocurrir. Para que una variable incorrecta llegue a producción, alguien tendría que crear la MR, que alguien la revisara y aprobara sin detectar el error, y que el pipeline la desplegara. Son tres capas de fricción deliberada. Si aun así ocurre, ya no es un fallo de infraestructura: es un fallo humano colectivo, y eso es mucho más difícil de cometer por accidente.

Las alertas necesitan contexto, no solo señal

Hay un detalle en este caso que vale la pena subrayar: la alerta de Uptime Kuma llegó por la mañana y fue ignorada porque no había forma de saber si correspondía a un despliegue en progreso o a una caída real.

Esto no es un problema de Uptime Kuma. Es un problema de correlación de eventos. Una buena práctica es integrar las notificaciones de despliegue con el sistema de monitorización: cuando el pipeline dispara un despliegue, se registra en el mismo canal donde llegan las alertas. Así, si llega una notificación de caída durante o justo después de un despliegue, el responsable tiene contexto inmediato. Si llega en un momento sin despliegue reciente, es una alerta genuina que hay que atender de inmediato.

Sin ese contexto, las alertas se convierten en ruido. Y el ruido mata la capacidad de respuesta.

Tres preguntas que vale la pena hacerse ahora

Antes de que ocurra el próximo incidente, hay tres preguntas concretas que cualquier equipo debería poder responder:

• ¿Cómo se comunican los despliegues a producción en tu equipo? ¿Hay un canal específico, un registro automático, o cada desarrollador decide si avisa o no? Si la respuesta es 'depende', el proceso está incompleto.
• ¿Sabes cuántos despliegues a producción se hacen cada semana sin revisión previa? Si no tienes esa métrica, probablemente la respuesta sea 'todos' o 'no lo sé', y ambas son señales de alerta.
• ¿Qué eventos adicionales deberían generar alerta inmediata? Un cambio en variables de entorno de producción, un despliegue fallido, una modificación en configuración de red — estos eventos deberían notificar de forma diferenciada, no mezclarse con el monitoreo general de disponibilidad.

El coste de implementar esto es bajo. El de no hacerlo, ya lo conoces

Las herramientas para implementar todo lo descrito arriba — branch protection rules, approval workflows, gestión de secretos, pipelines con entornos separados — están disponibles de forma nativa en GitHub, GitLab y Gitea. En la mayoría de los casos, sin coste adicional o con un coste marginal.

El tiempo de implementación de un flujo GitOps básico con ramas protegidas y revisión obligatoria en una pyme pequeña se mide en días, no en meses. El ROI es evidente: un solo día de caída de un sitio de ventas justifica con creces esa inversión.

Además, estas prácticas no son arbitrarias. El control de cambios con aprobación previa y la separación de entornos son pilares del control de acceso y gestión del riesgo operacional que recogen marcos de referencia como la ISO 27001. No hace falta certificarse para beneficiarse de la lógica que hay detrás.

Una nota sobre IA en los pipelines

Hay un ángulo que la comunidad también apuntó y que merece atención: si se empieza a integrar automatización con modelos de lenguaje en los pipelines de CI/CD — algo cada vez más común —, los controles de acceso deben ser más estrictos aún que para humanos, no más laxos. Un humano tiene conciencia de normas sociales y consecuencias. Un agente automatizado, no. Cualquier puerta que hoy está abierta para un desarrollador con buenas intenciones debe estar cerrada con doble llave para un proceso automatizado que opera sin contexto.

Esto no es un argumento contra la automatización. Es un argumento para diseñarla bien desde el principio.

El proceso, no la persona

El desarrollador del caso cometió un error. El responsable de infraestructura lo reconoce también en su propio proceso. Ninguno de los dos es el villano de la historia. El villano es un sistema de despliegue que permitía que un único cambio sin revisión llegara a producción y lo tumbara todo.

Arreglar eso no requiere culpar a nadie. Requiere un par de días de trabajo técnico, unas reglas claras sobre quién puede hacer qué en cada entorno, y un canal de comunicación donde los despliegues dejen rastro antes de ejecutarse.

Si en tu equipo ahora mismo alguien puede modificar una variable de producción y desplegar sin que nadie lo revise, ya sabes dónde está tu próxima noche en el bar.