heu, non, ce n'est pas incohérent, on appelle ça l'automatisation. On fait pareil sous Linux d'ailleurs. Et plein de monde fait les MAJ à temps (quelque soit l'OS).
Je ne connais personne qui arrive à mettre à jour des parcs de plusieurs centaines de serveurs d'une semaine sur l'autre systématiquement. Et ce quelque que soit le niveau d'automatisation que l'on mette en place, les OS concernés ou le niveau de support chez les meilleurs techniciens du marché.
Il y a pas mal d'infrastructure ou en une semaine tu ne peux même pas vraiment valider que les mises à jour ne cassent rien. Et je ne parle même pas des environnements ou il faut re-certifier les machines quand il y a des modifications.
Généralement tu vas tester les mises à jour sur un environnement dédié, valider que tout se passe bien, demander aux utilisateurs/clients/services de vérifier que tout va bien, passer les mises à jour sur les autres serveurs, re-valider que tout s'est bien passé. Rester sur le qui-vive jusqu'à ce que la clôture mensuelle/annuelle et le processus important qui n'est lancé que lorsque que strictement nécessaire se passent bien.
Même si tout est automatisé ET que tout se passe bien faire tout ça en une semaine et être prêt à recommencer la semaine suivante est extrêmement complexe.
Mais tout ne va pas bien se passer. Certaines mises à jour vont arriver avec leur lot de bugs, certains comportement de l'OS ou de la base de données ou des libs sur lesquelles tu t'appuyais vont changer (même subtilement). Un programme que tu compiles pour tes tests d'intégrité va avoir un hash différent. Un calcul va avoir une différence de résultat sur la cinquième décimale. Et du coup la question de "est-ce qu'on passe les mises à jour en prod ?" va se poser très sérieusement.
Et des fois ça va même franchement mal se passer. Tu vas tomber dans le cas à la con que ni MS ni IBM n'ont jamais testé de leur vie et qui va littéralement casser ton système ou effacer/rendre inaccessible une partie de tes données.
Et pendant que tu répares, que tu fais le tri entre les mises à jour que tu peux prendre et celles que tu veux éviter. Que tu escalades ton cas chez MS ou chez Red Hat - d'autres mises à jour hebdomadaires continuent de tomber. Avec bien sur des alertes CVE qui continuent d'arriver pour tes logiciels et de nouvelles menaces/problèmes à prendre en compte sur tes appliances et ton réseau.
Automatiser la mise à jour d'un parc de 800 serveurs, des applis qui tournent dessus et de l'infra qui va autour - ça n'est pas juste une ligne dans le chron que tu dupliques sur toutes tes machines et qui tourne le jeudi entre 2h et 3h du mat après les backups et avant les tests d'intégrité.
[^] # Re: ha...
Posté par Kaane . En réponse au journal Manutan, cyberattaque et Windows/Linux. Évalué à 10.
Je ne connais personne qui arrive à mettre à jour des parcs de plusieurs centaines de serveurs d'une semaine sur l'autre systématiquement. Et ce quelque que soit le niveau d'automatisation que l'on mette en place, les OS concernés ou le niveau de support chez les meilleurs techniciens du marché.
Il y a pas mal d'infrastructure ou en une semaine tu ne peux même pas vraiment valider que les mises à jour ne cassent rien. Et je ne parle même pas des environnements ou il faut re-certifier les machines quand il y a des modifications.
Généralement tu vas tester les mises à jour sur un environnement dédié, valider que tout se passe bien, demander aux utilisateurs/clients/services de vérifier que tout va bien, passer les mises à jour sur les autres serveurs, re-valider que tout s'est bien passé. Rester sur le qui-vive jusqu'à ce que la clôture mensuelle/annuelle et le processus important qui n'est lancé que lorsque que strictement nécessaire se passent bien.
Même si tout est automatisé ET que tout se passe bien faire tout ça en une semaine et être prêt à recommencer la semaine suivante est extrêmement complexe.
Mais tout ne va pas bien se passer. Certaines mises à jour vont arriver avec leur lot de bugs, certains comportement de l'OS ou de la base de données ou des libs sur lesquelles tu t'appuyais vont changer (même subtilement). Un programme que tu compiles pour tes tests d'intégrité va avoir un hash différent. Un calcul va avoir une différence de résultat sur la cinquième décimale. Et du coup la question de "est-ce qu'on passe les mises à jour en prod ?" va se poser très sérieusement.
Et des fois ça va même franchement mal se passer. Tu vas tomber dans le cas à la con que ni MS ni IBM n'ont jamais testé de leur vie et qui va littéralement casser ton système ou effacer/rendre inaccessible une partie de tes données.
Et pendant que tu répares, que tu fais le tri entre les mises à jour que tu peux prendre et celles que tu veux éviter. Que tu escalades ton cas chez MS ou chez Red Hat - d'autres mises à jour hebdomadaires continuent de tomber. Avec bien sur des alertes CVE qui continuent d'arriver pour tes logiciels et de nouvelles menaces/problèmes à prendre en compte sur tes appliances et ton réseau.
Automatiser la mise à jour d'un parc de 800 serveurs, des applis qui tournent dessus et de l'infra qui va autour - ça n'est pas juste une ligne dans le chron que tu dupliques sur toutes tes machines et qui tourne le jeudi entre 2h et 3h du mat après les backups et avant les tests d'intégrité.