Uma parcela grande das quedas sérias não são ataques nem falhas de hardware. São mudanças: uma configuração editada sob pressão de tempo, uma atualização que saiu do trilho, um certificado trocado com a cadeia errada, uma regra de firewall que bloqueou mais do que se pretendia. A parte incômoda é que estas são as quedas que você mesmo causa, o que significa que também são as que um pouco de estrutura previne. A estrutura é um runbook, e um bom runbook trata menos da mudança e mais de tudo o que a envolve: o que você confirmou antes de tocar em qualquer coisa, como se moveu, que sinal o faria parar e se o caminho de volta era um procedimento escrito em vez de uma decisão tomada sob pressão.
O plano é principalmente o que acontece antes e depois da mudança
O comando que de fato faz a mudança costuma ser a menor parte de um bom runbook. A maior parte do valor está no pré-voo e no encerramento. Antes de começar, três coisas merecem seu lugar toda vez: um escopo escrito (exatamente o que está mudando, em quais sistemas e a janela precisa), um backup fresco de tudo que você vai tocar e que você confirmou ser legível, e um baseline de saúde capturado agora, para que "funcionando" tenha uma definição com a qual comparar depois. O backup é o que as pessoas pulam quando estão confiantes, e é o que transforma uma mudança ruim de incidente em inconveniência. Um backup que você não abriu é uma esperança; faça-o e confirme que ele restaura antes de depender dele.
O encerramento importa por um motivo mais sutil. Quando a mudança dá certo, a nova configuração é o estado bom — então persista-o e faça um backup fresco dele, porque a próxima pessoa a fazer rollback deve voltar para este estado, não para o anterior à sua mudança. Fechar o chamado com o que de fato aconteceu, incluindo qualquer desvio do plano, é o que faz a próxima mudança neste sistema partir da verdade em vez da memória de alguém.
A reversibilidade decide o quanto o plano se apoia na prevenção
Nem toda mudança é igualmente recuperável, e o runbook deve ser moldado por qual tipo você tem. Uma mudança facilmente reversível pode se dar ao luxo de andar rápido e se apoiar no rollback se algo parecer errado. Uma mudança difícil de reverter, ou uma porta sem volta genuína sem nenhum rollback limpo, inverte toda a postura: a prevenção passa a ser a rede de segurança, porque o retorno não é. Isso significa mais verificação antes de começar e durante, uma mão mais lenta nos passos irreversíveis, e um plano acordado de correção para a frente para o caso de algo quebrar e voltar não ser uma opção. A combinação mais perigosa em operações é uma mudança sem volta em produção crítica durante o horário comercial, e é perigosa justamente porque cada um desses fatores remove uma camada de segurança de uma vez.
É também por isso que um rollback não testado merece desconfiança. Um retorno que está escrito mas nunca foi exercitado é uma forma comum de descobrir, no pior momento possível, que a restauração não funciona de fato — o backup estava incompleto, uma dependência foi esquecida, os passos documentados pulam algo que todos presumiam. Se uma mudança não é fácil de reverter, o rollback merece um teste antes da janela, não durante o incidente.
Sequencie para conter o raio de impacto
Como você percorre a mudança decide o quão grande um erro se torna. O instinto sob pressão é aplicar a mudança em tudo de uma vez e terminar logo; a disciplina é o oposto. Trabalhe em incrementos pequenos e reversíveis onde puder, e depois de cada um, pare para confirmar que fez o que você esperava antes de continuar. Em qualquer coisa com mais de um nó — um pool balanceado, um par de HA, um cluster — mude um membro primeiro, verifique ali, e só então propague para o resto, de modo que uma mudança ruim custe um membro em vez do serviço. Onde um equipamento carrega sessões vivas, drene-o antes de tocá-lo em vez de derrubar conexões ativas. O raio de impacto não é só uma propriedade da mudança; é uma propriedade de como você a sequencia, e um bom sequenciamento transforma uma queda em potencial num passo contido e observado.
Certos tipos de mudança carregam suas próprias arestas afiadas que vale nomear no plano. Uma rotação de certificado quebra todos os clientes de uma vez se a chave e a cadeia estiverem erradas, então o material é preparado e verificado offline antes de instalar qualquer coisa, e o handshake é testado de ponta a ponta depois. Uma mudança de DNS não tem efeito instantâneo; ela se propaga ao longo do (tempo de vida, do inglês time to live) do registro, então a resposta antiga permanece em caches e um erro não é desfeito no momento em que você corrige o registro — o que significa que cronometrar a mudança em torno do TTL, e reduzi-lo antes de um corte, faz parte do plano.
Decida o que o faria parar antes de começar
A linha mais valiosa de um runbook é o gatilho de rollback, e ele precisa estar escrito antes da mudança, não improvisado durante ela. Sob pressão, com uma mudança pela metade e algo parecendo errado, a tentação de seguir "só mais um passo" é forte e geralmente errada. Um gatilho decidido de antemão — uma taxa de erro específica, uma sonda de saúde falhando, um tempo decorrido sem sinal de sucesso — converte esse momento de um julgamento sob estresse num procedimento que você já concordou em seguir. Combine-o com os passos de retorno escritos explicitamente, e o rollback deixa de ser uma decisão e vira uma lista. Para uma mudança de alto impacto, nomeie também os papéis: quem executa a mudança, quem observa o monitoramento e quem toma a decisão de rollback, para que, quando o gatilho disparar, não haja debate sobre de quem é a decisão.
Nada disso substitui o processo de aprovação de mudança, o suporte do fornecedor ou a sua própria revisão de produção, e um runbook não é uma aprovação — ele não torna uma mudança segura, ele torna uma mudança organizada. O que ele traz é mais restrito e real: uma mudança que tem escopo, é sequenciada, reversível onde pode ser, e observada, com um caminho de volta escrito que alguém testou. O Construtor de Runbook de Janela de Mudança neste site codifica isso como um montador determinístico — descreva a mudança, receba um runbook em fases com os riscos que carrega e ressalvas de prontidão sobre o que você ainda não fez — justamente para que o plano exista no papel antes de a janela abrir, e para que uma pessoa o revise e execute em vez de confiar que ele funcione sozinho.