Hace un par de años, me llamaron para evaluar las prácticas de prestación de una empresa de servicios financieros de tamaño medio. Tenían todos los artefactos de una organización moderna de ingeniería: una tubería CI/CD, infraestructura como plantillas de código, un equipo SRE dedicado, canales de Slack llamados así por microservicios. El CTO me dijo orgulloso que habían «completado su transformación DevOps.»

Luego pasé una semana con los equipos.

La cadena CI/CD existía, pero la mayoría de los despliegues aún requerían una cadena de aprobación manual que tardaba tres días. Las plantillas de IaC fueron escritas por una sola persona y no las entendió nadie más. El equipo SRE se había convertido en el nuevo silo de operaciones: los desarrolladores les lanzaban código por encima del muro en lugar de a un equipo de operaciones tradicional. Los canales de Slack estaban activos, pero las conversaciones eran las mismas que habría escuchado en un sistema de tickets hace diez años: «¿Puedes reiniciar el servicio?» «¿Quién cambió esta configuración?» «¿Alguien está viendo esta alerta?»

Habían adoptado las herramientas. Habían renombrado los equipos. No habían cambiado la cultura.

Esto es lo que llamo teatro DevOps: la interpretación de prácticas modernas de ingeniería sin la transformación subyacente que las hace funcionar. Y tras trabajar en cientos de proyectos en la nube, puedo decirte que es mucho más común de lo que sugieren las historias de éxito.

El problema del cambio de nombre

El síntoma más visible del teatro DevOps es el cambio de nombre organizativo. Operaciones se convierte en SRE. QA se convierte en «Ingeniería de Calidad». Los gestores de proyectos se convierten en «Líderes de Entrega». El organigrama parece moderno. El comportamiento no ha cambiado.

Trabajé con una empresa que había reestructurado toda su organización de ingeniería en torno a los «equipos de producto». Cada equipo tenía un product owner, desarrolladores y un SRE integrado. Sobre el papel, era de manual. En la práctica, los SRE seguían reportando a un gestor central de infraestructuras que controlaba sus prioridades. Los equipos de producto no tenían una verdadera responsabilidad sobre su postura operativa. Cuando algo se rompió a las 2 de la madrugada, el SRE escaló al responsable de infraestructura, que lo hizo al vicepresidente de ingeniería, que despertó al desarrollador de guardia. Cuatro entregas por un solo incidente.

Tenían la estructura de DevOps sin la responsabilidad de DevOps.

El problema del cambio de nombre es seductor porque parece un avance. Puedes presentarlo al consejo. Puedes ponerlo en una presentación de diapositivas. Incluso puedes contratar consultores para que lo validen. Pero cambiar el nombre de un equipo no cambia la forma en que ese equipo toma decisiones, comparte la responsabilidad o responde al fracaso.

«Tú lo construyes, tú lo diriges» como lema

El famoso principio de Amazon, «lo construyes, lo ejecutas», se ha convertido en una de las ideas más citadas y menos practicadas en ingeniería de software.

El principio es sencillo: el equipo que escribe el código es responsable de operarlo en producción. No hay entregas. No hay un equipo de operaciones separado que herede las consecuencias de las decisiones de diseño de otra persona. El bucle de retroalimentación entre construir y ejecutar es directo e inmediato.

En la práctica, la mayoría de las organizaciones implementan una versión diluida. Los desarrolladores escriben el código y lo despliegan a través de una canalización, pero la responsabilidad operativa sigue estando en otro lugar. La monitorización la establece un equipo de plataforma. Las alertas se envían a una rotación de guardia en la que los desarrolladores participan a regañadientes. La respuesta a incidentes sigue un proceso diseñado por alguien que nunca ha leído la base de código.

El resultado es un bucle de retroalimentación que técnicamente está presente pero prácticamente está roto. Los desarrolladores no sienten el dolor de sus decisiones operativas porque alguien más lo absorba. El equipo SRE o de plataforma se convierte en un amortiguador que aísla a los desarrolladores de las consecuencias de sus decisiones, lo que significa que esas decisiones nunca mejoran.

Un patrón que sigo encontrando: organizaciones que adoptaron como política de «tú lo construyes, tú lo ejecutas» pero nunca invirtieron en las capacidades que lo hacen posible. Se les dijo a los desarrolladores que eran propietarios de la producción, pero nunca se les formó en observabilidad, gestión de incidentes o diseño operativo. Se les dio responsabilidad sin capacidad, lo cual es una receta para el agotamiento, no para la propiedad.

La Ilusión de la Automatización

Otra característica distintiva del teatro DevOps es la automatización que automatiza las cosas equivocadas.

He visto a organizaciones invertir meses en construir pipelines de despliegue sofisticados mientras su proceso de respuesta a incidentes sigue siendo una hoja de cálculo compartida. Otros automatizan la provisión de infraestructura, mientras que su proceso de gestión de cambios requiere tres aprobaciones por correo electrónico y una invitación en el calendario. Y luego están las empresas con suites de pruebas totalmente automatizadas en las que nadie confía, así que cada versión sigue pasando por un ciclo de regresión manual «por si acaso».

