Blizzard partage quelques commentaires techniques sur la sortie de Dragonflight

Posté par Blizzard (Source)

Maintenant que la sortie Dragonflight est derrière nous, nous aimerions revenir avec vous sur ces derniers jours d’un point de vue technique. L’objectif est d’expliquer un peu mieux ce que représente une sortie mondiale de ce genre, ce qui peut bien ou mal se passer, les problèmes qui peuvent survenir et les solutions à notre disposition pour les régler.

En interne, on appelle un jour comme lundi dernier un « lancement de contenu », car la sortie d’une extension est un travail de longue haleine et ne se résume pas à une seule date. World of Warcraft est loin d’être un jeu rigide et figé et a beaucoup évolué depuis ses débuts il y a 18 ans, et même au cours des deux dernières années. En conséquence, nous devons modifier notre façon de déployer le contenu au fur et à mesure que le jeu grandit.

Une extension est désormais déployée en plusieurs étapes : tout d’abord, le code est intégré au contenu existant, puis les évènements de prélancement permettent d’ajouter les nouveaux systèmes de jeu et enfin, le jour du « lancement de contenu », les quêtes, zones et donjons deviennent accessibles. Chaque étape est ciblée et nous permet d’isoler les problèmes plus efficacement. Cependant, pour des systèmes aussi complexes, on ne peut pas toujours se préparer à tout.

L’une des nouveautés propres à cette extension consistait en un lancement de contenu déclenché par un évènement chronométré, c’est-à-dire plusieurs modifications apportées au jeu programmées pour être déployées simultanément. Ces changements, s’ils étaient faits manuellement, impliqueraient inévitablement la possibilité d’une erreur humaine, ou le risque qu’une panne interne ou externe vienne contrarier le processus. Un lancement chronométré et automatisé permet de réduire considérablement les risques.

Un autre changement apporté avec Dragonflight a été l’amélioration du chiffrement des données de jeu. Ce changement nous permet d’envoyer des informations cruciales au jeu côté client pour que les cinématiques, les dialogues et les scripts de quêtes fonctionnent correctement et au bon moment, sans jamais rendre les données vulnérables ou accessibles avant l’heure. Nous connaissons la passion de notre communauté pour WoW ; lorsqu’on brûle de découvrir les nouveautés, il peut être tentant de sauter sur le moindre bout d’information et ainsi se gâcher la surprise. Ce nouveau système de chiffrement a pour but d’éviter ce genre de situation, et d’assurer que le contenu soit toujours disponible lorsque le bon moment se présente, et pas avant.

Nous avons identifié que les fortes latences et l’instabilité des serveurs de la semaine passée étaient causées par l’interaction entre ces deux nouveaux systèmes. Le serveur de simulation (celui qui gère vos déplacements et vos actions en jeu) se retrouvait à devoir recalculer plusieurs centaines de fois par seconde ce qui devait être accessible ou non et ce pour chaque simulation. De fait, le système s’est vite saturé avec ces calculs, les simulations ont commencé à s’enliser, et les requêtes d’autres services ont été mises en file d’attente. Pour les joueurs et joueuses, cela se traduit par de la latence et des messages d’erreur de type « Le serveur du monde est arrêté ».

Heureusement, nous avons pu identifier le problème. Les données chiffrées dans l’attente d’un évènement précis censé les débloquer ont exposé une erreur de logique dans le code : une ligne de code mal positionnée donnait au serveur l’instruction de recalculer quelles données chiffrer, alors que rien n’avait changé.

Voici comment notre enquête s’est déroulée. Tout commence à minuit, heure de Paris. Grâces aux tests menés, nous savions déjà que le navire de la Horde arriverait quelques instants avant celui de l’Alliance. La plupart d’entre nous sont également en jeu avec nos personnages sur les quais, aux deux points d’arrivée, avec d’autres fenêtres ouvertes pour afficher des données, des graphiques et divers tableaux. Nous sommes également en contact direct avec nos collègues des équipes d’assistance de tout Blizzard.

Avant le lancement, nous nous sommes préparés à plusieurs scénarios catastrophe et comment les éviter ou les régler rapidement grâce aux phases de test. Nous avions par exemple préparé des portails pour permettre aux joueurs et joueuses de rejoindre les îles aux Dragons au cas où les bateaux ne fonctionneraient pas.

