うまく障害調査をする術

　障害調査やデバッグという作業は，うまくいけば自分が名探偵か名刑事になったかのようで痛快ですが，難航するとつらいものですよね．

　以下は，私の経験から編み出した，障害調査のためのアドバイスです．障害に出会って困ったら，このチェックリストを使ってやってください．

　迷宮に逃げ込もうとする犯人（犯虫？）に追いすがり，あるいは待ち伏せして，有無をいわさず手錠をガチャリといわせて逮捕するあの快感．あれを味わうためには，合理的で，盲点につかまらない工夫が有効です．

　このページが，あなたがこれからぶつかる障害を素早く解決するのに役立てば最高です．

□ すでに分かっている障害にぶつかっただけではないか？
　障害について紙やWebや電子マニュアルで書かれているとすれば，どこにあるか．

□ 実は他にも同じ障害に遭遇している人がいるのではないか？
　障害に遭っても黙っている人が結構多いものだ．
　→Webで社内外を検索してみよう．周辺の人に聞いてみよう．
　周辺の人に同じことをやってもらい，障害が出るかどうか見せてもらおう．

□ 実は正常ではないのか？
　仕様の誤解というのはよくある．
　→仕様どおりとすればどんな仕様と考えられるか？机上で考えてみよう．
　確認しよう．
　開発元が仕様を変えてしまったのかもしれない．
　意外と，ずっと前に仕様が変わっていたりするものだ．

□ 最近正常だったのはいつ，どこでだったか？

□ 最近正常だった時点以降，自分または他人または計算機が何を変えた？
　→変わったハード，ソフト，ネットワークが障害にどう影響したか想像してみよう．

□ バージョンアップで起こったのではないか？
　　□ 古いバージョンではどうだったか？
　　□ 新しいバージョンでの非互換の問題ではないか？
　　□ 何か設定が増えたのではなかったか？
　　□ 障害修正はちゃんと当たっているか？

□ 障害の起こる条件を含む大きい環境条件で再現テストをしよう．
　→その環境条件（や実行ルート）をもっとも小さくして，障害が出なくなる境界点を探そう．その境界点の上に虫がいる．
　このような，境界点までぎりぎりちいさくして障害の再現する最小の環境を，「障害ミニモデル」と私は命名している．

　障害ミニモデルを作ることができれば，それを構成している少数の条件を分析することで，はやく障害が解決できる．障害調査が全然進展しなくてイライラするときには，障害ミニモデル作りをこつこつやっていこう．
　ただ，障害に再現性が少ない場合は悩まされるが……．
　環境条件と，起こる／起こらないを書きだして眺めてみよう．
　環境条件を小さくするため，バイパスできる機能がないかどうか探そう．
　「○○をバイパスしてみようか」というアイデアを書き出してみよう．

□ 障害の起こる条件を含まないほど小さい環境条件で再現テストをしよう．
　→その環境条件（や実行ルート）をもっと大きくして，障害が出るか出ないかの境界点を探そう．その境界点の上に虫がいる．
　このような，障害の再現しない最大の環境を，「正常マックスモデル」と命名している．
　環境条件と，起こる／起こらないを書きだして眺めてみよう．
　環境条件を大きくするため，障害が起こる環境の一部を通るようにしてみよう．
　「○○も通してみようか」というアイデアを書き出してみよう．

