SRE (サイト信頼性エンジニアリング) は、Web プロジェクトの可用性を確保するためのアプローチです。 これは DevOps のフレームワークとみなされ、DevOps プラクティスの適用で成功を収める方法について説明します。 この記事の翻訳 第 6 章 分散システムの監視 図書 サイト信頼性エンジニアリング Googleから。 私はこの翻訳を自分で作成し、監視プロセスを理解する上での私自身の経験に基づいて作成しました。 電報チャンネルでは @monitorim_it и Medium のブログ サービス レベルの目標に関する同書の第 4 章の翻訳へのリンクも公開しました。

猫による翻訳。 読書を楽しむ！

Google の SRE チームには、成功する監視および通知システムを作成するための基本原則とベスト プラクティスがあります。 この章では、Web ページの訪問者が遭遇する可能性のある問題と、Web ページの表示を困難にする問題の解決方法について説明します。

定義します

モニタリングに関連するトピックを議論するために使用される単一の語彙はありません。 以下の用語は Google でも一般的には使用されていませんが、最も一般的な解釈を列挙します。

監視

システムに関する定量的データのリアルタイムでの収集、処理、集計、表示: リクエストの数とリクエストの種類、エラーの数とエラーの種類、リクエストの処理時間、サーバーの稼働時間。

ホワイトボックス監視

内部システム コンポーネントによって表示されるメトリック (ログ、Java 仮想マシン プロファイリング メトリック、内部統計を生成する HTTP ハンドラー メトリックなど) に基づくモニタリング。

ブラックボックス監視

ユーザーの観点からアプリケーションの動作をテストします。

ダッシュボード

サービスの主要な健全性指標の概要を提供するインターフェイス (通常は Web)。 ダッシュボードには、フィルター、表示されるインジケーターを選択する機能などが含まれる場合があります。インターフェイスは、ユーザーにとって最も重要なインジケーターを識別するように設計されています。 ダッシュボードには、リクエストのキュー、優先度の高いエラーのリスト、特定の責任分野に割り当てられたエンジニアなど、テクニカル サポート スタッフ向けの情報も表示できます。

アラート（通知）

電子メールまたはその他の手段で個人が受信することを目的とした通知。エラーまたはリクエスト キューの増加によってトリガーされる可能性があります。 通知は、チケット、電子メール アラート、インスタント メッセンジャー メッセージに分類されます。

根本的な原因

一度修正すれば二度と発生してはいけないソフトウェアの欠陥または人為的エラー。 この問題には、不十分なプロセス自動化、ソフトウェアの欠陥、アプリケーション ロジックの不十分な精緻化など、いくつかの主な原因が考えられます。 これらの各要因が根本的な原因である可能性があるため、それぞれを除去する必要があります。

ノードとマシン (ノードとマシン)

物理サーバー、仮想マシン、またはコンテナー上で実行中のアプリケーションの単一インスタンスを指す、交換可能な用語。 XNUMX 台のマシンで複数のサービスをホストできます。 サービスには次のようなものがあります。

• 相互接続: たとえば、キャッシュ サーバーと Web サーバー。
• 単一のハードウェア上の無関係なサービス: たとえば、コード リポジトリと構成システムのウィザードなど。 人形 または シェフ.

プッシュ

ソフトウェア構成の変更。

なぜモニタリングが必要なのでしょうか?

アプリケーションを監視する必要がある理由はいくつかあります。

長期的な傾向の分析

データベースの規模はどれくらいですか?また、その成長の速さはどれくらいですか? XNUMX日のユーザー数はどのように変化しますか?

性能比較

Ajax DB 2.72 と比較して、バイト 3.14 の Acme Bucket でのリクエストは高速ですか? 追加ノードの出現後、リクエストのキャッシュはどの程度改善されましたか? 先週と比べてサイトの動作が遅くなりましたか?

アラート（通知）

何かが壊れているので、誰かがそれを直す必要があります。 または、何かがすぐに壊れるので、誰かがすぐにそれをチェックする必要があります。

ダッシュボードの作成

