2012年3月22日木曜日

トラブル対処の原則考

修正したヘルスチェックスクリプトがうまく動作しないというので、調査していた。
本来ならNGとなるべき出力がOKのままだという。その時実施した対応は、

1)状況の聞き取り
2)ログなどのエビデンス収集 => ログなどが0バイト
3)部分的な実行による切り分け

結局のところ、部分的に実行していった段階でミスに気付いたのだが、これをもっと早く確実に発見する方策がないだろうか?

3-1)主要スクリプトを単独実行 => 出力空
3-2)上記スクリプトを手で実行(SQLPLUS) => 空
3-3)確実に出力があるように変更して実行 => no rows selected

ここにいたって、Oracleのつなぎ先が違うのでは?という疑いが発生し、調べたらまさにそうであった。

教訓1:調査開始時点での前提を明らかにして疑ってみる
 => 原因の上流の確認は作業が容易で効果が大
教訓2:前提を明確にできるような工夫をスクリプトに入れておけばよかった
 => または、文書としてコメントに入れておくか、前提確認用スクリプトなど
 例)前提:Oracleとの接続、スクリプトの配置場所、XXファイルの書き込も権限
   前提違反時の振舞:エラーメッセージ、空文字出力、、、

優先順位マトリックスを考えてみた:
 作業の困難性  => 当該部分に問題があるかどうかの確認作業の時間やスキル
 影響範囲の大小 => 当該部分の障害から本件が発生しうる確率
 優先順位 => 容易で影響大 -> 困難だが影響大 -> 容易で影響小 -> 困難で影響小
  *中央の2,3番目の部分は時間配分やメンバースキルによって反対にした方がよいか
   または、メンバーに余裕があれば並行して作業するといい

今回の件だと、Oracleの接続先のような前提条件は
「作業が容易で影響範囲が大」となり、優先順位が高いものといえる。
環境変数の設定も、同じ範疇だ。しかし、個別スクリプトの問題となると
「容易で影響小」となる。

0 件のコメント: