SRE の教訓 : Google におけるインシデント管理とは

Google で何かおかしなことが起こったらどうなるか、考えたことはありますか？ この業界は面白い比喩を使うのが好きで、何か起こった際に対処することを「火消し」と呼んだりします。

上の写真に写っている実際の消防士の場合とは異なり、Google で起こった事故で生命の危険にさらされることは通常はありません。つまり完璧な比喩にはなっていないのですが、Google の Site Reliability Engineer（SRE : サイト信頼性エンジニア）の 1 次対応は、他の分野での 1 次対応と共通点が多いのです。

他分野での 1 次対応と同様、Google の SRE は定期的に緊急時対応の訓練を行い、迅速かつ効率的に目の前の問題が解決できるよう、スキルやツール、テクニック、態度に磨きをかけます。

緊急時のサービス対応チームおよび Google では、何かが起こったときのことを「インシデント」と呼んでいます。

このブログ記事では、Google の SRE として私が初めて経験したインシデントについてお話しします。

プロローグ : 準備段階

私は毎週 “Wheel of Misfortune”（不運のルーレット）というセッションに参加し、オンコール担当者が体験する典型的な問題を与えられ、その解決に取り組みました。また、実際のオンコール担当者と一緒に対応の手助けもしました。第 2 オンコール担当者となって、第 1 担当者が受けた緊急の問題を支援したり、さほど緊急でない問題には 1 人で対処したりしていたのです。

すべての準備が整えば、いつかは最前線に立たなくてはなりません。第 1 オンコール担当者となり、1 次対応者となるわけです。

編集部注 : 書籍『Site Reliability Engineering』の第 28 章 “Accelerating SREs to On-Call and Beyond”（オンコール対応と、さらにその先まで対応できる SRE になるには）には、新人の SRE が 1 次対応をこなせるようになるまでの Google での育成方法が詳しく書かれています。

オンコール担当者になるということ

私が初めてオンコールのシフトを担当したときは、警告システムに 2 回ページされたこと¹ に加え、他の問題が 2 件も私のところまでエスカレーションされました。

呼び出しがあるごとに、私はアドレナリンが出るのを感じました。「きちんと対応できるだろうか？ もしできなかったらどうしよう」とも考えました。でも、私は訓練のとおりに目の前にある問題に取りかかりました。すべてを知っている必要はないということを思い出したのです。他の人に聞けば誰かが答えてくれます。私は担当者ではありますが、1 人ではなかったのです。

編集部注 : 書籍『Site Reliability Engineering』の第 11 章 “Being On-Call”（オンコール担当者とは）には、オンコール担当者としての仕事を長期間にわたって効率的にこなすためのさまざまなアドバイスが書かれています。

インシデント発生！

自分の担当するサービスで Compute Engine を利用していた Google のエンジニアが、テストの自動化に失敗し、調査の結果、少し変なインスタンスがあることに気づきました。そこで、開発チームの第 1 オンコール担当だった Parya に連絡し、彼女が私にも連絡してきたのです。

私は、より経験のある第 2 担当の Benson にも声をかけ、この 3 人と開発チームの関係者で調査を始めました。起こっていることが真の問題であると把握するまでに、そう時間はかかりませんでした。この問題を報告してきた内部ユーザーだけが影響を受けているとは思えなかったので、私たちはこれをインシデントと見なしました。

インシデントと見なすというのは、どういうことでしょうか。基本的には、その問題の影響や範囲、複雑さがある程度大きい可能性があるため、きちんとした担当者らが協力して効率的に対処する必要があるということです。

ちなみに、Google Cloud Status Dashboard のまとめページに書かれていることは、すべて Google の誰かがある時点でインシデントと見なしたものです。実務的な話をすると、Google では内部インシデント管理ツールに新しいインシデントの項目を作成したときに、それをインシデントと見なしています。

オンコール担当者としての訓練を受けた際、私は Google のインシデント管理手順の原則に従い、インシデント対応を支援する内部ツールを使用しました。インシデント管理手順には関係者の役割や責任が定義されています。この投稿の最初の部分で、私は Google の SRE と他の分野の 1 次対応には共通点が多いと書きました。驚くことではないのですが、Google のインシデント管理の工程は、他の分野の緊急対応で使われている確立されたインシデント指揮手順を参考にしているため、両者は似ているのです。

私の役割はインシデント指揮官でした。問題をインシデントと見なしてから 7 分も経たないうちに、サポート チームのメンバーが外部コミュニケーション担当となりました。

このインシデントにおいては他の役割をあてがうことはしませんでしたが、今にして思えば、Parya がオペレーション リーダーだったと言えます。彼女は、必要に応じて他の人を呼び込むなどして、根本的原因の追究に力を発揮しました。

また、Benson はインシデント指揮官のアシスタントだったと言えるでしょう。私は「こうやって、こうやって、こうすればいいと思うんだけど、これでいいと思う？」といった感じで、さまざまな質問を彼に投げかけていたからです。

効率的なインシデント対応のカギの 1 つとなるのは、インシデント対応者と、インシデントの影響を受ける可能性がある人とが明確なコミュニケーションをとることです。そのコミュニケーションは、インシデント管理ツールでも行われます。インシデント管理ツールは、Google 担当者が Google のサービスで起こっているインシデントについて知ることができる中心的な存在になっています。

