Google Cloud

事後分析を外部と共有することの意義 : CRE が現場で学んだこと

2017年12月15日

Google Cloud Japan Team

「サービス停止の要点と分析結果をまとめた事後分析を作成することで、システムの信頼性が向上し、サービス担当者も教訓を得られる」ということを、私たち Google の SRE（Site Reliability Engineering）チームはかねてから学んできました。

それでは、作成した事後分析を社内だけでなく外部と共有することについては、どうお考えでしょうか。そもそも、なぜそんなことをするのでしょう？それは、サービスプロバイダーやプラットフォームプロバイダーの場合、事後分析をお客様と共有することは、自社にとってもお客様にとっても良い結果をもたらす可能性があるからです。

今回の『CRE が現場で学んだこと』シリーズでは、外部向け事後分析の利点と弊害、またその作成方法に関する実践的な知識について解説します。

外部向け事後分析の事例

過去の事例を調べ、分析内容を読み解く

Google は長年にわたってサービス停止の情報を共有してきましたが、最近ではその詳細をこれまで以上に公表するようにしています。たとえば、2016 年 4 月 11 日に発生した Google Compute Engine による着信トラフィックのドロップを、このようなインシデントレポートとして公開しました。

同様に、他社でもサービス停止の詳細な事後分析を公表しています。以下はその一例で、記憶にある方も少なくないでしょう。

GitLab.com が誤って PostgreSQL データベースを削除、しかもバックアップがないことが判明した
CloudFlare のエッジサーバーでメモリリークが発生した
Honeycomb.io で Kafka のバグが利用された

Google の SRE チームはこうしたインシデントの事後分析を読むことを好みますが、別に他人の不幸を喜んでいるわけではありません。実際、SRE チームはこれを読んで “there but for the grace of (Deity) go we”（「明日は我が身」の意）と考え、同じような失敗に自分たちは耐えられるだろうかと思いを巡らせます。もし同じように感じている方がおられたら、災害復旧テスト（DiRT : Disaster Recovery Testing）の実施をお勧めします。

さまざまなユーザーに広くサービスを提供しているプラットフォームプロバイダーにとって、こうした事後分析を外部に公開することには意味があります（その準備はとても大変ですし、競合他社や報道機関からの批判にさらされるかもしれませんが）。たとえサービス停止の影響がさほど大きくないとしても、SRE を実践しているのであれば、直接影響を受けたお客様に事後分析を提供することは理にかなっています。お客様の信頼を気にかけるということは、サービス停止の詳細をお客様と共有することでもあります。

Google Cloud Platform（GCP）の CRE（Customer Reliability Engineering）チームも、これと同じ立場を取っています。GCP のことをお客様に信頼していただくため、SRE のベストプラクティスを共に実践し、サービスの信頼性向上につながる方法をお客様に伝えます。それぞれのお客様のサービスにおいて構造上のリスクや運用上のリスクを特定して数値化し、そのリスクを低減させるべく共同で取り組み、お客様の SLO（サービスレベル目標）に合ったシステムの信頼性を維持できるように努めます。

具体的には、CRE チームがお客様の SLO に見合う可用性を保てるよう、それぞれのお客様と共同で取り組みます。そのための主な手順は次のとおりです。

ビジネスに関連する SLO を包括的に定義する
お客様が自社の監視プラットフォームで SLO に準拠しているかを測定できるようにする（サービスのエラーバジェットがどれだけ使われているかを把握できるようにする）
Google のサポートおよびプロダクト担当 SRE チームとの間で生の SLO 情報を共有する（これは共有監視と呼ばれる）
SLO 違反をお客様と共同で監視し対応する（運用上の宿命を共有する）

プラットフォームやそれに似たものを運用しているのであれば、お客様と共同で SRE を実施してください。そうすれば信頼性が向上し、変更を施したときにお客様が戸惑うこともなくなり、障害が発生した際の影響やその範囲に関する知識も高まります。

また、サービスのエラーバジェットを超えるようなインシデントや、許容範囲以上の割合でエラーバジェットを使ってしまうようなインシデントが発生した場合、サービスプロバイダーは次のことを把握する必要があります。

