Como posso, como desenvolvedor, ajudar os administradores de sistemas a melhorar as implantações de webfarm e a estabilidade de um aplicativo da web?

2

Problema:

A implantação e o gerenciamento deste site se tornaram um pesadelo. A implantação, do desenvolvimento ao controle de qualidade e à pré-produção, leva alguns dias. Temos muitos erros e isso envolve muito trabalho manual. Geralmente, temos arquivos de configuração que foram atualizados ou alterados incorretamente e, em seguida, todo o site nesse servidor da Web falha.

O ambiente:

  • Muitos servidores front-end da Web (Windows 2003, IIS6)
  • Muitos servidores MemCached (Linux)
  • Vários servidores de banco de dados (SQL 2005)
  • Aproximadamente 5 milhões exclusivos por mês

Mais detalhes:

Eu sou um dos desenvolvedores responsáveis pelo desenvolvimento do sistema. Atualmente, não há nenhuma automação, nenhum teste automatizado e o processo de implantação envolve o login nos servidores, com o servidor de terminal, e a alteração manual das configurações do IIS, a atualização de arquivos de configuração e horror semelhante. A documentação de recuperação de desastres deixa muito a desejar.

Gostaria de ativar a equipe que lida com as operações dos servidores para implantar e manter com êxito o aplicativo no qual estou trabalhando. Então, por razões em parte muito egoístas, quero que eles tenham sucesso.

Eu gostaria de alguma direção; sobre quais são as perguntas específicas que posso fazer, ou sugestões que posso fazer, sobre como os desenvolvedores podem criar coisas para ajudá-los a ter mais sucesso.

Atualmente, há um pouco de enlameado acontecendo, e eu acho que a única maneira de realmente consertar isso é ignorar o enlameado e focar no problema. E o problema atualmente é que é MUITO trabalhoso para manter, solucionar problemas e implantar o site.

Obrigado Rihan

    
por Rihan Meij 01.06.2009 / 12:01

7 respostas

5
  • Escreva o código que verifica a sanidade de qualquer configuração recebida e relate problemas diretamente para a pessoa que está fazendo a configuração e nos registros.

  • Faça uma separação clara entre os valores de configuração que são específicos do ambiente e aqueles que devem ser mantidos inalterados na sua rua Dev, Test, Acceptance, Prod (DTAP).

  • Use software de gerenciamento de versão (por exemplo, subversão) para rastrear alterações de configuração em todos os seus ambientes.

  • Gerencie a configuração de seus ambientes DTAP como um megalomaníaco.

  • Logo após você entregar uma versão, e antes de começar a codificar novamente, providencie para que o ambiente de produção seja copiado sobre todos os outros ambientes, incluindo o desenvolvimento. Quando você comunicar isso a seus colegas desenvolvedores, veja quais deles ficam brancos e pergunte a eles quais recursos eles não poderiam substituir à vontade do controle de origem.

  • O mais importante !!! Você provavelmente está lendo esse pensamento, quem é esse idiota? Isso é impossível! Nós não poderíamos fazer tudo isso. Morto certo - claro que você não pode - não agora. (Se você não estivesse em apuros, você não estaria fazendo a pergunta). Visão tão separada da implementação. Compartilhe essa visão com as outras partes interessadas. Decida em conjunto quais recursos você deve ter e faça um plano que comece a levá-lo até lá. Cada ciclo ou lançamento ou qualquer outra coisa, certifique-se de mover outro passo para mais perto da visão. Defina alvos realistas e encontre-os. (Claro, você pode mudar sua visão com base na experiência à medida que avança.)

por 01.06.2009 / 13:19
2

Eu diria que, além de manter as configurações do servidor e os arquivos de configuração iguais, você deve ter ambientes de teste para implantar em seu escritório. Se seus desenvolvedores testarem que o código desenvolvido por eles funciona em um ambiente muito parecido com um ambiente ao vivo, eles se sentiriam mais confiantes. Mais confiança significa que eles necessariamente se desenvolvem mais rápido (já que isso é algo que aprendemos com nossas equipes SCRUM) e muito menos enlameado e com sentimento de não estar no controle.