ダッシュボードには基本的な質問に答え、以下の内容が含まれている必要があります。 「4つの黄金信号」 — 遅延 (レイテンシ)、トラフィック (トラフィック)、エラー (エラー)、負荷サイズ (飽和)。

遡及分析（デバッグ）の実施

リクエスト処理の遅延が増加しましたが、同時期に他に何が起こったのでしょうか?
監視システムは、ビジネス インテリジェンス システムのデータ ソースとして役立ち、セキュリティ インシデントの分析を促進します。 本書は SRE が専門知識を有するエンジニアリング領域に焦点を当てているため、ここでは監視テクニックについては説明しません。

監視とアラートにより、システムがいつ故障したか、または故障しそうになったことを知らせることができます。 システムが自動的に修復できない場合は、人間がアラートを分析し、問題がまだ進行中かどうかを判断し、問題を解決して、根本原因を特定する必要があります。 システムコンポーネントを監査しなければ、単に「何かが少しおかしい」という理由だけでアラートを受け取ることはありません。

通知の負担を人に与えることは、従業員の時間をかなり高価に使うことになります。 従業員が働いている場合、アラートは作業プロセスを中断します。 従業員が在宅している場合、アラートによって個人の時間が中断され、睡眠が妨げられる可能性があります。 アラートが頻繁に発生すると、従業員はアラートに目を通したり、後回しにしたり、受信したアラートを無視したりします。 時々、彼らはノイズイベントによって隠蔽されている本当の警報を無視することがあります。 ノイズイベントにより問題を迅速に診断して修正することができないため、サービスの中断が長期間続く可能性があります。 効果的な警告システムは、優れた信号対雑音比を備えています。

監視システムに対する合理的な期待を設定する

複雑なアプリケーションの監視を設定すること自体が複雑なエンジニアリング作業です。 収集、表示、アラート ツールの重要なインフラストラクチャを備えている場合でも、10 ～ 12 人のメンバーからなる Google SRE チームには、通常、監視システムの構築と保守を主な目的とする XNUMX 人か XNUMX 人のメンバーが含まれています。 監視インフラストラクチャを統合して一元化するにつれて、この数は時間の経過とともに減少しましたが、通常、各 SRE チームには監視のみを専門とする担当者が少なくとも XNUMX 人います。 システム ダッシュボードの監視は非常に興味深いものですが、SRE チームは、問題を監視するために誰かが画面を見なければならない状況を慎重に避けていると言わざるを得ません。

全体として、Google は最適な事後分析ツールを備えたシンプルで高速な監視システムに移行しました。 私たちは、しきい値を予測したり根本原因を自動的に検出しようとする「魔法の」システムを避けます。 エンドユーザー要求内の意図しないコンテンツを検出するセンサーが唯一の反例です。 これらのセンサーがシンプルである限り、重大な異常の原因を迅速に検出できます。 キャパシティ プランニングやトラフィック予測など、監視データを使用するための他の形式はより複雑です。 低いサンプリングレート (時間または日) で非常に長い期間 (月または年) にわたって観察すると、長期的な傾向が明らかになります。

Google SRE チームは、複雑な依存関係階層を使用してさまざまな成功を収めてきました。 「データベースが遅いことがわかったら、データベースが遅いというアラートを受け取り、そうでない場合はサイトが遅いというアラートを受け取る」といったルールを使用することはほとんどありません。 依存関係ベースのルールは通常、データセンターへのユーザー トラフィックをフィルタリングするシステムなど、システムの不変部分を指します。 たとえば、「データ センターへのトラフィック フィルタリングが設定されている場合、ユーザー リクエストの処理の遅延について警告しない」は、データ センターからの警告に関する一般的なルールの XNUMX つです。 Google のインフラストラクチャでは継続的なリファクタリングが一定の割合で行われているため、複雑な依存関係階層をサポートしているチームはほとんどありません。

この章で説明されているアイデアの一部は、現在でも有効です。特に常に変化するシステムでは、症状から根本原因までより迅速に移行する機会が常に存在します。 したがって、この章では、監視システムのいくつかの目標とその目標を達成する方法について概説しますが、監視システムがシンプルでチームの全員が理解できることが重要です。

