Alibaba Cloud Elastic Computing SRE Practice

システムの安定性は、効果的な早期警告メカニズムと切り離すことができません。マーフィーの法則によれば、エラーが発生する可能性がある場所では、必ずエラーが発生します。いつ、どこでシステムにエラーが発生するかを正確に予測することはできません。しかし、システムに問題が生じた際には、インターフェイスの応答が遅くなる、システムサービスが利用できなくなる、ビジネスフローが低下する、顧客の操作が完了しない、さらには顧客からの苦情につながるといった事象が現れることは理解できます。

マーフィーの法則に対抗するためには、システムの各ノードに早期警告情報を事前に設定し、問題発生時に過度に受動的にならないようにする必要があります。同時に、問題発見率を追求するあまり（早期警告項目の増加、不適切なしきい値の設定、重要度の低い内容の追加）、早期警告カバレッジのジレンマに陥り、結果として早期警告地獄現象を招いています。次の図に示すように、これは典型的なポジティブフィードバック増強ループであり、早期警告の問題が増え続ける結果となります。

図：早期警告のポジティブフィードバック増強ループ

早期警告項目を増やせば問題は改善されるでしょうか。エントロピー増大の法則によれば、このプロセスは必然的に不可逆的な破綻を招き、どの早期警告に対応すべきか混乱したり、早期警告を無視する結果に陥る可能性があります。この問題を解決する方法はあるのでしょうか。答えは負のエントロピーです。ここでは、早期警告プロセスの 6 つの要素について説明します。

6 つの早期警告要素の中には、広く認識されているものもあれば、見落とされがちなものもあり、後者が早期警告地獄の原因となっています。この記事では、日常的な早期警告の定義、通知、ガバナンスの経験と知見をまとめ、早期警告ガバナンスの理想的な実践基準としています。良好な早期警告対応の維持、システムの問題の継続的な解決、システムの安定した健全な発展の促進に焦点を当てています。

01 精度：早期警告自体が正確であり、正しく通知される

無視されるアラートの中には、対応しなくても実際の問題が発生しないという点で、不正確と呼べるものが多く含まれます。正確性の第一の定義は、アラートが警告レベルに達していることです。対応不要な警告は「オオカミ少年」効果を生み、警告に対する無関心が増し、最終的に本当に必要な警告を見逃すことになります。実際、短い時間にアラートを監視する人がおらず、高密度の早期警告通知が短時間続く場合のみ注目されるというチームが見受けられます。このようなチームは早期警告に対してますます免疫が強まり、ますます危険になっています。さらに、無効な早期警告通知は、SMS や通話料金など、リソースの不必要な浪費にもつながります。ですから、今すぐ行動を起こし、無効な早期警告を排除しましょう。

正確性の第二の定義は、アラートが正しい受信者に正確に通知されることです。アラートを受け取る人が多いほど対応される可能性が高いと思わないでください。実際には、無関係な人はアラートを受け取っても様子見をする可能性が高く、誰も行動しません。無関係な人には対応する動機も能力もないからです。かつて、早期警告と緊急対応に関係のない人が、関係のあるチームに「システムに問題がないか確認してください」と通知したケースに遭遇しました。無関係な通知がこのケースでは役立ちましたが、早期警告と緊急対応が必要なチームにとっては、どれほど気まずく、恐ろしいことでしょうか。さらに、早期警告と緊急対応の担当者もアラート通知に対応する必要があります。一方では、関係者に早期警告が対応済みであることを伝え、他方では、早期警告の計測用データを準備できていないからです。

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

02 適時性：適時な通知と適時な緊急対応

早期警告への対応速度から見ると、すぐに通知してすぐに対応することが必ずしも最適とは限りません。ただし、負のエントロピーの対応を怠らないことが重要です。ほとんどの場合、過度な緊張や混乱を避けるために適時性を確保すれば十分です。

まず、適時に、時間帯に応じて異なる強度の通知チャネルを使用する必要があります。たとえば、夜間に緊急早期警告が必要な場合、SMS や IM では適時に届かないことがあり、電話などより強力な通知方法が必要です。しかし、通常の勤務時間では、全員がオンラインである必要はありません。非常に深刻な早期警告には、緊急度の高い強力な通知を維持して適時性を達成する必要がありますが、可能な限り使用を控えることを推奨します。

