今日から新しい章に入ります。
内容は効果的なトラブルシューティングです。
トラブルシューティングは、初心者は2つの要素で躓くことがあります。それは一般的なトラブルシューティングの手法の理解とトラブルシューティングを行うシステムに関する理解、これらの不足によります。
まずは、一般的なトラブルシューティングの手法、その理論から見ていきます。
一般的なトラブルシューティングの理論
形式的にはトラブルシューティングの過程は、仮説演繹法の応用と考えられます。
システムに関する一連の観察結果と、システムの挙動を把握する理論的な基盤をもとに、障害の原因の仮説を立て、その仮説を検証するというプロセスを繰り返します。
トラブルシューティングは、問題のレポートから始まり、トリアージ、観察、診断、テスト/対処、回復or観察に戻る。もしくは、トリアージを再び行うというように進みます。
仮説を検証する方法は2種類あり、観察したシステムの状態と仮説を指示するあるいは支持しない証拠を見つける方法。
もしくは、システムに何かしらの変更（手当て）を行い、その結果を観察するという方法。
一般的な落とし穴
トラブルシューティングの効率が悪くなるのは、システムへの理解が不足していることが多いです。
例えば、
- 関係のない症状を見てしまう。メトリクスの意味を取り違える。結果を一足飛びに求めすぎてしまう。
- 安全かつ効率的に仮説を検証するために必要なシステムやシステムの入力、環境の変更方法を誤解している。
- 生じている問題に対し、ありえないような仮説を思いついたり、一度起きたことはまた起きるはずだと考え、過去の問題の原因に固執する。
- 実際には偶然だったり、共通の原因を持つような出来事に対し、間違った関係性を追求してしまう。
初めの二つは、システムへの理解が増せば、解消されます。
3つ目は、すべての障害が起きる確率は等しくないということを念頭に考えるべきです。
最後の例の場合は、相関関係は因果関係でないということを忘れないようにすべきです。
まとめ
- 理論的にはトラブルシューティングは、仮説とその検証の繰り返しである。
参考文献
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 139-141