同様に、ノイズ レベルを低く、信号レベルを高く保つために、アラートが発生した資産を監視するアプローチは非常にシンプルで信頼性が高い必要があります。 人々に警告を発するルールは、理解しやすく、明確な問題を提示する必要があります。

症状と原因

監視システムは、「何が壊れたのか」と「なぜ壊れたのか」という XNUMX つの質問に答える必要があります。
「何が壊れたのか」は症状について、「なぜ壊れたのか」は原因について話します。 次の表に、そのような接続の例を示します。

症状
理由

HTTP エラー 500 または 404 が発生する
データベースサーバーが接続を拒否する

サーバーの応答が遅い
CPU 使用率が高い、またはイーサネット ケーブルが損傷している

南極のユーザーは猫の GIF を受け取っていません
CDN は科学者と猫を嫌っているため、一部の IP アドレスがブラックリストに登録されました。

プライベート コンテンツがどこからでも利用できるようになりました
新しいソフトウェア リリースの展開により、ファイアウォールがすべての ACL を忘れ、全員がアクセスできるようになりました。

「何を」と「なぜ」は、最大の信号と最小のノイズを備えた優れたモニタリング システムを作成するための最も重要な構成要素の一部です。

ブラックボックスとホワイトボックス

重要な指標については、広範なホワイトボックス監視と控えめなブラックボックス監視を組み合わせています。 ブラック ボックスとホワイト ボックスを比較する最も簡単な方法は、ブラック ボックスは症状に焦点を当てており、プロアクティブな監視ではなく事後的な監視である、つまり「システムは現在正しく動作していません」ということです。 ホワイトボックスは、システムの内部検証機能 (イベント ログまたは Web サーバー) に依存します。 したがって、ホワイトボックスを使用すると、差し迫った問題、リクエストの再送信と思われる障害などを検出できます。

マルチレイヤーシステムでは、あるエンジニアの担当領域の症状は、別のエンジニアの担当領域の症状であることに注意してください。 たとえば、データベースのパフォーマンスが低下しました。 データベース読み取りの遅さは、それを検出するデータベース SRE の症状です。 ただし、フロントエンド SRE が遅い Web サイトを監視している場合、同じデータベース読み取りが遅い原因はデータベースが遅いことです。 したがって、ホワイトボックス監視は、その範囲に応じて、症状に焦点を当てた場合もあれば、原因に焦点を当てた場合もあります。

デバッグのためにテレメトリを収集する場合、ホワイトボックス監視が必要です。 Web サーバーがデータベース クエリに応答するのが遅い場合は、Web サーバーがデータベースと通信する速度と、その応答速度を知る必要があります。 そうしないと、データベース サーバーが遅いのか、Web サーバーとデータベースの間のネットワークの問題なのかを区別できなくなります。

ブラックボックス監視には、アラートを送信する際に重要な利点があります。問題がすでに実際の症状を引き起こしているときに、受信者への通知がトリガーされます。 一方、まだ発生していないが差し迫ったブラックボックス問題に対しては、監視は役に立ちません。

XNUMXつの黄金の信号

XNUMX つのゴールデン モニタリング シグナルは、遅延、トラフィック、エラー、飽和です。 ユーザー システム メトリクスが XNUMX つしか測定できない場合は、その XNUMX つに焦点を当てます。

遅れ

リクエストの処理に必要な時間。 成功したリクエストと失敗したリクエストのレイテンシを区別することが重要です。 たとえば、データベースまたは他のバックエンドへの接続の喪失によって引き起こされる HTTP 500 エラーは非常に迅速に診断できますが、HTTP 500 エラーはリクエストの失敗を示している可能性があります。 500 エラーが全体的なレイテンシに与える影響を判断すると、誤った結論につながる可能性があります。 一方、遅いエラーは速いエラーでもあります。 したがって、単にエラーを除外するのではなく、エラーの遅延を監視することが重要です。

トラフィック

システムへのリクエストの数は、高レベルのシステム メトリックで測定されます。 Web サービスの場合、この測定値は通常、XNUMX 秒あたりの HTTP リクエストの数をリクエストの性質 (静的コンテンツまたは動的コンテンツなど) で割ったものを表します。 オーディオ ストリーミング システムの場合、この測定はネットワーク I/O 速度または同時セッションの数に焦点を当てます。 Key-Value ストレージ システムの場合、この測定値は XNUMX 秒あたりのトランザクションまたは検索結果になります。

