Comment puis-je, en tant qu'administrateur, aider les administrateurs de système à améliorer les deployments de files Web et la stabilité d'une application Web?

Problème:

Le deployment et la gestion de ce site sont devenus un cauchemar. Le deployment, allant du développement au QA, et la pré production, prend quelques jours. Nous avons beaucoup d'erreurs, et cela implique beaucoup de travail manuel. Nous avons souvent des files de configuration qui ont été mis à jour ou modifiés de manière incorrecte, et l'set du site sur ce server Web échoue.

L'environnement:


  • Beaucoup de servers frontaux Web (Windows 2003, IIS6)
  • Beaucoup de servers MemCached (Linux)
  • Plusieurs servers de database (SQL 2005)
  • 5 millions d'euros par mois

Plus de détails:

Je suis l'un des développeurs responsables du développement du système. Actuellement, il n'y a pas d'automation, de zéro test automatisé et le process de deployment implique de se connecter aux servers, avec le server de terminal, et à modifier manuellement les parameters IIS, mettre à jour les files de configuration et les horreurs similaires. La documentation sur le rétablissement des catastrophes laisse beaucoup à désirer.

J'aimerais permettre à l'équipe qui gère les opérations des servers, à déployer et à gérer avec succès l'application sur laquelle je travaille. Donc, pour des raisons partiellement très égoïstes, je veux qu'ils réussissent.

J'aimerais avoir une certaine direction; En ce qui concerne les questions spécifiques, je peux leur requestr, ou des suggestions que je peux faire, sur la façon dont, en tant que développeurs, nous pouvons créer des choses pour les aider à réussir.

À l'heure actuelle, il y a un peu de boue, et je trouve la seule façon de régler vraiment, c'est ignorer la boue et se concentrer sur le problème. Et le problème actuellement est qu'il est très important de conserver, de dépanner et de déployer le site.

