窓口を1つ足しただけで、公開中のアプリが空っぽに見えた — 原因は今も分からない — 制作日誌 #28
制作日誌

窓口を1つ足しただけで、公開中のアプリが空っぽに見えた — 原因は今も分からない — 制作日誌 #28

サーバーに新しい受付窓口を1つ足して配った。変えたのは2ファイルだけ。5時間後、「アカウントのデータが消えた」と連絡が来た。データは1件も消えていなかったのに、アプリには何も映らなかった。元の版に戻したら直った。けれど、なぜ壊れたのかは今も分かっていない。分からないまま、何を決めたかを残しておく。

KIYODO
#個人開発#サーバー#障害対応#失敗談#制作日誌

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つだけだ。

  1. 自分の配信が引き金になったのは確か(戻したら直った)
  2. データは消えていない(394件が生存、削除8件は全部配信前)
  3. 同じ窓口を足した版は、後で2回配って2回とも壊れなかった

決めたこと

原因が分からない以上、「原因を潰す」対策は打てない。代わりに、壊れたときの被害を小さくする方の決めごとを作った。

決めたこと中身
配る前の伝え方「すぐ戻せます」で終わらせず、壊れたら誰が困るか(公開中の全利用者)を先に言う
配った直後の確認新しい窓口ではなく、既存の窓口が今までどおり動くかを先に見る
調べ方本番で試さない。手元でサーバーを立ててから調べる
事故のとき止まる → 事実だけ報告 → 元の版に戻す。推測で直さない

窓口を1つ足すだけ、という工事でも、公開中の建物でやる以上は利用者全員の前でやっている。そのことを、394件のタスクが映らなかった5時間で思い知った。

コメント (0)

まだコメントはありません。最初の一言を残しませんか?