¿Cómo salvaguardar el despliegue de Ansible para mitigar los accidentes?

Recientemente, el Amazon S3 tuvo una interrupción importante en la región us-east-1. Parece que probablemente fue causado por un error de ortografía al ejecutar un libro de mantenimiento en Ansible o una herramienta similar. Puede poner un contenedor de script de shell alrededor de ansible-playbook para que se vea así:

#!/bin/bash
/usr/bin/ansible-playbook "$@" --list-hosts --list-tasks
read -p "Are you sure? (y/n) " answer
test "$answer" = "y" || exit 0
exec /usr/bin/ansible-playbook "$@"

Pero, ¿cuáles son algunas otras formas que utiliza para mejorar la seguridad y reducir la posibilidad de error que causa una interrupción importante para su empresa?

Estamos utilizando trabajos en jenkins para activar implementaciones. Asegura que no importa quién realice la implementación, el comando ansible que se ejecuta será el mismo. Una buena ventaja es el registro de registros de compilación cuando se activaron las implementaciones, quién las activó y qué sucedió exactamente durante la implementación.

Ciertamente no es infalible, pero ha sido una buena mejora sobre la ejecución manual de playbooks ansibles.

Para cambios más grandes / riesgosos, esto debería combinarse idealmente con alguna forma de gestión del cambio, de modo que los cambios se realicen solo después de que otra persona / equipo revise el cambio y el enfoque del cambio para ayudar a identificar y resolver problemas potenciales de manera temprana.

Además, nunca está de más tener un compañero de equipo que entienda el cambio que estás haciendo presente y observando mientras haces grandes cambios para que puedan vigilar y ayudar a prevenir errores en la ejecución del cambio.

Categorías de errores

Hay dos formas de ver los factores humanos que conducen a problemas y accidentes:

1. Puede ver el error humano como la causa de un accidente. En este caso, "error humano", bajo cualquier etiqueta: pérdida de conocimiento de la situación, violación del procedimiento, fallas regulatorias, deficiencias administrativas es la conclusión de su investigación.
2. Puedes ver el error humano como el síntoma de problemas más profundos. En este caso, el error humano es el punto de partida para su investigación. Investigará cómo el error humano está sistemáticamente conectado a las características de las herramientas, tareas y entorno operativo / organizacional de las personas.

El primero se llama el enfoque humano , y el segundo como el enfoque del sistema .

Para explicar el fracaso utilizando el enfoque humano, buscaría el fracaso y encontraría evaluaciones inexactas de las personas, decisiones equivocadas o juicios erróneos.

Para explicar la falla utilizando el enfoque del sistema, no está tratando de encontrar dónde la gente salió mal. En cambio, descubra cómo las evaluaciones y acciones de las personas tenían sentido en ese momento, dadas las circunstancias que las rodeaban.

Por ejemplo, Donald Berwick, del Instituto para la Mejora de la Atención Médica (IHI), argumenta que mejorar la seguridad del paciente requiere cambios en el diseño de los sistemas :

... Somos humanos, y los humanos erramos. A pesar de la indignación, a pesar del dolor, a pesar de la experiencia, a pesar de nuestros mejores esfuerzos, a pesar de nuestros deseos más profundos, nacemos falibles y seguiremos siéndolo. Ser cuidadoso ayuda, pero no nos acerca a la perfección ... El remedio está en cambiar los sistemas de trabajo. El remedio está en el diseño. El objetivo debe ser la seguridad extrema. Creo que deberíamos estar tan seguros en nuestros hospitales como lo estamos en nuestros hogares. Pero no podemos alcanzar ese objetivo mediante exhortación, censura, indignación y vergüenza. Solo podemos alcanzarlo comprometiéndonos con el cambio, de modo que los errores humanos normales se vuelvan irrelevantes para el resultado, se encuentren continuamente y se mitiguen hábilmente.

Donald M. Berwick. ¡No otra vez! BMJ 2001

