Como proteger a implantação Ansible para mitigar acidentes?

Recentemente, o Amazon S3 teve uma grande interrupção na região leste-1. Parece que foi provavelmente causado por um erro de ortografia ao executar um manual de manutenção no Ansible ou em uma ferramenta semelhante. Você pode colocar um wrapper de script de shell em torno do ansible-playbook para se parecer com:

#!/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 "$@"

Mas, de que outras maneiras você pode usar para melhorar a segurança e reduzir a chance de erro, causando uma grande interrupção na sua empresa.

Estamos usando trabalhos em jenkins para acionar implantações. Ele garante que, independentemente de quem faça a implantação, o comando ansible executado seja o mesmo. Um bom bônus é o registro dos logs de construção quando as implantações foram acionadas, quem as acionou e o que exatamente aconteceu durante a implantação.

Certamente não é infalível, mas foi uma boa melhoria em relação à execução manual de manuais ansíveis.

Para mudanças maiores / mais arriscadas, idealmente, isso deve ser combinado com alguma forma de gerenciamento de mudanças, para que as mudanças sejam feitas somente depois que outra pessoa / equipe revisar a mudança e a abordagem da mudança para ajudar a identificar e resolver problemas potenciais com antecedência.

Além disso, nunca é demais ter um companheiro de equipe que entenda a mudança que você está fazendo estar presente e assistir enquanto você faz grandes mudanças, para que eles possam observar e ajudar a evitar erros na execução da mudança.

Categorias de erros

Existem duas maneiras de analisar os fatores humanos que levam a problemas e acidentes:

1. Você pode ver o erro humano como a causa de um acidente. Nesse caso, "erro humano", sob qualquer rótulo - perda de conhecimento da situação, violação de procedimentos, deficiências regulatórias, deficiências gerenciais é a conclusão de sua investigação.
2. Você pode ver o erro humano como sintoma de um problema mais profundo. Nesse caso, o erro humano é o ponto de partida para sua investigação. Você investigará como o erro humano está sistematicamente conectado aos recursos das ferramentas, tarefas e ambiente operacional / organizacional das pessoas.

O primeiro é chamado de abordagem humana e o segundo como abordagem de sistema .

Para explicar o fracasso usando a abordagem humana, você procuraria o fracasso e encontraria avaliações imprecisas das pessoas, decisões erradas ou julgamentos ruins.

Para explicar a falha usando a abordagem do sistema, você não está tentando descobrir onde as pessoas deram errado. Em vez disso, descubra como as avaliações e ações das pessoas faziam sentido na época, dadas as circunstâncias que as cercavam.

Por exemplo, Donald Berwick, do Institute for Healthcare Improvement (IHI), argumenta que melhorar a segurança do paciente requer mudanças no design dos sistemas :

... Nós somos humanos, e os humanos erram. Apesar da indignação, da tristeza, da experiência, dos nossos melhores esforços, dos nossos desejos mais profundos, nascemos falíveis e assim permaneceremos. Ser cuidadoso ajuda, mas não nos leva a lugar algum perto da perfeição ... O remédio está na mudança dos sistemas de trabalho. O remédio está no design. O objetivo deve ser de extrema segurança. Acredito que devemos estar tão seguros em nossos hospitais quanto em nossas casas. Mas não podemos alcançar esse objetivo por meio de exortação, censura, indignação e vergonha. Podemos alcançá-lo apenas com o compromisso de mudar, para que erros humanos normais possam ser cometidos irrelevantes para o resultado, continuamente encontrados e mitigados com habilidade.

Donald M. Berwick. De novo não! BMJ 2001

Removendo erros do sistema

Uma ótima maneira de encontrar (e corrigir) as várias maneiras pelas quais a falha ocorre após o fato é procurar a causa raiz sem culpar as pessoas. Isso geralmente é chamado de "post-mortems sem culpa", e o Etsy Code como postagem do blog do Craft expande esse conceito. As pessoas do Etsy apresentaram e escreveram mais sobre isso em outros fóruns e blogs.

Para evitar erros, em primeiro lugar, alguns traços culturais são obrigatórios. Os procedimentos e vários artefatos criados no sistema devem testar se o uso por humanos é muito claro e auto-explicativo. Muitas vezes, quem cria não é quem consome, levando a uma desconexão e falta de clareza. O sistema não é seguro para operar, pois a única pessoa que conhece todas as suposições é a pessoa que o criou (e mais ninguém).

Medidas eficazes de controle

Implemente medidas de controle eficazes para interromper o processo quando ocorrer um erro. Isso é à prova de erros. Medidas de controle eficazes são alterações no projeto que impedem ou impedem que os processos continuem quando ocorreu um erro ao introduzir uma falha no processo

Exemplo:

Em 1896, Sakichi Toyoda inventou o primeiro tear de força do Japão chamado “o tear de força Toyoda Steam”. Esse desenvolvimento aumentou a produtividade em vinte vezes e a qualidade dos têxteis melhorou e causou uma revolução na indústria têxtil no Japão. Mas aqui está a descoberta e o princípio sutil, mas muito importante:

quando a agulha quebrou, a máquina parou

Sakichi Toyoda criou uma inovação para o tear que mais tarde se tornaria um dos pilares do Sistema Toyota de Produção (Lean). O pilar que chamamos agora de Jidoka, às vezes chamado de "automação inteligente com um toque humano" ou "autonomação".

Em grande parte, Andon (parada no primeiro defeito) e Poka-Yoke (prova de erros) são desenvolvimentos posteriores que encontram sua influência no tear.

Remoção de pontos fracos de ponto único

O termo fraqueza de ponto único refere-se à criação de redundâncias no sistema como uma abordagem para melhorar a confiabilidade do sistema. A redundância é criada aumentando o número de sistemas ou indivíduos envolvidos no processo. Ter mais sistemas de backup ou mais verificações (dupla, tripla ou mais) aumenta a probabilidade de o processo prosseguir corretamente.

Um ótimo exemplo disso é o "princípio dos quatro olhos", que significa que "todas as decisões e transações de negócios precisam da aprovação do CEO e do CFO. Como o CFO não está se reportando ao CEO, existe um mecanismo de controle independente" .

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

Tornar os riscos óbvios

Se os riscos são óbvios ou impossíveis de serem alcançados, os seres humanos não podem cometer erros. Por exemplo, o código de cores é uma abordagem comum para cometer erros mais óbvios. Ou se você pensar em vários soquetes de computador que só podem ser inseridos de uma maneira e não da outra, etc.

Alguns ótimos livros estão falando sobre o assunto, e não seria uma boa resposta sem mencioná-los:

• O Guia de Campo para Entender o 'Erro Humano' de Sidney Dekker
• Engenharia de confiabilidade do site: como o Google executa sistemas de produção
• Controle de qualidade zero: inspeção de fonte e sistema Poka-Yoke por Shigeo Shingo

Como o @bradim disse, usar sua ferramenta de CI / CD para iniciar a implantação em vez de comandos manuais geralmente é um bom passo à frente, assim como adicionar testes ao seu pipeline que realmente testam seus scripts de implantação no ambiente de armazenamento temporário (ou em um ambiente recém-criado), onde você pode detectar erros mais cedo.

Eu também acrescentaria que, em vez de chamar seus scripts ansible diretamente, você também pode adicionar ferramentas como Ansible Tower ao seu fluxo, o que permitirá rastrear as alterações executadas com mais facilidade e fornecer uma etapa adicional de segurança ao seu fluxo.