¿Qué es DevOps? Cultura, prácticas y pipeline de entrega

Toda organización que escribe software tiene dos fuerzas tirando en direcciones opuestas. A desarrollo se le premia por el cambio: nuevas funcionalidades, menor time to market, experimentos. A operaciones se le premia por la estabilidad: disponibilidad, capacidad predecible, ninguna sorpresa un viernes por la noche. Cuando esos dos grupos están en departamentos distintos, con responsables distintos y objetivos distintos, el resultado natural es un traspaso — un paquete de release lanzado por encima del muro con un documento de despliegue adjunto — y un proceso de puesta en producción lento, lleno de reproches, que nadie disfruta. DevOps es el conjunto de ideas y prácticas que surgió para derribar ese muro. Esta guía explica qué significa el término más allá del marketing, qué cambia de verdad en un equipo que lo practica y cómo empezar.

El problema que resuelve DevOps

Imagina el ciclo tradicional. Un equipo de proyecto construye una release durante varios meses. Las pruebas llegan al final. Un comité de aprobación de cambios se reúne para autorizar el despliegue. Operaciones la instala en servidores que configuró a mano hace un año, siguiendo un documento de Word, a las 2 de la madrugada de un sábado. Algo se rompe que nunca se había roto en el entorno de pruebas, porque el entorno de pruebas no es igual que producción. Se llama a los desarrolladores, se culpa a operaciones y la siguiente release se programa para todavía más adelante, para «reducir el riesgo».

El instinto de entregar con menos frecuencia es justo lo contrario de lo que conviene. Una release que contiene seis meses de cambios es enorme, difícil de probar y casi imposible de revertir. Una release que contiene un día de cambios es pequeña, fácil de entender y, si falla, la causa es evidente. Los lotes pequeños son la idea más importante que hay detrás de DevOps: reduce el tamaño de cada cambio y, con él, se reducen el riesgo, el miedo y la ceremonia que rodean cada puesta en producción.

Otras dos presiones hicieron insostenible el modelo antiguo. Los equipos de producto que adoptaron métodos ágiles empezaron a producir software potencialmente entregable cada dos semanas, y luego lo veían esperar meses a que hubiera hueco para una release. Y la llegada de las API de la nube hizo posible crear servidores, redes y balanceadores de carga con un script: la infraestructura se había convertido en software, y el software necesita prácticas de ingeniería de software.

CALMS: los cinco pilares

Una forma muy extendida de resumir el movimiento es el acrónimo CALMS — Culture, Automation, Lean, Measurement, Sharing (cultura, automatización, lean, medición, compartir). Resulta útil precisamente porque solo una de las cinco letras tiene que ver con herramientas.

Cultura. Desarrollo y operaciones comparten la responsabilidad del servicio en producción. «You build it, you run it» es la versión extrema: el equipo que escribe un servicio hace las guardias de ese servicio. La versión moderada es que las preocupaciones operativas — facilidad de despliegue, monitorización, capacidad, parches de seguridad — forman parte de la definición de hecho, en lugar de ser problema de otro más adelante. Los incidentes se investigan con post-mortems sin culpables, que buscan la causa sistémica y no a la persona que tecleó el comando.

Automatización. Todo lo que se hace más de dos veces se convierte en un script: compilar, probar, empaquetar, aprovisionar servidores, desplegar, hacer rollback. La automatización no consiste solo en ahorrar tiempo. Un script es repetible, revisable y testeable, cosa que no es un runbook seguido por una persona cansada, y hace que los entornos sean idénticos en lugar de simplemente parecidos.

Lean. Tomado de la industria manufacturera: trabajar en lotes pequeños, limitar el trabajo en curso, hacer visible el flujo de trabajo y eliminar el desperdicio — esperas de aprobaciones, traspasos entre equipos, retrabajo por defectos detectados tarde. El value stream mapping, en el que dibujas cada paso desde la idea hasta producción y mides cuánto espera el trabajo en cada uno, es el ejercicio clásico y suele revelar que la mayor parte del tiempo de entrega es espera en cola, no trabajo real.

Medición. No se puede mejorar lo que no se mide. Eso significa métricas técnicas (duración del build, frecuencia de despliegue, tasas de error, latencia) y también de negocio (altas, pedidos, ingresos por hora), para que un mal despliegue aparezca como un problema de negocio en cuestión de minutos. Las métricas deben estar a la vista de todos, no encerradas en un dashboard de operaciones.

Compartir. El conocimiento, las herramientas y el código cruzan las fronteras entre equipos. Los desarrolladores pueden leer la configuración de producción y los ingenieros de operaciones pueden abrir pull requests sobre el código de la aplicación. Los informes de post-mortem se publican internamente. Los pipelines reutilizables, las imágenes base y los módulos de Terraform se mantienen como productos compartidos.

