【要約】外部サービスが『静かに壊れる』とき — 404 が 33 時間続いて初めて気付いた観測性の穴 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
外部APIの不具合により、以下の「静かな破壊」が発生した。
- ・HTTP 200が返るため、
raise_for_status()で検知不能。 - ・クエリパラメータ無視により、他者のデータが混入。
- ・「取得件数0」が正常値と区別できず、異常を見逃す。
- ・ログは正常だが、データが壊れる事態に33時間気付けなかった。
// Approach
以下の4つの対策を講じる。
1.**データ内容の検証**:
item["user"]["username"] == user のように、返却値の整合性を明示的にチェックする。2.**期待値の記録**: JSONLに
api_ok フラグや追記件数を付与し、SQL等で異常を検知可能にする。3.**多角的な観測**: API以外に、HTMLへのHEADリクエストやRSS取得など、別経路での生存確認を行う。
4.**監視の分離**: 週次の「データ取得」と、日次の「健全性チェック」を分離し、検知までの遅延を最小化する。
// Result
データの整合性チェックにより、APIの挙動変化を即座に検知可能。また、監視を日次に分離することで、異常検知までの時間を最大1週間から24時間以内に短縮できる。
Senior Engineer Insight
> 外部依存の健全性は、ステータスコードではなく「意味論的な整合性」で判断すべきだ。APIの仕様変更は、エラーではなく「正しい形式のゴミ」として現れる。本記事が示す「データの素性検査」や「監視周期の分離」は、リソースの限られた環境でも導入可能な、極めて実戦的な観測戦略である。大規模システムにおいても、この「期待値との乖離」を検知する設計は不可欠だ。