ログの記録方法が適切であり、トラブルシューティングに必要な情報が取得できるか？¶
Type: DeepDive
Category: 非機能要件・運用 Audience: 設計リーダー / SRE / インフラ設計者 / レビュー担当者
背景・概要¶
設計段階で「何をログに残すか」を明示しておかないと、障害調査が不可能になり、ブラックボックス化する
ログレベル・粒度・個人情報マスキング・ID付与などを検討し、設計に落とし込む必要がある
例¶
- エラー・警告・情報ログをレベル分けして出力する
- 各リクエストに trace_id を付与し、ログビューアやトレーシングツール（Datadog・New Relic・OpenTelemetry・AWS X-Ray・Azure Monitor Logsなど）で一気通貫で確認できるように設計する
- メールアドレスや氏名などの個人情報はログ出力前にマスキングする
よくある失敗例¶
- 重要な処理のログが全く出力されていない
- スタックトレースしか出ておらず、何をしていたかが分からない
- ログ量が膨大すぎて、欲しい情報が埋もれてしまう
FAQ¶
Q. ログの出力方針を誰が決めるべき？
A. 設計者が「どう調査するか」を想定して設計し、実装者とすり合わせるのがベストで運用目線が重要
Q. セキュリティとログって相反しない？
A. 適切なマスキング・匿名化をすれば併存可能です。ログが無い方が重大事故につながるのでしっかり設計されたい