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


13

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 , 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)?


Você entrou em contato com uma equipe , o que significa que eles já devem ter abençoado o patch com relação aos princípios de aprovação em vigor. Eu realmente começar a odeio essas perguntas retóricas :( apenas a minha opinião, não se incomode com ele muito
Tensibai

@Tensibai, como é possível "abençoar algum patch" (ou consertar) antecipadamente, sem saber qual era a causa do problema quando "você foi contatado"? Além disso, você pode ser mais específico sobre a retórica? Não é um bom ajuste, algo mais?
Pierre.Vriens

Quero dizer, você diz que conseguiu entrar em contato com a equipe às 3:20, o que significa que não é só você que está tentando resolver o problema. Uso retórica como "caso hipotético, baseado na experiência ou não, onde você já sabe qual resposta está esperando". Mais ou menos minhas preocupações com a meta , sinto-me sozinha, não interessada por este Q / A de 'princípios genéricos', então provavelmente estou errada. O que tenho certeza é que não visitarei duas vezes uma pergunta / resposta sobre princípios genéricos se eu fosse um estranho dessa versão beta.
Tensibai

Eu posso dizer o mesmo sobre as questões genéricas Jenkins se eles estavam chegando agora
Tensibai

Os compromissos não serão computados até a versão beta pública. Por enquanto, em particular, estamos construindo o que os usuários 'comprometidos' consideram questões exemplares para este site, e acho que temos muito trabalho nos 12 dias restantes, ou talvez eu apenas tem que ir através do 7 fases de tristeza
Tensibai

Respostas:


8

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 ...


3

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.


Concordo com a sua recomendação, que parece ser semelhante à minha própria recomendação (resposta). Você pode pensar em algum exemplo no mundo do SCM com o qual você esteja familiarizado e como o implementaria lá? Se sim, você pode expandir isso em sua resposta?
Pierre.Vriens
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.