S’il y a une leçon à tirer de Effondrement du système de Southwest Airlines en décembre dernier, c’est que les logiciels critiques doivent être régulièrement testés pour s’assurer qu’ils peuvent supporter des conditions extrêmes.
Les logiciels critiques de test de résistance font gagner du temps et de l’argent aux organisations – ce que Southwest a appris à ses dépens, déclare Stephen Feloney, vice-président des produits, tests continus, chez le fournisseur d’outils de développement d’applications Perforce. Les performances de test peuvent simuler efficacement le comportement du logiciel pendant les périodes de trafic élevé. « L’identification et la correction des erreurs avant qu’elles ne soient rencontrées par les clients diminuent le risque d’accident et empêchent les fiascos comme Southwest Airlines de se produire », note-t-il.
Selon Arie Trouw, PDG et CTO de XYO, développeur d’un protocole technologique conçu pour améliorer la validité des données, le pire moment pour découvrir que votre logiciel critique est incapable de gérer une charge élevée ou une autre situation de stress est lorsque cela se produit dans l’environnement réel. certitude et valeur. “Les tests de résistance sont le seul moyen de valider que votre architecture et votre implémentation peuvent résister à une crise de type Sud-Ouest.”
Les tests de résistance sont analogues à la conduite d’un exercice d’incendie dans un immeuble de bureaux, explique Rohan Padhye, professeur adjoint à la Carnegie Mellon University School of Computer Science. “L’objectif est de garantir que les éventualités conçues pour gérer des conditions extrêmes et inattendues, telles que les protocoles d’urgence et les systèmes de secours, fonctionnent réellement comme prévu.”
Tester, tester
Les tests de résistance soumettent généralement un système logiciel à des charges de travail très importantes sous la forme d’un volume élevé de demandes ou d’un taux élevé d’échec dans les composants individuels. “L’idée est de simuler un scénario du pire des cas avec des effets secondaires potentiellement imprévisibles”, explique Padhye.
Les tests révèlent comment un système réagira aux ralentissements, aux fuites de mémoire, aux problèmes de sécurité et à la corruption des données. “Dans les tests basés sur les performances, les tests de résistance doivent être associés à des tests de charge”, conseille Feloney. “Par exemple, tests de pointe examiner comment un système se comportera en cas d’augmentation soudaine et élevée du trafic, et essais de trempage examiner la pérennité du système sur une longue période.
Les tests de résistance peuvent être effectués soit dans un environnement isolé conçu à des fins de qualité, soit directement sur le déploiement en direct face au client. “Bien que cela semble effrayant, tester un déploiement en direct est beaucoup plus représentatif d’un scénario extrême réel, car il intègre également le facteur humain présenté par les utilisateurs répondant aux événements simulés d’une manière difficile à prévoir”, explique Padhye.
Les développeurs doivent toujours exécuter des tests de résistance après le déploiement d’une mise à jour ainsi qu’avant les événements à forte demande anticipés. “En identifiant les goulots d’étranglement avant les pics de trafic, les équipes peuvent lutter contre les erreurs avec les bonnes ressources et surveiller en permanence les performances”, déclare Feloney. “Par exemple, Panne du système de Ticketmaster pendant Taylor Swift La tournée des époques La vente montre l’importance des tests de résistance à l’avance pour éviter l’énergie et les coûts associés à la réparation d’une panne du système.
Les tests de résistance peuvent être effectués par le personnel informatique ou un prestataire de services externe. Il y a de la valeur dans les deux approches, dit Padhye. “D’une part, le personnel informatique qui gère les opérations au quotidien comprend très bien le système et est susceptible d’identifier rapidement des faiblesses spécifiques ou des composants obsolètes qui doivent être minutieusement testés pour des conditions extrêmes”, explique-t-il. “D’un autre côté, trop de familiarité avec le fonctionnement d’un système peut également introduire un biais inconscient sur la façon dont le système est censé fonctionner.”
Un prestataire externe peut parfois soumettre le système à comportement de cas d’angle qu’une équipe interne n’aurait peut-être même pas envisagé comme une possibilité. “Une nouvelle paire d’yeux peut donc permettre un test impartial de l’ensemble du système”, déclare Padhye. “Les services externes sont particulièrement utiles lors du test d’un système logiciel pour des incidents de sécurité, tels que des violations de données potentielles ou des perturbations malveillantes.”
Problèmes et risques
Même le test de résistance le plus complet ne peut pas anticiper toutes les situations possibles, il est donc important de développer un plan de récupération pour redémarrer ou réparer une panne induite par le stress. Un exemple courant est lorsqu’un composant spécifique du système tombe en panne sous contrainte. “Le redémarrage de cette partie du système est très difficile car des files d’attente en attente en dehors de celle-ci se sont accumulées pendant les temps d’arrêt”, déclare Trouw. “À ce stade, le stress lors du redémarrage peut être encore plus élevé que le stress qui a initialement causé la panne”, note-t-il.
L’un des principaux problèmes affectant les déploiements de logiciels complexes et de grande envergure est une dépendance croissante vis-à-vis de produits et services tiers qui ne sont pas créés ou maintenus par les membres du personnel informatique interne. “Ces composants peuvent tomber en panne de nombreuses manières inattendues, ou simplement devenir obsolètes”, prévient Padhye. “Le simple fait de décider de mettre à jour ces composants vers leur dernière version est une tâche difficile.”
Un risque associé à l’utilisation d’un composant obsolète est qu’il peut contenir des défauts non corrigés ou des vulnérabilités de sécurité. D’autre part, un composant mis à jour peut provoquer une défaillance du système si le composant présente une interface d’exploitation considérablement modifiée. “Les protocoles de test doivent spécifiquement prendre en compte les divers risques associés à la dépendance à ces logiciels tiers lors de l’exploitation de services critiques”, recommande Padhye.
Que lire ensuite :
Ingénierie du chaos : avantages de la construction d’une stratégie de test
Comment la dette technique entrave les efforts de modernisation des organisations
Dawn Foods essaie une recette low-code pour l’automatisation des tests d’assurance qualité
