あなたのエンジニアリングチームは警戒心の疲労を経験していますか？ これらの8つの質問をする

アラートの疲労は、運用を処理し、インフラストラクチャを維持するエンジニアリングチームに共通の問題です。

この問題は通常、チームが成長し、複雑さが増すインフラストラクチャの使用を開始するにつれて、アラートを作成するための無計画なアプローチに起因します。 これはごく普通のことです。企業やチームが成長するにつれて、可観測性の文化と確実なアラートの実践が具体化するまでに時間がかかることがよくあります。

感度が高すぎ、ノイズが多すぎ、慎重すぎるアラートを作成するのは簡単です。 最初は、製品の初期段階で注意を払い、生産信号を最大化する方がよいという理由だけで、すべてが警戒に値するように見えます。

「機能とインフラストラクチャの数と複雑さが増すにつれて、アラートの改善は通常、優先順位リストのはるか下にあります」

当然、このアプローチはあまり拡張性がありませんが、機能とインフラストラクチャの数と複雑さが増すにつれて、アラートの改善は通常、優先順位リストのはるか下にあります。 その結果、オンコールエンジニアにとって、多くの半意味のあるアラート、ノイズ、コンテキストスイッチング、およびマルチタスクが発生します。 極端な場合、チームメイトは燃え尽き、アラートは無視され、オンコールチームはサービスの品質の向上から、意味のある影響を与えることなく絶え間ない消火活動に移行します。

すべての企業と同様に、インターコムはこれらの非効率性の影響を受けません。 そこで、アラートの疲労と戦うために比較的軽量なプロセスを考案しました。

アラート戦略についての考え方

「アラート規律」の概念は、アラートを制御するための核心です。 機能作業と同様に、アラートとアラート戦略には、意図的で構造化された方法でアプローチする必要があります。 ただし、機能作業とは異なり、事前に十分に計画できるものではありません。

結局のところ、新しい機能を出荷する前に、運用上の健全性とノイズを予測できる可能性はほとんどありません。 アラートの労力が持続不可能なレベルにまで上昇しないように、アラートを定期的に計画的に監視する必要があります。

チームのアラートを評価するときに尋ねる8つの質問

頻繁なアラートを処理するチーム向けに、定期的なアラートレビューセッションを導入しました。 これらは当初、6週間のエンジニアリングサイクルごとに1回、または複数回発生しましたが、アラートとモニターの状態がより管理しやすいレベルに改善されるにつれて、より間隔が空けられました。

各アラートレビューセッションは、前の期間に発生したアラートの順序付きリストから始まり、発生頻度順に並べられています。 アラートソースとしてPagerDutyプラットフォームを使用しており、その分析機能により、アラートの頻度と応答を分類するために必要な情報が得られます。 全体的なノイズに最も寄与する（つまり、最も頻繁に発生する）アラートが最初に確認されます。

次に、各アラートは質問のチェックリストを通過します。

1.アラートはまだ関連していますか？

古いシステムやメンテナンスされていないシステムによってトリガーされたアラートは、オンコールエンジニアに迷惑をかけないようにする必要があり、すぐに削除する必要があります。

2.アラートは実行可能ですか？

オンコールエンジニアがアラートを受信した場合、根本的な原因を修正または改善するために今すぐ何かを行うことができますか？ アラートが実用的で有用でない場合は、削除する必要があります。 問題またはパフォーマンスの低下の週ごとの要約は、アラート内の情報のより良い場所である可能性があります。

3.アラートの情報は、実行可能でなくてもすぐに役立ちますか？

アラート情報は大きく2つのカテゴリに分類できます。

• シグナル：これらのアラートは、システムが限界で動作していることを警告しますが、必ずしもサービスが影響を受けていることを意味するわけではありません。 例として、100％CPUで実行されているサーバーの1つがあります。 サービスがまだ正常に動作している場合、オンコールで調査に貴重な時間を費やす必要がありますか？ 結局のところ、サーバーは最高のコスト対効果の比率で実行されているだけです。
• 症状：これらのアラートは、カスタマーエクスペリエンスが影響を受けたときに発生します。 ここでの例は、サービスが呼び出し元に返す5XXHTTPエラーの数です。

