> 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/ja/2020/w29-business-metrics-monitoring-and-end-to-end-canary-releases.md).

# W29-業務指標の監視とエンドツーエンドの段階的リリース

水曜日に美支で発生した本番障害から、二つの考えに広がった。

まず簡単に振り返る。発見、対応、調査、影響の解消まで、私はほぼすべての重要な段階に参加した。最終的な影響範囲と結果は特に深刻ではなかったが、後から見ると、道中はずっとリスクにさらされていた。**ある意味で私たち自身の構造的なリスクを露呈した事例であり、必ず教訓にすべきだ。**

* **発見と対応が受け身で遅かった。** 問題のチャネルはネットバンキング決済だった。利用者が銀行サイトへ移った後、上流も下流も統合決済からの成功コールバックを待つ。しかし異常は銀行側の支払い手順で発生し、決済画面のフロントエンドもバックエンドも検知できなかった。そのため顧客が事業側へ伝え、事業側が決済チームへ伝える経路で発見された。水曜午後に多数の報告を受けても、いつから起きていたのか、どのバージョンで入ったのかが分からず、調査を難しくした。
* **調査が混乱していた。** 原因を入れたバージョンが分からず、フロントエンドから最下流まで、全経路を調べた。すべての役割が入り、現場は混乱した。最初にすべきは被害を止め、速やかに戻すことだ。しかし、どの箇所で、いつ、どの版を公開して起きたのか誰も分からず、特定に長い時間がかかった。

ここから、二つの示唆を得た。

* **第一に、業務指標の監視を確実に進める。** 決済で最も重要な指標は**決済成功率**だ。当初、リアルタイム監視の利益をよく理解していなかったが、この事例が推進する動機になった。ネットバンキング、WeChat、Alipay など第三者へ遷移する場面では、依存先の異常を直接検知できず、決済成功率のリアルタイム監視で初めて発見できる。今の法人向け決済成功率は D+1 の帳票で、リアルタイムでもなく、監視もない。**実装には二つの経路がある。** 一つは決済バックエンドとデータチームに基盤を作ってもらうこと。以前も試したが相手の動機が弱かった。ただし今回を受けて姿勢が変わる可能性はある。もう一つはフロントエンドが raptor で自ら作ることだ。独自の複合指標で、決済成功率の直前期間比の傾向を監視できる。フロントエンドの絶対値は正確でなくても、問題の早期発見には足りる。**Q3 の計画では、決済フロントエンドの監視体系づくりを重点に置く。**
* **第二に、B2B 決済の全経路で段階的リリースを進める。** 障害後、美支側が監視・警告の改善専用グループを作った。この機会に、フロントエンドとバックエンドを通した段階的リリースを進められる。今、決済フロントエンドの選択肢は二つだ。一つは tradeno の注文番号末尾で振り分ける方法だが、同じ利用者が複数回注文すると異なる版の画面へ行き、体験を大きく損なう。もう一つは、段階公開用のサーバーへ出した後、ホワイトリストの利用者で本番検証し、通れば全体へ公開する方法だ。どちらも最適ではない。**Q3 に利用者の一意識別子を軸とした全経路の段階的リリースを確立し、今後の更新を安全で安定したものにし、A/B Test の基盤も整えたい。**