Qiita様事例

サーバーダウン、サイバー攻撃による機密情報の漏洩、プロダクトの不具合に起因するトラブルの大量発生等。あらゆる事業活動において、想定外のタイミングでの「インシデント」の発生はつきものです。
これらインシデントの発生から解決までに時間がかかりすぎてしまうと、ユーザーの体験価値が低下するだけでなく、企業やプロダクトの価値を大きく棄損し、中長期的にはエンジニアの疲弊によるり優秀な人材の流出にもつながってしまいます。それ故に、あらゆる企業にとって成熟したインシデント対応オペレーションの構築は、不可欠な経営マターだと言えるでしょう。
そんなインシデントにおける対応ソリューションを展開しているのが、同領域でのグローバルリーディングカンパニーである「PagerDuty」です。同社では、インシデントを「何らかの対応が必要な課題」と定義し、早期解決に向けた支援はもちろん、運用担当者の負荷軽減や将来のインシデントの未然防止に向けて、各種機能を実装・展開しています。
今回は、PagerDutyの国内初期ユーザーであるQiitaでの運用ケースについて、QiitaエンジニアとPagerDutyコンサルタントの対談を通じて深掘りしていきながら、同プロダクトが提供する顧客価値やそのバックボーンにある思想等を探っていきます。

システム障害からリコール対応まで、幅広く活用されているPagerDuty

水井悠太（以下、水井）：本日はよろしくお願いします！Qiita社は長年利用していますが、読者の中にはPagerDutyを知らない方もいると思いますので、改めてPagerDutyの概要と他社ソリューションと比較した際の特徴を教えてください。

山田索氏（以下、山田）：まずは概要をお話しします。PagerDutyは、2009年に米サンフランシスコで設立されたインシデント対応ソリューション企業です。創業以来、世界80ヵ国以上で1.9万社以上のクライアントに導入いただいており、累計6億以上のインシデントに対応してきました。サービスの細かい特徴は後述するとして、大きな特徴としてプロダクトをAIや自動化によってモダン化していることから、現場のエンジニアがより生産性の高い仕事に注力できるように日々ご支援しています。

水井：多様なインシデントがありますが、PagerDutyはどのようなインシデントに対応しているのですか？

山田：前提として弊社ではインシデントを「何らかの対応が必要な課題」と定義していて、ITシステムの障害を引き起こしている課題や、近いうちに障害につながるような課題全般に対応するソリューションとなっています。似たような定義に「アラート」があると思うのですが、これは一部のシステムの異常を知らせる連絡のことを指しますよね。この中のごく一部がインシデントという分類をしていて、膨大なアラートの中から対応が必要なものを見つけて適切な対処へとつなげる必要があることから、導入いただくケースが多いです。ユースケースとして多いのは、今お伝えしたようなシステム障害やセキュリティインシデント対応なのですが、それ以外にも面白いところとして、北米のスーパーで販売商品のリコールがあった際にフロアマネージャーに知らせるような仕組みで使っていただいている例もあります。

水井：インシデントと聞くとシステム障害やセキュリティ事故等をイメージしますが、店舗でのリコールのようなケースでも活用されているんですね！

山田：対面での人の対応が必要なオペレーションはまだまだたくさんあるので、そういったところでの用途も広がりはじめている印象です。

水井：海外ではシスコシステムズさまやNetflixさま等、多くの有名企業が利用していると思いますが、国内ではどのような会社が使っているのでしょうか？

山田：まだ日本法人がない段階からお使いいただいているお客さまが多いです。また、NTTドコモさまやヤフーさま、LINEさま、オイシックス・ラ・大地さまのような、エンジニアさん自身が運用改善に向けて積極的にアンテナを張ってソリューションを探しているような企業が多い印象ですね。

一連のインシデントライフサイクルをカバーするソリューション

水井：続いて、他社ソリューションと比較したPagerDutyの特徴も教えてください。

山田：大きく分けて生産性、柔軟性、信頼性の3点が他社との違いになると考えています。まず「生産性」についてですが、PagerDutyでは「検知・トリアージ・動員・協力/解決・予防（学習）」という、一連のインシデントライフサイクルを通してインシデント対応を支援しています。検知に特化したツールや動員を効率化するソリューションを展開する会社はたくさんありますが、これら全体に対して一気通貫で対応しているところはPagerDutyだけではないかと思います。