次に、緊急対応の観点から、適時に対応されない早期警告はより強力な通知チャネルへエスカレーションできます。同時に、対応者も上司や SRE などにエスカレーションし、適時な緊急対応の目的を達成できます。すべての早期警告が緊急対応を必要とするわけではありません。たとえば、多数のオンラインマシンの 1 台であれば、ビジネスフローに影響しないため、後で対応可能です。

最後に、同一の早期警告が短時間に繰り返し送信されないよう適時に制御し、早期警告の大量通知に埋もれないようにする必要があります。一般的に、アラートは集約され、関連する統計が作成され、アラート分類に応じて対応する抑制処理が実行されるか、その種のアラートの送信を手動で一定期間一時停止します。最初の早期警告が対応済みになれば、関連する緊急対応が開始されたことを意味します。その後の関連早期警告のプッシュは干渉となり、処理効果はモニタリングで確認できるため、同一の早期警告を継続的に報告する必要はありません。

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

アラート受信後、最初に行うべきことは問題を特定し、適切な分離または止血措置を講じることです。アラート内容がシンプルすぎると、このプロセスが推測ゲームになり、現場での検証やさまざまな手段による推測が必要となり、早期警告対応で最も時間がかかる部分になります。さらに、多くが経験に依存するため、新人が介入するのはほぼ困難です。したがって、早期警告情報に影響範囲、コンテキスト、診断情報を含めておけば、問題の特定が飛躍的に効率化されます。

まず、早期警告の影響範囲は緊急対応の優先度を判断する重要な指標です。影響範囲はリソース、ビジネス、ユーザーなどの次元を含みます。

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

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

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

影響範囲が個別の場合、単一マシンの分離、非コアリンクの除去、単一顧客へのフロー制御の適用など、迅速に分離措置を講じることができます。一方、大規模な影響の場合は、上司、SRE、チーム内の他のメンバーなど、より多くの対応者を動員し、場合によっては障害レベルまでエスカレーションするなど、より多くの緊急対応メカニズムを採用する必要があります。

次に、コンテキスト情報は問題の特定を飛躍的に効率化します。コンテキスト情報は誤診断の判断に役立ち、現場再現の手間を省きます。コンテキスト情報には以下が含まれます。

・トレース：早期警告に対応するトレースリンク。現場再現に相当します。

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

・関連付け：関連するアラートまたは変更情報。早期警告が他の問題の関連付けや変更によって引き起こされたかどうかを迅速に判断できます。

コンテキスト情報があれば、さらなるトラブルシューティングの方向性が基本的に確定します。そうでない場合、さまざまなプラットフォームから情報を収集したり、現場を再現したりする必要があり、時間がかかるだけでなく、情報の不完全さや時間の経過により必要な情報を取得できない可能性があります。

最後に、早期警告に含まれる診断情報は、問題の原因を直接特定できるため、トラブルシューティングの時間を削減できます。問題の特定は、多くの場合、対応者のビジネス理解、ツールの活用、プラットフォームのデータ、過去の経験に依存します。早期警告診断は、これらの知識をルールとデータを通じて結果に変換し、直接出力します。診断は、ある程度のシステムケイパビリティの構築を通じてのみ実現できます。たとえば、ECS では診断をサポートするために、以下のアーキテクチャを内部で使用しています。

1. 異なるチャネルからの早期警告情報を統一された方法で接続する必要があります。早期警告情報が直接送信されると、診断リンクが失われます。早期警告情報をまず診断レイヤーに接続することで、後続の診断アクションを実現できます。

2. 各種メタ情報（アプリケーション、データベース、API、人員、オンデューティなど）、変更情報、運用保守ツール、ログ、その他の早期警告情報を含む、一定の情報収集ケイパビリティが必要です。

3. 早期警告と収集した情報を統合し、診断フレームワークと組み合わせて診断結果を導き出す、一定の情報統合ケイパビリティが必要です。

04 復旧：分離、止血、自己修復

復旧は早期警告対応において最も重要な事項です。まずシステム、ビジネス、顧客への影響を排除し、その後、問題のトラブルシューティングを行います。要素 3（詳細：影響範囲、コンテキスト、診断情報の提供）：問題を特定するために、ビジネスは対応する復旧手順を実行する必要があります。

