自社プロダクト「Studel」の問い合わせフォームが、ドメインの移設をきっかけに65日間405を返し続けていた(出所: 自社の運用記録、確認日2026-09-06)。
この記事で分かること
- なぜデータベースの件数監視では受け口の故障を検知できなかったのか
- 何を監視に足せば次は見つかるか
- SREの監視分類のどこにこの故障が当てはまるか
この記事で分からないこと(正直に書く)
- 65日間で実際に取りこぼした問い合わせの件数(原理的に復元不可能)
- 同種の受け口が他のプロダクトに残っていないかどうかの全数確認
何をしたか: ドメインを移設した
問い合わせフォームを含む配信環境のドメインを移設した。この移設によって、フォーム送信を受け取る処理の配置がずれ、送信そのものが受け付けられなくなった(出所: 自社の運用記録、確認日2026-09-06)。
何が起きたか: 65日間、送信が消え続けた
移設後、問い合わせフォームへの送信は405を返し続けた。データベースには送信の行が一切増えないため、「未通知の件数を数える監視」は常に0件を示し、それが正常なのか、そもそも届いていないのかをデータベース側からは区別できなかった(出所: 自社の運用記録、確認日2026-09-06)。取りこぼした件数は原理的に復元できない。
なぜ気づけなかったか: 「受け取ったものの異常」しか見ていなかった
監視が見ていたのは「受け取った送信の中に異常があるか」だった。受け口そのものが機能しているかどうかは対象に入っていなかった。米Googleが公開しているSREの監視の考え方では、監視を症状に基づくブラックボックス型と、内部の状態を調べるホワイトボックス型に分け、エラーの指標については「明示的な失敗だけでなく、200のような成功応答でありながら中身が誤っているものも含めて捉える」という考え方が示されている(出所: Google SRE Book「Monitoring Distributed Systems」、https://sre.google/sre-book/monitoring-distributed-systems/、確認日2026-09-06)。今回の受け口は、そもそも応答そのものが405だったにもかかわらず、後段のデータベース側の指標だけを見ていたために「システムが今まさに動いていない」という症状を直接捉える監視が存在しなかった。
どう直したか: 本番へ実際に送信する合成監視を置いた
2026年9月、本番の問い合わせエンドポイントへ実際に送信し、テストである旨を含む行を残す合成監視を追加した。データベースの件数だけを見る監視と併用し、受け口そのものの生死を外側から定期的に確認する形にした(出所: 自社の運用記録、確認日2026-09-06)。
再発防止: 受け口には外から叩く検査を足す
問い合わせ・申込・予約・登録のような受け口は、内部の記録が増えないこと自体では故障と区別がつかない。何を検査に書けば次は見つかるかという観点では、データベースの件数監視に加えて、本番エンドポイントへ実際にリクエストを送る合成監視を置くことが効いた。デプロイや配信構成を変えた直後は特に、この外側からの検査を欠かさないようにしている。
会員向け画面がデプロイから丸ごと消えていた事例は会員画面が消えていた話、人間には白紙だったページの事例はcurlでは見えない白紙ページの話にまとめている。監視の粒度の設計判断は、姉妹記事「監視の粒度を上げるほど費用になる理由」も参考にしてほしい。
自社の受け口監視や合成監視の設計について相談したい場合は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. なぜデータベースの件数監視では検知できなかったのか
送信が受け付けられずデータベースに行が一切増えないため、「未通知件数」を見る監視は常に0件を示し続けた。0件が「異常が無い」のか「そもそも届いていない」のかを区別できなかった。
Q2. SREの監視の考え方とはどう関係するか
Google SRE Bookは、症状に基づくブラックボックス型監視と内部状態を見るホワイトボックス型監視を分け、エラーの指標には成功応答でも中身が誤っているものを含めるべきだとしている。今回はその成功応答にすら至らず405を返していたが、受け口そのものの症状を直接見る監視が無かった。
Q3. 取りこぼした問い合わせは後から分かるのか
分からない。データベースに記録が一切残らないため、65日間で実際に何件を取りこぼしたかは原理的に復元できない。
Q4. 再発防止のために何を追加したか
本番の問い合わせエンドポイントへ実際に送信し、テストである旨を含む行を残す合成監視を追加した。データベースの件数監視と併用し、受け口そのものの生死を外側から確認できるようにした。