ログ設計 に関連する内容。

「なにかトラブルが起こった時にログが出てないと対処できない、とりあえずたくさん出力しておく。」をやると痛い目を見る。

トラブルが起きた時の対応を予測して設計しておかないと、いくらたくさんのログを出力していても、ノイズになるだけで実際のトラブル時には役に立たない。

必ずトラブル発生時にどのように調査・対応するのかを事前に想定して設計する。

例外設計の考え方

予期する例外	予期しない例外
アプリケーションコードで必ずハンドリングする	予期してないのでアプリケーションコードでハンドリングされない
システム上発生しうるが、処理を継続できないもの。 ・不正な入力値 ・同時更新における排他 ・開発者がどうしようもできない事象。 　・マネージドサービスの障害 　・ 外部サービスのAPI呼び出しのサーバ側のエラー 　・ 長くかかる処理のタイムアウト	・コーディングミス 　・ 設定ファイルのミス 　・ リリース作業時の手順ミス 　・ データベースのマイグレーション漏れ ・リソースの不足 　・ Out of Memory 　・ Disk full

「とりあえず出しておくログ」は役に立たない

トラブルが起きたとき、やみくもに全ての情報をログに出力するだけでは、運用で本当に役立つログは得られない。重要なのは、トラブル発生時にどのように調査・対応するのかを事前に想定して設計することで対応シナリオを想定せずに出した大量のログは、実際の障害対応ではノイズになることが多い。

障害検知には誤検知と見逃しがある

障害検知システムには false positive （偽陽性）と false negative （偽陰性）が存在し、これらが多いと検知の信頼性が低下する。
偽陽性は本来異常でないのに異常として検知される状態、偽陰性は本来異常なのに検知できない状態を指す。偽陰性は開発ルールや静的検査で防ぎやすいが、偽陽性は設計段階での注意が必要になる。

false negative（偽陰性）が多いと起きる問題

偽陽性が多いと、Alert Stormingと呼ばれる状態に陥る。大量のアラートが発生するが、その多くは対応不要なものであり、人間が慣れてしまうことで本当に重要なアラートへの初動が遅れる。必須パラメータの欠落など、発生頻度が高く開発者が対応しないケースは、特にこの原因になりやすい。

予期しない例外を減らす

予期しない例外とは、発生する可能性は分かっているが、発生時には利用者や運用者では対応できず、開発者による調査と修正が必要になる例外を指す。特にユーザー入力をきっかけに予期しない例外が発生しないように設計することが重要。ネットワーク断のように扱いが難しいものは、常に予期しない例外とするのではなく、サーキットブレイカーなどで条件を絞り、断続的なエラー時のみ予期しない例外として扱うとよい。