Cuando GitOps choca con parches de emergencia: lecciones con ArgoCD

GitOps suena impecable sobre el papel. Defines toda tu infraestructura y despliegues en Git, tus canalizaciones se encargan del resto y herramientas como ArgoCD mantienen todo en el clúster alineado con la verdad bajo control de versiones. Es la clase de aspiración DevOps que llena ponencias en cualquier conferencia del sector.

La infraestructura real, sin embargo, es un cementerio de compromisos, alertas de madrugada y carreras para apagar fuegos. Y cuando GitOps descarrila, normalmente a las 2 AM, la persona que se despierta rara vez es el ingeniero senior que dio la charla en KubeCon. Es el SRE junior sudando frente a kubectl edit, rezando para que sus cambios se mantengan antes de que ArgoCD se dé cuenta.

La situación resulta dolorosamente reconocible y las anécdotas abundan.

GitOps frente a incendios en producción: ¿quién gana?

Una de las frustraciones más habituales con los flujos de GitOps es su rigidez por diseño. Esa rigidez es deliberada: queremos eliminar intervenciones manuales, reducir el desfase (drift) y garantizar la repetibilidad. Sin embargo, a veces esa misma repetibilidad juega en contra.

Imagina la escena: producción está caída, la canalización va lenta y las colas de aprobación están atascadas. Mientras tanto, ArgoCD, fiel guardián del estado declarado, revierte tus parches de emergencia una y otra vez porque no se aplicaron «al estilo GitOps».

Eso le ocurrió a un SRE junior al que llamaron a mitad de la noche. Ante un problema en un despliegue, recurrió a kubectl edit para intentar estabilizar el servicio, solo para ver cómo ArgoCD deshacía sus modificaciones cada pocos minutos. Para colmo, la única persona con permisos de administración en ArgoCD no estaba localizable. El desenlace fueron ocho horas de caída porque nadie pudo impedir que la automatización anulara el trabajo de emergencia.

Dista mucho de ser un caso aislado. Ocurre con más frecuencia de la que muchos equipos están dispuestos a reconocer.

Detección de desviaciones: ¿salvavidas o sabotaje?

La idea tras la detección de desviaciones es legítima: cualquier modificación realizada fuera de Git debe señalarse o revertirse. En situaciones de crisis, sin embargo, se convierte en un arma de doble filo. Como señalaba un ingeniero: «A veces simplemente hay que apagar el fuego».

Para lograrlo, muchos equipos deben pausar temporalmente la detección de desviaciones, resolver la incidencia y reactivarla tras fusionar el PR (si es que llega a fusionarse), o recurrir a accesos de emergencia breakglass (si es que existen).

Incluso entonces compites contra el ciclo de sincronización de ArgoCD. En algunas arquitecturas deshará tu corrección en milisegundos. En otras dispones de una ventana de 3 minutos antes de que vuelva a dejar el clúster en estado fallido.

El callejón sin salida de ArgoCD (catch-22)

ArgoCD merece un apartado propio porque aparece en casi todas estas historias de guardia.

Es una herramienta sólida que cumple lo que promete. Pero le resulta indiferente que los responsables de aprobar estén durmiendo o que tu CI tarde una eternidad. Forzará el último estado declarado, sin importar lo desfasado que esté respecto a la incidencia.

Esto ha provocado algunas soluciones improvisadas:

• Desactivar la sincronización automática editando el objeto de aplicación de ArgoCD a mano (kubectl edit app argocd -n argocd)
• Apuntar ArgoCD a una rama temporal de un PR para eludir el lento proceso de fusión
• Eliminar el pod del servidor de ArgoCD confiando en que al reiniciarse haya cambiado de actitud (aviso: no lo hace)

Nadie calificaría esto como buenas prácticas; son recursos nacidos de la urgencia. Pero con producción caída, la elegancia técnica pasa a un segundo plano frente al tiempo de actividad.

¿Por qué los perfiles junior tienen acceso a producción?