エラーバジェットは合計でどれだけ使われたのか
なぜインシデントが起こったのか
同じインシデントが再発しないように、できること、やるべきことは何か

1 の質問には簡単に答えられますが、2 と 3 の質問を判断する仕組みに相当するのは事後分析となります。インシデントの根本的原因が純粋にお客様側にあるのであれば簡単ですが、自社のプラットフォーム側で発生した何かがきっかけだったとしたらどうでしょう。そういう場合は外部向け事後分析を検討すべきです。

外部向け事後分析の基礎となるもの

サービス停止の分析と、その内容を事後分析として書き起こすことで、プラットフォーム運用者とサービスプロバイダー双方から 2 種類の監視データを入手できることになります。これにより、インシデントはいつ発生したのか、どれくらい継続したのか、どれほどひどかったのか、お客様のエラーバジェットに対して合計でどれほどの影響があったのかなど、インシデントの外的影響を客観的に測定できます。

これが非常に役に立つと、GCP の CRE チームは考えています。エンドユーザー側の下層レベルのクラウドサービスで発生した問題は、その影響の測定が難しいためです。内部で 1 % のエラー率を観測してレイテンシが増加したとしても、スタックの多くのレイヤを移動すると、外部ではなかなか気づかないものです。

サービスプロバイダーの監視データと独自の監視情報を基に、プラットフォームチームは標準的な方法と Google の事後分析テンプレートに沿って事後分析を作成します。これにより、内部でレビューしたドキュメントが出来上がり、そこにはインシデントの時系列や、影響の範囲と大きさ、優先順位の高い行動などが書かれています。

優先順位の高い行動とは、こうした状況が発生する可能性を低くし（平均故障間隔の増加）、予想される影響を抑え、検知精度を向上させ（平均検知時間の短縮）、インシデントから迅速に回復すること（平均回復時間の短縮）を可能にするための行動です。

ただし、事後分析を外部と共有する場合はこれで終わりではありません。影響を受けたお客様に対して、すべてではないにしろ、一部の事後分析情報を公開するのです。

外部向け事後分析を誰に公開するべきか

SLO を定義したのがお客様である場合は、インシデントによってどれほど影響があったのかを、お客様は（あなた自身も）把握していることでしょう。一般に、インシデントによって使われたエラーバジェットが大きければ大きいほど、お客様はその詳細を詳しく知りたいと考えるため、情報共有の重要度も高まります。また、インシデントの直後には判明していなかった事故の範囲やタイミング、影響など、事後分析にまつわるフィードバックをお客様が提供してくれる可能性も高くなります。

お客様の SLO 規約には触れなかったものの、その問題がお客様のエンドユーザーにも影響を与えてしまったときは、お客様の側でも事後分析を行う必要があります。SLO やその測定方法に関して、どのような変更が必要なのかを見極めるのです。たとえば、可用性を測定していた場所が、実際に問題が発生した場所よりもずっと下のレイヤにあったのではないか、といったことなどです。

もしエンドユーザーエクスペリエンスを示す SLO をお客様が設定していなかった場合、客観的に事故を判断することは難しくなります。インシデントが特定のお客様に偏って影響を与えたことを示す明確な理由でもない限り、より包括的なインシデントレポートにするしかないでしょう。

もう 1 つ考慮すべき点としては、情報共有したいお客様と NDA（秘密保持契約）を結んでいるかどうかです。結んでいない場合、共有できる内容は必然的に厳しく制限されます。

障害によって多数のお客様に影響が及んだときは、上述した例のように、外部向け事後分析を一般向け事後分析やインシデントレポートのベースとすべきかどうかも検討しましょう。もちろん、これは（内部向け事後分析を編集して内部の承認を得るといった）一部のお客様とだけ共有する外部向け事後分析よりも大変な作業ですが、それなりの利点があります。

事後分析を完全に一般公開することの最大のメリットは、ユーザーからの信頼を取り戻せることではないでしょうか。プラットフォームを利用している 1 ユーザーの視点からすると、特定ユーザーの問題なんてプラットフォームプロバイダーは気にしていないと感じていることでしょう。そうしたユーザーに向けて事後分析を一般公開すれば、サービスに何が起こったのか、その理由は何だったのか、今後どうやって再発を防ごうとしているのかを多くのユーザーが把握できるようになります。

