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")
Respuestas:
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:
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.
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 "
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:
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:
fuente
Un problema que se soluciona rápidamente sigue siendo un problema. Si no está informando esto como tal, eso es un problema.
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.
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.
fuente