パブリック クラウドのサポータビリティ向上を目指して

※この投稿は米国時間 2019 年 9 月 9 日に Google Cloud blog に投稿されたものの抄訳です。

Google Cloud テクニカル サポート チームは、サポートケースを通してお客様の課題解決のお手伝いをしています。また、Google Cloud プロダクトのサポータビリティを高めることにも時間を割き、お客様のサポート ケースをより短時間で解決することに加えて、サポートケース自体を減らすことにも取り組んでいます。

Google Cloud プロダクトを支える大規模かつ複雑で変化の激しい分散システムのサポートには多くの難題があり、私たちはその解決に向けてさまざまなツールやベスト プラクティスを生み出してきました。もちろん、解決しなければならない課題はまだ多数残されていますが、この投稿ではサポータビリティに関する私たちの取り組みの一端をご紹介します。

サポータビリティの定義 : サポータビリティ（supportability）という用語は、Wikipedia では保守性（serviceability）の同義語とされ、製品が抱える問題を解決するスピードだと定義されています。しかし、私たちはこの言葉を、お客様のサポート ケースを早期に解決するだけでなく、テクニカル サポート エクスペリエンス全体を網羅するように一歩進めた形で再定義したかったのです。

サポータビリティの測定 : 私たちは取り組みの出発点として、SRE（Site Reliability Engineering）担当の同僚が信頼性を測定するために使っている SLO のような、能力の評価に使用する客観的な測定の方法をサポータビリティにも設定したいと考えました。

サポータビリティの測定は、当初は顧客満足度のトランザクショナル調査を頼りにしていました。トランザクショナル調査の結果は、お客様の期待を上回ったときとそうでないときを見分けるシグナルとなります。しかし、そうした調査では、サポート品質の全体像はなかなか見えてきません。そこで最近では、お客様の負担度を表す指標（customer effort score : 顧客努力指標）を多用するようになっています。これは顧客調査から編み出した指標で、問題解決のためにお客様が払った労力の度合いを示します。顧客努力指標は、さほど苦労せずに問題を解決するという、お客様がテクニカル サポートに本来求めているものと強く相関していることが研究でも示されています。

ただし、これだけではお客様の労力しか考慮されないので、発生した問題には人間やその他のリソースを割り当てればよいとか、Google Cloud プロダクト エンジニアリング チームに負担を押し付ければよいといった考えに陥る危険があります。そこで、関係者全体の負担を含め、次のような形でサポータビリティを測定することにしました。

お客様のサポート ケースを解決することに要する、お客様、サポートおよびプロダクト チームの労力

労力が増えるとサポータビリティは低くなることに注意する必要がありますが、労力をかけないことよりも実際に労力を測定したほうが、より直感的だと考えたのです。

現在、次のものを含むさまざまな指標を使って全体の労力を測定しています。

• 顧客努力指標 : 問題解決のためにお客様が払った労力の度合い

• 解決所要時間 : サポート ケースのオープンからクローズまでの時間

• 問い合わせ率 : 製品の 1 ユーザーあたりのサポート ケースの件数

• バグ率 : プロダクト エンジニアリング チームにエスカレーションされたサポート ケースの割合

• 照会率 : サポート チームのスペシャリストにエスカレーションされたサポート ケースの割合

いくつかの前提を設けることにより、この指標を正規化して製品間で比較できるようにし、ターゲットを設定できます。

サポータビリティの課題 : 大規模な分散システムは、モノリシックなシステムよりも問題のトラブルシューティングがかなり難しくなります。その主な理由は次のとおりです。

• 本番環境は絶えず変化しています。各製品が多数のコンポーネントを持ち、それぞれが定期的に新しいバージョンをロールアウトします。しかも、それらのコンポーネントが、それぞれ独自のロールアウト スケジュールを持つものに複数依存している場合もあります。

• App Engine などのサービスを利用しているお客様は、開発者として Google Cloud 内のプラットフォーム上でお客様独自のコードを実行している可能性があります。私たちはお客様のコード自体をチェックできないため、こうしたお客様の場合、明確に定義された API を持つ製品とは比べものにならないほどエラーが起こるシナリオの可能性が大きく広がります。

• ホストとネットワークはともに仮想化されているため、ping や traceroute のような従来のトラブルシューティング ツールは役に立ちません。

• モノリシックなシステムのサポートの場合は、ナレッジベースでエラーメッセージを検索すれば解決方法のヒントが得られます。それに対して分散システムのエラーメッセージは、RPC（リモート プロシージャ コール）を多用するアーキテクチャが原因で、簡単に検索できないことがあります。さらに、API によっては毎秒数百万の呼び出しがかかる大規模なパブリック クラウドでは、エラーに対応するログ データを見つけることが困難な場合があります。

サポータビリティ向上のためのプラクティス

チームの発展とともに、私たちはサポート結果の改善につながるプラクティスを生み出してきました。その一部をご紹介します。

ローンチ レビュー : 私たちは過去数年の間に 100 種を超える製品をローンチしており、各製品はそれぞれ定期的に機能の追加を実施しているため、毎日複数のローンチがあります。ここ数年は、関連するチーム間のコミュニケーション システムも開発してきました。また、製品ごとに PEL（product engagement lead）と呼ばれるサポータビリティ プログラム マネージャーとサポート エンジニアを割り当て、プロダクト エンジニアリング チームへの窓口にするとともに、重要な顧客対応機能を含むすべてのローンチを審査しています。PRR（product readiness review）を設けている SRE と同様に、製品ライフサイクルの各ステージ（アルファ、ベータ、GA）において適切なサポート リソースとプロセスが準備できていることを検証するローンチ チェックリストに従って承認を出しています。チェックリストの重要項目には、社内ドキュメントの拡充、サポート エンジニアのトレーニング、社内 SLA を満たす課題対応プロセス、トラブルシューティング ツールへのアクセス、関連ケースを調査・追跡するためのツールの設定などが含まれます。また、非推奨機能をチェックして、お客様のために実現性のある移行パスを確保し、適切な通知がお客様に確実に届くようにするプランも立てています。

