Quais são as boas práticas para distinguir o ambiente de produção de outros? [fechadas]

Question

Minha principal área de trabalho é a programação, e às vezes tenho que executar algumas ações em servidores de produção (ao implantar aplicativos ou configurar algo ...).

Então, minha pergunta é: o que deve ser feito para ter certeza de que não atrapalho algo no servidor de produção que pretendia fazer em meu ambiente de teste / máquina? Limpando algum banco de dados ou excluindo logs, por exemplo.

O que me vem à mente são algumas coisas básicas, como:

• ter o console de produção aberto por tanto tempo quanto necessário para fazer meu trabalho lá e, em seguida, fechá-lo
• configurar o console no servidor de produção para ser realmente diferente, em seguida, outros - como plano de fundo vermelho ou algo parecido
• ter cada comando requer uma confirmação adicional

Existem outras regras que ajudam a manter a integridade e a não bagunçar o servidor de produção?

    

Answer 1

Existe sempre uma linha tênue entre proteger dos erros e dificultar o trabalho. Embora eu seja um administrador dedicado, nossa organização é pequena o suficiente para que não seja prático implementar toda a sobrecarga e a burocracia que as grandes empresas gostam de manter sua produção segura.

Além das suas regras, também temos o seguinte:

• nunca use as mesmas credenciais para teste e produção (por exemplo, login, banco de dados), se você não puder arcar com os firewalls, coloque regras de descarte para erros comuns, ou seja, conectando ao backend de teste do frontend ao vivo, etc.
• implemente o máximo possível de gerenciamento de alterações / controle de versão, não apenas no nível do aplicativo, mas também no nível do sistema operacional. Aqui nós usamos cfengine, mas há muitas outras opções, ou seja, fantoche ou até mesmo crescer o seu próprio.
• automatize todas as tarefas de rotina, ou seja, você não deve excluir nada manualmente na produção regularmente
• mantenha uma documentação atualizada de tudo, não considere uma tarefa feita até que esteja documentada adequadamente, combine o wiki e o sistema de rastreamento de bugs. Tem que haver um "Porquê" para cada mudança e para cada esquisitice na configuração. Eu sei que isso soa como um Santo Graal, mas qualquer documentação é melhor que nada.

Answer 2

Use senhas diferentes : além do fato de que diferentes usuários podem ter acesso, você não pode fazer logon no banco de dados do sistema de produção (e fazer algo ruim ) pensando que é o banco de dados do servidor de teste se a senha não for a mesma.

Código de cores : o que também é uma boa ideia, porque é difícil de perder. Defina a cor do prompt da linha de comando de acordo com o nome do host e defina a cor de fundo da área de trabalho para acesso à GUI.

    

Answer 3

Meus métodos principais para fazer isso são como você disse, mudando a cor do fundo, mudando o layout, tornando-o significativamente diferente do servidor de desenvolvimento.

Outra coisa que você pode fazer é alterar a senha no servidor de produção para algo que você precisa pensar em inserir, dessa forma, você está consciente de que está efetuando logon no servidor de produção.

Outro método que vi usado em outras empresas é ter um método para promover o trabalho do desenvolvimento à produção, usando uma interface da Web ou script em lotes, para que você não trabalhe realmente no servidor de produção, mas apenas promova trabalhar quando estiver pronto.

    

Answer 4

Regra 1, se os desenvolvedores puderem acessar as coisas, não é um servidor de produção.

A execução do controle de versão apropriado (não apenas um VCS, mas a marcação correta) pode realmente ajudar aqui.

    

Answer 5

Uma coisa que vi implementada é usar um servidor de terminal "intermediário" entre sua rede operacional e sua rede de produção, portanto, quaisquer alterações devem ser feitas (para sistemas de produção) quando em uma sessão de serviços de terminal. Ao não fazer o mesmo com os sistemas de teste, a distinção é muito, muito clara.