Las prácticas fundamentales

Los pilares son principios; esto es lo que un equipo hace en realidad.

Todo en control de versiones

El código de la aplicación, por supuesto, pero también los scripts de build, las definiciones de infraestructura, la configuración de los servidores, las migraciones de base de datos, los dashboards y las reglas de alerta. Lo que no está en Git no se puede revisar, reproducir ni revertir. Consulta la guía de fundamentos de Git para ver la mecánica.

Integración continua

Cada desarrollador hace merge en la rama principal al menos una vez al día, cada merge dispara un build automatizado que compila el código y ejecuta la batería de pruebas, y un build roto se arregla antes que cualquier otra cosa. El objetivo es encontrar los problemas de integración minutos después de crearlos, en lugar de semanas más tarde. La integración continua tiene su propia guía.

Entrega continua

El build produce un artefacto versionado e inmutable — un jar, una imagen de contenedor — que atraviesa los entornos sin cambios. El despliegue es un paso automatizado con scripts que se lanza pulsando un botón (o de forma totalmente automática), y el pipeline demuestra que cada commit es entregable. El despliegue continuo va un paso más allá y pone en producción cada build en verde sin decisión humana. La guía del pipeline de entrega cubre las etapas, las estrategias y las migraciones de base de datos que intervienen.

Infraestructura como código

Servidores, redes, registros DNS, definiciones de clústeres y su configuración se declaran en ficheros, se aplican con herramientas como Terraform u OpenTofu y Ansible, y se revisan como cualquier otro cambio. La vieja costumbre de entrar en un servidor y editar un fichero a mano — que produce máquinas «snowflake» que nadie sabe reconstruir — se sustituye por reconstruir desde el código fuente. La guía de infraestructura como código profundiza en las herramientas.

Contenedores y orquestación

Las imágenes Docker empaquetan la aplicación con su runtime para que desarrollo, CI y producción ejecuten exactamente los mismos binarios. Kubernetes planifica esos contenedores en un clúster, los reinicia cuando fallan y despliega las nuevas versiones de forma gradual. Los contenedores no son obligatorios para hacer DevOps, pero abaratan mucho cumplir la promesa de «el mismo artefacto en todas partes».

Monitorización, logs y feedback

Las métricas (Prometheus, Grafana), los logs centralizados (el stack de Elastic, Loki) y el tracing distribuido cierran el ciclo: el equipo que desplegó un cambio ve su efecto en las tasas de error y en la latencia en cuestión de minutos. Las alertas avisan a las personas que pueden resolver el problema, y los dashboards se diseñan en torno a los síntomas que percibe el usuario, no a gráficas de CPU.

Medir la entrega: las métricas DORA

El programa DevOps Research and Assessment (DORA) dedicó años a encuestar a miles de organizaciones y redujo el rendimiento de entrega a cuatro números.

Las dos primeras miden el throughput, las dos últimas la estabilidad. La conclusión más importante de la investigación es que se mueven juntas: los equipos que despliegan más a menudo también fallan menos y se recuperan antes, porque los cambios pequeños son más seguros y los pipelines automatizados permiten entregar una corrección tan rápido como una funcionalidad. Elegir entre «rápido» y «fiable» es un falso dilema una vez que las prácticas de ingeniería están implantadas.

Usa las métricas como diagnóstico, no como un objetivo que maquillar. Un equipo que despliega diez veces al día con una tasa de fallos del 40 % tiene un problema de pruebas; un equipo con un tiempo de entrega de una hora y releases trimestrales tiene un problema en el proceso de aprobación.

Organizar los equipos

Cómo dibujas el organigrama importa tanto como qué herramientas compras. Hay varias configuraciones que se repiten.

Silos de Dev y Ops, más un «equipo DevOps» en medio. El antipatrón más común. Un nuevo equipo es dueño de los pipelines y del clúster de Kubernetes, los desarrolladores abren tickets para que les desplieguen sus cambios y ahora hay tres silos en lugar de dos.

Equipos de producto totalmente integrados. Cada equipo multidisciplinar es dueño de un servicio de principio a fin: código, pipeline, infraestructura, guardias. Es el modelo más puro y funciona bien en organizaciones con ingenieros sólidos y un número limitado de servicios, pero duplica el trabajo de plataforma entre equipos.

Equipo de plataforma más equipos alineados con el flujo de valor. Los equipos de producto son dueños de sus servicios; un equipo interno de plataforma ofrece el camino pavimentado (paved road) — un servicio de CI/CD, imágenes base, un clúster, observabilidad, almacenamiento de secretos — como un producto con documentación y una API. Los equipos de producto consumen la plataforma en autoservicio en lugar de abrir tickets. Para la mayoría de las organizaciones de cierto tamaño, esta es la configuración que escala.

