• ブログ
  • 製品
    • PagerDutyの製品機能
      • アラートの集約と分類
      • サービスとチームの組織
      • システム&ユーザーレポート
      • プラットフォームの拡張性
      • モバイルでのインシデント管理
      • ライブコールルーティング
      • リアルタイムコラボレーション
      • 事後検証から学び改善する
      • 多様なアラート機能
      • 簡単なスケジューリング
      • 信頼性の高い環境
      • エンタープライズレベルのセキュリティ
    • 操作画面の特徴
    • 開発者の責任
    • 部門ごとのPagerDuty活用法
    • ITの運用
    • ビデオで学ぶPagerDuty
  • 事例
  • サポート
    • FAQ
    • インテグレーションガイド
    • 日本語サポートサイト
  • 価格

  • お問い合わせ
  • Why DSC?
  • 無料トライアル
  • ブログ
  • 製品
    • PagerDutyの製品機能
      • アラートの集約と分類
      • サービスとチームの組織
      • システム&ユーザーレポート
      • プラットフォームの拡張性
      • モバイルでのインシデント管理
      • ライブコールルーティング
      • リアルタイムコラボレーション
      • 事後検証から学び改善する
      • 多様なアラート機能
      • 簡単なスケジューリング
      • 信頼性の高い環境
      • エンタープライズレベルのセキュリティ
    • 操作画面の特徴
    • 開発者の責任
    • 部門ごとのPagerDuty活用法
    • ITの運用
    • ビデオで学ぶPagerDuty
  • 事例
  • サポート
    • FAQ
    • インテグレーションガイド
    • 日本語サポートサイト
  • 価格

  • お問い合わせ
  • Why DSC?
  • 無料トライアル

アラート管理:インシデントの優先順位をどう決めるか

  • On 2018年1月15日
  • Blog

アラート 。それはいとも簡単に積み上がります 。一瞬で目にするアラートはほんの一握り。でも数時間、場合によっては数分後に、積みあがった山を見ることになります。 どのようにそれらを管理すれば、担当者がお手上げにならないようになるんでしょうか?

これらは非常に重要な質問です。 アラート管理システムにノイズが溢れていて、対応チームが慢性の疲労状態にある場合は、初動に対応するITアラート管理システムを持っていないも同然です。 過剰なノイズとアラート疲れは、アラート管理システムの有効性を完全に低下させます。

 

フィルタリングの適用:インシデントにアラートをまとめる

 

多くの点で、アラート管理システムの合理化の鍵は、関連するアラートをインシデントに統合し、インシデントの優先順位を決定するための迅速かつ正確な方法にあります。緊急度別にインシデントを並べ替えることで、ほとんどのノイズを自動でフィルタすることができ、すぐに注意が必要なものとしばらく様子を見ることができるものを、合理的に推量することができます。すべてのアラートがインシデント化や対応を必要とするわけではありません。対応不要なアラートを抑制すると、ノイズがさらに削減され、重要なことに集中できます。

 

ソート(優先度順に並べ替える)プロセスの一部を自動化する(例えば、ソースとキーワードで並べ替える)ことはおそらく可能ですが、一部の(多分相当な量の)ソートプロセスでは、ディスパッチャの役割を果たしているレスポンスチームの誰かが介在する必要があります。ただし、どのような方法を使用しても、基本となる基準は変わりません。

 

優先順付けのスキームのほとんどは、ITILが定めているインシデントの優先順位付けガイドラインなどに準拠しています。インシデントの優先順位は、インパクトと緊急性という2つの密接に関連する要因に基づいて付けられます。この記事では、これらの要因とその相互作用について詳しく見ていきます。

 

インシデントのインパクトを判断する

 

インパクトは、インシデントの影響範囲(部門、ユーザー、または主要サービスがどれだけ影響を受けるか)に基づきます。 影響判定プロセスの少なくともいくつかの要素を自動化するのは比較的簡単です。 たとえば、ほぼ同時に特定のサービスが利用できないことを示す多数のレポートが出てくれば、影響の大きいインシデントになる可能性があります。一方、単一のユーザーからの問題のレポートは、類似のレポートが他になければ、 影響の少ないインシデントだということを示します。 多くのIT部門にとって、インシデントの影響を判断するためのガイドラインは、次のようになります。

 

