Google Cloud

クラウド時代のトラブルシューティング : 解決に役立つプロバイダーとのコミュニケーション（前編）

2018年7月6日

Google Cloud Japan Team

編集部注 : 今回の記事は、数年前に SRE（サイト信頼性エンジニアリング）の本を出した（本当に！）Google エキスパートチームが執筆してくれました。実際に手を動かして学ぶ同書の姉妹書『The Site Reliability Workbook』も発売に向けて準備が進んでいるようです。ここでは、多くの IT チームにとって重要な SRE の一分野である、クラウドコンピューティング時代のトラブルシューティングについて取り上げます。今回は 2 回連載の前編です。本稿を読み終えたら、クラウドプロバイダーとのコミュニケーション方法をテーマにした後編もぜひご覧ください。

技術的な問題を効果的に解決するためには、運や経験に頼るのではなく、系統的なアプローチが必要です。書籍『Site Reliability Engineering』の中でも述べたように、トラブルシューティングは学習できるスキルです。

しかしながら、クラウドインフラストラクチャ上でシステムやサービスを実行するようになって、あなたや運用チームはどう変わりましたか？　ウェブサイトやアプリがどこで実行されているかにかかわらず、サイトが落ちたときに呼び出しがかかり、問題を解決し、疑問を解明しなければならないというプレッシャーにさらされるのは、依然としてあなたではないですか？

クラウドは、IT チームが旧来のシステムから移行しつつある新しい仕事の形です。システムがオンプレミスに存在したときは、システムのあらゆる側面を見てコントロールすることができました。しかし、オフサイトにあるクラウドベースのインフラストラクチャに依拠するようになると、見ることで理解できる部分は限られてきます。それは、システムやプロセスがいかに一流で、あなたがいかに優秀なトラブルシューターであっても同じです。通常、クラウドプロバイダーシステムの中身は見られる部分が限られています。

難しいのは純粋なデバッグだけではありません。クラウドプロバイダーとうまくコミュニケーションを取る必要があるのです。プロバイダーのサポートプロセスやエンジニアと関わりを持ち、問題がどこにあるかを協力して突き止め、できる限り早く問題を解決しなければなりません。これは、IT チームが新しいスキルを獲得し、クラウドベースの技術モデルに適応するための格好のチャンスでもあります。

正しいクラウドトラブルシューティングは間違いなく可能です。重要なのは、クラウドプロバイダーを選ぶときに、彼らが問題発生時にどのように協力してくれるかをきちんと見極めることです。実際にプロバイダーと付き合い始めると、問題の伝え方や解決までのスピードに関して、あなたが思う以上にあなたは大きな役割を果たします。

私たちは、SRE モデルのアクショナブルな改善をヒントに、クラウドプロバイダーとの協力のもとで行う、より効果的で効率的なトラブルシューティングを提案したいと思います（トラブルシューティングプロセスを通じたクラウドプロバイダーとのコミュニケーションの方法については後編をご覧ください）。

クラウドプロバイダーのサポートワークフローを把握する

問題は避けがたく発生します。したがって、ここでの目標は、問題が実際に発生したときに、プロバイダーに対して情報を適切に提供する最善の方法を見つけ出すことです。インフラストラクチャ向けにおそらく複数のクラウドプロバイダーを利用していることを考慮すると、まずはここから着手するのがうまいやり方です。通常、クラウドプロバイダーのサポート担当とのやり取りは、マイグレーションに関連した質疑応答から始まり、本番環境のインテグレーション、本番環境で生じた問題のトラブルシューティングへと進んでいきます。

頭に入れておきたいのは、顧客とのやり取りについての考え方がプロバイダーごとに異なるということです。たとえば、顧客に大きな自由度を与える代わりに直接的なサポートをあまり提供しないプロバイダーもあります。そのようなプロバイダーは、顧客自身が Stack Overflow などのオンラインフォーラムから答えを見つけるべきだと考えています。逆に、顧客と密接な関係を持ち、協力してトラブルシューティングにあたることを強調するプロバイダーもあります。

トラフィックをクラウドで本格的に処理するつもりなら、必ず済ませておかなければならない宿題があります。クラウドプロバイダーの営業担当者、プロジェクトマネージャー、サポートエンジニアと話をすることです。そして、プロバイダーがサポートにどのように取り組んでいるか、感触をつかんでおきましょう。次のような質問をしてみてください。

