プロバイダーがダウンしたとき
最終更新:
プロバイダーのステータスページとは、クラウド、ホスティング、コード、決済のプロバイダーが自社の健全性を宣言するために維持する公開ダッシュボードです。1つの全体インジケーター、コンポーネントのリスト、そしてインシデントがまだ進行している間にプロバイダー自身が書くインシデントのタイムラインがあります。それをよく読むことは運用者の技能です。見出しは要約であり、真実はその下にあるからです——どのコンポーネントが影響を受けているか、どの地域で、宣言された影響はどれほどか、インシデントがプロバイダー自身のワークフローでどこまで進んでいるか。本記事はその読み方を教え、あなたが依存するプロバイダーが問題になったときの最初の10分にすべきことで締めくくります。プロバイダーステータスボードから始めてください。主要プロバイダーのページを1つのスナップショットに集めています。そしてダウンしているのか、それともあなただけか？という問いを全体を通して心に留めてください。2つのツールは同じ疑念の反対の半分に答えます。
2つの異なるもの：インジケーターとインシデント状態
成熟したステータスページはどれも、読者が絶えず混同する2つの別々のシグナルを備えています。1つ目は全体インジケーターです。サービス全体の1つの要約状態で、ページの背後にある機械可読フィードでは通常 none、minor、major、critical、maintenance のいずれかです——Statuspage開発者ドキュメントに記録されたモデルで、大半の大規模プロバイダーは直接使うか、密接に模倣しています。インジケーターは意図的に粗いものです。忙しい読者——あるいは当社のステータスボードのような機械——が「あちらで何か問題があるか？」に1秒で答えられるように存在し、最も影響を受けたコンポーネント、プロバイダー自身の判断、または両方から算出されます。
2つ目のシグナルはインシデント自体であり、インジケーターが平らにしてしまう独自のライフサイクルを持っています。インシデントは、名前、宣言された影響、ワークフローから取られた状態とともに開かれます。調査中（症状は見えるが原因はまだわからない）、特定済み（原因がわかり、対処中）、監視中（修正が出て、保持されるか観察中）、解決済み（終わったと考えられる。ポストモーテムを条件とする）。これらの状態はインジケーターが運べない情報を運びます。監視中に2時間いる重大インシデントは通常終わりかけです。4分前に調査に入った minor インシデントは、これから何にでもなりえます。
両方を、その順序で読み、その間の更新を読んでください。インシデントの下にある短い更新のタイムラインこそ、プロバイダーが見出しでは決して言わないことを伝える場所です。どのサブシステムが失敗したか、どんな回避策があるか、影響を受けているのはデータか可用性だけか、次の更新が20分後か2時間後か。更新が来なくなるインシデント自体がシグナルです——チームが圧倒されていて、より長い障害と相関するか、インシデントが静かにより大きなものに畳み込まれたか。見出しを撮影して読むのをやめる運用者は、日常的にページで最も情報の少ない文に基づいて行動しています。
「すべてのシステムが正常稼働中」が、あなたのダウンを意味しうる理由
インジケーターはサービス全体を要約し、現代のサービスは1つのものではありません。プロバイダーはグローバルに誠実に緑でありながら、あなたがデプロイする地域、あなたが呼び出す唯一の製品画面、固定されているレガシーAPIバージョン、デプロイに必要なコントロールプレーンが、それに触れるすべての顧客に対して失敗していることがあります。コンポーネントリストはまさにこのために存在します。GitHubのステータスページのようなページは、サービスを Git操作、APIリクエスト、Actions、Pages などに分解し、そのいずれもが、全体のバナーが安心させるままでいる間に劣化していることがあり——逆に、あなたが使ったことのないコンポーネントのためにバナーが赤くなることもあります。
さらに静かなギャップが3つあります。第1に、宣言の遅れです。プロバイダーはインシデントを確認したときに宣言するのであって、最初のエラーが発生したときではありません。そのため、多くの障害の最初の数分は、緑のページと燃え上がるソーシャルフィードを示します。ページは嘘をついているのではなく、遅れているだけです。第2に、しきい値です。プロバイダーは、ある階層の2パーセントのエラー率を通常の背景として扱い、何も宣言しないことがありますが、その2パーセントはちょうどあなたのトラフィックパターンに集中しています。第3に、範囲です。ステータスページは、回線のプロバイダー側を記述します。ユーザーと健全なプロバイダーの間の DNS障害、ルーティングの問題、ブロックされた経路は、緑のインジケーターの下であなたに完全な障害をもたらします——だからこそ、仲間の問い「ダウンしているのか、それともあなただけか」は、プロバイダー自身のページからではなく、独立した観測点から答えなければなりません。
実務のルールは、緑を「宣言されたインシデントなし」として扱い、決して「健康が証明された」とは扱わないことです。自社の監視がユーザーの失敗を告げ、プロバイダーが正常稼働を言っているときは、ユーザーに関しては自社の監視を信じ、ステータスページは別の仕事に使ってください。後で宣言が現れるかどうかを確認すること（それは原因を遡及的に確認します）、そしてあなたが依存するコンポーネントに、あなたが今経験しているものと同じ形のインシデントの履歴があるかどうかを確認することです。
ページではなく、コンポーネントを購読する
ほとんどの運用者は、ステータスページをニュースレターを購読するように購読します。1つの購読、すべてのインシデント、永遠に——そして予測どおり、メールを無視し始めます。大規模プロバイダーのグローバルフィードは、使わないコンポーネント、サービスしない地域のインシデントを絶えず垂れ流すからです。アラート疲労は性格の欠陥ではありません。範囲の悪いシグナルに対する正しい反応です。修正は機械的で、ほぼすべての成熟したステータスページで利用できます。コンポーネントレベルで購読することです。インジケーターを定義する同じ Statuspage モデルは、購読者がコンポーネントでフィルターすることも可能にし、独自システムを運用するプロバイダー、例えばCloudflareのステータスページも、独自の購読フローで同じ選択肢を提供します。
各購読の範囲を、午前3時に実際にあなたの行動を変えるものに絞ってください。本番トラフィックが呼び出すコンポーネントは、大きな音のチャンネルに属します——ページングし、メッセージを送り、少なくとも数分以内に目にする何かにバッジを付けるチャンネルです。ビルド、分析、内部ツールだけに使うコンポーネントは、勤務時間に確認する静かなチャンネルに属します。使わないコンポーネントはどこにも属しません。正しく無視した通知のたびに、次の通知を無視しやすくなり、重要な通知も含みます。スタックが変わるたびにリストを見直してください。購読は両方向に腐敗するからです——誰も購読していない新しい依存関係と、誰も見ていないチャンネルをまだページングしている死んだ依存関係です。
可能な場合は機械可読フィードを優先してください。メールはステータスページが提供する最も遅く、最も無視しやすいチャンネルです。webhook とフィードは、独自のダッシュボードを駆動し、内部チケットを開き、最初のユーザー苦情が届く前にサポートチームの用意した保留ページを切り替えることができます。軽量な版でも見返りがあります。当社のプロバイダーステータスボードのスナップショットは、まさにこれらの公開フィードから構築されており、データが、開くことを覚えておかなければならないブラウザータブで鑑賞するためではなく、プログラム的に消費するためにそこにあることの証拠です。
独自の依存関係インベントリを作る
リストがなければ、上記の助言はどれも機能せず、ほとんどのチームは障害の最中に、自分たちにリストがないことに気づきます。依存関係インベントリとは、些細に聞こえてそうではない問いへの書面による答えにすぎません。今夜止まったら私たちを止める外部サービスはどれか——そして、単に恥をかかせるだけのものはどれか？ 穏やかな天気のうちに作ってください。アーキテクチャを面ごとに歩きます——ホスティング、DNS、コードホスティングと CI、データベースとストレージのプロバイダー、決済処理業者、メールと SMS の送信者、IDプロバイダー、エラートラッカー、分析タグ、他社の CDN からページが読み込むフォントとスクリプト——そして、それぞれについて、プロバイダー、実際に消費するコンポーネント、そのステータスページの場所、それが失敗したときにユーザーが経験することを書き留めます。
各項目は、ベンダーをどれだけ好きかではなく、その失敗の形でランク付けしてください。依存関係の中には硬いものがあります。止まればあなたも止まり、できる仕事はコミュニケーションと待機だけです。柔らかいものもあります。それらなしでもサイトは動きますが劣化します——分析なし、チャットウィジェットなし、パーソナライズなし——そして、それらについては、誰がオフにでき、どうオフにするかをインベントリに記すべきです。そして、隠れたものがあります。あなたが選んでいない推移的な依存関係です。例えば、SaaSデータベース自体が動いているクラウド地域の状態、あるいはすべての下にある証明書と DNS のインフラです。隠れた依存関係は、「すべてダウンしているのに、私たちがお金を払っているものは1つもリストにない」という障害を生み出すものであり、各ベンダーに一度、彼らが何に依存しているかを尋ねることで見つけられます。
インベントリは、インシデントが手の届く場所に保管してください。ランブックの中、エスカレーションリストの隣です。IDプロバイダーこそがダウンしているものだというときに誰も開けない wikiページではありません。1ページで十分です。障害の際のその仕事は、「何かがおかしい」をチェックリストに変えることです——硬い依存関係ごとに、30秒で、上か下か——そして、その後の仕事は修正されることです。本当のインシデントはどれも、あなたがランクを誤った依存関係について何かを教えるからです。決して修正されないインベントリは、運用文書ではなく歴史文書です。
プロバイダー障害の最初の10分
0分から2分：確認して、場所を特定する。自社の監視をチェックして、障害が本物であり、あなたが宣言すべきものか確かめ、次にステータスボードと容疑のあるプロバイダーのページを開きます。答えている問いは1つです。あなたが使うもの——コンポーネント、地域、製品——と重なる、宣言されたインシデントはあるか？ あれば、原因と最初のメッセージが手に入ります。なければ、確認を広げます。インベントリの別のプロバイダー、あなた自身の直近のデプロイ、あなたの DNS です。偽のドラマのほとんどはこの2分で死に、本物のほとんどはここで形を取ります。
2分から5分：率直に、早く伝える。ユーザーが実際に読むチャンネルで、名前を挙げた上流のプロバイダーにインシデントが発生していること、それが実際的に何を意味するか——何が動かず、何がまだ動き、データは安全か——そして、次にいつ更新するかを伝えます。4分目に送られた正直な保留メッセージは、40分目に送られた正確な説明に勝ります。沈黙は、ユーザーが最悪の推測と競合他社の名前で埋めるものだからです。内部では、1つのインシデントスレッドを開き、発言者を1人指名し、すべてにタイムスタンプを付けます。ポストモーテムで自分に感謝するでしょうし、プロバイダーのサポートチームも、彼らが必要になったときに感謝するでしょう。
5分から10分：悪化させるのをやめ、柔らかい着地を用意する。デプロイを凍結します——進行中の上流インシデントの中で行われた変更は評価できず、ロールバックすらできないかもしれません。失敗しているプロバイダーを叩く積極的な再試行と、必須でないジョブを止めます。1万のクライアントが歩調を合わせて再試行すると、回復は測定できるほど遅くなり、一部のプロバイダーはあなたをレート制限で、自ら招いた2番目の障害に陥らせます。インベントリで切り捨て可能と印を付けた柔らかい依存関係をオフにするか劣化させ、保留ページがあれば掲示し、そして、インシデントが決めるリズムに落ち着きます。プロバイダーの更新を監視し、ニュースがあってもなくても約束した時刻にユーザーへ更新を伝え、事実が変わらない限り他には何も変えません。障害はプロバイダーのスケジュールで終わり、あなたのスケジュールでは終わりません。あなたの10分は、ユーザーがそれを、彼らのプロバイダーの悪い日として記憶するか、あなたの悪い日として記憶するかを決めます。