エラーが発生

これは、明示的 (例: HTTP 500)、暗黙的 (例: HTTP 200、ただし無効なコンテンツと組み合わされている)、またはポリシー (例: 「XNUMX 秒以内に応答をキャプチャした場合、XNUMX 秒はエラー」) の失敗したリクエストの割合です。 HTTP 応答コードがすべての障害状態を表現するには不十分な場合、部分的な障害を検出するために二次 (内部) プロトコルが必要になる場合があります。 このような誤ったリクエストをすべて監視することは有益ではない可能性がありますが、エンドツーエンドのシステム テストは、誤ったコンテンツを処理していることを検出するのに役立ちます。

飽和

この指標は、サービスがどの程度集中的に使用されているかを示します。 これは、最も制約されているリソースを特定するシステム監視の手段です (たとえば、メモリ制約のあるシステムではメモリが表示され、I/O 制約のあるシステムでは I/O 数が表示されます)。 多くのシステムは使用率が 100% に達する前にパフォーマンスが低下するため、使用率の目標を設定することが重要であることに注意してください。

複雑なシステムでは、飽和はより高いレベルの負荷測定によって補完できます。サービスは 10 倍のトラフィックを適切に処理できるか、99% 多いトラフィックのみを処理できるか、または現在よりもさらに少ないトラフィックを処理できるか。 リクエストの複雑さを変更するパラメータを持たず (たとえば、「何も与えない」や「一意の単一の単調整数が必要」)、構成がほとんど変更されない単純なサービスの場合は、静的負荷テストの値が適切である可能性があります。ただし、前の段落で説明したように、ほとんどのサービスでは、CPU 使用率やネットワーク帯域幅など、既知の上限がある間接信号を使用する必要があります。 レイテンシーの増加は、多くの場合、飽和状態の主な指標となります。 XNUMX パーセンタイルの応答時間を小さなウィンドウ (XNUMX 分など) で測定すると、非常に早い段階で飽和の信号が得られる可能性があります。

最後に、飽和は差し迫った飽和に関する予測にも関連付けられています。たとえば、「データベースが 4 時間以内にハード ドライブをいっぱいにするようです。」などです。

XNUMX つのゴールデン シグナルをすべて測定し、いずれかのメトリクスに問題がある場合 (または、飽和の場合はほぼ問題がある場合)、人に警告すると、サービスは多かれ少なかれ監視の対象になります。

「テール」（または楽器やパフォーマンス）に関する懸念

監視システムを最初から作成する場合、平均レイテンシー、ノードの平均 CPU 使用率、またはデータベースの平均占有率などの平均値に基づいてシステムを開発する誘惑があります。 最後の 100 つの例の危険性は明らかです。プロセッサとデータベースは非常に予測不可能な方法で破棄されます。 遅延についても同様です。 平均レイテンシが 1000 ミリ秒で 1 秒あたり 5 リクエストの Web サービスを実行すると、リクエストの 99% に XNUMX 秒かかる可能性があります。 ユーザーがそのような複数の Web サービスに依存している場合、XNUMX つのバックエンドの XNUMX パーセンタイルがフロントエンドの応答時間の中央値になる可能性があります。

リクエストの遅い平均と非常に遅い末尾を区別する最も簡単な方法は、実際のレイテンシではなく統計 (表示に適したツールはヒストグラム) で表されるリクエストの測定値を収集することです。つまり、サービスが処理したリクエストの数 (0 ミリ秒の間にかかったリクエストの数)ヒストグラムの境界をほぼ指数関数的に (およそ 10 倍に) 拡大することは、多くの場合、分布を視覚化する簡単な方法です。リクエストの。

測定に適切な詳細レベルの選択

システムのさまざまな要素は、さまざまな詳細レベルで測定する必要があります。 例えば：

