Loon での事後検証: 迅速な開発のための指針

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

Google SRE 出身者によって設立された Loon のプロダクション エンジニアリング / SRE チームが、過失を責めない事後検証の文化を導入したことは自然な流れでした。これは、インシデントに対応するための Loon のアプローチの重要な特長となりました。過失を責めない事後検証は、20 世紀半ばに航空宇宙分野での手法として始まったこともあり、これがめぐりめぐって、最先端の航空宇宙分野の仕事と通信プラットフォームや世界初の成層圏一時空間ソフトウェア定義ネットワークの開発を融合させた企業で用いられるようになったのは、非常に理にかなっていました。事後検証の実施は、航空電子工学や製造から航空業務、ソフトウェア プラットフォーム、ネットワーク サービスまで、Loon のチーム全体の標準化の要因となりました。このブログ投稿では、Loon が統一性に欠けていたアプローチから事後検証へと移行することで、最終的にこの手法をどのように組織全体で標準化し、共有するまでになったかをご紹介します。この転換により、同社は 2020 年に研究開発から商用サービスに移行できました。

背景

事後検証

多くの業界が事後検証を採用しています。特に、ミスが致命的であったり、非常に大きなコストが発生するリスクの高い分野では、事後検証は一般的になっています。また、誤ったプロセスや仮定が高額なプロジェクト開発費用を発生させる可能性があり、同じ失敗を繰り返さないことが優先される業界やプロジェクトでも、事後検証は普及しています。個々の業界や組織では、事後検証の導入やチーム間での共有を容易にするために、独自の事後検証の基準やテンプレートを開発する例も多く見られます。

過失を責めない事後検証は、20 世紀半ばに医療や航空宇宙産業で始まったと考えられています。これらの業界では失敗がもたらすコストが非常に高いため、失敗をオープンに話し合うことで得られる透明性と継続的な改善の文化を構築する必要がありました。SRE ブックで説明されているように、過失を責めない事後検証は、「すべての「ミス」をシステムを強化する機会と捉える環境」への鍵となります。

事後検証の目的は、インシデントやイベントを記録することで、影響を受けたチームのみならず、組織全体でその教訓を生かすことにあります。事後検証には通常、事象のタイムライン、実施したソリューション、インシデントの影響、根本原因の調査、再発防止のための変更やフォローアップなどが含まれます。教訓を生かすには、SRE の事後検証で、維持、拡張していくべき成功点を確認するとともに、変更すべきである失敗点も明らかにしなければなりません。このように、事後検証のアクション アイテムは、同じ失敗を繰り返さないために作業の優先順位を決める鍵となります。

Loon

Loon は、成層圏の気球を介してインターネット接続を提供することで、サービスがない、または十分なサービスを受けられない世界中の人々にインターネット アクセスを提供することを目的としていました。これら高高度の「空飛ぶ基地局」は、地上タワーよりもはるかに広範囲をカバーでき、また高価な陸上輸送や設置を必要とせずに地球上の最辺境地域にデプロイ、再配置することが可能です。Loon はこのような試みを行った最初の企業として、数百日間空中に留まるように設計された超高圧気球、風に依存する操縦、絶えず移動するノードからなるソフトウェア定義のネットワーク、地表から 20 キロメートル上空の極端な温度や天候など、複雑で難易度が高く、斬新なシステムをいくつも扱ってきました。

Prod チーム

Loon の初期のハイリスクなミッションは、航空電子工学的なものでした。ネットワークのペイロードを搭載した気球を、ターゲットとする地域に到達させ、サービスを提供するだけの航行時間を確保できるかという課題がありました。そのため、Loon 社内での初期の失敗レポート（当時は公式に「事後検証」とは呼ばれていませんでした）は、ほとんどが気球の製造や飛行に関するもので、航空電子工学、信頼性エンジニアリング、飛行安全性の分野におけるチームメンバーの経験を役立てていました。Loon のシステムが進化し、成熟するにつれ、運用面での信頼性も求められるようになります。Google の「ムーンショット ファクトリー」と呼ばれるインキュベーター X での純粋な研究開発プロジェクトから、商業目的の会社になる直前に、Loon は社内で「Prod チーム」と呼ばれるサイト信頼性エンジニアリング（SRE）チームの構築を開始しました。

ユーザーに効率的にインターネット接続を提供するために、Loon はネットワーク サービスの障害をハードウェアの障害と同じように厳密に解決する必要がありました。Prod チームは、ネットワークの信頼性を向上させるために、さまざまな取り組みを率先して行うことになります。Prod チームには、主に次の 3 つの目標がありました。

• 航空業界の高い安全基準を満たすために、フリートの自動化システム、管理システム、セーフティクリティカル システムの構築と運用を確実に行う。

