動くものと動かないものを並べて置く
一言でいうと
鑑別診断とは、失敗したサンプルだけを見つめる代わりに、成功したサンプルを並べて置き、すべての失敗にあって、どの成功にもない属性だけを残す手順です。
なぜ必要なのか
「ある顧客は動いて、ある顧客は動きません。」現場で最もよく聞く文であり、同時に最も良い知らせです。動く側があるということは、比較できる対照群があるということだからです。
ところが、たいていはこの知らせを捨てて、失敗したリクエストのログだけを掘り下げます。失敗のログには、TLSハンドシェイクも、リトライも、警告もあります。どれも怪しく見えます。その怪しさが本当に原因なのかを知るには、成功したリクエストのログにも同じものがあるかを見る必要があります。成功にもあるなら、それは原因ではなく背景です。
この手順には名前があります。医学から来た言葉で、鑑別診断(differential diagnosis)といい、ソフトウェアでもこの訳語を使います。核心は1つです。片側だけを見るとすべてが原因候補に見え、両側を見ると大半が自然に消えるのです。
どう動くのか
手順は4つの段階です。
1. サンプルを集める。失敗サンプルだけを20個集めても意味がありません。成功サンプルも、同じくらいの数を集める必要があります。このとき、成功サンプルは失敗と最も似た条件の成功であるほど良いです。まったく別の国の、別のバージョンの成功サンプルは、消してくれるものがあまりありません。
2. 属性に展開する。各サンプルを(属性 = 値)の一覧に変えます。地域、クライアントのバージョン、エンコーディング、認証方式、デバイス、エンドポイント、時間帯です。この一覧を決める作業が、実際には最も難しいです。一覧にない属性は、永遠に候補になりません。
3. 2つの集合を引く。すべての失敗に入っている値の集合から、成功の1つにでも入っている値の集合を引きます。残ったものが候補です。ここで消える値が重要です。「すべての失敗にtoken認証があった」という事実は、成功の3分の1もtokenだったという事実と並べた瞬間、何の意味もなくなります。
4. 候補が2つ以上なら、切り分ける。この場面が、この手順の本当の難しさです。
相関は原因ではありません。同じ時期にデプロイされた2つのものが常に一緒にいると、サンプルだけでは2つを区別できません。表が2つを同じように指すのは、表が間違っているからではなく、データに2つを分ける事例がないからです。分ける方法は2つだけです。
- データをさらに得ます。2つが分かれる組み合わせが1つでも入ってくれば、片方が外れます。新しいサンプルで、Aはあるのに成功した事例、またはBがないのに失敗した事例を探します。
- 介入します。属性を1つだけ変えて、残りを固定し、結果がひっくり返るかを見ます。これが観察と実験の違いであり、実験だけが因果を語れます。
1つの属性で分かれない場合もあります。エンコーディングがutf-8-sigで、かつデバイスがキオスクのときだけ失敗するなら、単独の候補は1つも残りません。それぞれは成功サンプルにもあるからです。そのようなときは、値のペアを候補にして、同じ引き算をもう1回行います。3つ以上の組み合わせまで行くと場合の数が急速に増えるので、普通はペアまで見て、その先は介入で確認します。
数字で見ると、この手順になぜ価値があるのかがはっきりします。サンプル240件、属性が7つ、値が20種類ほどだとします。失敗40件の共通部分を求めると、たいてい値が2、3個残り、そこから成功200件の和集合を引くと、1つか2つが残ります。目で眺めると20個すべてが怪しいのに、引き算2回で候補が1つか2つになるのです。人が賢くなったのではなく、成功サンプルが残りを消してくれたのです。
もう1つ。この手順は、属性を増やすほど強くなります。記録にない属性は候補になれないので、調査の初期に「何を一緒に記録するか」を決めることが、事実上、調査の半分です。リクエストヘッダー、クライアントのバージョン、テナント、パス、認証方式は、ほとんどの事件で役に立ちました。
現場での姿
1つ目は、失敗サンプルだけを集めることです。顧客は、失敗したものだけを送ってくれます。成功したものは、誰も保管していないからです。そのため、最初の依頼は常に「成功したものも同じ数だけ送ってください」であるべきです。
2つ目は、サンプルが偏っていることです。失敗はすべて夜間バッチから集め、成功はすべて昼間の画面から集めると、時間帯とパスがすべて候補に残ります。データを集めた方法が、データに模様を残したのです。
3つ目は、候補を1つだけ見つけて止まることです。候補が2つ残っているのに、もっともらしいほうを選んで報告すると、半分の確率で間違えます。そしてその報告は、直すのに何日も使わせることになります。候補が2つなら2つと書き、切り分ける実験を設計するのが正しいです。
4つ目は、消したものを書かないことです。「auth_modeは原因ではない」という事実は、次の人が同じ道をもう一度歩かずに済むようにしてくれます。報告書には、残った候補だけでなく、消した候補と消した根拠も一緒に書きます。
実務で本当に大切なこと
- 成功サンプルが半分です。対照群なしの調査は、推測です。
- 属性の一覧になければ、候補もありません。何を記録するかを先に決めます。
- 完全な相関が2つあるなら、データをさらに得るか、介入します。もっともらしいほうを選びません。
- 単独で分かれなければ、ペアを見ます。相互作用は、単独の検査ではまるごと消えます。
次のラボですること
決済ゲートウェイのサンプル240件で、属性ごとの差分表を作り、すべての失敗にあって、どの成功にもない値を選び出します。候補が2つ残る場面で、新しいサンプル120件を加えて片方を外し、再現ツールで属性を1つだけ変えて、結果がひっくり返るかを確認します。最後に、1つの属性では分かれない別のテナントのサンプルからペア候補を探して、1枚で報告します。