金曜日の午後、JavaScriptの更新が正常に実行されます。アプリが起動し、認証が正常で、クラッシュカウンタも注目に値しないままです。チェックアウトが開始する際に、デバイスの一部でエラーが発生し、App StoreとPlay Consoleのダッシュボードはロールバックの決定を確実にするために遅れています。
そのインシデントは、 アプリケーション健康チェック を
ダッシュボードのレビュー
- 金曜日の午後インシデントがこのプレイブックを始動させる
- 目次
- 健康基準を定義する
- アプリの健康チェックとCIチェック
- ストアとデバイスの間の盲点にあるアップデート、アップデーター
- JavaScriptアプリのセキュリティ、パーミッション、テレメトリの清掃
- 健康信号がトリガーされたときの回復とロールバック
金曜日の午後、インシデントがこのプレイブックを始める
最初のレポートは、一般的には「チェックアウトが一部のユーザーで機能しない」というものです。サポートはスクリーンショットが数枚あり、エンジニアは最近のバンドルを持っています。ストアのコンソールでは明らかなレグレッションはありません。チームはログを比較し、最近のバンドルを使用して一台のデバイスでフローを再現し、更新状態、バックエンドのレスポンスの形状、古いネイティブシェルの組み合わせに依存することがわかりました。
これはデバッグセッションではありません。リリースシステムの失敗です。
大規模なアプリストアのダッシュボードは、 24時間以内にほとんどのKPIで遅れ、クラッシュとANRレートの場合は72時間以内に遅れます、ストアのテレメトリの遅延参照に従ってください。 そのダッシュボードは、傾向分析に役立ちますが、ライブインシデント中の唯一のロールバックトリガーとしては遅すぎます。
実践的なルール: ストアコンソールは、報告遅延後に何が起こったかを教えてくれます。 アップデータとランタイムのテレメトリは、現在のリリースが何をしているかを教えてくれます。
定期的なヘルスチェックは、チームに3つの層の証拠を提供します:
- ランタイムの品質: クラッシュ、ANR、起動動作、画面レンダリング、エラー、リソースの圧力。
- ユーザーの結果: ログインの完了、チェックアウトの成功、支払い確認、ユーザーが成功または失敗と認識するジャーニー。
- リリースの配信: 採用、失敗したインストール、ブロックされたデバイス、チャンネル動作、ロールバック状態。
各層には対応するオペレーショナルレバーが必要です。 クラッシュのレグレッションは、ロールアウトを停止したり、JavaScriptのバンドルをリバートしたりする必要があります。 バックエンドの依存関係が失敗した場合は、サービスを修復する必要がありますが、アプリのロールバックではありません。 更新パスの破損は、チャンネル制御とデバイスレベルの調査が必要です。
実践的な対応は、タイムラインから始まるべきです。 バンドルの公開日、受信したチャンネル、最初の失敗したジャーニーの出現日、影響を受けたバージョンを記録してください。 次に、 モバイルチーム向けのインシデント対応ガイド オーナーを割り当て、証拠を保存し、安全なアクションとしてチャンネル停止、ロールバック、またはネイティブリリースを決定する
このプロセスの目的は単純です: 静的エラーを減らし、悪い信号から安全なアクションまでの距離を短縮する. その結果に基づいて、残りのヘルスチェックを設計する
ユーザーの痛みを予測するためのヘルス基準を定義する
金曜日のリリースは、ユーザーがログイン、チェックアウト、またはアップデートを受信できない場合でも、グリーンなストアダッシュボードを示すことができます。 そのインシデントの前に、「正常」な状態を定義し、各信号をリリース、CI、またはロールバック決定に結び付ける言葉で表します。 プラットフォームの信頼性が高まるまでの24時間から72時間のブラインドスポットがあるため、ストレージのテレメトリも含め、デバイス側のイベントは、信頼できるプラットフォームレポートが得られる期間をカバーする必要があります。
最初のレベルは、ユーザーが意味のある作業を完了できるかどうかを説明します:
- クラッシュフリーのセッション iOSの場合、99.93%、Androidの場合、99.81% 、ドキュメント, です。 アプリケーションヘルスフレームワークリファレンス. これらの値をレビュー基準として扱ってくださいが、普遍的な保証ではありません。リリース、オペレーティングシステム、デバイスファミリー、ロールアウトコホートでセグメントしてください。リリース固有のドロップは拡張を停止させたり、バンドルをリバートさせたりします。
- ANRの動作。 フリーズしたインターフェイスはログイン、チェックアウト、または支払い確認をブロックすることなくクラッシュを生じさせません。バージョンとフローのグループでANRをグループ化し、WebViewの作業、プラグインの呼び出し、ネイティブブリッジの操作を確認してください。これらの操作がメインスレッドをブロックしている可能性があります。修正はcodeまたはCIにありますが、ロールアウトのレバーは一時停止です。
- 起動と画面の準備。 インタラクティブになるまでの時間を測定してください。プロセスが早く起動するが、最初の有用な画面が空白になっている場合でも、まだ不健康です。CIの基準を設定してリグレッションを検査し、失敗した場合にデバイスのトレースを検査してください。
- 重要なジャーニーの成功。 ログイン、検索、チェックアウト、支払い、同期、ログアウトには明示的な成功イベントが必要です。HTTPレスポンスはユーザーが確認に到達したことを証明するものではありません。ドロップは影響を受けたフローを特定する必要があります。ロールバックを選択する前に誰もがロールバックを選択することなく。
リリースゲートと診断信号を分離してください。
リリースゲート 通常はクラッシュフリーセッション、ANR、起動、認証、最高価値ユーザージャーニーを含みます。 診断信号 メモリ圧力、バッテリー影響、ストレージ増加、ネットワーク遅延、HTTPエラークラス、WebViewレンダリングを含みます。 これらは、失敗の説明と修復ガイドを提供しますが、すべてのデプロイを自動的にブロックすることはありません。
各基準を4つのフィールドで書きます。
| フィールド | 例 |
|---|---|
| 信号 | チェックアウト完了 |
| セグメント | リリース、プラットフォーム、地域、デバイスファミリー |
| レビュー規則 | 前回の安定コホートと比較 |
| アクション | ロールアウトを一時停止、ログを確認、またはバンドルを元に戻す |
この機能を使用 アプリの健康状態を監視するためのガイド まず、各信号を個人が担当するように割り当て、結果を変えるためのレバーをドキュメント化し、元の信号を表示する。1つのスコアは、健康な背景アクティビティの背後で、深刻な支払い失敗を隠す可能性がある。
健全なリリースは、安定し、反応し、観察し、ユーザーが価値を置くタスクを完了できる。さらに、オンコールエンジニアが実行できるアクションに接続されている。
実行時間チェックを今週に組み込むことができるもの
アプリの実行場所でユーザーが作業を経験する場所にのみ、チェックを組み込む。Capacitor アプリは、JavaScript の例外、ネイティブのクラッシュ、ブリッジの失敗、ナビゲーションタイミング、そしてジャーニーイベントをキャプチャできる。Electron アプリは、レンダラー プロセスの失敗、メイン プロセスのエラー、プリロードの失敗、ウィンドウのリードイー、そしてリソースの観察を追加できる。
実用的アプリの健康チェックは 安定性とパフォーマンスを一緒に測定する、クラッシュ率、ANR率、起動時間、画面レンダリング時間、エラー率、そしてリソースの利用率を含む。 モバイルパフォーマンスの健康チェックのガイド リリースバージョンとロールアウトコホートによるセグメンテーションも強調している。セグメンテーションがなければ、健全な古いバージョンは、新しいバージョンが失敗していることを隠す可能性がある。
開始は、決定を変える信号から始めましょう。
セッションID、アプリバージョン、ネイティブシェルバージョン、プラットフォーム、デバイスクラス、地域、ロールアウトチャネルを含む、各ヘルスイベントでキャプチャしてください。 それらのフィールドに個人データを入れないようにしてください。 コンテキストは、デバッガーを開く前に「どのユーザーが影響を受けているか」という質問に答えるために、オンコールエンジニアに役立ちます。
各信号に対して、ターゲットとレスポンスを定義してください。
- クラッシュ: クラッシュフリーのセッションをプラットフォームベンチマークと比較してください。 リリース固有の低下は、エンジニアがスタックまたはプラグイン境界を特定するまで、影響を受けるコホートを一時停止させるべきです。
- ANR: イベントをスクリーンとオペレーションでグループ化してください。 ブリッジコール中に繰り返しフリーズが発生する場合、データベースマイグレーション中にフリーズが発生する場合とは異なる対策が必要です。
- 起動時間: 最初のインタラクティブスクリーンが利用可能になるポイントをマークしてください。 低速の結果は、ウェブアセットが大きすぎる、同期初期化、証明書チェック、またはナビゲーション前に実行されるプラグインなど、さまざまな要因によって引き起こされます。
- スクリーンレンダリング: チェックアウト、ログイン、検索、他の高価値スクリーンに発生する開始とリードイベントを発行してください。 リードイベントが欠落している場合、クラッシュレポートが示さない静的な失敗を明らかにすることがよくあります。
- エラー率: エラークラス、ステータスファミリー、オペレーション名を正規化して記録する。トークン、支払い情報、またはフルリクエストボディをログに記録しない。
- リソース利用率: メモリ、ストレージ、バッテリーの挙動、ネットワークエラーをサポートする証拠として監視する。リソースの傾向が失敗した旅やANRと関連している場合に最も重要となる。
以下の表は意図的に保守的である。ベンチマークが提供されている場合は、ベンチマークが含まれる。ベンチマークが提供されていない場合は、安定した基準から選択する。
| シグナル | 単位 | 正常範囲 | なぜ重要か |
|---|---|---|---|
| クラッシュフリー セッション率 | パーセンテージ | 99.93%のiOS、99.81%のAndroidを基準として | 予期せぬ終了セッションを検出する |
| ANR率 | イベントまたはセッション | 安定コホートからリリース固有の不良が見られない | 凍結インターフェイスを特定する |
| 起動時間 | ミリ秒または秒 | 前のリリースに対して安定している | アプリがすぐに利用可能になるかどうかを示す |
| 画面レンダリング時間 | ミリ秒または秒 | 重要な画面に対して安定している | 遅いまたは不完全な旅を明らかにする |
| エラーレート | イベント数/オペレーション | バージョンとオペレーションごとの安定性 | エラーとユーザー作業を関連付ける |
| リソース利用率 | メモリ、ストレージ、バッテリー、ネットワークの測定 | リリースごとの説明が必要ない | フリーズ、エラー、低性能のデバイスの原因を説明する |
アクションをインストルメントするだけでなく、警告をインストルメントする
クラッシュイベントはリリースとロールバックパスにリンクする。チェックアウトの失敗は失敗したステップとレスポンスクラスにリンクする。起動のレグレッションは初期化フェーズに時間を費やした部分にリンクする。
Capacitor チームの場合、JavaScriptとネイティブの境界近くにインストルメントを近づけ、物理デバイスで検証する。Electronの場合、レンダラーとメインプロセスのセパレートコンテキストを収集する。 Capacitor パフォーマンスモニタリング設定 チームは、リリースレベルでの調査に役立つように、信号を接続することができます。
問題をユーザーが行う前に検出するためのヘルスエンドポイントとCIチェック
実行中のプロセスは、適用が準備されていることを証明するものではありません。バックエンドは、データベースプールが枯渇している場合やキャッシュが利用できない場合や、重要な外部サービスがタイムアウトしている場合でもTCP接続を受け付けることができます。
特定の、非認証のリードネスエンドポイントを使用することができます。 /healthzエンドポイントは、重要な依存関係とアプリケーションが正常な場合に200を返し、正常でない場合に503を返すようにする必要があります。 ヘルスエンドポイントの実装ガイドラインに従ってください。ガイドラインでは、チェック時間を500ms以内に保つことを推奨しています。また、データベース、キャッシュ、重要な外部サービスをチェックし、依存関係ごとにタイムアウトを設定することも推奨しています。 応答を有用で境界付きにします問題をユーザーが行う前に検出するためのヘルスエンドポイントとCIチェック 500 ms500ms以内に
応答を有用で境界付きにします
小さく安定したレスポンスの形を返す。全体的なステータスと機械読み取り可能なコンポーネントの状態を含めるが、クレデンシャル、スタックトレース、内部ホスト名、または敏感な構成を暴露しない。必要な依存関係が利用できない場合、リードネスチェックは明確に失敗し、オプションのサービスはアプリがコア機能を提供できる場合に診断用に残るべきである。
ステータスを検証する以外のものもcode:
- レスポンスが期待どおりのフィールドを持つ有効なJSONであることを確認する。
- エンドポイントが意図したバックエンドバージョンに到達することを確認する。
- 関連する地域とネットワークルートからパスをテストする。
- 独立したタイムアウトを設定して、1つの遅い依存関係が全体のプローブを止めることができないようにする。
- インフラがプロセス失敗と依存関係失敗を区別する必要がある場合、ライブネスとリードネスを分離する。
200レスポンスに不正なJSONまたは期限切れの証明書がある場合、ユーザーの視点から見ると健康なアプリではない。
チェックをリリースパス内に置く。
CIでデプロイされたプレビュー環境に対してエンドポイントを実行し、次にアプリが使用するAPIの操作を実行し、最後にエミュレータまたはデバイスファームで小さなセットの重要なUIフローを実行する。環境が生産環境と同じリードネス契約を満たせない場合、ビルドは失敗するべきである。
GitHubアクションズジョブは単純に残ることができる:
- Web bundleとネイティブシェルをビルドする。
- 隔離された環境にデプロイする。
- Poll
/healthzタイムアウトとともに。 - ステータスとレスポンスの形を検証する。
- ログインと収益が高いjourneyの統合テストを実行する。
- すべてのゲートが通過した後のみ、リリースする。
エンドポイントは、データを書き込むことや破壊的なマイグレーションを実行しないようにする。繰り返し実行しやすく、安価で、頻繁に呼び出せるようにする。エンドポイントはリリースゲートであり、2番目のアプリケーションではない。
アップデート、アップデーター、ストアとデバイスの間の盲点
リリースは技術的に正しくても、デバイスが受信、インストール、または状態を報告しない場合に、実行上失敗する可能性がある。アップデータはアプリの健康に含まれるが、配信の詳細ではない。
チェックアウトの検証を変更するJavaScript bundleを考慮する。ストアでインストールされたネイティブシェルは利用可能だが、更新チャネルは新しいWebアセットを一部のデバイスに配信する。成功したデバイスもあるが、ネイティブバージョンが互換性がないため、検証に失敗したりブロックされたりするデバイスもある。ストアのダッシュボードでは、状態の差異をすぐに認識できない。
報告のギャップは重要な問題である。ストアのダッシュボードは、約 24時間でほとんどのKPI、クラッシュとANRレートは72時間、 モバイルリリースの可視性の参考。近リアタイムアップデーターのテレメトリは、デバイスがバンドルを受け取ったか、インストールに失敗したか、ロールバックしたか、チェックインしなかったかを示します。
チャンネルを安全境界として扱う
別々のベータ、ステージング、プロダクションチャンネルを使用し、明確な互換性のルールを指定します。プロダクションロールアウトには、必要なプラグインまたは構成機能が欠けているネイティブシェルを含めるべきではありません。チャンネル、リリース、プラットフォーム、報告されたアプリバージョンごとに採用と失敗を追跡します。
オペレーショナルなレバーは具体的です:
- ガードレール: 不適合のバンドルが非対応のシェルに到達するのを防ぎます。
- アウディエンスロールアウト: コントロールされたコホートから始め、実行時とジャーニー信号が健常な場合に拡大します。
- 差分配信: アップデートの際に変更されたアセットのみを送信することで、更新の作業量とデータの量を削減します。
- ロールバック保護: インストールまたは起動検証が失敗した場合、前のバージョンの知られている良好なバンドルを復元します。
- バージョン比較: 新しいコホートと安定化コントロールグループとの比較で、クラッシュ、起動、WebView、journeyの健康を実行します。
Capgoは、CapacitorとElectronチームが署名されたJavaScript、CSS、設定、資産の更新、ターゲットチャンネル、デバイスごとのログ、採用と失敗のメトリクス、ロールバックコントロールの必要性に応じて、オプションです。 Capacitorのライブアップデートの概要 __CAPGO_KEEP_0__のアップデートモデルと、チームが配信状態をリリース決定と接続する方法について説明しています。
重要な原則は、ベンダーではなく、フィードバックループです。ロールアウトは証拠を生み出し、次のコホートがバンドルを受け取るかどうかを制御する必要があります。
JavaScriptアプリケーションのセキュリティ、パーミッション、テレメトリの清掃
アプリケーションは安定しているように見えますが、パーミッション、更新の信頼、またはテレメトリのリスクを引き受けている可能性があります。CapacitorとElectronのリリースの際には、プラグインと埋め込まれたWebコンテンツを攻撃面の一部として検査する必要があります。
はじめにこれらのチェックを実行してください。
- プラグインの許可リスト: 不要なプラグインを削除し、ネイティブ機能を確認し、連絡先、ファイル、位置、カメラ、マイク、または外部の意図へのアクセスを検証してください。
- デープリンクのレビュー: URLスキームとAndroidのインテントをテストしてください。信頼できないリンクは、特権フローを開くことなく認証を回避することはできません。
- バンドル検証: 更新を適用する前に署名を検証し、不完全または予期せぬパッケージを拒否し、最後の知られている良好なバンドルを回復用に保持してください。
- トークンストレージ: プラットフォームの安全なストレージにクレデンシャルを保持し、JavaScriptにアクセス可能なファイルまたは制限のないローカルストレージにしないでください。
- エレクトロンの境界: メインプロセスに特権APIを保持し、狭いプレロードインターフェイスを公開し、任意のリモートコンテンツがネイティブAPIに到達するのを防ぎましょう。
テレメトリには対応する制御が必要です。イベント名、リリース識別子、オペレーションクラス、エラーカテゴリを記録してください。トークン、支払い情報、ユーザーが入力した全テキスト、正確な位置、または未加工のレスポンスボディを除外することはできません。文書化されたセキュリティレビューが許可する場合のみ。
リリースの不具合を特定するために、運用上の必要性に基づいて保持期間を設定し、ロールごとにアクセスを制限する。プライバシー要件が適用される場合、削除または削除のパスを提供する。ヘルス イベントは、リリースの不具合を分離する必要があるが、ユーザー行動の二次データベースにはならない。
ストアダッシュボードは、すぐに全体像を提供することはできない。アプリストアとプレイコンソールのテレメトリは、24-72時間のレポートギャップを残す可能性があるため、ストア信号をアップデーターの状態、リリース識別子、デバイス側のエラーイベントと組み合わせる。 Google Play Console のレポートドキュメント 結果の遅延を考慮する際の報告コンテキストを説明します。
リメディエーションとロールバック:ヘルス シグナルがトリップしたとき
ヘルス シグナルは、安全なアクションにつながるまで意味がない。インシデントが発生する前に、チームがまだ明確に考えているときに決定treeを書く。
1つのリリースまたはコホートでクラッシュまたはANRの不具合が発生した場合:
- そのチャネルを停止し、影響を受けたバージョンと安定したコホートを比較し、ネイティブシェルが互換性がある場合にバンドルをロールバックする。 ヘルス エンドポイントが503を返した場合:
- アプリのロールアウトを停止し、失敗した重要な依存関係を修正する。サービスを再起動することで助かるかもしれないが、アプリのロールバックを使用してバックエンドのダウンタイムを隠すことはしない。 Google Play Console のレポートドキュメントは、遅延された結果を解釈するために、チームが考慮すべきレポートのコンテキストを説明している。
- 重大なエラーが発生しながら、クラッシュは通常のままです: 影響を受けた機能またはチャネルを無効にし、レスポンスの形状と構成を検査し、修正されたバンドルを配信します。
- 更新のインストールまたは起動の検証が失敗します: 前のバンドルを有効にし、リリースを不健康にし、署名、互換性、またはアセットの完整性を調査します。
- ネイティブの権限またはプラグインの動作が正しくありません: ライブのJavaScriptの更新だけでは十分ではない場合があります。修正がネイティブのcode、マニフェストの変更、特権、または新しい権限の宣言を必要とする場合は、ストアのリリースを準備してください。
The Capacitor live update のロールバック戦略 は、緊急事態の際に発見されるページではなく、ランブックの重要な部分であるべきです。自動保護は、インストールまたは起動の失敗を信頼性の高い方法で検出できるアップデーターが存在する場合に適切です。ユーザーが起動を完了できるが重要なジャーニーで失敗する場合には、フルなインシデントが必要です。
このプロセスの正式化への商業的圧力は明らかです。モバイルアプリケーションテストサービス市場は2025年で 7.70億ドルに達する見込みです と予測される 2031年までに$19.84億に達する見通し17.09%のCAGR 、Apple App Storeの却下率は2024年に約24.9%に報告 、市場とストアのレビューデータによると。 これらの数字は、品質チェックを任意のものとして扱うコストを強調するものであり、エンジニアリングの判断を置き換えるものではない。
各インシデントの後、タイムラインを保存し、最初の行動可能なシグナルを特定し、どのレバーが機能したかを記録し、欠落したチェックをリリースゲートに変換する。 成熟したアプリケーションヘルスチェックは、単に失敗を報告するのではなく、次の失敗を検出、抑制、逆転させるのに役立つ。
CapgoはCapacitorとElectronチームが署名したライブアップデート、ターゲットチャンネル、ロールアウトと失敗のテレメトリ、デバイスごとのログ、ロールバック保護を提供し、実行時ヘルスシグナルがリリース決定を導くようにする。 Capgo を訪問して、更新パイプラインをアプリケーションヘルスチェックと修復コントロールと接続する。
