クラウド時代のトラブルシューティング : 解決に役立つプロバイダーとのコミュニケーション（後編）
Google Cloud Japan Team
編集部注 : この記事は、数年前に SRE（サイト信頼性エンジニアリング）の本を出した（本当に！）Google エキスパート チームが執筆してくれました。同書の続編も発売に向けて準備が進んでいるようです。ここでは、多くの IT チームにとって重要な SRE の一分野である、クラウド コンピューティング時代のトラブルシューティングを取り上げます。今回は 2 回連載の後編です。クラウド プロバイダーのサポート部門に送るイシュー レポートの基本的な書き方については前編をご覧ください。
コンピュータ システムのトラブルシューティングは、コンピュータそのものと同じくらい古くから行われており、職人技とまで言われることもあります。ところが、クラウド コンピューティングのパラダイムにより、IT チームによるトラブルシューティングの方法は根本的に変わろうとしています。
IT トラブルシューティングは、運や経験だけで成功させられるようなものではありません。教えることや学ぶことのできる意識的な仕事です。クラウド インフラストラクチャを使用する場合は、クラウド プロバイダーのヘルプ デスクを介してトラブルシューティングを行うことが多く、ユーザー サポートの階層が 1 つ増えます。このように、従来の IT チーム モデルからシフトしなければならないので、プロバイダーとのコミュニケーションがきわめて重要になります（トラブルシューティングを初動から改善する効果的なイシュー レポートの書き方については前編をご覧ください）。
問題があることをプロバイダーに連絡したら、問題解決に向けて、プロバイダーのサポート チームとの共同作業が始まります。
クラウドにおけるトラブルシューティングの要点
クラウド インフラストラクチャの技術的な問題を診断する担当者は、状況の説明（仮説）と説明の根拠となる証拠を探します。短期的には、問題と関係のあるシステム内の変化を探し出し、問題を緩和して直接的な影響を止めるための第一歩としてロールバックを目指します。それに対して長期的な目標とは、問題の根本的な原因を突き止めて解決し、問題が再発しないようにすることです。
SRE の視点から見ると、トラブルシューティングの一般的なアプローチは次のようになります。
- トリアージ : 可能な範囲で問題の影響を緩和する。
- 検証 : 観察されたことを集約、共有する。
- 診断 : 観察されたことを説明するための仮説を立てる。
- テストと修復 :
- 仮説を証明、または反証するテスト方法を見つける。
- テストを実施し、結果の解釈を統一する。
- 次の仮説に移り、問題が解決するまでこのプロセスを繰り返す。
クラウド プロバイダーと協力して問題のトラブルシューティングにあたる場合は、自分ではコントロールできない部分がいずれ出てきます。しかし、あなたにはあなたの側で行うべきことがあります。クラウド プロバイダーのサポート チームに報告を送るときに行うべきことは次のとおりです。
1. すでに自分で行ったトラブルシューティングの内容を伝える
イシュー レポートを送るまでに、たとえばプロバイダーのステータス ページをチェックするなど、おそらく何らかのトラブルシューティングをすでに行っているはずです。実施したことと、それによってわかったことをプロバイダーに知らせましょう。実施したことのタイムラインとログ ブックを残しておき、プロバイダーと共有してください。問題が発覚した後は、できる限り早い段階からログ ブックを残すようにしなければならないということです。
インフラストラクチャの状態をリアルタイムで把握できるようにする遠隔測定の手段をクラウド プロバイダーが有している場合もあります。しかし、あなたのシステムの特定の実装に起因する依存関係は自明ではないかもしれません。設計上、クラウド リソースの特定の利用方法は非公開かつプロプライエタリであるため、見晴らしのきくあなたの視点はきわめて重要です。
問題を診断できていると判断したときは、その結論に至った経緯を説明しましょう。ほかの人間でも問題を再現できるようであれば、そのための手順も説明に含めます。再現可能なテストがイシュー レポートに含まれていると、通常は最速での解決につながります。
ただし、推理の根拠となるような証拠を探すあまり、反対証拠を無視して確証バイアスに陥らないように注意してください。
2. 問題を明確かつ具体的に示す
1 列に並んだ人々が順に次の人にメッセージをささやく伝言ゲームをしたことがあれば、人の解釈や言い換えによってコミュニケーション ギャップが生じることをよくご存じでしょう。プロバイダーとのやり取りでは、情報を一方的に説明するのではなく、シェアするようにしてください。そうすれば、あなたが言っていることを相手が誤解する可能性が低くなり、トラブルシューティングのスピードアップにつながります。プロバイダーならすべての情報を知っているはずだと思い込んではなりません。設計上、顧客のプライバシーに関わる事項については、プロバイダーが知っていることは限られます。
情報のシェアは、たとえば次のようにします。
- 見たとおりのものを示すため、スクリーンショットを添付する。
- ウェブ ベースのインターフェースとして HAR（Http Archive）ファイルを提供する。
- tcpdump 出力、ログの一部、サンプル スタック トレースなどの情報を添付する。
3. 本番アウテージは早い段階で報告する
アプリケーションがユーザーにトラフィックを送信しなくなったり、同等の重大な影響をビジネスに及ぼすようになったりしたら、それは本番アウテージと見なされます。本番アウテージが発生したら、クラウド プロバイダーのサポート部門にできる限り早く知らせましょう。なお、開発者用のテスト環境で少数の開発者がアクセスできなくなるような問題が起きても、それは本番アウテージとは見なしません。報告の優先順位も低くなります。
通常、クラウド プロバイダーのサポート チームに本番アウテージを知らせると、彼らは次の手順ですぐにトリアージに着手します。
- インフラストラクチャに影響を及ぼす既知の問題を直ちにチェックする。
- 問題の性質を確認する。
- 通信チャネルを開設する。
一般に、次の内容を含む簡潔なメッセージをプロバイダーに送ると、すばやい対応が期待できます。
- 複数の顧客に影響を及ぼす既知の問題の有無
- 報告した問題をプロバイダー側で観察することの承認や、詳細情報のリクエスト
- 希望する通信手段（たとえば、電話、Skype、イシュー レポート）
大切なのは、4 つの必須情報（前編で説明）を含むイシュー レポートをすぐに作成し、そのあとで自分の側のトラブルシューティングを深めていくことです。あなたが所属する組織がインシデント管理プロセス（SRE 本のインシデント管理の章を参照）を定義している場合は、クラウド プロバイダーへのエスカレーションを早い段階で行う必要があります。
4. ネットワーク関係の問題はとりわけ具体的に報告する
多くの場合、クラウド プロバイダーのネットワークは膨大かつ複雑であり、さまざまなテクノロジーやチームが関与しています。そうした中で重要なのは、ネットワーク固有の問題をすばやく特定し修復できるチームと協力して作業を行うことです。
ネットワークに関連する問題の多くは、「サーバーに接続不能」というように、類似した症状を示します。このレベルの報告は漠然としており、根本的な原因を突き止めるうえで役には立ちません。もっと多くの診断情報を提供する必要があるのです。接続関連のネットワーク障害には少なくとも 2 つの地点（送信側と受信側）が関わっています。ネットワーク関連の問題を報告するときは、これらの地点に関する情報を必ず含めるようにしてください。
イシュー レポートを作成する際はパケット フロー図の概念ツールを使用しましょう。
- パケットの送信側から受信側までの経路における重要なホップと、経路に沿って行われる重要な変換（たとえば NAT）を書き出す。
- 最初に、インターネット IP アドレスまたは RFC 1918 プライベート アドレスと、ネットワークの AS 番号を用いて、影響を受けたネットワーク エンドポイントを識別する。
- エンドポイントの管理者、DNS ホスト名との関連の有無など、エンドポイントに関して意味がある情報を書き込む。
- VPN トンネル、プロキシ、NAT ゲートウェイなど、間に入るカプセル化や間接参照の情報を書き込む。
- ファイアウォール、CDN、WAF など、途中のフィルタリングの情報を書き込む。
レイテンシの増加やパケットの消失といった形で現れる問題を診断するには、パス分析やパケット キャプチャが必要です。パス分析とは、パケットが通過するホップのリストです（たとえば MTR や tcptraceroute で取得)。パケット キャプチャ（pcap。名前はライブラリ名の libpcap に由来）は、実際のネットワーク トラフィックを観察することです。難しい場合もありますが、両方のエンドポイントで同時にパケットをキャプチャすることが重要です。必要なツール（たとえば tcpdump や Wireshark）の使い方に慣れ、必要になる前にインストールしておくようにしてください。
5. 必要に応じてエスカレーションする
状況の変化次第では、問題の緊急度を引き上げて、プロバイダーにすぐに対処してもらわなければならないこともあります。ビジネスへの影響が大きくなったり、サポート部門といくらやり取りしても状況の進展が見られなかったり、その他の要因で早期解決が必要になったりした場合はエスカレーションを要求します。
最も明確なエスカレーションの方法は、イシュー レポートの優先度の変更です（たとえば P3 から P2）。エスカレーションが必要な理由をコメントの形で提供し、サポート部門が適切に対応できるようにしましょう。
6. 長く続く問題や困難な問題についてはサマリー ドキュメントを作成する
時間の経過とともに、新しい事実に光が当てられたり、仮説が除外されたりして、問題の状態や関連情報は変化していきます。その間に新しい担当者が調査に参加することもあるでしょう。そのような場合に備えて、サマリー ドキュメントに情報を集約し、最新の情報が伝達されるようにしておいてください。
優れたサマリー ドキュメントには次のような特徴があります。
- 最新の状況が冒頭にまとめられている。
- すべての関連イシュー レポートや社内バグ管理情報へのリンクがまとめられている。
- 正しいかもしれない仮説と、すでに除外された仮説のリストがまとめられている。特定の仮説について検証を開始するときはそのように書き、使用する予定のテストやツールを明らかにする。そうすることで、適切なアドバイスをもらえたり、作業の重複を避けたりすることができる。
以下はサマリー ドキュメントの書式例です。
$TIMESTAMP
<現在の顧客への影響> <機能している仮説と取ろうとしている行動> <次のステップ>
13:00:00
顧客への影響は緩和され、解決された。先月の使用料の支払いを忘れたため、ネットワーク プロバイダーが当社のトラフィックを制限している。今後は財務部門との連絡を強化したい。
12:00:00
当社のサービスに接続できないとの苦情が 100 人以上の顧客から寄せられている。ネットワーク プロバイダーは、顧客トラフィックの処理を 1 個のロード バランサだけに絞っている。対策チームは、ネットワーク プロバイダーのティア 1 サポートと協力して、この問題が発生した理由と経緯を調査している。
11:00:00
api.acme.com の API に継続的に接続できないという苦情が、4 つの異なる地域の 50 人の顧客から 100 件届いている。当社のエンジニアは上流のネットワークに問題があると考えている。次のステップは、ネットワーク プロバイダーに連絡を取り、上流に問題があるかどうかを確かめることである。
10:00:00
api.acme.com に接続できないという苦情が 5 人の顧客から届いている。当社のエンジニアが問題を調査している。
個々のイシュー レポートでは 1 つの問題だけを扱うようにしてください。新しい問題が以前の問題に関連しているからといって、以前の問題のイシュー レポートを再度使用してはなりません。新しいレポートにおいて類似の問題の参照情報を提供すると、根本原因によって引き起こされるパターンをプロバイダー側が認識しやすくなります。
コミュニケーション スキルを磨く
細かい技術情報を明確にアクショナブルな形で伝えることは容易ではありません。そのためには集中と特別なスキルが必要です。ストレスが溜まる場面では、これが特に難しくなります。ストレスに対する生物学的反応が、明快で状況を見据えた推論の足を引っ張るのです。全員に対してわかりやすいコミュニケーションを取るには次のテクニックが役に立ちます。
詳細なイシュー レポートを書いて認知的負荷を下げる
イシュー レポートを読み進めるにあたって、推論や計算が必要になることがあります。これが認知的負荷を生み出し、技術的な問題の解決に使える精神的エネルギーを減退させます。
イシュー レポートは、できる限り具体的かつ詳細に記述するようにしてください。細部に注意を払うと、そのぶん作成にかかる時間は増えます。とはいえ、作成されたイシュー レポートは多くの人に何度でも参照されることになるため、全員が包括的な情報を得ていれば問題を早く解決できます。
また、イシュー レポートには略語や社内のコード名などを使わないようにしてください。第三者に情報を開示するときも、顧客のプライバシー保護に十分配慮しましょう。
ナラティブ（ストーリー テリング）のテクニックを使う
“昔々あるところに…”
人間は、ストーリーの形になっている情報の吸収に特に長けています。そこで、この能力を活用すれば、効果的に論点を理解してもらえます。状況説明から始めてください。初めて問題を観察したときに何が起きたか、どのような解決方法を試みたか、誰が関与していたか、彼らにとってその事象はなぜ問題だったのか。テキストの書式やグラフ、スクリーンショットなどのイメージを活用して、イシュー レポートにビジュアルな要素を組み込みましょう。
テキストの書式
ログ データ、コードの一部、MySQL の結果といった書式のあるテキストをプレーンテキスト メールの一部として送信すると、見分けがつきにくくなります。そこで、マーカーを意識的に追加すれば（たとえば引用の最終行に <<<<<< を入れる）、重要な部分に注意を向けやすくなります。また、長い URL については脚注を活用するか、URL 自体を短くするようにしてください。
項目を列挙する場合は、箇条書きリストを使用し、インスタンス名などの重要な細部については目立つようにします。手順の箇条書きには番号を付加してください。
グラフ
時系列データをわかりやすくするうえで、グラフはとても効果があります。イシュー レポートにグラフを添付するときは、以下のベスト プラクティスを常に心がけましょう。
- タイトルや軸ラベルを付けた状態でスクリーンショットを取得する。絶対数には単位（分あたりのリクエスト数、秒あたりのエラー数など）を付加する。
- スクリーンショットに矢印や丸でコメントを付け、重要なポイントを目立たせる。
- 何を測定しているグラフなのかを簡潔に説明する。
- 正常な場合のグラフがどのような形になるかを簡潔に説明する。
- グラフに対する自分なりの解釈、問題との関連を簡潔に説明する。
次のアンチパターンに注意してください。
- Y 軸が個別的なエラー（たとえば自分のハンドラ内の例外数）を示しており、調査中の問題（たとえば永続化レイヤのレイテンシ）との関係がはっきりしない。このような場合は、問題にとってこのグラフがなぜ重要なのかを説明する必要がある。
- Y 軸が絶対数（たとえば 1 分あたりの数）になっていて、相対的な影響についての手がかりが得られない。
- X 軸にタイム ゾーンの指定がない。
- Y 軸が 0 から始まっていない。これでは Y 軸の値のわずかな差が非常に大きく見えてしまう。
- 軸ラベルがなかったり、消されたりしている。
きちんとしたイシュー レポートを作成し、クラウド プロバイダーと緊密にコミュニケーションを図ることができれば、問題解決のペースが上がり、解決に要する時間が短縮されます。
コンピュータ システムのトラブルシューティングは、クラウド コンピューティング モデルの登場によって大きく変わりました。もはや、技術的知識が豊富であれば効果的なトラブルシューティングが可能だという時代ではありません。クラウド プロバイダーとの間で明快かつ効率的にコミュニケーションを図る必要があるのです。
デプロイされた実際の環境が特異で複雑、しかも微妙な部分を含んでいるとしても、この連載の内容が効果的なトラブルシューティングを手助けしてくれるでしょう。
関連コンテンツ
- SLO、SLI、SLA について考える : CRE が現場で学んだこと
- SRE vs. DevOps: competing standards or close friends?
- Google の新しい専門職 : CRE が必要な理由
Special thanks to Ralph Pearson, J.C. van Winkel, John Lowry, Dermot Duffy and Dave Rensin
* この投稿は米国時間 5 月 31 日、Luke Stone と Jian Ma によって投稿されたもの（投稿はこちら）の抄訳です。
- By Luke Stone and Jian Ma
