DevOps a fondo: cultura, prácticas y cómo empezar sin crear otro silo

Hace unos años era normal que un equipo de desarrollo terminara una versión un viernes, la "lanzara" a operaciones y se fuera a casa. Operaciones recibía algo que no había visto, con instrucciones incompletas, para desplegar en un fin de semana y sostener con guardias. Si fallaba, cada lado tenía su relato: "funcionaba en mi máquina" contra "ustedes no probaron en el entorno real". DevOps nació para deshacer ese nudo. Y como suele pasar con las ideas exitosas, hoy significa tantas cosas que conviene empezar por aclararlo.

El problema de fondo: incentivos opuestos

Dos equipos, dos mandatos:

• Desarrollo es evaluado por entregar cambios: funcionalidades, correcciones, mejoras.
• Operaciones es evaluado por estabilidad: disponibilidad, rendimiento, menos incidentes.

Pero todo cambio es un riesgo para la estabilidad. Con esos incentivos, desarrollo empuja y operaciones frena. La respuesta natural a la inestabilidad es cambiar menos y con más ceremonias, lo que agranda cada cambio, y los cambios grandes fallan más. Un círculo vicioso: despliegues escasos, enormes, temidos y propensos a fallar. DevOps rompe el círculo con una apuesta contraintuitiva: cambiar más seguido, en piezas pequeñas, con automatización y retroalimentación rápida, de modo que cada cambio sea menos riesgoso y más fácil de revertir.

Qué es (y qué no es)

El término se popularizó alrededor de 2009. Una definición práctica: un conjunto de cultura, prácticas y herramientas que alinea a quienes construyen y a quienes operan software con un objetivo compartido: entregar valor de forma rápida, frecuente y fiable. Lo que no es:

• No es un equipo "DevOps" que se interpone entre desarrollo y operaciones. Suele convertirse en un tercer silo con su propia cola de tickets.
• No es un título que se pone a un administrador de sistemas.
• No es "comprar herramientas". Puedes tener todo el catálogo de herramientas y seguir con el muro entre equipos.
• No es que los desarrolladores hagan todo. Es compartir responsabilidad y conocimiento, no cargar a una persona con tres trabajos.
• No es solo automatización, aunque se apoya mucho en ella.

La frase que mejor lo resume viene de Werner Vogels: "you build it, you run it" (si lo construyes, lo operas). Quien crea un servicio comparte la responsabilidad de que funcione en producción, y por eso lo diseña para que se pueda operar.

CALMS: un mapa de lo que cubre

| Letra | Significado | Qué incluye | |---|---|---| | C | Cultura | Colaboración, confianza, responsabilidad compartida, seguridad psicológica | | A | Automatización | Pipelines, infraestructura como código, pruebas, despliegues, aprovisionamiento | | L | Lean | Flujo en lotes pequeños, limitar trabajo en curso, eliminar desperdicio, ciclos cortos | | M | Medición | Métricas de entrega y de operación, observabilidad, datos para decidir | | S | Compartir | Conocimiento abierto, documentación, postmortems, comunidades de práctica |

La C y la S son las que más se omiten y las que más pesan. Puedes copiar un pipeline en una tarde; no puedes copiar la confianza.

Las tres vías, en una línea cada una

(Las desarrollo en otro artículo de esta serie.)

1. Flujo: acelera el camino del valor desde la idea hasta el usuario.
2. Retroalimentación: crea señales rápidas y constantes desde producción hacia el desarrollo.
3. Aprendizaje continuo: convierte errores y experimentos en mejora sistemática.

Prácticas técnicas, con su porqué

1. Control de versiones para todo

Código, configuración, infraestructura, documentación y pipelines viven en repositorios, con revisión y trazabilidad. Si un cambio no está en control de versiones, no existe de manera confiable.

2. Integración y entrega continuas

Integración frecuente en la rama principal, un pipeline que compila, prueba y empaqueta en cada cambio, y despliegues automatizados con estrategias graduales y reversión simple. (Más en el artículo de CI/CD.)

3. Infraestructura como código (IaC)

La infraestructura se define en código (Terraform, CloudFormation, CDK, Pulumi), se revisa, se versiona y se aplica por pipeline. Beneficios: entornos reproducibles, cambios auditables, recuperación ante desastres como un apply, y fin de los servidores "únicos" configurados a mano. Complementos: detección de deriva y políticas como código (verificaciones automáticas de seguridad y cumplimiento antes de aplicar).

4. Pruebas automatizadas

La red de seguridad que permite cambiar con confianza: muchas pruebas unitarias, integración donde hay riesgo, pocas de extremo a extremo y verificaciones de humo tras cada despliegue.