サポートに対する典型的なイシューレポートのライフサイクルはどうなっているか？
問題が複雑もしくは重大な場合の社内のエスカレーションプロセスはどうなっているか？
<サービス名>の社内サービスレベル目標（SLO）はあるか？　ある場合、その内容はどうなっているか？
プレミアムサポートとしてどのようなタイプのものを利用できるのか？

このステップは、クラウドプロバイダーの巨大なブラックボックスが関係している問題のトラブルシューティングにまつわる不満を軽減するうえで不可欠です。

クラウドプロバイダーのサポート担当との効率的なコミュニケーション

プロバイダーのサポートワークフローがどのようなものなのか、その感じがつかめれば最良の情報伝達方法がわかります。その問題についてなぜ言及するのかを含め、プロバイダーのサポートチームに完璧なイシューレポートを送るときに役立つベストプラクティスがあります。報告の 80 % で役に立つ詳細情報の 20 % を知らせるという 80/20 ルールに従うのです。イシュートラッカー、ユーザーグループ、フォーラムなどにバグレポートを送る際にも同じ原則が当てはまります。

クラウドプロバイダーとのコミュニケーションを図るにあたっては、その方針に明確性が含まれていなければなりません。適切なレベルの技術的詳細を示し、望むことを明確に伝えることが大切です。

基本情報の提供
常識だと思われるかもしれませんが、イシューレポートに基本情報を含めることはきわめて重要です。これらの詳細を書き漏らすと、解決の遅れや不満の残る対応の原因になります。

4 つの必須情報
効果的なトラブルシューティングは、時刻、製品、位置、具体的な識別子から始まります。

1. 時刻
イシューレポートへの時刻の記載例を見てみましょう。

太平洋夏時間 2017 年 9 月 8 日 15 時 13 分から 5 分後まで～が観察されました
2017 年 9 月 10 日以降、間欠的に 2～5 回観察されたことですが、～
太平洋夏時間 2017 年 9 月 8 日 15 時 13 分以降ずっと～
太平洋夏時間 2017 年 9 月 8 日 15 時 13 分から同 22 時 22 分まで～

発生時刻と期間を具体的に示せば、クラウドプロバイダーのサポートチームはその期間の時系列モニタリングに注力できます。問題がまだ続いているのか、過去に発生しただけなのかを明確にしましょう。問題が収まっているのなら、それを明確にし、可能なら終期をサポートチームに伝えてください。

また、タイムゾーンを忘れないようにしましょう。曖昧さがなく、ソートしやすい ISO 8601 形式を使うことをお勧めします。相対的な方式で時刻を記載してしまうと、相手は時系列モニタリングツールに時刻を入力するために、ローカルタイムを絶対形式に変換する必要が出てきます。この変換作業はミスの元であり、コストもかかります。たとえば、「昨日のもっと早い時間」に何かが起きたというようなメールを送ると、相手はメールヘッダを探し、頭の中で発生日時を計算しなければなりません。すると、認知的負荷が発生し、技術的な問題の解決に向けられる精神的エネルギーが減ってしまいます。

ある期間に問題が間欠的に起きた場合は、最初に観察されたときか、問題が確実に発生していなかった過去の時点を記載し、観察された頻度を入れ、具体例を 1～2 件示すとよいでしょう。

避けるべきアンチパターンを挙げておきます。

今日早く : 十分に特定できていません。
昨日 : 連絡を受け取った側が暗黙の日付を明らかにしなければなりません。特に日付変更線をまたがる場合は曖昧になります。
9/8 : 曖昧です。米国では 9 月、他の地域では 8 月だと解釈される恐れがあります。明確にするために ISO 8601 形式を使いましょう。

2. 製品
イシューレポートでは使用している製品をできる限り具体的に示し、必要に応じてバージョン情報も追加してください。たとえば、次のような表現では具体性が足りず、診断に役立つコンポーネントやログを特定できません。

REST API がエラーを返しました。
データマイニングのクエリインターフェースがハングアップしています。

理想を言えば、特定の API や URL を指定するか、スクリーンショットを添付したいところです。問題が起きたのが特定のコンポーネントやツールであれば（たとえば CLI や Terraform）、それを明確にしましょう。複数の製品が関与している場合は、一つひとつを明確にします。そして、観察した動作と、こうなるはずだと思っていた動作を記述します。

以下はアンチパターンです。

仮想マシンを作成できません。仮想マシンをどのようにして作ろうとしたのかがはっきりしません。エラーモードがどうなっているのかもわかりません。
CLI コマンドがエラーを返します。
エラーの内容を具体的に書き、コマンドの構文を明示して、他の人も実行できるようにしましょう。
より良い書き方 : “mktool create my-instance --zone us-central1” を実行したところ、次のようなエラーメッセージが返ってきました。

