前回はトラブルシューティングの理論について、学びました。
今回からは実践編です。
実際のトラブルシューティングは、理論のようにきれいなものではないですが、その過程をよりよくするにはどのようのすればいいでしょうか？
実践
問題のレポート
問題は必ずレポートから始まります。
レポートがでるのは、さまざまな状況があります。（アラートや同僚からの報告）
効果的なレポートにするためには、以下を含める必要があります。
- 期待される動作
- 実際の動作
- できれば、その状況を再現する方法
理想的なレポート
- レポートを一定の形式で作成する
- バグ追跡システムのような検索できる場所に保存する
レポートの報告ですべきでないこと
Googleにおいて、レポートを人へ直接報告することは、推奨されません。
その理由は次の通りです。
- 問題の報告をチケットに起こす手間が増える
- チーム内の他のメンバーから見えない低品質のレポートを生み出す
- 報告者がたまたま知っている少数のメンバーへ負荷が集中する
トリアージ
レポートを受け取った後、次にすべきなのは、何をすべきかを決定することです。
問題は大小さまざまで、ユーザー一人にのみ生じている場合もあれば、システム全体にかかわることもあります。
できるだけ早く根本原因の特定を行うことがいいように思われますが、そうではなく、行うべきは、システムをその環境下でできる限り上手く動作させることです。
なぜなら、根本原因を探っている間にシステムが完全停止してしまったら意味がないからです。
逆に回復不可能なデータ破壊を起こすバグがある場合、システムを動作させ続けることより、停止してしまうことがよりかもしれません。
まとめ
- 問題レポートの3つの観点。
- バグ報告はオープンにする。
- 原因調査の前にトリアージを行う。
参考文献
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 142-143