公開してからが本番

サービスは、作って公開したら終わりではありません。使われ始めると、思ってもいなかった入力が届き、外部のサービスが止まり、ある日の変更が別の場所を壊します。

作ったものを動かし続け、壊れたら直す仕事を、保守運用と呼びます。この講座では、その中でも一番最初に任されることの多い「エラーが起きたときの対応」を扱います。

ここでいう障害は、利用者が期待どおりにサービスを使えない状態のことです。画面が真っ白になる、ボタンを押しても進まない、表示が間違っている、どれも障害です。

障害対応の6つの段階

障害対応は、次の6つの段階に分けて考えます。

急いでいるときほど、3の次にいきなり「直った、終わり」にしたくなります。でも、飛ばした段階のツケは後から、利子付きで返ってきます。この講座は、その「後から困ること」を毎回具体的に見ていきます。

naminori で実際に起きたこと：6週間、誰も気づかなかった

naminori では、毎日決まった時刻に動く処理（定期処理）がいくつかあります。新しい記事を検索エンジンに知らせるための一覧（サイトマップ）を作る処理、求人を検索エンジンに知らせる処理などです。

2026年8月、週ごとの数字をまとめていたところ、公開した記事が5日間、検索結果に1回も表示されていないことに気づきました。たどっていくと、サイトマップが約6週間前から更新されていませんでした。

• サーバに入れる道具の管理方法を変えたときから、定期処理が起動すらしていなかった
• 定期処理は実行結果を捨てる設定で動いていたので、失敗しても何も残らず、誰にも知らされなかった
• 巻き添えで、求人を検索エンジンに知らせる処理も止まっていた

原因そのものは設定の問題でした。でも、6週間も続いた理由は「気づく」段階が無かったことです。この件のあと、定期処理が失敗したら通知が届くようにし、さらに「作られるはずのものが2日以上古ければ知らせる」見張りも足しました。

この講座の進め方

• 第2回 … 影響を確かめて報告する
• 第3〜4回 … ログの置き場所と読み方
• 第5回 … エラー追跡ツールの読み方
• 第6回 … 原因の切り分け
• 第7回 … 一時対応（止血）
• 第8回 … 恒久対応と記録

• 保守運用と障害の意味
• 障害対応の6つの段階
• 段階を飛ばすと後から困ること
• 定期処理が6週間止まっていた実例