ステータスページの作り方：コンポーネント、インシデント、稼働チェック

ステータスページは、サービスが正常に動いているかどうかを一か所でユーザーに伝えるページです。作るには、コンポーネントの一覧（Webサイト、API、決済、メール配信など）、各コンポーネントの現在の状態、時刻付きのインシデントと更新情報、過去のインシデントの履歴が必要です。購読機能があれば、利用者はわざわざ確認しなくても問題を知ることができます。ページ自体はシンプルです。重要なのは、どこで動かすかという判断です。ステータスページは、報告対象のアプリがダウンしているときにも稼働していなければならないため、報告対象と同じホスティング、データベース、デプロイの仕組みを使うべきではありません。

ステータスページの目的

障害が起きたとき、ユーザーが知りたいことは三つです。「自分だけの問題か」「運営側は把握しているか」「いつ直るのか」。ステータスページは、サポートへの問い合わせが殺到する前に、この三つにまとめて答えます。また、率直な報告付きのインシデント履歴を公開し続けることで、問題への対応姿勢が伝わり、信頼につながります。

これは変更履歴ではありません。新機能は変更履歴ページに載せ、障害やメンテナンスはこのページに載せます。

ページに必要なもの

データ

コンポーネントの状態は、通常は次の固定リストです：正常稼働中、パフォーマンス低下、一部障害、全面障害、メンテナンス中。

ページ

• 公開ステータスページ： 全体のバナー（「すべてのシステムは正常に稼働しています」、または現在の最も悪い状態）、各コンポーネントとその状態、対応中のインシデントとその更新情報、今後のメンテナンス、稼働チェックのデータがあれば過去90日分の履歴。
• インシデントページ： 1件のインシデントの更新履歴すべて。サポートがリンクできるよう、独自のURLを持たせます。
• 履歴： 過去のインシデントを月ごとに表示。
• 購読： 確認メール付きのメール登録と、コンポーネントごとの通知設定。
• 管理画面： インシデントの作成、更新の投稿、コンポーネント状態の変更、メンテナンスの予約。

権限

公開されたものは誰でも見られます。投稿できるのはチームだけです。可能であれば、管理画面のログインはアプリのログインシステムとは別にしてください。そうすれば、認証プロバイダーの障害で、自分のステータスページからも締め出される事態を避けられます。

最も重要な判断：独立させること

自作のステータスページが失敗しやすいのはここです。ステータスページが次のいずれかを共有していると、

• アプリと同じサーバーまたはホスティングアカウントで動いている
• アプリと同じデータベースを読んでいる
• アプリと同じドメイン設定やCDNの設定の下にある
• アプリと同じデプロイの仕組みで配備されている

多くの障害で一緒に落ちてしまい、人々が最も必要としているときに使えなくなります。実践的な対策は次のとおりです。

• ホスティングを分ける。 メインのアプリとは別のプロジェクトまたは別のプロバイダーを使います。
• 専用のサブドメインを持たせる。 例えば status.example.com のように、DNSで個別に設定します。ドメインとDNSの仕組みも参照してください。
• データを独立させる。 インシデントは、アプリのデータベースではなく、ステータスページ自身の保存先に置きます。
• 静的なフォールバックを用意する。 公開ページを静的にして、更新のたびに再生成するチームもあります。壊れる要素がほとんどなくなります。

手動更新か、自動チェックか

手動（まずはこちら）

チームが管理画面からインシデントを投稿し、コンポーネントの状態を手動で変更します。実際、多くのステータスページはこの方法で運用されています。「一部のカード種別で決済が遅い」といった人の判断は、自動の赤い表示よりも役に立つからです。

問題にすばやく気づくには、アプリを1分ごとほどにチェックし、メール、SMS、チャットで通知してくれる外部の稼働監視ツールを使いましょう。多くの監視サービスには無料プランがあります。

自動化

自動化とは、各コンポーネントを定期的にチェックし、状態を自動で更新する仕組みのことです。メインのアプリのインフラから離れた場所で、スケジュールに従って動くコードが必要です。よく使われるパターンは二つあります。

• 外部の監視ツールが、チェックの失敗や復旧時にWebhookを通じてステータスページを呼び出し、コンポーネントの状態を更新させる。
• ステータスページ自身のホスティング上のスケジュールジョブが、各コンポーネントにpingを送り、結果を記録する。信頼する前に、ホスティングがスケジュールタスクをどう扱うかを確認してください。選択肢については、バックグラウンドジョブの実行方法のガイドを参照してください。

自動での状態変更は、回線が遅いと、ステータスがパタパタ変わる（正常、停止、正常）ことがあります。ステータスを変える前に2〜3回連続で失敗することを条件にし、大規模な障害を発表する前には人が確認するようにしましょう。

