Quel est le meilleur moment pour planifier des mises à jour régulières sur le serveur de production interne?

Étant donné un serveur interne fonctionnant en mode production, je voudrais garder l'impact sur les utilisateurs aussi bas que possible lors du déploiement de mises à jour régulières (sur le serveur lui-même, pas sur les machines utilisateur .. mais ce serait un problème assez similaire).

La réponse évidente à ma question est "la nuit, quand les utilisateurs sont à la maison". Mais la «nuit» est une longue période de temps. Faut-il commencer tôt le soir pour peut-être détecter les problèmes avec la mise à jour tôt et être prêt à revenir en arrière? Ou vaut-il mieux commencer tôt le matin et utiliser les premiers utilisateurs comme "cobayes" pour déclencher plus rapidement les problèmes? Ou au milieu de la nuit lorsque la concentration de celui qui supervise la mise à jour est assez faible, mais il est garanti qu'il n'y a pas de descripteurs de fichiers ouverts pour certains utilisateurs qui travaillent tard?

Existe-t-il des documents de recherche sur le sujet?

Pourquoi ne pas examiner l'historique d'utilisation simultanée de votre système et déterminer les heures de la journée qui sont les plus faibles? Collez ensuite votre monnaie en plein milieu de cette période de faible utilisation.

Lorsque vous déterminez la durée du changement, incluez des tests avant / après la mise en œuvre et des tests de vérification de la production. En outre, déterminez combien de temps le changement prendra pour annuler si un test échoue.

À mon humble avis, vos «premiers utilisateurs» ne devraient pas être des cobayes. Faire en sorte que les utilisateurs en direct vérifient essentiellement vos modifications de production n'est pas une bonne chose. Il détruit la confiance des utilisateurs finaux et les résultats inattendus peuvent gâcher la production, ce qui signifie non seulement que vous devez annuler le changement, mais aussi annuler tout `` dommage '' que le changement peut avoir causé.

Je ne connais aucun document de recherche, mais jetez un œil à tout cadre de gestion des services informatiques (ITSM) tel que ITIL, vous trouverez de nombreuses normes et meilleures pratiques sur la gestion des versions logicielles. Tous les systèmes sont différents, de sorte que l'étendue du nombre de pratiques que vous adoptez et la formalité dépendent. Les normes ITSM ont de gros systèmes en tête.

Cela dépend entièrement de la nature de l'entreprise. Certains bureaux sont ouverts 9 à 5 jours par semaine. Les autres entreprises fonctionnent 24 heures sur 24, 365 jours par an. D'autres facteurs tels que la disponibilité du personnel et des ressources jouent un rôle important. Aucun document de recherche ne pourrait couvrir de manière exhaustive tous les calendriers ou éventualités possibles.

En fin de compte, la direction de l'entreprise ou du service, de concert avec la direction informatique, doit déterminer ce qui est le mieux.

La clé du succès est de communiquer avec les utilisateurs lorsque le temps d'arrêt doit commencer, combien de temps il devrait durer, toute préparation requise des utilisateurs et ce à quoi ils peuvent s'attendre en cas de succès ou d'échec. Une grande partie de cela répond aux attentes que vous définissez.

Au final, rien n'est gravé dans la pierre. Si le processus ne fonctionne pas, faites des ajustements. Votre flexibilité et votre adaptabilité seront appréciées.

En effectuant au préalable des procédures de maintenance et de mise à jour des équipements de test, vous serez mieux préparé au moment de les implémenter sur les systèmes de production.

Je travaille chez un FAI et d'après mon expérience, la plupart des gens que je considérerais comme des administrateurs système de frappeurs lourds choisissent les vendredis soirs le week-end de vacances pour effectuer leurs principales révisions du réseau. Cela leur donne 24 heures supplémentaires pour tester et, si nécessaire, annuler leurs modifications. Cependant, dans une large mesure, cela dépend entièrement de la nature et des habitudes de vos utilisateurs.

Nous installons les mises à jour à 21 heures, suffisamment tard pour que la plupart des gens ne soient pas allumés, assez tôt pour tirer la nuit si nécessaire.

Dans mon cas, nous installons les mises à jour à 4h du matin, afin d'éviter tout impact sur les utilisateurs, même ceux qui travaillent un peu en retard.

Si vous avez un bon système de surveillance qui vous avertit en cas de problème, vous devriez pouvoir le corriger tôt le matin, avant même d'aller travailler.

Cela dépend vraiment de la nature de votre entreprise, mais je préfère personnellement le mercredi soir après 17 h. Vous ne voulez jamais faire ça le vendredi soir car si quelque chose ne va pas, vous travaillerez le week-end. Faire cela mercredi vous donnera jeudi et vendredi pour résoudre les problèmes éventuels.

Un autre facteur important est de planifier des fenêtres de gestion des modifications. Il est essentiel de faire savoir aux gens que vous exécutez la maintenance - que les services peuvent être interrompus ou indisponibles pendant cette période. Cela vous permettra de travailler en toute confiance, au lieu de vous inquiéter du fait que les utilisateurs se plaindraient de l'arrêt des services. Votre direction doit bien sûr approuver les fenêtres de modification.