💡Listoru（リストル）は、Web上の情報から企業の営業リストを自動で収集・作成するツールです。
この「企業DB開発日誌」では、数ある機能の裏側に隠された、私たちの試行錯誤を綴っていきます。
エラー画面には出ない問題や、データとの静かな対話から見えてきたもの。
正解のない開発現場のリアルな空気を、少しだけおすそ分けさせてください。
今日もリストルの裏側で起きた、ひとつの物語をお届けします。
インシデント（障害）報告の原則と、コンフィグ（設定）ファイルの脆弱性
この回は、書き方に迷いました。
書かなければ、何も伝わりません。
書きすぎれば、同じことを他所で起こす手引きになります。
だから、構造だけを書きます。
何が起きたかの形と、そこから何を決めたか。それだけです。
それでも、この回を抜くことは、考えませんでした。
都合の良い話だけを並べた記録は、どこかで信用を失います。
いちばん書きにくい回を書けるかどうかが、連載全体の信用に関わると考えました。
どのシステムにも、設定を書いたファイルがあります。
接続先。動作の切り替え。上限の数値。
そして、外の仕組みとやりとりするための情報。
これらは、プログラムの本体とは分けて持ちます。
環境ごとに違うものだからです。
分けて持つのは、正しい作りです。
分けて持つと、決まりごとも要ります。
誰が触れるのか。
どこに置くのか。
書き換えたあと、どう反映するのか。
この決まりごとは、作ってありました。
ただ、急ぎの作業のときに、その手順を通らないことがあります。
短い1行を足すだけなら、直接書いたほうが早い。
そう判断してしまう場面が、確かにあります。
手順は、面倒だから省かれるのではありません。
省いても、何も起きないから省かれます。
何も起きない日が続くほど、手順は、ただの形式に見えてきます。
形式に見えたまま、その日が来ました。
ある日、この設定を1つ書き足す作業をしました。
手で書きました。短いファイルです。書く内容も、決まった形をしています。書いて、保存して、反映しました。
問題は、そのあとに起きました。
設定を読み込む処理で、うまくいかない状態が発生しました。
そして、その状態が、画面に出ました。
本来、画面に出るはずのないものが、そこに表示されていました。
インシデント対応における「システムの一時停止」と、フェイルセーフの決断
ここから先の対応は、順番が決まっています。
- 何が出たのかを確認する。
- それを見た可能性のある範囲を確認する。
- 外とのやりとりを止める。
- 出てしまったものを、無効にする。
- 新しいものに置き換える。
- 確認する。
この順番のうち、いちばん大事なのは、3番目です。
止めることです。
原因を調べるより先に、止めます。
調べているあいだも、時間は流れているからです。
外の仕組みとの連携は、一時停止しました。
そのあいだ、その連携を使う機能は動きません。
お客様には、その旨をお伝えしました。
止めるのは、勇気の要る判断です。
動かしておけば、誰も困りません。
止めれば、確実に困ります。
それでも、止めました。
止めなかった場合に何が起きるかは、こちらには分からないからです。
止めた場合の損は、あとで数えられます。
止めなかった場合の損は、起きたかどうかさえ分かりません。
数えられる損と、数えられない損。
選べるのは、数えられるほうだけでした。
判断を早くできたのは、手順を先に決めてあったからでした。
こういう場面で、その場で相談を始めると、必ず「様子を見よう」という案が出ます。
止めれば確実に迷惑がかかり、止めなければ、何も起きないかもしれない。
その比較をすると、動けなくなります。
だから、比較しない形にしてあります。
この状況になったら、止める。
判断ではなく、手順として書いてあります。
決めておくのは、落ち着いているときにしかできません。
対応は完了しています。
出てしまったものは無効にし、新しいものに置き換えました。
連携は復旧しています。
この回で書けるのは、ここまでです。
何が、どういう形で出たのかは書きません。
どこに置いてあるものかも書きません。
構造だけを書いて、再現できる情報は載せません。
それが、この種の話を公開するときの最低条件だと考えています。
エラーハンドリング（例外処理）が動く前の死角。ブートストラップ（起動）処理の無防備な時間
止めているあいだも、作業は続きます。
- 原因を確かめる。
- 同じ構造の場所が他にないかを探す。
- 直したものを、順に確認していく。
このとき、焦って一度に直すと、別の不具合を作ります。
急いでいるときほど、1つずつ、確認しながら進める必要があります。
止めている時間を短くしたい気持ちと、確実に直したい気持ちは、いつも逆を向きます。
この綱引きに、うまい答えはありません。
あるのは、確認を1つずつ済ませていくという、地味な進み方だけでした。
原因のほうは、単純な構造でした。
設定を読み込む処理は、たいてい、いちばん最初に走ります。
システムが立ち上がる前。
何かを表示するより前。
まだ、何の準備もできていない段階です。
つまり、この処理でうまくいかないことが起きると、それを受け止める仕組みが、まだ動いていません。
受け止められないものは、そのまま外へ出ます。
普通の処理なら、こうはなりません。
うまくいかない場合の受け皿が、ちゃんと用意されています。
設定を読む処理だけが、その外側にいました。
いちばん危ないものを扱う処理が、いちばん守りの薄い場所にありました。
順番を考えれば、当然のことです。
守りの仕組みも、設定を読んでから動き始めます。
設定が読めていない段階では、まだ立ち上がっていません。
つまり、この処理は、構造上、必ず無防備な時間に走ります。
その事実を、私たちは意識していませんでした。
意識していれば、この処理だけは特別扱いにしていたはずです。
言い換えれば、守りの仕組みが立ち上がるより前に走る処理は、自分で自分を守るしかありません。
そういう処理は、数えるほどしかありません。
数えるほどしかないなら、特別扱いにできます。
再発防止策とデプロイ手順の厳格化。外から入ってくるもの以上に「内側」を守る設計
直したことは、2つです。
ひとつ。
設定を読み込むあいだ、外への出力を止めます。
何が起きても、そこから外へは出ません。読み終わってから、出力を再開します。
ふたつ。
うまくいかない場合を、必ず受け止めます。
受け止めたうえで、こう表示します。
「設定の読み込みに失敗しました」
それだけです。何が失敗したのかは、外には出しません。
調べるための記録は、別の場所に残します。
お客様への説明も、その日のうちに行いました。
何が起きたのか。
どの機能が、いつから、いつまで止まるのか。
影響はあるのか。
こちらが何をしたのか。
分かっていないことは、分かっていないと書きました。
調査中のことを、確定したように書くと、あとで訂正することになります。
訂正は、最初の説明より、ずっと信用を削ります。
この種の連絡で守るべきなのは、早さと、正確さの両方です。
そして、両立しないときは、「まだ分かっていない」と書けば、両方守れます。
この件のあと、決めごとを1つ増やしました。
設定を読む処理は、手で書かない。書く場合も、必ず所定の手順を通す。
そして、その処理には、出力を止めることと、うまくいかない場合を受け止めることを、必ず両方入れる。例外は、認めていません。
システムを守るとき、私たちは外から入ってくるものに注意を向けます。
入力を確かめる。
おかしなものを弾く。
権限を確認する。
そちらは、たくさんの目が向いています。
書籍にも、指針にも、そう書いてあります。
確認する項目も、整理されています。
こちらも、その通りにやってきました。
今回、問題が起きたのは、外から入ってくる場所ではありませんでした。
自分たちが、自分たちのために置いたものを、自分たちで読み込む場所でした。
守りを固めるとき、どこを固めるかは、たいてい経験から決まります。
経験は、過去に起きたことからしか作れません。
起きていないことについては、指針を読んで、想像するしかない。
今回のことは、そこに1つ足されました。
同じ構造は、おそらく、どのシステムにもあります。
いちばん最初に走る処理の無いシステムは、存在しないからです。
構造だけでも、この回を書いたのは、そのためです。
設定を読む処理こそ、いちばん厳重に囲うべきものでした。
いちばん最初に動くということは、まだ誰も見張っていない、ということです。
━━━━━━━━━━━━━━━━━━━━━━━━
次回予告
最終話「消した一行」
「使う会社が増えるほど、精度が上がります」
そう書きかけて、確かめに行きました。
━━━━━━━━━━━━━━━━━━━━━━━━
リストルは、今日もどこかを直しています。
→ 営業リスト探しに、もう時間をかけない。
業種別に企業情報をまとめて収集できるリストルを、まずは3,000件まで無料でお試しください。👇📝営業リスト収集ツール「リストル」