Então, basicamente, o que estou dizendo é: basta dar aos desenvolvedores muitas máquinas para jogar e testar e você verá resultados positivos.

    
por 01.06.2009 / 13:19
1

A etapa mais importante é uma maneira simples de tornar a configuração de todos os servidores da sua infraestrutura o mais consistente possível. Um Ambiente Operacional Padrão (SOE), se você quiser:

  • Todas as instâncias do IIS têm configuração idêntica.
  • Todos os servidores da web têm a mesma cópia do site neles.

Depois de ter isso, é muito mais fácil implementar implementações automatizadas, testes e assim por diante.

Se a configuração do IIS for idêntica em todos os servidores, você poderá atualizar o arquivo de configuração que o IIS usa em um servidor mestre e executar um script para enviá-lo para todos os servidores da Web, testá-lo e recarregar o IIS. Você pode fazer o mesmo com seus arquivos de sites reais.

    
por 01.06.2009 / 12:26
1

Meu palpite é que, se você tivesse a opção de padronizar os servidores para os quais você vai implantar, você já teria feito isso, então vou pular essa sugestão. O que você precisará fazer é criar scripts / MSIs, etc., para automatizar o processo de implantação da equipe de operações. Levará algum tempo para a configuração, mas remover a intervenção manual da equipe de operações do processo é a única maneira de executá-la sem problemas. Agora não estou insultando a inteligência deles, longe disso. O problema é que eles não sabem como o código funciona. Eles não sabem como será um arquivo de configuração com um valor ruim. Eles dependem de você saber que para ajudá-los e a razão pela qual a automação é fundamental para resolver o seu problema.

Minha sugestão seria configurar localmente máquinas virtuais que imitem os vários servidores, para que você possa testar repetidamente como a instalação irá funcionar. Se o seu departamento de TI for parecido com o meu, obter novos servidores será difícil, pois envolve orçamento e alocação de recursos etc. As máquinas virtuais removem grande parte da dor de cabeça, já que você não precisa de novo hardware, e a contribuição de qualquer pessoa será mínima Como você só precisa saber como os servidores estão configurados e, em seguida, você provavelmente pode fazer o resto sozinho. As VMs também permitem que você redefina rapidamente a máquina para seu estado original e tente o processo de instalação novamente.

    
por 01.06.2009 / 14:13
1

Na minha infraestrutura, temos um ambiente de preparação chamado preview, no qual os dados vão antes de chegar à produção. O código do aplicativo no nível de preparação é exatamente o mesmo que o código de produção, portanto, quaisquer problemas de dados serão mostrados lá.

Também temos um ambiente de teste para o novo código, que opera em dados antigos e em bom estado (que podemos manipular quando necessário para testar como o código falha).

De modo geral, essa segregação nos permite ter um ambiente de produção bastante sólido, e não vemos muitas coisas inesperadas surgindo.

Devo notar que não lidei muito com isso, já que não sou programador. Eu apenas sincronizo os bancos de dados e atualizo os arquivos quando eles me pedem; -)

    
por 01.06.2009 / 14:27
0

Primeiramente, a CONSISTÊNCIA. Certifique-se de que todos os seus servidores sejam exatamente iguais. Todos os servidores da Web W2003 devem se parecer com o resto. Todos os servidores de banco de dados, todos os servidores Linux. Quero dizer mesmo . Mesma versão do SO, os mesmos patches, a mesma estrutura de diretórios ... Tudo!

Em segundo lugar vem a encenação. Você deve ter um servidor separado de cada tipo, que pode ser usado para testar sua implantação. É aqui que você comete todos os erros de configuração. Você então copiaria seu sistema desses servidores de implantação para produção.

Terceiro, o conceito "Separação de preocupação" deve ser aplicado aos seus arquivos de configuração. Se módulos diferentes tiverem itens de configuração diferentes, coloque-os em seu próprio arquivo de configuração. Se houver configuração específica da máquina, mova a TI para seu próprio arquivo de configuração. Dessa forma, você pode implantar os arquivos de configuração afetados do servidor de implantação junto com os próprios componentes.

    
por 01.06.2009 / 13:00
0

Uma palavra: backups

Verifique se eles têm backups bons, centralizados, redundantes e consistentes.

    
por 01.06.2009 / 15:06