desafío de métricas de implementación anteriores a DevOps

TL; DR, ¿cómo demuestra que los devops, específicamente la automatización de implementación, mejoran las tasas de falla de cambio?

Todos estamos tratando de capturar métricas sobre 'fallas de implementación' utilizando los medios actuales (principalmente manuales). Desafortunadamente, rara vez ocurre un 'fracaso', ¿verdad? Porque cuando algo sale mal, el equipo se une (generalmente con heroicidades) para solucionar el problema (generalmente permisos, configuraciones perdidas, ya sabes el ejercicio). Entonces ... cuando preguntamos cómo fue el despliegue, la respuesta es "funcionó".

Pero, intuitivamente, todos sabemos que eso no es bueno. El informe del estado de devops de 2017 dice que hay un " índice de falla de cambio " del 31-45% . Si bien eso parece intuitivamente correcto, ¿se registran como incidentes? Nah Porque se arreglan bastante rápido, generalmente durante la validación. Es mucho más raro revertir una implementación.

Por lo tanto, se necesita disciplina para informar las tasas de falla con precisión. Estamos desincentivados para informar así porque queremos que las cosas funcionen y hacemos lo que sea necesario para que esto suceda.

Entonces, ¿cómo demuestra que los DevOps, específicamente la automatización de implementación, mejoran las tasas de falla de cambio?

(PS intentó etiquetar esto con "# devops-capacity-model")

Una técnica que hemos usado en el pasado en situaciones similares es conseguir un "compromiso de gestión" que imponga estas reglas a cada miembro del equipo:

1. El acceso para realizar actualizaciones en las áreas de implementación de destino (es decir, producción) se limita a los sistemas automatizados seleccionados, que tienen pistas de auditoría apropiadas (= registro) de cualquier tipo de actualizaciones en las áreas que administran.

2. Las actualizaciones manuales de las áreas de implementación de destino, por el motivo que sea, ya no están permitidas por los miembros típicos del equipo (ID de usuario) que solían (autorizar) realizar estas actualizaciones. En su lugar, se crearán nuevas ID de usuario (adicionales) que tendrán todos los permisos necesarios para (aún) realizar tales actualizaciones manuales, siempre que sea necesario. Pero para poder usar esas nuevas ID de usuario (= iniciar sesión con ellas), el miembro del equipo que quiera iniciar sesión con dicha nueva ID de usuario deberá realizar "algún" paso adicional para acceder a la contraseña para dicho nuevo ID de usuario. Idealmente, este paso adicional también está automatizado (use su propia imaginación como debería verse), pero si algo más falla: solo comuníquese (= correo electrónico, llamada, etc.) con el guardián de la contraseña requerida, incluyendo "qué problema tienen para arreglarse "

3. Poner a ese portero en su lugar no es un trabajo fácil. Y la mayor resistencia vendrá de ... los miembros del equipo (por todo tipo de razones). Por lo tanto, una variación de esas nuevas ID de usuario (como en el paso anterior) es que cada miembro del equipo obtiene una ID de usuario adicional (con la contraseña que ellos mismos deciden), pero con una cadena adicional adjunta: solo se les permite realizar un inicie sesión con esa identificación de usuario (extra) si realmente tienen una buena razón para hacerlo. Y cada vez que realizan dicho inicio de sesión, se les exige que presenten algún tipo de informe sobre "qué problema solucionaron" (similar a su pregunta).

Con estos procedimientos en su lugar, todo lo que queda por hacer es revisar periódicamente cada uno de esos informes / razones por las cuales se requería usar una identificación de usuario tan especial y hacer la pregunta " ¿Hay algo que se pueda hacer para automatizar aún más esto? reducir aún más la necesidad de un inicio de sesión tan especial? ".

Actualización :

Cita de tu comentario adicional debajo de esta respuesta:

Creo que agregar barreras artificiales para solucionar un problema de implementación es contraproducente.

Es cierto que agrega una barrera adicional, pero no estoy convencido de que sea "artificial". Por lo que sé, esta es la única forma de tomar conciencia de las cosas que los miembros del equipo de otra manera nunca le dirán, por razones como:

• seguridad en el empleo.
• cosas / prácticas malas que prefieren mantener ocultas.
• poder que no quieren perder.

El informe del estado de devops de 2017 dice que hay un 31-45% de "tasa de falla de cambio". Si bien eso suena intuitivamente correcto, ¿se los rastrea como incidentes? Nah Porque se arreglan bastante rápido, generalmente durante la validación.

Un problema que se soluciona rápidamente sigue siendo un problema. Si no está informando esto como tal, eso es un problema.

Por lo tanto, se necesita disciplina para informar las tasas de falla con precisión. Estamos desincentivados para informar así porque queremos que las cosas funcionen y hacemos lo que sea necesario para que esto suceda.

Si su objetivo es que las cosas funcionen, entonces debe ser honesto acerca de las fallas para poder prevenirlas en el futuro. Parece que el equipo aquí está mintiendo (tal vez a sí mismos, ciertamente a la gerencia) sobre fallas porque su objetivo es que las cosas parezcan estar funcionando.

Estas son cosas diferentes. Por ejemplo, tome el viejo chiste de que QA produce errores: "mi código estuvo bien hasta que QA lo descubrió y luego hicieron todos estos errores". Los errores estuvieron allí todo el tiempo, pero el desarrollador los ignoró. El objetivo de un equipo de operaciones debe ser la confiabilidad real , y su administración debe incentivarlos como tales. Eso significa que si implementan más monitoreo que conduzca al descubrimiento de nuevos problemas, deberían ser recompensados, no penalizados por la posterior caída en las métricas de confiabilidad.

TL; DR, ¿cómo demuestra que los devops, específicamente la automatización de implementación, mejoran las tasas de falla de cambio?

Si está tratando de motivar el cambio en su organización, entonces no debería intentar probar nada, sino proporcionar evidencia de lo que otras organizaciones dicen sobre sus propias transiciones. Si está tratando de medir los procesos que ya tiene implementados y justificar su existencia continua, entonces debe estar siguiendo las métricas de confiabilidad estándar, como el tiempo medio de reparación (MTTR).

Pero los principios de DevOps no se tratan simplemente de aumentar la fiabilidad. Incluso la ingeniería de confiabilidad del sitio no se trata simplemente de aumentar la confiabilidad. Por el contrario, desea alcanzar un nivel adecuado de confiabilidad, algo que beneficie al negocio pero que no obstaculice el desarrollo. Y eso plantea el verdadero motivador en devops, que es potenciar el cambio . Desea permitir que la empresa responda más rápido a los estímulos del mercado, lo que ocurre al disminuir la fricción del desarrollador, aumentar la tasa de despliegues, automatizar procesos manuales, etc., mientras se mantiene dentro de un límite aceptable de confiabilidad. Esto significa que necesita medir la confiabilidad, pero también necesita medir la velocidad, porque su objetivo es aumentar la última mientras mantiene la primera relativamente estática.