ステータスページの作り方

ステータスページは、インシデント中に自動で更新され、顧客が必要なときに見つけられる場合にだけ価値があります。ここでは最初から実際のモニターで動き、サポートの問い合わせを減らせるだけの人間による文脈も持ったページを作ります。

1. 1

   最初に監視すべきもの

   顧客が認識でき、別々に気にする製品の部分を列挙します。メインサイトまたはアプリ、他社が連携するAPI、独立して失敗し得るチェックアウトや請求、停止すると顧客が気づく重要なバックグラウンドサービスなどです。リストは短く意味のあるものにします。社外の誰にも分からない20個の内部ラベルより、認識しやすい3から6個のコンポーネントの方が有用です。

2. 2

   ノイズを減らすアラート

   ページ上の各コンポーネントを、それをすでにチェックしているモニターに接続します。日々サイトを監視している同じ外部チェックまたはheartbeatです。これによりページは自動で更新されます。基になるチェックが失敗するとコンポーネントは赤になり、回復すると手動操作なしで緑に戻ります。背後にモニターがないコンポーネントは、モニターを追加するか公開ページから外してください。

3. 3

   Holter の使い方

   インシデント中に実際に見つけられる場所へステータスページのリンクを置きます。サイトのフッター、ドキュメント、サポートの自動返信、オンボーディングメール、APIドキュメントがよくある場所です。技術的には公開されていても、どこからもリンクされていないステータスページはサポートチケットを減らしません。顧客との契約やSLAがあるなら、停止中に参照する場所がこのページになるようにします。

スキャンは一時点の状態です

実際のインシデント中は、原因が分かる前でも、何かがおかしいと分かった時点で短い更新を投稿します。「認識して調査中です」は沈黙より有益です。追加情報が分かったら再度更新し、修正後には解決メモを投稿します。自動のコンポーネント状態は「稼働中か停止中か」を扱います。短い人間のメモは、影響、範囲、回避策、次回更新時刻を扱います。インシデント中は両方が重要です。

次に追加するもの

ページが公開され、実際のモニターに正しく接続されたら、繰り返し質問を減らす要素を追加します。稼働履歴バッジ、RSSまたはメール購読、プレッシャー下でチームが再利用できる短いインシデントテンプレートです。基になるモニターにTLSやドメイン期限切れチェックが含まれる場合、それらを顧客向けコンポーネントにするべきか、メインサイトの状態の一部として表す方がよいかを決めます。期限切れが近い証明書は本当のリスクですが、独立した公開行が必要とは限りません。

避けるべきよくある失敗

すべての内部コンポーネントを列挙する。顧客が認識できないコンポーネントが十数個あるページは、顧客に本当に関係する3つか4つの項目だけのページより、一目で把握しにくくなります。チームが詳細な内訳を必要とするなら、内部向けビューに残します。

何にも接続しない。実際のモニターに接続されていないステータスページは、誰かが更新を思い出さなければならない静的ページにすぎません。そしてそれは、全員が最も忙しい瞬間に失敗します。真実の情報源は、すでに問題を検出しているモニターであるべきです。

公開してもどこにもリンクしない。ステップ3と同じく、サイト、ドキュメント、サポート導線からリンクされていないステータスページは、重要な瞬間に誰にも見つけられません。アラートをテストするのと同じように発見しやすさをテストしてください。顧客なら最初にどこを見るかを問いかけます。