Cultura DevOps
Puedes comprar Kubernetes, contratar consultores y montar el pipeline más elegante del mercado. Si el equipo de desarrollo sigue lanzando código "por encima del muro" y el de operaciones sigue considerando que cada despliegue es una amenaza, no has hecho DevOps: has automatizado un proceso roto.
Las herramientas se copian en un trimestre. La cultura es lo que de verdad diferencia a una organización, y también lo que más cuesta cambiar.
Por qué aparecen los silos
Es tentador pensar que es cuestión de mala actitud. Casi nunca lo es: es que los incentivos están enfrentados.
| Desarrollo | Operaciones | |
|---|---|---|
| Se le mide por | Entregar funcionalidades | Estabilidad del servicio |
| El cambio es | Su trabajo | Su principal riesgo |
| Un buen mes es | Muchas releases | Ninguna incidencia |
Con esos objetivos, ambos equipos están actuando de forma perfectamente racional. Desarrollo quiere desplegar; operaciones quiere frenar. Y el conflicto no se resuelve pidiendo que colaboren más, sino cambiando los incentivos.
Cuando ambos responden del mismo indicador —por ejemplo, un SLO compartido— la discusión cambia de naturaleza. Deja de ser "tú quieres ir rápido y yo quiero estabilidad" y pasa a ser "¿cuánto presupuesto de error nos queda este mes?".
El modelo CALMS
Las cinco dimensiones de una cultura DevOps:
- Culture — responsabilidad compartida sobre el resultado, no sobre la propia parcela
- Automation — todo lo repetitivo se automatiza, empezando por lo que más duele
- Lean — reducir el trabajo en curso y eliminar esperas
- Measurement — decidir con datos, no con opiniones
- Sharing — el conocimiento circula en vez de acumularse
El orden no es casual. La cultura va primero porque sin ella las otras cuatro se implantan a medias: se automatiza lo cómodo, se mide lo que queda bien y se comparte lo que no compromete a nadie.
Las tres ideas que más cambian las cosas
"You build it, you run it"
Quien construye el software es responsable también de operarlo. La frase es de Werner Vogels, de Amazon, y su efecto es inmediato: cuando el mismo equipo que escribe el código recibe la llamada a las tres de la mañana, ese código empieza a tener logs útiles, métricas y un manejo de errores decente.
No hace falta ser radical. Basta con que desarrollo participe en las guardias y vea de primera mano qué pasa con lo que entrega.
Cultura sin culpables
Cuando algo falla, la pregunta no es "¿quién lo rompió?" sino "¿qué permitió que esto llegara a producción?".
No es amabilidad mal entendida, es que funciona mejor. Si señalar tiene consecuencias, la gente esconde información, y entonces no te enteras de lo que pasó de verdad ni puedes evitar que se repita.
La comprobación práctica: si en tu organización alguien puede decir en voz alta "he desplegado esto y se ha caído todo" sin miedo, tienes seguridad psicológica. Si no, tus postmortems son ficción.
Responsabilidad compartida sobre el resultado
Que el sistema funcione no es "cosa de operaciones", igual que la calidad no es "cosa de QA". Cuando cada equipo responde solo de su tramo, los problemas viven en las costuras y no son de nadie.
Los obstáculos reales
"Siempre lo hemos hecho así". No se combate con presentaciones. Se combate con un equipo voluntario, un caso pequeño y un resultado que se pueda enseñar. Un despliegue que pasa de dos horas a diez minutos convence más que cualquier argumento.
"No tenemos tiempo". Cierto: siempre están apagando fuegos. Por eso hay que empezar automatizando lo que causa los fuegos, no lo más elegante. El tiempo aparece cuando dejan de repetirse las mismas tareas.
Objetivos enfrentados. Es el obstáculo de fondo, y el único que no puede resolver el equipo. Requiere que alguien con autoridad cambie cómo se mide a cada parte. Sin eso, lo demás es cosmética.
Falta de conocimientos. Real y resoluble: formación, tiempo protegido para aprender y pares que enseñen. Lo que no funciona es esperar a que la gente aprenda en su tiempo libre.
Cómo se empieza
Por algo pequeño y visible:
- Elige el dolor más evidente. Normalmente el despliegue manual que a todo el mundo le da pereza.
- Un equipo voluntario. Los escépticos se convencen con resultados, no antes.
- Mide el antes. Sin línea base no puedes demostrar la mejora.
- Automatiza y enseña el después.
- Extiende a quien lo pida, no a quien se lo impongas.
Lo que casi siempre falla es el enfoque contrario: reorganizar el organigrama, renombrar al equipo de sistemas como "equipo DevOps" y esperar que la cultura cambie sola. Eso solo renombra el silo.
Un aviso sobre el "equipo DevOps"
Crear un equipo llamado DevOps entre desarrollo y operaciones suele producir exactamente lo que se quería evitar: un tercer silo, ahora con la responsabilidad de traducir entre los otros dos.
Los modelos que sí funcionan, según Team Topologies:
- Equipos alineados al flujo que son dueños de su producto de principio a fin
- Un equipo de plataforma que les da herramientas y caminos fáciles, pero no despliega por ellos
La diferencia es sutil y decisiva: la plataforma ofrece un servicio de autoservicio, no un intermediario al que pedir turno.
Cómo saber si está funcionando
Más allá de las métricas DORA, hay señales que se notan antes:
- ¿Alguien de desarrollo ha mirado un panel de producción esta semana?
- ¿El último postmortem menciona nombres o menciona controles?
- ¿Cuánto tarda una persona nueva en desplegar a producción por primera vez?
- ¿Se despliega los viernes?
Esa última es más reveladora de lo que parece. "No desplegamos los viernes" no es prudencia: es la confesión de que no confías en tu capacidad de detectar y revertir un problema.
Resumen
- Las herramientas se copian; la cultura es lo que diferencia
- Los silos no son mala actitud, son incentivos enfrentados
- CALMS: cultura, automatización, lean, medición y compartir — en ese orden
- "You build it, you run it" mejora el código porque cambia quién sufre las consecuencias
- Sin cultura sin culpables, los postmortems son ficción
- Empieza pequeño, con voluntarios y midiendo el antes
- Un "equipo DevOps" suele crear un tercer silo: mejor equipos de flujo más plataforma
- Si no despliegas los viernes, ya sabes en qué trabajar
Recursos adicionales
- The Phoenix Project — la novela que lo explica mejor que cualquier manual
- Team Topologies
- Westrum organizational culture — el modelo detrás de las métricas culturales de DORA
💡 Recuerda: si tu transformación DevOps consiste en renombrar al equipo de sistemas, no has transformado nada.
En el próximo capítulo bajamos a la herramienta que sostiene todo el flujo: Git.