知られていない未知を発見する

Metaの製品エコシステムは、ソーシャルなつながりのため、あるいはビジネスエンゲージメントのために、毎日何十億ものユーザーに利用されています。それら何十億ものユーザーは、Meta製品の新機能や改善を絶えず求めており、そのペースはますます加速しています。そのような大きなユーザーベースの期待に応えるため、Metaは毎日何千というコード変更を配信しています。

そのような多数の製品改善を絶えずリリースし続けると、アプリの健全性が後退してしまい、ユーザーエクスペリエンスが低下する可能性があります。不具合を含んだ製品変更がリリースされることがないように、Metaは予防ツールを洗練された仕方で何層にも重ねて使用しています。そのような予防ツールにより、さまざまな製品シグナルをモニタリングし、アプリがリリースされる前に後退現象を検出することができます。そのようなシグナルは、パフォーマンス、信頼性(機能とシステム)、効率という3つの分野に分けられます。それらをまとめて製品の「PRE」と呼びます。予防措置は、開発者がコードをオーサリングしている間に収集される、さまざまな可観測性や分析トレースから始まります。さらに、可観測性とモニタリングツールにより、本番前環境の製品の社内利用状況のデータが収集されます。そのような本番前環境では、手動と自動の両方の品質保証ツールにより製品がテストされます。

コード変更を本番環境にリリースする前にその品質を評価してユーザーへの影響を回避するメカニズムは存在するものの、ユーザーに影響する変更が本番状態に入ってしまい、作業をやり直してもう一度リリースする、ということは生じ得ます。大勢の人に影響する問題が発生する可能性をできるだけ低くするため、Metaはさまざまなメカニズムを使って、変更の差分のみを一般にリリースしています。

ユーザーが予期している機能から逸脱すると、Metaはそれを後退として定義します。Metaが使用している「シグナル」という語は、何かが期待どおりに動作しないというユーザーからの報告があったことを示すものです。データインサイトやインストルメント化コードを通じて可能な限り早くシステマティックに後退シグナルを収集し、修正をデプロイすることによりユーザーへの影響を抑えるようにしています。ツールから強力なシグナルが得られない場合には、利用者からの報告を後退発生のシグナルとして利用します。それらの報告はさまざまなメカニズムによって収集されます。例えば、アプリの使用中に問題が発生した時点で、スマートフォンを振ってその問題を報告するユーザーがいます。

お客様のニーズに確実にかつできるだけ早く(時にはその日のうちに)応えるため、Metaは信頼性関連のプログラムやシステムに多大の投資をして、大幅に応答性を向上させるようにしてきました。

シグナル源は、一般ユーザー(個人、会社、グループなど)や社内ユーザーです。社内ユーザーからのシグナルを精査するなら、望ましくない変更内容が本番環境に入ってしまうのを防ぐのに役立ちます。シグナルは集計されることに注意してください。例えば、シグナルには100万ユーザーあたりの不具合の数が含まれます。シグナルは、自動テストツールやテストシナリオ、開発ツール(実行時に問題を引き起こす可能性のある変更があれば、Metaから開発者に警告します)、システムログ、その他のソースからも生成されます。また、これらのシグナルを利用してピンポイントで原因や適切な修正方法をすばやく特定するツールもあります。

後退状況が特定されたら、関係するエンジニアを見つけ、修正を適用してそれをリリースするようにします。後退の複雑度によっては、適切なエンジニアをピンポイントで特定するために複数の方式を採用しています。その1つの方式として、機械学習でMetaが蓄えたノウハウを活用しています。機械学習の性質上、新しい機能をリリースし続けて絶え間ない変更についていくというモデルを維持する限り、これは継続的なプロセスとなります。

今やその進歩は大詰めを迎えています。後退状況を検出することから始まり、それを軽減・防止し、さらには持続的に封じ込めることまでできるようになりました。その過程の中で、応答性、投資収益率、効率をできるだけ高めるようにしています。

