Jusqu’en 2020, la notion « d’automatisation de tests » correspondait à la planification manuelle des tests de restauration et de redémarrage.
Cela impliquait qu’un Opérateur spécifie manuellement le jour et l’heure du test pour une machine donnée.
En 2020, nous comptabilisions déjà plusieurs centaines de serveurs à tester régulièrement, avec en général, plusieurs disques à restaurer. Cela générait un travail important de planification et de contrôle pour les équipes techniques de Nuabee.
Nous souhaitions également augmenter la fréquence des tests de redémarrage de serveurs, pour améliorer la qualité de la solution UCover.
Les objectifs fixés étaient alors :
- De permettre aux équipes Opérationnelles de ne plus passer de temps sur cette planification grâce à une automatisation complètement indépendante.
Celle-ci choisirait d’elle-même le meilleur moment pour restaurer & redémarrer un serveur, selon de multiples critères, et qui ne requiert l’attention d’un opérateur qu’en cas de problème. - D’optimiser les coûts des tests de redémarrage serveur tout en augmentant leur fréquence.
Ce deuxième objectif permet également de réduire les risques lors d’un test de PRA, en testant les serveurs des clients plus régulièrement.
Industrialisation d’une automatisation des restaurations
Pour commencer, nous nous sommes posé la question suivante : En quoi consiste une automatisation ?
Ce mot, bien que barbare aux premiers abords, prend tout son sens si nous détaillons les principes de celui ci en fonction de notre contexte.
Ici, nous voulons faire en sorte que les serveurs des clients soient restaurés et redémarrés le plus souvent possible, mais qu’également qu’ils le soient au meilleur moment.
En effet, il faut accorder « du temps » pour chaque serveur, afin d’éviter que plusieurs tests de serveurs se chevauchent. Pour imager ce concept, nous souhaitons éviter qu’un seul chaton d’une portée mange toutes les gamelles des autres !
Ici c’est la même chose, le temps alloué à chaque test serveur doit être optimisé pour être certain d’avoir une restauration en cours qui se réalise sans erreur, peut importe le jour et l’heure.
La seconde notion importante à prendre en compte est la suivante : la notion de « poids ».
Si le système de PageRank de Google vous parle et bien vous avez déjà compris une partie du projet. Selon Google, un site Web a une notion de poids, c’est à dire une valeur qui peut monter ou descendre. Plus la valeur est élevée plus le site Web est important.
Ici nous avons le même principe, sauf que nous parlons de serveurs : plus le poids d’un serveur est élevé , plus celui-ci a de l’importance dans le processus de tests de redémarrage.
Considérant cette notion de poids, détaillons les critères que nous avons décidé d’appliquer pour définir quel serveur est plus important qu’un autre et doit donc être restauré et redémarré en priorité :
- Les serveurs JAMAIS restaurés (ceux des nouveaux clients) ont un poids de 360 de base.
- Les serveurs qui ont déjà eu une restauration positive (ie. test réussi), ont un poids de 0 de base.
- Les serveurs qui ont déjà eu une restauration mais négative (ie. échec) prennent un poids de -1.
- Ils deviennent blacklistés, ils doivent être analysées par un Opérateur humain. Lorsque le problème a été résolu, l’opérateur peut le remettre dans la pool de restauration.
- Les machines qui ont eu une demande de restauration prioritaire suite à une demande manuelle par un Opérateur, prennent un poids de base de 1000.
Augmentation de la fréquence des tests de redémarrage de serveur
Pour réaliser le deuxième objectif, nous avons fait le choix de la location d’une instance dédiée à ces tests (ou plusieurs en cas de besoin) avec une utilisation en continue. Cela correspond donc à de la réservation d’instance sur une période de plusieurs années, ce qui nous permet de diminuer le coûts des tests de redémarrage.
Grâce à cette modularité, on s’assure d’optimiser les coûts en temps réels. Vous pouvez voir cela comme dans une gestion ferroviaire : on peut choisir d’ouvrir ou fermer des voies en fonction du trafic.
Quant à la logique industrielle que cela implique, nous avons du faire face à plusieurs grands principes qu’il a fallu rendre indépendants d’un point de vue code mais également faire en sorte qu’ils soient compatibles.
En synthèse
Grâce à ces mécanismes, nous avons multiplié par 4 le nombre de tests de redémarrage des serveurs Client sans augmentation importante des coûts.
Néanmoins, nous devons trouver le bon équilibre entre la qualité de notre solution et l’impact carbone des tests. Ces études sont au goût du jour chez Nuabee, et nous reviendrons bientôt vers vous avec nos recherche et nos études à ce sujets.