Merci Rihan

  • Écrivez un code qui vérifie la santé mentale de toute configuration obtenue et rapporte des problèmes à la fois directement à la personne qui effectue la configuration et dans les journaux.

  • Faites une séparation claire entre les valeurs de configuration spécifiques à l'environnement et celles qui doivent être transmises sans modification de votre rue Dev, Test, Acceptance, Prod (DTAP).

  • Utilisez un logiciel de gestion de version (p. Ex. Subversion) pour suivre les changements de configuration dans tous vos environnements.

  • Gérez la configuration de vos environnements DTAP comme un mégalomane.

  • Juste après avoir livré une version, et avant de recommencer à coder, faites en sorte que l'environnement de production soit copié sur tous les autres environnements, y compris le développement. Lorsque vous communiquez ceci à vos développeurs, consultez ceux d'entre eux devenus blancs et requestz-leur quels actifs ils ne pourraient pas replace à leur volonté du contrôle source.

  • Plus important!!! Vous lisez probablement cette pensée, qui est cet idiot? C'est impossible! Nous ne pourrions pas faire tout cela. Bien droit – bien sûr, vous ne pouvez pas – pas maintenant. (Si vous n'étiez pas déjà en difficulté, vous ne poserez pas la question). Donc, une vision distincte de la mise en œuvre. Partagez cette vision avec les autres parties prenantes. Décidez set quelles sont les capacités que vous devriez avoir, et faites un plan qui vous amène là-bas. Chaque cycle ou sortie ou quoi que ce soit, assurez-vous de vous rapprocher de la vision. Définissez des cibles réalists et rencontrez-les. (Bien sûr, vous êtes autorisé à modifier votre vision en fonction de l'expérience acquise).

Je dirais que, en dehors de garder les parameters de server et les files de configuration identiques, vous devriez avoir des environnements de test à déployer dans votre bureau. Si vos développeurs prouvent que le code qu'ils ont développé fonctionne sur un environnement qui ressemble beaucoup à un environnement en direct, ils se sentiraient plus confiants. Plus de confiance signifie qu'ils se développent nécessairement plus rapidement (car c'est quelque chose que nous avons appris de nos équipes SCRUM) et beaucoup less de boue et de sentiment de ne pas maîsortingser.

Donc, fondamentalement, ce que je dis, c'est simplement donner aux développeurs beaucoup de machines à jouer et à tester et vous verrez des résultats positifs.

L'étape la plus importante est un moyen simple de rendre la configuration de tous les servers de votre infrastructure aussi cohérente que possible. Un environnement d'exploitation standard (SOE), si vous voulez:

  • Toutes les instances IIS ont une configuration identique.
  • Tous les servers Web ont la même copy du site sur eux.

Une fois que vous avez cela, il devrait devenir beaucoup plus possible de mettre en œuvre des deployments automatisés, des tests, etc.

Si la configuration IIS est identique sur tous les servers, vous pouvez mettre à jour le file de configuration utilisé par IIS sur un server maître et exécuter un script pour l'envoyer à tous les servers Web, le tester et recharger les IIS. Vous pouvez faire de même pour vos files Web réels.

Je suppose que si vous aviez l'option de standardiser les servers que vous allez déployer, vous l'aviez déjà fait, alors je vais ignorer cette suggestion. Ce que vous devez faire, c'est créer des scripts / MSI, etc., pour automatiser le process de deployment de l'équipe opérationnelle. Il faudra du time pour configurer, mais la suppression de l'intervention manuelle de l'équipe Ops du process est la seule façon de le faire fonctionner en douceur. Maintenant, je n'insulte pas leur intelligence, loin de là. Le problème, c'est qu'ils ne savent pas comment fonctionne le code. Ils ne savent pas à quoi ressemblera un file de configuration avec une mauvaise valeur. Ils dépendent de vous en sachant que pour les aider et la raison pour laquelle l'automation est la key pour résoudre votre problème.

Ma suggestion serait de configurer des machines virtuelles localement qui imitent les différents servers, de sorte que vous pouvez tester à plusieurs resockets comment l'installation va fonctionner. Si votre département informatique est comme le mien, les nouveaux servers seront difficiles, car il s'agit de la budgétisation et de l'allocation des ressources, etc. Les machines virtuelles suppriment une grande partie du mal de tête car vous n'avez pas besoin de nouveau matériel, et les commentaires de n'importe qui seront minimes car il vous suffit de savoir comment les servers sont configurés et vous pouvez probablement faire le rest vous-même. Les machines virtuelles vous permettent également de réinitialiser rapidement la machine dans son état original et d'essayer à nouveau le process d'installation.

Dans mon infrastructure, nous avons un environnement de mise en scène appelé l'aperçu où datatables sont avant qu'elles ne produisent. Le code de l'application dans le niveau de mise en scène est exactement le même que le code de production, de sorte que tout problème de données se manifestera là-bas.

Nous avons également un environnement de test pour le nouveau code, qui fonctionne sur des données anciennes et connues (ce qui nous permet de mangle lorsque cela est nécessaire pour tester la façon dont le code échoue).

D'une manière générale, cette ségrégation nous permet d'avoir un environnement de production assez solide, et nous ne voyons pas trop de choses inattendues surgir.

Je dois noter que je ne m'attaque pas trop à cela, puisque je ne suis pas un programmeur. Je synchronise simplement les bases de données et rafraîchis les files lorsqu'ils me requestnt 😉

D'abord et avant tout, CONSISTANCE. Assurez-vous que tous vos servers sont exactement les mêmes. Tous les servers Web W2003 devraient ressembler au rest. Tous les servers DB, tous les servers Linux. Je veux dire la même chose . La même version du operating system, les mêmes correctifs, même structure de directorys … Tout!

Deuxièmement, une mise en scène. Vous devriez avoir un server distinct de chaque type, qui peut être utilisé pour tester votre deployment. C'est là que vous faites toutes vos erreurs de configuration. Vous copyz ensuite votre système de ces servers de deployment vers la production.

Troisièmement, le concept "Séparation of Concern" devrait être appliqué à vos files de configuration. Si différents modules ont des éléments de configuration différents, placez-les dans leur propre file de configuration. S'il existe une configuration spécifique à la machine, déplacez l'IT vers son propre file de configuration. De cette façon, vous pouvez déployer les files de configuration affectés à partir du server de deployment ainsi que les composants eux-mêmes.

Un mot: sauvegardes

Assurez-vous qu'ils ont des sauvegardes bonnes, centralisées, redondantes et cohérentes en place.