Uno de los puntos más debatidos en estos casos es la gestión de accesos. ¿Por qué un SRE junior tiene permisos directos en producción? ¿Es una muestra de confianza o una señal de que las guardias necesitan un replanteamiento profundo?

Hay opiniones para todos los gustos. Hay quienes defienden que los perfiles junior nunca deberían ser la primera línea de respuesta ante incidentes críticos. Otros argumentan que responder a incidentes es donde realmente se aprende, siempre que haya un perfil senior disponible para acompañar o liderar.

A menudo el acceso en sí no supone un inconveniente; lo problemático es la falta de una estructura de apoyo. Entregar a un SRE junior las llaves de producción sin salvaguardas, sin orientación y sin un procedimiento de emergencia definido resulta una imprudencia, por muy buena que sea la intención de darle autonomía.

Cómo es un buen sistema de acceso de emergencia

El acceso de emergencia o breakglass es un principio aceptado y pensado para estas situaciones exactas, pero requiere un diseño riguroso. Cada uso debe quedar registrado y revisarse después, y los permisos deben caducar de forma automática. Todo acceso exige una justificación y habitualmente un análisis posterior. Y debe ser accesible: no puede requerir despertar a cinco personas ni esperar una hora para utilizarse.

Si tu «acceso de emergencia» tarda más en desbloquearse que la propia canalización de Git, has construido una trampa en lugar de una solución.

Un equipo describía el uso de roles de AWS IAM donde puedes asumir un rol especial de breakglass mediante SSO, superando un paso adicional de confirmación. Es rápido, visible y obliga a pensar dos veces antes de actuar sin bloquear la respuesta cuando los minutos cuentan.

¿El problema es realmente GitOps?

Gran parte de estas incidencias derivan de una mala implantación más que del propio modelo GitOps.

Si tu flujo de GitOps es demasiado lento para responder a un incidente, el fallo reside en el diseño de las canalizaciones, no en el paradigma. Si dependes de una sola persona para acceder a ArgoCD, se trata de un problema organizativo y de procesos ajeno a las herramientas.

Y si los ingenieros sienten que deben saltarse el procedimiento para arreglar las cosas a tiempo, probablemente signifique que el proceso nunca estuvo diseñado para soportar las exigencias del mundo real.

Lecciones aprendidas en primera línea

Los ingenieros en estas situaciones demuestran iniciativa y capacidad de respuesta. Saben que estabilizar el sistema a veces exige saltarse las normas y les frustra verse obligados a hacerlo.

Esto es lo que los equipos pueden aplicar de verdad para mitigar los roces con GitOps en producción:

• Documenta el protocolo de emergencia. No des por hecho que todo el mundo sabe pausar ArgoCD o redirigir una sincronización. Déjalo por escrito.
• Diseña vías rápidas para parches críticos en producción. Si un cambio urgente tarda horas en fusionarse, lo que tienes es frustración continua en vez de despliegue continuo.
• Configura webhooks en ArgoCD. Deja de depender de consultas cada 3 minutos. El modo push es más rápido, menos confuso y más eficiente.
• Rota los accesos. Evita concentrar permisos críticos en una sola persona. Si hace falta intervenir en ArgoCD a las 2 AM, esa persona debe estar localizable.

Lo fundamental: realiza análisis retrospectivos (postmortems). Si algo falla gravemente, asegúrate de que quien responda la próxima guardia nocturna cuente con algo más que esperanza.

La conclusión

GitOps no está roto, aunque los procesos del equipo tal vez sí lo estén.

La automatización es tan eficaz como las personas que la gestionan, y cuando el equipo está cansado, con formación insuficiente o sin respaldo, las mejores herramientas no bastan para salvar la situación.

ArgoCD corregirá desviaciones de configuración de forma automática. Lo que no corregirá son procesos deficientes, falta de documentación o la ausencia de una red de soporte para los perfiles más jóvenes. Resuelve esos puntos y GitOps dejará de dar disgustos para hacer su trabajo con normalidad.