👆🏻 ✡️ 🖱️ L'histoire de l'oiseau Dodo du genre Phoenix. La grande chute de Dodo EST 👏🏻 🤾🏽 👨‍👨‍👧‍👧

Chaque année le 21 avril, nous rappelons l'histoire de la Grande Chute de Dodo IS en 2018. Le passé est un enseignant cruel mais juste. Il vaut la peine de s'en souvenir, de répéter les leçons, de transmettre les connaissances accumulées aux nouvelles générations et de se référer avec reconnaissance à ce que nous sommes devenus. Sous la coupe, nous voulons vous raconter une histoire et comment partager les conclusions. Vous ne pouvez même pas souhaiter une telle situation à l'ennemi.

Grande histoire d'automne

Jour 1. L'accident qui nous a coûté des millions de roubles

Le samedi 21 avril 2018, le système Dodo IS est tombé. Tombé très mal. Pendant plusieurs heures, nos clients n'ont pu passer de commande ni via le site ni via l'application mobile. La ligne d'appels vers le centre d'appels a atteint un tel niveau que la voix automatique du répondeur indique: "Nous vous rappellerons dans 4 heures."

Ce jour-là, nous avons connu l'une des chutes les plus graves de Dodo IS. Le pire, c'est que la veille, nous avons lancé la première campagne de publicité télévisée fédérale avec un budget de 100 millions de roubles. Ce fut un grand événement pour Dodo Pizza. L'équipe informatique était également bien préparée pour la campagne. Nous avons automatisé et simplifié le déploiement - maintenant, à l'aide d'un seul bouton dans TeamCity, nous pouvions déployer un monolithe dans 12 pays. Nous n'avons pas fait tout ce qui était possible et avons donc foiré.

La campagne publicitaire était incroyable. Nous avons reçu 100 à 150 commandes par minute. C'étaient de bonnes nouvelles. La mauvaise nouvelle: Dodo IS n'a pas pu supporter une telle charge et est décédé. Nous avons atteint la limite de la mise à l'échelle verticale et ne pouvions plus traiter les commandes. Le système a été instable pendant environ trois heures, récupérant périodiquement, mais est immédiatement tombé à nouveau. Chaque minute d'arrêt nous a coûté des dizaines de milliers de roubles, sans compter la perte de respect des clients en colère. L'équipe de développement a laissé tomber tout le monde: clients, partenaires, gars des pizzerias et centre d'appels.

Nous n'avions pas d'autre choix que de retrousser nos manches et de nous asseoir pour corriger la situation. Depuis dimanche 22 avril, nous avons travaillé en mode dur, nous n'avons pas eu le droit de nous tromper.

Ce qui suit est notre résumé de l'expérience sur la façon de nous retrouver dans une telle situation et comment en sortir plus tard. Amis, ne faites pas nos erreurs.

Deux échecs qui ont lancé l'effet Domino

Cela vaut la peine de commencer par la façon dont tout a commencé et où nous avons foiré.

Le samedi 21 avril 2018, vers 17 h, nous avons remarqué que le nombre de verrous dans la base de données commençait à augmenter - signe avant-coureur de problèmes. Nous avions un runbook prêt à résoudre, car nous comprenions d'où venaient ces verrous.

Tout s'est mal passé après l'échec du runbook à deux reprises. Pendant quelques minutes, la base est revenue à la normale, puis a recommencé à s'étouffer avec les serrures. Hélas, la base de données master rollback_on_timeout avait 600 secondes, c'est pourquoi tous les verrous s'accumulaient. Il s'agit du premier fichier important de cette histoire. Une configuration simple pourrait tout sauver.

Ensuite, il y a eu des tentatives pour ramener le système à la vie à bien des égards, mais aucune n'a réussi. Jusqu'à ce que nous réalisions qu'il y a une différence dans le schéma de réception des commandes dans l'application mobile et sur le nouveau site. En les coupant à leur tour, nous avons pu comprendre où se trouvaient les trous dans l'ancien schéma de prise de commande.