La automatización sin confianza es simplemente una burocracia más rápida.

El problema más profundo es que muchas organizaciones automatizan sus procesos existentes en lugar de replantearlos. Llevan a cabo un proceso de despliegue manual con siete pasos y automatizan los siete, incluidos los tres que no deberían existir. Construyen una tubería que hace cumplir las mismas puertas de aprobación que se diseñaron para un mundo donde los despliegues se realizaban trimestralmente, no diariamente.

La verdadera automatización DevOps comienza con la pregunta: «¿Debería existir este paso en absoluto?» Si la respuesta es no, automatizarlo es un desperdicio. Si la respuesta es sí, la siguiente pregunta es: «¿Quién debería ser el dueño de esto y qué retroalimentación produce?» La automatización que no genera retroalimentación es simplemente trabajo manual invisible.

Las métricas que mienten

El teatro DevOps se sostiene gracias a métricas que miden la actividad en lugar de los resultados.

La frecuencia de despliegue es el ejemplo más común. Las organizaciones registran la frecuencia con la que se despliegan y celebran cuando el número aumenta. Pero la frecuencia de despliegue sin medir la tasa de fallo de cambios, el tiempo de entrega y el tiempo medio hasta la recuperación no te dice nada sobre si realmente estás entregando valor más rápido.

Trabajé con un equipo que desplegó 47 veces en un solo mes. Estaban orgullosos del número. Si miré más de cerca, 19 de esos despliegues eran rollbacks o hotfixes del despliegue anterior. Su tasa real de parto exitoso se acercaba al 60%, y el tiempo medio hasta la recuperación se medía en días, no en horas. La métrica de frecuencia de despliegue indicaba «equipo de alto rendimiento». La realidad decía «equipo en modo de bomberos constante.»

Las métricas DORA (frecuencia de despliegue, tiempo de entrega para cambios, tasa de fallo de cambios, tiempo medio de recuperación) existen precisamente para evitar este tipo de autoengaño. Pero incluso las métricas DORA pueden convertirse en teatro si se miden sin contexto. Un equipo que despliega frecuentemente en un entorno de staging pero lanza en lotes a producción cada dos semanas no es un equipo de alto rendimiento, independientemente de lo que diga el panel de control.

Las métricas deben generar responsabilidad, no comodidad. Si tus métricas hacen que todos se sientan bien pero nada mejora realmente, estás midiendo el rendimiento, no la práctica.

Por qué la cultura no cambia

Si las herramientas están disponibles y los frameworks bien documentados, ¿por qué persiste el teatro DevOps?

Tres razones, de forma constante.

Primero, el cambio cultural requiere vulnerabilidad. Admitir que tu equipo en realidad no es dueño de la producción, que tu pipeline es una formalidad, que tu equipo SRE es solo operaciones con un nombre nuevo, requiere que los líderes reconozcan que la transformación que patrocinaron no funcionó del todo. Es una conversación difícil, especialmente cuando la junta ya ha sido informada de que ha tenido éxito.

En segundo lugar, la cultura DevOps requiere confianza entre equipos, y la confianza se construye a través de consecuencias compartidas. Cuando desarrolladores y operaciones comparten rotaciones de guardia, revisiones de incidentes, comparten el dolor de un mal despliegue, la confianza se desarrolla de forma natural. Cuando esas experiencias se separan, cuando un equipo construye y otro sufre, la confianza no se forma por muchas plantillas de «postmortem sin culpa» que adoptes.

Tercero, y esto conecta con algo que exploré en las cuatro cosas que la IA no puede reemplazar en las personas que contratas: la cultura DevOps depende de las mismas cualidades humanas que ningún proceso puede fabricar. Trabajo en equipo que va más allá de la colaboración. Adaptabilidad que cuestiona las suposiciones, no solo aprende nuevas herramientas. Empoderamiento que distribuye la propiedad en lugar de acapararla. Las organizaciones que contratan por resultados individuales y recompensan sus heroísmos individuales tendrán dificultades con DevOps independientemente de su inversión en herramientas.

Lo que realmente funciona

Tras trabajar en cientos de proyectos en Clouxter, las organizaciones que realmente practican DevOps, no solo lo realizan, comparten algunas características.

En Clouxter, obtuvimos la designación AWS CloudFormation Service Delivery como uno de nuestros primeros pasos para construir una práctica disciplinada en la nube, y más tarde la AWS DevOps Competency. Eso fue hace unos seis años. Lo que vemos hoy en los entornos de los clientes es fundamentalmente diferente de lo que veíamos entonces, lo que en sí mismo demuestra que DevOps nunca es un destino. Pero los patrones que separan la práctica real del teatro se han mantenido notablemente consistentes.

