Qui est responsable de la maintenance d'IIS pour les applications Web?

IIS / Applications Web a été un problème délicat dans les magasins dans lesquels j'ai travaillé au fil du temps.

D'une part, IIS est un service intégré au serveur (en gros) et est généralement la responsabilité des administrateurs du serveur de maintenir et de configurer. Lorsqu'un problème survient, ils savent ce qui doit arriver, ou peuvent au moins diagnostiquer au point où ils disent: «Quelque chose ne va pas avec l'application Web» et demander au développeur de déboguer leur code.

Cependant, chaque application Web sur le serveur est unique et comporte de nombreuses nuances qui peuvent être complexes en fonction des problèmes rencontrés.

D'un autre côté, chaque application Web est unique à bien des égards et avait des problèmes spécifiques qui doivent être traités et le développeur est la personne qui en sait le plus sur l'application. Si le fichier web.config doit être modifié pour le débogage, ou qu'un IIS commence à gêner l'application Web, le développeur doit savoir où se situe le problème et le résoudre en conséquence, soit en raison d'IIS ou de l'application elle-même.

Cependant, permettre à un développeur d'entrer et de modifier lui-même IIS devient un problème grave car certains paramètres / optimisations peuvent sérieusement perturber les performances et la stabilité du serveur.

Alors, où est l'équilibre? Les administrateurs de serveur doivent-ils être des gourous IIS et gérer tous ces problèmes et j'envoie simplement les fichiers de site au cours du déploiement, ou le développeur doit-il assumer la responsabilité des problèmes de serveur et d'IIS et les traiter en conséquence?

On dirait que ce dont vous avez vraiment besoin, c'est d'une personne compétente des deux côtés de la clôture.

D'après mon expérience (avec des entreprises de plus petite taille), le personnel informatique / administrateur système n'a pas le temps, l'intérêt ou les connaissances spécifiques aux applications Web pour maintenir correctement les configurations IIS. Ils iront jusqu'au système d'exploitation et me remettront IIS, le développeur.

De toute évidence, je dois être "plus qu'un simple codeur" pour que cela fonctionne correctement; Je dois être conscient des problèmes au niveau du système (sécurité et ainsi de suite). Je fais de la gestion de systèmes de bas niveau depuis des années, donc je suis confiant avec ce genre de tâche (en fait, j'ai enseigné quelques choses aux administrateurs système professionnels au fil des ans). Cependant, tous les développeurs n'ont pas cette capacité.

Pourtant, d'après ce que j'ai vu, il y a plus de développeurs avec des compétences sysadmin que des sysadmin avec des compétences de développement (webapp).

Comme toujours, YMMV.

Personnellement, je ne voudrais pas qu'un développeur dérange IIS, surtout si cela signifie que cela pourrait causer des problèmes avec une autre application avec un autre développeur devant dépanner, encore et encore.

S'il y a des problèmes IIS, demandez à SysAdmin de l'examiner et s'il y a un problème avec une application particulière, renvoyez-le au développeur. Si le développeur a un problème, signalez-le au SysAdmin, qui peut alors tenter de prendre une décision éclairée quant à l'opportunité d'apporter des modifications et de comprendre comment cela affectera tout le monde.

Nous (les administrateurs système) traitons nos développeurs comme nous le ferions pour un fournisseur tiers - lorsqu'ils veulent que nous déployions une application, ils doivent fournir de la documentation s'ils s'attendent à ce qu'elle soit prise en charge. Cela inclut des routines de dépannage courantes et un chemin d'escalade de support (exigences de disponibilité combinées avec une responsabilité documentée du développeur dans le cas d'une panne inacceptable).

Ce n'est évidemment pas noir et blanc, mais cela a beaucoup fait pour atténuer la tension entre les développeurs et les administrateurs. Les développeurs réalisent maintenant qu'ils doivent fournir des logiciels d'une qualité inversement proportionnelle à leur volonté d'être paginés après les heures, et les développeurs ont maintenant des outils et des documents à parcourir sans se sentir accrochés aux outils qu'ils n'ont pas créés.

Ainsi, dans votre scénario, cela signifierait que les développeurs créent leur application sur leur propre serveur IIS, puis fournissent le logiciel et la documentation que les administrateurs doivent installer sur le serveur de production.

Les administrateurs de serveur doivent-ils être des gourous IIS et gérer tous ces problèmes et j'envoie simplement les fichiers de site au cours du déploiement, ou le développeur doit-il assumer la responsabilité des problèmes de serveur et d'IIS et les traiter en conséquence?

Réponse: trouvez une personne et annotez-la "WSA" (Administrateur de serveur Web) . Il peut s'agir d'un administrateur ou d' un développeur; ça n'a vraiment pas d'importance. Mais ils doivent s'immerger dans les deux aspects du travail, et le reste de l'équipe (des deux côtés) doit respecter leur expertise.

Ce n'est pas différent de la façon dont les administrateurs de base de données chevauchent la ligne entre l'informatique et le développement. Étant donné l'importance des serveurs Web dans une organisation dotée d'un produit Web, je pense que c'est un rôle essentiel, et souvent négligé.

Étant donné que le Web est encore jeune (par rapport aux bases de données), il est difficile de recruter cette personne. Vous aurez très probablement besoin de faire grandir / préparer quelqu'un dans ce rôle.

Avec de nouveaux utilitaires tels que l' outil de déploiement Web (qui deviendra le moyen intégré standard de publier une application Web à partir de Visual Studio 2010), Microsoft semble s'orienter vers la voie permettant aux développeurs ou au moins aux ingénieurs d'installation de choisir des éléments comme les paramètres IIS ( certificats, paramètres du pool d'applications, etc.). Ils sont intégrés au package d'installation msdeploy et automatiquement appliqués au serveur IIS lorsque le package est déployé sur les serveurs.

On dirait un compromis raisonnable. Les développeurs n'effectuent pas manuellement le nettoyage des paramètres sur les serveurs de production en direct, et les administrateurs système n'ont pas besoin d'avoir les connaissances spécifiques aux applications Web. Et pourtant, les paramètres IIS souhaités sont clairement visibles pour les administrateurs système qui souhaitent comprendre ce qui va se passer avant l'installation du package.