Alguém tem bons exemplos de runbooks que eles usam quando fazem mudanças de produção?

2

Estou sempre interessado em como as equipes de TI abordam o planejamento das mudanças na produção. Normalmente, usamos runbooks para planejar os principais passos de uma mudança, bem como planos de reversão. Eu estou ansioso para ver se podemos aprender com os outros e como melhor documentar os runbooks.

    
por nik 10.07.2009 / 23:17

4 respostas

1

O que eu faço:

Toda a configuração do servidor que precisa ser alterada da linha de base do SO instalada é gerenciada pelo Chef, que é armazenado em módulos (chamados de livros de receitas), que são armazenados no controle de versão por meio do Git.

A maioria das configurações foi feita manualmente em um sistema de teste (geralmente uma imagem de VM ou simplesmente uma instância do EC2) e, em seguida, uma receita de configuração escrita para cobrir todos os vários componentes das alterações. A atualização do fluxo de trabalho do ambiente é algo assim:

  • Crie um ticket no sistema apropriado que uma alteração precisa ser feita.
  • Documente todos os porquês e o que acontece com a mudança.
  • Edite a (s) receita (s) de configuração, modelos, arquivos, etc, necessários para que a mudança ocorra no sistema ou sistemas de destino.
  • Confirme a alteração no repositório local e envie para o servidor de controle de versão principal.
  • Atualize o ticket para revisão por pares das alterações.
  • As alterações são assinadas e a alteração é implantada no servidor Chef para que ele saiba sobre os bits atualizados.
  • Execute o Chef manualmente em clientes ou deixe-o rodar automaticamente dependendo do requisito da mudança. (Eu não diria mais do que meia dúzia de sistemas à mão).

O modo de operação do Chef é falhar se houver um problema ao executar o cliente, como se um pacote não existisse ou um arquivo de modelo não fosse encontrado ou muitos outros problemas. Corrija o problema, documente no ticket e execute novamente o cliente.

A pessoa com o requisito de negócios para a alteração verifica se foi bem-sucedida e fecha o ticket.

Chef específico, porque é isso que eu uso. Subsulte a ferramenta apropriada para o seu ambiente e, se você não estiver usando uma ferramenta de gerenciamento de configuração, precisará examinar algo, porque isso torna todo esse processo muito mais robusto e confiável. Sem mencionar escalável.

    
por 11.07.2009 / 09:29
1

Eu prefiro scripts com comentários e impressões.
Eles têm uma dupla vantagem de documentar e automatizar.

Mas, adotando uma abordagem mais holística, geralmente há muitas coisas para acompanhar,
o script é apenas para coisas que precisam ser feitas em uma sequência.

Quando há muitas notas envolvidas, eu prefiro um Wiki localmente hospedado ( pessoal ou group )

Pode ser usado para

  1. consulte suas ferramentas com links e escreva notas rápidas
    • enumerar contatos e referências de escalonamento
    • documente etapas de emergência com base em palavras-chave
    • locais de backup e sequências de recuperação
    • hospeda um registro pesquisável de requisitos e soluções regulares; então as pessoas vêm até você depois de terem verificado isso

Mas mantenha a localização segura - você não quer que os dados fiquem inacessíveis em uma emergência.

Esta é uma antiga página de runbook do Microsoft Technet SQL Server para captar ideias genéricas.

    
por 11.07.2009 / 10:43
0

Para mudanças realmente críticas e sensíveis, normalmente terei um arquivo de texto com os comandos reais que eu usarei com #comments explicando o que está acontecendo. Dessa forma, posso recortá-los e colá-los em um terminal rapidamente.

    
por 11.07.2009 / 00:20
0

Eu seria a segunda idéia básica do post do jtimberman, com o boneco sendo minha ferramenta de escolha.

    
por 11.07.2009 / 11:01

Tags