Ops integrado temporalmente. Un ingeniero de operaciones se une a un equipo de producto durante unos meses para construir la automatización del despliegue y formar al equipo, y después sigue su camino. Es útil como transición y perjudicial si se vuelve permanente, porque el conocimiento se va con el ingeniero.

Sea cual sea la estructura, la prueba es sencilla: ¿puede un desarrollador llevar un cambio a producción sin esperar a otro equipo? Si la respuesta es una cola de tickets, la transformación todavía no ha ocurrido.

Errores comunes

• Primero las herramientas. Comprar Jenkins, Docker y Kubernetes y esperar que la cultura venga detrás. Las herramientas amplifican el proceso que ya existe; automatizar un proceso roto solo hace que falle más rápido.
• Cambiar el nombre al equipo de operaciones. Sustituir «Ops» por «DevOps» en el organigrama sin cambiar responsabilidades, incentivos ni el proceso de despliegue.
• Medir actividad en lugar de resultados. Contar pipelines construidos o contenedores en ejecución en lugar del tiempo de entrega y la tasa de fallos.
• Saltarse los cimientos aburridos. Probar canary releases antes de que la batería de pruebas sea fiable, o Kubernetes antes de que la aplicación pueda configurarse mediante variables de entorno. Los principios twelve-factor son una buena checklist para saber si una aplicación está preparada.
• Dejar la seguridad para el final. Las revisiones de seguridad como barrera final recrean el problema del traspaso. El análisis de dependencias, el escaneo de imágenes y el análisis estático deben estar en el pipeline desde la primera semana, y eso es exactamente a lo que se refiere el término DevSecOps.
• La transformación big bang. Anunciar que todos los equipos serán «DevOps para el tercer trimestre». Las transformaciones que funcionan empiezan con un equipo, un servicio y un pipeline, y copian lo que ha salido bien.

Por dónde empezar

1. Mapear el camino actual hasta producción

   Anota cada paso desde un commit fusionado hasta un despliegue en ejecución, quién lo hace y cuánto tiempo espera el trabajo en cada etapa. El tiempo de espera, no el de trabajo, suele ser la sorpresa.

2. Poner todo en control de versiones y automatizar el build

   Un único comando que genere el artefacto desplegable a partir de un checkout limpio, ejecutado en un servidor de CI en cada push. Sin esto no es posible nada más.

3. Conseguir una batería de pruebas fiable

   Un pipeline que está en rojo la mitad del tiempo por motivos que nadie investiga acaba ignorándose. Elimina o arregla los tests inestables (flaky), mantén el build por debajo de diez minutos y trata una rama principal en rojo como la máxima prioridad del equipo.

4. Automatizar el despliegue con un script

   Sustituye el runbook por un script o una etapa del pipeline que despliegue en un entorno de pruebas con la misma forma que producción. Después reutiliza ese mismo script para producción.

5. Añadir una monitorización que el equipo mire de verdad

   Un dashboard con la tasa de peticiones, la tasa de errores y la latencia por servicio, con una alerta sobre la tasa de errores, proporciona el ciclo de feedback que hace seguras las releases pequeñas y frecuentes.

6. Aumentar la frecuencia de release de forma deliberada

   Pasa de mensual a quincenal y luego a semanal. Cada paso deja al descubierto el siguiente cuello de botella — aprobaciones manuales, migraciones de base de datos, deriva entre entornos —, que se convierte en lo siguiente que automatizar.

Ideas clave

• DevOps aborda el conflicto estructural entre los equipos a los que se premia por el cambio y aquellos a los que se premia por la estabilidad, dándoles la responsabilidad compartida del servicio en funcionamiento.
• Los lotes pequeños son la idea central: los cambios más pequeños son más fáciles de probar, desplegar, entender y revertir, así que entregar más a menudo reduce el riesgo en lugar de aumentarlo.
• CALMS — cultura, automatización, lean, medición, compartir — describe el movimiento; solo la automatización tiene que ver con herramientas.
• Las prácticas son concretas: todo en control de versiones, integración continua, un pipeline de entrega que produce artefactos inmutables, infraestructura como código y una monitorización que devuelve información al equipo.
• Las cuatro métricas DORA miden a la vez el throughput y la estabilidad, y los mejores equipos mejoran ambos al mismo tiempo.
• Organiza los equipos de forma que un desarrollador pueda llegar a producción sin una cola de tickets; un «equipo DevOps» entre Dev y Ops suele acabar siendo un tercer silo.
• Empieza con un equipo y con los cimientos aburridos — build repetible, pruebas fiables, despliegue automatizado — y aumenta la frecuencia de release paso a paso.