山田：次に「柔軟性」についてですが、PagerDutyではモニタリングツールやコラボレーション・チケット管理ツール等、700以上の外部サービスと連携しています。ですので、オンプレも含め、どのようなシステムにも対応できるよう設計されています。

山田：そして3つ目の「信頼性」についてですが、当然ながらPagerDutyは「止まることが許されない」サービスです。もちろんメンテナンスウィンドウ（定期メンテナンス枠）は設定しておらず、インシデントの数もゼロではありませんが、万が一発生したとしたら迅速に対応にあたると共に、インシデントの影響範囲と原因、再発防止策を公開するなどして、サービスの信頼性向上に努めています。

水井：インシデントライフサイクルについてですが、ここ最近で引き合いが特に多いのはどの部分になりますか？

山田：もともとは、創業時の事業領域ということもあって3番目の「動員（Mobilize）」部分へのニーズが大きかったのですが、最近では2番目の「トリアージ（Triage）」や4番目の「協力/解決（Resolve/Collaborate）」部分に特に価値を感じられているお客様が多い印象です。

山田：例えば「解決/協力」部分のソリューションとしては、GitHubやJenkins等のCI/CDツールとの連携が挙げられます。仮に最近、システムで何らかの構成の変更が発生していた場合、「GitHubでこういうコードの変更がありますよね」という表示をしてあげることで、該当する変更がインシデントの原因となっていないかの情報提供をします。

山田：また、過去の類似インシデントの対応履歴の情報や、他サービスで現在発生している関連性の高いインシデントの情報等から原因特定のための手がかりも出します。これらの情報を迅速に提供することで、次なる打ち手をスピーディーに策定できるように支援しているわけです。

Qiitaチーム内で「サービスの根幹はみんなで守る」という意識と体制を醸成

山田：ここまではPagerDutyの概要についてお話しさせていただいましたが、次に、Qiitaさんでの活用内容について詳しく教え一連のインシデントライフサイクルをカバーするソリューションQiitaチーム内で「サービスの根幹はみんなで守る」という意識と体制を醸成システム障害からリコール対応まで、幅広く活用されているPagerDutyてください。そもそも、何がきっかけでPagerDutyを導入することになったのでしょうか？

水井：実は私がQiitaへと転籍してきた2020年時点では、既にPagerDutyが導入されていた状況だったのですが、担当されていた方から聞いた内容をお伝えしますね。
PagerDutyを導入したのは2016年で、当時のQiita株式会社（旧Increments株式会社）では障害発生の通知をSlackで受け取っていました。業務時間中であればすぐに気がついて対応できるのですが、業務時間外だとなかなかそうもいきません。通知に気付くために各メンバーが、いわば職人芸のような感じで工夫して対応していく必要があったのです。
実はこれ、私がQiitaに転籍する前の会社や前職の経験とも重なっていて、当時障害発生時の機械的な連絡方法としてチャットツールやE-mailを利用していました。どちらも日頃から通知を受け取るように設定し、見逃さないような状態を各々が工夫していました。また、深夜でも可能な限り連絡がつくように連絡先をドキュメントに記載したり、チャットツールのプロフィール欄に電話番号を設定し、何かあったらそこに電話をしてもらうといった、実にアナログな方法で障害対応を行っていました。

山田：まさに職人芸ですね（笑）

水井：このような方法を取っていたため、どうしても通知の見逃しや対応出来る人が集まれないことによる属人化等が発生してしまい、結果として原因の特定に時間がかかり、障害も長期化する傾向にありました。またプロダクトに対してだけでなく、常に「通知に気付かなきゃ」というマインドが頭にあることで、精神的な負荷にもなっていた状況です。

山田：多くのお客さまでもペインポイントになる「深夜帯での動員部分」の課題が、Qiitaさんでも顕在化していたわけですね。

水井：確実にインフラのオペレーションが出来るエンジニアに対して、業務時間内外問わず連絡を取れる手段を構築したいということで、2016年に電話連絡・通知を行うツールとしてPagerDutyを導入しようということになりました。当時のエンジニアが「5日連続でPagerDutyから電話があった」と回想していましたね（笑）