Le système d'acceptation des commandes a été rédigé il y a longtemps. À cette époque, il était déjà en cours de traitement et il a été déployé sur le nouveau site dodopizza.ru. Il n'était pas utilisé dans l'application mobile. Initialement, les raisons de la création d'un nouveau système de commande étaient liées à des règles purement commerciales; les problèmes de performance n'étaient même pas à l'ordre du jour. Il s'agit du deuxième fichier important - nous ne connaissions pas les limites de notre système.

Jour 2. Élimination des accidents

La réponse de l'équipe a été très révélatrice. Notre station-service a écrit un article sur Slack, et tout le monde est venu le lendemain - le 22 avril, le travail a commencé à 8h30 du matin. Personne n'avait besoin d'être persuadé ou invité à venir son jour de congé. Tout le monde a tout compris: ce qui doit être pris en charge, aidé, avec ses mains, avec sa tête, dans les tests, l'optimisation des requêtes, les infrastructures. Certains sont même venus avec toute la famille! Les gars des équipes voisines, non liées à l'informatique, sont venus au bureau avec de la nourriture, et le centre d'appels a apporté des forces supplémentaires au cas où. Toutes les équipes réunies dans un même objectif - se lever!

Une nouvelle réception de la commande était le principal objectif du dimanche 22 avril. Nous avons compris que le pic des commandes serait comparable à samedi. Nous avions le délai le plus sévère - à 17 heures, une nouvelle vague de commandes tombera.

Ce jour-là, nous avons agi selon le plan "pour nous assurer qu'il ne tombe pas", que nous avons élaboré la veille du 21e jour en fin de soirée, alors que nous avions déjà soulevé le système et compris ce qui s'était passé. Le plan était conditionnellement divisé en 2 parties:

Mise en place du schéma avec une nouvelle commande dans l'application mobile.
Optimisation du processus de création de commande.

En implémentant ces choses, nous pouvons être sûrs que Dodo IS ne tombera pas.

Nous déterminons le front du travail et le travail

La mise en œuvre du programme avec une nouvelle commande dans une application mobile était la plus haute priorité. Nous ne disposions pas de chiffres exacts pour l'ensemble du système, mais dans certaines parties, le nombre et la qualité des requêtes vers la base de données, nous avons savamment compris que cela augmenterait la productivité. Une équipe de 15 personnes a travaillé sur la tâche jour après jour.

Bien qu'en fait l'introduction d'un nouveau schéma de commande, nous avons commencé avant la chute du 21/04, mais n'avons pas terminé la transaction. Il y avait encore des bogues actifs et la tâche se bloquait dans un état semi-actif.

L'équipe a divisé la régression en plusieurs parties: régression à partir de deux plateformes mobiles, plus gestion de pizzeria. Nous avons passé beaucoup de temps manuellement à préparer des pizzerias de test, mais une séparation claire a permis de paralléliser la régression manuelle.

Dès qu'un changement a été introduit, il a été immédiatement déployé dans l'environnement de pré-production et testé instantanément. L'équipe était toujours en contact les uns avec les autres, ils étaient vraiment assis dans une grande salle avec des lieux de rencontre. Les gars de Nizhny Novgorod et Syktyvkar étaient également toujours en contact. S'il y avait une prise, il a immédiatement décidé.

Habituellement, nous sortons progressivement de nouvelles fonctionnalités: 1 pizzeria, 5 pizzerias, 10 pizzerias, 20 pizzerias et ainsi de suite sur l'ensemble du réseau. Cette fois, nous devions agir de manière plus décisive. Nous n'avions pas le temps - à 17 heures un nouveau pic a commencé. Nous ne pouvions tout simplement pas manquer de l'attraper.

Vers 15h00, la mise à jour a été déployée sur la moitié du réseau (environ 200 pizzerias). À 15h30, nous nous sommes assurés que tout fonctionnait bien et avons allumé l'ensemble du réseau. Les fonctions bascule, les déploiements rapides, la régression divisée en parties et l'API fixe ont aidé à faire tout cela.