5. Observabilidad y monitoreo

No basta con saber si algo falla: necesitas poder preguntar por qué. Métricas, logs estructurados y trazas, alarmas basadas en síntomas del usuario y paneles que cuenten una historia.

6. Gestión de la configuración y de los secretos

Configuración separada del código, secretos en gestores dedicados, credenciales temporales, rotación automática.

7. Seguridad integrada (DevSecOps)

Mover la seguridad a la izquierda: análisis de dependencias, secretos y código en el pipeline; escaneo de imágenes; revisión de infraestructura; modelos de amenaza en el diseño. La seguridad deja de ser una puerta al final y pasa a ser una propiedad del proceso.

8. Despliegues seguros

Despliegues graduales (canary, azul/verde), feature flags, migraciones de base de datos compatibles hacia atrás, reversión rápida y verificación automática.

Operar bien: SLO, incidentes y postmortems

DevOps no termina al desplegar: incluye operar con criterio.

Objetivos de nivel de servicio (SLO) y presupuesto de errores

Concepto de la ingeniería de fiabilidad de sitios (SRE):

• SLI: una medida del servicio que le importa al usuario (porcentaje de solicitudes exitosas, latencia p95).
• SLO: el objetivo (por ejemplo, 99.9 % de solicitudes exitosas en 30 días).
• Presupuesto de errores: lo que puedes "fallar" sin incumplir el objetivo (el 0.1 % restante).

Es un mecanismo elegante para resolver el conflicto original entre velocidad y estabilidad: mientras queda presupuesto, se entregan cambios con libertad; si se agota, se prioriza fiabilidad. Convierte una discusión de opiniones en una conversación con datos y reglas acordadas de antemano.

Gestión de incidentes

Elementos de un proceso sano:

1. Detección por alarmas (no por usuarios), con severidades definidas.
2. Una persona a cargo de la coordinación (comandante del incidente) y roles claros (comunicación, investigación).
3. Guardias (on-call) sostenibles: rotaciones justas, compensadas, con guías de operación (runbooks) y escalamiento claro. Una guardia que despierta a diario es un problema de sistema, no de personas.
4. Mitigar primero, investigar después: restablecer el servicio (revertir, apagar una flag, escalar) antes de buscar la causa raíz.
5. Comunicación regular a los afectados.

Postmortems sin culpables

Tras un incidente significativo, se analiza lo ocurrido con un documento compartido. La regla: sin culpables (blameless). No porque las personas no importen, sino porque si se castiga al que se equivocó, la gente esconde información, y la próxima vez nadie contará lo que realmente pasó. La pregunta correcta no es "¿quién falló?" sino "¿qué del sistema hizo fácil este error y difícil detectarlo?". Estructura útil:

| Sección | Contenido | |---|---| | Resumen e impacto | Qué pasó, a quién afectó, durante cuánto tiempo | | Cronología | Hechos con hora (detección, decisiones, mitigación) | | Causas | Factores que contribuyeron (técnicos y de proceso), no una única "causa raíz" | | Qué salió bien | Lo que ayudó, para repetirlo | | Qué salió mal / suerte | Lo que costó, y lo que pudo ser peor | | Acciones | Con responsable y fecha; priorizadas y seguidas |

El valor está en las acciones que se cumplen. Un postmortem sin seguimiento es teatro.

Ingeniería de plataforma: cómo escalar DevOps

A medida que la organización crece, pedir a cada equipo que domine nube, redes, seguridad, observabilidad y pipelines genera una carga cognitiva enorme y soluciones duplicadas. La respuesta de muchas organizaciones es la ingeniería de plataforma: un equipo que construye una plataforma interna como producto —caminos pavimentados (golden paths), plantillas, pipelines, entornos bajo demanda— para que los equipos de producto entreguen sin reinventar lo común. Para que no se convierta en un nuevo silo:

• Trátala como producto: con usuarios (los equipos), retroalimentación y métricas de adopción.
• Autoservicio: si hay que abrir un ticket, la plataforma falló.
• Opcional pero atractiva: si es obligatoria y mala, la rodean.
• Los equipos siguen siendo dueños de sus servicios en producción.

Esto conecta con las ideas de Team Topologies: equipos alineados al flujo, equipos de plataforma que reducen carga y una interacción clara entre ellos.

Cómo se mide: DORA

La investigación de DORA (DevOps Research and Assessment, hoy parte de Google Cloud) identificó indicadores que predicen el desempeño de entrega de software y de la organización:

