「インシデント対応の自動化」に企業が取り組むための3ステップ

システムに障害が発生した際、修復に多くの時間を要したり、インシデント対応に割う時間が多すぎて、本来注力すべき「ビジネス拡大のためのエンジニアリング作業」が妨げられることに悩む企業は少なくありません。システム障害をもたらすインシデント発生の度に、必要な情報を探したり、同じマニュアル作業を繰り返したりするのでは非効率ですが、一方で、インシデント対応の自動化に手を付ける余裕のない企業が多いのも事実です。こうしたインシデント対応で繰り返される手動作業は、「Crawl-Walk-Run（ハイハイ – 歩く – 走る）」と呼ばれるアプローチを用いて段階的に自動化することが有効です。無理なくインシデント対応の自動化を進めることで、迅速かつ効率的なインシデント対応を実現できます。

PagerDutyは、「スタートアップ企業」から「フォーチュン100企業」まで、様々な顧客との取り組みを通じ、最も効果的なインシデント対応を実践するためのベストプラクティスを生み出してきました。この記事では、その経験を元にインシデント対応の自動化における「Crawl-Walk-Run（ハイハイ – 歩く – 走る）」アプローチの進め方を解説します。

サービスの可用性を高めるために有効なインシデント対応の自動化

顧客のデジタル体験への期待は業界を問わず高まっています。「自分が愛着を持つブランドであっても、1度でも満足度の低いユーザー体験を経験すると、3人に1人はユーザー離れを引き起こす」といわれるほど、顧客は利用するサービスに対して「完璧かつ迅速な提供と高い可用性」を求めておりサービスの停止や中断は許されなくなっているのです。

その結果、システム運用を担当する今日のエンジニアは、「かつてないほどの量のインシデント」と「業務のプレッシャー」に直面しています。サービスの可用性維持を担当するチームは大量のアラートに晒され、インシデント対応者は解決に必要な情報を特定できず混乱してしまうなど、インシデント発生のたびに必要な情報を探し、同じマニュアル作業を繰り返すのはあまりにも非効率です。

平均修復時間（MTTR）を最短にし、顧客維持率を高め、かつ対応チームの業務環境を整えるには「インシデント対応プロセスの自動化」が有効です。ただし、自動化の導入やその適用範囲の拡大は一朝一夕に達成できるものではありません。DevOpsにおける単一のスプリントだけでは実現することは難しいため、様々な課題や局面を乗り越えインシデント対応の改善に取り組もうとする企業の姿勢が大切になります。

「インシデント対応の自動化」における3つの課題

ここでは、「インシデント対応の自動化導入」における3つの大きな課題をご紹介します。

・目先の問題の対応に追われる

頻発するインシデント対応により多くのチームが危機的状況に追い込まれていると感じるような環境下では、問題の先取りや迅速な対応が難しくなり、各自の業務を完了させることも、ましてやインシデント対応の改善・向上に取り組むことは難しくなりがちです。

・社内の賛同を得にくい

様々な業界で多くのリーダーが、最小限のコストで競争力を最大化する手段を模索しています。「インシデント対応の自動化」といった、多くの時間を要するが収益へのメリットが可視化し難い取り組みは、不要なものとみなされる場合があります。

・スケーリングの課題

「インシデント対応の自動化」に取り組む中で、壁にぶつかり前に進めなくなる企業もあります。自社サービスの安定稼働のために「既に精巧な自動修復を多く実装しているチーム」がある一方で、「マニュアル作業に終始しているチーム」もあるなど、自動化の適用範囲の拡大に課題を持つ場合があります。

以上のような課題が組織内で発生している場合は、インシデント対応の自動化を「Crawl-Walk-Run（ハイハイ – 歩く – 走る）」アプローチで進めるのがおすすめです。

インシデント対応の自動化における「Crawl-Walk-Run（ハイハイ – 歩く – 走る）」アプローチ

