Quem é responsável por manter o IIS para aplicativos da web?

Aplicativos IIS / Web tem sido um problema complicado nas lojas em que trabalhei ao longo do tempo.

Por um lado, o IIS é um serviço incorporado ao servidor (em geral) e geralmente é de responsabilidade dos administradores do servidor manter e configurar. Quando surge um problema, eles sabem o que precisa acontecer ou podem, pelo menos, diagnosticar até o ponto em que dizem "Algo está errado com o aplicativo Web" e pedir ao desenvolvedor que depure seu código.

No entanto, cada aplicativo Web no servidor é único e possui muitas nuances que podem ser complexas com base nos problemas em questão.

Por outro lado, cada aplicativo Web é único em muitos aspectos e possui problemas específicos que precisam ser tratados, e o desenvolvedor é a pessoa que mais conhece o aplicativo. Se o arquivo web.config precisar ser modificado para depuração, ou se o IIS começar a incomodar o aplicativo Web, o desenvolvedor deve saber onde está o problema e corrigi-lo adequadamente, devido ao IIS ou ao próprio aplicativo.

No entanto, permitir que um desenvolvedor entre e ajuste o IIS por conta própria torna-se um problema sério, porque algumas configurações / otimizações podem prejudicar seriamente o desempenho e a estabilidade do servidor.

Então, onde está o equilíbrio? Os administradores do servidor devem ser gurus do IIS e lidar com todos esses problemas e simplesmente envio os arquivos do site durante a implantação ou o desenvolvedor deve assumir a responsabilidade pelos problemas do servidor e do IIS e lidar com eles de acordo?

Parece que você realmente precisa de alguém com experiência nos dois lados da cerca.

Na minha experiência (com empresas de menor porte), a equipe de TI / administrador de sistemas não tem tempo, interesse ou conhecimento específico de aplicativos da web para manter adequadamente as configurações do IIS. Eles levarão as coisas até o sistema operacional e entregarão o IIS para mim, o desenvolvedor.

Obviamente, eu preciso ser "mais do que apenas um codificador" para fazer isso funcionar corretamente; Eu tenho que estar ciente dos problemas no nível do sistema (segurança e outros enfeites). Eu pratico gerenciamento de sistemas de baixo nível há anos, por isso estou confiante com esse tipo de tarefa (de fato, ensinei alguns administradores de sistemas profissionais algumas coisas ao longo dos anos). No entanto, nem todo desenvolvedor tem esse recurso.

Ainda assim, pelo que vi, há mais desenvolvedores com habilidades em sysadmin e há habilidades em desenvolvimento com sysadmin (webapp).

Como sempre, YMMV.

Pessoalmente, eu não gostaria que um desenvolvedor mexesse com o IIS, especialmente se isso significasse que ele poderia causar problemas em outro aplicativo, com outro desenvolvedor precisando solucionar problemas continuamente.

Se houver problemas no IIS, faça com que o SysAdmin verifique e, se houver um problema com um aplicativo específico, envie-o de volta ao desenvolvedor. Se o desenvolvedor tiver um problema, leve-o ao SysAdmin, que poderá tentar tomar uma decisão informada sobre se deve fazer alguma alteração e descobrir como isso afetará a todos.

Nós (os administradores de sistemas) tratamos nossos desenvolvedores da mesma forma que trataríamos com um fornecedor de terceiros - quando eles querem que implantemos um aplicativo, eles precisam fornecer documentação se esperam que ele seja suportado. Isso inclui rotinas comuns de solução de problemas e um caminho de escalação de suporte (requisitos de tempo de atividade combinados com uma responsabilidade documentada do desenvolvedor no caso de uma interrupção inaceitável).

Obviamente, não é preto e branco, mas foi feito muito para aliviar a tensão entre desenvolvedores e administradores. Os desenvolvedores agora percebem que precisam fornecer software de qualidade inversamente proporcional à sua disposição de serem paginados após o expediente, e os desenvolvedores agora têm ferramentas e documentos a serem seguidos sem se preocupar com as ferramentas que não criaram.

Portanto, no seu cenário, isso significaria que os desenvolvedores criassem o aplicativo em seu próprio servidor IIS e fornecessem o software e a documentação para os administradores instalarem no servidor de produção.

Os administradores do servidor devem ser gurus do IIS e lidar com todos esses problemas e simplesmente envio os arquivos do site durante a implantação ou o desenvolvedor deve assumir a responsabilidade pelos problemas do servidor e do IIS e lidar com eles de acordo?

Resposta: encontre uma pessoa e anote-a "WSA" (administrador do servidor Web) . Eles podem ser um administrador ou desenvolvedor; isso realmente não importa. Mas eles precisam mergulhar nos dois aspectos do trabalho, e o restante da equipe (dos dois lados) precisa respeitar seus conhecimentos.

Não é diferente de como os DBAs estão na linha entre TI / dev. Dada a importância dos servidores da Web em uma organização com um produto baseado na Web, acho que essa é uma função crítica e muitas vezes esquecida.

Como a web ainda é jovem (em comparação com os bancos de dados), é difícil recrutar esse indivíduo. Você provavelmente precisará cultivar / preparar alguém para o cargo.

Com novos utilitários, como a Web Deployment Tool (que se tornará a maneira padrão interna de publicar um aplicativo Web a partir do Visual Studio 2010), a Microsoft parece estar caminhando para permitir que desenvolvedores ou pelo menos engenheiros de instalação escolham coisas como as configurações do IIS ( configurações do pool de aplicativos etc.). Eles são incorporados ao pacote de instalação msdeploy e aplicados automaticamente ao servidor IIS quando o pacote é implantado nos servidores.

Parece um compromisso razoável. Os desenvolvedores não mexem manualmente nas configurações dos servidores de produção ao vivo, e os administradores de sistemas não precisam ter o conhecimento específico de aplicativos da web. E, no entanto, as configurações desejadas do IIS são claramente visíveis para os administradores de sistema que desejam entender o que acontecerá antes da instalação do pacote.