Cuando realizamos evaluaciones de madurez DevOps con los clientes, la brecha entre la madurez percibida y la madurez real es consistentemente el hallazgo más sorprendente. Los equipos que se consideran «avanzados» suelen puntuar en niveles fundamentales de cultura y proceso, incluso cuando sus puntuaciones tecnológicas son altas. Las herramientas son modernas; El comportamiento no lo es. Esa brecha es donde vive el teatro, y hacerla visible es el primer paso para cerrarla.

Las organizaciones que lo cierran comparten algunas características.

Empiezan con la propiedad, no con las herramientas. Antes de seleccionar una plataforma CI/CD o diseñar una pipeline, responden: «¿Quién es responsable de este servicio en producción y tiene la autoridad y capacidad para actuar?» Si la respuesta no está clara, primero lo solucionan.

Invierten en la alfabetización operativa. Los desarrolladores aprenden observabilidad, respuesta a incidentes y diseño operativo como habilidades clave, no como extras opcionales. Esto no es un programa de formación; Es un criterio de contratación y una expectativa de progresión profesional.

Miden los resultados, no la actividad. La frecuencia de despliegue solo importa en el contexto de la tasa de fallo del cambio y el tiempo de recuperación. El tiempo de entrega solo importa si mide el ciclo completo desde el compromiso hasta el valor del cliente, no solo el tiempo de ejecución de la pipeline.

Tratan los incidentes como aprendizaje, no como culpas. Las autopsias inocentes son comunes en nombre; Son raros en la práctica. Las organizaciones que aprenden del fracaso son aquellas en las que la autopsia produce un cambio concreto, no solo un documento. Si tu archivo postmortem crece pero tus patrones de incidentes no cambian, el proceso también es teatro.

Aceptan que DevOps nunca «termina». Las empresas que declararon su transformación DevOps terminada suelen ser las que representan teatro. Los que lo tratan como una disciplina continua, revisando las prácticas, cuestionando suposiciones, adaptándose a nuevas capacidades, son los que realmente mejoran.

Y todo lo que he descrito aquí se aplica con apuestas aún mayores cuando se añade la seguridad a la ecuación. Las organizaciones que renombraron su proceso como «DevSecOps» sin integrar la seguridad en el flujo de desarrollo, sin dar a los desarrolladores alfabetización en seguridad, sin convertir la seguridad en una responsabilidad compartida en lugar de una puerta al final, están realizando el mismo teatro con consecuencias mucho mayores. El teatro de seguridad en una tubería DevOps no solo te ralentiza; Crea la ilusión de protección mientras deja vulnerabilidades reales sin abordar. Esa dimensión merece su propia conversación, y la exploraré en una futura entrada.

La dimensión de la IA

Esto importa más ahora que hace cinco años. A medida que la IA se convierte en parte del flujo de trabajo de ingeniería, la brecha entre el teatro DevOps y la práctica DevOps genuina se amplía, y no solo por los asistentes de programación.

La IA está transformando cada etapa de la cadena de entrega. El código de infraestructura generado por IA parece sintácticamente correcto, pero a menudo ignora los estándares organizativos, las políticas de seguridad y el contexto operativo que un ingeniero senior lleva en su cabeza. La revisión de código asistida por IA y el escaneo de seguridad en pipelines CI/CD producen resultados que los equipos aceptan sin crítica, creando falsa confianza en una pipeline que ya estaba en teatro. La monitorización y alerta impulsadas por IA genera ruido en lugar de señal cuando el modelo operativo debajo está roto, porque la IA no tiene contexto de cómo es lo «normal» en un entorno que nadie entiende realmente.

Y luego está el efecto acumulador. La IA permite a los equipos crear nuevos servicios, nueva infraestructura e integraciones más rápido que nunca. En una organización que practica DevOps genuino, esa velocidad se absorbe por bucles de retroalimentación muy ajustados, verdadera propiedad y alfabetización operativa. En una organización que realiza teatro, esa velocidad crea nuevos servicios que nadie posee, nueva infraestructura que nadie supervisa y nuevas integraciones que nadie entiende. La brecha de gobernanza no crece de forma lineal; Se acumula.

La cuestión no es si tu organización ha adoptado DevOps. La cuestión es si la adopción cambió la forma en que las personas trabajan, o simplemente cómo se muestra el organigrama.

La pregunta honesta

Si eres un líder tecnológico, aquí tienes una pregunta que merece la pena hacer a tus equipos y ser honestos con la respuesta:

Cuando algo se rompe en producción a las 2 de la madrugada, ¿qué ocurre realmente? No es lo que dice el manual de reglas. No es lo que describe el proceso de respuesta a incidentes. ¿Qué ocurre realmente?

La distancia entre el proceso documentado y el comportamiento real es la distancia entre tu práctica DevOps y tu teatro DevOps.

Cerrar esa distancia no es un problema de herramientas. Es una cuestión de liderazgo.

Ricardo