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

22

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?

Pierre.Vriens
fonte

Respostas:

11

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.

Tensibai
fonte
Verifique a edição menor de sua resposta (erros de digitação). Se você não gostar, basta reverter ou reeditar, ok? Além disso, eu não tinha pensado nesses PRs, então com certeza acho muito aplicável. Vou marcar esta resposta como aceita (eu "aprendi" algo com ela, as coisas em minha própria resposta que eu sabia, é claro). Embora não garanta no futuro, posso mudar de idéia (inaceitável) caso uma resposta ainda melhor seja publicada. About: "Isso permite testar a mesclagem do código de release (mestre) real com o código no PR de maneira automática", não entendi, devo postar uma nova pergunta?
Pierre.Vriens
@pierre, você pode mudar de idéia quantas vezes quiser :) Para o teste do código proposto, o Travis CI (por exemplo) pode ser executado no resultado do mestre real com o código de solicitação pull incorporado nele, portanto falha se a mesclagem for impossível ou se os comandos definidos no travisci.yml retornarem um código de saída diferente de zero. FWIW, pesquisando som a melhor abordagem IMHO, o assunto é grande
Tensibai
@pierre e para a edição, apenas um ponto, o princípio de 4 olhos é ter mais 1 pessoa para revisar, o que significa que 2 pessoas viram a alteração (o autor não a revisou), daí o singular no número variável de pessoas ( como poderia ser apenas um, e em francês talvez apenas um seja singular: p). Não sou tão fluente em inglês quanto gostaria de ser, mas acho que o primeiro ponto é válido (2 leitores, 2
viram
aha, é isso que você quer dizer, agora entendi (e tomei a liberdade de copiar / colar o esclarecimento extra na sua resposta). BTW: ex a mple (EN), não ex e mple (como em FR) ...
Pierre.Vriens
@ Pierre.Vriens culpar o auto correto com a linguagem dupla :)
Tensibai
9

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).
Pierre.Vriens
fonte
6

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.

kenchew
fonte
Merci por essas variações interessantes! Nunca ouvi falar dessa "programação em pares" antes, isso realmente parece uma variação de tocar piano com "4 mãos"!
Pierre.Vriens
1
Recentemente, entrevistei uma empresa que faz a forma mais intensiva de programação em pares que já vi. Eles tinham configurações de "pod" com duas máquinas, cada uma com um monitor dedicado e um monitor compartilhado. Todo o desenvolvimento foi feito em pares. Não é para todos, mas, segundo todos os relatórios, funciona bem para eles.
23817 Dave Swersky