私のサーバーがダウンして5時間後に偶然気づいた

通知は監視サービスから来ませんでした。自動アラートやSlackに火入れするウェブフックからも来ませんでした。想像できる最も原始的な監視システムから来ました：ブラウザを開き、URLを入力し、空白のページを見つめることです。それは火曜日の午後でした。サイトは朝9時頃からダウンしていて、午後2時を過ぎていました。通常は1日数千のリクエストを処理するウェブアプリケーションからの5時間の完全な沈黙。5時間の間、すべての訪問者がエラーページを見て、すべてのAPI呼び出しが何も返さず、すべてのスケジュール済みタスクがバックグラウンドで静かに失敗しました。サーバーは劇的にクラッシュしませんでした。カーネルパニックもなく、ディスク障害もなく、法医学的証拠を残す攻撃ベクトルもありませんでした。Contabo VPSは単にHTTPリクエストへの応答を停止し、有効なIPアドレスとネットワークレイヤーでのハートビートを持ちながら、ウェブトラフィックを提供することを拒否していました。

発見は完全に関係のないタスクのために起こりました。デザイン変更の特定のページレイアウトをチェックする必要があったため、ブラウザはURLに移動して何も返されませんでした。最初の本能はローカルネットワークのせいにすることでした。ページを更新しました。まだ何もありません。別のブラウザを試しました。まだ何もありません。ターミナルを開いてサーバーをピングしました。パケットは正常に返されました。SSH接続？うまくいってます。Apacheステータス？死んでいます。ウェブサーバープロセスは早朝のある時点でクラッシュし、その正確な障害モードを処理するプロセススーパーバイザーが構成されていなかったため、再起動されませんでした。修正は30秒かかりました。これが再び起こる可能性があり、おそらく誰も気づかずに前に起こっていた可能性があるという認識は、かなり長くかかりました。

VPSで本番サービスを実行したすべての開発者は、このストーリーのバージョンを持っています。それは5時間ではなかったかもしれません。2時間、8時間、または満杯の週末だったかもしれません。詳細は異なりますが、パターンは同じです。サーバーはダウンし、誰も気づかず、発見は偶然でした。根本的な問題はサーバーの信頼性ではありません。サーバーは失敗し、プロセスがクラッシュし、ディスクが満杯になり、メモリリークが蓄積します。これは物理ハードウェアでソフトウェアを実行する性質です。根本的な問題は監視の欠如であり、より具体的には、サーバーがオンラインであることを知ることと、アプリケーションが実際に機能していることを知ることの間のギャップです。

アップタイム監視と実際のサイト機能を知ることの違い

従来のアップタイムモニターは1つのことをよくやります。彼らは定期的にHTTPリクエストをURLに送信し、応答コードが200であるかどうかを確認します。コードが他のものである場合、またはリクエストがタイムアウトした場合、アラートが発火します。これは最も壊滅的な失敗をキャッチします：サーバーは完全に到達できず、ドメインが期限切れになり、SSLサーティフィケートが無効です。しかし、それはおそらくより一般的でより損傷していそうな問題の巨大なカテゴリーを逃します。

サーバーが200ステータスコードを返すシナリオを考えてください。ページが壊れています。データベース接続が失敗したため、コンテンツ領域は予想される製品リストの代わりにエラーメッセージを表示します。CSSファイルの読み込みに失敗したため、ページはスタイルなしHTMLとしてレンダリングされます。JavaScriptエラーがメインアプリケーションの初期化を防ぎ、ユーザーを決して解決しない読み込みスピナーで見つめさせます。第三者ウィジェットは、ページコンテンツ全体をカバーするオーバーレイを挿入します。これらすべてのケースで、アップタイムモニターは200応答を受け取ったため、すべてが健康であると報告します。サーバーは起動しています。サイトが壊れています。誰も知りません。

「サーバーが応答する」と「サイトが機能する」の間のこのギャップは、スクリーンショット監視が本質的になるところです。スケジュール済みスクリーンショットは、ページが定期的に実際にどのように見えるかを捉えています。ページが突然エラーメッセージ、壊れたレイアウト、または空白の白い画面を表示する場合、スクリーンショットはそれを即座に表示します。スケジュール済みスクリーンショットをピクセルディフ比較と組み合わせると、システムはページが予想外の方法で変更された場合を自動的に検出できます。コンテンツ更新のためにいくつかのピクセルがシフトしているのは正常です。ページ全体が白くなるか、エラースタックトレースを表示することは、ディフアルゴリズムが構成可能な感度しきい値で2つを区別することができます。

5時間のアウタージの後、最初に設定されたのは、すべてのクリティカルサービスのアップタイムモニターでした。しかし、より興味深い追加は、15分ごとにキー頁の実際の視覚的な状態をキャプチャするスケジュール済みスクリーンショット監視でした。アップタイムモニターは明白なクラッシュをキャッチします。スクリーンショットモニターはすべてをキャッチします：200ステータスコードを返しながら壊れたページを表示する微妙な失敗、予期しないコンテンツを挿入する第三者スクリプト、特定の条件下にのみ表示されるデータベースエラー。

最初から存在すべきアラートパイプラインの構築

適切な監視システムのアーキテクチャは理論上、複雑ではありません。スケジューラーは定義された間隔でチェックをトリガーします。チェックはターゲットの現在の状態をキャプチャします。状態は予想されるベースラインと比較されます。比較がしきい値を超える場合、アラートが発火します。チャレンジはアーキテクチャではなく、各コンポーネントの信頼性にあります。それ自体がダウンしている監視システムは、監視がないよりも悪いです。これは虚偽のセキュリティ感を生じさせるからです。

