Alibaba Cloud Elastic Computing SRE Practice with Hundreds of Million Calls

システムの安定性は、効果的なアラートメカニズムと切り離せません。マーフィーの法則によれば、エラーが発生する可能性がある場所では、必ずエラーが発生します。システムがいつ、どこでエラーを起こすかを正確に予測することはできませんが、システムに問題が生じた場合、インターフェイスの応答遅延、システムサービスの利用不能、ビジネスフローの低下、顧客のオペレーション未完了、さらには顧客からのクレームにつながる可能性があることは把握できます。

マーフィーの法則に対抗するためには、あらかじめシステムの各ノードにアラートを設定し、問題発生時に過度に受け身にならないようにする必要があります。同時に、問題検出率を追求する（アラート項目を増やす、しきい値を不合理に下げる、些細な内容まで検出する）ことで、アラートカバレッジのパラドックスに陥り、結果として現在広く見られるアラート地獄現象を招いています。次の図に示すように、これは非常に典型的なポジティブフィードバック増強ループであり、アラート関連の問題がますます増加する一方です。

図：アラートのポジティブフィードバック増強ループ

アラート項目を増やせば問題は改善されるだろうか。エントロピー増大の法則によれば、このプロセスは不可逆的な崩壊へと向かい、最終的にはどのアラートに対応すべきか分からなくなる、あるいはアラートの無視につながる可能性があります。この問題を解決する方法はあるだろうか。あります。ネガティブエントロピーを実践することです。アラートの 6 つの重要な要素について、順を追って説明します。

これら 6 つのアラート要素のうち、一部は広く認識されており明白ですが、他は見過ごされがちで、アラート地獄を招く原因となっています。本稿は、日々のアラート定義、通知、ガバナンスの経験と知見を組み合わせた、アラートガバナンスの理想的な実践基準です。良好なアラート管理を維持し、システムに潜在する危険を継続的に解消し、システムの安定的かつ健全な発展を促進することに重点を置いています。

01 正確性：アラート自体の精度と正しさ

無視されているアラートの多くは、対応しなくても実際の障害が発生しないため、「不正確」と呼べるものが少なくありません。正確性の第一の定義は、アラートがアラートレベルに達していることです。対応不要なアラートは「嘘をつく少年」効果をもたらし、アラートはますます無視され、最終的には本当に対応が必要なアラートを見逃すことになります。低重大度のアラートを誰も監視せず、短時間で高密度の通知だけが注目を集めるというチームを実際に見つけたことがあります。そのようなチームはアラートに対してますます鈍感になり、より危険な状態にあります。さらに、無効なアラート通知は SMS や電話料金などのリソースを不必要に浪費します。今すぐ無効なアラートを排除する取り組みを始めましょう。

正確性の第二の定義は、アラートが正しい受信者に正確に通知されることです。アラート通知を受け取る人が多いほど対応される可能性が高いと思ってはいけません。実際には、無関係な人は通知を受け取っても様子見をする傾向があり、結局誰も対応しません。これらの無関係な人には対応する動機も能力もないからです。かつて、アラートと無関係な受信者が、本来対応すべきチームに「あなたのシステムに問題がないか確認してください」と連絡したケースに遭遇したことがあります。この場合は無関係な通知が機能しましたが、本来アラートを受けるべきチームにとって、これがどれだけ気まずく恐ろしいことか。さらに、アラート対応チームはアラート通知に応答し、対応を引き継いで処理中であることを通知元に知らせる必要があり、一方でアラート評価用のデータ準備も求められます。

まとめると、「正確性」要素は本物のアラート情報を正しい受信者に届けることです。本物のアラートも正しい受信者も、どちらが欠けてもなりません。同時に、これはハンドシェイクのプロセスでもあります。受信者は通知を受け取ったら、対応の引き継ぎと準備を行う必要があります。

02 適時性：タイムリーな通知と緊急対応

アラートの対応率を追い求めるなら、通知と対応はタイムリーであるほど良いと言えます。しかし、ネガティブエントロピーを実践することを忘れてはいけません。大半のケースでは、過度な緊張やパニックを避けるためにも適時に対応することが重要です。

まず、時間帯やアラートの緊急度に応じて、異なる強度の通知チャネルを使い分ける必要があります。たとえば夜間の緊急アラートでは、SMS や IM ではタイムリーに到達しない可能性があり、電話などより強力な通知手段が必要です。ただし通常の勤務時間中は、全員がオンラインである必要はありません。非常に深刻なアラートには、緊急度の高い強力な通知を維持する必要がありますが、可能な限り使用は控えることを推奨します。

次に対応の面では、タイムリーな対応がないアラートはより強力な通知チャネルにエスカレーションできます。同時に、上長や SRE など対応者をエスカレーションして、タイムリーな緊急対応を実現することもできます。すべてのアラートが緊急対応を必要とするわけではありません。たとえば、多数のオンラインマシンの 1 台であればビジネスフローに影響しないため、後で対応できます。

