(cache) 特に利害関係が無く関心も見識も低い野次馬向けの障害報告作法

2017-06-23

■[web]特に利害関係が無く関心も見識も低い野次馬向けの障害報告作法

　かの有名なメルカリで利用者の名前や住所、銀行口座番号、メールアドレス、クレジットカードの下4桁と有効期限、購入・出品履歴、ポイント・売上金、お知らせ、やることリストなど、５万４１８０人の個人情報が外部に晒されたそうな。

　幾ら何でも全部過ぎるだろ…と思うんだが、まぁそれはそれとしてこの「技術的観点からの原因報告」が酷い。

　「原因*1はnginxの設定ミスでした。ミスしたのはこの箇所です」

…それ原因じゃなくてミスそのものの説明じゃん。ただの作業報告だ。作業員の日報だ。こういう時の例え話は誤解の元だが「車で人を撥ねたのは、運転手がブレーキを踏まなかった事が原因です」みたいな。それ原因じゃねぇ。事象そのものだ、分析対象だ。最浅でも「運転手は何故ブレーキを踏まなかったのか？」の答えが原因と名の付く最低限。寝てたとかポケモンGOしてたとか実はブレーキ踏んだけど故障してたとか。今回なら必要な設定を知らなかったとか、知ってたけど設定するの忘れてたとか、設定したつもりだったが反映させなかったとか。普通はその次に、知らなかったなら、知らないまま動かしちゃったのは何故かとか、忘れたなら、なんで設定するの忘れたのかとか分析する訳だが…。

　分析が何もないただの作業員の日報中のミスの説明を原因と称したものだから当然出てくる再発防止策も酷い。

再発防止策

外形監視を利用した、CDNによる意図しないキャッシュを早期に検知できる仕組みを導入します
http://tech.mercari.com/entry/2017/06/22/204500

　追加チェック！出た！追加チェック出た！得意技！追加チェック出た！追加チェック！これ！追加チェック出たよ～～！俺は限界だと思った。

　原因分析が浅い時にやりがちだけどもやってはいけない「駄目な再発防止策ナンバー１」それが追加チェック導入。以後の作業を重くし金をムダにしミスするポイントを増やす最悪の再発防止策だ。原因分析が浅いどころかノー分析からの再発防止策だとまぁ大概こうなるのだが…しかもチェック対象が今回の事象ピンポイント限定追加。最悪中の最悪をよく選ぶな…。他人事で良かった。

　そうじゃないだろ。ミスの再発を前提にそれを検出するためのチェックを追加、ではなくて、ミスを起こさない方法を講じるのが再発防止策だろ…。

　今回しくじったのは恐らくオペレータだけど、こういう人がプログラマだと不味いんですよ。バグで障害出す度に再発防止策として「レビューチェックリスト」を作って肥大化させるから。「if文の<と<=を間違えて境界値での動作をしくじりました」→「レビューチェックリストに<と<=の誤りが無いか、を入れます」。んでそのうちその肥大化した長大なチェックリストはあまりの長大さにチェック作業自体をミスるようになり、やがて時間ばかり食って効果が薄いということで使われなくなる…。せめて「コーディング規約で原則として全部<に統一します」ならまだ。

　トラブル後にこんな報告書持って行ったら…「いや作業員の日報はいいから」と突っ返されるだけで穏便(?)に済めば１晩徹夜で書き直すだけで済むけど、「こんな分析とは御社はどういう仕事のやり方をしてるんだ」とか技術力ごと疑われると下手すると一か月コースもあり得るので想像するだに恐ろしいが…そもそもお客に持って行く前にこんな報告書に上司が判子をくれる訳が無いので安心か。

　事程然様に全くもって酷い報告書な訳だがこれがネットでは好評だ。

iuhyaメルカリ特に好きじゃないけど、見直したわ。

nisisinjuku 詳細な情報は後で助かる。（助かるような事態が起きないように目を通しておくことも必要だね）

Nobeee 対応に大変好感がもてるなー

haratakedn 失敗をオープンにできる会社の風土はいいと思う。

sekirei-9 技術的な説明があると納得感がある不思議

Soraneko 事例公開はとても好感がもてます

(以下多いので略)
http://b.hatena.ne.jp/entry/tech.mercari.com/entry/2017/06/22/204500