公開された情報を基にユーザーがミニ事後分析を行い、「もし同じことがまた起こったら、それをどう検知すればいいか、また自分たちのサービスへの影響を抑えるにはどうすればいいか」といったことをユーザー自身で考えるきっかけになるのです。

どこまで共有するか、なぜ共有するかを決める

外部向け事後分析を作成するにあたっては、サービス停止の原因をどこまで深く掘り下げるかについても考えなくてはなりません。内部向け事後分析をほとんど編集することなく提供するべきなのか、それとも短いインシデントサマリーを作成するべきなのか。これはややこしい問題で、Google 社内でもたびたび議論してきました。

Google では、簡単なサマリーではなく事後分析の詳細すべてをお客様に提供するかどうかを、以下の 2 点を基に決めています。

障害の再発防止を検討するにあたり、事後分析の詳細がどれだけ重要か
障害によってお客様のサービスはどれほどの損害を被ったか。つまり、どれだけエラーバジェットを使ったのか

もしお客様が内部向け事後分析から事故の詳細な時系列を把握できたとしたら、お客様側の監視による警告と関連づけることができ、今後は事故検知までの時間を短縮できるかもしれません。逆に、サービス停止で使った 30 日間のエラーバジェットがわずか 8 % だった場合、お客様はこうした事故が 1 か月に一度以上発生する可能性があるかどうかを知りたいだけということもあります。

Google は、自動化と実践を組み合わせることで、内部向け事後分析の共有可能なバージョンを、10 % の追加作業と内部レビューによって作成できるようにしました。欠点としては、作業開始前に事後分析が完了またはほぼ完了するのを待たなくてはならないことです。一方、インシデントレポートについては、事後分析作成担当者が根本的原因をほぼ突き止めた段階で、事後分析と同等の労力で作成できます。

事後分析の内容

事後分析が作成される頃にはインシデントも解決しています。その段階でお客様が本当に知りたいのは以下の 3 点です。

なぜインシデントが発生したのか？
よりひどくなる可能性はあったのか？
どうすればもう発生しないと確信が持てるのか？

「なぜインシデントが発生したのか？」は、Google の事後分析テンプレートの “Root causes and Trigger”（根本的原因ときっかけ）や “What went wrong”（何が間違っていたのか）のセクションに当てはまります。また、「よりひどくなる可能性はあったのか？」は “Where we got lucky”（運が良かった点）です。

この 2 点は、内部向け事後分析にできるだけそのまま記載すべき項目です。とはいえ、わかりやすく言い換える必要はあるかもしれません。

「どうすればもう発生しないと確信が持てるのか？」は、事後分析の中のやるべきことに関する表に当てはまります。

記載してはいけないこと

事後分析には以下の 3 点を記載してはならないことも覚えておきましょう。

人の名前 : 「John Smith さんが誤ってサーバーを蹴飛ばしてしまった」とするのではなく、「ネットワークエンジニアが誤ってサーバーを蹴飛ばしてしまった」と書きましょう。Google 社内では人の役割を人名ではなく役職で表現するようにしています。こうすることで、誰も責めることのない事後分析カルチャーが保たれています。
内部システムの名称 : 内部システムの名称はユーザーに公表しておらず、それがどう組み合わさっているのかを把握することもユーザーにとっては困難です。たとえば、Google では Chubby のことを社外の人に話す機会がありますが、外部向け事後分析には「われわれのグローバル分散ロックシステム」と記載しています。
お客様固有の情報 : 内部向け事後分析にはおそらく「x 時 x 分に Acme 社から問題が発生したことを知らせるサポートチケットが発行された」と記載されていると思いますが、こうした詳細は報告した企業（この場合は Acme 社）に過度の負担がかかる可能性があるため、外部と共有するのは控えるべきです。ここでは簡単に、「x 時 x 分にお客様から ……」としておきます。1 社以上のお客様について記載する場合は、お客様 A、お客様 B などとして区別しましょう。

その他、気をつけるべきこと

事後分析を外部と共有するうえで、もう 1 点難しいことがあります。それは、インシデントの状況を設定する “Background”（背景）のセクションです。内部向け事後分析の場合、読者が技術的背景および運用の背景に関する基礎的な知識を有していることを想定して書かれていますが、外部のお客様がそのような知識を持ち合わせているとはかぎりません。