山田：なるほど。PagerDutyを導入してから、どのようなプロセスでインシデント対応の効率を上げていかれたのでしょうか？

水井：実は、PagerDutyを効果的に利用できるようになったのは最近のことです。と言いますのも、今までは様々な都合からPagerDutyのアカウントを持つ人が限られていて、PagerDutyのアカウントを持つエンジニアが集中して対応を行っていました。
そんな中、2019年頃にインフラエンジニアが不在となる時期があって、インフラもできるアプリケーションエンジニアが日々の障害対応を行うようになったのです。でも、結局はインシデント対応の負荷がそのエンジニアへと集中することになってしまい、対応品質やスピードがまばらになったりと、様々な問題が発生する事態になりました。
そこで、当時あるエンジニアがPagerDutyの「On-CallSchedules機能」を導入しようと提案してきて、それに併せて従来からの課題だったライセンス数も増やすことになりました。

水井：メンバーにライセンスを付与してOn-CallSchedulesを導入したことで、「サービスの根幹はみんなで守る」という意識と体制が醸成されるようになったわけです。

山田：Slackのチャンネル向け通知だとそのチャンネルに参加している全員に通知が飛ぶので、誰かがオーナーシップを持って進めていくことは簡単ではないと思います。通知に気付いても「今は取りたくないな」となるケースもあり、担当者がつくまでに時間がかかってしまうという。

水井：結果、対応できるエンジニアがチケットを取り、余計大変になるという流れですよね。ちなみに、On-CallSchedules導入時にはじめてPagerDutyを触るエンジニアも多かったことから「PagerDutyとは」「On-Callとは」「On-Callshiftとは」等、PagerDutyをどのように使っていくかについても広く社内に展開する動きが活発化していきましたね。

プリベンティブ（予防的）な運用体制に向けて

山田：水井さんが転籍されてからのお話で結構なのですが、PagerDutyをうまく活用したことによる具体的な成果を教えてください。

水井：まずは、通知から解決までの時間が確実に短縮しました。それまで1時間程かかっていた時間が、現在では平均して5～10分、長くても30分くらいに収まるようになりました。また、PagerDutyからの通知への対応率は90％となっていて、障害発生時に迅速に関係者へと通知や連絡ができるPagerDutyならではの効果だなと感じています。
さらに、過去3ヵ月間にPagerDuty経由で対応したエンジニアは社内の83％にも上っています。

山田：過去3ヵ月、一度もアラートを受け取っていないエンジニアは2割ということですね。

水井：はい。適切なメンバーに連絡するだけでなく、エスカレーション機能も活用することで、インシデントのいち早い復旧に向けた体制ができていると感じます。また定量的な内容ではないのですが、SlackやE-mailを常に確認する必要もなくなって、対応を行うエンジニアに心の余裕ができていると感じますね。そういう意味で、PagerDutyは福利厚生の1つだと言っても過言ではないなと感じています。もちろん、PagerDutyからの電話連絡が来るとすこし悲しくなりますけどね（笑）他のユーザーでは、どのような成果が出ているのでしょうか？山田：様々な成果が出ているのですが、例えば日本のあるお客さまでは、従来平均で10分かかっていたMTTA（平均確認時間）が約1分に短縮しました。また、早期検知によってMTTR（復旧、修復、対応、解決までの平均時間）も短縮され、ほとんどのインシデントが発生当日に解決できているとのお言葉を頂戴していますね。さらに、インシデントデータの蓄積・分析によって再発防止にもつなげられており、結果として自社提供サービスの品質向上につながっていたり、エンジニアへの負荷の劇的な減少とそれに伴うコスト削減も、導入に伴う成果としてコメントをいただきました。

同様の海外事例ですが、SAP様ではPagerDuty導入後、2ヵ月でMTTAが30%、MTTRが26%短縮されました。またIBM様ではインシデントの自己修復率が5～10%でしたが、PagerDuty導入後にその比率が65%にまで向上しています。今ご紹介したお客さまは、適切でタイムリーな情報が提供できる「プロアクティブ」の段階にあると言えますね。

水井：インシデント対応体制にも段階があるんですね。

山田：はい、いつもこのような図でご説明しています。