学習ツールの整備 : サポータビリティに取り組むにあたって、私たちはサポート ケース作成の必要性を減らすことにも重点を置いています。以前は、1 つのプロダクト スイートにおけるサポート ケースの 75 % は「ハウツー」の質問でした。そこでテクニカル サポート チームのエンジニアたちは、お客様がサポート ケースを作成する際に関連ドキュメントを参照できるようなシステムを作り、これがお客様自らによる問題解決に貢献しました。このほうが、サポート ケースを作成するよりも負担は大きく軽減されます。これと同じシステムが、ドキュメントの不具合を見つけることにも役立っています。サポート ケースを作りにくくしてお客様をイライラさせることがないように、A/B テストを使ってサポート ケースの傾向を測定し、顧客満足度を注意深くモニタリングしました。

一部のサポート ケースは人間の介在なしで解決することができます。たとえば、お客様がある特定製品の P1 ケースをたびたび作成するのは、クォータ超過による機能停止が理由だとわかりました。そこで、届いたサポート ケースをチェックし、この問題やその他の既知の問題を人間の手を介さずに処理する自動システムを構築しました。私たちのロボット ケース ハンドラは、満足度のトランザクショナル調査でチーム内最高のスコアを獲得しています。

信頼性の高いアプリケーションの作成を支援するため、サポート チームのメンバーは、Google SRE で使用されている原則をお客様に教示する CRE（Customer Reliability Engineering）チームの設立にも関わりました。CRE は、お客様のアプリケーションがインシデントを起こしたときに Google のページャーが鳴る「運命共同体」サービスを提供します。

サポータビリティのスケーリング : 複雑さに対処するための 1 つの方法は、サポート エンジニアの担当製品をできる限り少数に絞り込み、彼らが専門能力を短時間で高めることができるようにすることです。製品ごとのシャーディングは、対応できる範囲と専門的な能力のトレードオフです。Google のサポート エンジニアは、サポート ケースが多い 1～2 種類の製品に関する専門的な知識を持ち、サポート ケースが少ない多数の製品についてもある程度の専門能力を有しています。サポート ケースのボリュームが増えれば、狭い範囲で専門的な知識を蓄積できます。

私たちは、製品がどのように実装されているかをサポート エンジニアが理解できるように、各製品のアーキテクチャ図を保管しています。アーキテクチャに関する知識は、エラーを起こしたコンポーネントを特定したり、その部分を担当する SRE チームに連絡を取ったりする際に役立ちます。また、私たちは各製品のプレイブックも管理しています。標準的な事象に対するプレイブックは、クォータの増量のような、よく知られたプロセスの手順を提供してくれます。これらのプレイブックで手順が記載できるものは、将来的に自動化の対象となりえます。より詳しく事象を調べるための診断用プレイブックは、たとえばお客様の App Engine アプリケーションが低速化したケースといった問題カテゴリのトラブルシューティング手順です。私たちは、診断用プレイブックにおいて、最も一般的な一連の問題を網羅するよう努めています。なお、『The Checklist Manifesto』は、こういったタイプのプレイブックの利点を見事に明らかにしています。

解決に時間を要するサポート ケースを重点的に取り上げることが特に有用だということもわかっています。そこで私たちは、製品ごとに毎週会議を開き、解決に時間を要したサポート ケースをレビューしています。解決に時間がかかる原因のパターンは明らかにできており、それに基づいてプロセスの改善方法を提案したり、問題防止のためのトレーニングやドキュメントを準備したりしています。

サポータビリティの将来 : Google Cloud におけるサポータビリティのプラクティスは、サポートの品質、コスト、スケーラビリティを評価するにあたって、より厳格で計量的な方法を導入することを目的にプログラム管理チームによって最初に開始されました。このプラクティスは、現在ではエンジニアリングの原則とベスト プラクティスの定義を進めるところまで進化してきています。また、サポータビリティへの取り組みは SRE と似ている点があります。Google 社内で SRE という職務が必要とされたのは、Google のシステムが大規模かつ複雑すぎて、従来のシステム管理手法では信頼性やコスト効率の点で不満の残るシステム管理しか行えなかったからです。SRE チームは信頼性を中心とする新しいエンジニアリング プラクティスを開発しました。同様に、サポート チームのテクニカル ソリューション エンジニアも、サポート ケースの処理経験を生かしてサポータビリティの向上に努めています。私たちは、自らの技術スキルと運用経験を活用して、サポータビリティを高めるツールやシステムの構築方法を常に模索しています。

成長を続けるクラウドは、私たちに新しい課題を突きつけています。高品質のサポートを大規模に提供するためには、イノベーティブな方法を見つけ出さなければなりません。サポータビリティに取り組むことはすばらしい時間を過ごすことであり、お客様のエクスペリエンスに有意義な影響をもたらす大きなチャンスでもあります。私たちも、現在チームを拡張しているところです。

- By Luke Stone, Technical Solutions Engineer, Google Cloud Platform and John Lowry, Technical Solutions Engineer, Google Cloud Platform

- Lilli Mulvaney, head of supportability programs, Google Cloud Platform, also contributed to this blog post.