• 一定期間にわたって CPU 使用率を監視しても、遅延の原因となる長期的なスパイクは表示されません。
• 一方、年間 9 時間以内のダウンタイム (年間稼働時間 99,9%) を目標とする Web サービスの場合、HTTP 200 応答のチェックを XNUMX 分に XNUMX ～ XNUMX 回以上行うことは、不必要に頻繁になる可能性があります。
• 同様に、ハード ドライブの空き容量が 99,9% であるかどうかを 1 ～ 2 分ごとに複数回チェックする必要はおそらくありません。

測定の粒度をどのように構成するかに注意してください。 CPU 負荷を 1 秒に XNUMX 回収集すると興味深いデータが得られますが、そのような頻繁な測定は収集、保存、分析に非常にコストがかかる可能性があります。 監視の目標に高い粒度が必要で、高い応答性は必要ない場合は、サーバー上でメトリクス収集を設定し、それらのメトリクスを収集および集計する外部システムを設定することで、これらのコストを削減できます。 出来ますか：

1. CPU負荷を毎秒測定します。
2. ディテールを 5% に削減します。
3. メトリクスを毎分集計します。

この戦略により、分析やストレージに大きなオーバーヘッドを発生させることなく、高い粒度でデータを収集できます。

できるだけシンプルですが、これ以上シンプルではありません

さまざまな要件が重なり合うと、非常に複雑な監視システムが完成する可能性があります。 たとえば、システムには次のような複雑な要素が含まれている可能性があります。

• さまざまなインジケーターのすべてのタイプについて、さまざまなパーセンタイルでのリクエスト処理レイテンシーのさまざまなしきい値に基づいてアラートを生成します。
• 考えられる原因を検出して特定するために追加のコードを作成します。
• 考えられる問題の原因ごとに関連するダッシュボードを作成します。

潜在的な合併症の原因には終わりがありません。 すべてのソフトウェア システムと同様に、監視は非常に複雑になり、脆弱になり、変更や保守が困難になる場合があります。

したがって、監視システムをできるだけ簡素化するように設計してください。 追跡対象を選択するときは、次の点に注意してください。

• 実際のインシデントをほとんどの場合検出するルールは、可能な限りシンプルで、予測可能で、信頼できるものである必要があります。
• 頻繁に実行されない (たとえば、一部の SRE チームでは四半期に一度未満) データ収集、集計、およびアラートの構成を削除する必要があります。
• 収集されているものの、プレビュー ダッシュボードに表示されていない、またはアラートによって使用されていないメトリクスは、削除の候補となります。

Google では、基本的な指標の収集と集計は、アラートやダッシュボードと組み合わせて、比較的スタンドアロンのシステムとしてうまく機能します (Google の監視システムは実際にはいくつかのサブシステムに分かれていますが、人々は通常、これらのサブシステムのすべての側面を認識しています)。 複雑なシステムを調査するために、詳細なシステム プロファイリング、プロセスのデバッグ、例外や障害に関する詳細の追跡、負荷テスト、ログの収集と分析、トラフィック検査などの他の手法と監視を組み合わせたくなる場合があります。 これらのほとんどは基本的なモニタリングと共通点がありますが、それらを混合すると結果が多すぎ、複雑で脆弱なシステムが作成されます。 ソフトウェア開発の他の多くの側面と同様に、明確でシンプルな疎結合の統合ポイントでさまざまなシステムをサポートすることが最善の戦略です (たとえば、Web API を使用して、長期間にわたって一貫性を維持できる形式で集約データを取得します) ）。

原則を結びつける

この章で説明する原則は、Google SRE チームによって承認および遵守されるモニタリングおよびアラートの哲学に組み合わせることができます。 この監視哲学に従うことは望ましいことであり、アラート方法を作成または修正するための良い出発点となり、組織の規模やサービスやシステムの複雑さに関係なく、運用機能について適切な質問をするのに役立ちます。

監視ルールとアラート ルールを作成するときは、次の質問をすることで、誤検知や不要なアラートを回避できます。

