窓口を1つ足しただけで、公開中のアプリが空っぽに見えた — 原因は今も分からない — 制作日誌 #28
サーバーに新しい受付窓口を1つ足して配った。変えたのは2ファイルだけ。5時間後、「アカウントのデータが消えた」と連絡が来た。データは1件も消えていなかったのに、アプリには何も映らなかった。元の版に戻したら直った。けれど、なぜ壊れたのかは今も分かっていない。分からないまま、何を決めたかを残しておく。
9月6日の夕方、サーバーに窓口を1つ足した。
作っているのは、タスクとカレンダーのアプリだ。スマホのアプリは、自分で書いた小さなサーバーを経由してデータを読み書きしたり、地図の検索をしたりしている。このサーバーに、Android 版のための場所検索の窓口を1本足した。
5時間ほどあとに、連絡が来た。
「iPhone のアカウントのデータが消えた」
この記事は、そこから元に戻すまでと、原因がまだ分からないという事実をどう扱ったかの記録だ。きれいな結末はない。
例えで言うと
サーバーを、役所の建物だと思ってほしい。
| 例え | 実物 |
|---|---|
| 役所の建物 | サーバー |
| 受付窓口 | 決まった用件を受け付ける入口(「経路」とも呼ぶ) |
| 新しい窓口を1つ増設 | 場所検索の入口を1本追加 |
| 倉庫の書類 | データベースに入っているタスク |
| 住民票の窓口に行っても紙が出てこない | アプリを開いても一覧が空 |
今回やったのは「窓口を1つ増設する」工事だった。既存の窓口には一切手を触れていない、つもりだった。ところが工事の翌日、既存の窓口で書類が出てこなくなった。倉庫を見に行くと、書類はちゃんと棚に並んでいた。
ここまでは例えのとおりだ。例えが破綻するのはこの先で、現実の役所なら「増設工事で配線を1本切った」といった原因がいずれ見つかる。今回はそれが見つかっていない。
変えたのは本当にそれだけだったか
最初にやったのは、自分の工事の範囲を疑うことだった。
| 確かめたこと | 結果 |
|---|---|
| 配った差分のファイル数 | 2ファイル |
| 新しく作ったファイル | 場所検索の処理 106行 |
| 既存ファイルへの変更 | 9行(読み込み1行・除外リスト1行・窓口の登録1行ほか) |
| 設定ファイル・部品の版の一覧 | 手元の本体と完全に同一 |
| サーバーの他のコード | 本体と同一。古い作業場から配って巻き戻したわけではない |
「うっかり別の版から配った」「部品の版がずれた」という、よくある事故の筋は全部消えた。論理的には、他の窓口に影響する変更ではない。
データは消えていなかった
次に、倉庫を見た。
データベースを直接数えると、いちばん大きな口座に 394件 のタスクが生きていた。直近12時間で消された行は 8件 だけで、その8件はすべて配信より前の時刻だった。
つまり、利用者の目には「消えた」と映っていたが、実際には1件も消えていなかった。アプリがサーバーから中身を取り込めず、空の一覧を出していただけだ。
これは大きかった。データが本当に消えていたら、戻す作業は復元になる。映っていないだけなら、窓口の側を戻せば済む。
分岐1:自分で直すか、元の版に戻すか
ここで道は2つあった。
A. 原因を探して、その場で直す。 差分は小さいので、怪しい行はすぐ見つかりそうに思える。
B. まず元の版に戻す。 原因探しは後回しにする。
選んだのは B だった。理由は単純で、A を選ぶと、原因が分かるまでの間ずっと、公開中の利用者全員が空の画面を見続けることになる。しかも「怪しい行」を推測で直して配ると、それがまた別の壊れ方をしない保証はない。
戻し先は、2日前の9月4日18時13分に配った版にした。報告を受けて21時35分に切り戻し、直後に元どおり映ることを本人に確かめてもらった。
配ったのが16時17分、報告が来たのは21時半ごろ。およそ 5時間。その間、壊れていることに作った本人は気づいていなかった。
なぜ5時間も気づけなかったか
配った直後に確かめたのは、「新しい窓口が返事をするか」だけだった。
既存の窓口、つまりアプリがいつもタスクを取り込んでいる経路は、1回も叩いていない。増設した窓口の前で「開いてますね」と確認して帰り、隣の住民票の窓口が止まっていることには気づかなかった、という形だ。
新しいものを足したときに壊れるのは、たいてい新しいものではなく、それまで動いていたものの方だ。確かめる順番が逆だった。
分岐2:同じ窓口を、もう一度足すか
切り戻したあと、同じ日のうちに、同じ場所検索の窓口を足した版をもう一度配った(中身は場所検索の窓口と、集計画面の列を5行足したものだけ)。
今度は動いた。Android のエミュレーターで2回検索すると、場所検索の利用回数は 0→1→2 と増え、iPhone 側の地図検索の回数は 184 のまま変わらなかった。出し分けは効いていて、iPhone 側に影響も出ていない。
3日後の9月9日にも、この窓口を含む版を配った。配った後は、場所検索だけでなく、タスクの経路や広告の報告の経路など既存の窓口もまとめて叩き、全部が「鍵を見せてください」という正しい拒否を返すのを確かめた。
ここで困ったことになった。同じ中身が、1回目は壊れて、2回目以降は壊れなかった。原因として考えられる筋は、どれも裏が取れていない。
「たぶん」と書かないと決めた
ここがこの記事でいちばん残したいところだ。
原因が分からないとき、それらしい説明を書きたくなる。「配った瞬間の一時的な不具合だろう」「アプリ側の取り込みがたまたま失敗しただけだろう」。どれもあり得そうで、どれも確かめていない。
確かめていない説明を記録に書くと、次に同じことが起きたとき、その「たぶん」を事実として読んでしまう。だから記録には「原因は未特定」とだけ書いた。
分かっているのは次の3つだけだ。
- 自分の配信が引き金になったのは確か(戻したら直った)
- データは消えていない(394件が生存、削除8件は全部配信前)
- 同じ窓口を足した版は、後で2回配って2回とも壊れなかった
決めたこと
原因が分からない以上、「原因を潰す」対策は打てない。代わりに、壊れたときの被害を小さくする方の決めごとを作った。
| 決めたこと | 中身 |
|---|---|
| 配る前の伝え方 | 「すぐ戻せます」で終わらせず、壊れたら誰が困るか(公開中の全利用者)を先に言う |
| 配った直後の確認 | 新しい窓口ではなく、既存の窓口が今までどおり動くかを先に見る |
| 調べ方 | 本番で試さない。手元でサーバーを立ててから調べる |
| 事故のとき | 止まる → 事実だけ報告 → 元の版に戻す。推測で直さない |
窓口を1つ足すだけ、という工事でも、公開中の建物でやる以上は利用者全員の前でやっている。そのことを、394件のタスクが映らなかった5時間で思い知った。
コメント (0)
まだコメントはありません。最初の一言を残しませんか?