Le monde du commerce en ligne regorge d’histoires de sites Web qui ont réussi à obtenir une tonne de trafic et qui n’ont ensuite pas pu gérer la charge.
Certains sites se rétablissent, mais dans l’ensemble, une fois qu’un site est en panne, il faut généralement une intervention manuelle pour le remettre en service. Cela peut coûter beaucoup d’affaires à une entreprise, car les pannes de site se produisent souvent sans avertissement et à des moments de la journée et de la semaine où les techniciens qualifiés ne sont pas disponibles pour rétablir le service.
La solution à ce problème est de tester la charge de votre site. Ce processus n’est vraiment pas différent de tout autre type de test logiciel. Vous devez simplement faire fonctionner le site dans des circonstances conçues pour simuler le plus fidèlement possible les conditions du monde réel.
Voici quelques conseils pour vous assurer que votre processus de test est aussi efficace que possible
1. Simulez au moins une défaillance
La règle dans tout projet d’ingénierie est que la défaillance doit se produire aussi tôt et aussi bruyamment que possible. Une défaillance silencieuse qui survient un jour est le fléau de tout projet qui dépend de la précision, de la technologie ou d’une ingénierie complexe.
Les informations que vous recueillez à partir d’une défaillance exposeront les faiblesses de votre système. Une fois que vous savez où le système est sujet aux défaillances, vous pouvez effectuer des réparations intelligentes et atténuer les problèmes futurs.
La simulation de défaillance peut fournir de nombreux types de mesures différentes. Chacune vous donnera une idée des limites de votre matériel et de votre configuration. Plus vous pouvez tester de choses, plus vous pouvez durcir votre système.
Pour durcir un système et exécuter le nombre approprié de tests, il est bon d’utiliser un outil qui peut simuler un grand nombre d’utilisateurs.
2. Concentrez-vous sur votre basculement
Un système de basculement est un système conçu pour répondre si un système principal déclenche un ou plusieurs seuils de performance. Les serveurs de basculement peuvent être alignés en série, de sorte que si le site A tombe en panne, le site B peut prendre en charge le nouveau trafic. Si le site B tombe en panne, le site C se met en ligne et ainsi de suite.
Dans l’exemple ci-dessus, si le nombre de demandes adressées à un domaine ou à une instance logicielle particulière atteint une certaine proportion de sa limite, toutes les nouvelles demandes peuvent être acheminées vers le site B. Il est d’une importance vitale que vous vous assuriez que tous ces seuils et leurs configurations de routage fonctionnent. De plus, vous devez vous assurer qu’ils fonctionnent même si le site et tous ses basculements sont soumis à une charge maximale.
3. Test en production uniquement
Si vous développez des serveurs web à l’intérieur de votre propre réseau, il peut être très facile de supposer que tout fonctionne bien. Sur un réseau local, la latence sera presque inexistante, aucun routeur extérieur ne touchera vos paquets et les choses peuvent souvent donner l’impression de fonctionner sans problème alors qu’en réalité, l’introduction de conditions réelles peut immédiatement causer des problèmes.
La qualité de vos serveurs web compte également. Par exemple, si vous utilisez un hébergement professionnel de faible qualité pour héberger votre site, vous risquez de constater que vos serveurs présentent un degré élevé de latence.
Un problème courant qui survient lorsqu’une plate-forme de test est déplacée « à l’extérieur » pour ainsi dire, est que tous les logiciels de prévention des pannes se déclenchent en même temps parce qu’ils interprètent le ralentissement du réseau comme un événement de charge élevée. Soudain, l’ensemble du réseau se dispute l’attention et provoque le type de panne que ces systèmes étaient censés prévenir.
Mettre en place un environnement de test en interne, c’est bien, mais pour obtenir les bonnes données dans les bonnes conditions, vous devez mettre votre avion dans les airs. S’il se plante, au moins vous serez au courant du problème bien à l’avance.
4. Commencez sur le métal
Comme tout projet logiciel, un processus de test de charge doit être opérationnel à chaque phase d’intégration. Cela signifie que seul le logiciel de base peut être exécuté lors de votre premier test. Une fois que vous avez garanti que votre système de base fonctionne, vous pouvez alors ajouter des plug-ins, des add-ons, des filtres et ainsi de suite. Chacun d’entre eux doit être isolé et testé seul.
La raison pour laquelle cela est si important est que les logiciels intégrés doivent se dégrader gracieusement. Si l’un de ces plug-ins tombe en panne, il ne peut pas entraîner tout le système dans sa chute. Le système de base doit être solide pour pouvoir continuer à fonctionner même si ses fonctions auxiliaires sont en panne.
Naturellement, vos mécanismes de basculement doivent se déclencher sur tout type de panne logicielle. La façon la plus simple de mettre cela en place est de créer un mécanisme d’interrogation afin que le système de base puisse régulièrement envoyer un ping aux systèmes auxiliaires pour s’assurer qu’ils sont en place.
5. Documentation
Sans exception, la partie la plus importante de tout régime de test est de documenter vos résultats. Ces informations vous donnent non seulement un enregistrement vital de ce que vous avez accompli, mais elles servent également de point de départ à toute enquête visant à déterminer pourquoi le système a pu tomber en panne ou déclencher un basculement. Considérez votre documentation comme une carte. Sans elle, vous ne saurez pas où chercher si un problème inexplicable survient.