| Métrica | Mide | Tipo | |---|---|---| | Frecuencia de despliegue | Cada cuánto llegas a producción | Velocidad | | Tiempo de entrega de cambios | Del commit a producción | Velocidad | | Tasa de fallo de cambios | % de despliegues que causan degradación | Estabilidad | | Tiempo de recuperación | Cuánto tardas en restablecer el servicio | Estabilidad |

Los informes recientes han ido refinando el marco (por ejemplo, incorporando una medida de retrabajo), así que consulta el informe más reciente en lugar de fiarte de umbrales viejos. Lo permanente es el hallazgo central: velocidad y estabilidad no son opuestas; los mejores equipos logran ambas. Y la advertencia de siempre: usa las métricas para mejorar el sistema, no para comparar o presionar a personas; si se convierten en objetivo, se manipulan.

Gestión del cambio sin burocracia paralizante

Muchas organizaciones tienen un comité de aprobación de cambios (CAB) que revisa cada despliegue. La investigación de DORA encontró que la aprobación externa pesada no mejora la estabilidad y sí empeora la velocidad. Lo que funciona mejor:

• Revisión por pares (en el pull request) y pruebas automáticas como controles principales.
• Controles automatizados (políticas como código, escaneos, aprobaciones del pipeline).
• Reservar la revisión formal para cambios realmente de alto riesgo.
• Dejar trazabilidad automática (quién, qué, cuándo, por qué) para auditoría.

Para entornos regulados, el reto es traducir los requisitos de control en automatismos auditables, no eliminarlos.

Adopción: un plan de 90 días

No necesitas reorganizar la empresa. Un camino razonable para un equipo:

Días 1–30: ver y medir

• Mapea el flujo de un cambio, de la idea a producción: pasos, esperas y manuales.
• Mide frecuencia de despliegue, tiempo de entrega, fallos y recuperación (aunque sea a mano).
• Pon todo en control de versiones (incluida la configuración).
• Elige un dolor concreto (despliegue manual, pruebas lentas, incidentes repetidos).

Días 31–60: automatizar lo esencial

• Pipeline que compila y prueba en cada cambio; rama principal siempre verde.
• Despliegue automatizado a un entorno de pruebas.
• Infraestructura de ese servicio en código.
• Alarmas de síntomas de usuario y logs estructurados.

Días 61–90: cerrar el ciclo

• Despliegue a producción automatizado, gradual y con reversión.
• Postmortems sin culpables con acciones seguidas.
• Primeras guías de operación y guardia compartida entre quien construye y quien opera.
• Revisión de métricas y siguiente cuello de botella.

Elige un servicio piloto, aprende y expande. Cambiar todo a la vez casi siempre termina en nada.

Cómo lo vivo desde DevSecOps

Hoy soy desarrollador full stack y, a la vez, responsable de DevSecOps. Esa mezcla me ha dado una perspectiva que no tendría de otra forma: cuando construyes y también te toca desplegar y proteger lo que construyes, dejas de ver al pipeline y a la seguridad como obstáculos y los empiezas a ver como parte del producto. He trabajado en sectores muy distintos (comercio, jurídico, financiero, inmobiliario y construcción), y lo que más me ha sorprendido es lo mucho que se repite el patrón: los problemas de entrega casi nunca son de herramientas, son de claridad, trazabilidad y confianza entre equipos. Lo que más impacto me ha dado ha sido quitar fricción: por ejemplo, pasar a runners de CI/CD efímeros y sin servidores, que bajaron el costo y me dieron libertad para desplegar sin depender de infraestructura que mantener.

Antipatrones frecuentes

• Renombrar equipos ("equipo DevOps") sin cambiar responsabilidades ni incentivos.
• Automatizar un proceso roto, que solo falla más rápido.
• Herramientas primero, cultura después (o nunca).
• Operaciones sin voz en el diseño, y desarrollo sin responsabilidad en producción.
• Culpar a personas tras los incidentes.
• Métricas como arma de evaluación individual.
• Guardias insostenibles que queman a las mismas personas.
• Pipelines opacos de los que solo un "experto" sabe.
• Seguridad como puerta final.
• Plataforma obligatoria y mala, que genera atajos.
• Intentar el cambio total de golpe.

Para finalizar

DevOps es, en el fondo, una respuesta a un problema de incentivos y de flujo: acerca a quien construye y a quien opera, reduce el tamaño de los cambios, automatiza lo repetible, mide lo que importa y convierte cada error en aprendizaje. Las herramientas cambian cada pocos años; la lógica de fondo permanece. Si hoy quieres empezar con una sola cosa, haz visible el camino de un cambio hasta producción y elige el obstáculo más grande. Quitarlo suele enseñar más que cualquier marco teórico.