インシデント対応のベストプラクティス：ソロdevが実装する監視の最小構成
要約
ソロdevがユーザーより先に障害を知るための最小構成。アラート・ランブック・ステータスページの3要素を週末1日で実装できる。エンタープライズツールは不要。自分のプロダクトを守る具体的な手順を解説。
インシデント対応のベストプラクティスは、エンタープライズチーム向けに書かれている。プロダクトをshipして、ユーザーが増えて、ある朝「3時間もダウンしてたよ」というツイートを見つける。自分では気づいていなかった。アラートなし。ランブックなし。ステータスページなし。
ソロ開発者の90%が経験する障害の本質はここにある。セキュリティ侵害でも壊滅的なインフラ障害でもなく、「ユーザーが先に気づいて、自分は後から知る」という状況だ。
必要なのは40ページのプレイブックでも、エンタープライズツールスタックでもない。3つだけ：壊れたことを知ること、何をすべきかわかること、関係者にステータスを伝えること。このガイドでは、ソロbuilder視点からそれぞれの実装方法を、自作する部分と既存ツールを活用する部分に分けて解説する。
ソロon-callで最初に壊れるもの
初めてのインシデントでは、実際に修正する前の12分間を「どこに何があるか」の確認に費やすことになる。
それが本当のコストだ。ダウンタイムそのものじゃない。何も記録していない一人チームのコーディネーションオーバーヘッドだ。環境変数はどこにある？どのサービスが実際に落ちている？全ユーザーに影響しているのか、特定の顧客だけか？インシデントの黄金の時間を、事前に答えておくべき質問の探索に費やすことになる。
解決策は複雑なツールじゃない。午前3時より前にその質問に答えておくことだ。
有用なテスト：今すぐ本番APIが落ちたとする。10分ある。すでに開いている2つのタブ以外を開かずに、関連ログを見つけ、障害コンポーネントを特定し、ロールバックまたはホットフィックスできるか？答えがノーなら、それがまさにインシデント対応が解決する問題だ。
インディー開発者のインシデント対応に本当に必要な3つのこと
構築前に、システムが何をすべきかを明確にしよう：
問題の検知：ユーザーにDMされる前に
対応手順の把握：半分眠った状態でも、アラートのコンテキストだけで何をすべきかわかる
ユーザーへの情報提供：状況を悪化させずに何が起きているかを伝える
PagerDutyから自作cronジョブまで、すべてのインシデント対応ツールはこの3つのうちのひとつにマッピングされる。3つすべてをカバーする最もシンプルなバージョンを作ったら、そこで止める。
誘惑はエンタープライズ版に向かうことだ：on-callスケジュール、エスカレーションポリシー、P0からP5の重大度レベル、ポストモーテムテンプレート。20人のエンジニアと50万ユーザーには適切だ。1人のdevと500ユーザーなら、その抽象化は週末を消費して使われないまま終わる。最小バージョンは今週末に実装できる。まずそれをshipしよう。
アラート層の構築：フォールスポジティブ問題を先に解決する
自前でアラートを構築したことがあるdevなら、みんな同じ経験をしている：最初に書いたルールが間違っていて、2週間でノイズに耐えられなくなってページャーを切った。
まず1つ、本当に重要なチェックから始めよう。ヘルスチェックエンドポイントが落ちていれば十分だ。
# シンプルなヘルスチェックエンドポイント (Express/Node)
app.get('/health', (req, res) => {
res.json({ status: 'ok', timestamp: Date.now() });
});次に、60秒ごとにpingするcronジョブを組む。3回連続で失敗したら、テキストが来る。これが最初のアラート層だ。ユーザーに影響するインシデントの80%をキャッチできる。
このセットアップのフォールスポジティブ率はほぼゼロだ。キャリブレーションされていない閾値に引っかかったCPUスパイクではなく、サービスが実際に落ちているときだけページングされる。アラートで最も難しいのは、これだ：アラートは常に正しくなければならない。そうでなければ、自分がアラートを無視する習慣をつけることになる。
ログベースのアラートは、アップタイムチェックが機能して信頼できるようになってから追加する。セルフホスト環境では、Grafanaが低コストでうまく機能する。Datadogは複数のサービスを管理していて、デプロイパイプラインと統合された統一ビューが欲しい場合に意味を持ち始める。
ランブックは午後11時に書いて午前3時に読むドキュメント
ランブックはドキュメントじゃない。ドキュメントはものの仕組みを説明する。ランブックは、ストレスを抱えてほぼ眠れていない状態のあなたに、今すぐ何をすべきかを正確に伝えるものだ。
ソロプロジェクトで機能するフォーマット：
何が壊れているか？ 1文、観察可能な症状のみ
緊急か？ 今まさに有料ユーザーに影響しているか？
何をすべきか？ 3〜5つの番号付きステップ、最も速く試せることから始める
それだけだ。インシデントが起きていないときに書く。インシデントの後に見直して、実際に役立ったかを確認する。
ランブックをどこに保管するかは、書く習慣そのものより重要じゃない。Notionのページ、リポジトリのMarkdownファイル、共有ドキュメント。テスト：午前3時、半分眠った状態で、スマートフォンから30秒以内に開けるか？
Notionがリポジトリファイルより便利な実用的な理由：モバイルアクセスだ。デプロイしたばかりのコードが心配で、スマートフォンのそばで眠っているなら、それは重要な違いになる。GitBookはパブリックな開発者ドキュメントとしても機能する、より構造化された選択肢でもある。
パブリックステータスページ：障害時にユーザーが本当に求めること
ユーザーがリアルタイムの可観測性ダッシュボードを必要としているわけじゃない。知りたいのは2つ：全員に影響しているのか、あなたは把握しているのか？
最小限のステータスページに必要な3要素：
ステータスインジケーター（最大3状態：正常・低下・停止）
現在の状態が最後に更新された時刻のタイムスタンプ
何かが壊れているときの平易な1行テキスト
インシデント中にステータスページを確認するユーザーはアーキテクチャ図を読んでいない。自分のセットアップのトラブルシューティングをやめてよい理由を求めている。自分のせいじゃないとわかれば十分だ。
構築に要するのは4時間未満：
エンドポイントからステータスを取得するJavaScriptスニペット付きの静的HTMLページ
2つのフィールドを持つSupabaseテーブル：status (enum) と message (text)
ヘルスチェック結果に基づいてステータスを更新するcronジョブ
手動メッセージを書き込むための認証付き管理エンドポイント
難しいのは構築じゃない。インシデント中に修正に飛び込む前にステータスを更新する習慣だ。その更新に30秒かかる。15通のカスタマーサポートメールが来なくなる。
自作するもう一つの理由：商用ステータスページツールは、本質的にはJSONエンドポイントと静的HTMLページのために月$30〜$100を請求する。一度構築すれば、自分のものだ。ユーザーにはStatuspage.ioは不要だ。メインドメインが落ちても動くURLが必要なだけだ。
自分だけを責められるポストモーテム
エンタープライズでのポストモーテムは、個人を責めないことと、組織的な失敗を特定することに関するものだ。ソロの場合、あなたがシステムだ。心理的な違いはあるが、実践は依然として重要だ。
一人でポストモーテムを書く理由：書かなければ、同じクラスの問題を2回解くことになる。3ヶ月後、インデックスを追加しなかったために発生したデータベースクエリのロックを見て、以前に同じようなことを修正した記憶がぼんやりあるが、何をしたかは覚えていない、という状況に陥る。
5分でできるフォーマット：
何が起きたか（1段落、事実のみ、責任追及の言葉なし）
どう修正したか
システムの中で変えるべき1つのこと
プロセスの中で変えるべき1つのこと
ランブックと同じ場所に書く。次のランブック更新への入力になる。6ヶ月続けると、ソロbuilderのためのどんなエンタープライズポストモーテムツールも再現できない、自分のシステムの障害モードの軽量な記録が出来上がる。
自作するか既存ツールを組み合わせるか？
正直な答えは、現在地によって異なる。
有料ユーザーがゼロなら：全部自作しよう。ヘルスチェックcron、ステータスページ、Notionのランブック。パターンを学ぶためのプロジェクトとして最適だ。週末にshipできる。インシデント対応が本当に何を必要としているかを体験できる。後でプロダクトとして構築・販売しようと思ったとき、自分自身でその要件を検証済みだ。
アップタイムに依存する有料ユーザーが今日いるなら：まず既存ツールを使おう。Grafana Cloudの無料プランを組み込み、アップタイムモニターを設定し、今日の午後にNotionのランブックページを開く。今すぐカバレッジが必要で、3週間かけて構築している時間はない。
どのステージでも自作する価値があるもの：ステータスページ。自分のものにして、別のドメインでホストし、今週末に構築しよう。それ以外は、複雑さが正当化するまで既存の無料プランで対応できる。
どのインシデント対応ガイドも言及しない盲点
問題はツールじゃない。「アラートを設定しよう」と思ってから「実際に設定した」の間の48時間だ。
ほとんどのソロdevスタックは、1日で最初のインシデント対応層を構築するのに十分な可観測性の基本要素を既に持っている。ヘルスチェックエンドポイントはどこかに存在する。ログはどこかにある。デプロイパイプラインには何らかのエラーハンドリングがある。足りないのは、90分間の集中した接続作業だ：ヘルスチェックからアップタイムモニターへ、アップタイムモニターからSMSまたはTelegramアラートへ、3つのランブックを含む1つのNotionページ、SupabaseステータスエンドポイントのついたHTMLページ。
これはユーザーにshipするプロジェクトじゃない。自分自身にshipするプロジェクトだ。
今週末に構築しよう。午前3時に何かが壊れて、40分の探索ではなく4分で修正できたとき、インシデント対応のベストプラクティスが存在する理由がわかる。エンタープライズチームが義務付けたからじゃなく、代替手段の方が悪いからだ。