Editar en prod: una carta a todo SRE que ha tenido que romper el cristal

Hay un tipo de pánico que solo aparece a las 2AM. Las alertas empiezan a sonar, Slack se enciende y, en algún rincón de tu terminal, un despliegue de Kubernetes se está destruyendo a sí mismo. Ya conoces la rutina: abrir Git, enviar un pull request, esperar la aprobación, dejar que ArgoCD sincronice y tal vez encender una vela para tener suerte. Pero el fuego ya se está extendiendo, y esta noche no vas a esperar. Haces un kubectl edit directamente en producción, ¿y sabes qué? Está bien.

En el mundo de GitOps, donde la infraestructura es código y los despliegues deben ser rituales impecables y repetibles, existe un acuerdo tácito: a veces hay que romper el cristal de emergencia. Lo rompes porque el sistema no contempló la realidad cotidiana, esa en la que la gente duerme, en la que el único ingeniero con permisos de acceso a ArgoCD no contesta al teléfono y en la que la política de sincronización que configuraste con tanto esmero revierte tus cambios más rápido de lo que tardas en escribirlos.

El sueño de DevOps frente a la realidad de las 2AM

GitOps representa el estándar dorado en la gestión moderna de Kubernetes. Promete coherencia, auditabilidad e infraestructura con autorreparación. Herramientas como ArgoCD y Flux vigilan los repositorios de Git de forma continua para asegurar que lo que corre en el clúster coincida con el control de versiones. Suena impecable, hasta que la persona autorizada para aprobar tu parche urgente está en su fase más profunda de sueño y tu clúster está ardiendo.

Un usuario lo definió a la perfección: edita en producción mientras esperas que aprueben el PR, porque a veces simplemente tienes que apagar el fuego. Ese es el conflicto de fondo: una canalización de CI/CD idílica frente a la batalla solitaria de las operaciones reales. Cuando tu nombre es el que figura en las guardias del buscapersonas, los ideales no solucionan los incidentes.

El bucle de sincronización bajo presión

ArgoCD, con todas sus virtudes, puede actuar como un fantasma implacable cuando intentas aplicar una corrección de emergencia. Detecta tus modificaciones manuales y las deshace con entusiasmo en cuestión de milisegundos, sencillamente porque hace exactamente aquello para lo que fue configurado. Con el autoheal activado en ArgoCD, comentaba un ingeniero, puedes editar manualmente las veces que quieras; siempre volverá a su estado previo.

Es como jugar a golpear topos con tus propios archivos YAML.

Quienes conocen bien el sistema aplican el truco habitual: pausar la sincronización automática de forma temporal. Aun así, eso asume que dispones de los permisos requeridos, algo que en más de una historia de terror queda restringido a un único ingeniero sénior que no está disponible. Alguien contaba cómo vio a ArgoCD revertir sus cambios de kubectl durante ocho horas seguidas porque nadie más tenía privilegios para detener la sincronización. Eso es un fallo organizativo del sistema, y uno especialmente frustrante.

El problema de los procesos rígidos

La tensión reside entre los procesos rígidos y los seres humanos a los que supuestamente deben servir. Nadie defiende programar al estilo cowboy en producción a diario. Pero cuando tus alternativas son esperar a que se apruebe el pull request o perder información de tus clientes, de repente usar kubectl edit deja de parecer tan condenable.

Un SRE sénior aportaba una perspectiva sensata: el acceso a producción debería exigir una cuenta de breakglass. Nada farragoso, simplemente un mecanismo monitorizado, registrado y que obligue a realizar un postmortem después. Ese es el equilibrio adecuado: facilitar la acción cuando hay urgencia, pero asegurar que nada quede en el olvido. No deberías depender de rezos ni de desahogos en Slack para hacer tu trabajo.

El verdadero problema es diseñar arquitecturas que dejen a un ingeniero júnior gestionando alertas a solas a las 2AM sin herramientas ni respaldo.

Cultura cowboy frente a límites de seguridad eficaces

Muchas organizaciones todavía intentan escapar de las viejas costumbres improvisadas de DevOps. Ya conoces el cuadro: sin aprobaciones, sin auditorías, pura intuición y acceso root para todo el mundo. El error surge cuando dan el bandazo contrario, llenando cada paso de burocracia y aprobaciones obligatorias que se vuelven inviables bajo presión.

Los equipos más maduros se preparan para ambos escenarios. Asumen que los incidentes van a ocurrir y facilitan a sus ingenieros vías seguras, documentadas y reversibles para actuar con rapidez. Eso puede implicar desactivar la sincronización automática, apuntar ArgoCD a una rama de parche temporal o aplicar un cambio manual con instrucciones claras de reversión. Lo decisivo es que sea una decisión consciente y controlada.

GitOps con sentido humano

Una de las opiniones más lúcidas del sector lo resumía así: GitOps no es solo enviar código de Git al clúster, también abarca la reconciliación, la automatización y, cuando la situación lo exige, el control humano. Lo que a menudo olvidan los puristas de GitOps es que la mejor infraestructura se diseña para las personas que la operan.

Eso significa dejar espacio para la contingencia controlada y entender que la autorreparación puede volverse contraproducente si carece de contexto. También implica considerar cada edición directa en producción como una señal de que tu sistema necesita una vía de escape mejor diseñada.

Una carta de apoyo con registro de auditoría

Vaya desde aquí este reconocimiento para quienes pasan la noche en vela: los júniors que recibieron el aviso porque nadie más podía atenderlo, los séniors que les dieron las herramientas y la confianza para actuar, y quienes pausaron la sincronización, aplicaron la solución y luego redactaron el postmortem que enseñó al resto del equipo cómo actuar la próxima vez. Ustedes son los auténticos planes de contingencia en acción.

Ten a mano tu comando kubectl, pero no olvides documentarlo en Git en cuanto el fuego esté apagado.