¿Cuáles son algunos métodos para medir el ROI de DevOps?

DevOps es complejo e involucra muchos aspectos no deterministas como la cultura y el proceso.
¿Cuáles son algunas formas de medir las iniciativas de DevOps para el éxito?
¿Cómo le demuestra a una empresa que la inversión que ha realizado es devolver (o ahorrar) dólares reales?

Gran pregunta! La mayoría de nosotros sabemos que invertir en prácticas de DevOps es una actividad muy valiosa por innumerables razones; Sin embargo, no solemos justificar a DevOps solo por el impacto en el resultado final.

Nota : esta es una pregunta algo obvia, y mi respuesta es igualmente obstinada.

Tensibai sugirió sabiamente que encontráramos las métricas correctas, y usó el tiempo de comercialización como ejemplo. Este es un gran enfoque general.

Como un enfoque alternativo, mi experiencia con los contadores de frijoles es que no necesitan, o necesariamente quieren, conocer el panorama general, solo quieren evidencia de responsabilidad fiscal. Quieren ver una tendencia en la dirección correcta.

Estas son solo algunas victorias fiscales:

• calcular los costos del servidor ahorrados al aprovechar el autoescalado en la nube
• para sitios que generan ingresos, extrapolar el costo por minuto de tiempo de inactividad, luego mostrar mejoras en MTTI y MTTR
• nuevamente, para los sitios que generan ingresos, calcule el costo por minuto ahorrado aprovechando la arquitectura de alta disponibilidad basada en incidentes pasados
• Si ha mejorado su canalización de compilación e implementación, demuestre que ha reducido las regresiones y los errores en la producción causados ​​por fallas ya rastreadas
• Si ha realizado mejoras en los entornos de prueba de desarrollador, o incluso en las herramientas y la configuración de las computadoras portátiles de desarrollador, consulte los historiales de confirmación para ver si los nuevos ingenieros están haciendo sus primeras contribuciones antes de unirse.
• realice una comparación completa de costos entre la nube y las instalaciones locales, al igual que lo hizo Gitlab recientemente , para justificar su gasto en infraestructura (¡también conocido como ahorro!)

Demostrar que usted es consciente del dinero y tiene algunas victorias claras es a menudo suficiente. Ciertamente me he perdido algunos ejemplos obvios; siéntase libre de agregar comentarios a continuación.

La métrica clave para una tubería DevOps es el tiempo de ciclo (también llamado tiempo de entrega ). Este es el tiempo que lleva un cambio (o una solicitud de cambio, rastreando hasta el inicio de la idea). La mejor ilustración de este concepto que conozco es del libro "The Goal", que habla de él en un contexto de fabricación.

La frecuencia de implementación también es útil. Queremos que las implementaciones sean frecuentes en una tubería de DevOps. No hay una medida mágica de "1 día es bueno, 2 días es malo"; Esto necesitará un contexto histórico en su proyecto para ser significativo.

Tamaño de implementación : medido en la medida en que sus desarrolladores miden el trabajo: historias de usuarios, puntos de historia, quatloos, lo que sea. Una vez más, desea ver las tendencias a lo largo del tiempo, no el valor absoluto.

Entre frecuencia y tamaño hay una historia que contar. ¿Nuestros lanzamientos se vuelven cada vez menos frecuentes y más grandes? ¿por qué? ¿Se están volviendo más pequeños y más frecuentes? De nuevo por qué?

Al explicar si la tendencia de frecuencia / tamaño es buena, también necesitaremos Porcentaje de despliegues fallidos . Descubrir el 'por qué' en esas tres métricas le dirá mucho sobre la salud del proyecto.

Mi favorito personal, aunque es una métrica de vanidad, es Time for a Trivial Deploy . Si encuentra la cosa más pequeña posible que vale la pena volver a desplegar todo el sitio ... tal vez un error tipográfico en nombre del CEO ... ¿qué tan rápido podría pasar de la llamada de pánico a un sitio desplegado? Digo 'vanidad' porque realmente no es tan predictivo más allá de lo que discuten las otras métricas anteriores, pero me hace sentir bien cuando me gusta el valor.

