Estou sempre interessado em saber como as equipes de TI abordam o planejamento de mudanças na produção. Normalmente usamos runbooks para planejar as principais etapas de uma mudança, bem como planos de restauração. Estou ansioso para ver se podemos aprender com os outros e qual a melhor forma de documentar os runbooks.
Responder1
Prefiro roteiros com comentários e prints.
Eles têm uma dupla vantagem de documentação e automação.
Mas, adotando uma abordagem mais holística, geralmente há muitas coisas para rastrear,
o script é apenas para coisas que precisam ser feitas em sequência.
Quando há muitas notas envolvidas, prefiro um Wiki hospedado localmente (pessoalougrupo).
Pode ser usado para
- consulte suas ferramentas com links e escreva notas rápidas
- enumerar contatos e referências de escalonamento
- documentar etapas de emergência com base em palavras-chave
- locais de backup e sequências de recuperação
- hospedar um registro pesquisável de requisitos e soluções regulares; então as pessoas vêm até você depois de verificarem isso
Mas apenas mantenha o local seguro – você não quer que os dados fiquem inacessíveis em caso de emergência.
Aqui está um velhoRunbook do Microsoft Technet SQL Serverpágina para capturar ideias genéricas.
Responder2
O que eu faço:
Toda a configuração do servidor que precisa ser alterada em relação à linha de base do sistema operacional instalado é gerenciada pelo Chef, que é armazenada em módulos (chamados de livros de receitas), que são então armazenados no controle de versão via Git.
A maior parte da configuração 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 é mais ou menos assim:
- Crie um ticket no sistema apropriado informando que uma alteração precisa ser feita.
- Documente todos os porquês e o quê da mudança.
- Edite as receitas de configuração, modelos, arquivos, etc., necessários para que a alteração ocorra no sistema ou sistemas de destino.
- Confirme a alteração no repositório local e envie-a para o servidor mestre de controle de versão.
- Atualize o ticket para revisão por pares das alterações.
- As alterações são assinadas e implantadas no servidor Chef para que ele conheça os bits atualizados.
- Execute o Chef manualmente nos clientes ou deixe-o rodar automaticamente dependendo do requisito da mudança. (Eu não usaria, digamos, mais de meia dúzia de sistemas manualmente).
O modo de operação do Chef falhará se houver um problema ao executar o cliente, como se um pacote não existir, ou um arquivo de modelo não for encontrado, ou muitos outros problemas. Corrija o problema, documente no ticket e execute novamente o cliente.
A pessoa com o requisito comercial para a alteração verifica se ela foi bem-sucedida e fecha o ticket.
Específico do Chef porque é isso que eu uso. Substitua a ferramenta adequada para o seu ambiente, e se você não estiver usando uma ferramenta de gerenciamento de configuração, você precisa dar uma olhada em algo, pois torna todo esse processo muito mais robusto e confiável. Sem mencionar escalável.
Responder3
Para alterações realmente críticas e sensíveis, normalmente terei um arquivo de texto com os comandos reais que usarei com #comments explicando o que está acontecendo. Dessa forma, posso recortá-los e colá-los rapidamente em um terminal.
Responder4
Eu apoiaria a ideia básica por trás da postagem de jtimberman, com o fantoche sendo minha ferramenta preferida.