Le reste de l'équipe a traité différentes options d'optimisation lors de la création d'une commande. Le nouveau schéma n'était pas entièrement nouveau, il utilisait toujours la partie héritée. Enregistrer des adresses, appliquer des codes promotionnels, générer des numéros de commande - ces pièces étaient et sont restées courantes. Leur optimisation a été réduite soit à la réécriture des requêtes SQL elles-mêmes, soit à leur suppression dans le code, soit à l'optimisation de leurs appels. Quelque chose s'est passé en mode asynchrone, quelque chose, comme il s'est avéré, a été appelé plusieurs fois au lieu d'une.

L'équipe d'infrastructure s'est engagée à allouer une partie des composants à des instances distinctes simplement pour ne pas traverser la charge. Notre principal problème était la façade Legacy, qui est allée à la base Legacy. Tout le travail lui était consacré, y compris la division des instances.

Organisez le processus

Le matin, nous avons eu la seule synchronisation de la journée, nous sommes entrés en équipes et sommes partis travailler.

Au début, nous avons conservé l'intégralité du journal des modifications et des tâches directement dans Slack, car au début, il n'y avait pas tellement de tâches. Mais leur nombre augmentait, nous avons donc rapidement déménagé à Trello. L'intégration configurée entre Slack et Trello a notifié tout changement d'état dans le puzzle.

De plus, il était important pour nous de voir l'intégralité du journal des changements de production. La version électronique était à Trello, la version de sauvegarde était sur la carte d'infrastructure sous forme de cartes. En cas de problème, nous devions trouver rapidement les modifications à annuler. La régression complète ne concernait que le schéma avec un nouvel ordre, les autres modifications ont été testées plus fidèlement.

Les tâches ont volé à la production à une vitesse de balle. Au total, nous avons mis à jour le système 15 fois ce jour-là. Les gars ont été déployés sur des bancs d'essai, un par équipe. Développement, contrôle rapide, déploiement en production.

En plus du processus CTO principal, Sasha Andronov a constamment rencontré des équipes avec la question «Comment aider?». Cela a permis de redistribuer les efforts et de ne pas perdre de temps sur le fait que quelqu'un n'a pas pensé à demander de l'aide. Gestion du développement semi-manuel, un minimum de distractions et un travail à la limite.

Après cette journée, il fallait sortir avec le sentiment que nous faisions tout ce que nous pouvions. Et encore plus. Et nous l'avons fait! A 15h30, un nouveau schéma d'acceptation des commandes a été déployé pour l'application mobile sur l'ensemble du réseau. Mode Hackathon, moins de 20 déploiements par production par jour!

La soirée du 22 avril fut calme et claire. Ni les chutes ni le moindre indice n'est que le système peut être mauvais.

Vers 22 heures, nous nous sommes à nouveau réunis et avons défini un plan d'action hebdomadaire. Limitation, tests de performances, ordre asynchrone et bien plus encore. Ce fut une longue journée, et il y avait de longues semaines à venir.

Renaissance

La semaine du 23 avril a été infernale. Après cela, nous nous sommes dit que nous avions fait de notre mieux à 200% et fait tout ce que nous pouvions.

