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 :
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é :
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.
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.
76 rue Denfert-Rochereau
69004 Lyon
Tel : 04.28.29.79.01
© 2014–2022 NUABEE. TOUS DROITS RÉSERVÉS.
Cookie | Durée | Description |
---|---|---|
cookielawinfo-checkbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checkbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |