Como implementar o princípio dos quatro olhos para correções de emergência?

Considere este cenário (qualquer comparação com situações do mundo real é puramente acidental):

• 3:07 da manhã : chamada de suporte recebida " Algo na produção caiu, preciso da sua ajuda! ".
• 03:12 : conectado ao sistema (logon aceito) ... e sem tempo para tomar café.
• 03:15 : sorte a sua, imediatamente você poderá identificar o problema por meio de alguma mensagem de erro em algum lugar.
• 03:17 : use sua caixa de ferramentas do SCM para pegar o código, corrigir o problema, testá-lo, ótimo ... minha correção funciona!
• 03h20 : entrar em contato com o Dev Ops-time para enviar a correção e para obter a produção de correr novamente.
• 3:21 da manhã : bandeira vermelha ... " Para respeitar os quatro olhos , precisamos de mais 2 olhos para obter aprovação para essa correção ".
• 03:22 : ggggrrrreat, agora o que, para quem mais podemos ligar (= acordar algum gerente)?

Se você implementou algum procedimento de aprovação semelhante à minha resposta a " Quais são as possíveis implementações (ou exemplos) do princípio dos quatro olhos? ", Então você está sem sorte ... aqui estão suas escolhas:

• Sua correção ficará bloqueada (leia-se: a produção diminuirá) até que mais 2 olhos se envolvam.
• Você descobre uma maneira de contornar os olhos perdidos.

Então, como implementar o princípio dos quatro olhos para correções de emergência? ... Para que você inicie a produção o mais rápido possível, ou seja, por volta das 3:25 da manhã ... E para que você também possa encerrar a ligação (e voltar para a sua origem)?

No mundo do SCM, onde estou mais familiarizado, o cenário acima é normalmente abordado pelo que é chamado de " procedimento de lista de aprovação abreviada " .

Aqui está uma planta:

• Defina o horário comercial, por exemplo, das 8h às 18h.
• Definir uma completa lista de aprovação de (digamos) de 3 níveis de aprovação (para funções de X, Y e Z).
• Defina uma lista de aprovação abreviada de (digamos) apenas 1 nível de aprovação (apenas para as funções X).
• As mudanças planejadas sempre exigem todas as aprovações da lista completa de aprovações.
• Para alterações não planejadas , a lista completa de aprovações também é usada para reunir as aprovações necessárias, desde que as aprovações sejam emitidas durante o horário comercial definido.
• Para quaisquer aprovações de alterações não planejadas que devem ser emitidas fora do horário comercial definido:
  • Somente as aprovações da lista de aprovação abreviada (como a função X acima) são necessárias para autorizar a alteração. E após a autorização pela lista abreviada de aprovação, a implantação da alteração (no ambiente de destino) será efetivamente realizada.
  • Porém , serão necessárias pós- aprovações adicionais posteriormente (dentro de uma quantidade razoável de horas / dias), ou seja, de todas as funções contidas na lista de aprovação completa (como as funções Y e Z acima), que também não estão contidas na lista de aprovação abreviada (como a função X acima). E se dentro da quantidade acordada (inicial) de horas / dias nem todas as aprovações posteriores foram emitidas (por exemplo, porque a correção funcionou "desta vez", mas era apenas uma correção temporária), a alteração pode estar sujeita a uma reversão . Embora exista pelo menos 1 pós-aprovação pendente, a alteração é marcada como "aprovações de pós-espera".

Com essa solução, a chamada pode ser encerrada por volta das 3:23 da manhã ... já que não haverá mais bandeira vermelha às 3:21 da manhã ... ggggrrreat, hora de uma cerveja comemorar minha correção para dar continuidade à produção (em vez de café) ... e os dedos cruzaram as aprovações pendentes em breve chegarão em breve ...

No caso de correções de emergência fora do horário comercial, é mais prático exigir menos aprovação para alterações do que o procedimento normal. Geralmente, você pode implantar uma correção e fazer pós-aprovações no próximo dia útil. Se a correção não for aprovada, poderá ser revertida e substituída por uma solução permanente.

Durante uma situação de interrupção, a prioridade número um deve ser restaurar o serviço. Se sua organização não reconhecer esse processo relaxado durante uma interrupção, sim, sua única opção é começar a acordar mais pessoas para assinar.