いわゆるクローズド ループとは、アラームの発行、請求、共同処理、問題の回復、レビューと改善のプロセス全体を指します。
スケジュールを設定し、特別なタスクを実行する専任担当者を配置する
この方法は大げさではありませんが、確かに非常に効果的です。シフト中は不安で責められるのが怖かったですが、シフト制だったのでこのサイクルを乗り切っても大丈夫だろうという希望を常に心の中に持っていました。
当直者は当直中の第一責任者であり、問題解決に120％のエネルギーを注ぐことになる 当然、責任者である方が問題解決を促進しやすい 常に警察が介入する。
スケジューリング システムは通常、オープン ソースではなく、イベント センターの機能です。PagerDuty はスケジューリング機能を提供しており、非常に役立ちます。
勤務担当者は勤務中に細心の注意を払っていますが、必然的にそれを無視するため、アラームエスカレーションメカニズムが必要です。
アラームエスカレーションメカニズム
アラーム エスカレーションとは、最初の責任者がアラームを受信した後に時間内に応答しなかった場合に、システムが第 2 ラインおよび第 3 ラインの担当者に自動的に通知するメカニズムを指します。携帯電話がミュートになっていて聞こえなかった、夜中に眠ってしまった、一時的な外出時に携帯電話を忘れてしまったなど、現場の職員がタイムリーに対応できなかった理由はさまざまであると考えられます。この時点で、システムはアラームが回復されておらず、要求されていないことを検出し、一定の時間が経過した後、当番要員のリーダーまたは第 2 ラインのバックアップ要員に通知する必要があります。担当者が長期間応答しない場合は、アップグレードを続ける必要があります。
アラームエスカレーションメカニズムには、クレーム機能の協力が必要です。つまり、最前線の担当者がアラームを受け取った後、特定のメカニズムを通じてシステムに次のように伝える必要があります。「私はすでにアラームを認識しており、今は対処を開始しています」それでエスカレートしないでください。」
したがって、エスカレーション メカニズムは通常、重大なアラームに対してのみ有効になり、警告または通知アラームに対してエスカレーション メカニズムを有効にする必要はありません。もちろん、この基準をどのように設定するかは各チームが決定できます。
アラーム収束ロジック
一般的な収束ロジックは、イベント -> アラート -> インシデントの 3 レベルの収束です。
イベントからアラートまでの収束ロジックは、第 1 レベルの収束と呼ばれます。この収束ロジックだけでは十分ではなく、アラーム情報は依然として比較的分散しています。これらの分散したアラームに基づいて調整し、複数のアラートを 1 つのインシデント (障害) に収束させるのは容易ではありません。インシデントに基づいて調整する方が便利です。 。ただし、イベントからアラートまでは固定の収束ロジックがあり、プログラムによって自動的に収束できますが、アラートからインシデントまで自動的に収束することは困難です。
1. 時間に基づく収束、2. 時間 + タグに基づく収束、3. 時間 + テキストの類似性に基づく収束。
アラームを自動的に障害に収束させる方法はないため、手動で行うことができます。主要なアラームが障害に関連付けられている限り、障害に関連する主要なアラームを区別するのは比較的簡単であり、その後の調整はこの障害に基づいて行うだけで十分です。いわゆるコラボレーション、1つは情報の同期と共同処理、もう1つはフォローアップ項目の共同レビューと管理です。
障害調整
まず、すべてのアラームを障害調整にエスカレーションする必要があるわけではありません。一般的に、当直担当者が直接対応できるアラームであれば、他のチームのサービスに影響を与えることはなく、他のチームに通知する必要もなく、通常は障害にアップグレードする必要もありません。アラームレベルで連携すれば十分で、チーム内で消化し、当直者とそのチームだけで対応できないアラームは障害に格上げし、他チームの人を投入して対処するそれも一緒に。
複数のチームが協力して障害に対処します。異なるチームの人々がいくつかの異なる手がかりを見つけることになるため、その手がかりをすべての関係者にタイムリーに同期する必要があります。この時点で、障害の下にコメントを追加することができ、他のチームもコメントを追加できます。時間内に見てください。損失が停止した後は、全員が障害タイムラインに従ってレビューし、一連のフォローアップ項目を作成する必要がありますが、このとき、障害管理モジュールにはフォローアップ項目管理の機能が必要です。タスク管理システムと適切に通信するため。
このような障害調整メカニズムにより、障害が処理される確率は大幅に増加し、将来的には、いくつかの運用統計手法を使用して、各チームの平均障害ストップロス時間がカウントされ、レッドリストとブラックリストが作成されるようになるでしょう。誰もが失敗に対してより高い熱意を持って対処できるようになります。もちろん、人間がどれほど熱心であっても、機械ほど速くはありませんが、一部のアラームを自動処理ロジックに直接関連付けることができれば、イベントのクローズドループ率が大幅に向上することは間違いありません。
自動アラーム処理
多くの監視システムは、アラームがトリガーされたときに HTTP インターフェイスを自動的にコールバックして自動ロジックに接続し、アラーム イベントを無人で自動的に処理できるように、Webhook を使用して構成できます。たとえば、コンピューター室の特定のサービスがハングアップした場合、Webhook のロジックは、損失を防ぐという目的を達成するために、フロー切断インターフェイスを自動的に呼び出してサービス フローを切断することです。
自動アラーム処理のロジックは必ずしもアラームの自己修復を実現できるとは限りませんが、状況を把握するためにこのメカニズムを使用するだけでも非常に価値がある場合があります。たとえば、プロセスがハングアップしたときに、さまざまなリソースの占有状況やシステム ログ情報など、その時点でのマシンの実行状況を知りたい場合は、自動アラーム処理の方法を使用して、自動的に実行することができます。その時点でマシン上の一部のオンサイト情報をキャプチャするスクリプトは、アラームを受信した後にマシンに手動でログインして確認するよりもはるかに効率的です。
この記事は8月のDay15の学習ノートです 内容はGeek Timeの「運用保守監視システム実践ノート」から引用したものです お勧めの講座です。