最後に、同じアラートを短時間に繰り返し送信しないことです。アラートの爆発に埋もれてしまうのを防ぐためです。通常、アラートを統合して関連統計を作成し、アラート分類に基づいて対応する抑制処理を行うか、手動選択で一定期間その種のアラートの送信を停止します。最初のアラートが対応開始されると、関連する緊急対応が既に開始されていることを意味します。さらに関連アラートをプッシュすることは干渉となります。対応の効果はモニタリングで確認できるため、同じアラートの報告を続ける必要はありません。

03 詳細性：影響範囲、コンテキスト情報、診断情報の提供

アラート受信後、最初に行うべきことは問題を判断し、適切な分離または止血措置を講じることです。アラート内容が不十分な場合、このプロセスが推測ゲームと化します。現場に出てさまざまな手段で検証し推測して問題を特定する必要があり、これがアラート対応で最も時間のかかる部分です。さらに、その多くは経験に依存するため、新人が介入するのはほぼ困難です。したがって、アラート情報に影響範囲、コンテキスト情報、診断情報が含まれていれば、問題箇所の特定は半分の労力で倍の成果を得られます。

まず、アラートの影響範囲は緊急対応の優先度を判断する重要な指標です。影響範囲にはリソース、ビジネス、ユーザーなどの次元があります。

・リソース：単体マシン、クラスター、関連する依存関係

・ユーザー：個別、一部、または全顧客

・ビジネス：コア業務、バイパス業務、非コア業務

影響範囲が個別ケースであれば、単体マシンの隔離、非コアリンクの切り離し、個別顧客の流量制御など、迅速な隔離対応が可能です。逆に影響範囲が広域レベルの場合、より多くの人員（上長、SRE、チーム内のその他のメンバー）を動員し、場合によっては障害レベルまでエスカレーションするなど、より強力な緊急対応メカニズムが必要です。

次に、コンテキスト情報は少ない労力で効果的な位置特定を可能にします。コンテキスト情報はエラーの診断判断を支援し、現場再現の手間を省きます。コンテキスト情報には以下が含まれます。

・トレース：アラート問題のトレースリンク。現場再現に相当します。

・ログ：詳細なエラーログリンク。具体的なコードと現在のスタック情報を特定できます。

・関連付け：関連するアラートや変更。アラートが他の問題や変更によるものかを素早く判断できます。

コンテキスト情報があれば、さらなるトラブルシューティングのパスが基本的に確定します。コンテキスト情報がない場合、さまざまなプラットフォームから情報を収集し、場合によってはリアルタイム情報の再現が必要になります。これらのオペレーションは時間がかかるだけでなく、情報の不完全さやタイムフローの問題により、必要な情報が取得できない可能性もあります。

最後に、アラート内の診断情報により、原因特定の時間を直接省くことができます。問題の位置特定は、多くの場合、対応者のビジネス理解、ツール活用能力、プラットフォームのデータ、過去の経験に依存します。アラート診断は、このプロセスにおける経験をルールとデータを通じて結果に変換し、直接出力するものです。診断は一定のシステム構築を通じてのみ実現できます。たとえば、ECS の内部では次のようなアーキテクチャを採用して診断をサポートしています。

1. 異なるチャネルからのアラート情報を接続する必要があります。アラート情報が直接送信されると、診断リンクが失われます。アラート情報をまず診断レイヤーに接続することで、後続の診断アクションを呼び出せるようにします。

2. 一定の情報収集能力を備える必要があります。各種メタ情報（アプリケーション、データベース、API、担当者、オンコール体制）、変更情報、運用ツール、ログ、その他のアラート情報を含みます。

3. 一定の情報統合能力を備え、アラートと収集した情報を統合し、診断フレームワークと組み合わせて診断結果を出力する必要があります。

04 回復：隔離、止血、自己修復

回復はアラート処理の最優先事項です。トラブルシューティングに先立ち、システム、ビジネス、顧客への影響を排除する必要があります。要素 3（詳細性：影響範囲、コンテキスト情報、診断情報の提供）で問題を特定したら、ビジネスに対し対応する回復手順を実行します。

通常、回復には何らかのアクションが必要です。アラートがさらに踏み込んで回復操作を提示できれば、対応スピードは大幅に向上します。

一般的に、回復アクションには次の実行パスがあります。

・障害自己修復：アラートに基づいて影響を判断し、プリセットされたアクションと関連付けて自己修復を完了します。まず、アラートに対するコールバックアクションのバインディングをサポートする必要があります。アラート内容に応じて適切な自己修復操作を選択できます。次に、アクション実行の制御範囲により、自動実行による二次障害を防止できます。たとえば、単体マシンの問題を検出してそのマシンを除去する場合などです。自己修復では実行のスコープと影響を判断し、信頼性の高いアクションを自動実行できるようにします。

・止血アクション：リンクやチャットを通じて止血アクションをアラートコンテンツに埋め込み、関連アクションをクリックして素早く影響を排除します。たとえば、流量制御、再起動、切り替えなどのアクションをアラート通知に記載し、ワンクリックで操作を完了できます。

・止血アクションがない場合：ベストプラクティス、操作マニュアル、または関連連絡先を提示して操作を案内し、マニュアルに従った操作の継続や対応可能な担当者への連絡を促します。