次のセクションでは、後退状況が発生しているという事実をどう確認するのか、またそれが分かったときにどう対応するのかについてさらに詳しく論じます。

未知を既知に変換して定量化する

ここでの未知という語は、ユーザーまたはシステムが経験している不具合のことを指します。まずは、次のようなさまざまなソースから不具合の可能性について知ることになります。

• アプリとそれに含まれる特定の製品が正しく動作しているかどうかの総合テスト。
• 不具合検出のためにテストしている社内ユーザー。専用テストチーム、またはMetaの中のもっと広範囲なユーザーベースの場合があります。
• 問題が発生し、アプリの問題報告ダイアログを使って報告する社外ユーザー。

これらの不具合は、実際にユーザーが経験するインシデントとしてフラグが立てられるまでは未知のものです。そのような不具合レポートの数が特定のしきい値に達すると、それらは真陽性と判断され、後退イベントとなります。コードの変更により新たな不具合が発生したため、早急に対処する必要があります。報告には、大きく分けて次の2つのタイプがあります。

• 「知っている未知」 - インストルメント化コードによって後退が検出され、報告された場合。このシグナル生成のためのさまざまなツールがあります
• 「知らない未知」 - 後退が社内では検出されず、ユーザーが実際に後退を報告してきた場合

後退状況はいくつかのカテゴリに分類されます。コードの不具合を示すものなのか、スパムのようなものか、それともほかのコンテンツポリシー違反か、といった具合です。ここで主に考慮するのは最初のもの、コードに関連したユーザーエクスペリエンスの問題について扱います。ユーザーが何千件もの問題を報告してきたら、どう対応するのでしょうか。

シグナルとインサイトの生成

大量の報告を管理するために、問題をMetaが認識できるようにフラグを立てる具体的なシグナルを生成します。最初のタイプのシグナルは、適切に調整されたしきい値を超えることで、本当にインシデントであること、または後退状況が発生していることを示すものです。後退のタイプによっては多数のイベントが発生している可能性があることに注意してください。例えば、共通のコードベースが原因で、1つの後退が複数の製品に影響しているかもしれません。そのような共通性がないか調べ、リソースを最適に揃えるために単一のインシデントとして扱います。下のグラフの例から、傾向線からの逸脱が後退を示していることを視覚的に確認できます。

次に、シグナルをさらに収集します。その一部は、今直面している後退のタイプを示すものです。そのようなシグナルから、当該の後退状況に付随する症状についてインサイトが得られます。それらのシグナルは、特定のMeta製品に合わせて調整された機械学習アルゴリズムから生成されます。それらのアルゴリズムによって、利用者からの報告が分析され、後退状況の原因が特定されます。そして、どのエンジニアリングチームがコード修正やほかの対策をデプロイして問題にあたるのがベストなのか判断されます。

さらに、収集されたログデータに基づいて生成されるシグナルもたくさんあります。それらの診断ログには、(ユーザーの同意のもとに)収集したクライアントサイドやサーバーサイドのログがあり、これらも問題を特定するのに役立ちます。アプリに組み込まれている同意フローにより、ユーザーの許可に基づいてこのタイプのデータを収集できるかどうかが判断されます。また、適用される規制に準拠するために、この収集したデータの寿命も考慮に入れます。

複数シグナルを組み合わせることにより、後退状況を突きとめ、それを製品チームに割り当てることができます。そうすれば、短期間で問題を軽減し、期待どおりのユーザーエクスペリエンスに戻すことができます。

インサイトは、集計データによる発見からも得られます。共通の根本原因を検出し、後退状況の再発防止のために変更が必要かどうか見極めるため、集計データを調べます。そのようにすることは、ユーザーエクスペリエンスの問題に対処するための堅実なアプローチの重要な面であり、時間が経過するにつれて後退状況が表面化する範囲を最小限に抑えるのに役立ちます。

