16 de octubre de 2026 · 4 min
Las tres vías de DevOps: flujo, retroalimentación y aprendizaje continuo
DevOps · Cultura · Principios
Cuando se habla de DevOps, la conversación suele irse a herramientas: Docker, Kubernetes, Terraform, Jenkins. Pero hay un conjunto de principios debajo de todas ellas que explica por qué funcionan. Se conocen como las tres vías de DevOps, y se popularizaron con la novela The Phoenix Project y The DevOps Handbook. Aquí las explico en mis palabras y con ejemplos.
Primera vía: el flujo
Idea: acelerar el camino que recorre el trabajo desde que se pide (desarrollo) hasta que llega al cliente (operaciones). Piensa en el trabajo como un río. El objetivo es que fluya sin presas.
Cómo se logra
- Hacer visible el trabajo. Tableros que muestren qué hay, en qué etapa y dónde se estanca.
- Reducir el tamaño de los lotes. Cambios pequeños se prueban, revisan y despliegan más rápido y con menos riesgo que un cambio gigante.
- Limitar el trabajo en curso. Hacer menos cosas a la vez para terminarlas.
- Reducir los traspasos entre equipos: cada uno es una espera y una pérdida de contexto.
- Eliminar cuellos de botella y desperdicio: esperas, aprobaciones innecesarias, trabajo manual repetitivo, defectos que obligan a rehacer.
- Automatizar compilación, pruebas, despliegue e infraestructura.
Una regla útil
Nunca pases un defecto conocido al siguiente paso. Detenerlo donde nace es más barato que encontrarlo en producción.
Segunda vía: la retroalimentación
Idea: crear canales rápidos y constantes de información de derecha a izquierda, es decir, de producción hacia desarrollo, para detectar y corregir problemas pronto. Si el flujo es el río hacia adelante, la retroalimentación es la señal de regreso que te dice si vas bien.
Cómo se logra
- Pruebas automáticas en cada cambio: sabes en minutos si algo se rompió.
- Monitoreo y observabilidad de producción, con métricas, registros y alertas útiles.
- Revisión por pares del código antes de integrarlo.
- Detener la línea: cuando algo falla en el pipeline, el equipo se detiene a corregirlo antes de seguir.
- Acercar a desarrollo a las consecuencias de lo que construye: participar en la operación, atender guardias, leer los incidentes.
- Escuchar al cliente: datos de uso, soporte, encuestas.
El efecto
Los problemas se detectan cerca de su causa, cuando son pequeños y baratos. Cuanto más tarda en llegar la señal, más cuesta corregir.
Tercera vía: aprendizaje continuo y experimentación
Idea: construir una cultura que fomente la experimentación, la asunción de riesgos razonables y el aprendizaje de los errores y el éxito, con práctica constante.
Cómo se logra
- Cultura sin culpables: los fallos se analizan para aprender, no para castigar.
- Dedicar tiempo a mejorar el trabajo diario: reducir deuda técnica y mejorar procesos es tan importante como las funcionalidades nuevas.
- Experimentar a propósito: pruebas de caos, ejercicios de recuperación ante fallos, pruebas A/B.
- Compartir conocimiento: documentación, charlas internas, retrospectivas, post-mortems accesibles.
- Convertir los aprendizajes locales en mejoras globales.
Por qué importa
Los sistemas complejos fallan de formas imprevisibles. Los equipos que practican la recuperación y aprenden de los incidentes se vuelven resilientes, y los que ocultan sus errores repiten los mismos.
Cómo se relacionan
| Vía | Pregunta clave | Prácticas típicas | |---|---|---| | Flujo | ¿Qué tan rápido llega el valor al cliente? | CI/CD, lotes pequeños, límites de WIP | | Retroalimentación | ¿Qué tan pronto sabemos que algo falla? | Pruebas, monitoreo, revisiones | | Aprendizaje | ¿Qué hacemos con lo que aprendemos? | Post-mortems, experimentos, mejora continua |
Las tres se refuerzan: un flujo rápido sin retroalimentación te lleva más rápido al error; retroalimentación sin aprendizaje solo te informa de los mismos problemas.
Cómo usarlas en la práctica
Hazte tres preguntas sobre tu equipo:
- Flujo: ¿cuánto tarda un cambio desde que se pide hasta producción? ¿Dónde espera más tiempo?
- Retroalimentación: ¿cuánto tardamos en enterarnos de que un cambio causó un problema?
- Aprendizaje: ¿qué cambió en nuestra forma de trabajar tras el último incidente?
Con las respuestas ya sabes por dónde empezar.
Errores frecuentes
- Adoptar herramientas sin entender el principio: instalar un pipeline que no mejora el flujo.
- Optimizar una sola etapa (por ejemplo, programar más rápido) sin ver el sistema completo; el cuello de botella simplemente se mueve.
- Ignorar la tercera vía, la más difícil y la que más cuesta mantener.
- Culpar a personas y destruir la retroalimentación honesta.
Para finalizar
Las tres vías son una forma de pensar: acelerar el flujo, escuchar pronto lo que dice la realidad y convertir cada experiencia en aprendizaje. Las herramientas cambian cada pocos años, estos principios se mantienen. Si tuviera que quedarme con una sola idea sería esta: mejora el sistema donde trabajas, no solo el trabajo que haces dentro de él.