• 通信サービスの統合をエンドツーエンドでリードする（LTE など）。

• 信頼性の高い商用サービス（Loon Library）を実世界で展開し、提供するというミッションを持つ。  

Loon における事後検証

初期

事後検証は、Prod チーム（SRE）の目標を達成するための一つのツールでした。Prod チームは、EPC（Evolved Packet Core）を開発しているチーム、通信事業者のパートナー、エッジ ネットワーク接続を処理するチームなど、Loon サービスにつながりのあるインフラストラクチャ サポートチームの SRE と頻繁にやり取りしました。事後検証はこれらすべてのチームでインシデント情報を共有するための共通のツールであり、上流の問題がお客様に影響を与える場合には、複数の会社にまたがることもありました。

Loon の事後検証には次のような目標がありました。

• インシデントに関連するイベント、アクション、対処方法を記録し、文書化する。

• 問題を修正するためのフィードバック ループを確立する。

• 安全措置やアラートを改善する場所を示す。

• チーム間のサイロを解消し、部門の枠を超えた知識の共有を促進し、開発を加速する。

• 長期にわたるマクロ的なテーマや盲点を特定する。

航空宇宙とハイテクの組み合わせにより、事後検証を実施する上で 2 つの強力な手法がもたらされました。しかし同時に、これらの境界を越えた問題や、システムのどこに障害があるのかが明確でない場合に、どのように問題を共有し、調査し、フォローアップするかという課題も生じました。

Loon では、ハードウェア、ソフトウェア、オペレーションの各組織のチームが、それぞれの分野でインシデント対応の標準的な手法になっていた事後検証を行いました。打ち上げられた気球の日々の操縦を行うフライト オペレーション チームは、飛行中の問題をトラッキング システムで把握していました。トラッキング システムは、問題の根本原因を特定して解決する異常解決システムの一環として考案されたものです。異常解決システムを補完するために、フライト オペレーション チームは、さらなる調査が必要なインシデントに対して、SRE ソフトウェア チームの事後検証の形式を取り入れました。たとえば、暴風雨を回避できなかった場合、インシデントにつながったシミュレーション（予想）飛行経路からの逸脱、インシデントを直接または間接的に引き起こしたフライト オペレーターの行動などです。ほとんどのインシデントが複数のチームにまたがっていましたが（例: フライト オペレーターが送信した誤ったコマンドを自動化でキャッチできず、ハードウェアの故障につながった）、チーム間で一貫した事後検証の形式を使用することで、共同作業が簡単になりました。

また、フライト システムやフライト プロセスに関する安全性に焦点を当てた航空・システム安全チームは、独自の事後検証の慣例とベスト プラクティスを導入しました。チームのモットーである「安全性を確保する」は、安全に関するパフォーマンスを継続的に改善し、会社全体でポジティブな安全文化を構築するというコミットメントをもたらしました。これは Loon の文化の強みの一つでした。「あらゆる場所で人々をつなぐ」という大胆なビジョンだけでなく、それを安全かつ効果的に行うために、すべての部門が結束しました。しかし、事後検証の業界標準や、問題の種類ごとの対処方法がチームによって異なるため、プロセスには一部ばらつきがありました。Loon は、チーム間、組織間、社内で事後検証を共有することを積極的に奨励し、誰もがインシデントに対するフィードバックや分析情報を提供できるようにしました。このようにして、Loon では全員が事後検証に貢献し、インシデントがどのように処理されたかを確認し、Loon が取り組んでいる課題の広がりを認識できました。

課題

事後検証は重要な手法であることは誰もが認めていたものの、動きの速いスタートアップの文化では、アクション アイテムを包括的にフォローすることは困難でした。これは、同じような環境にいるデベロッパーにとっては周知の事実でしょう。投資を必要とするプラットフォームやサービスが急速に変化したり、置き換えられたりするなかで、同じ失敗を繰り返さないということのためにリソースを費やすことは困難です。理想的には、複数の世代のプラットフォームに適用可能なベスト プラクティスや教訓に焦点を当てた事後検証を優先すべきですが、インシデント発生の時点でそれらを特定するのは容易ではありません。

会社の規模はそれほど大きくありませんでしたが、Loon のプラットフォームの新規性と業務の相互接続性のために、どのチームが事後検証の実施と根本原因の調査を担当するかを決定するのは困難でした。たとえば、地上での 20 分間のサービス障害は、気球からバックホール ネットワークへの接続性の喪失、ペイロードのアンテナのポイント設定のエラー、バッテリー残量の不足、気球を一時的に圏外に吹き流す風などが原因で発生します。実際の原因は非常にあいまいであり、複数のサブシステム間の相互作用に起因することも多くあります。つまり、どのチームが事後検証と調査を開始し、欠陥のあるシステムやプロセスを所有している可能性が高いと思われるチームにどの時点で事後検証を引き渡すべきかという、卵が先か鶏が先かという問題があったのです。すべてのチームに事後検証の文化があるわけではないので、根本原因が発生したシステムによっては、プロセスが停滞することもありました。こうした理由から、Loon の Prod チーム / SRE は、全社的に過失を責めない事後検証の文化の必要性を訴えました。