• このルールは、他の方法では検出できないシステムの、緊急で行動を促す、必然的にユーザーに影響を与える状態を検出しますか?
• この警告は無害であるため無視してもよいでしょうか? この警告を無視できるのはいつ、なぜですか?また、このシナリオを回避するにはどうすればよいですか?
• このアラートは、ユーザーが悪影響を受けていることを意味しますか? トラフィック フィルタリングや、アラートをフィルタリングする必要があるテスト システムを使用する場合など、ユーザーに悪影響が及ばない状況はありますか?
• このアラートに応じてアクションを起こすことはできますか? これらの対策は緊急ですか? それとも朝まで待つことができますか? アクションを安全に自動化できますか? この措置は長期的な解決策となるのでしょうか、それとも短期的な回避策となるのでしょうか?
• この問題に関して複数のアラートを受け取っている人もいますが、アラートの数を減らす方法はありますか?

これらの質問は、アラートと警告システムに関する基本的な哲学を反映しています。

• アラートが届くたびに、すぐに対応しなければなりません。 XNUMX日に数回、疲れる前に緊急に反応することができます。
• 各アラートは関連性がある必要があります。
• アラートに対するすべての応答には人間の介入が必要です。 通知が自動的に処理できる場合は、通知は届かないはずです。
• アラートは、以前には存在しなかった新しい問題またはイベントに関するものである必要があります。

このアプローチでは、特定の区別が曖昧になります。アラートが前の XNUMX つの条件を満たしている場合、アラートがホワイト ボックス監視システムから送信されたかブラック ボックス監視システムから送信されたかは関係ありません。 このアプローチは、特定の違いも強調します。つまり、原因よりも症状の特定に多くの労力を費やす方が良いです。 原因に関しては、避けられない原因についてのみ心配する必要があります。

長期モニタリング

今日の生産性環境では、監視システムは、ソフトウェア アーキテクチャ、ワークロード特性、パフォーマンス目標の変化に伴い、進化し続ける生産システムを監視します。 現在自動化が難しいアラートが一般的になる可能性があり、おそらく対処する価値さえあるでしょう。 この時点で、誰かが問題の根本原因を見つけて排除する必要があります。 このような解決策が不可能な場合は、アラートへの対応を完全に自動化する必要があります。

長期的な目標を念頭に置いてモニタリングの決定を下すことが重要です。 今日実行されるアラートはすべて、明日のシステムの改善から気をそらしてしまうため、長期的な監視システムの改善に必要な時間の間、生産システムの可用性やパフォーマンスが低下することがよくあります。 この現象を説明するために XNUMX つの例を見てみましょう。

Bigtable SRE: 過剰な警戒心の物語

Google の内部インフラストラクチャは通常、サービス レベル (SLO) に基づいてプロビジョニングされ、測定されます。 何年も前、Bigtable のサービス SLO は、ライブ クライアントをシミュレートする合成トランザクションの平均パフォーマンスに基づいていました。 Bigtable とストレージ スタックの下位レベルの問題により、平均パフォーマンスは「大きな」テールによって左右され、クエリの最悪 5% が残りのクエリよりも大幅に遅くなることがよくありました。

SLO しきい値に近づくと電子メール通知が送信され、SLO を超えるとメッセンジャー アラートが送信されます。 どちらのタイプのアラートも非常に頻繁に送信され、許容できないほどのエンジニアリング時間が費やされました。チームは、実際に関連する少数のアラートを見つけるためにアラートを分類するのにかなりの時間を費やしました。 アラートの一部だけがその特定の問題に関するものであったため、実際にユーザーに影響を与える問題を見逃してしまうことがよくありました。 アラートの多くは、インフラストラクチャにおける理解できる問題のため緊急ではなく、標準的な方法で処理されたか、まったく処理されませんでした。

この状況を改善するために、チームは 75 つの側面からのアプローチを採用しました。Bigtable のパフォーマンスの向上に懸命に取り組みながら、一時的に SLO 目標をクエリ応答レイテンシの XNUMX パーセンタイルに設定しました。 また、電子メール アラートの数が非常に多く、診断に時間を費やすことができなかったため、電子メール アラートもオフにしました。

この戦略により、戦術的な問題を常に修正するのではなく、余裕を持って Bigtable とストレージ スタックの下位層の長期的な問題の修正を開始できるようになりました。 実際、エンジニアは常にアラートにさらされることなく仕事を進めることができました。 最終的に、アラート処理を一時的に延期することで、サービスの品質を向上させることができました。