インシデント対応の自動化は、「Crawl-Walk-Run（ハイハイ – 歩く – 走る）」アプローチによって段階的に取り組むことが可能です。ここでは、「Crawl-Walk-Run（ハイハイ – 歩く – 走る）」アプローチによるインシデント対応の自動化について解説します。

・「Crawl-Walk-Run（ハイハイ – 歩く – 走る）」アプローチとは

「Crawl-Walk-Run（ハイハイ – 歩く – 走る）」とは、人間が段階を踏んで成長するように、「大規模な変革や改善の実現」に向けて段階的なアプローチを踏むことです。「一般的なビジネス」や「プロジェクト管理」の原則として広く使われています。「Crawl-Walk-Run（ハイハイ – 歩く – 走る）」アプローチを採用することで、先にご紹介した「インシデント対応の自動化」における課題も乗り越えやすくなると考えられます。

・同アプローチを用いた自動化導入の流れ

最初のステップでは、「チームメンバー構成」と「チームが取り組む上でどのレベルを目指すか」を決めることが大切です。インシデント対応の自動化導入に際し、その効果の理解を得るベストな方法の1つが、小規模なパイロットを実施して特定の部署・サービスにおける日常業務の改善することです。つまり、短期間でメリットを感じられやすい対象から始めること。

その上で、インシデント対応の自動化においては次のように段階を踏むことがおすすめです。まず、「Crawl（ハイハイ）」ステップでは、対応が不要なアラートを抑制し、通知を一時休止します。これにより、インシデント対応者の負荷を軽減が可能できます。次に「Walk（歩く）」ステップでは、自動化に向けてデータをエンリッチメントし、インシデントの解決をより容易にします。最後の「Run（走る）」ステップでは、システム障害の自動修復を実現します。

1.「Crawl（ハイハイ）」ステップ：対応が不要なアラートの抑制と通知の一時休止

イベント・インシデントの発生数がチームの処理能力を超える場合は、発生原因を突き止めた上で、対応が不要なインシデントの発生を抑えましょう。そのために「Crawl」のステップではインシデント対応の自動化に向けて「アラート抑制と一過性アラートにおける通知の一時停止」に取り組みます。どちらも他のタイプの自動化と比べて実装しやすく、インシデント対応者のアラート疲れを短時間で軽減できます。

・アラート抑制

アラート抑制とは、「対応が不要となるアラートがインシデントとして通知されることを抑制し、オンコール対応者に通知しないようにするもの」です。PagerDutyでは、AIを活用した自動化支援として「PagerDuty AIOps」を提供しています。「AIOps」をご利用頂いているお客様のデータによると、ノイズ削減のうち50%がアラート抑制の効果によるものです。アラート抑制では、対応者が知る必要のないイベントを対象にルールを設定することでインシデントの発生量を低減できます。例えば、PagerDuty内の開発チームでは、受信するアラートが一定数に達するまで、対応者が知る必要のないイベントを抑制します。その後、アラートが一定数を超えたタイミングで「イベントオーケストレーション」機能によりインシデントを作成します。

・通知の一時停止

ユーザーが事前に定義した期間内においてインシデント発生の通知を一時停止し、その期間が終了すると通常通りインシデントがを発生させるようにします。この自動的な通知の一時停止は、明確に定義された条件を持つ特定のインシデントに対してフラグを立てる際にも適しています。例えば、CPU使用率が高いがものの５分以内で解消するイベントは抑制し、５分以上その状態が続く場合のみインシデントとして通知するといったケースです。

2.「Walk（歩く）」ステップ：自動化に向けたデータのエンリッチメント

ノイズが削減されチームが対応すべきインシデントの数が少なくなれば、適切なデータを使ったインシデントの解決が容易になります。これを実現するのが「イベント、アラート、インシデントのエンリッチメント」です。「エンリッチメント」とは、さまざまなデータの組み合わせにより、データをさらに有用なものに強化することです。これによって、データが適切な形になり、インシデントの解決が容易になります。インシデント対応の自動化に向けては、次のようなエンリッチメントが重要です。

