Salesforceの「Trust Status」は、同社サービスの稼働状況や障害情報を確認するための公式ページだ。ところが今回元記事として参照されたページには、実質的な内容がほとんど表示されておらず、「JavaScript を有効にしないとこのアプリを実行できない」とだけ書かれていた。つまり、障害情報そのものではなく、その情報を載せるはずの状態監視ページが、閲覧環境によっては空っぽに見えてしまう、という話になる。クラウドサービスの信頼性を語るうえで、こうした“見え方”はかなり重要だと思う。
元記事の本文として抽出できた内容は非常に短く、ページの見出しである「Trust Status」に続いて、「You need to enable JavaScript to run this app.」という文言が出ているだけだった。これは、ブラウザ側で JavaScript を有効にしていないと、このページが正しく動かないことを示す案内だ。逆に言えば、少なくとも抽出された範囲では、障害件数や稼働率、復旧予定時間、地域別の影響といった、通常のステータスページに期待する情報は表示されていない。
Salesforce の Trust Status は、ユーザーが自分でサービス障害の有無を確かめるための窓口だと考えるとわかりやすい。メールやチャット、CRM、基幹連携など、業務の中心に Salesforce を置いている企業では、何か不具合が起きたときに、まずこのページを開いて状況を確認することが多い。ところが今回の表示では、その確認作業の入口自体が成立していない。ページを開いても、実際にはアプリの初期化に必要な JavaScript が動かなければ中身が出ない、という構造だけが露出している。
元記事の情報から読み取れるのは、少なくともこのページが単なる静的HTMLではなく、JavaScript に依存したアプリとして実装されていることだ。一般的な考え方として、こうした構成はインタラクティブな表示やリアルタイム更新に向いている。一方で、読み込みに失敗したときは、ユーザーの目に入るのが案内文だけになる。今回まさにその状態で、Trust Status という名前に反して、信頼状況を伝えるべき画面が何も伝えられていないように見える。
まず引っかかるのは、ステータスページが JavaScript 前提だったこと自体だ。もちろん、現代のWebサービスでは珍しくない。ただ、障害情報を伝えるページは、通常のサービス画面よりもずっと単純であるべきだと思う。利用者が知りたいのは「今落ちているのか」「どこが影響を受けているのか」「復旧見込みはあるのか」の3点で、派手なUIは要らない。だからこそ、重いフロントエンドや複雑な依存に乗せると、肝心なときに見えなくなるリスクが増す。
しかも障害時には、普通の利用環境ではない状況が起きやすい。社内ネットワークの制限、セキュリティ設定、古い端末、広告ブロッカーやスクリプト制御の拡張機能など、JavaScript の読み込みを邪魔する要因はいくらでもある。そういうとき、ステータスページが最低限の静的HTMLで「現在の状況」を返してくれれば、それだけで安心材料になる。今回の表示は、その逆を見せてしまった。情報を届けるためのページが、情報にたどり着けない入り口になっている。
もう一つ気になったのは、ページ名が「Trust Status」だという点だ。単なる「Status」ではなく「Trust」と付いている以上、そこには稼働状況の開示だけでなく、透明性や説明責任まで含めた印象がある。だから利用者は、障害が起きたときにここへ行けば、少なくとも事実確認ができるはずだと期待する。ところが実際に出たのが JavaScript 有効化の案内だけなら、その期待との落差は大きい。
この落差は、表面的には小さな技術的都合に見えるかもしれない。でも利用者側からすると、「この会社は障害情報を見せる仕組みを本当に運用できているのか」という印象に変わる。特にエンタープライズ向けサービスでは、機能そのものの品質と同じくらい、障害時の説明のわかりやすさが信用につながる。実際の障害があったかどうか以前に、情報開示の窓口が見えないのは、あまり良いサインではないと思う。
こうしたページの不具合は、エンジニアだけの問題に見えて、実は業務部門により強く響くはずだ。開発者ならコンソールを見たり別の回線で試したりできるが、現場の担当者はまず「今も障害が続いているのか」を知りたい。営業、サポート、管理部門の人たちは、原因究明より先に社内説明や顧客連絡を抱えていることが多い。そのときにステータスページが読めないと、判断材料が一つ減るだけでなく、説明の材料まで失う。
だから私は、ステータスページは“最悪の条件でも最低限読めること”が重要だと思う。アプリとして作り込むこと自体は悪くないが、入り口に静的な逃げ道を残しておくべきだ。たとえば、ページ上部に現在の状態だけはHTMLで出しておき、詳細や履歴だけを JavaScript で補う設計なら、かなり違う。今回の表示は、その逆で、全部をアプリに寄せた結果、入口の可用性まで依存してしまっているように見える。障害を知らせるページが障害に弱いのでは、本末転倒だ。
最後に、この件は Salesforce だけの話として片付けるより、SaaS 全体の設計思想の問題として見たほうが面白いと思う。クラウド製品は、機能の豊富さだけでなく、止まったときにどう振る舞うかで評価が決まる。サービス本体が止まるのはまだしも、状態を知らせるページまで見えなくなると、利用者は復旧を待つ時間にさらに不安を抱える。情報がない時間は、障害そのものを長く感じさせるからだ。
この手のページは、普段は目立たない。だが障害が起きた瞬間に、会社の姿勢が一番はっきり出る。派手な告知よりも、まず現状がすぐ読めること。あたりまえだが、実際にはそこが一番難しいのだと思う。Trust Status という名前を掲げるなら、信頼はサービスの中身だけでなく、こういう“見える設計”でも支えるべきではないか。私はそう見た。
参考: Trust Status
