Sommaire (4 sections)
Sur la question des mises à jour de sécurité, un parc de serveurs n'a que trois doctrines possibles. Ne rien faire, la plus répandue, et indéfendable. Tout automatiser : unattended-upgrades partout, les paquets s'installent seuls la nuit. Ou voir, puis décider : une visibilité continue sur l'état de chaque machine, et des mises à jour appliquées par une décision humaine outillée. Nous avons pratiqué la deuxième, puis démonté jusqu'à notre propre automatisation maison pour adopter la troisième. Voici pourquoi, et le dispositif complet.
Le problème d'unattended-upgrades n'est pas ce qu'il fait, c'est ce qu'il ne voit pas #
Soyons justes : sur un poste isolé ou un serveur personnel, unattended-upgrades vaut infiniment mieux que l'oubli. Notre objection vaut pour un parc de production : un patch est un changement non testé, appliqué à un moment que vous ne choisissez pas, sans humain pour constater le résultat. Un service qui redémarre en pleine nuit et ne revient pas, une dépendance qui casse une application, un correctif qui exige un redémarrage complet resté en attente pendant des semaines : l'automatisation aveugle transforme chaque nuit en déploiement sans pilote. Et son échec est silencieux : le paquet qui ne s'installe pas ne prévient personne, la machine « à jour » dans votre esprit dérive dans la réalité. Sur trente machines aux rôles différents, la panne aléatoire nocturne coûte plus cher que les quelques jours de délai d'un patch décidé.
Étape intermédiaire : l'automatisation maison, et pourquoi on l'a retirée aussi #
Notre première réponse fut un patching centralisé par Ansible : des playbooks, une planification, des rapports. Honnête, mais deux défauts structurels ont fini par peser. D'abord, pas d'inventaire vivant : entre deux exécutions, aucune idée de l'état réel du parc : combien de correctifs en attente, où, depuis quand. Ensuite, le cron patchait sans regarder : la même automatisation aveugle, juste écrite par nous. La leçon : le problème n'était pas l'outil d'application, c'était l'absence de visibilité permanente entre les actions.
La doctrine actuelle : PatchMon, voir puis décider #
Aujourd'hui, un agent léger sur chacune des 36 machines du parc remonte en continu vers une instance PatchMon auto-hébergée (open source) : paquets en attente, correctifs de sécurité, versions, historique. Le tableau de bord répond à tout instant à la question « où en est le parc ? », et le patching redevient ce qu'il aurait toujours dû être : une décision informée. Depuis la même console, un run de patch cible une machine ou un groupe, à l'heure choisie, avec son résultat consigné. Plus de quatre-vingts runs exécutés à ce jour, zéro échec : non parce que l'outil est magique, mais parce que chaque run est fait en regardant.
Le rituel qui rend le patch ennuyeux (c'est le but) #
- Regarder avant : que va-t-il se passer, quels services sont concernés, y a-t-il un redémarrage de service ou de machine à la clé ?
- Snapshot avant toute mise à jour significative : sur un hyperviseur, un instantané de la machine coûte quelques secondes et transforme le pire scénario en retour arrière de cinq minutes.
- Ordre de passage : les environnements de développement et machines sans enjeu d'abord, la production ensuite, jamais tout d'un coup.
- Vérifier après : le healthcheck applicatif : pas « le paquet est installé » mais « le service répond ». C'est l'étape que l'automatisation aveugle ne fera jamais.
- Les exceptions assumées : une montée de version majeure de base de données est une migration, pas un patch : jamais en automatique, jamais en lot.
La visibilité sur le parc, les runs décidés, les snapshots avant, les vérifications après : c'est le contenu concret de notre infogérance. Si votre réponse actuelle est « unattended-upgrades et on croise les doigts », ou pire « on verra plus tard », comparons.