一般的に、復旧にはいくつかのアクションが必要です。早期警告がさらに進んで復旧操作を示唆できれば、対応速度が大幅に向上します。

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

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

・止血アクション：リンクや ChatOps を通じてアラート内容に組み込むことができます。関連するアクションをクリックするだけで影響を迅速に排除できます。たとえば、アラート通知にフロー制御、再起動、切り替えなどのアクションを含め、ワンクリックで操作を完了できます。

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

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

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

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

あるタイプの早期警告には類似のモニタリング項目や類似のしきい値定義があります。このタイプの標準モニタリングは、複数のアプリケーションやビジネスを迅速にカバーし、巡回メカニズムを通じて見落としを防ぐ必要があります。一般的に、アラートモニタリング項目は基本モニタリングとビジネスモニタリングに分けられます。モニタリングとアラートの定義はビジネスの重要度レベルによって異なり、アプリケーションレベルに応じた対応レベルを提案し、レベルに応じてテンプレートでモニタリングをオーバーライドすることで、設定忘れを防ぎます。同時に、新たに追加されたリソースやサービスも自動的にカバーされます。

一般的なモニタリングは蓄積され、テンプレート化して経験を伝え、同様の問題の再発を防ぐ必要があります。たとえば、あるチームで以前に障害が発生しました。デプロイスクリプトの問題により、デプロイ中に VIP から除去されたマシンがデプロイ完了後に再マウントされず、最後のマシンがデプロイされた時点で VIP にサーバーが存在せず、ビジネスが利用不能になりました。レビューを通じてこの一般的なルールをまとめ、VIP に接続されたマシンの xx% 以上が除去された場合にアラートを送信し、複数の組織に適用することで、将来の同様のインシデントを回避できます。

06 計測：データ統計による負のエントロピー

最後に、早期警告のデータ統計について説明します。マネジメントの巨匠ドラッカーはかつてこう言いました。

測定できないものは管理できない。――ピーター・ドラッカー

計測は早期警告ガバナンスのクローズドループを完成させる重要な部分です。ここでは「リーン」の考え方を使用し、データフィードバックを通じて問題を見つけ、問題の解決を試み、データを振り返ります。

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

・アラートの具体的なデータ：その後の分析と改善に使用され、通知頻度をカウントし、アラートを統計します。たとえば、1 日あたり平均 3 件以下のアラート、および人員/チーム/アプリケーションの TOP のレッドリスト・ブラックリストなどです。

・無効マーク：無効なアラートを明確にします。

・対応済みかどうか：対応率をレッドリスト・ブラックリストを通じて公開する必要があります。

・対応時間：緊急改善のため、障害の「 1-5-10 」を参照します（ 1 分で問題発見、5 分で特定、10 分で復旧）。

・解決時間：「 1-5-10 」をより良く完了させます。

・アラート対応ツールの使用：ツール推奨の精度を向上させます。

これらの運用データにより、ガバナンスの根拠が得られます。継続的な運用のみが早期警告をより健全な方向に進化させます。

まとめ

最後に、Alibaba Cloud エラスティックコンピューティングの内部実践と組み合わせて、6 つの要素を組み合わせた早期警告ガバナンスの実施方法を説明します。

早期警告において、統一された早期警告プラットフォームを構築し、6 つの要素をエンジニアリングを通じて早期警告ライフサイクル管理に統合しました。

まず、ほとんどの早期警告チャネルをクローズしました。内部には SLS、POP、ARMS、DAS、Prometheus などの複数の早期警告ソースがあり、これらのアラートは特定の人ではなく早期警告ゲートウェイに通知されます。アラートゲートウェイはこれらのデータを分析、構造化、診断します。

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

診断プロセスで早期警告のエスカレーションが必要と判断された場合、基本早期警告を自動的にエスカレーションし、対応する緊急対応プロセスを開始します。たとえば、重要顧客を識別し、緊急対応のためのアラートプロセスを開始します。

最後に、データの定量化を通じて対応するレッドリスト・ブラックリストが形成され、基準を満たしていない指標を継続的に管理します。同時に、データ分析を通じて継続的にイテレーションを行い、クローズドループを形成します。