DevOps
Cultura y conjunto de prácticas que unifican desarrollo (Dev) y operaciones (Ops) para entregar software con mayor velocidad, calidad y confiabilidad. No es un rol — es una forma de trabajar.
DevOps es un movimiento cultural y técnico que elimina los silos entre desarrollo y operaciones. Nació de la frustración con el modelo tradicional donde Dev «lanza código por encima del muro» y Ops «lo mantiene vivo» — sin responsabilidad compartida.
¿Qué problema resuelve?
En el modelo tradicional:
- Dev quiere cambios rápidos → Ops quiere estabilidad → conflicto permanente
- Deploys manuales cada semanas/meses → acumulación de riesgo
- «Funciona en mi máquina» → problemas en producción
- Blame culture → nadie quiere hacer deploy los viernes
DevOps alinea incentivos: el equipo que construye el software es responsable de operarlo.
Los tres caminos
Principios fundamentales del libro The Phoenix Project:
1. Flow (sistemas de izquierda a derecha)
Optimizar el flujo de trabajo desde desarrollo hasta producción:
- Hacer el trabajo visible (tableros Kanban)
- Limitar work in progress (WIP)
- Reducir batch sizes
- Eliminar handoffs y colas
- Automatizar todo lo repetitivo
2. Feedback (de derecha a izquierda)
Crear loops de retroalimentación rápidos:
- Monitoring y alertas en producción
- Tests automatizados en CI
- Code review en PRs
- Post-mortems sin culpa
- Telemetría de usuario
3. Continual learning
Cultura de experimentación y mejora:
- Blameless post-mortems
- Chaos engineering
- Game days (simulacros de incidentes)
- 20% time para mejoras técnicas
- Compartir conocimiento (tech talks, documentación)
CALMS framework
Modelo para evaluar la adopción de DevOps:
| Pilar | Significado | Ejemplo |
|---|---|---|
| Culture | Colaboración sobre silos | Equipos cross-funcionales |
| Automation | Eliminar trabajo manual | CI/CD, IaC, auto-scaling |
| Lean | Eliminar desperdicio | Limitar WIP, reducir batch size |
| Measurement | Medir todo | DORA metrics, SLOs, error budgets |
| Sharing | Compartir conocimiento | Post-mortems, runbooks, tech talks |
Prácticas esenciales
Infrastructure as Code (IaC)
Definir infraestructura en archivos versionados:
# Terraform
resource "aws_lambda_function" "api" {
function_name = "api-handler"
runtime = "nodejs20.x"
handler = "index.handler"
filename = "lambda.zip"
}Beneficios: reproducibilidad, auditoría, rollback, review en PRs.
Monitoring y observabilidad
Los tres pilares:
- Logs — eventos discretos (qué pasó)
- Metrics — valores numéricos en el tiempo (cuánto)
- Traces — flujo de una request a través de servicios (dónde)
SLOs y error budgets
- SLI (Service Level Indicator) — métrica medible (latencia p99, availability)
- SLO (Service Level Objective) — objetivo interno (99.9% availability)
- SLA (Service Level Agreement) — compromiso contractual con consecuencias
- Error budget — margen permitido de fallo (0.1% = 43 min/mes de downtime)
Si el error budget se agota → congelar features, priorizar estabilidad.
Blameless post-mortems
Después de cada incidente:
- Timeline — qué pasó, cuándo, quién hizo qué
- Root cause — análisis de los 5 porqués
- Impact — usuarios afectados, duración, datos perdidos
- Action items — mejoras concretas con owners y deadlines
- Lessons learned — qué funcionó bien, qué no
Regla cardinal: culpar al sistema, no a las personas.
Chaos engineering
Inyectar fallos deliberadamente para descubrir debilidades:
- Apagar instancias aleatorias (Chaos Monkey)
- Inyectar latencia en la red
- Llenar discos
- Simular fallos de dependencias
DevOps vs SRE
| Aspecto | DevOps | SRE |
|---|---|---|
| Origen | Comunidad (2009) | Google (2003) |
| Enfoque | Cultura + prácticas | Ingeniería de confiabilidad |
| Definición | Movimiento | Rol/disciplina |
| Relación | Filosofía | Implementación de DevOps con ingeniería |
Como dijo Ben Treynor (creador de SRE en Google): «SRE es lo que pasa cuando le pides a un ingeniero de software que diseñe un equipo de operaciones».
Evolución: Platform Engineering
La evolución natural de DevOps en organizaciones grandes:
- DevOps — «you build it, you run it» (cada equipo opera su software)
- Platform Engineering — un equipo construye la plataforma interna que otros equipos consumen
La plataforma abstrae la complejidad: el desarrollador hace git push y la plataforma se encarga de build, test, deploy, monitoring.
Anti-patrones
- DevOps team — crear un equipo llamado «DevOps» que se convierte en el nuevo silo
- Automation sin cultura — herramientas sin cambio cultural no resuelven nada
- Heroísmo — depender de una persona que «sabe todo» en lugar de documentar
- Métricas vanidosas — medir deploys/día sin medir calidad o impacto
- Tool obsession — cambiar de herramienta cada 6 meses sin resolver problemas de fondo
¿Por qué importa?
DevOps no es un rol ni una herramienta — es un cambio cultural que elimina la barrera entre quienes escriben el código y quienes lo operan. Las organizaciones que lo adoptan efectivamente entregan software más rápido, con menos fallos y con recuperación más ágil. Las que lo tratan como un título de puesto pierden el punto.
Referencias
- The Phoenix Project — Gene Kim, Kevin Behr & George Spafford, 2013. La novela que popularizó DevOps.
- The DevOps Handbook — Gene Kim et al., 2021. Guía práctica de implementación (segunda edición).
- Accelerate — Nicole Forsgren, Jez Humble & Gene Kim, 2018. Investigación científica sobre métricas DORA.
- Google SRE Books — Google, 2016-2024. Tres libros gratuitos sobre Site Reliability Engineering.
- State of DevOps Report — DORA/Google Cloud, 2024. Investigación anual sobre prácticas y rendimiento.
- The Twelve-Factor App — Adam Wiggins, 2011. Metodología para construir aplicaciones cloud-native.