顧客に本当に信頼されるステータスページの作り方
ほとんどのステータスページは存在しています。信頼されているものはわずかです。障害中に常に緑色のページは、ページがないよりも悪いです。なぜなら、顧客に見るのをやめるよう教えるからです。信頼されるステータスページには4つの特性があります。壊れているものについて正直であること、インシデントを認めるのが迅速であること、影響範囲を慎重にスコープすること、そして読者に探させることなく「これは私に影響していますか?」という質問に答えること。このガイドでは、そのようなページを設計する方法を説明します。
顧客がステータスページに本当に求めるもの
ステータスページへの訪問はすべて、2つの質問によって駆動されます。顧客は、自分が気にかけているものが壊れているかどうか、そして誰かが気付いているかどうかを知りたがっています。それ以外はすべて装飾です。
ページが一目で両方の質問に答えれば、顧客はそのページを信頼し、サポートに電話するのをやめます。どちらにも答えなければ、すべてのインシデントは5つの追加のサポートチケットを生成し、信頼性をゆっくりと失います。視覚的なデザインは、ファーストビューに表示されるものの構造ほど重要ではありません。
信頼できるページの4つの特性
4つの特性が、有用なステータスページと見栄えだけのページを区別します。4つすべてを正しく実装すれば、実際のインシデント発生時に顧客はそのページを信頼するでしょう。
- 正直さ。何かが壊れていれば、壊れていると表示します。まだ分からない場合、ページには「調査中」と表示します。実際のインシデント中に緑色を表示することは、信頼を永久に破壊します。
- スピード。インシデントは検知から数分以内に投稿されます。実際の障害から1時間遅れるステータス更新は、マーケティングコピーとして扱われます。
- スコープの明確さ。顧客は、インシデントが自分の使っているものに影響するかどうかを数秒で判断できます。リージョン、製品エリア、深刻度の3つが、ラベル付けすべき次元です。
- 平易な言葉。更新は、受動態の企業文体ではなく、友人にインシデントを説明する時と同じ口調で書かれます。
効果的なインシデント更新
ほとんどのステータスページテンプレートは、受動的でぼかした口調をデフォルトとしています。「レイテンシ上昇の報告を調査中です」。これは責任回避として読み取れます。信頼を築くパターンはその逆です。何が壊れているかを明示し、ユーザーへの影響を明示し、対応している内容を明示します。
良い最初の更新はこう読めます。「EUリージョンの約30%の顧客でログインが失敗しています。データベースのフェイルオーバーが進行中で、ETAは10分です」。良い解決報告はこう読めます。「ログインは復旧しました。根本原因は停止したフェイルオーバースクリプトでした。これが再び静かに停止しないように、ウォッチドッグを追加しました」。どちらも短いです。どちらも影響、対応、フォローアップを明示しています。
影響範囲を正しくスコープする
単一の全体ステータスページは、複数の製品ラインやリージョンを持つようになると、間違った抽象化です。米国のみにデプロイしている顧客は、EUリージョンでレイテンシが上昇していることを気にしません。
- ページをコンポーネントごとに分割してください。API、ダッシュボード、データ取り込み、課金など。単一のグローバルインジケーターではなく、コンポーネントごとのステータスを表示します。
- 該当する場合はリージョンまたは環境の次元を追加してください。インシデント中は影響を受けるリージョンを明示的にマークします。
- ライブステータスの下に過去90日間のインシデントを表示してください。訪問者があなたを賭ける価値があるほど信頼できるか判断するためにチェックするのは、この履歴ビューです。
- 提供している場合は、RSSまたはJSONフィードを公開して、関心のある顧客が自分のツールでサブスクライブできるようにしてください。
沈黙しないスケジュールされたメンテナンス
スケジュールされたメンテナンスは、ステータスページで正しく実施するのが最も簡単で、最もスキップされる部分の1つです。48時間前にウィンドウを投稿し、何が影響を受けて何が影響を受けないかをまとめ、完了を確認するフォローアップを投稿してください。
スケジュールされたメンテナンスは、インシデント更新と同じ口調で扱ってください。ウィンドウを明示します。影響を受けるサービスを明示します。影響を明示します。クリーンなメンテナンス投稿は、サポートチケットを未然に防ぎます。曖昧なものは、十数件のチケットを生み出します。
ステータスページ自体の信頼性
ステータスページは、メインインフラストラクチャから独立した場所でホストしてください。データベース障害中にステータスページがダッシュボードと同じデータベースエラーを返す場合、ページ自体がインシデントの一部になります。別のプロバイダー、別のリージョン、または静的なCDNから読み込まれるステータスページは、実際の障害が発生したときに最初に報われる、ちょっとしたアーキテクチャ上の規律です。ほとんどのチームは、これを苦い経験から学びます。