監視ツールを選ぶ前に利用者導線から決めるべき理由

サーバーが正常でも利用者は失敗します

監視ツールより先に決めるべきは、利用者がサービスで必ず終えるべき仕事と、その仕事が成功したという証拠です。サーバーが応答しCPUとメモリに余裕があっても、利用者がログインできない、注文を完了できない、アップロードしたファイルを使えないのなら、サービスは信頼できる状態ではありません。

インフラ指標は問題が起きた理由を説明するために必要です。しかしサービス信頼性の最終的な定義にはなれません。Google SREは監視において「何が壊れたか」という症状と「なぜ壊れたか」という原因を区別します。CPU飽和やデータベース接続エラーは原因かもしれませんが、利用者が重要な作業を完了できなかったという事実が先です。HTTP 200の応答とともに誤った結果を返す場合も失敗に含めます。^[1]

したがって監視設計の順序は、重要な利用者導線から始まり、成功結果、開始・完了・失敗の事象、SLI、測定位置、必要な計装を経てツールに至ります。ツールを先に決めると、集めやすいCPU、メモリ、要求数、状態コードがダッシュボードを埋めます。逆に利用者導線から決めると、どのデータがなく、どこを新たに計装すべきで、どの製品や保存方式が必要かが見えてきます。

状態コードが無用という意味ではありません。状態コードは要求処理の一段階を示します。問題はその一段階を利用者の結果全体へ拡大解釈するときに生じます。とくに非同期処理ではacceptedとcompletedを分けます。キューに仕事を入れた時点は中間のチェックポイントにすぎません。Worker実行、外部API呼び出し、データ保存、利用者への結果提供まで終えて初めて導線が完了します。

ログイン

成功と誤解しやすい信号: 認証APIがHTTP 200を返す / 利用者が経験した失敗: トークン保存や画面初期化が失敗し保護画面に入れない / 実際に確認すべき結果: 認証済み画面が実際に使える状態になった

注文・決済

成功と誤解しやすい信号: 決済要求が承認された / 利用者が経験した失敗: 注文原簿が生成されない、または領収が表示されない / 実際に確認すべき結果: 決済・注文・表示の状態が一貫して完了した

ファイルアップロード

成功と誤解しやすい信号: アップロード受付APIが成功した / 利用者が経験した失敗: 非同期変換処理が失敗しファイルを開けない / 実際に確認すべき結果: 後処理を終えたファイルが実際に使える状態になった

検索

成功と誤解しやすい信号: 検索APIが正常に応答した / 利用者が経験した失敗: 古い索引や誤った絞り込みで必要な結果が見つからない / 実際に確認すべき結果: 結果が表示され正確性と鮮度の条件を満たした

重要な利用者導線から選びます

Critical User Journey、すなわち重要な利用者導線とは、利用者がサービスの中心的な価値を得るために行う一連の作業です。オンライン商取引なら商品検索、買い物かごへの追加、購入完了がこれにあたります。各導線は複数の構成要素と要求から成るため、既存のサーバーログ一つで成功と失敗を判定するのは困難です。Google SREも、何を測るかを決める前に利用者にとって重要な活動をまず識別すべきだと説明します。^[1]

すべての画面とAPIを重要にする必要はありません。下記六基準で範囲を絞ります。低頻度でも重要性は低いとは限りません。月末精算、管理者承認、大量データ提出はまれでも失敗被害が大きい導線です。

選んだ導線をUser Journey Canvasの14Fieldへ記入します。

Completion Boundaryは「APIが応答した」ではなく、利用者が得ようとした状態が生まれたという証拠でなければなりません。逆に利用者が意図して取り消した導線をサービスの失敗として集計してもいけません。分母に何を入れ何を除いたかがSLIそのものと同じくらい重要です。

利用者価値

失敗するとサービス利用目的を達成できないか。

被害の大きさ

金銭・データ・権限・業務遅延など戻しにくい被害が生じるか。

事業重要度

売上・契約履行・顧客の主要業務へ直接結び付くか。

依存性

外部認証・決済・メッセージング・保存など複数システムを通るか。

復旧難度

再試行だけで解決できず人の確認が必要か。

到達範囲

多数が使うか、低頻度でも失敗被害が大きいか。

導線をOutcomeとEvent、SLIへ移します

SLI（Service Level Indicator）は、サービスが利用者に提供した結果の水準を表す測定値です。実務では良い事象と有効な全体事象の比率として書いておくと再利用しやすくなります。利用者導線の成功率SLIは、成功と確認された有効導線の数を、測定可能な有効導線の全体数で割った値です。

