Quais são as possíveis implementações (ou exemplos) do princípio dos quatro olhos?

Michael Grünewald postou recentemente este comentário :

Um método muito importante que você não menciona é o “princípio dos quatro olhos”, que é usado nas finanças - como uma obrigação regulatória ou como salvaguarda. Na indústria de software, ele é implementado de várias maneiras, como, por exemplo, revisões de código, mas também pode ser usado para validar comandos que afetam sistemas ativos.

Me corrijam se eu estiver errado, mas fui ensinado que o "princípio dos quatro olhos" é sobre algo "aprovado para acontecer", depois que pelo menos dois seres humanos (e / ou processos automatizados) deram sua benção prévia. Ou, para usar o texto (ligeiramente corrigido) sobre a "regra de dois (dois) homens" da Wikipedia :

A regra dos dois homens é um mecanismo de controle projetado para alcançar um alto nível de segurança para operações ou materiais especialmente críticos. Sob esta regra, todo acesso e ações requer a presença de duas pessoas autorizadas o tempo todo.

As obrigações regulatórias são, com certeza, fora de tópico aqui, mas no contexto de "salvaguarda", quais são as possíveis implementações conceituais desse princípio dos quatro olhos, que provavelmente poderiam se aplicar a qualquer plataforma / sistema operacional / hardware sendo usado?

Uma das implementações no código é o PR ( Pull Request Model ) popularizado pelo GitHub.

O principal raciocínio por trás disso é que apenas um pequeno conjunto de mantenedores do produto poderá mesclar código no ramo de lançamento. Cada novo recurso / correção de bug ocorrerá em uma nova ramificação e, uma vez concluído, será definido como uma solicitação de recebimento.

Isso permite testar a mesclagem do código de liberação (mestre) real com o código no PR de maneira automática (Travis é o mais popular para projetos públicos na verdade) e fornecer um primeiro feedback sobre a qualidade do código. O Travis CI (por exemplo) pode ser executado no resultado do mestre real com o código da solicitação pull mesclada a ele, portanto falhará se a mesclagem for impossível ou se os comandos definidos no travisci.yml retornarem uma saída diferente de zero código

Depois que os testes automáticos são aprovados, para o princípio dos 4 olhos, ainda é necessário um número configurável de pessoas para revisar e aprovar a alteração antes que ela seja mesclada, obviamente, pelo menos 1 pessoa (que não é o autor de RP) para aplicar 4 olhos revisando a alterar.

Há uma ampla variedade de opções para mesclar automaticamente quando o quorum de revisores for atendido ou ainda precisar de uma mesclagem manual por um mantenedor.

As permissões para revisar e mesclar podem ser separadas, o que ajuda a dar a mais pessoas o direito de "votar" no status da mesclagem, mantendo a possibilidade de restringir quem pode realmente fazer a mesclagem.

Revisões de código

Trata-se de ter pelo menos uma outra pessoa olhando o código escrito por alguém, por exemplo, para avaliar se ele atende a alguns critérios predefinidos, como:

• Padrões de codificação (recuos, etc).
• Documentação em linha.
• Manutenção do código.
• Tratamento de erros.
• Completude (por exemplo, if/then/elseou case/whenconstruções cobrem todos os casos possíveis).

Aprovações para atualizar alguns ambientes de destino

Trata-se de ter pelo menos duas confirmações de alguma pessoa e / ou sistema automatizado antes que seja permitido atualizar algum ambiente de destino (que pode estar ativo ou pode ser algo como algum arquivo mestre / biblioteca de linha de base). Alguns exemplos são:

• Somente um conjunto limitado de avisos é permitido ao transformar (criar) componentes de origem em componentes executáveis.
• Algum conjunto de testes automatizados deve ter sido concluído sem problemas.
• Alguns seres humanos devem ter indicado sua aprovação prévia (e sem isso, qualquer tentativa de atualizar os ambientes de destino falhará automaticamente).

Estas são estratégias / padrões em que consigo pensar:

Separação de serviço

DevOps, pelo menos a meu ver, não significa incorporar os desenvolvedores e os operadores em uma única pessoa. Portanto, ainda é possível separar o dever de forma que aquele que escreve o código (dev) não seja quem o executa (ops).

Por exemplo, se uma instrução SQL deve ser executada no ambiente ativo, uma grava a SQL e outra a executa. O que isso pressupõe é o que a execução precisa ter também um entendimento do SQL e não apenas a execução.

Implementar gatilho

Embora haja mérito para implantar continuamente. A equipe de um setor mais regulamentado pode nomear outra parte (separada) para acionar a implantação em vez de implantar automaticamente. Lista de verificação, testes automatizados, somas de verificação são possíveis verificações antes de iniciar a implantação.

Uma vez acionada, a automação pode prosseguir para executar a implantação.

Programação em pares

Pessoalmente, não citei essa técnica como um método para auditar a satisfação do princípio de verificação e equilíbrio. Mas potencialmente acho que pode ser uma estratégia.

AMF

Eu posso estar me alongando um pouco com este, mas é possível que, por algum motivo, você não queira entrada unilateral em um sistema, alguém possa manter a senha e outra pessoa manter o token ou dispositivo por um código de tempo. Portanto, 2 pessoas devem estar presentes para avaliar o sistema.