Lowe’s が SRE により平均復元時間（MTTR）を 80 パーセント以上削減した方法
Google Cloud Japan Team
※この投稿は米国時間 2021 年 9 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。
編集者注: 以前のブログ投稿で、住宅リフォーム小売業者の Lowe’s が Google Cloud で Google のサイト信頼性エンジニアリング（SRE）フレームワークを採用し、サポートできるリリース数を増加させた事例をご紹介しました。Lowe’s はリリースの頻度を 2 週間に 1 回から 1 日 20 回以上に増加させ、顧客のニーズにより迅速かつ効率的に対応できるようになりました。本日は、Lowe’s の SRE チームから、SRE の原則を活用して平均復元時間（MTTR）を 80 パーセント以上も削減させた手法をご紹介いただきます。
Lowes.com の管理の重要性はかつてなく高まっています。つまり、お客様が当社のサイトで取引を続けられるように、可能な限り迅速にインシデントを特定し、トラブルシューティングを行って復元する必要があるということです。
そのためには、確固としたインシデント エンジニアリング手法を確立することが重要です。「インシデントを解決する」とは、その影響を緩和し、サービスを以前の状態に戻すことを意味します。これにかかる平均時間を「平均復元時間（MTTR）」と呼びます。この指標をトラッキングすることで、Lowe’s のシステムの全体的な信頼性を常に把握できると同時に、復元のスピードを改善できます。当社の目標は、エラーがあってもビジネスに悪影響が及ばないよう、MTTR の指標を可能な限り低く抑えることです。当社では、MTTR を全体的に改善するために、次の 4 つの領域に取り組みました。
Lowe’s のインシデント報告プロセス
MTTR を削減するために、SRE の原則に従ってシームレスなインシデント報告プロセスを定めました。当社のインシデント報告プロセスは、インシデントが発生した時点で開始し、事後調査の報告後に SRE 責任者がアクション アイテムをクローズすることで終了するというワークフローです。このアプローチにより、重大なインシデントの件数を抑えることができています。この報告プロセスを構成するのは、モニタリング、アラート、過失を責めない事後調査（ブレームレス ポストモータム）という 3 つの中核的な要素です。
モニタリングとアラート
インシデント管理に関しては、適切なモニタリングとアラートを実施することが重要です。モニタリングとアラートのツールにより、問題が発生すると即座に検出でき、可能な限り短時間で最適な担当者が通知を受けて対処できます。測定の観点からは、これを平均確認応答時間（MTTA）としてトラッキングしています。これは、アラートがトリガーされてから問題への対処が開始されるまでの平均時間です。
インシデントが発生した時点で、モニタリングとアラートのツールが PagerDuty を介して電話、テキスト メッセージ、メールの形式でオンコールの SRE 第一対応者に通知します。当社の SRE ソフトウェア エンジニアリング チームは、さまざまなサービスレベル指標（SLI）アラートやサービスレベル契約（SLA）通知を可能にするために多数の自動化を行ってきました。オンコールの SRE 担当者はその後、サービス / ドメインの関係者とのトリアージ コールを開始してインシデントを解決します。この結果、MTTA を 2019 年の 30 分から 1 分に削減できました。削減率は 97 パーセントです。
過失を責めない事後調査: インシデントから教訓を得る
事後調査はインシデントに関する書面の記録で、インシデントの影響、解決のためにとったアクション、原因、インシデント再発防止のためのフォローアップ アクションが記載されます（サンプルはこちら）。過失を責めない事後調査はこれを基盤としており、SRE の文化、そして Lowe’s の文化の中核をなしています。個人を非難の対象とすることなく、すべての事後調査の結果を教訓とプロセス改善の糧にしています。
当社にとって、事後調査のプロセスはインシデント ワークフローにおいて最も大きな部分を占めます。SRE が新しい事後調査レポートを作成する場合、その最初のステップは、レポートの確認を担当するドメインの関係者と事後調査セッションを実施することです。その後、事後調査は確認段階に入り、週 1 回の事後調査会議で他の関係者による確認も行われます。プロセスの最終段階では、週 1 回の会議にて参加者全員がレポートの完成に同意した後、SRE 責任者がレポートをクローズします。
事後調査を適切に行うには、個人ではなく、システムおよび運用プロセスの不備や問題に焦点を当て続け、特定した問題に対処するための具体的なアクションを定めることが重要です。これを確実に行うために、当社はいくつかのベスト プラクティスを実践しました。
まず、問題を特定した人物から情報やデータを収集し、各 SLI オーナーは不備を特定するか、影響の原因を作った 1 段階上流の SLI オーナーを特定する。
すべての SLI オーナーにそれぞれのケースを提示する機会を十分に与え、問題の特定をコミュニティの作業として行う。
アクション アイテムとプロセス変更を特定したら、それらのアクションを完了するオーナーを指名するか、立候補を募る。
簡単に参照できるように、インシデント ナレッジベースに事後調査を公開および保存する。このプロセスにより、将来インシデントが発生しても、SRE は継続的な改善を実現できる。
継続的な改善
過失を責めない事後調査に必要な、透明性の高い率直かつ直接的なフィードバックの文化を促進するには、経営幹部からの支持のもと、インシデント責任者に議論や成果を全体的に取り仕切る権限を与え、繰り返し取り組みを行う必要があることがほとんどです。事後調査を成功させ、そこで決定したアクション アイテムを完了したら、SRE のパフォーマンス目標評価において、成果として認められ、考慮される必要があります。Google の SRE ブックで説明されているように、効果的な事後調査の記述を、経営陣の認知と参加を得た、報酬と称賛に値する作業とすることが推奨されます。経営陣から全面的な賛同を得られていない場合、企業文化を変革する途中の段階で効果的な事後調査を行ううえで、ここが最も達成の難しい部分となるでしょう。
しかし、そうするだけの価値は十分にあります。このプロセスは、当社が最終的に MTTR を 2019 年の 2 時間からわずか 17 分に減少し、改善させることができた主たる要因です。
当社の SRE インシデント報告プロセスにより、企業としての問題解決への取り組み方も大きく変化しました。アラートから問題解決、過失を責めない事後調査までのワークフローを合理化したことで、MTTR を 82 パーセント、MTTA を 97 パーセント削減できました。最も重要な点は、チームがあらゆるインシデントから教訓を学んでいること、またその結果エンジニアとして成長し続けていることです。クラウドにおける SRE のベスト プラクティスの実践について詳しくは、Google Cloud の SRE のウェブサイトをご覧ください。
謝辞
本ブログ投稿に協力してくれた Lowe’s の Rahul Mohan Kola Kandy、Vivek Balivada、そしてデジタル SRE チームに感謝します。
-Lowe’s Companies, Inc. デジタル SRE 担当リード ソフトウェア エンジニア Shyam Palani 氏
-Lowe’s Companies, Inc. デジタル SRE 担当リード ソフトウェア エンジニア Nishanth Prasad 氏