インシデントの更新の書き方

• 早めに投稿する。 完璧な文面を1時間後に出すより、数分以内に「ログインに失敗する件を調査しています」と出す方が良いです。
• 内部の故障箇所ではなく、ユーザーが気づくことを書く。
• 次の更新時刻を約束し、それを守る。
• 解決したら短いまとめで締めくくる。 何が起き、どれくらい続き、何を変えるのかを書きます。

最初に効くプロンプトの例

メインのアプリ Parcelio 用に、独立したステータスページを作ってください。status.parcelio.com で別途ホストします。コンポーネントは Website、Tracking API、Notifications、Payments の4つで、それぞれの状態は「正常稼働中」「パフォーマンス低下」「一部障害」「全面障害」「メンテナンス中」のいずれかです。公開ページには、現在の最も悪い状態を使った全体バナー、各コンポーネントの状態、対応中のインシデントを新しい順に時刻付きの更新とともに、今後のメンテナンス、月ごとにまとめた過去のインシデント一覧を表示してください。各インシデントには専用のページを用意します。パスワードで保護された管理画面では、インシデントの作成（タイトル、影響度、影響するコンポーネント）、更新の投稿（メッセージとステータス：調査中、原因特定、監視中、解決済み）、コンポーネント状態の変更、メンテナンスの予約ができるようにしてください。外部の監視ツールから、コンポーネント名と up/down を受け取る POST /api/check-result エンドポイントも追加し、シークレットトークンで保護してください。コンポーネントは、3回連続で down を受け取った後にのみ「パフォーマンス低下」にしてください。すべてのデータはこのアプリ自身のデータベースに保存します。シンプルで落ち着いたデザインで、スマホでもすばやく読み込めるようにしてください。

構築の手順

1. 公開ページと、手動でインシデントを作る管理画面。 これだけで動くステータスページになります。
2. 別々にホストし、サブドメインを向けます。
3. インシデントのページと履歴。
4. メンテナンス時間帯。
5. 購読機能。 二重承認のメール登録と、新しいインシデントや更新時の通知。メールには送信プロバイダーが必要です。アプリからメールを送る方法を参照してください。
6. 自動でステータスを変えたい場合は、監視のWebhook。
7. 訓練を実施する。 架空のインシデントを作成し、更新を投稿し、解決し、メールを確認してから削除します。

よくある間違い

• アプリと同じ場所でホストする。 最も多く、最も深刻な間違いです。
• いつも「すべてのシステムは正常に稼働しています」と表示するページ。 問題を一度も表示しないページは、ユーザーに信頼されなくなります。
• 時刻やタイムゾーンがない。 時刻は必ずタイムゾーン付きで表示しましょう。
• 管理画面にメインアプリのログインを使う。
• 更新の間の沈黙。 「変化なし、まだ対応中です」も有効な更新です。
• 自動判定の状態がパタパタ変わる。 状態を変える前に、繰り返し失敗することを条件にしてください。

ホスト型のステータスページサービスの方が良い場合

ホスト型のステータスページサービスは、独立性の問題に対応するために作られています。別のインフラで動き、メールやSMSでの購読者通知を扱い、多くは監視やインシデント管理ツールとの連携も備えています。稼働率が顧客に提供する価値の一部である場合や、インシデントを報告する契約上の義務がある場合は、専用サービスを使う価値が高いでしょう。無料または低価格のプランを提供しているところも多いので、作る前に確認してください。

次のような場合は自作を選びましょう。デザインと文言を完全にコントロールしたい場合、必要なものが単純な場合（コンポーネントが少数で、手動更新）、または他者に提供する製品の一部としてステータスページを作る場合です。

Mythexで作る

Mythexでは、ステータスページを独立したプロジェクトとして作れます。メインのアプリとは別のホスティングと、専用のデータベースが使えます。チャットで説明し、ライブプレビューで確認してから公開し、status.yourdomain.com のようなサブドメインを接続してください（カスタムドメインはProプランの機能です）。ただし、公開されたMythexアプリとそのデータベースは、アイドル時にはスリープし、次の訪問で起動します。そのため、静かな時間の後の最初の読み込みは遅くなることがあります。軽量でシンプルなページにすると助かります。

Mythexには定期実行ジョブの機能がドキュメントされていないので、自動チェックには、ステータスページのWebhookエンドポイントを呼び出す外部の稼働監視ツールを使ってください（Webhookのレシピを参照）。購読者へのメール通知は、自分で用意したプロバイダーを通して送り、APIキーはプロジェクトのシークレットとして保存します（メール送信のレシピを参照）。

よくある質問