- La panne de 36 heures de CookieRun: Kingdom, la plus longue de l’histoire de Devsisters
- Utilisation de CockroachDB comme base de données distribuée principale : 4 nœuds, 12 To de stockage, 7 réplicas
- Pendant une opération d’extension de la base de données, la moitié des nœuds est tombée en panne
- Cela a provoqué une panne générale du service, et l’ingénieur support côté CockroachDB a estimé que la restauration était impossible
- Un article qui récapitule les efforts entrepris pour retrouver directement les données stockées dans le stockage
24 commentaires
C’est un billet particulièrement controversé, non… ? Je ne sais pas ce qu’il en est du point de vue du service, mais les développeurs qui ont travaillé dessus ont dû en tirer une énorme fierté.
Je ne sais pas quelle a été la réaction des utilisateurs, mais en tant que joueur, j’ai envie de saluer le fait qu’ils aient essayé d’éviter un rollback des données… Cela dit, si l’on pense à la perte d’utilisateurs et à l’expérience client dégradée pendant 36 heures, le coût a peut-être été encore plus élevé. Du point de vue d’un développeur, je pense malgré tout que c’était un défi intéressant. Si l’entreprise avait été une banque plutôt qu’un jeu, qu’en aurait-il été ?
Il paraît que Pokémon Go utilise Spanner de GCP (https://cloud.google.com/blog/topics/…), et il n’y a effectivement pas vraiment d’alternative adéquate sur AWS.
Au vu de l’intention de l’équipe de développement telle qu’on peut la déduire de ce document, il n’aurait pas fallu utiliser CockroachDB dans ce projet.
Quelle base de données aurait-il fallu utiliser ?
Selon le service, le contenu peut être assez glaçant.
J’ai pris plaisir à le lire.
Il semble que le blog ait publié une série d’articles sur cet incident. En les lisant d’un bout à l’autre, j’ai trouvé particulièrement frappant le niveau de panique mentale qu’ont dû ressentir les personnes chargées de rattraper la situation.
Je ne sais pas vraiment si, d’un point de vue business, il était juste de passer 36 heures à restaurer les informations de tous les utilisateurs plutôt que d’opter pour un rollback qui dégrade l’expérience d’une partie des utilisateurs mais protège la majorité. Du point de vue d’un développeur, en revanche, ce sont des éléments intéressants.
Il y a ce passage dans le corps de l’article.
Offrir la meilleure expérience possible à nos clients est notre mission, et nous nous sommes efforcés de la mettre en pratique avec sincérité. Personne ne s’est laissé abattre ni n’a renoncé.
Même ici, j’en arrive à entendre qu’on peut abandonner une partie des utilisateurs pour de l’argent, et cela me rappelle une fois de plus la manière dont les joueurs sont traités dans l’industrie du jeu en Corée.
Je pense que c’est une lecture un peu trop tordue, et rétrospectivement, s’ils n’avaient pas réussi à résoudre le problème, ils auraient à la fois perdu du temps et subi des reproches pour le rollback des données.
Et du point de vue selon lequel, quand le service ne fonctionne pas, on abandonne les utilisateurs pendant tout ce temps, cela reste tout aussi vrai.
Je compatis très, très fortement...
Du point de vue d’un développeur, c’était une lecture extrêmement intéressante (titre sensationnaliste compris), mais j’avais moi aussi une vision assez proche. Comme il s’agit d’éléments mentionnés dans un article un peu ancien, il peut y avoir un écart avec la réalité, mais il me semble que le chiffre d’affaires de Cookie Run: Kingdom dépassait les 300 milliards de wons ; ils ont donc sans doute comparé les recettes attendues correspondant à 36 heures d’indisponibilité avec le montant des compensations versées après le rollback avant de prendre leur décision.
Je pense aussi que le fait qu’il s’agisse d’une organisation où la culture développeur, très axée sur la résolution de problèmes, est forte a dû avoir une certaine influence.
Même aujourd’hui, je ne sais toujours pas très bien quelle décision j’aurais prise à leur place.
De nos jours, dans les jeux (surtout ceux avec des systèmes de tirage aléatoire), un rollback est... vraiment une méthode qu’on ne peut utiliser qu’en tout dernier recours... À moins de ne pas se soucier de son image comme le jeu L, c’est impossible, donc dans ce cas précis, le fait de ne pas avoir fait de rollback et d’avoir ensuite offert une grosse compensation a plutôt amené les joueurs à plaisanter entre eux en disant : si on manque de ressources, est-ce que le serveur ne pourrait pas encore tomber une fois ? Je pense que c’était la bonne décision.
Comme il s'agit d'un jeu, j'imagine qu'un rollback de 36 heures aurait pu entraîner d'importantes pertes financières liées au cash.
Je vote pour dire que ça ne semble pas être une décision judicieuse d’un point de vue business.
Une erreur de configuration involontaire (la plus critique, un véritable cas absurde d’erreur humaine. Une manipulation énorme qui a fini par empêcher le fonctionnement du réplica de cette manière ; même en faisant venir tous les concepteurs et développeurs de la base de données, ça, c’est irrécupérable)
Donc, comme on ne pouvait pas se permettre de perdre toutes les données... il a fallu renoncer à la cohérence des données les plus récentes et aller chercher directement les données DB dans leur forme binaire finale enregistrée (7 To), puis écrire un programme en Go pour les convertir en csv... ?
Se lancer dans la création d’un programme Go pour cette conversion, même s’il est parfaitement fait, à quoi bon au fond..
Pff... rien que d’y penser, c’est étouffant. Pourquoi a-t-il fallu en arriver là.. Le plus important, ce sera clairement de renforcer les processus pour éviter ce genre d’erreur humaine. Et évitez de raconter toute l’histoire de la galère à convertir du binaire pendant le traitement de l’incident.
Y a-t-il une autre raison de ne pas raconter ce genre d’histoire ? Publier un post-mortem a déjà du sens en soi.
À mon avis, si l’on veut écrire un article vraiment utile, le titre devrait plutôt être celui-ci, non ?
"Analyse des causes de l’erreur empêchant la formation du cluster en raison d’une mauvaise configuration des nœuds, et enseignements à en tirer"
Ce serait un sujet à part entière pour un autre article, et l’« analyse de la cause de l’incident » ainsi que le « processus de résolution de l’incident » sont deux sujets distincts, tous deux importants ; j’ai du mal à comprendre qu’on rabaisse la valeur de l’article sous prétexte qu’il n’y avait pas d’« analyse de la cause de l’incident »...
Vous pourriez simplement dire qu’il serait encore mieux qu’un article de suivi soit publié sur l’analyse des causes, mais affirmer avant cela que ce texte n’a aucune valeur n’est pas une bonne attitude.
À proprement parler, ce n’était pas un « processus de résolution d’incident », mais plutôt un travail de forçat pour récupérer des données incomplètes. Disons simplement qu’on a un peu réduit l’ampleur des pertes ? À ce niveau-là.
Où est-il écrit, dans le texte ci-dessus, que la récupération des données était « incomplète » ? Au minimum, d’après le contenu de l’article, ils ont réussi une récupération complète. Et si restaurer une base de données détruite n’est pas une résolution d’incident, alors qu’est-ce que c’est ? Le service en question a-t-il cessé de fonctionner tel quel après cet incident ?
Ce n’est pourtant pas une raison pour ne pas raconter cette histoire, non ?
Vous semblez vraiment vous compliquer la vie.