Bonjour à tous,

Le 24 septembre, nous avons tenté de lancer la tant attendue première bêta du système de restructuration des mondes ! Vous le savez sans doute, tout ne s’est pas exactement déroulé comme prévu. Aujourd’hui, nous souhaitons partager avec vous notre post-mortem de l’événement. Le post-mortem est un procédé utilisé par les équipes de développement pour faire le point sur un événement (lancement, panne, etc.) et déterminer ce qui s’est bien passé et ce qui aurait pu mieux se passer, l’objectif étant d’identifier des améliorations de processus applicables à l’avenir. Nous avons pris quelques libertés créatives avec le format pour le rendre un peu plus accessible aux lecteurs, mais nous espérons que vous apprécierez ce petit aperçu du travail effectué en coulisses.

Dans cet article, vous trouverez un résumé du déroulement de la tentative de bêta, un aperçu des problèmes que nous avons rencontrés et des explications sur ce que nous en avons appris. Enfin, nous vous présenterons nos plans pour la prochaine bêta.

Avant d’entrer dans le vif du sujet, nous souhaitons préciser que ce qui est arrivé n’a aucun rapport avec la courte panne de connexion ayant impacté les serveurs européens juste avant la tentative de bêta. Voilà au moins une théorie que vous pouvez écarter !

Résumé

Le vendredi 24 septembre à 19 h, heure de Paris (10 h, heure du Pacifique), durant la réinitialisation hebdomadaire du Monde contre Monde européen, nous avons activé la fonction de restructuration des mondes. Lors de la réinitialisation, le McM est vidé de ses joueurs, les appariements sont reconfigurés et les scores réinitialisés. En profiter pour activer la restructuration des mondes devait permettre à la bêta de partir sur des bases vierges.

L’activation s’est déroulée avec succès sur les serveurs de jeu en ligne européens (premier obstacle), mais nous avons très vite commencé à recevoir des signalements de joueurs qui n’étaient pas placés dans les bonnes équipes (au cinéma, c’est là que la lumière vire au rouge et que les alarmes retentissent). À l’origine du problème, des fragments de données obsolètes qui n’avaient pas été mis à jour chez certains joueurs avant que ceux-ci essaient d’accéder au McM. Chez les joueurs impactés, le client de jeu effectuait la demande d’accès en utilisant ces vieux fragments de données. Résultat, les joueurs étaient placés sur la mauvaise carte et se voyaient même attribuer la mauvaise couleur d’équipe. Ajoutez à cela un problème d’IU n’affichant pas les bons noms d’équipes, et vous obtenez une confusion générale.

Intervient alors un second problème.

Cet événement bêta était très attendu, c’est peu de le dire. De plus, avec la réinitialisation du vendredi, le taux de participation était incroyablement élevé et, par conséquent, les files d’attente pour accéder aux cartes très longues. Naturellement, afin de tuer le temps, les joueurs ont commencé à entrer sur la carte de débordement de la lisière des Brumes. Alors que nous cherchions à résoudre le premier problème mentionné plus haut, nous avons reçu un message de Robert Neckorcuk, notre ingénieur en chef des serveurs (que vous connaissez pour l’article « Dans les coulisses d’ArenaNet : analyse d’une panne du jeu »). Il souhaitait nous alerter sur la quantité anormalement élevée de ressources serveur utilisées pour les instances de la lisière des Brumes, environ trente fois supérieure à la norme.

Cela n’était toutefois pas lié à la hausse d’activité des joueurs, mais à quelque chose de plus insidieux. Nous constations que de nouvelles instances de la lisière des Brumes étaient créées, alors même que celles qui existaient déjà étaient encore loin de leur pleine capacité. En d’autres termes, le nombre d’instances créées était bien trop élevé par rapport au nombre de joueurs actifs, ce qui consommait une grande partie de nos ressources serveur. Et vous pouvez nous croire, lorsque la capacité des serveurs vient à manquer, ce n’est jamais une bonne chose. Il en a découlé une sorte d’effet de serre que nous devions surveiller et résoudre manuellement. Le plus préoccupant, c’est que nous ignorions pourquoi tant d’instances étaient créées, et cela a clairement ébranlé notre confiance en notre capacité à résoudre rapidement les problèmes de la bêta. C’est ce moment qu’a choisi un autre de nos ingénieurs pour nous signaler un troisième problème. Jamais deux sans trois !

Lorsque nous intégrons du contenu inédit, de nouvelles fonctionnalités ou que nous lançons un événement bêta, nous essayons d’ajouter des processus de consignation supplémentaires. Il s’agit de journaux enregistrant toutes les opérations réalisées au sein d’un système. Ils nous permettent de vérifier que le système en question fonctionne comme prévu, d’avoir une idée des problèmes rencontrés et nous aident à identifier les solutions éventuelles. Nous avons des serveurs entiers consacrés à la gestion de tous les journaux générés par le jeu. Eh bien, ce jour-là, ces serveurs ont rencontré un obstacle. Le nouveau serveur de restructuration des mondes, BattleSrv, transmettait une erreur à une fréquence tellement élevée qu’elle mettait notre infrastructure de journalisation sous forte pression. Ces serveurs de journalisation étant essentiels au fonctionnement de Guild Wars 2, la situation était pour le moins inquiétante.

C’est difficile à croire, mais ces quatre petits paragraphes ne résument que deux heures de cette journée, au cours desquelles l’expérience McM en Europe s’est fortement dégradée. Nous avons rassemblé toute l’équipe et défini deux voies possibles pour la suite.