山田：PagerDutyを使い始めたお客さまの多くは2番目の「レスポンシブ（即応的）」の段階にいて、日本のお客さまもこの段階が多い印象です。その先で、PagerDutyをうまく使えていて標準化されたプロセスで運用できている段階が「プロアクティブ（能動的）」です。

水井：「プリベンティブ（予防的）」の段階のユーザーはどれほどいらっしゃるものなのでしょうか？山田：グローバルを見渡しても、まだほんの一握りですね。ここまでリフトアップするのが、我々のミッションだと捉えています。

日本のエンジニアが「未来を創る仕事」に集中するために

山田：今後、QiitaさんとしてPagerDutyを通じて「やってみたいこと」について、ぜひ教えてください。

水井：まだ我々はPagerDutyがもつ機能を十二分に使い切れていないのが現状だと思っていまして、その中でも直近では2つのことを進めていきたいと考えています。

まず1つ目は、ServiceDirectory（運用対象をまとめる機能）やチーム設定（障害対応するメンバーを選んでチームを作る機能）を活用し、障害対応の振り返りを行える体制を作ることです。

現在、障害発生後にポストモーテムを作成して振り返りをしているのですが、事象ごとにしかできておらず、3ヵ月毎や6ヵ月毎のように期間を定めた長期的な振り返りについてはまだまだできていないと感じています。せっかくPagerDutyにアナリティクス機能があるので、この機能をフル活用すべく、ServiceDirectoryやチーム設定等を適切な状態に変更して、複雑な手順なしで振り返りを行える状態を作りたいと考えています。もう1つ、障害対応の一部自動化も進めていきたいです。日々発生する障害の多くは対応する内容が定まっています。冒頭で山田さんがおっしゃったとおり、PagerDutyにはインシデント対応の自動化を支援する機能があるため、それを使って障害発生時に即時復旧できるような仕組みを積極的に構築していきたいです。

山田：ぜひ！追加で、中長期的にPagerDutyに期待されていることはありますか？

水井：期待で言うと、まずはインシデントのステータス変更履歴やNotesに記載した情報をGitHubのIssueやDatadog等の様々なツールと連携して管理できるようにしてもらいたいです。

山田：と言いますと？

水井：先ほどもお伝えしたとおり、弊社では全員がPagerDutyのアカウントを持っているわけではありません。ただし、障害の情報はエンジニアであれば誰もが確認できるような状態にしたいと考えています。情報がツール内に閉じてしまうと、情報の分断だけでなく、チーム外で連携して動く際の障壁にもなってしまうので、この辺りをもう少しシームレスにできたらいいなと考えています。

山田：なるほど。また追って、詳細を確認させてください。

水井：もう1つは「日本語化」ですね。PagerDutyのような素晴らしいツールは、ぜひ障壁なく、多くのエンジニアに使ってもらいたいと考えています。英語に慣れないエンジニア向けにPagerDutyを使うまでの機能説明等を、現在はアカウント発行毎に実施しています。いきなりUIとまでは言いませんが、せっかく日本法人が設立されたので、日本語のマニュアル・ドキュメント類等の情報を増やしてほしいと感じています。

山田：こちらについては目下進めているところで、UIの日本語化についてはリクエストを上げ始めたところです。そもそものマルチ言語対応を考えて作っているのか等、裏側のアーキテクチャ含めてフィジビリティチェックをしています。またナレッジベースについてですが、ローカライズのプラグインを入れて作ろうとしています。機械翻訳を活用しますが、日本のエンジニアでレビューを行います。主要なドキュメントは日本語で出てくるようにしたいと考えていますが、それらが整備されるまでは、Qiitaに設定ガイドを書いているので、ぜひそちらもご参照いただきたいです。

水井：ありがとうございます！楽しみにしています。それでは最後に、PagerDutyの中長期的な取り組みへのビジョンについて教えてください。

山田：エンジニアの皆さまの運用負担を減らし、「未来を創る仕事」に集中してもらうためには、日本のお客さまに合わせた形でプロダクトを提供する必要があると考えています。UIの日本語化もその一環です。日本のお客さまのユースケースやご要望を積極的に取り入れていき、さらに使い易く・また多くのお客さまに活用されるサービスにしたいと考えています。