3. 位置
クラウドプロバイダーはリージョンやゾーン全体に変更をロールアウトすることが多いので、リージョンとゾーンを明確にすることは重要です。リージョンやゾーンの情報は、クラウドで稼働するソフトウェアのバージョン番号の代わりになります。

イシューレポートへの位置情報の記載例を見てみましょう。

us-east1 において～
リージョン eu-west-1 と eu-west-3 で試したところ～

位置情報があれば、クラウドプロバイダーのサポートチームはその場所でロールアウトが行われているかどうかを確かめたり、位置情報から社内リリース ID を割り出して社内用のバグレポートで報告したりすることができます。

4. 具体的な識別子
多くのトラブルシューティングツールにはプロジェクトの識別子が含まれています。エラーが発生したのは複数のプロジェクトなのか、それとも特定のプロジェクトだけなのかをはっきりさせましょう。

具体的な識別子とは、たとえば次のようなものです。

プロジェクト 123412341234 または my-project-id で～
複数のプロジェクト（123412341234 が含まれます）にわたって～
社内のゲートウェイ 56.56.56.56 からクラウドの対外 IP 218.239.8.9 に接続するとき～

IP アドレスは曖昧さのない識別子の 1 つですが、イシューレポートで使用する場合は追加の詳細情報が必要です。IP アドレスを指定するときは、どのように使われているかも書くようにしましょう。たとえば、その IP が VM インスタンスに接続されているのか、ロードバランサやカスタムルートに接続されているのか、あるいは API エンドポイントなのかといったことを明確にしてください。IP アドレスがクラウドプラットフォームの一部でなければ（たとえば、ホームインターネット、VPN エンドポイント、外部モニタリングシステムなど）、その情報も追加します。192.168.0.1 は世界中で無数に使われていることを忘れないようにしましょう。

以下はアンチパターンです。

弊社インスタンスの 1 つにつながりません : 曖昧すぎます。
インターネットから接続できません : 曖昧すぎます。

5W1H（ジャーナリズムなどでよく使われています）などのモデルも、イシューレポートを構造化するうえで役に立ちます。

問題発生の影響と回答に対する要望の明確化

クラウドプロバイダーに対するイシューレポートには、問題の発生がビジネスに及ぼす影響や、希望する回答期限なども含めるようにします。

期待する優先順位
クラウドプロバイダーは、イシューレポートの回覧や緊急度の判定の際に、顧客が指定した優先順位を使います。優先順位は対処のスピードを左右し、緊急だと判断されればオンコール担当者が呼び出されることもあります。

適切な優先順位以外に効果的なのが、どのような影響があるかの説明です。P1 を選んだ理由を明確にして、間違った思い込みをされないようにしてください。

優先順位はビジネスへの影響度を考慮して決めましょう。優先順位の厳密な定義を有しているクラウドプロバイダーもありますが（たとえば P1 は全面的なダウン）、そうした定義のせいでビジネスクリティカルな問題の解決が遅れることは避けなければなりません。問題が解決されない場合に予想される影響や最悪のシナリオをレポートに含めるようにしましょう。たとえば、次の 2 つの例は実質的に P1 に相当します。

バックログが増えてきています。現時点での影響はまだ小さいですが、12 時間以内に解決されなければ、システムは実質的にダウンした状態になります。
重要なモニタリングコンポーネントがエラーを起こしています。現時点では影響はありませんが、監視できない個所が生じており、それによってユーザーにもわかる機能停止が起きる恐れがあります。

希望する回答期限
回答期限に関して具体的なニーズがある場合は、それを明確に示しましょう。たとえば、「シフトが終了する午後 5 時までに回答をお願いします」とレポートに記します。緊急時の連絡に関する SLO が社内で規定されている場合は、その SLO を満たす形で回答期限を指定します。多くのクラウドプロバイダーは 24 時間 365 日体制のサポートを提供していますが、そうでない場合や担当者のタイムゾーンがずれている場合は、タイムゾーン固有のニーズをプロバイダーに伝えましょう。

これらの詳細情報をイシューレポートに含めれば、あなたの時間を無駄にせず、プロバイダーの修復作業全体をスピードアップさせる効果があるはずです。実際のトラブルシューティングプロセスにおいてクラウドプロバイダーとどのようなコミュニケーションを取るべきかについては、後編をご覧ください。