高インパクト

  • 重要なシステムがダウンしている。
  • 1つ以上の部門が影響を受ける。
  • 相当数のスタッフがその機能を実行できない。
  • そのインシデントが多数の顧客に影響を与える。
  • そのインシデントが、財務上の大きな損失や組織の評判への損害になる可能性がある。
  • 組織の機能と影響を受ける他のシステムに応じて変わるその他の基準もあります。例えば公衆の安全上の脅威、人命の喪失、または重大な財産の被害などが含まれる可能性があります。

 

中程度のインパクト

  • 一部のスタッフまたは顧客は影響を受ける。
  • 失われたサービスはどれも重要ではない。
  • 財務上の損失や組織の評判への損害は起きる可能性があるが、範囲は限られている。
  • 人命、公共安全、身体的財産への脅威がない。

 

低インパクト

  • 少数のユーザーしか影響を受けない。
  • 重要なサービスは関与しておらず、財務上の損失や評判の低下の可能性はほとんどない。

 

インシデントの緊急度

 

インシデントのインパクトとその緊急性を厳密に区別することは必ずしも容易ではありませんが、ほとんどの場合、このコンテキストで言う「緊急性」とは、「問題がシステムにどれだけ早く影響を及ぼし始めるか」ということだと定義できます。 給与計算システムの故障は、例えば、影響が大きい可能性がありますが、給与の支払い周期の始めに発生した場合は、毎日使う顧客関係データベースの損失よりも緊急性が低い可能性があります。

 

緊急度高

  • 日々の操作に不可欠なサービスが利用できない。
  • インシデントのインパクトの範囲が急速に拡大しているか、または迅速なアクションによってその範囲を制限できる可能性がある。
  • 時間に敏感な仕事や顧客の行動に影響がある。
  • そのインシデントが、高位の個人または組織(上級管理職または主要なクライアント)に影響を与える。


緊急度低

  • 影響を受けるサービスはオプションであり、まれにしか使用されない。
  • インシデントの影響は拡大しないように見える。
  • 重要な作業や時間に敏感な作業は影響を受けない。

注意してほしいのは、インパクトと緊急度の両方について、一般的には各カテゴリの1つの基準に当てはまればそのカテゴリになると思ってよいということです(基準のすべてまたは大多数を満たす必要はありません)。インシデントは、それが条件を満たす最も高いカテゴリに配置する必要があります。

 

優先度=インパクト+緊急度

 

以上のように考えれば、優先順位をインパクトと緊急性の両方の合算で評価すべきだと分かりやすくなったはずです。アラート管理とインシデントのディスパッチプロセスには関係なく、優先順位を決定するための基準に従ってルーティングする必要があり、結果としてアラートノイズを大幅に減らすことができ、低インパクト、低緊急度のイベントは自然に優先順位リストの下端に並ぶと思います。これにより、インシデント対応チームは、非常に注意を払う必要がある、高インパクトで高優先度のインシデントに集中することができます。

アラートの山はどうなるか、ですか? 実行可能で緊急性の高いものに焦点を当てることで、特にPagerDutyのようなソリューションの助けを借りてそうすれば、そんなものがなくなることがわかります!

 


 

本記事は米国PagerDuty社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。

0 Comments