Si comenzamos a monitorear, hay un montón de cosas diferentes que podemos rastrear ... desde cosas que abarcan todo, como ' Tiempo de actividad ', hasta cosas de muy bajo nivel como el tiempo dedicado a regenerar HTML personalizado en un ciclo de solicitud-respuesta ... pero esos no son específicos para instituir una cultura DevOps.

Estos no se vinculan directamente con los dólares ... para hacerlo, se requerirá más conocimiento sobre su organización de lo que puedo ofrecer en un foro como este; pero son la clave para COMENZAR a responder esa pregunta. Una vez que sepa que puede lanzar regularmente el trabajo a producción como un no evento, puede comenzar a ver cuánto esfuerzo estaba desperdiciando antes. Como enseña el libro "The Goal" (sobre las tuberías de fabricación, es relevante), optimizar localmente puede parecer que está ahorrando dinero, pero en última instancia, solo crea valor que está vinculado al inventario (características no implementadas).

Más allá de este consejo, debería echar un vistazo al Informe del estado de DevOps de los últimos años. Esto está lleno de mediciones sobre proyectos del mundo real que podrías emular.

Capitán obvio: al reducir el tiempo de comercialización y los defectos en los lanzamientos.

Para ampliar esta línea, el escollo habitual es ser un cambio de organización sin ninguna referencia.

Involucrarse en un cambio de cultura u organización implica algunos gastos para capacitar e introducir a las personas a este nuevo método, esto tiene un costo en capacitación pero también implica una pérdida de productividad ya que las personas en una sesión de capacitación no producirán nada. Esta es la parte de inversión del cambio cultural.

Para medir un ROI, primero debe encontrar algunas métricas relevantes que deberían mejorarse (comprender costosas, costosas o la fuente de pérdida de ganancias). Esto podría ser un tiempo de comercialización más corto, menos parche después de cada lanzamiento, una mejor participación del cliente dentro de su producto. Las métricas relevantes dependerán en gran medida de sus productos.

La medición de un ROI (qué tan rápido ha cubierto el gasto de capacitación) implica que puede presentar una evolución de hecho en esas métricas, por lo que antes de realizar cualquier cambio debe haber definido esas métricas y medirlas de manera objetiva.
Una vez que tenga una evolución real que mostrar, puede saber si mejoró algo de una manera que cubrió los gastos de capacitación y se volvió más rentable de lo que era antes.

El escollo habitual es realizar el cambio antes de haber definido cualquier métrica y, por lo tanto, evaluar el retorno de la inversión en un sentimiento y no en datos reales.

La productividad puede ser una métrica, pero su medición suele ser muy difícil de hacer de manera objetiva y no debe ser una métrica de primera clase para este tipo de estudio.

Tarde para el juego aquí, pero pensé que intervendría.

No puede administrar lo que no mide, por lo que, para empezar, aquí están las métricas clave que los equipos de desarrollo deberían rastrear para la respuesta a incidentes:

• Tiempo de actividad% : % total de tiempo disponible = [tiempo total - tiempo de inactividad] / [tiempo total]
• MTTR : tiempo medio de resolución = [tiempo de inactividad] / [# incidentes]
• MTTA : tiempo medio de reconocimiento = [tiempo total de reconocimiento] / [# de incidentes]
• MTBF : tiempo medio entre fallas = [tiempo total - tiempo de inactividad] / [# de incidentes]

Estas métricas le brindan un control de estado de alto nivel de sus operaciones y lo ayudan a identificar dónde necesita profundizar más.

Eche un vistazo a la animación de la pizarra aquí para obtener una visión más detallada del tema.

Una vez que conozca sus métricas, puede compararlas con el costo del tiempo de inactividad . Puede comenzar a desarrollar el ROI de su equipo desde allí y establecer algunas métricas cuantitativas para la mejora continua.