Nous avons dû sauver Dodo IS et avons décidé d'appliquer une analogie médicale. En général, c'est le premier vrai cas d'utilisation d'une métaphore (comme dans le XP d'origine), qui a vraiment aidé à comprendre ce qui se passait:

Réanimation - lorsque vous devez sauver un patient mourant.
Traitement - lorsqu'il y a des symptômes, mais que le patient est toujours en vie.

Réanimation

La première étape de la réanimation est le runbook standard pour restaurer le système en cas de panne selon certains paramètres. Une chose est tombée - nous le faisons, celle-là est tombée - nous le faisons et ainsi de suite. En cas de plantage, nous trouvons rapidement le runbook souhaité, ils se trouvent tous sur GitHub et sont structurés par problèmes.

La deuxième étape de la réanimation est la limitation des commandes. Nous avons adopté cette pratique à partir de nos propres pizzerias. Lorsque de nombreuses commandes sont déversées à la pizzeria et qu’elles comprennent qu’elles ne peuvent pas les faire cuire rapidement, elles s'arrêtent pendant 5 minutes. Juste pour effacer la ligne de commande. Nous avons fait un schéma similaire pour Dodo IS. Nous avons décidé que si cela devenait vraiment mauvais, nous allumerions la limite générale et informerions les clients, disent-ils, les gars, 5 minutes et nous prendrions votre commande. Nous avons développé cette mesure au cas où, mais en conséquence, nous ne l'avons jamais utilisée. Pas utile. Et gentil.

Traitement

Afin de commencer le traitement, il est nécessaire de faire un diagnostic, nous nous sommes donc concentrés sur les tests de performance. Une partie de l'équipe est allée collecter un profil de charge réel de la production en utilisant GoReplay, une partie de l'équipe s'est concentrée sur les tests synthétiques sur scène.

Les tests synthétiques ne reflétaient pas le profil de charge réel, mais ils ont donné lieu à des améliorations, ont montré certaines faiblesses du système. Par exemple, peu de temps avant, nous déplacions le connecteur MySQL d'Oracle vers un nouveau . Dans la version du connecteur, il y avait un bug avec les sessions de mise en commun, ce qui a conduit au fait que les serveurs ont simplement atteint le plafond du processeur et ont cessé de servir les demandes. Nous l'avons reproduit avec des tests Stage, conçu et mis en production en silence. Il y a eu une douzaine de cas de ce type.

Lorsqu'ils diagnostiquent et identifient les causes des problèmes, ils sont corrigés de façon ponctuelle. Nous avons en outre compris que notre moyen idéal est la réception asynchrone d'une commande. Nous avons commencé à travailler sur son introduction dans une application mobile.

Hell semaines: organisation des processus

Une équipe de 40 personnes a travaillé sur un seul grand objectif: la stabilisation du système. Toutes les équipes ont travaillé ensemble. Je ne sais pas quoi faire? Aidez les autres équipes. Se concentrer sur des objectifs spécifiques a aidé à ne pas se faire asperger et à ne pas se livrer à des bêtises qui n'étaient pas nécessaires pour nous.

Trois fois par jour, il y avait la synchronisation, un stand-up commun, comme dans une mêlée classique. Pour 40 personnes. Seulement deux fois en trois semaines (pour près de 90 synchronisations), nous n'avons pas rencontré 30 minutes. La synchronisation la plus longue a duré 57 minutes. Bien que cela prenne généralement 20 à 30 minutes.

Le but des synchronisations: comprendre où l'aide est nécessaire et quand nous allons mettre ces tâches en production. Les gars se sont unis dans les équipes de projet, si une aide aux infrastructures était nécessaire, une personne est venue sur place, tous les problèmes ont été résolus rapidement, moins de discussions étaient plus importantes.

Le soir, afin de soutenir les gars, notre laboratoire R&D a préparé de la nourriture pour les développeurs pour la soirée. Recettes de pizza folles, ailes de poulet, pommes de terre! C'était vraiment cool! Un tel soutien a motivé autant que possible les gars.

Travailler dans un tel mode non-stop était sacrément difficile. Le mercredi 25 avril, vers 17 heures, Oleg Blokhin, l'un de nos développeurs, a approché CTO, qui figurait samedi sans s'arrêter. Il y avait une fatigue inhumaine dans ses yeux: "Je suis rentré chez moi, je ne peux plus le supporter." Il dormait bien et le lendemain était copieux. Vous pouvez donc décrire l'état général de nombreux gars.

Le samedi suivant, le 28 avril (c'était un samedi de travail pour tout le monde en Russie) était plus calme. On ne pouvait rien changer, on regardait le système, les gars se reposaient un peu du rythme. Tout s'est bien passé. La charge n'était pas si énorme, mais elle l'était. Ils ont survécu sans problème, ce qui donne confiance que nous allons dans la bonne direction.

Les deuxième et troisième semaines après la chute étaient déjà dans un mode plus calme, le rythme infernal jusque tard dans la soirée avait disparu, mais le processus général de la loi martiale était resté.

Jour suivant X: test de résistance

Le lendemain, X était le 9 mai! Quelqu'un était assis à la maison et surveillait l'état du système. Ceux d'entre nous qui sont allés se promener ont pris des ordinateurs portables avec nous pour être complètement armés en cas de problème. Sasha Andronov, notre station-service, s'est rapprochée du pic du soir d'une des pizzerias afin de tout voir en personne en cas de problème.

Ce jour-là, nous avons reçu 91500 commandes en Russie (à l'époque le deuxième résultat de l'histoire du Dodo). Il n'y avait même pas la moindre trace de problème. Le 9 mai a confirmé que nous étions sur la bonne voie! Concentrez-vous sur la stabilité, les performances, la qualité. La restructuration du processus nous attendait davantage, mais c'est une toute autre histoire.

Grand automne rétro et 6 pratiques

Dans les situations critiques, de bonnes pratiques sont développées qui peuvent et doivent être transférées à un moment de tranquillité. Concentration, aide inter-équipes, déploiement rapide en production sans attendre une régression complète. Nous avons commencé avec rétro, puis développé le cadre du processus.

Les deux premiers jours se sont écoulés sur une discussion des pratiques. Nous ne nous étions pas fixé pour objectif de "mettre une rétrospective à 14 heures". Après une telle situation, nous étions prêts à prendre le temps d'élaborer nos idées et notre nouveau processus en détail. Tout le monde a participé. Tous ceux qui ont participé d'une manière ou d'une autre aux travaux de restauration.

Par conséquent, il y a 6 pratiques importantes dont j'aimerais parler plus en détail.

Top N . , . Product Owners , , , . . , . , , , . , . N – Lead Time .
. . -, , . , , , . .
. , « » . , . , , . , - . Dodo IS. .
Pull Request. , Pull Request, - . . , , , , - . , . , . 15 .
Performance- — . performance- . , . Performance- . baseline , PR . , .
Performance . — . , , -, , , . . , .

21.04.2018 – Dodo IS. ?

(Site Reliability Engineering): . , .

(Site Reliability Engineering, Product Owner Dodo IS): . , , .

auth’, . . , .

, () :

. , .

. , . . -. , , . - , , . , -, , .

. redis, . . - , . .

Dodo IS . . , . , , , , . , — .

. « ». « , » .

- ?

:

– . . . , . . .

:

. , . ( ), - . .

. :

?

:

, , , .

:

, , . , .

? ?

: , – .

— . - - .

, . 2018 , PerformanceLab, .
, . Less-.
. 2018 -, . , . - 2018 .
async . , 21.04.2018 . , . async.
. , SaveOrder async-await. , . : , LF, 20 . , . , . !

, , , .

, , . — -. .
. , (, ). , . «» . nginx , - , .

: innodb_lock_wait_timeout = 5; innodb_rollback_on_timeout = ON. . , , , , .

, ?

, , , . , .
, .
, , , . – .

.
. , , -. .
. , - , .

, ?

:

«» , «». , , . .

:

, . , , . .

2. , (Dodo IS Architect)

— , . , — .

, , . , (, , ) .

IT-. Dodo IS, . …

X , . . Dodo IS , , , . , , , . . 146%, . , Dodo IS ?

, . , , . , . , !

, . « »: 11- , , 2 . «» . 3-4 , . , . .

, , . . Dodo IS , « ». ! ( ).

, Dodo IS , . Dodo IS . « », , . ( ), loadtest, , .

L'histoire de l'oiseau Dodo du genre Phoenix. La grande chute de Dodo EST