障害再発防止策策定の試練

　2005年3月7日付けの日経コンピュータの名物連載「動かないコンピュータ」を読んで怒り狂った。なんて馬鹿がシステムの設計をやっているのだ。
　あまりにもひどいので、ついでに言うと日経BPの取材も詰めが甘いので、これをネタにしてものを書くと罵詈雑言の嵐になってしまう。

　ところで町の何でも屋である私は障害管理もやっている。怒り狂っているだけでは何も生み出さないので、他山の石として現在試行中の障害対策検討の枠組みに載せて分析をしてみることとした。
　障害管理のやり方を調べているうちに「一般的な障害管理手法は障害事象をとらえて原因を追及するために作ったものであるから、再発防止を主眼とするなら別の分析方法を考えないといけないな」という気になって試しに作ってみたのである。さて、これで冷静さを取り戻せるであろうか。

発生日

2005.1.29

問題部署

Jストリーム（ただし監督責任はオリコンDD）

システム名

楽曲オンライン配信システム

発見経緯

利用者よりのクレーム

影響

サービス全般の信頼を揺るがす規模

現象

以下の２つの複合事象

Webサイトより楽曲を購入しようとしたところ、サイトの受付処理が停止。

受付がなされ、決済も完了したが、楽曲がダウンロードできない。

原因

決済処理に時間がかかりタイムアウトした。

ライセンス発行処理に時間がかかりタイムアウトした。

作込工程

テスト設計：実運用レベルの負荷テストを計画していない。

基本設計：決済処理とライセンス発行処理を別々のトランザクションとした。（構築を請け負ったJストリームは得意のライセンス発行処理に特化し、決済処理を別会社に再委託した。）

発見予測工程

テスト計画レビュー

JストリームよりオリコンDDへの再委託届出承認（別々の会社が構築しているので、当然トランザクションは分離されているはずで発注後のリカバリは不可能。）

SafetyNet

なし。

何をしていれば防げたか

常識的な負荷テスト

決済を伴う仕訳と伴わない仕訳におけるトランザクションの粒度について認識している専門家の介在。

再発防止策

常に十分な負荷テストを行うよう社内手続を整備

決済システム専門家によるレビュー

再委託の届出手続、および承認の審査基準充実。

再発防止策の採否

否／（らしい）理由はインターネット環境で本番稼働後と同等の負荷テストが実施できる保証がないこと。（言い訳だなあ）

否の場合の代替策

第三者によるシステム監査の実施

コメント

決済が完了したのちライセンス発行でタイムアウトした事象の方が重要。日経BPの記事にはないが、顧客に実損が発生する可能性があるから。ライセンス発行でタイムアウトすると決済自体を取り消す動きをすれば（つまり、決済＋ライセンス発行＋ダウンロードの一連の処理を一つのトランザクションとして捉えれば）、少なくともユーザーの実損発生は防げたはず。しかし、外注先の再委託を認めてしまい、日経コンピュータの記事でも特に問題視していないように、オリコンDDにそのへんのトランザクションをまとめるという意識は全くなかった。要するに決済の絡む取引を、在庫管理の仕訳と同レベルと考えてしまった。換言すれば一挙に複式簿記で記帳しなければならない取引を、別々の単式簿記で記帳してよしと考えてしまった。

　よし、少なくとも日経BPよりは深い分析ができた。この分析手法で気に入っているところは「個人攻撃をしない」ところ。「人間のやることだから見落としは必ずある。それを本番までに発見するためにはどうすればよいか」という観点でものを見るようにしているところ。
　しかし、ここまで根本的に間違うと・・・直しようがないなあ。オリコンDDものど元すぎれば・・・みたいだし。（今、サイトにお詫びや事情説明は載っていない。）第一トランザクションを分離させたことによるリスクは未だに全く認識されていない。あぶねえから、みんな、あそこからは買わないほうがよいぞ。

　ついでに、この号の日経コンピュータ、次のページのニュースにあった事象も「なにやっとんじゃ」と怒鳴りつけたくなった。かのジャスダック証券取引所、「注文取り消し殺到」でシステムが停止したのだそうだ。
　通常の10倍の買い注文取り消し指示がやってきて、処理しきれずにタイムアウトしたということだ。で、再発防止策としてとられたのが、タイムアウト時間を２分から１０分に伸ばすことだったらしい。その理由が今回の事象を再現させたところ５分で処理が終わったからそれでいいのだそうだ。
　おいおいおいおい、正気か？通常の10倍の取り消し指示が来たので止まってしまったのは仕方がない。でもどうしてタイムアウトまでの時間をいきなり５倍にできるんだ？それができるのならどうして最初にタイムアウトまでの時間を２分に設定したんだ。１０分で問題がないのならはじめから１０分にしておけばいいじゃないか。
　それに、タイムアウトすることは設計時に予測できたわけだろ。じゃあタイムアウトした場合にどうするかの運用は当然設計されているはずでしょう（該当の銘柄を一時取引停止にして、切り離し、全体の処理は続行。該当銘柄は手作業で取引を突合させるくらいが妥当でしょう）。なのにどうして全銘柄の取引が停止するの？
　つまり、タイムアウトの時間をいい加減に決めて、タイムアウトした場合の運用を何も考えていなかった（ついでに言うと、一つの取引が止まると全部止まるという本質的にシングルタスクの取引システムを作ってしまった）、ということですよ。ここまで根本的でしょうもない間違いだと当方（個人的に）試行中の障害対策の枠組みに当てはめることすら無理だわ。

　うーん。折角考えた枠組みだったんだけどダメみたいね。要するにCMMI２級以上の組織についてしか役に立たないと言うこと。CMMI１級以下の組織に対しては、私の嫌いな「チェックリスト」を適用しなければならないということ。
　この場合、チェックリストの項目はこんな感じになる。

• テスト設計時には、データ全量を取り扱えることを確認するテストを実施すること。不可能な場合は、代替策を考え、識者のレビューを受けること。
• 外注先が再委託を行う場合には、再委託されたサブシステムを別会社が担当することについての弊害がないかどうか、基本設計と照合して確認すること。
• 決済（勘定の移動）を伴うトランザクションは、対となる物の移動のトランザクションとまとめて一つのトランザクションとしてコミットポイントを設定すること。
• 処理の異常をタイムアウトで検知する場合は、タイムアウト時間の設定を運用設計と同期をとって設計し、タイムアウト発生時の処理についても別途決定するよう、ユーザーないし運用設計セクションに文書で依頼すること。
• 前項の依頼を行う場合は、システム設計に影響があるとされた場合にフィードバックを受けることについて文書で取り決めておくこと。（期限、窓口、フィードバックの形式）
• 一つのプロセスを終了させる可能性がある場合は、その終了が他のプロセスの停止を招かないようにすること。

　むなしい。でも「チェックリスト」でなく「ルールセット」の体裁をとれただけでもマシとせねばなるまい。