Google SREはSLIをまず利用者にとって重要な結果として仕様化し、その結果を実データでどう測るかは別の実装問題として扱うよう勧めます。同じSLIでも、サーバーログ、ロードバランサー、合成テスト、クライアント計装で異なる方式で実装され、それぞれ正確度・網羅性・費用が異なります。^[2] OpenSLOもSLIをデータソースから指標を読む方法として定義し、goodまたはbadとtotalを分けて表します。SLOの目標値・評価期間・警報方針はSLIとは別の対象として扱います。^[3]

ここでは遅延の基準や目標成功率を決めません。まず開始と終了を一貫して測り、分布と生の件数を確保します。どの水準を目標とし、どの期間で評価するかは後続のSLO方針で決めます。

導線ごとにOutcomeとEvent、候補SLI、注意すべきBlind Spotを併せて書きます。ログイン後の業務開始のOutcomeは、認証済みの利用者が保護画面を実際に使える状態です。主要Eventはlogin_submitted → session_created → protected_view_readyで、Blind Spotは外部認証は成功したがクライアント初期化が失敗する区間です。注文・決済完了のOutcomeは、決済と注文原簿、領収の状態が互いに一致することです。Eventはcheckout_submitted → payment_confirmed → order_committed → receipt_visibleで、Blind Spotは決済承認後のWebhook失敗と重複再試行です。ファイルアップロードと処理のOutcomeは、ファイルが受け付けられて終わりではなく実際に使えるようになることです。Eventはupload_started → upload_accepted → processing_started → file_readyで、Blind Spotはキュー投入後の仕事の消失とDead Letter、コールバックの欠落です。検索結果確認のOutcomeは、結果が表示され必要なデータ範囲と最新の状態を反映することです。Eventはsearch_submitted → results_renderedとindex_watermarkで、Blind SpotはHTTP 200の空結果、古い索引、一部データセットの欠落です。承認業務完了のOutcomeは、正しい権限者が承認し後続の状態が反映されることです。Eventはapproval_requested → approval_recorded → downstream_state_updatedで、Blind Spotは承認記録はあるが後続システムの同期が失敗する区間です。

事象名そのものは組織ごとに変わります。重要なのは一つの導線IDで開始、中間段階、最終結果をつなぐことです。再試行が起きる場合は、同じ試行を何度も集計しないよう冪等キーや相関IDも必要です。

どこで測るかを決めます

利用者に近い位置で測るほど実際の体験をよく反映しますが、実装費用とデータ欠落の可能性は大きくなります。サーバー内部で測れば安定して集めやすい一方、要求がサーバーへ届く前の失敗やクライアント画面の問題は見えません。Google SREも、同一のSLI仕様がサーバーログ、ブラウザ基盤の合成テスト、クライアント計装で実装され、それぞれ異なる欠落を持つと説明します。^[2]

一つの位置だけですべてを判断するのは困難です。一般には、利用者の結果を裏づける測定点と、失敗の原因を説明する内部の測定点が併せて必要です。ただしログ・メトリクス・トレースのどれを選ぶかは別のSignal Selectionの問題です。

よく生じる測定の死角は五つです

第一に、HTTP 200だけを成功として分類する場合です。HTTP状態コードはプロトコル処理の結果です。応答本文が誤っていたり、一部のデータしか返らなかったり、エラーメッセージを200で包んだのなら、利用者は失敗しています。Google SREもHTTP 200と誤ったコンテンツが同時に返る場合を暗黙の失敗として分類し、こうした誤りには端から端までの確認が必要だと説明します。^[1] したがって業務結果コード、画面利用可能の事象、データの不変条件など、状態コード以外の完了証拠が要ります。

第二に、非同期要求の受付と完了を取り違える場合です。202 Accepted、キュー投入の成功、処理ID発行は導線の完了ではありません。利用者に必要な結果が生まれる時点まで同じ導線IDを保ちます。完了事象が来ないときの扱いも決めます。明示的な失敗事象だけを集計すると、永遠に待機中の仕事が統計から消えます。結果を確定できない状態は成功と見なさず、unknownまたはstuckとして別に示します。

第三に、外部依存の失敗を利用者指標から除く場合です。外部の決済や認証の提供者が失敗したとしても、利用者はそのサービスを使えませんでした。利用者導線SLIでは失敗として残します。代わりに失敗の原因にdependencyを付けて内部システムの問題と分けます。外部提供者の責任だからと利用者の結果から取り除くと、内部指標はよく見えますが実際の体験から離れます。端から端までの利用者SLIを保ちつつ、構成要素・依存の指標で原因を分けるほうが賢明です。^[1]

