調査：仮説をもとに、根気強くログやトレース、メトリクスを確認

調査：仮説をもとに、根気強くログやトレース、メトリクスを確認

何が起きているかがわかったら、次は根本原因を調査する。このとき「闇雲にログを眺めてもわからないので、いくつか自分の中で仮説を立ててからログやメトリクスを見て、問題がなければ仮説の立案から繰り返すのがいい」とTakagi氏は言う。

さらに調査の過程で、思いついたことなどをほかの人にも共有して、一緒に調査を進めるとよいとTakagi氏は語った。

トラブルシューティング2：問題の原因を調査する

具体的なパターンとしては、まずエラーが増えているパターンでは、根気強くログを見ることの重要性を改めてTakagi氏は強調した。気になるメッセージや、いつから発生していたかを調べるほか、エラーの発生場所やタイミングに偏りがないか確認することもTakagi氏は勧めた。

エラー増加の原因調査

またレイテンシーの増加やタイムアウトエラーのパターンでは、トレースやメトリクスを確認する。リクエストをネットワークの外側から順番に見ていき、どこまでが正常でどこからエラーになっているのかを追っていくのも有効だとTakagi氏は紹介した。

レイテンシー増加やタイムアウトエラー

ログなどを調べてもなかなかわからないパターンについては、調査の切り口を変えてみることをTakagi氏は勧めた。

さらに問題の切り分けのために、サービスを1つ前のバージョンに戻すなど、変化を加えてみることもある。「もしそれで直ればラッキーだし、直らなくても原因の候補が1つ潰せればいいぐらいの気持ちで」とTakagi氏は説明した。

切り口を変えて調査する

変化を加えてみる

そのほか、クラウド側に問題がないかどうかサポートチケットを切って調査してもらうパターンもTakagi氏は挙げた。

クラウドへのサポートチケットの起票

修正：原因は特定できたが修正できない場合への対処も用意

続いて修正対応のフェーズだ。これについては、特定した原因を修正することになる。

ここで問題となるのは、原因は特定できたが修正できない、しかしどうしても負荷に耐えられないというケースだ。そのときのために、メンテナンスモードにしてリクエストを止めてしのぐ、といった対処も用意しておくとよい、とTakagi氏は紹介した。

トラブルシューティング3：問題の修正案を考える

そして最後のフェーズとして、問題の復旧を確認する。このときの注意として、すぐに再発する可能性があるときには、それをチームにちゃんと共有することの重要性をTakagi氏は挙げた。

トラブルシューティング4：問題の復旧を確認する

トラブルは必ず起きる、同じ失敗を繰り返さないことが重要

最後に、次のトラブルを防ぐための取り組みについてTakagi氏は取り上げた。

トラブルは必ず起きるもので、そこから学んで同じ失敗を繰り返さないことが重要だ。そのために、根本原因を修正するほか、それが難しい場合は再起動などのように影響を緩和する対応もあわせて考えること、さらに類似の問題がほかで発生しないか確認することなどが挙げられた。

次のトラブルを防ぐための改善

次への改善に向けた取り組みとしては、まずポストモーテムの実施、つまりチームで振り返りを行って原因対策を考えることがある。ここで重要な点として「誰のバグが悪かった」といった非難ではなく、「どうやったらより良くできるか」といった建設的な議論を行うことをTakagi氏は強調した。

ポストモーテムの実施

また、次に同じ問題が起きたときの調査や対応の方法をドキュメント（プレイブック）に残しておくことがある。これにより、次以降の対応が早くできるというわけだ。

プレイブックの作成

こうした検知、把握、特定、対応の各プロセスをなるべく早くすることが重要だと、Takagi氏は改めて語った。

トラブルシューティングの流れ（再掲）

クラウドネイティブなシステムのトラブルシューティングについて、ハマりどころや調べるべきことなどのノウハウが語られたセッションだった。

派手な道具だてではなく、地道な準備や調査など、経験から得たことがらが紹介された。大規模なシステムでなくても、あるいはクラウドネイティブなシステムでなくても、システムのトラブルシューティング全般で、参考になるセッションだったと感じた。