・イベントデータの標準化

「イベントデータの標準化」により、対応者はインシデントに関連する背景情報を入手しやすくなり、トリアージを迅速化できます。また、組織全体でインシデントにより効率良く対応することも可能です。イベントデータの標準化は、対応するイベントの情報に一貫性を必要とするネットワークオペレーションセンター（NOC）や、L1の対応チームにとって特に役立ちます。多くのチームをサポートしている場合、チームごとに異なる記述方法では内容の理解に時間がかかるからです。

・アラート作成における重要度の定義

アラート作成における重要度の定義は、さらに一歩踏み込んだ対応を可能にします。重要度に応じて適切に通知がエスカレーションされるようになり、対応時間が短縮されます。

・アラートのグループ化とインシデントメモの記録

複数アラートが単一のインシデントにグループ化されると、インシデント作成タイミングにおける優先度設定、および関連情報などをメモとして追加できます。つまり、インシデントが「P1（優先度が高い）」の場合はチーム総出で対応する必要があり、逆に「P4（優先度が低い）」の場合は、今行っている作業を中断する必要がないことが明確になります。PagerDutyではインシデントにメモを記録することが可能ですので、ナレッジベース記事や社内Wiki、対応マニュアルなどの作成に便利です。

3.「Run（走る）」ステップ：インシデントの自動修復

ここまでご紹介してきた内容において、1つの最終形態が「インシデントの自動修復」といえます。自動修復は「L0での対応者」、つまり「自動化によりインシデントが解決される状態」であり、人間が対応する必要はありません。これを実現する方法は、インシデントの作成時にトリガーできるWebhooksを使用すること、あるいは、PagerDutyや他のベンダーを介して自動化された仕組みを呼び出すことが考えられます。

PagerDutyを活用して無理なくインシデント対応を自動化しましょう

このような高度なレベルまで自力で進化させる企業もありますが、「インシデント対応の自動化の構築」と「会社組織全体への拡大」は決して容易ではなく、多くの課題をもたらす可能性があります。PagerDutyが多くの人々から注目される理由の1つがここにあります。PagerDutyでは、不要なアラート通知を抑制する「AIOps」や、システム障害対応のワークフローを自動化する「Process Automation」など、各段階のインシデント対応の自動化に役立つ機能を提供しています。PagerDutyの自動化に関する機能を使うことで、「自動化の開発担当チーム」や「自動化を組織全体にスケールさせる責任があるSREチーム」が抱える負担を軽減できます。また、PagerDutyでは、こうしたエンドツーエンドかつイベントドリブンな自動化の実現を、円滑に進めるためのサポートも実施していますので、ぜひお気軽にお問合せいただくほか、無料トライアルをお試しください。

公式資料
自動化ROI測定ガイド

本ガイドでは、現在のビジネス状況から収集すべき「ベースとなる指標」から「自動化対象のワークフローの利点」まで、企業が推進すべき「自動化プロジェクトのROI・ビジネス価値」を効果的に計測する方法を詳しく解説。
社内の業務プロセスの自動化を検討する皆様必見です！→ PagerDutyの資料をみる（無料）

無料ダウンロード >

無料ダウンロード >

この記事の著者

山田索

PagerDuty
Manager, Solutions Consulting
ソリューションズコンサルティング マネージャー

山田索

PagerDuty
Manager, Solutions Consulting
ソリューションズコンサルティング マネージャー

ネットワーク機器メーカーにて、インターネット・データセンターのインフラ構築に従事した後、CDNベンダーにて主に動画・ゲーム・電子書籍サービスの拡張性ならびに信頼性向上・セキュリティ対策プロジェクトを推進。2022年よりPagerDuty株式会社にて、インシデント対応の自動化等、デジタルオペレーションのモダン化・成熟度向上を支援している。趣味は自家製スモーカーを使ったベーコン等の燻製作り。

SNS

• 
•