個人情報を集め過ぎずに本番障害を調べる

利用者の仕事から始める

役立つログは、必要最小限の実用的な情報で出来事を説明します。どの操作が、どの段階で、どの版のもとで、依存先のどんな結果によって失敗したかという運用の問いから始めます。リクエスト本文を丸ごと保存する近道は、顧客情報の管理されない複製を作りがちです。

目的に合う範囲を保つ

構造化したイベント名、時刻、リクエストID、機密でない結果コードを優先します。顧客の本文は権限のある業務システム内に置きます。OWASPのログ指針も機密情報の除外とアクセス保護を扱っています。障害中に収集を増やす前に、保存期間、アクセス、マスキングを決めておきます。

試したいシナリオ

顧客更新を外部連携が拒否する例では、連携名、操作ID、試行回数、分類済みのエラーを記録します。担当者は業務記録へ別途アクセスできます。外部エラーにメールやトークンが含まれる場合も試します。自前の項目を消しても、外部メッセージは消えません。関数の引数だけでなく実際の保存結果を確認します。

問題を移すだけにしない

プロキシや分析に残り得るURLへ秘密を入れないでください。ハッシュ化したIDを自動的に匿名とみなさず、デバッグ設定で本番収集を黙って広げません。権限や期間が違う場合は監査記録と一般診断を分けます。ログ処理自体の代替エラーにも秘密を出さないようにします。

障害になる前にログイベントを設計する

更新失敗を例に、名前、時刻、操作ID、アプリ版、試行回数、範囲を決めた結果分類を定義します。関連付けに必要な項目と便利なだけの項目を分けます。任意オブジェクトの保存では後で情報が増え得るため、許可項目を明示します。顧客への説明を一般的にしても、運用イベントは役立つものにできます。

保存までの全経路をたどります。アプリのログだけでなく、プロキシ、ミドルウェア、エラー収集、ワーカー、依存ライブラリも出力します。URL、ヘッダー、例外、入れ子の外部応答を確認します。架空のメール・トークン・本文に似た目印を入れ、各保存先で探します。マスキングの単体試験だけでは、別部品が先に元の値を保存しなかったことを証明できません。

閲覧と削除も運用作業として決めます。検索、出力、保存期間変更の担当を定め、一時的な詳細収集は自然に期限切れにします。原記録が必要なら業務システムの権限を使い、全員のログ権限を広げません。出力コピーや障害メモも削除範囲で考えます。消しすぎて診断不能なら、個人情報全体を戻さず安全な構造情報を加えます。加工した障害例を残し、変更後にもこの両立を試します。

ログ確認の表

結果の確かめ方

各項目は何の診断に必要か。誰が読めて出力できるか。コピーも含めいつ消すか。加工済みの代表エラーを用意し、顧客の全文を受け取らずに実際の失敗パターンを調べられることを確認します。