「こちらでは問題ありません」
その言葉を、何度聞きましたか

インフラ責任者・運用責任者の皆さまへ

障害の責任分界点を、
推測ではなく実測データで示す

こんな経験はありませんか

監視の仕組みは整えてきたはずです。
それでも、障害のたびに、こんな場面に立ち会っていないでしょうか。

アラートは鳴っていない。ダッシュボードもすべて正常。
それなのに、顧客からの問い合わせで障害を知る。
監視ツールに投資してきたのに、最初のアラートは顧客の声です。

通信事業者も、CDNベンダーも、クラウド事業者も「こちらでは問題ありません」。
誰の責任なのかが決まらないまま、時間だけが過ぎていきます。

復旧はした。しかし、なぜ起きたのかを説明できない。
「外部要因と推測される」と書いて提出し、再発防止策も書けないまま終わります。

原因が特定できていないので、手を打てない。
深夜の呼び出しと、原因不明のままの報告が繰り返されます。

これらに共通しているのは、問題がサーバの外で起きている可能性です。

多くの監視ツールは、自社のシステムの内側を見るためのものです。
しかし顧客は、自社のシステムに届くまでに、いくつもの事業者のネットワークを通っています。
企業が監視している世界と、顧客が利用している世界は違います。

いつ、どこで、どのISPで、どのモバイル回線で、どの地域で、どの経路で問題が起きていたかを、実測データで示します。
事業者との切り分けを、推測ではなく記録にもとづいて進められます。

国内7都市の計測センターから、NTT/KDDIの光回線と4キャリアの回線を使って、24時間計測します。
顧客から連絡が来る前に、問題に気づけます。

計測結果は、障害報告書、ポストモーテム、役員報告の根拠として使えます。
「外部要因と推測される」ではなく、「この時刻に、この経路で、この遅延が起きていた」と書けるようになります。

SpeedData は、既存の監視ツールを置き換えるものではありません。
計測結果を Datadog や New Relic に送り、サーバ内部のデータと並べて見られます。

「原因は特定できませんでしたが、外部の要因と考えられます」
再発防止策も、追加投資の必要性も、説明の根拠がありません。

「この時刻に、この地域の、この回線で、この区間の遅延が起きていました。事業者に是正を求めています」
原因と対策、必要な投資を、事実にもとづいて説明できます。