第四に、トラフィックが低いのに比率だけを見る場合です。試行数が少ないサービスでは一度の失敗が比率を大きく揺らします。逆にその期間に要求がまったくなければ失敗を観測する機会もありません。Google SREも、要求が非常に少ない利用者の可用性は偶然すべて成功することも、一度の失敗で非常に低くなることもあると指摘します。^[1] 低トラフィックでは五つの原則が要ります。比率とともに分子・分母の実件数を示します。要求なしを正常に置き換えません。主要経路の全断は合成トランザクションで補います。実際の利用者結果と合成テストの結果を同じ分母に混ぜません。目標値と評価期間は十分なデータと利用者の被害を検討したうえで別の方針で決めます。

第五に、測れなかった導線を成功として扱う場合です。クライアント事象収集の障害、標本抽出、誤った絞り込み、スキーマ変更、相関IDの欠落によって結果がわからない場合があります。このとき観測されなかった事象を成功として扱うと、計装障害が信頼性の向上のように見えます。SLIとは別に計装の網羅性を確認します。想定される開始事象に対して結果をつなげられる比率、事象収集の遅れ、スキーマ誤り、未分類の結果数を併せて見ます。

計装の空白は一覧で閉じます

点検が付かなかった項目を、そのまま特定製品の購入一覧に変えることはしません。まずどのデータがなぜ必要かを計装Backlogとして登録します。そのうえで既存のログや事象で解決できるか、アプリケーションの変更が要るか、別の測定基盤が要るかを判断します。

SLIを次の運用判断へ引き継ぎます

利用者導線SLIができたからといって、ただちに警報や配布遮断の規則を付けてはなりません。まずSLIの意味とデータ品質を、他の運用方針が使える形で引き継ぎます。順序は重要な利用者導線からUser Outcome、開始・完了・失敗の事象、SLI仕様、SLI実装と網羅性の証拠まで下りたあと、SLOの目標とError Budget、警報条件と伝達先、Signalの選択、障害Runbook、配布ゲートとロールバック行動へ分かれます。OpenSLOもSLI、SLOの目標と時間窓、AlertPolicyを分離した構造で表します。この分離は特定のツールを使うための形式というより、測定の定義と運用の判断を混ぜない契約として読むほうが有用です。^[3]

Handoff Contractを下記五項目に分け、渡す入力と次段階が決める内容を区別します。

この段階で99.9%のような汎用の目標を入れる理由はありません。目標の数値は、サービスの利用者の期待、被害、現在の測定データ、費用と運用責任を併せて検討して決めます。

SLO・Error Budget

引き継ぐ入力: 導線定義、good/total事象、測定位置、網羅性、区分、結果確定方法. 次段階の判断: 目標値、評価期間、Error Budgetと使用方針.

Alert

引き継ぐ入力: 利用者被害の意味、失敗理由コード、データ遅延、低Traffic特性. 次段階の判断: 人を起こす時点、Page・Ticket・Dashboard、抑制・重複排除.

Deployment Gate

引き継ぐ入力: 配備Versionと結べるSLI、変更前後の比較可能性、計装正常性. 次段階の判断: 配備中止・承認・例外条件と方針.

Signal Selection

引き継ぐ入力: 調査する失敗区間と測定点. 次段階の判断: Log・Metric・Trace・Profileの種類と配置.

Incident / Rollback

引き継ぐ入力: 利用者影響、失敗導線、影響区分. 次段階の判断: 緩和・復旧・連絡・Rollbackまたは前進復旧行動.

ツールの選択は測定契約が完成したあとです

利用者導線とSLIが定義されると、監視ツールを評価する問いも変わります。必要な測定位置の事象を集められるか、クライアントとサーバー、非同期処理、外部依存を一つの導線としてつなげるか、good eventsとvalid eventsの分子・分母を失わずに計算できるか、計装の欠落と結果不明の状態を隠さないか、利用者・地域・端末・テナント別の問題を必要な水準まで分けられるか、配布バージョンと利用者の結果をつなげるか、測定の定義を特定製品の外でも検討し移せるかです。

これらの問いに答えられなければ、機能の多いツールを入れてもダッシュボードが増えるだけです。サービスが信頼できるという言葉は、サーバーが動いているという意味ではありません。利用者が重要な仕事を始め、正しい結果を必要な時間内に得られるという意味です。インフラ指標はその結果が悪くなった理由を探させてくれます。何を信頼性と見るかは利用者導線が決めます。