ここまでで、4 つの要素の最適化を通じてアラートの緊急対応プロセス全体を完了しました。次の 2 つの要素はアラートの運用に焦点を当て、効率的かつ効果的な運用を通じてアラートをさらに管理します。

05 カバレッジ：テンプレートによる自動カバレッジ

障害復旧の過程で、対応するモニタリングが不足していたため、多くの問題がタイムリーに発見されませんでした。すべてのモニタリング項目をカバーすることは不可能ですが、経験は蓄積し継承できます。汎用的で標準的なアラートは大半のビジネスに適用でき、テンプレートを通じてより広範囲にカバーできます。

まず、同種のアラートはモニタリング項目が類似しており、しきい値の定義も近いことが多いものです。この種の標準モニタリングは複数のアプリケーションやビジネスに迅速に適用でき、巡回メカニズムを通じて確実にカバーする必要があります。通常、アラートのモニタリング項目は基本モニタリングとビジネスモニタリングに分けられます。モニタリングとアラートの定義はビジネスの重要度によって異なります。たとえば、アプリケーションレベルに応じたモニタリングの対応レベルを定義し、レベルごとにテンプレートでモニタリングをカバーすることで、設定ミスを防ぎ、新しいリソースやサービスも自動的にカバーされます。

汎用モニタリングは蓄積してテンプレート化し、経験を継承して類似問題の再発を防ぐ必要があります。たとえば、あるチームで次のような障害が発生しました。デプロイスクリプトの問題により、デプロイ中に VIP から除去されたマシンがデプロイ完了後も再マウントされず、最後のマシンがデプロイされた時点で VIP にサーバーが存在しなくなり、サービスが利用不能になりました。二重チェックを通じて汎用ルールをまとめました。VIP に接続されたマシンの xx% 以上が除去された時点でアラートを発出し、複数の組織に適用して今後類似の事態を防ぎます。

06 測定：データ統計によるネガティブエントロピーの実践

最後に、アラートのデータ統計について説明します。経営の巨匠ドラッカーはかつてこう言いました。

測定できなければ、管理もできない。— Peter Drucker

測定はアラートガバナンスのクローズドループを完成させる重要なパートです。リーンアプローチに基づき、データフィードバックから問題を発見し、問題の解決を試み、再度データを振り返る流れです。

測定データには次の側面を含めることができます。

・アラートの具体的データ：後続の分析と改善に使用。通知頻度の統計、アラート数量の統計。たとえば、1 日当たり平均 3 件以下、人/チーム/アプリケーション別の TOP ランキング、レッドブラックリストなど。

・無効マーク：無効アラートのクリア。

・対応開始の有無：対応開始率をレッドブラックリストで公開。

・対応開始時間：緊急対応の改善。「1-5-10」（1 分で問題発見、5 分で位置特定、10 分で復旧）を参照。

・解決時間：「1-5-10」をより良く達成する。

・アラートツールの使用状況：ツールレコメンデーションの精度を向上。

これらの運用データがあれば、ガバナンスの指針が得られます。継続的に運用することで、アラートをより健全な方向へ進化させられます。

まとめ

最後に、Alibaba Cloud エラスティックコンピューティングの内部実践例を通じて、6 つの要素を組み合わせたアラートガバナンスの実践を説明します。

アラート面では、統一アラートプラットフォームを構築し、6 つの要素をエンジニアリングを通じてアラートのライフサイクル管理に統合しました。

まず、大部分のアラートチャネルを集約しました。内部には SLS、POP、ARMS、DAS、Prometheus など複数のアラートソースがあり、これらのアラートは個別の担当者ではなくアラートゲートウェイに通知されます。アラートゲートウェイはこれらのデータを分析、構造化、診断します。

診断環境で影響範囲、根本原因、迅速回復ツールを出力します。この部分は最も複雑で、一定の情報統合能力と診断能力が必要です。まずアラート情報をメタ情報に関連付けます。これは内部で継続的に構築している基礎データで、リソース情報（マシン、データベース、API、アプリケーションなど）、組織情報（組織構造、オーナー情報、オンコール情報）、戦略情報（緊急プロセス、エスカレーション戦略、通知戦略など）を含みます。さらに、アラート内容の影響を受けた範囲（影響を受けた顧客、リージョン、リソース、API など）を診断し、コンテキストを保持してログやトレースリンクを捕捉し、最後にアラート内容の分析に基づいて回復ツールを提供します。これらの情報はテンプレートエンジンでレンダリングされ、最終的に具体的な担当者にプッシュされます。

診断プロセスでアラートのエスカレーションが必要と判断された場合は、自動的にアラートベースをアップグレードし、対応する緊急プロセスを開始します。たとえば、再保険顧客を識別して緊急対応のためのアラートプロセスを開始します。

最後に、データの定量化を通じて対応するレッドブラックリストを形成し、未達の指標を継続的に管理します。同時にデータを通じてガバナンスプロセスの不備を分析し、継続的に改善してクローズドループを形成します。