これらの2つのカテゴリは連携して最適に機能します。 オンコールの担当者は、症状に対応してトラブルシューティングを行い、信号をさらなる情報源としてのみ確認する必要があります。

4.アラートが実行可能でページングされている場合、すぐに対処する必要がありますか？

問題をすぐに処理する必要がない場合は、深夜に誰かを起こしてはなりません。 チームは、これらの状況でアラート内の情報を表示する別の方法を決定する必要があります。たとえば、Slackまたはダッシュボードの通知、または問題追跡メカニズムで開かれたタスクです。

5.実行可能な場合、Runbookまたはトラブルシューティングのリンクはありますか？ チームのエンジニアが従うのに十分な手順が明確ですか？

オンコールエンジニア、特に新しいエンジニアであることの最悪の経験の1つは、時間の経過とともにエンジニアリングチームに蓄積される部族の知識の量です。 システムのその領域に精通しておらず、十分に文書化されていないことに気付くために、重大度の高い本番インシデントに飛びつくのは恐ろしいことです。

「アラートのトラブルシューティング情報を明確、シンプル、最新の状態に保つことは、インシデントを軽減して回復するための平均時間を短縮するのに大いに役立ちます。 」

あなたが専門知識を持っていたとしても、あなたはずっと前にコードを書いたので、それが何をしているのかをはっきりと覚えていないかもしれません。 アラートのトラブルシューティング情報を明確、シンプル、最新の状態に保つことは、インシデント（MTTMおよびMTTR）を軽減および回復するための平均時間を短縮するのに大いに役立ちます。

6.実行可能である場合、ダッシュボードリンクがあり、すべての既知の潜在的な原因が表示されていますか？

ダッシュボードは、大量のシステム情報を一度に表示するための優れた方法です。つまり、エンジニアは、問題の原因を特定するためにさまざまなログ、メトリック、およびトレースを調べる必要がありません。 データをダッシュ​​ボードに集約し、アラートの一部としてリンクを提供することで、はるかに迅速なトラブルシューティングが可能になります。

7.アラートの感度が高すぎたり、具体的すぎたりしませんか？ 感度低下やスコープ変更の恩恵を受けるでしょうか？

多くのアラートは便利ですが、正しく調整されていません。 それらは、広すぎて毎回発火しないか、または特定すぎて同じインシデントに対して数回発火する可能性があり、これはノイズを増やすだけです。

8.最後に、人間は修復を行う必要がありますか？

ある意味で、すべてのコンピューターコードは、人間ができることを自動化します。 では、アラートをトリガーする問題の修正を自動化してみませんか？ コードのバグやシステムのパフォーマンスの問題など、特定の厄介なアラートを自動的に修正するのは困難ですが、自動化されたアクションで多くの一般的な問題を解決できます。

これは、AWSのようなクラウドプラットフォームで実行していて、追加のハードウェアを要求することを心配することなくインフラストラクチャをプロビジョニングできる場合に特に当てはまります。 たとえば、検索クラスター内のノードに障害のあるディスクが表示されている場合、それを自動的に置き換えてみませんか？ トラフィックの増加によりサービスのコンピューティングリソースが不足している場合は、スケールアップしてVMまたはコンテナを追加してみませんか？ 修復の詳細は、アラートのないチャネルを介してチームに送信できるため、チームは自由に確認できます。

これらの質問のいずれかに「いいえ」と答えましたか？

これらの質問のいずれにも「いいえ」と答えると、チームがアラートを改善するための作業を行うための優先度の高いタスクが発生します。これは、アラートのページングの停止、トラブルシューティング手順の改善、自動化、または単に根本的なシステムの問題の修正を意味します。

アプローチの核心は、これを定期的かつ計画的な方法で行うことです。 それは騒音レベルを低く保ち、あなたの運用とオンコールエンジニアは幸せで生産的です。 彼らは、消火活動の代わりに、品質の向上とインパクトの提供に集中することができます。

インターコムでの働き方に興味がありますか？ 私たちはあなたと話をしたいです–私たちのオープンエンジニアリングの役割をチェックしてください。