を14日間無料で試してみる
700以上ものツールと連携。システム障害を自動的に検出・診断するだけでなく、適切な障害対応メンバーをアサインし、デジタル業務全体の修復ワークフローを自動化します。
近年、金融機関や通信会社などで多発しているシステム障害。システムが1分停止すると約100万円、24時間で約10億円の損失が生じるともいわれています。システム障害が長期化し大きな損害になるケースの多くは、原因究明の遅延や復旧作業などが遅れることが原因と考えられがちですが、本質的な課題は「システム運用監視体制」が整っていないことにあります。ますますデジタル化が進む中で、システム障害は必ず起きるものであり、ゼロにすることは不可能です。いざというときに適切な「インシデント管理・対応」ができるよう、インシデント対応のための体制や仕組みを構築しておくことが重要です。
本記事では、インシデント対応の一般的な流れと、LINE社のPagerDuty導入事例から読み取れる運用体制の構築ポイントを紹介します。
目次
PagerDutyではインシデントを、「システム障害に際して何らかの対応が必要な課題」と定義しています。また、インシデントが発生した際、迅速にシステムやサービスを復旧させるための取り組みをインシデント管理・対応と呼びます。ここでは一般的なインシデント対応の流れを紹介します。
監視ツールやオブザバビリティツールによってシステムの監視を行い、異常を検知した際にはアラートが送られます。システムが複数あったり、担当部署が違ったりなどの理由で複数の監視ツールを使う場合が多く、それぞれのツールから適切にアラートが送信されるよう、設定する必要があります。一日のアラート数は会社によって異なりますが、数千~数万になる場合もあります。
受け取ったアラートの中から、インシデント(対応が必要なもの)を特定し、システム運用担当者への通知や自動修復など、適切な一次対応を実施するステップです。監視センターなどで、このステップを人手で行う場合、オペレーターは手順書(Runbook)を参照して対応を行います。手順書には受け取ったアラートの内容に応じて、「システム担当者に通知するかしないか」「どの担当者に電話で通知するか」等、どのような一次対応を実施すべきかが記載されています。システムが複雑になると、この手順書の内容も複雑になります。大量のアラートに対して人手で対応する場合、対応に時間がかかることはもちろん、時にはミスも発生します。
システム運用担当者による対応が必要になった場合、そのシステムに責任を持つ担当者に通知を行いインシデント対応を開始します。担当者は、一般的に専用のアプリや電話・メール・チャットで通知を受けます。適切な担当者に通知する必要があるため、どのようなアラートを受け取った場合に、誰に通知すべきなのか、明確にしておくことが重要です。また、当番の担当者が対応できない場合に備えて、バックアップの仕組みも構築する必要があります。
運用担当者がインシデントにアサインされれば、次は原因を特定し、解決するステップに入ります。原因を特定するための情報収集を行い、必要であれば専門のエンジニアやベンダーなどに対応を依頼して、原因特定と復旧作業を進めます。また、影響の大きいインシデントであれば、進捗状況や影響範囲について、社内の関係者(経営者やカスタマーサービス等)にも適切な情報共有が必要になります。
今後のインシデントの未然防止や運用プロセスの改善に向けて、「事後検討レポート(ポストモーテム)」を作成したり「運用プロセスの見直し」を行うステップです。各インシデントの対応履歴の記録とMTTA/MTTRなどのKPIを可視化し、見直しを行うための仕組みが必要になります。将来的なインシデントの発生を防ぐには、組織内での情報・教訓の共有が大切です。また定期的なレビューを行ない、インシデント対応の仕組みや体制を見直すことで、より効果的な対応が可能となります。
LINE社は多くのユーザーが利用するメッセージアプリや、決済サービスなどを提供しており、エンジニアも多数在籍しています。そのなかでも2016年から運用しているプライベートクラウド「Verda」では、同社がサービスを提供するにあたって必要なシステム基盤が展開されており、80名の開発者がさまざまなサービス開発やインシデント対応に関わっています。ここからは、PagerDutyの導入事例内容から読み取れる、LINE社の具体的なインシデント対応改善事例を紹介します。
LINE社では、Slackの専用チャンネルに投稿されるアラートを開発者が見て、気付いたメンバーが自発的に対応していました。しかし、アラートが多いと「どれが最も重要なのか・だれが対応するのか」なのかが判断しづらく、迅速な対応ができないこともありました。
インシデント対応を、外部のMSP(マネージドサービスプロバイダ)企業に依頼する選択肢もありましたが、インシデントを検知してから担当者に通知するまでを文書でマニュアル化しなければなりませんでした。それならコードを書いたほうが速い、という判断でPagerDutyを使うことになりました。
LINE社では、緊急対応が必要なインシデントに24時間体制で対応するオンコール対応を、それぞれのサービス開発チームで体制を組んで実現しました。1週間あたり2人のエンジニアがチームごとにつく体制をつくり、アラート発生時には電話・アラート音で担当者に通知しています。担当となる頻度はチームの規模によって異なり、月に1~2回巡ってくる体制です。
また、Slackに専用チャンネルを設け、PagerDutyからの通知を受けたタイミングで、APIを使ってサポート担当者のメールアドレスを返信するように環境を構築。このシステムにより、メンションする担当者を自動的に割り当てる試みを実施しました。対応内容は、別途課題管理アプリケーションとも連携してチケット化することによって、「チーム内でインシデントに対応しているのはだれか」など、進捗状況もわかりやすくなりました。この結果、アラートの件数も減少しました。
アラートの監視とシステム担当者への通知を外部委託すると、大量のアラートが発生した場合に適切な対応ができなかったり、担当者に通知するまでに時間を要することがあります。これは、インシデントを検知してから担当者に通知するまでの手順を文書でマニュアル化した上で、委託先が人手で対応するためです。
一方、「トリアージ」「動員」を自動化するツールを活用して自社運用する場合は、アラートが発生してから担当者に通知するまでの時間を数秒に短縮することができ、通知漏れなどのミスも減らすことができます。また「トリアージ」段階で自動診断の機能を活用して、原因特定に必要な情報を収集しておけば、担当者が問題解決を素早く行うことができます。復旧作業を自動化すれば、担当者に対応を依頼することなく、自動復旧させることも可能です。
緊急性のないインシデントで夜中に起こされたり、一部の担当者にインシデント対応の負担が偏らないよう、アラート数や担当者毎の通知を受けた回数・時間帯などのデータを可視化し、運用を最適化する工夫が必要です。同社の事例ではメンバーに電話がかかるようになったため導入後の現場で戸惑いが見受けられました。しかし、インシデントの優先順位を決めてアラートを減らす仕組みをつくることで、メンバーへの電話が減るように工夫しました。さらに、各チームと対話してアラートの定義づけを行ない、部門や担当者を明確に設定しているほか、インシデントの対応中に別のコールが重ならないように体制が整えられています。
インシデント管理・対応ツールを導入することで、エンジニアの負担を軽減し、問題解決をスピーディーに行なえます。ツールによっては「動員」部分の機能しか提供していなかったり、連携できる外部ツールが限られているなど特徴が異なるため、自社に合ったものを選ぶことが大切です。LINE社はPagerDutyを導入し、重要なアラートが迅速に開発者に届く仕組みを実現しました。また、PagerDutyのAPIを活用し、Slackと連携させることで担当者にメンションを行う仕組みを構築したり、課題管理アプリケーションとも連携してチケット化を行い、進捗状況を記録・共有することで業務効率を高めています。
「システム運用監視体制」を整備しておくことで、インシデントが発生した場合でも迅速に解決に導くことが可能です。日々の運用状況を可視化し、プロセスや体制を継続的に改善することができれば、インシデントの発生を最小限に抑え、エンジニアや関係者が(インシデント対応以外の)本来の業務に注力できるようになります。
PagerDutyを導入することで、本記事で紹介した「トリアージ」「動員」部分を含め、インシデントライフサイクル全体を効率化し、工数削減と迅速なインシデント解決を実現できます。また、PagerDutyでは自社のインシデント対応プロセスをこちらで公開しています。これからインシデント対応の体制・プロセスを整備しようとしている方は、参考にしてください。インシデント対応のための体制・プロセスを適切に構築することが、迅速で効率的なインシデント対応につながります。自社の状況やニーズに合わせて、適切な体制・プロセスとそれを支えるツールを選択してください。
▼こちらの記事もおすすめ
> システム障害を未然に防ぐ「インシデント管理」とは?
> インシデント対応を効率化する「10のチェックポイント」
700以上ものツールと連携。システム障害を自動的に検出・診断するだけでなく、適切な障害対応メンバーをアサインし、デジタル業務全体の修復ワークフローを自動化します。
目次