Loon が事後検証を使用する方法の大部分は、特にソフトウェア開発と Prod チームにおいて、SRE の業界基準に沿ったものでした。しかし Loon の初期には、サービスレベル目標または契約（SLO/A）がありませんでした。Loon は研究開発プロジェクトだったため、「サービスの停止」ではなく、打ち上げ後にテスト ネットワークが起動に失敗したり、パフォーマンスがチームの予測を満たさなかったりしたときに事後検証を報告しました。その後、ペルーやケニアの災害救援地域で Loon が商用サービスを提供した際には、SLA を満たせなかったために事後検証が必要となったユーザー向けのインシデントの種類を、Prod チームがより明確に特定できました。

Loon の事後検証プロセスの改善と標準化

Loon を研究開発モデルから商用化に必要な信頼性と安全性のモデルに移行させるには、単に事後検証を行うだけでは不十分でした。事後検証をオープンに、そして Loon 全体で幅広く共有することは、継続的な改善と根本的な原因に対処する文化を構築するうえで非常に重要でした。

インシデントに対するチーム間の意識を高めるため、2019 年には事後検証作業グループを立ち上げました。作業グループの目標は、社内全体から寄せられた最近の事後検証について読み、話し合うだけでなく、事後検証を実施しやすくすること、事後検証を実施する慣行を促進させること、チーム間での共有を増やすこと、失敗のパターンを学ぶためにそれらのインシデントの結果を話し合うことでした。グループを作成した目的は、「Loon で事後検証の文化を育み、慎重なリスクの取り方を奨励し、失敗を活かし、時間の経過とともに改善をサポートする仕組みを提供する」ことでした。事後検証の量は、数週間から数か月の間で増減することもありますが、複数年の商用サービスでは、複数のチームが協力して対処すべきマクロ的な傾向を把握できると期待しました。

事後検証の作業グループに加えて、事後検証のメーリング リストとすべての事後検証の作業のリポジトリを作成し、過失を責めない事後検証についての「ランチ & トレーニング」を実施しました（以下のサンプル スライドを参照）。Prod チームや他のいくつかのチームのミーティングでは、社内全体で関心のある事後検証を審査するという不変のアジェンダがありました。また、半年に一度、Loon の最近の「ベスト・オブ」インシデント（最も興味深いか、学びの多いサービス停止）を発表するメールを送信しました。

標準化された事後検証のテンプレートがあれば、それを採用して商用サービスのフィールド テストの記録に再利用できます。タイムラインとインシデントの記録、問題の根本原因を特定するプロセスとスペースの定義、測定値と指標の記録、アクション アイテムの追跡のための仕組みの提供によって、将来のタスクに向けた事後検証の活用が可能になりました。

Loon がペルーやケニアなどで商用トライアルを開始したときには、何度もフィールド テストを行いました。これらのテストでは、Loon と通信事業者のエンジニアが遠隔地に赴き、地上での LTE シグナルの強度を測定しました。Prod チームは積極的に事後検証テンプレートを活用して、フィールド テストの記録を残しました。それが、テストイベントのログ、期待通りの結果とそうでない結果、そしてこれらの失敗についてのさらなる調査との関連付けを記録するうえで有用な形式となりました。変化の激しい動作環境における最先端のプロジェクトで、事後検証テンプレートをデフォルトのテスト テンプレートとして使用することで、常に迅速なイテレーションと改善が行われていることを確認できました。これらのトライアルは、COVID-19（新型コロナウイルス感染症）とそれに伴う在宅勤務への移行という突然わきおこった状況の中で、2020 年の初めから半ばにかけて行われました。Loon の事後検証の核となる構造化されたコミュニケーションは、対面式の調整室から WFH に移行する際に特に役立ちました。

Loon が事後検証の標準化から学んだこと

事後検証には大きな効果があるため、さまざまな業界で幅広く利用されています。Loon では、動きの速いスタートアップや研究開発プロジェクトであっても、透明性が高く、過失を責めない事後検証の文化に早期に投資すべきだと考えました。その文化には、事後検証を報告するための明確なプロセス、事後検証を実施するタイミングについての明確なガイドライン、アクション アイテムのフォローアップに対するスタッフのコミットメントが含まれていなければなりません。

事後検証とサービス停止のメタレビューではいくつかの傾向が明らかになりました。