Metaのモバイルアプリには、ユーザーが問題を報告するためのナビゲーションパスが含まれているだけでなく、デバイスを振ることによって問題発生について伝達する機能も含まれています。そのようにして、コンテキスト内のテレメトリを収集できます。そのテレメトリ情報は、アプリから来るBlack Boxシグナルを通じてさらに肉付けされます。Black Boxはフライトレコーダーのようなものであり、不具合報告時にアプリがどうなっていたかを示す特定のログを(ユーザーの同意があれば)自動的にキャプチャします。それらは、問題についてより良い診断を下すのに役立ちます。

このテレメトリはすべて一連のタイムラインビューに取り込まれ、そこからエンジニアリングチームは問題の原因を突きとめることができます。アプリのリリース速度が速く、サーバーサイドのアプリコンポーネントの変更も多いため、もしこの機能がなかったら、問題をピンポイントで特定するのは難しくなるでしょう。このテレメトリを長期にわたって収集していけば、後退のパターンを検出して将来の再発を防ぐことができます。

より狭い製品サーフェスにスケールする

シグナルの精度向上に努めた結果、より多くの後退サーフェスに対処することができるようになっています。その中には、以前には検出できないで終わっていたかもしれないものも含まれています。サーフェスとは、ニュースフィードやリールなど、製品内の特定のオファリングを表しています。これは1つの課題です。すでに多くの細かい機能を持つ製品に一定の頻度で新しい機能が追加されていくからです。それで、後退サーフェスは単に大きいだけでなく、時間とともにさらに大きくなっていきます。そのため、Metaの防御戦略と攻撃戦略も継続的に調整していく必要があります。

スケールするためには、次の条件が満たされていなければなりません。

1. Metaは既存の製品サーフェスの正確な範囲を特定し、適切に分類しなければならない
2. Metaは既存の製品の後退サーフェスを削減しなければならない(読み取り: 予防)
3. Metaは新しい製品サーフェスに達するようにアルゴリズムを拡張しなければならない

上記の条件が満たされないと、サイズ、複雑度、不正確さのゆえに、ふくれ上がるシステムを管理できなくなるというリスクが生じます。それで、日常業務を効率的に遂行しながら、バランスを保って管理していく必要があります。

不具合の先を見る

後退サーフェスを(警戒を緩めることなく)削減していくにつれて、それ以外の重要な分野、予防や使い勝手の向上に、より多くの注意を向けることができるようになります。

予防には次のことが関係します。

1. 過去の後退からどんな教訓を学べるか？
2. それらの後退の再発を防ぐため、どんな防御策を実装するか？
3. 今後も後退サーフェスが確実に削減し続けるようにするためには、どうしたらよいか？

前述のように、集計した過去の後退のデータから教訓を引き出すことができます。そこで得た教訓を次のことにつなげます。

1. 本番前環境の段階で今後問題となりそうなコードにマーカーを付けることにより、望ましくない変更が本番状態に入ってしまうのを防ぐ
2. そのような後退状況を検出するためのテスト範囲をさまざまなレベルで広げる
3. 製品自体を変更して問題に対処する

予防策を講じれば、開発ライフサイクルの中で残っている後退をより早い段階で処理することができ、結果的にコストを削減できます。そのためには、開発プロセスの初期段階で十分なシグナルを得るようにします。つまり、コードオーサリングのときから始めて、本番前のリリースサイクルに乗せます。それにより、ユーザーエクスペリエンスが改善されるだけでなく、開発コストも削減され、リソースを新たな製品開発に振り向けるのに役立ちます。

後退をもっと効率よく処理するためのMetaの能力を改善するなら、ユーザーが困っていることや使い勝手の問題にもっと力を入れることができます。単に問題を修正するのではなく製品を改善することにつながるので、これらはより価値の高い関心事です。時間の経過とともに、使い勝手の問題の割合が後退と比べて高くなっていき、使い勝手の問題と後退の合計数は減っていくはずです。

最終的には、ユーザーエクスペリエンスが継続的に向上し、それと共に機能性も使い勝手も向上していくのです。

この記事は、Metaのテクニカルプログラムマネージャであるビジャン・マージャンと共同で執筆したものです。