> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/fr/2020/w29-business-metrics-monitoring-and-end-to-end-canary-releases.md).

# W29-Suivi des indicateurs métier et déploiement progressif de bout en bout

L'incident Meituan Pay de mercredi m'inspire deux réflexions.

J'ai participé à presque toutes les étapes clés, de la découverte à la réponse, au diagnostic puis à la suppression de l'impact. Les conséquences finales n'étaient pas très graves, mais les risques étaient ouverts tout au long du parcours, **révélant en partie notre risque systémique. Nous devons en tirer les leçons.**

* **Découverte et réponse passives et lentes.** Le canal concerné était le paiement bancaire en ligne. Après la redirection, toute la chaîne attendait le callback de succès du paiement unifié. L'anomalie survenait chez la banque, invisible pour le frontend et le backend du module. Le client a donc signalé le problème au métier, qui nous l'a transmis. Quand les retours se sont multipliés mercredi après-midi, nous ignorions depuis quand il existait et quelle version l'avait introduit, compliquant le diagnostic.
* **Diagnostic désordonné.** Sans version identifiée, toute la chaîne, du frontend au service le plus aval, a dû être examinée. Tous les rôles participaient dans la confusion. Le premier réflexe devrait être de limiter les pertes et revenir en arrière. Mais personne ne savait quel composant, quel moment ni quelle version étaient responsables ; la localisation a donc pris du temps.

Deux leçons.

* **Faire résolument avancer le suivi métier.** L'indicateur essentiel est le **taux de succès du paiement**. J'en comprenais mal l'intérêt en temps réel, mais cet incident m'a convaincu. Pour les dépendances tierces, banque, WeChat ou Alipay, leurs erreurs nous échappent ; seul ce taux en temps réel permet de les voir. Le B2B ne dispose que d'un rapport à J+1, sans temps réel ni alerte. **Deux voies sont possibles.** Faire construire cette capacité par le backend et l'équipe données : une tentative avait échoué faute de motivation, mais l'incident peut changer leur attitude. Ou la construire côté frontend avec raptor, via des indicateurs composites surveillant l'évolution relative du taux. Les valeurs absolues frontend sont imparfaites, mais suffisantes pour détecter vite. **Le suivi frontend du paiement sera une priorité du plan du troisième trimestre.**
* **Faire avancer le déploiement progressif B2B de bout en bout.** Meituan Pay a créé un groupe dédié à l'amélioration des alertes après l'incident. Profitons-en pour relier frontend et backend. Aujourd'hui, le frontend peut répartir selon le suffixe du numéro tradeno, mais un même utilisateur peut alors voir différentes versions au fil des commandes, ce qui dégrade l'expérience. Il peut aussi publier sur une machine pilote, configurer une liste d'utilisateurs, valider puis généraliser. Aucun choix n'est optimal. **Nous espérons construire au troisième trimestre un déploiement fondé sur un identifiant utilisateur unique, pour sécuriser les évolutions et préparer les tests A/B.**