さまざまな事後検証で観察された多くの障害点は、Loon のシステムの複雑さと、それをサポートするインフラストラクチャの複雑さの両方を示していました。事後検証は、ハードウェアの故障や衛星ネットワークの停止と同様に、テストの欠陥やプロセスの脆弱性を発見するのにも適しています。このような複雑な状況は、多くのスタートアップ企業ではよく起きることです。事後検証は、安全に変更を行うことと、迅速に動いて多くの新しいことを試すこととの間で、トレードオフを見いだすのに役立ちます。

Loon の運営にはまだスーパーヒーローに頼る文化がありました。さまざまな問題を解決するために、少人数のエキスパートがシステムの修正のために何度も呼ばれました。これはスタートアップ企業にはよくあることで、決して否定的な意味ではありませんが、Prod チーム / SRE の多くが当たり前に考えていたシステムの成熟度とは明らかに異なっていました。このようなパターンが特定された時点で、24 時間 365 日対応のオンコール ローテーション体制でスタッフを配置し、プログラム マネージャーが本番環境のリスクを回避するための目的プロセスを推進して補完することが、商用サービスの計画になりました。

事後検証では、「この分野では他にどんな問題が出てくる可能性があるか」といった質問をする場が設けられており、すでに確認した特定の問題ではなく、より広いケースの問題を解決するよう促されました。また、開発のスピードを優先して問題を放置したり、「プロトタイプを重視したから」という理由で問題を片付けたりすることもなくなりました。

ヒントと要点

事後検証を標準化するための Loon の具体的なプロセスは、一企業の事例ではありますが、ほとんどの組織で適用できるヒントや要点があります。

ヒント 1: 事後検証の文化の導入には全員の参加が必要

事後検証を報告するという取り組みは、多くの場合ソフトウェア チームから始まりますが、この手法をすべてのチームで導入するには次の方法を試すことをおすすめします。

• 事後検証がすべての人にとってメリットになる仕組みと理由を説明する。

• 事後検証の作業グループを作る。

• さまざまなチームの代表者を事後検証の作業グループに招待する。参加者により、それぞれのチームによって何が最善かについての洞察が提示されます。

• 事後検証の作業グループに事後検証の実施を任せないこと。このアプローチではそれ以上の広がりが見込めません。特に新しいチームがこの手法を導入している途中では、事後検証のレビューやコンサルティングもチームの職務に含まれることになります。

ヒント 2: 簡易化された事後検証プロセスを定義する

特に導入中には、チームには事後検証を作成する負担よりも、事後検証のメリットを認識してもらわなければなりません。最低限の要件を備えた事後検証テンプレートを作成すると便利です。

ヒント 3: 事後検証のオーナーを明確に定義する

誰がいつ事後検証を作成するべきでしょうか？オンコール ローテーションを採用しているソフトウェア チームの場合、答えは明確です。インシデント発生時にオンコールだった人がオーナーとなり、サービスの中断により SLO に違反した際に事後検証を作成します。ただし、サービスに SLO がない場合や、チームにオンコール ローテーションがない場合には、定義された基準が必要です。その停止が複数のシステムやチームを必要とするものであればボーナス ポイントを与えます。この分野では次のようなことが役立ちます。

• 各チームの視点、およびチーム間のやり取りでの視点からこれらのトピックを振り返る。

• チームごとに、どのタイプのインシデントが事後検証のきっかけになるべきか定義する。

• チーム内で誰がどの事後検証のオーナーになるのかを定義する。頻繁に同じ人に負担をかけることは避け、ローテーションを組むようにします。

ヒント 4: 過失を責めない事後検証を奨励し、事後検証することに誇りを持ってもらう

過失を責めない事後検証の文化を促進するには、以下のアクティビティが推奨されます。

• 一定期間に行われた最高の事後検証についての報告書を作成し、広く配布する。

• 事後検証の実施方法についてのトレーニングを実施する。

• マネージャーをトレーニングし、チームで事後検証を優先化することを奨励する。

結論

Loon がシャットダウンしたとき、これらのすべてのポイントに対処する準備はできていませんでした。「この事後検証プロセスが失敗を解決する」ことを教えられる機会はありません。それは事後検証のプロセスではないからです。しかし、事後検証を行うことで、繰り返し同じ失敗に対処する必要がなくなったとはいえ、最初の事後検証で出てきたアクション アイテムを十分に優先させなかったことでインシデントを繰り返してしまったこともありました。とはいえ Loon の事後検証についての「事後検証」といえるこの投稿からも、一般的な教訓（事後検証は、幅広く受け入れられ、その仕組みに則って進められるならば有効に機能する）を得ていただけるのではないかと思っています。

- Loon サイト信頼性エンジニア Danielle van Dyke

- Google Cloud サイト信頼性エンジニア Giselle Font