運用は「作ったあと」ではなく「作るとき」に決まる

講座34では、障害が起きたときにログを読み、原因を切り分け、一時対応して記録する方法を学びました。この講座はその先です。そもそも困りにくい形で作ることを扱います。

この講座の第一前提は1つです。

保守運用の第一前提は、長期的に困らない設計を最初からすること。

「運用は動き出してから考えればいい」と思いがちです。でも、運用で困ることの多くは、作るときに選んだ形から来ています。そして、その形は後から直すほど高くつきます。

なぜ後から直すと高くつくのか

理由は4つあります。どれも時間がたつほど大きくなります。

後から直して高くつく例

よくある例と、naminori で実際に起きたことを並べます。

• ログに個人情報が残る（よくある例）: 登録の画面で入力された氏名やメールアドレスが、そのままログに書かれる作りは珍しくありません。古いログを消す仕組みも無いと、気づいたときには何年分も貯まっています。直すにはログごと消すしかなく、それより前の調査の手がかりも一緒に失います（第6回）
• 定期処理が6週間止まっていた: 失敗しても何も言わない設定だったため、誰も気づきませんでした（第4回）
• OSとデータベースの更新: 古い版のサポート切れが近づき、深夜にメンテナンス表示を出して44分止めて更新しました。止める前提の作業には、事前の検証・バックアップ・戻し方の準備が要ります（第8回）

どれも、最初に「どう残すか」「どう気づくか」「どう更新するか」を決めていれば、小さく済んだものです。

最初に決める6つの問い

この講座では、機能を作るときに次の問いを先に考えます。

1. 既存のデータと、どう両立させるか（第2・3回）
2. 壊れたら、どうやって気づくか（第4回）
3. 誰に、どの重さで知らせるか（第5回）
4. あとで「いつ・誰が・何を」を追えるか（第6回）
5. 設定はどこにあり、何をしたら消えるか（第7回）
6. 戻せるか、更新し続けられるか（第8回）

全部を完璧にする必要はありません。後から足すと高くつくものだけは、最初に決めておく。それがこの講座の考え方です。

• 保守運用の第一前提
• 後から直すと高くつく4つの理由
• naminori で後から直して高くついた例
• 最初に決める6つの問い