Google では、細かい説明を最小限に抑えつつも、なぜインシデントが発生したのかを読者が把握できるようにしています。ここで詳細を記載しすぎると、役に立つというより不快感を与えてしまうおそれがあるのです。

Google の SRE チームは、よく事後分析に監視グラフを組み込みます。監視データは客観的で、一般的に嘘をつくことはありません（とはいえ、それが当てはまらないこともあります。これについては、Google の Sebastian Kirsch が便利な指標を示しています）。

ただし、事後分析を社外と共有するにあたっては、こうしたグラフの情報がトラフィックレベルやサービスのユーザー数などを公にしてしまう点に気をつけましょう。目安としては、X 軸（時間）はそのままにしておき、Y 軸は指標や数量を消すか、割合のみを示すようにしてください。これは、お客様側で生成されたデータを内部向け事後分析に組み入れる場合にも言えることです。

運が果たす役割

Tina Turner の『What's Love Got To Do With It』（「いったい愛と何の関係があるの？」の意。邦題は『愛の魔力』）という歌には申し訳ないですが、ここでは “What's Luck Got To Do With It”（いったい運と何の関係があるの？）」としておきましょう。今後の障害の原因となるもの以外の運とは何なのでしょうか。

Google の内部事後分析テンプレートには、“What went well”（何がうまくいったのか）や “What went badly”（何がうまくいかなかったのか）はもちろんのこと、“Where we got lucky”（運が良かった点）という項目も含まれています。

運に関する項目は、インシデントで発覚した今後の障害のリスクを引き出すのに役立ちます。インシデントはたいてい、タイミングや、ある特定の人がオンコール担当だったこと、別の障害が同時に発生して通常より詳しい精査が本番システムで必要になったことなど、比較的ランダムな要素によって、実際に与えたであろう影響よりも小さな影響しか出ないことが多いのです。

「運が良かった点」は、事後分析において追加でやるべきことを確認するきっかけとなります。たとえば次のようなことです。

「適切な人がオンコール担当だった」ということは、作戦ノートに記載すべき部門知識が存在しているということです。災害復旧テストでもその内容を実施する必要があります。
「（バッチプロセスやユーザーアクションなど）他のことが同時に起こっていなかった」ということは、ピーク時の負荷を処理するのに十分な容量がシステムに備わっていないということです。リソースの追加を検討すべきでしょう。
「インシデントの発生が業務時間内だった」ということは、自動アラートや 24 時間ページャーで呼び出せるようなオンコール体制が必要だということです。
「すでに監視モニターを見ているところだった」ということは、積極的に監視していなくても似たような最先端のインシデントを見つけられるよう、アラートのルールを調整する必要があるということです。

事後分析に “Where we got unlucky”（不運だった点）について書くこともあります。いくつもの状況が重なってインシデントの影響が大きくなったものの、同様のことが起こる可能性は低いケースがそれに当たります。不運な例としては以下のようなものがあります。

1 年で最も忙しい日にサービス停止が発生した
問題は修復していたものの、他の理由により、まだロールアウトしていなかった
天候が原因で停電が発生した

「不運だった点」というカテゴリーを設けることの主なリスクは、実際には不運が原因ではないにもかかわらず、問題を不運だったと分類してしまうことです。内部向け事後分析で以下のように報告された例を見てみましょう。

不運だった点

過去の障害や実験により、本番環境にさまざまな矛盾が生じていた。それが適切に処理されておらず、本番環境の状態を判断するのが困難だった。

これは、“What went badly”（何がうまくいかなかったのか）に分類すべきでしょう。取り組むべき点が明らかであり、今後に向けた修正も可能だからです。

このような不運に見舞われたときは、必ず「何がうまく行かなかったのか」に記録するようにし、今後発生する可能性を算定するとともに、どう対処すべきかも決めるようにしてください。開発時間は限られているため、すべてのリスクを低減しようとは思わないかもしれませんが、常にすべてのリスクを列挙して数値化し、状況が変わっても「未来の自分」がその決定を見直せるようにしておきましょう。