Eliminar errores del sistema

Una excelente manera de encontrar (y corregir) las diversas formas en que ocurre la falla después del hecho, es buscar la causa raíz sin culpar a las personas. Esto a menudo se llama "autopsias sin culpa", y Etsy Code como publicación de blog Craft amplía el concepto. La gente de Etsy presentó y escribió más sobre esto en otros foros y blogs.

Para evitar errores en primer lugar, algunos rasgos culturales son imprescindibles. Los procedimientos y diversos artefactos creados en el sistema deben probar que usarlos por humanos es muy claro y se explica por sí mismo. A menudo, los que crean no son los que consumen, lo que lleva a una desconexión y falta de claridad. El sistema no es seguro para operar, ya que la única persona que conoce todas las suposiciones es quien lo creó (y nadie más).

Medidas de control efectivas

Implemente medidas de control efectivas para detener el proceso cuando ocurra un error. Esto es a prueba de errores. Las medidas de control efectivas son cambios de diseño que impiden o impiden que los procesos continúen cuando se produce un error al introducir una falla del proceso

Ejemplo:

En 1896, Sakichi Toyoda inventó el primer telar eléctrico de Japón llamado "el telar eléctrico de Toyoda Steam". Este desarrollo aumentó la productividad en veinte veces, y la calidad de los textiles mejoró y causó una revolución en la industria textil en Japón. Pero aquí está el descubrimiento y principio sutil pero muy importante:

cuando la aguja se rompió, la máquina se detuvo

Sakichi Toyoda creó una innovación para el Telar que luego se convertiría en uno de los pilares del Sistema de Producción Toyota (Lean). Ese pilar que ahora llamamos Jidoka, a veces llamado "automatización inteligente con un toque humano" o "autonomía".

En gran parte, Andon (parada en el primer defecto) y Poka-Yoke (prueba de errores) son desarrollos posteriores que encuentran su influencia en el Telar.

Eliminar debilidades de un solo punto

El término debilidad de punto único se refiere a la creación de redundancias en el sistema como un enfoque para mejorar la confiabilidad del sistema. La redundancia se crea al aumentar el número de sistemas o individuos involucrados en el proceso. Tener más sistemas de respaldo o más verificaciones (doble, triple o más) aumenta la probabilidad de que el proceso continúe correctamente.

Un gran ejemplo de esto es el "principio de los cuatro ojos", lo que significa que "todas las decisiones y transacciones comerciales necesitan la aprobación del CEO y CFO. Dado que el CFO no informa al CEO, existe un mecanismo de control independiente". .

^{fuente: https://en.wikipedia.org/wiki/Two-man_rule}

Hacer que los peligros sean obvios

Si los peligros se hacen obvios o imposibles de alcanzar, los humanos no pueden crear errores. Por ejemplo, la codificación de colores es un enfoque común para hacer que los errores sean más obvios. O si piensa en varios enchufes de computadora que solo se pueden insertar de una manera y no de la otra, etc.

Algunos grandes libros hablan sobre el tema, y ​​no sería una buena respuesta sin mencionarlos:

• La guía de campo para comprender el 'error humano' por Sidney Dekker
• Ingeniería de confiabilidad del sitio: cómo Google ejecuta los sistemas de producción
• Control de calidad cero: inspección de la fuente y el sistema Poka-Yoke por Shigeo Shingo

Como dijo @bradim, usar su herramienta CI / CD para iniciar la implementación en lugar de comandos basados ​​en la mano suele ser un buen paso adelante, al igual que agregar pruebas en su tubería que realmente prueben sus scripts de implementación en su entorno de preparación (o un entorno recién creado), donde Puedes recoger errores antes.

También agregaría que en lugar de llamar directamente a sus scripts de Ansible , también puede agregar herramientas como Ansible Tower en su flujo, lo que le permitirá rastrear los cambios que se han ejecutado más fácilmente y puede darle un paso adicional de seguridad en su fluir.