Pourquoi nous redémarrons les serveurs

Une question qui revient assez régulièrement est de savoir si les serveurs devraient être redémarrés de façon routinière, par exemple une fois par semaine, ou s'il faudrait les laisser fonctionner aussi longtemps que possible afin d'atteindre un « temps de fonctionnement » maximal. Pour moi, la réponse est simple — à de rares exceptions près, les redémarrages réguliers constituent le choix le plus approprié pour les serveurs.

Comme pour toute règle, il existe des cas où elle ne s'applique pas. Par exemple, certaines entreprises exploitant des systèmes critiques ne disposent d'aucune marge pour les temps d'arrêt et doivent être disponibles 24 h/24 et 7 j/7. Évidemment, des systèmes de ce type ne peuvent pas être simplement redémarrés de manière routinière. Cependant, si un système est si critique qu'il ne peut jamais être interrompu, cette situation devrait déclencher un signal d'alarme indiquant que ce système est un point de défaillance, et une réflexion sur la manière de gérer les temps d'arrêt, planifiés ou non, devrait peut-être être engagée.

Une autre exception : certains systèmes AIX ont besoin d'un temps de fonctionnement significatif, supérieur à quelques semaines, pour atteindre une efficacité maximale, car le système s'auto-optimise et a besoin de temps pour obtenir des informations d'utilisation et s'ajuster en conséquence. Cela tend à se limiter aux grands serveurs de bases de données qui changent rarement et à des scénarios d'utilisation similaires, moins courants que sur d'autres plateformes.

En informatique, nous vénérons souvent le concept de « temps de fonctionnement » (uptime) — la durée pendant laquelle un système peut fonctionner sans nécessiter de redémarrage. Mais le « temps de fonctionnement » n'est pas un concept qui apporte de la valeur à l'entreprise, et l'informatique doit garder à tout moment à l'esprit les besoins de l'entreprise plutôt que de se concentrer sur des métriques artificielles. L'entreprise ne se soucie pas de savoir combien de temps un serveur a réussi à rester en ligne sans redémarrer — elle se soucie seulement que le serveur soit disponible et prêt lorsqu'on en a besoin pour le traitement métier. Ce sont des concepts très différents.

Pour à peu près n'importe quel serveur d'entreprise ordinaire, il existe une plage horaire pendant laquelle le serveur doit être disponible à des fins métier et une plage pendant laquelle il n'est pas nécessaire. Ces plages peuvent être quotidiennes, hebdomadaires ou mensuelles, mais il est rare qu'un serveur soit réellement utilisé en continu, 24 h/24, sans exception.

J'entends souvent des gens affirmer que, parce qu'ils utilisent le système d'exploitation X plutôt que Y, ils n'ont plus besoin de redémarrer, mais c'est tout simplement faux. Il existe deux principales raisons de redémarrer de façon régulière : vérifier la capacité du serveur à redémarrer avec succès et appliquer les correctifs qui ne peuvent pas l'être sans redémarrage.

L'application des correctifs est la raison pour laquelle la plupart des entreprises redémarrent. Presque tous les systèmes d'exploitation reçoivent des mises à jour régulières qui nécessitent un redémarrage pour prendre effet. Comme la plupart des correctifs sont publiés à des fins de sécurité et de stabilité, en particulier ceux qui exigent un redémarrage, l'importance de leur application est plutôt élevée. Rendre un serveur inutilement vulnérable juste pour préserver le temps de fonctionnement n'est pas judicieux.

Tester la capacité d'un serveur à redémarrer avec succès est ce que l'on néglige souvent. La plupart des serveurs font l'objet de modifications appliquées de manière régulière. Ces modifications peuvent être des correctifs, de nouvelles applications, des changements de configuration, des mises à jour ou des éléments similaires. Toute modification introduit un risque. Ce n'est pas parce qu'un serveur est en bonne santé immédiatement après l'application d'une modification que le serveur, ni les applications qui s'exécutent dessus, démarreront comme prévu au redémarrage.

Si le serveur n'est jamais redémarré, alors nous ne savons jamais s'il est capable de redémarrer avec succès. Avec le temps, le nombre de modifications appliquées depuis le dernier redémarrage augmentera. C'est très dangereux. Ce que nous craignons, c'est qu'un grand nombre de modifications aient été apportées, dont beaucoup éventuellement non documentées, et qu'un redémarrage échoue alors. À ce stade, identifier quelle modification est à l'origine de la défaillance du système pourrait s'avérer un processus insurmontable. Aucune modification unique à annuler, aucun chemin connu vers la récupération. C'est là que la panique s'installe. Bien entendu, une machine qui n'est jamais redémarrée intentionnellement est plus susceptible de redémarrer involontairement — ce qui signifie que le risque d'un redémarrage raté est à la fois plus probable de se produire et plus probable de se produire en cours d'utilisation active.

Bien que les redémarrages réguliers n'aient pas pour but de réduire la fréquence des redémarrages ratés — en réalité, ils augmentent même l'occurrence des défaillances — leur finalité est de rendre ces défaillances facilement gérables du point de vue des « modifications connues » et, plus important encore, de contrôler le moment où ces redémarrages surviennent, afin de garantir qu'ils se produisent à un moment où le serveur est désigné comme disponible pour la maintenance et est censé être mis à l'épreuve, de sorte que les problèmes soient détectés à un moment où ils peuvent être atténués sans impact sur l'activité.

J'ai entendu bien des administrateurs système affirmer qu'ils évitent les redémarrages du week-end parce qu'ils ne veulent pas se retrouver coincés à travailler le dimanche à cause de serveurs qui ne redémarrent pas après un redémarrage. J'ai moi-même été appelé bien des dimanches matin à cause d'un redémarrage raté, mais chaque fois que je reçois cet appel, j'éprouve un sentiment de soulagement. Je sais que nous venons tout juste de détecter un problème à un moment où l'activité n'est pas impactée financièrement. Si ce serveur n'avait pas été redémarré en dehors des heures de travail, on aurait pu ne pas découvrir qu'il était « non démarrable » avant qu'il ne tombe en panne pendant les heures d'activité et n'entraîne une perte de revenus.

Grâce aux redémarrages réguliers du week-end, nous pouvons détecter en toute sécurité des désastres imminents et, du fait de savoir que nous n'avons qu'une semaine de modifications à examiner, nous sommes régulièrement en mesure de corriger les problèmes avec généralement peu d'efforts et une grande confiance dans notre compréhension des modifications qui avaient été apportées avant la défaillance.

Les redémarrages réguliers consistent à protéger l'entreprise contre les pannes et les temps d'arrêt qui peuvent être atténués grâce à des processus très simples et fiables.