NTTドコモ様事例

ブランドスローガン「あなたと世界を変えていく。」のもと、積極的に事業領域を拡大する株式会社NTTドコモは、通信を土台とした新たな生活や社会の実現に向け、コンシューマーの多様なニーズに応えるサービスを次々に生み出しています。これらのサービスや、サービスを実現するためのプラットフォームの企画、開発、運用を担うサービスデザイン部では、デバイスのお試しサービス「kikito」や、サービス開発を効率化するための統合API基盤「RAFTEL」などのインシデント管理にPagerDutyを採用。あらゆるムダを省いたスマートな対応を実現しています。

アラート対応のスピード感を損なう3つの課題

コンシューマー向けサービスのインシデント対応は、関係者間で発生状況を速やかに共有することに加え、短時間で事態を終息させ影響を最小化すること、さらには発生を未然に防ぐことが重要です。しかし、同社がPagerDutyを導入する以前は課題が山積みでした。当初、サービスデザイン部に在籍していた宮川倫氏は、次の3つの課題があったと指摘します。

課題1.アラートの集約と精査が困難
　複数の監視ツールからのアラートが精査されていないため、すべてに目を通す必要があり、対応すべきアラートを特定してアクションを起こすまでに時間がかかっていました。しかも、アラートの設定変更はツールごとに行う必要があり、使い勝手も異なります。ツールに精通していない当社チームでは手に負えず、開発委託先に設定変更を依頼することも少なくありませんでした。

課題2.NOCへのアウトソースに伴う煩雑な業務が発生
　また、24時間365日のシステム監視を担う社内のNetwork Operations Center（NOC）には、アラートに対応するための手順書を作成し、事前に渡しておかなければなりません。手順の変更や、監視対象のアラートの追加を行うたびに手順書の更新が必要で、その作業を開発委託先に依頼する手間もありました。

課題3.アラート対応をめぐるやりとりに多くの時間と労力を消費
　アラートの設定や手順書の更新を開発委託先に依頼するにしても、すぐに作業に着手できるわけではありません。まずは相談からスタートし、依頼した内容が意図したものになっていることが確認できるまでに多くの時間を要します。こうした非効率な運用に追われ、サービスの機能追加や改善、より信頼性の高い運用環境の実現といった本来業務になかなかリソースを割けない歯がゆさもありました。

本来業務のサービス開発に注力すべくインシデント対応の変革に着手

　インシデント対応プロセスに稼働時間の多くが取られ、本来業務に集中できない現状を解決するには、もはや小手先の業務改善では限界がありました。「新しいツールの検討は、こうした仕組みを変えたいという思いがきっかけです」と宮川氏。求められたのは、緊急度の高いアラートを適切なタイミングでしかるべき人が受け取り、一刻も早く対応に着手できる仕組みづくりです。
　そこで、同社が着目したのが、他のプロジェクトチームで活用されていたPagerDutyでした。目指すべきインシデント対応を可能にする十分な機能を備えているのはもちろん、社内に蓄積されている知見を共有できる期待感もあり、導入決定には多くの議論を必要としませんでした。

月間10,000件ものアラートが1,000件へ、大きな成果を創出

　PagerDutyが日々のインシデント管理を支えるプラットフォームとなった同社では、複数の監視ツールからのアラートをPagerDutyで集約。発報条件のチューニングにより、月間10,000件ものアラートが1,000件程度に減少。平均確認時間（MTTA）は3～5分、平均修復時間（MTTR）は2時間15分を実現しており、クリティカルではないアラートへの対応時間は月40時間ほど削減できています。

アラートの集約・精査が可能に

　アラートの集約と精査が可能になったことで、「本当に対応が必要なアラートだけを、電話やメール、Slackなど、緊急度に応じて個人が設定した最適な通知手段で受け取れます。開発委託先に依頼していた設定作業も9割方は社内で行えるようになり、アラートの発生状況についてチーム内で共通認識を持てるようになりました」と宮川氏。

NOCレスな運用監視へ

　手順書の準備や更新が煩雑だったオンコール対応にも変化が生まれています。PagerDutyの導入を機にチーム内でできることが大幅に増えたため、NOCへの依頼領域を改めて精査。NOC向けに手順書の準備や更新を行う手間を考えると、NOCを利用しないという選択肢が出来たのは大きな効果です。実際、新規プロジェクトではNOCレスな運用監視を基本とする動きが見られます。
　また、ライブコールルーティング機能のおかげで、電話連絡も大幅に効率化されました。「1つの電話番号でオンコール状態にある必要な相手とすぐに連絡が取れるので非常に便利です。エスカレーションルールを自分たちでコントロールできて、電話番号は常に1つ、というのがいいですね。人事異動の際にも柔軟に対応できます。」（宮川氏）

開発チーム内だけでなくビジネスチームも巻き込んだ重要アラートの共有・対策が可能に

　さらに、開発チーム体制をフロントエンドとバックエンドに分けているkikitoのプロジェクトを担当する大石氏は、「クリティカルなアラートは両チームに同時に通知するという設定も可能です。おかげで関係者全員が速やかにアラートに気づき、同じ情報をもとに即時で会話できるようになりました。しかもクリティカルなアラートだけが通知されるので、アラートが上がったら何らかの対応が必要だという意識を共有できています」と語ります。
　PagerDutyと連携するSlackのチャンネルには開発メンバー以外にビジネスチームのメンバーも追加されているため、すべての関係者が各々の立場で速やかに必要なアクションを起こせるようになり、チーム間のコミュニケーションに伴うタイムラグも解消。意外なところでは、「UIが直感的でわかりやすいので、組織再編に伴う担当者の引継ぎも速やかに行えました。学習コストを抑えられるだけでなく、スピード感も以前とは全く異なります」と大石氏。

インシデント管理の一元化と自動化を目指して全サービスへのPagerDutyの導入に期待

　PagerDutyの有用性を高く評価するサービスデザイン部では、導入範囲の拡がりが生み出す新たな効果に期待を寄せています。「社内のあらゆるサービスがPagerDutyを活用するようになれば、連携しているシステム間でインシデント状況を一元管理できるメリットもありそうです。今後はPagerDutyの中で対応状況の可視化、インシデントのクローズまでを完結できるように、インシデント管理に関わる業務プロセスのさらなる自動化を進めていきたいですね。」と大石氏。
　「大量のアラート発生により真に対応が必要なアラートを見逃してしまうような状況を減らしたい」と宮川氏が願うように、PagerDutyは一人ひとりの生産性を高めることで、これまでのインシデント対応の”当たり前”を大きく塗り替えようとしています。