Le mot « panne » évoque peut-être chez vous l'effondrement total d'un service, l'arrêt soudain de chaque élément de la chaîne de distribution du service. Cependant, si vous observez de près l'anatomie de la plupart des pannes, il est rare (bien que pas impossible) qu'elles soient totales.
Nous avons remarqué récemment une légère hausse de ce que nous appelons les « défaillances fonctionnelles » : une partie d'un service tombe en panne, mais les répercussions en aval perturbent l'ensemble de la chaîne de distribution. Il peut s'agir d'une passerelle de paiement qui ne fonctionne plus ou d'un problème au niveau du processus d'authentification utilisateur. Ces composants sont souvent mis à disposition par des prestataires externes et échappent au contrôle du fournisseur de services, mais ils peuvent avoir des conséquences désastreuses sur la distribution des services.
C'est seulement en examinant l'anatomie de ces pannes que vous pourrez commencer à les maîtriser, aussi bien en tant que fournisseur de services qu'en tant que client. Découvrons comment vous pourrez limiter les risques de défaillance à long terme si vous comprenez mieux le déroulement d'une panne.
Des défaillances fonctionnelles en hausse
Si vous écoutez régulièrement notre podcast The Internet Report, vous aurez remarqué que nous avons beaucoup parlé ces derniers mois de défaillances fonctionnelles touchant de grands noms des services Internet dans le monde. Lors de ces pannes, l'utilisateur se retrouve souvent face à un service non disponible. Cependant, en examinant ces pannes de plus près, on réalise qu'il s'agit en général d'une seule petite partie de l'application qui est défaillante, comme un plug-in tiers, une passerelle de paiement ou le fournisseur d'authentification.
Nous sommes à l'ère de l'architecture distribuée, les services sont constitués de différents composants qui doivent fonctionner en harmonie. Cette configuration présente de nombreux avantages, notamment une optimisation du service et une réduction de la latence. Par exemple, une boutique en ligne ne souhaitera probablement pas gérer sa propre passerelle de paiement. Et pourquoi le ferait-elle ? Ce n'est pas son cœur de métier, c'est un terrain miné pour la sécurité, et il est presque toujours moins coûteux de déployer une option tierce qui n'engendre pas de coûts de développement ou de maintenance continue. Même les plus grandes entreprises technologiques du monde font appel à des composants externes pour certains aspects de leurs applications. Cette approche n'est pas purement technologique, elle permet souvent d'améliorer les performances et de réduire les frais généraux.
Mais il existe aussi une part de risque. Un de ces composants peut être la seule cause d'une défaillance. Si un utilisateur ne peut pas s'authentifier auprès d'un réseau social par exemple, il importe peu que la messagerie du service continue à fonctionner sans problème. Il ne peut pas y accéder de toute façon.
De même, nous voyons des pannes au cours desquelles l'authentification se passe sans problème et l'application semble fonctionner normalement. Cependant, à cause de la défaillance fonctionnelle d'un service back-end, lorsque l'utilisateur tente d'effectuer une action, comme envoyer un message ou acheter un article, le service échoue.
Si la plupart des fournisseurs de services intègrent un élément de redondance à leurs services, le rapport risque/bénéfice n'est pas toujours favorable à un système de basculement. Par exemple, déployer une passerelle de paiement de sauvegarde est une solution techniquement complexe et coûteuse dont choisiront de se passer de nombreux fournisseurs de services. Tout comme les consommateurs qui achètent rarement le même type de service deux fois au cas où l'un deux tomberait en panne.
Mais cela ne signifie pas que nous devons baisser les bras et accepter les pannes occasionnelles, du côté du fournisseur de services comme de l'utilisateur.
Comprendre une panne
Alors que faire dans ce genre de situations ? Vous devez d'abord comprendre l'anatomie de la panne.
Vous devez commencer par identifier le domaine à l'origine de la panne (c'est-à-dire où le problème est survenu et qui est chargé de le résoudre). Par exemple, provient-elle d'un service externe ou du data center hébergeant ce service ?
Mais notre objectif n'est pas simplement de désigner un responsable. Il est essentiel de comprendre l'impact de cette panne et ses répercussions possibles à l'avenir, si elle devait se reproduire. Avez-vous subi une perte complète du service ou une simple baisse des performances ? Quelles ont été les conséquences de l'augmentation de la latence dans une partie spécifique de la chaîne de services ? C'est seulement une fois que vous aurez bien compris les conséquences d'une panne que vous pourrez commencer à réfléchir à la manière de l'éviter, ou d'en diminuer l'impact, à l'avenir.
En tant qu'entreprise, c'est vous qui devrez décider où et quand une redondance est utile. Comme indiqué précédemment, il est peu probable que vous disposiez de deux passerelles de paiement, car c'est une solution souvent trop coûteuse. Cependant, vous pourriez envisager d'avoir deux fournisseurs CDN ou de les répartir selon différentes régions. Cela représentera un coût de calcul, mais qui fera partie de l'évaluation des risques.
Les clients de ces services devront eux aussi effectuer une évaluation des risques. Combien coûte une panne de ce type et combien coûterait sa résolution ? Si vous êtes client d'un fournisseur de service cloud par exemple, vous pourriez envisager d'investir dans deux zones de disponibilité distinctes. Une analyse des coûts est nécessaire : quel sera le coût informatique supplémentaire ? Comment pourrez-vous synchroniser les données entre les deux zones ? Aurez-vous besoin de plusieurs CDN ? Est-il plus judicieux sur le plan financier d'utiliser un fournisseur cloud de niveau 2 ?
Toutes ces questions nous ramènent à la nécessité de comprendre l'ensemble de la chaîne de distribution des services. Vous devez savoir pourquoi la panne est survenue, s'il est probable qu'elle se répète à l'avenir, le niveau de risque auquel vous faites face et si vous devez prendre des mesures pour éviter qu'elle se reproduise.
Vous devez vous éloigner de l'attitude qui consiste à « trouver la panne, résoudre la panne » et chercher plutôt à améliorer constamment votre approche, afin d'anticiper les problèmes potentiels et de les maîtriser avant qu'ils ne surviennent.
Écoutez l'épisode « The Anatomy of an Outage » de notre podcast pour en savoir plus sur l'anatomie des pannes et découvrir des études de cas réelles.
Identifier les informations importantes
Nous devons donc sortir de cet état réactif et adopter une approche préventive, c'est-à-dire rechercher sans cesse des moyens d'améliorer les performances sur tout le réseau. Pour ce faire, nous devons nous concentrer sur les bonnes données.
Il est facile de tomber dans le piège qui consiste à essayer de tout vérifier, en tirant sur tous les fils possibles. C'est une approche non seulement chronophage, mais qui peut également s'avérer très coûteuse. Et même si vous avez les moyens financiers de collecter toutes ces données, cela revient très vite à rechercher une épingle dans une meule de foin.
Ce qui est important, c'est de savoir identifier les informations pertinentes pour votre entreprise, celles qui vous permettront d'optimiser vos opérations à l'avenir, car vous aurez une connaissance approfondie des risques et des coûts/bénéfices que représentent la résolution des problèmes potentiels ou les solutions potentielles.
Au cours de ma carrière, j'ai travaillé avec un grand nom du secteur des jeux d'argent. L'entreprise avait décidé de déplacer les opérations de son propre data center vers le cloud, d'effectuer ce qu'on appelle un « réhébergement » de son infrastructure. Il lui avait été expliqué qu'il lui suffisait de répliquer sa structure actuelle dans une architecture cloud pour réduire les coûts et améliorer les performances.
Cependant, une fois la migration terminée, l'entreprise a été surprise de constater une diminution des performances, malgré un équipement plus moderne, car elle n'avait pas adapté l'architecture aux besoins de la nouvelle infrastructure cloud. Dans le secteur des jeux d'argent, tout délai dans les performances des applications a d'importantes répercussions, car les clients placent des paris sur des événements en direct et veulent réagir instantanément à tout changement dans le jeu. Mais sur la nouvelle infrastructure, les paris prenaient deux fois plus longtemps que sur l'ancienne, ce qui a fait fuir les clients.
Pour aggraver la situation, les coûts de calcul de l'entreprise augmentaient, car ils avaient migré une structure on-premise vers le cloud sans optimiser le back-end pour l'infrastructure cloud.
Pour résoudre le problème, ils ont dû reculer et réexaminer la situation. Ils ont repensé le code en fonction de la plateforme cloud pour faire baisser les coûts, mais sans nuire aux performances. En fait, ils avaient besoin d'améliorer l'efficacité de la solution. Pour y parvenir, ils ont divisé le service et rapproché géographiquement l'infrastructure cloud des utilisateurs afin de réduire le trop long délai lorsque ces derniers plaçaient un pari.
Identifier les points critiques
Cette expérience illustre notre argument sur la recherche proactive d'amélioration. La chose la plus importante que peut faire une entreprise est d'identifier les points faibles au sein de cet environnement. Où se trouvent les goulots d'étranglement ?
Il n'est pas nécessaire d'identifier chaque point de défaillance. Il s'agit de déterminer l'endroit où une dégradation des performances est la plus probable. Si vous parvenez à l'identifier, il s'agit probablement aussi de la partie qui tombera en panne, car une panne se manifeste principalement par une perte. C'est à ce moment-là que la dégradation et la retransmission se produisent et que la latence augmente, ainsi que tous les indicateurs principaux d'une panne.
Mais si vous savez identifier ces goulots d'étranglement avant la panne, vous pouvez cibler les composants à optimiser. Il s'agira de votre meilleur retour sur investissement en termes de dépenses informatiques. Et vous ne passerez pas la journée à vérifier vos rapports pour essayer de comprendre d'où vient le problème.