Gmail: 予測可能なアルゴリズムによる人間の反応

Gmail は当初、検索インデックスのチャンクをバッチ処理するように設計された、修正された Workqueue プロセス管理システム上に構築されていました。 Workqueue は存続期間の長いプロセスに適応され、その後 Gmail にも適用されましたが、不透明なスケジューラ コードのいくつかのバグは修正が非常に難しいことが判明しました。

当時、Gmail の監視は、Workqueue を使用して個々のタスクがキャンセルされたときにアラートがトリガーされるように構成されていました。 このアプローチは理想的ではありませんでした。なぜなら、当時でも Gmail は何千ものタスクを実行し、それぞれのタスクがユーザーの数パーセントに提供されていたからです。 私たちは Gmail ユーザーに優れたユーザー エクスペリエンスを提供することに非常に懸念していましたが、非常に多くのアラートを処理することは不可能でした。

この問題に対処するために、Gmail SRE はユーザーへの影響を最小限に抑えるためにスケジューラのデバッグを可能な限り支援するツールを作成しました。 チームでは、問題の発見から長期的な解決策が見つかるまでの修復までのサイクル全体を単純に自動化するかどうかについて議論しましたが、そのような解決策では実際に問題を解決するのが遅れるのではないかと懸念する人もいました。

この緊張はチーム内で一般的であり、多くの場合、自己規律に対する信頼の欠如を反映していました。一部のチームメンバーは正しい修正に時間を費やしたいと考えていますが、他のメンバーは最終的な修正が忘れられ、一時的な修正に永遠に時間がかかることを心配しています。 状況を永続的にするのではなく、問題を一時的に解決することがあまりにも簡単であるため、この問題は注目に値します。 マネージャーと技術スタッフは、長期的な修正を実装する上で重要な役割を果たし、最初の「痛み」が治まった後でも、長期的な可能性のある修正をサポートし、優先順位を付けます。

定期的に繰り返されるアラートやアルゴリズムによる応答は危険信号です。 チームがこれらのアラートの自動化に消極的であるということは、チームがアルゴリズムを信頼できるという自信が欠けていることを意味します。 これは対処する必要がある深刻な問題です。

長期

Bigtable と Gmail の例に共通するテーマは、短期的な可用性と長期的な可用性の間の競争です。 多くの場合、強力な努力によって脆弱なシステムが高可用性を達成することができますが、この道は通常短命で、チームの燃え尽き症候群や、同じ英雄的なチームの少数のメンバーへの依存を伴います。

可用性の制御された短期的な低下は多くの場合苦痛を伴いますが、システムの長期的な安定性にとって戦略的に重要です。 各アラートを個別に見るのではなく、アラート量の全体的なレベルが、実行可能なチームと良好な予後を備えた健全で適切にアクセス可能なシステムにつながるかどうかを検討することが重要です。 当社は、経営陣への四半期レポートでアラート頻度の統計 (通常はシフトごとのインシデントとして表現され、インシデントは複数の関連インシデントで構成される場合があります) を分析し、意思決定者がアラート システムの負荷とチーム全体の健全性を継続的に把握できるようにします。

まとめ

健全な監視とアラートへの道はシンプルかつ明確です。 アラートをトリガーする問題の症状に焦点を当てており、原因の監視は問題のデバッグに役立ちます。 データベースの負荷とパフォーマンスの監視はデータベース自体で直接行う必要がありますが、制御するスタックの上位になるほど症状の監視は容易になります。 電子メール通知の有用性は非常に限られており、ノイズになりやすい傾向があります。 代わりに、電子メール アラートをトリガーする現在の問題をすべて監視するダッシュボードを使用する必要があります。 ダッシュボードをイベント ログと組み合わせて、履歴の相関関係を分析することもできます。

長期的には、監視によって迅速な診断が確実にサポートされるように目標を調整しながら、症状や差し迫った実際の問題に関するアラートを適切にローテーションする必要があります。

訳文を最後まで読んでいただきありがとうございます。 モニタリングに関する私の電報チャンネルを購読してください @monitorim_it и Medium のブログ.

出所： habr.com