Première option : mettre en œuvre une poignée de correctifs à court terme pour tenter de faire fonctionner la bêta (autant vous dire que ce n’était pas gagné). Cela aurait nécessité le déploiement d’un « serveur vierge » et, pour les joueurs, une déconnexion et le téléchargement d’une mise à jour mineure du client. Cette méthode aurait entraîné un rafraichissement forcé des données pour chacun des joueurs impactés par le problème de données obsolètes, qui auraient alors été réaffectés aux bonnes équipes. Nous pensons que cette solution aurait permis de résoudre le problème, mais nous n’avions aucun moyen de la tester avant de la mettre en œuvre. De plus, il n’existait aucune garantie que les autres problèmes ne continueraient pas de se manifester au cours de la semaine de bêta, à mesure que de nouveaux joueurs se connecteraient pour y participer. Nous aurions sans doute également dû remettre en place cette même mise à jour de « serveur vierge » quelques heures plus tard, après la réinitialisation hebdomadaire en Amérique du Nord. Dans ce scénario, il aurait aussi fallu désactiver la carte de la lisière des Brumes pour toute la durée de la bêta, afin d’atténuer le problème d’utilisation du serveur. Nous avons trouvé une solution au problème de journalisation, mais la mise en place du changement requis aurait été longue (d’autant plus un vendredi soir). Pendant ce temps, nos serveurs auraient continué à souffrir.

Deuxième option : mettre fin prématurément à la bêta. Vous l’aurez compris, c’est ce que nous avons choisi de faire, et pour une raison simple : la première option comportait trop de risques et d’inconnues. Une fois prise la décision de mettre un terme à la bêta et après un redémarrage rapide des cartes McM, nous avons pu rétablir sans difficulté le système d’association de mondes.

Quelques heures plus tard…

Après un court moment de répit, l’équipe s’est à nouveau réunie pour établir un post-mortem, ainsi qu’un plan d’action pour remédier aux problèmes rencontrés. Voici nos plus grandes victoires de la journée :

Même si cela peut paraître étonnant, le système de restructuration des mondes a fonctionné avec succès, et cette étape déterminante a renforcé notre confiance en cette technologie ! Pour chaque joueur mal assigné à une équipe, d’autres, plus nombreux, ont été correctement placés. L’activation réussie de la restructuration des mondes nous a permis, au cours de ces deux heures de tentative de bêta, de recueillir suffisamment de données pour identifier les causes de ces problèmes dans le code. L’apparition de ces problèmes en jeu live nous aura également aidés à mieux comprendre comment améliorer nos processus internes de test pour un meilleur repérage des problèmes au cours du développement de la restructuration des mondes. Tester intégralement des fonctions de serveur à grande échelle lors du développement peut être difficile, tout particulièrement dans le cas d’un système sur mesure comme celui-ci.

Ensuite, l’algorithme de matchmaking employé pour la première bêta a réparti les joueurs et les guildes en équipes de manière incroyablement équitable. Avec le système d’association de mondes, il existe jusqu’à 50 % de différence d’activité des joueurs entre certains mondes. La plus grande différence enregistrée entre deux équipes lors de la première bêta était de 2 %, ce qui représente une amélioration considérable. La création de matchs équilibrés étant le principal objectif du système de restructuration des mondes, nous sommes ravis de ce résultat.

Enfin, nous sommes parvenus à rétablir le système d’association de mondes sans grande difficulté après avoir mis fin à la bêta. Cela découle notamment du fait que notre équipe était convenablement préparée à un tel scénario, grâce à un dossier d’exploitation détaillé préalablement établi en vue de restaurer le système. Nous avions testé ce processus à de multiples reprises sur nos serveurs de développement, mais jamais à une échelle comparable à celle du jeu live. L’entraînement a porté ses fruits !

Et ensuite ?

Nous avons identifié dix bugs à corriger impérativement avant d’essayer une nouvelle bêta, la plupart étant liés aux problèmes de données obsolètes mentionnés précédemment et à l’affichage incorrect des noms d’équipes. Nous avons déjà réalisé des progrès significatifs, mais il reste encore beaucoup à accomplir. Pour le moment, nous espérons pouvoir sortir ces correctifs lors de la mise à jour du 9 novembre et lancer notre prochaine bêta le 12 novembre.

Nous préparons également plusieurs améliorations de confort en Monde contre Monde pour la mise à jour du 9 novembre. Vos retours sont clairs : la progression dans les parcours d’escarmouche est trop longue, notamment pour les nouveaux joueurs et pour ceux de la troisième équipe associée. Pour y remédier, nous allons augmenter le nombre de points attribués selon le classement de l’escarmouche de 3/4/5 à 4/5/6. Nous ajouterons également +1 point d’escarmouche bonus aux joueurs de rang McM 1 à 149. Les points bonus déjà conditionnés au rang seront également augmentés de +1 (soit un total de +2 au rang bronze, +3 au rang argent, etc.).

Nous avons aussi étudié des éléments des parcours d’escarmouche et du système de participation qui, à l’heure actuelle, ne remplissent pas leurs objectifs initiaux. À court terme, nous essaierons de supprimer certains avantages obtenus via un imprévu de gameplay, ainsi que les « périodes de grâce » conférées par la réparation de structures en McM. De plus, nous allons supprimer le point bonus d’infériorité en nombre, mais l’amélioration du même nom sera conservée.

C’est tout pour aujourd’hui ! Merci de votre attention.

À bientôt,
— L’équipe Guild Wars 2