À 00h02, le navire de la Horde arrive comme prévu. Hourra ! Les joueurs et joueuses, nous y compris, s’entassent à bord. Certains et certaines d’entre nous restent à quai, au cas où il faudrait activer les portails. Le bateau part, mais plusieurs passagers et passagères n’arrivent pas à destination, subissent des déconnexions ou se retrouvent coincés.

Nous passons immédiatement les données, graphiques et tableaux en revue. Il n’y pas beaucoup de monde sur les îles aux Dragons. Plusieurs collègues signalent des problèmes avec leurs noms de personnages et leurs royaumes. D’autres remontent des soucis dans la charge processeur et avec le NFS (Network File Storage, le protocole de gestion de fichiers) utilisé par nos serveurs. Nos équipes continuent de surveiller le jeu et de signaler les problèmes.

Après les navires de la Horde, nous observons l’arrivée des navires de l’Alliance. La plupart n’arrivent pas, et les navires de la Horde ne reviennent pas.

Nous commençons à avoir une vue d’ensemble : les navires sont coincés et les serveurs des îles aux Dragons sont plus lents à répondre que prévu. C’est le moment de nous retrousser les manches et de mettre au point des solutions. [Text Wrapping Break][Text Wrapping Break]Ce n’est pas la première fois que les bateaux posent problème. Nous activons les portails, et nous continuons d’enquêter. Notre NFS est très clairement surchargé. Trop de requêtes sont en attente et notre système de coordination des serveurs de simulation déjà saturé commence à lancer des calculs pour toutes les requêtes qui n’aboutissent pas. L’infrastructure est totalement submergée. Pire encore, l’activation des portails n’a fait qu’accentuer le problème, car il est possible de cliquer dessus à répétition, ce qui génère encore plus de requêtes. Nous désactivons les portails.

Nous faisons tout notre possible pour qu’un maximum de joueurs et de joueuses puisse jouer, mais le service ne se comporte pas du tout comme lors des phases de test. Nous procédons par élimination, grâce aux données récoltées pendant ces phases de test.

Il commence à se faire tard, mais une partie de l’équipe continue de travailler à résoudre les problèmes, pendant que les autres vont se reposer afin de pouvoir revenir prendre le relais à la première heure.

Mardi matin, nous avons une bien meilleure vue d’ensemble du problème. Nous savons maintenant que les clients de jeu reçoivent trop d’informations pour la gestion des quêtes. Nous comprendrons plus tard que ce n’est pas la cause initiale du problème. Notre protocole API sollicite beaucoup trop le NFS. Le code qui gère les nouvelles interactions avec les PNJ est anormalement lent. Le service met trop de temps à envoyer aux clients de jeu toutes les modifications de données apportées dans les correctifs. Les joueurs et joueuses qui ont pu rejoindre les îles aux Dragons souffrent à présent d’une latence énorme.

Mercredi matin, le hasard joue en notre faveur : en fouillant le code en question, nous découvrons des interactions inhabituelles avec le système de chiffrement. Nous commençons à nous demander si le système de chiffrement ne serait pas à l’origine de tous ces problèmes. Et en effet, cela se révèle être exact. La lenteur du système de chiffrement explique tous les autres problèmes de transfert de données, de NFS, de surcharge processeur et de latence. Une fois la source du problème identifiée, l’auteur du système en question est en mesure de rapidement corriger les erreurs.

Cependant, implémenter un correctif dans un code utilisé par tellement du services différents ne se fait pas d’une simple pression sur un bouton. Il va maintenant falloir transférer tous les personnages vers de nouvelles simulations pour qu’elles s’effectuent en tenant compte des correctifs. Nous nous précipitons d’ailleurs un peu trop, ce qui génère une charge supplémentaire sur un autre service. Un redémarrage des serveurs va s’imposer, mais nous le repoussons pour l’appliquer en heure creuse et ne pas ajouter à la contrariété des joueurs et joueuses. Une fois le correctif en place, les performances et la stabilité ont été grandement améliorées.

Il n’a pas été aisé d’identifier le problème et de le corriger, mais notre équipe s’est montrée très réactive et appliquée, et a pu déployer un correctif aussi vite que possible. En ingénierie logicielle, l’objectif n’est pas de jamais faire d’erreur, mais d’essayer de réduire au maximum les chances qu’elles se produisent, d’être capable de les identifier rapidement lorsqu’elles se produisent, d’avoir les bons outils à disposition…

… et une incroyable équipe prête à surmonter tous les obstacles.

– L’équipe technique de World of Warcraft