今回は実践編の最後と実験により否定的な結果がもたらされた場合のアプローチについて、見ていきます。
実践
テストと対応
潜在的な問題をある程度絞った後は、根本原因の調査を行う必要があります。
テストを行う際に注意する点、観点は次の通りです。
- 理想的なテストは問題の原因の仮説を受け入れ、その他の仮説を否認するものです。現実的にはそうなるようにするのは、難しい場合があります。
- 明らかなことから始める。システムに与える影響を考慮しながら、可能性の高い順番にテストを行う。
- 混乱を招く要素により、実験の結果を誤って、認識することがある。（例：特定のIPアドレスを許可するファイアウォール下でテストした場合、自分のワークスペースからは失敗するかもしれない）
- テストが環境に与える影響が大きい時、後のテスト結果が変わる場合がある。
- 結果が決定的なテストだけでなく、示唆的な結果しか与えてくれないテストもある。その場合、妥協が必要な時もある。
テストを行うときのドキュメント
- 考えていること、実行したテスト、得られた結果をはっきりと記録する。
- 出来事を正確に記述し、同じステップを繰り返さないようにする。
否定的な結果のすばらしさ
否定的な結果とは、実験の結果、期待した結果が得られなかったときの結果のことです。
以下では、否定的な結果へのアプローチを見ていきます。
否定的な結果は、無視したり過小評価するべきではない
はっきりとした否定的な結果は、設計上の問題に回答を与えてくれる場合があります。（2つの案の内、一方に進むことで、もう一方が優れていることを知る）
否定的な結果が出た実験は決定的なもの
プロダクションや設計領域、既存のシステムのパフォーマンスの限界について、確実なことを示します。そして、それらの実験は、独自の設計や実験を行う価値があるかどうかを他者へ伝えることができます。
ツールや方法論は、実験そのものよりも長く残り、詳細な作業の助けとなる
最初の結果は、望ましくない結果だったとしても、そこから恩恵を受けるものは多くあります。
また、繰り返し行われる実験の為のツールを作ることは、そのツールにより良い結果が得られなかったとしても、次のアプリケーションでは異なる結果を生むかもしれません。
否定的な結果を公開することは、IT業界のデータ駆動の文化を改善することになる
否定的な結果を説明することでメトリクスにおけるバイアスを下げ、不確実性を慎重に受け入れる例を他者へ示せるようになります。
すべてを公開することで他社にも同じ行動をとることを推奨することになります。
結果を公開する
実験の結果に自分が関心を持っているなら、他人も関心を持っている可能性は高いです。
失敗した結果は、報告することを避けたくなりますが、それはよく考えてリスクをとった結果の一部であり、十分に設計された実験にはメリットがあります。反対にあまり失敗について、言及されていない結果は、懐疑的に見る必要があります。
対策
問題の原因が特定できたら、それが本当に原因であるかを確認するために、実際に問題を起こしてみることをするといいですが、難しい場合もあるかもしれません。
その場合は、問題の推定原因しか見つけられないことになります。
また、問題を引き起こした要因を見つけられたら、ポストモーテムを書く必要があります。（システムで生じた問題、問題を突き止めた過程、問題解決方法、再発防止策）
まとめ
- テストを行う際は、思考の過程などもメモを残し、同じ作業の繰り返しをしないようにする。
- 否定的な結果を無視しない。すべてを公開する。
参考文献
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 142-143