¿Qué indicadores clave de rendimiento (KPI) se utilizan para medir DevOps?

Estoy tratando de generar buenos comportamientos dentro de un programa de transformación DevOps, para apoyar esto, estoy buscando identificar métricas accionables en torno a las disciplinas de operaciones:

• Manejo de problemas e incidentes
• Gestión de la capacidad
• Gestión de cambios y lanzamientos

Para ser absolutamente claros, estas son funciones que solían pertenecer a la organización de operaciones y ahora son propiedad de la organización Agile / DevOps. Existen KPI existentes que generan malos comportamientos:

• Análisis del tiempo de la causa raíz completado:
  • Impulsa RCA incompletos solo para ingresarlos al sistema a tiempo.
• Duración de ejecución de prueba:
  • Inhabilita las pruebas de larga duración, independientemente de su valor comercial.
• Utilización promedio de servicios en la nube:
  • Fomenta el compromiso excesivo de los recursos informáticos, lo que resulta en tiempos de respuesta lentos

¿Qué indicadores clave de rendimiento se pueden utilizar para fomentar el buen comportamiento en un programa DevOps?

No creo que haya ningún KPI DevOps "universal". Por ejemplo, la velocidad es excelente, a menos que no sea un factor clave para su negocio. Amazon se preocupa mucho por la velocidad porque tienen una operación minorista masiva. Eso es menos importante para una aplicación pequeña con 100 usuarios.

Esto plantea la pregunta: ¿cómo se seleccionan los mejores KPI relevantes para su negocio? Ese es un proceso de investigación y descubrimiento que involucra a toda su empresa.

¿Que te preocupa?

• Calidad
• Fiabilidad
• Mantenibilidad
• Velocidad
• La mejora de procesos
• Niveles de servicio

¿Qué mantiene despiertos a los interesados ​​de su negocio por la noche? ¿Qué determina si ganas dinero este trimestre o no? La lista anterior puede incluir algunas de esas cosas, o puede que no. Haga su lista, luego descubra cómo alinear los incentivos en todos los departamentos para lograrlos.

Los incentivos impulsan el comportamiento, así que decida en colaboración sobre los objetivos SMART. Elija dos o tres elementos de su lista de lluvia de ideas y comience un ciclo de retroalimentación de medida / corrección para cada uno. No elijas demasiados a la vez: es más probable que tengas éxito si te concentras en dos o tres cosas.

DevOps no tiene ningún KPI . Sería como preguntar cuáles son los KPI del amor. Pero algunas de las cosas que usted ha mencionado ( de problemas y gestión de incidentes , capacidad de gestión , administración de cambios y de salida ) tenemos buenos KPI, algunos de los cuales se basan en la teoría detrás de DevOps.

En general, para cualquier proceso comercial, puede crear un Mapa de la cadena de valor que describa cómo fluye el valor del Cliente , a través de la empresa de regreso al Cliente . Todo el ciclo siempre tiene que comenzar y finalizar con el Cliente, pero a veces, para una organización de servicios, el Cliente puede ser interno. El rendimiento del valor a través de dicha cadena puede ser una buena manera de diseñar su KPI de manera a prueba de manipulaciones. La medición de cualquier KPI en cualquier enlace individual de la cadena de valor solo tiene sentido siempre que ese enlace en particular sea el cuello de botella del proceso e intente explotar o elevar el cuello de botella.

Un problema común con KPI es cuando comienza a la mitad de la cadena. Por ejemplo, un proceso de Cambio y Lanzamiento a menudo comienza con desarrolladores y termina con la implementación. Este proceso excluyó:

• Cliente que tiene un problema
• Equipo de soporte identificando los problemas
• Equipo de producto que define el problema de la acumulación
• Equipo de soluciones que personaliza la implementación para el cliente
• Cliente obteniendo valor de la solución

El problema es que medir solo el tiempo de un ciclo podría conducir a dos problemas principales:

1. El cuello de botella se encuentra en cualquiera de las partes excluidas mencionadas anteriormente y sus clientes no se dan cuenta del valor y usted no se da cuenta de los ingresos proporcionales a la velocidad de su tiempo de ciclo. Entonces, aunque su ingeniería es excelente, su negocio sufre.

2. La desconexión de los Clientes hará que su ciclo de lanzamiento gire en vacío, sin producir ningún valor, a pesar de los cambios realizados, o incluso contrarrestará las necesidades de sus Clientes y el trabajo realizado podría tener un valor comercial negativo.

Otro problema con KPI es que, al comenzar y terminar con un cliente, en realidad no puede medir el valor para el cliente. Un buen ejemplo sería un proceso de Respuesta a incidentes y problemas y MTTR (Tiempo medio de reparación) como KPI. ¿El problema incluso afecta a alguien? ¿Cuál es el valor para los clientes? Podría tener un excelente MTTR de 3 horas en más de 100 incidentes. Pero si la mayoría de ellos fueron internos, con un impacto mínimo o nulo para los clientes y se resolvieron en minutos, mientras que el gran incidente con un gran impacto en el cliente tardó 3 días en manejarse, el valor comercial es menor que si tuviera 1 día MTTR, porque usted ignore la mayoría de los incidentes internos, pero respondió al gran incidente de impacto en el cliente en 1 hora.

NOTA: Para un cliente interno, en el caso del proceso comercial del equipo de soporte, el valor derivado no es el valor del trabajo para el cliente interno, sino el valor ganado por el negocio al desbloquear al cliente interno en su propio proceso comercial. Desbloquear un equipo que es un cuello de botella en su propio proceso deriva un valor más alto que desbloquear un equipo o individuo sin cuello de botella. Todos los KPI de dicho equipo de soporte deben incluir el valor comercial en su cálculo.

1. Frecuencia de implementación
2. Velocidad de despliegue
3. Tasa de éxito de implementación
4. Con qué rapidez se puede restaurar el servicio después de una implementación fallida
   Y, por último,
5. Cultura DevOps, que en realidad no se puede medir