スクリーンショット監視パイプラインはステージで機能します。スケジューラーは、ページの重要度に応じて、通常5分、10分、または15分の間隔でキャプチャジョブをディスパッチします。キャプチャジョブはヘッドレスChromiumインスタンスを実行して、ページを読み込み、レンダリングが完了するまで待機し、結果のスクリーンショットを保存します。新しいスクリーンショットは、変更された地域を特定し、変更の総パーセンテージを計算するピクセルディフアルゴリズムを使用して、以前のキャプチャと比較されます。変更が構成されたしきい値を超える場合、通知は構成されたチャネルを介してディスパッチされます：メール、ウェブフック、Slack、またはカスタムエンドポイント。

ディフ比較は、技術的観点から本当に興味深いことになるところです。素朴なピクセル比較は、タイムスタンプ、広告、またはアニメーション要素などの動的コンテンツのために、すべてのスクリーンショットを変更されたとしてフラグを立てます。ディフエンジンは、除外ゾーン、比較前にマスクされるページの矩形領域をサポートすることによってこれを説明します。ヘッダーのタイムスタンプ、回転バナー広告、コーナーのライブチャットウィジェット：これらはすべて除外できるため、意味のある変更のみがアラートをトリガーします。除外後に残るのは安定したコンテンツ領域であり、そこでの変更はほぼ確実に調査する価値があります。

5時間のアウタージは、このシステムの下でも数分以内にキャッチされていたでしょう。サーバーがダウン後の最初のスケジュール済みスクリーンショットは、空白の画像またはエラーページのいずれかを返していたでしょう。どちらもベースラインから劇的に異なっていたでしょう。ディフパーセンテージはほぼ100％に近く、合理的なしきい値を遥かに超えていたでしょう。そしてアラートはすぐに発火していたでしょう。5時間のダウンタイムは5分間のダウンタイムになっていたでしょう。そして、それらの5分間は、人間が問題に偶然つまずくのにかかった時間ではなく、監視間隔そのものでした。

5時間の目に見えないダウンタイムが実際にコストするもの

5時間のダウンタイムの直接的なコストは、数字が利用可能なときに計算するのは簡単です。1日数千のリクエストを処理するサイトの場合、5時間は日常のトラフィックの重要なスライスを表しています。エラーを返したすべてのリクエストは、彼らが来たもの、つまり何も得なかった。何人かのユーザーは、二度と戻ってこない新しい訪問者でした。何人かは、わずかな信頼を失うであろう既存のユーザーでした。一部はAPI消費者であり、その依存関係のため、彼ら自身のアプリケーションは失敗しました。直接的な収益の影響は、サイトの性質に依存しますが、小さなSaaS申請であっても、営業時間中の5時間のダウンタイムは簡単に数百ドルの失われたコンバージョンを表すことができます。

隠されたコストは定量化するのは難しいですが、おそらく大きいです。それらの5時間の間にサイトをクロールした検索エンジンはエラー応答を受け取りました。簡単なアウタージはGoogleのクローリングインフラストラクチャによって一般的に許容されていますが、拡張ダウンタイムは影響されたページの一時的なディインデックスになる可能性があります。アウタージ中に実行されていたメールキャンペーンは、死んだエンドポイントにトラフィックを駆動し、キャンペーン全体の支出を無駄にしました。ウェブアプリケーションに依存するスケジュール済みタスク、ウェブフック配信、レポート生成、バッチ処理などのものはすべて静かに失敗し、サーバーが復元された後に手動で識別して再実行する必要がありました。

最も不安な費用は名声のあるものです。ダウンしたサイトに遭遇するユーザーは、通常、「あなたのサイトが落ちている」というメールを送信しません。彼らは単に去り、戻ってくるかもしれません。ダウンタイムのためのフィードバックメカニズムはありません。なぜなら、フィードバックメカニズム自体が落ちているからです。5時間のウィンドウは、一部のユーザーがサイトを試し、それを壊す、そして競合他社に移動するのに十分な長さであり、何が起こったかを示すであろう単一のデータポイントを生成することなく移動した。彼らは単に去り、誰が何人が多いのか知る方法はありません。

反応的から積極的へ、二度と偶然で気づくことがない

火曜日の午後からの教訓は、サーバーがクラッシュすることではありませんでした。それはすでに知られていました。教訓は、障害とその発見の間のすべての分が複雑な損傷の分であり、そのウィンドウを最小化する唯一の方法は検出を自動化することです。人間の監視は拡張しません。サイトを手動で1日1回チェックすることは、平均検出時間が12時間であることを意味します。1時間に1回チェックすることで、それを30分まで持ってきますが、人間が毎時間毎時間毎時間確認することができます。

アップタイム監視と視覚的スクリーンショット監視の組み合わせは、問題の両方のレイヤーをカバーしています。アップタイムモニターは、サーバーが完全にオフラインになることをキャッチします。スクリーンショットモニターは、サーバーが起動したままでアプリケーションが壊れることをキャッチします。一緒に、彼らは検出ウィンドウを「誰かが気づくことに」から監視間隔に減らします。これは重要なサービスのために1分と同じくらい短くすることができます。アラートが発火し、通知が到着し、修正は数時間ではなく数分以内に始まります。

その元のインシデント以来、サーバーはさらに2回ダウンしました。両方の時間、アラートは3分以内に到着しました。両方の時間、修正は重大なトラフィックが失われる前に適用されました。監視インフラストラクチャは、それが最初に捕まったインシデント自体で支払いました。そしてそれ以降のすべてが純粋な上昇です。偶然に発見される見出しの時代は終わり、振り返ると、唯一の本当の質問は、5時間の投資を明らかにするのに5時間のアウタージがかかったなぜ？