Continuamos la serie para hablar de DevOps en Podemos TI. Ahora vamos a hablar un poco de cómo medir DevOps...
La primera parte la pueden leer aquí.
La tercera y última parte la pueden leer aquí.
Antaño, o bueno, en realidad hoy en día también, suele haber una diferencia muy marcada entre los que desarrollan el sistema, y los que operan el sistema (que son los que lo suelen instalar, le dan seguimiento, lo mantienen vivo y sano). Ya desde lejos se puede ver el problema: la oposición de incentivos. Los desarrolladores buscan crear cosas lo más rápido posible para entregar nuevo valor a los usuarios rápidamente, mientras que los operadores lo que buscan es que el sistema siempre esté en un estado usable y estable para seguir entregando valor a los usuarios. Esta diferencia y las barreras que genera es la PRIMER causa de que no seamos eficientes. El nombre DevOps de hecho sale de aquí. De unir a los Desarrolladores (Developers) con los Operadores (Operators) para que juntos sean un mismo equipo, con intereses comunes: el equipo DevOps.
¿Cómo se ve DevOps a nivel mundial?
Existen una serie de estudios que se suelen hacer con frecuencia anual, y que analizan con mucha lupa el estatus de DevOps en la industria del desarrollo de software.
De leer algunos de estos estudios aprendí las principales 4 métricas que se pueden tomar para saber qué tan buenos somos en DevOps:
- ¿Con qué frecuencia se hacen los despliegues para entregar valor a los usuarios? (Deployment Frequency) Las organizaciones de TI que son realmente DevOps lo hacen bajo demanda, mútliples veces al día. Mientras que las más alejadas lo hacen una vez cada mucho tiempo, en semanas o hasta meses. Para estas últimas desarrollar software es una labor de alto riesgo, que debe ser tomada con pinzas, lo cual genera un tiempo muy largo para finalmente entregar valor. Tan largo que a veces cuando se despliega la solución el problema ya cambió y el desarrollo es irrelevante. El ejemplo a seguir que se suele dar aquí es Amazon. El equipo de desarrollo de Amazon tiene la bien ganada fama de estar desplegando soluciones en la asombrosa y alucinante cantidad de cada ¡11.6 SEGUNDOS!
No se como se pronuncia 'Amazon'. Supongo que así como se lee... 'a-ma-zon'... pero en mi casa, mi mamá le dice 'a-mei-zon', y aquí aplica porque justo, cuando leí esto, me quedé así: 'AMAZING!'
- ¿Cuánto tiempo pasa desde que un desarrollador tiene una solución hecha, hasta que dicha solución está ya desplegada, entregando valor a los usuarios? (Lead Time for Changes) Las Devops deberían de esperar no más de un día. De nuevo el ejemplo de Amazon es representativo en este caso. Una organización anti-DevOps seguramente también esperará entre un mes o hasta seis meses (!!) para lograr que los cambios suban a producción
- ¿Cuánto tiempo pasa entre que ocurre un problema del sistema que impacta a los usuarios y el valor que obtienen del mismo, y cuando el servicio es restaurado? (Time to Restore Service) En DevOps deberíamos aspirar a menos de una hora. Anti-DevOps, por su naturaleza, puede ver tiempos de entre una semana o hasta un mes.
- ¿Cuál es el ratio de cambios al sistema que provocan un servicio degradado (entregando menos valor a los usuarios) y que requieren remedio, contra los que no lo hacen? (Change Failure Rate) En DevOps, este porcentaje no debe exceder el 15%. Mientras que en anti-DevOps podría estar entre el 45 y 60% :-o
La siguiente entrega, ahora sí, tratará de como tenemos implementado DevOps hoy en día en Podemos TI ;-)
Si quieres ver las otras partes de esta serie:
La primera parte la pueden leer aquí.
La tercera y última parte aquí.