Que tipo de garantias que você usa para evitar que acidentalmente fazer mudanças inesperadas em seu ambiente de produção?

Question

Porque não temos um bom ambiente de teste muitas vezes temos de depurar problemas em nossos sistemas de produção. Temos web, aplicativos e servidores de banco de dados.

Que tipo de garantias que você usa para evitar que acidentalmente fazer mudanças inesperadas no ambiente de produção quando está fazendo isso?

---

EDIT:

O aplicativo é um muito complexo B2B aplicação web vertical. Existe uma grande quantidade de dados envolvidos. Algumas tabelas têm perto de 100 milhões de discos.

---

EDIT:

O ambiente de teste que temos em lugar não tem a capacidade de produção espelho. Há também centenas de gigabytes de arquivos de dados envolvidos além dos dados do banco de dados real.

---

EDIT:

Nós fazemos o controle de origem uso para o código, mas não para os procedimentos armazenados. Há alguns velhos procedimentos armazenados no controle de origem, mas ninguém mantém que mais atualizado.

As principais preocupações são o banco de dados e os dados no sistema de arquivos.

BTW, eu sou um consultor nesta empresa, e não um empregado real.

Answer 1

A resposta mais direta é: "Não faça isso"

Answer 2

controle de origem. nada como um rollback quando as coisas para irremediavelmente errada. Além disso, uma comparação pode ajudá-lo a replicar as alterações para outros sistemas de produção.

Answer 3

Novas versões de produção ir através de nossos sistemas de caras, os programadores e desenvolvedores só pode pedir para fazer seu novo sistema de ir ao vivo, é necessária a aprovação, bem como, e mostramos que cada alteração que foi feita foi testado (incluindo um instantâneo de tudo o que foi testado neste comunicado no pedido de produção).

Nós manter as versões anteriores de produção de fallback em caso de problemas.

Se as coisas pausa (que não deve fazer muitas vezes com um procedimento de teste adequada e lançamentos gerenciados) então nós pode back roll, ou correcção. Muitas vezes, quando as coisas estão quebrados em ao vivo e a correção é pequena, podemos correcção, em seguida, passar a correção para teste de fazer um teste adequado.

Independentemente disso, às vezes as coisas ficam por ...

Answer 4

só permitem que certas contas acesso de escrita, então você tem que logar-se de forma diferente de fazer uma mudança

no servidor web, tem duas estruturas de diretório, esse espelho um do outro, um onde apenas um ID pode escrever, o outro dir encenação, todos podem escrever.

no servidor de banco de dados, tem um db de produção, onde apenas um ID pode escrever, ter um db de teste onde todos podem escrever. a encenação DB pode ter backup noturno restaurada a ele.

No entanto, se você tiver um mau consulta ou algum recurso porco em seus recursos do sistema de preparo será puxado de produção, ea máquina poderia pendurar.

Answer 5

Para Web e servidores de aplicações, gostaria de tentar copiar o ambiente para um novo local (mas no mesmo ambiente) e ter as pessoas afetadas reproduzir o comportamento na cópia. Isto, pelo menos, dar-lhe um nível de separação de estragar acidentalmente com 100% de seus clientes.

Para os servidores de banco de dados, gostaria de configurar contas de usuário no sistema de produção para dar-lhes somente leitura direitos.

Answer 6

Read-Only / contas Visitante. Seriamente. É a mesma razão que você nem sempre login como raiz ou administrador.

Answer 7

Esta é uma coisa difícil, e vai com o território de "nenhum ambiente de teste."

Por muitas razões, é melhor ter um dedicado (duplicado) de PROD você pode usar para implanta palco para ... e para depuração, mas eu sei que às vezes, quando você está começando que não funciona tão rapidamente ou completamente quanto nós queremos.

Uma coisa que eu tenho visto de trabalho é o uso de VMs: além do ambiente de depuração, você pode criar um mini-PROD em uma máquina virtual e usar isso para depuração. Isto pode não ser prático dado o tipo de aplicativo que você está desenvolvendo, detalhe de modo adicional nessa área seria útil.

Como para evitar alterações ao PROD durante a depuração: há uma razão que você precisa mudar nada para facilitar a depuração? Se assim for, que pode valer a pena olhar para resolver de outra maneira.

Answer 8

O controle de versão é extremamente útil para controlar alterações para ambientes de produção - basta fazer o seu ambiente de produção de uma cópia de trabalho do diretório apropriado ou diretórios do repositório. Quando você lançar uma atualização, o sistema de controle de origem garante que todos os arquivos alterados são copiados. Quando uma atualização breaks algo, você pode rolar a cópia de produção funcionando de volta para a última revisão que não foi quebrado. Além disso, você pode verificar o seu WC produção para fora de uma tag em vez da partir do tronco; Dessa forma, você pode decidir qual revisões repositório para aplicar ao ambiente de produção, ajustando a tag.

Se você não estiver familiarizado com os conceitos de sistemas de controle de versão, eu aconselho que você faça alguma pesquisa. Eles são conceitualmente complexa, mas extremamente útil e poderosa. O artigo da Wikipedia é um bom lugar para começar: http://en.wikipedia.org/wiki/Revision_control

Answer 9

Sinto muito, você tem que ter um ambiente de teste. Não há como contornar isso. Se isso significa que você tem que abater o tamanho de seus conjuntos de dados, então é isso que você tem que fazer. Use VMware e conversor VMware para importar os sistemas de produção durante o down-períodos, se você tê-los (este é um processo muitas horas, talvez por isso não é prático).

Há uma certa classe de problemas que não consegue resolver sem ter pleno acesso a bancos de dados de produção (ou uma cópia), o desempenho é um desses. Mas você realmente deve construir um ambiente de teste, mesmo que seja na máquina desktop de alguém com um conjunto de dados simplificada.

Quanto ao resto, eu tive que viver minha vida com algumas delas no passado, e realmente, não há nada que você pode fazer, exceto lotes de backups. Toda mudança que você faz deve ser precedida de backups incrementais. Dessa forma, se você fubar'd alguma coisa, a quantidade que você perdeu não é substancial. servidor SQL pode fazer backups diferenciais que quantidade limite de espaço em disco utilizados para backups. A Oracle pode também.

Answer 10

No caso de você realmente não tem outra escolha, e é provável que seja uma situação crônica ... considerar a adição de alguma forma para os dados do aplicativo (arquivos ou banco de dados) para sinalizar um conjunto de dados como 'por favor, Deus, não realmente mudar ativamente estado de produção com esses dados', combinados com dados despeja em posições críticas em um processo quando este sinalizador é ativado, você pode ser capaz de exercer a maior parte da lógica de produção sem os dados realmente sendo postas em prática.