□ 上記の障害ミニモデルと正常マックスモデルとで間の虫を閉じ込めて押し潰す方法「ミニマックス挟み打ち法 (Sonobe's Mini-Max Pinching Method)」は長年自分で実践してきたものであり，その優れた効果には自信がある．

　一般にいう「障害切分け」とは異なるが，障害切分けも，場合によっては実はこれと同じことをしている場合がある．

　ともかく，障害原因が論理的に分からなくて途方に暮れたようなときに，障害ミニモデルと正常マックスモデルをこつこつ作っていけば原因が分かる道があるということが嬉しい．

　正常マックスモデルを追求しているうちに，「なんだ，こうすれば当面の目的は果たせるじゃないか」と，障害が解決しなくても運用できる「逃げ手」を発見できることも多い．
　もう逃げ手は見つかったか？そうでなければ，正常マックスモデルから探してみよう．

□ どこにバグがいるか，現在の障害ミニモデルと正常マックスモデルの間をサンプリングして試そうというときに，じわじわ端から攻めていくのが速いとは限らないので注意しよう．
　たとえば，1024の通過点のあるパスを端から攻めていったら，あらゆる可能性があるとすれば平均512回の試行が必要になってしまう．
　これに対して，「二分法 (binary division method)」を採用するとよい場合がある．私の考えたこの二分法という方法は，次のようなものである．

　障害になる点とならない点のちょうど真ん中（と思われるあたり）を試して，障害になればその点と障害にならない点のさらに中央を試すし，障害にならなければその点と障害になる点のさらに中央を試す，というように，区間を半分，半分，半分と縮めていく方法である．
　すると，1024の通過点があっても，最大10回の試行で境界点にいきつくことになる．極めて効率的といえる．（log₂通過点数）

　たとえば，ある日の障害の例でいえば，あるファイルのどこかに悪いコードの文字があってファイルの文字化けがエディタで発生した．そこで，ファイルの何行目までの区間までを抽出したら化けるのか，区間を狭めていった．こんな具合である――500:NG, 250:OK, 125:NG, 190:NG, 200:OK, 195:NG, 197:NG, 199:NG ということで，199行めに悪いコードがあると判明，それを取り除いて解決した．

　補足しておくと，テスト環境を作成するコストを加味するといちがいに二分法が最短時間とはいえない．端から攻める方が手間がかからない場合もある．
　回線障害調査の例でいえば，回線業者に障害申請して調べるのは社内部分の切りわけよりもコストがかかるので，最後に残しておく方がいいのかもしれない．社内部分で簡単に折り返し試験できるところを，（その中では二分法で）調べるのがよいだろう．

　また，プログラムのどこで変数が壊れているかなどを調べるときには，二分法でも端からでもなく，同時にたくさんの点にスナップショットをしかけておいて，一発で判明させるのが痛快である．

□ こんな障害現象をプログラミングせよと逆に言われたら，どういう仕組みにするのが実現しやすいか，机上で設計してみよ．
　→実際にそうなっているのかもしれない．コツは，なるべく一箇所の簡単な変更でその障害事象を起こしてみようとすること．

□ ほかに周辺で起こっている障害や不審な現象は何？関連があるのでは？
　同一原因で起こっていることがよくある．
　→両方を同時に起こすようなプログラミングをせよと言われたらどう実現するか考えてみよう．

□ 障害を直したときに，間違って新しい障害を生んでしまったかもしれない．このパターンはとても多い．
　→最近自分やひとが直した障害はどこだっけ？　関連性は不明でも，とりあえず，直した部分を細かくチェックしてみよう．

□ 同じようなものがもうひとつあって，混同しているのではないか？
　→同じプログラム名でちょっと違うものはなかったか考えてみよう．
　混同でなかったとしたら，その似たものでも実験してみよう．

□ 知識の不足かもしれない．
　関連マニュアルや電子ドキュメントに該当箇所はないか？
　→読んでヒントを探そう．ただし，つい漫然と大量に読んでしまい，時間をかけすぎたことを後悔しないよう，注意．

□ 設定ミスかもしれない．
　→関連する設定を思いだそう．正しく設定して動いている人に設定を教えてもらおう．

□ 不安定なハードウェアや回線がソフトウェアのバグを誘発したのではないか？
　もっと安定したハードウェアや回線で試せないか？
　電話回線だったら別の回線にするとか．
　その反対に，不安定なハードウェアや回線をわざと使って，めいっぱい障害を再現させて調べるという手もある（特に再現性が低いばあい）．
　世の中には，操作がせわしいとかいろいろな機能を利用したがるタチで，障害を呼び覚ますことにたけた人というのがいる（私もそう，かな）．障害を再現させたいときはそういう人に使ってみてもらうのもよい．

□ きわどいタイミングの生んだ障害ではないのか？
　並行処理で壊れたのではないか？同時にふたつ（ふたり）以上が動いていなかったか調べる．

□ その障害の独特の形跡を検討しよう．
　何かの壊れ方，エラーメッセージ，出てくるタイミングなど，障害のさまざまな特徴，個性，奇異な点，どこか偶然ではなさそうな“匂う”ところを収集して，犯人特定の手がかりにしよう．

□ 見えるようにし，聞けるようにして調べよう．
　自分のプログラムだったら，肝心の情報の出入りでの形をスナップショットしてみよう．当たり前だと思っても，そこを，思い通りかどうか調べるのである．
　モデムなど音の出るものは設定で音を出そう．

□ 情報の流れを箱と矢印で書いてみよう．
　どこから異常になったか，また，どの箱がシロでどの箱がクロかを，一個一個チェックマークしよう．
　最初からシロだとして書かない箱があってはいけない．だって，どこかにシロそうでクロい箱があるに違いないのだから，シロそうな箱こそちゃんと洗い出さなければいけない．

□ 障害調査を自分ひとりとか少人数でやっているときも，調査過程をメモ用紙かノートか電子ファイルにログしていこう．
　仮説，実行，結果，判明事実などを区別しながら，記録していく．
　ときたま見直してみると，新たな有力仮説が出てきたり，埋もれている判明事実が明らかになったりするものである．
　電子ファイルに溜まったら，Web上に掲載すれば，障害調査ノウハウとして共有できる．（世の中にはPrimus社などのサポートセンター（CTI）用のツールなんていうのがあって，記録や検索を合理的にできるのだが個人用ではない．）

□ ひとりで時間をむやみにかけず，今まで集めた情報をもって誰かに相談してみよう．