自社が運営する弁護士みつかるは、インフラを全面的に移行した際、2つのテーブルへの書き込みだけが移植されず、長期間誰も気づかないまま残っていた。読み取りは正常に動いていたため、画面も応答もすべて200のままだった。この記事はその経緯と直し方をまとめる。
この記事で分かること
- 書き込みだけが落ちる移行漏れが、なぜ画面上は正常に見えるか
- 時刻の表記形式で移行前後を切り分ける見つけ方
- 移行後の検収に「書けるか」をどう組み込んだか
この記事で分からないこと(正直に書く)
- 同種の書き込み漏れがほかのテーブルにも残っていないかは、全テーブルを洗い直していない
- 落ちていた期間の利用者への影響を、件数以外の形で定量化できていない
書き込みだけが3か月以上、静かに止まっていた
自社が運営する弁護士みつかるは、2026-05にインフラを全面的に移行した。86個のAPIを書き直す大掛かりな移行だったが、そのうち2つのテーブルへの書き込みだけが移植されず、101日間、誰も気づかないまま残っていた(出所: 自社の運用記録、確認日2026-09-06)。読み取りは正常に動いていたため、画面は普通に表示され、応答もすべて200だった。
列名のズレと、隠れる場所が悪かったこと
一方のテーブルは、書き込み処理自体が移行の書き直しから漏れて存在しなかった。もう一方は書き込み処理は残っていたが、列名が移行前のスキーマのままで実際の列名と一致していなかった。しかもこの処理は応答を返したあとに裏側で実行される非同期の仕組みの中に置かれていたため、失敗しても例外がどこにも出ず、応答はそのまま200で返り続けていた(出所: 自社の運用記録、確認日2026-09-06)。
なぜ気づけなかったか
最終更新日時を見るだけでは、故障日と移行日を取り違える。効いたのは、書き込まれる時刻の表記形式で切り分けたことだった。移行前の基盤に由来する記録は特定の書式、移行後の基盤に由来する記録は別の書式で残る。対象の2テーブルを調べると、移行後の書式の記録が一件もなかった。ほかの2つのテーブルには移行後の書式の記録があり、システム自体は生きていることが確認できたため、「止まった」のではなく「移行の時点から一度も書けていない」と分かった(出所: 自社の運用記録、確認日2026-09-06)。
どう直したか
2026-09に、抜けていた書き込み処理を実装し直し、列名を実際のスキーマに合わせた。あわせて、応答を返したあとに裏側で実行する処理には、失敗を記録に残す仕組みを入れた。検収の方法も変えた。移行後の検収は「読めるか」だけでなく「書けるか」を、実際に1件書き込んで移行後の書式で行が増えることまで確認する形にした(出所: 自社の運用記録、確認日2026-09-06)。
検査に何を書けば次は見つかるか
週次のレポートに、テーブルごとの最終書き込み時刻を確認する項目を追加した。応答を返したあとに裏側で実行される処理は、失敗しても表からは見えないという性質を前提に設計する必要がある。移行のような大きな切り替えでは、読み取りだけでなく書き込みも、切り替え後の形式で実際に増えているかを確かめて初めて完了とみなす。
同じ「200のまま隠れる」型の事故は、5xx監視の「ゼロ件」の記事や、INFOレベルの失敗ログの記事でも扱っている。
自社の移行検収・監視設計について相談したい場合は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. 何が起きていたのか
インフラ全面移行で、2つのテーブルへの書き込みだけが移植されず、101日間、誰も気づかないまま残っていた。読み取りは正常だったため、画面も応答もすべて200だった。
Q2. なぜ書き込みの失敗が表に出なかったのか
一方は書き込み処理自体が移行から漏れて存在せず、もう一方は列名が移行前のスキーマのままだったが、応答を返したあとに裏側で実行される非同期の仕組みの中にあったため、失敗しても例外がどこにも出なかった。
Q3. どうやって見つけたのか
書き込まれる時刻の表記形式で切り分けた。移行前後で書式が異なるため、対象のテーブルを調べると移行後の書式の記録が一件もなく、ほかのテーブルには移行後の記録があることから、移行の時点から一度も書けていないと分かった。
Q4. どう直したのか
抜けていた書き込み処理を実装し直して列名を実際のスキーマに合わせ、裏側で実行する処理には失敗を記録に残す仕組みを入れた。検収も「読めるか」だけでなく「書けるか」を確認する形に変えた。