また同ツールは、詳細が書かれた問題追跡データベースや、インシデント対応の調整に使われているコミュニケーション チャネルなど、Google 担当者に関連リソースも提供します。

編集部注 : 書籍『Site Reliability Engineering』の第 12 章、13 章、14 章は、効率的なトラブルシューティング、緊急対応、インシデント管理について書かれています。

SRE の火消しツールはロールバック機能

一部のメンバーが問題の範囲を把握しようとする一方で、他のメンバーはインシデントの解決に向けたアクションがとれるよう、問題の近因や根本的原因を探っていました。問題の範囲はある程度限られていることがわかり、原因については公開リリースに含まれていた、ある変更が元となっていることがわかりました。

これはよくあることです。稼働中のシステムにおける問題の多くは、新しい設定やバイナリ、そしてそれらの実行に必要なサービスに対して何か変更を加えることによって起こります。

こうしたよくある状況において役に立つベスト プラクティスが 2 つあります。

1 つは、緊急でない変更は徐々に行うべきだということです。簡単に言うと、すべて同時に変更しないようにするのです。こうすることで、今回のように多くのお客様に影響が出るような大問題に発展する前に、問題に気づく時間が生まれたりします。

もう 1 つは、公開するにあたっては、しっかりと理解され、きちんとテストされているロールバック機能が必要だということです。つまり、どの変更によって問題が起こっているのかが判明したときに、サービスを修復する「取り消し」ボタンが必要なのです。

徐々に公開して問題を最小限に抑え、信頼できるロールバック機能で迅速に問題に対処することこそ、サービス レベル目標（SLO）を追求するうえで非常に強力な 2 つのツールとなります。

今回のインシデントも、このパターンに当てはまります。問題が小さいうちに把握し、ロールバックによって迅速に「火消し」することができたからです。

編集部注 : 書籍『Site Reliability Engineering』の付録 B “A Collection of Best Practices for Production Services”（稼働中のサービスにおけるベスト プラクティス集）には、ここで触れたベスト プラクティスやその他のベスト プラクティスの詳細が書かれています。

エピローグ : 事後分析

Google には、誰も責めることなく事後分析を行うカルチャーがあります。何かおかしなことが起こっても、そのことで誰かを責めたり罰したりしてはいけないと考えているのです。今回の物語に登場した人たちも、みな善意から何かを手がけており、インシデントの発生時点で手元にある情報を駆使して、できる限りのことをやっています。

耐久性のある変更を行いつつ、今後似たような問題を起こさないためには、システムやツール、人に関するプロセスの改善方法を見いだし、同じことが決して起こらないようにしなくてはなりません。

インシデントの影響は限られており、バグの性質も大したものではありませんでしたが、事後分析によって今後問題を避けたり、同じ問題が起こった際に早期に発見して解決したりするには、補足のアクションが 9 つ必要であることがわかりました。この 9 つの課題は、担当者を割り当てたうえで、すべてバグ追跡データベースにファイルされました。これで今後もこの問題が考慮され、研究や追跡が行われるはずです。

事後分析からわかったことは、補足のアクションだけではありません。Google では、すべてのインシデントで事後分析を行い、事後分析ドキュメントには共通のテンプレートを使用します。そのため、全般的なトレンドを分析することも可能です。Google で発生したインシデントの大半が設定の変更によるものだったことが判明したのも、このためなのです（誰かが「ちょっと設定を変更するだけじゃないか」と言って、連休前の金曜日に変更を実施しようと言い出したら、このことを思い出してください）。

事後分析は関連チームにも共有されます。たとえば Compute Engine チームの場合、インシデント レビューに関するミーティングを毎週実施し、多くの SRE 担当者や Compute Engine の開発者に対してインシデント対応者が事後分析を発表します。

こうすることで、見過ごす可能性のある補足事項が確認できるほか、幅広いチーム メンバーとの間で教訓を共有でき、事例研究で信頼性について深く考えられるようになります。これは、誰も責めることなく事後分析する Google のカルチャーを浸透させる方法でもあります。

あるとき、このミーティングで、問題の責任は自分にあるといったような事後分析をする人がいたのですが、ミーティングの司会者は「自分が犠牲になろうとする気持ちは有り難いのですが、ここではそんなことはしないんですよ」と教えていました。

Google のステータスを示すページに「Google はこの問題に関する内部調査を実施し、問題の再発防止に向け、また問題を最小限にとどめるため、システムを適切に改善します」と書かれているのを目にしたときは、今回の話を思い出してください。Google でのインシデント対応を第 1 担当者として経験した私が言うのですから、この言葉が表面的な約束でないことはわかっていただけると思います。

編集部注 : 書籍『Site Reliability Engineering』の第 15 章 “Postmortem Culture: Learning from Failure”（事後分析カルチャー : 学びと失敗）には、事後分析カルチャーの詳細が書かれています。 

_{1）今では呼び出しの際にページャーを使うことはないのですが、どんなデバイスやコミュニケーション方法を使っていても、いまだに呼び出しのことを「ページする」と言ってしまいます。}

* この投稿は米国時間 2 月 27 日、Incident Commander である Paul Newson によって投稿されたもの（投稿はこちら）の抄訳です。

- By Paul Newson, Incident Commander