Recent Posts
  • Japan IT Week 春 出展報告 2022年4月19日
  • PagerDutyをJapan IT Week 春に出展します 2022年3月21日
  • インシデントフローと対応の省力化を実現するPagerDuty&Rundeckを出展~Japan IT Week 秋 2021年11月10日
  • システム運用を強力に支援するPagerDutyとRundeckをJapan IT Week秋に出展 2021年10月25日
  • DevOpsのROIを測定する方法 2021年8月23日
  • 8/25 CEDEC 2021でCI/CDツールHarnessとインシデント管理ツールPagerDutyの活用例を紹介 2021年8月20日
  • PagerDuty Summit 2021の概要 Part 2 2021年7月12日
  • PagerDuty Summit 2021の概要 Part1 2021年7月2日
  • 6月23日-25日 PagerDuty Summit 2021 バーチャル開催のご案内 2021年5月20日
  • DevOpsを高速化するための6つのステップ 2020年10月15日
Product Tags
AWS Blog DevOps News Post Mortem SecOps signalfx Slack SRE インシデント インテグレーション オンコール・スケジュール オンコール管理 スケジューリング ステークホルダー ビジネス関係者 モニタリング モバイル リリース 事後検証 導入事例Video 更新 製品アップデート

Zabbix 3.xのインストレーションガイドを追加しました

DevOpsの失敗から学ぶ方法

Scroll
会社情報

株式会社Digital Stacks

〒141-0001

東京都品川区北品川5-5-15

大崎ブライトコア 4F SHIP 414


  • Home
  • 製品情報
    • PagerDutyの製品機能
    • 操作画面の特徴
    • 開発者の責任
    • 部門ごとのPagerDuty活用法
    • ITの運用
    • ビデオで学ぶPagerDuty
  • サポート
    • FAQ
    • インテグレーションガイド
    • 日本語サポートサイト
  • DSCが選ばれるポイント
  • 価格
  • お知らせ
    • お知らせ一覧
      • 更新情報
      • メディア掲載情報
      • 受賞情報
  • 更新情報
  • PagerDutyの製品機能
    • アラートの集約と分類
    • サービスとチームの組織
    • システム&ユーザーレポート
    • プラットフォームの拡張性
    • モバイルでのインシデント管理
    • ライブコールルーティング
    • リアルタイムコラボレーション
    • 事後検証から学び改善する
    • 信頼性の高い環境
    • 多様なアラート機能
    • 簡単なスケジューリング
    • エンタープライズレベルのセキュリティ
  • PagerDuty導入事例
    • 導入事例インタビュー:株式会社ミクシィ
    • 導入事例インタビュー:イーサポートリンク株式会社 
    • 導入事例インタビュー:株式会社いい生活
    • 導入事例インタビュー:株式会社Jストリーム
    • 導入事例インタビュー:SmartNews 尾形暢俊氏
    • 導入事例:IBM Cloud
    • 導入事例:IBM Smarter Workforce
    • 導入事例:GREE
    • 導入事例:Panasonic
    • 導入事例:Evernote
    • 導入事例:Backcountry
    • 導入事例:Groupon
    • 導入事例:SendGrid
    • 導入事例:Brightcove
    • 導入事例:Code.org
    • 導入事例:インディアナ大学
    • 導入事例:Signal Sciences
更新情報
  • Japan IT Week 春 出展報告 2022年4月19日
  • PagerDutyをJapan IT Week 春に出展します 2022年3月21日
  • インシデントフローと対応の省力化を実現するPagerDuty&Rundeckを出展~Japan IT Week 秋 2021年11月10日
  • システム運用を強力に支援するPagerDutyとRundeckをJapan IT Week秋に出展 2021年10月25日
  • DevOpsのROIを測定する方法 2021年8月23日
  • 8/25 CEDEC 2021でCI/CDツールHarnessとインシデント管理ツールPagerDutyの活用例を紹介 2021年8月20日
  • PagerDuty Summit 2021の概要 Part 2 2021年7月12日
  • PagerDuty Summit 2021の概要 Part1 2021年7月2日
  • 6月23日-25日 PagerDuty Summit 2021 バーチャル開催のご案内 2021年5月20日
  • DevOpsを高速化するための6つのステップ 2020年10月15日
Copyright © Digital Stacks Corporation. All Rights Reserved.
  • 無料トライアルを申し込む
  • お問い合わせ
  • 販売会社情報
  • 個人情報保護方針
  • サイト利用規約