クラウドはもちろん、物流を支えるオンプレミス環境にPagerDutyを活用
オイシックス・ラ・大地は、食品宅配のサブスクリプションを主な事業としており、有機野菜や特別栽培の野菜、できる限り添加物を使用せずに作った加工食品などを取り扱っている。社名からイメージできるように、複数の企業が統合してできた企業だ。2017年にオイシックス株式会社と株式会社大地を守る会が統合し、2018年にはらでぃっしゅぼーや株式会社が加わった。この経営統合最中である2018年1月からPagerDutyを利用しており、林氏も同じころ入社している。
同社の従業員は2000人ほどで、そのうちエンジニア職は約100人。林氏が所属するシステム基盤部 SREセクションには2023年1月現在11人のメンバーが在籍している。同社のエンジニア組織のカルチャーについて林氏は「セクションごとにかなり裁量があり、各セクションが掲げた理念に向かって仕事をしています。SREセクションは、社内で運用するシステムの信頼性に焦点を置き、より良くしていくことをミッションとしています」と語る。
SREセクションの業務の一つがシステムの可視化。どこでどのような事象が起きて、今後どのように推移していくか、現在の状態は良好かどうかをテクノロジーによって可視化する。もう一つが自動化による効率化だ。人の手で行う繰り返し業務をソフトウェアで自動化する。これにはインシデント対応もあり、PagerDutyを使った自動化、効率化も行われている。林氏自身はマネージャーとして、システム全体を管理し、メンバーのフォローも行うなど、チームがうまく動けるような活動をしている。
オイシックス・ラ・大地のITインフラは、オンプレミスとパブリッククラウドであるAWSのハイブリッド環境となっている。システム特性について林氏は「オンプレミスではお客様に食品をお届けする物流拠点のネットワーク機器が稼働しています。一方でパブリッククラウドではECサイトのシステムなどをAWSに置いています。サーバーは600台ほど運用しており、各システムは複数のモニタリングツールによって監視し、それらからのアラートをPagerDutyで受けてインシデント対応を行っている形です。PagerDutyには豊富なインテグレーションの機能があり、大抵の監視ツールを使っていてもオンプレミスやクラウドに関係なく連携ができ、適切な対応につなげられる安心感があります」と語った。
システム運用体制上、PagerDutyが発するアラートを受けるのは、SREセクションの11人に加え、アプリケーション開発者やブランドごとのエンジニアなども含めた40人ほど。電話でのコール（オンコール）に待機するのはSREチームの8人から週次でプライマリ、セカンダリの2人が割り当てられる。なお、一部のアプリケーションについては直接開発者に割り当てており、コンテナ化され担当範囲が明確な場合があるからで、今後もオンコール先の分割と最適化を進めていく予定だ。
モニタリングツールにおいてどのチームにどんなアラートを出すかを整理しPagerDutyを通じて発報する。林氏は「PagerDutyの優れた点がAPIキーごとに通知先をたくさん並べられることです。モニタリングツール側で切り分けを設定して、どこに通知するかをコントロールしています」と説明した。
MSPからPagerDutyへの移行でMTTA（平均確認時間）は約30〜50%改善し、コスト削減も実現
PagerDutyの導入は、ちょうど林氏が入社したころにSREチームで検討していた。PagerDuty導入の背景として、当時はインシデント対応をMSP（マネージドサービスプロバイダ）企業に委託していたものの、柔軟な対応ができないという課題があったからだ。
「MSP事業者の場合、たとえば、『今日はほかに用事があるので電話は受けられない』『休みなので対応できない』といった変更をいちいち連絡する必要があり、個々の対応もチケット制で煩雑でした。SNSなどを通じてPagerDutyの存在を知り、導入を検討することにしました。当時からPaerDutyはインシデント管理のサービスとして高いシェアを持っていたため、PagerDutyを導入するか、MSP事業者への委託を継続するかの二択でした」（林氏）
PagerDutyへの移行によって、MTTA（平均確認時間）は約30〜50%程度の改善を実現した。MSP事業者に委託していたころは、MSPの担当者側で、通知を受けてから手順書に従った判断するまでに15分〜20分かかっていたが、10分未満に短縮している。また、コスト面でもインパクトがあった。MSP事業者の料金体系がサーバー台数に応じたものだったからだ。一方、PagerDutyはアカウント数に応じた料金のため、当時SREセクションの数名だけの利用となったことで、大きなコスト削減を実現した。
インシデントの社内対応への移行の背景には、3社の経営統合もあった。各社で展開するブランドがあり、システムもそれぞれ異なる。インシデント自体も増加し、対応のための発報のやり方などもブランドのポリシーによって変わるため、きめ細やかなサポートが必要となる。
「夜中でもすぐに対応してほしいというチームもあれば、システムが安定しているのでメッセージ通知のみで良いというチームもあります。多様なルールを整理してPagerDutyで最適化を続けています」（林氏）
オンコール担当者のウェルビーングと助け合い文化を実現する「優しさのOverrides」機能
現在、各チームの要求に対応するPagerDutyの最適化が行われているが、それに至るまでには時間を要した。そのきっかけは2021年7月に実施したメインのデータベース移行だ。移行に伴い、より細かなイベントを監視するためモニタリングツールを変更した。すると監視対象が広範囲になり、アラートの発報が増えてしまった。そこで、SREセクションでは発生するインシデント情報を蓄積しながら地道に最適化を行っていった。
「オンコール担当は、夜中に2〜3回電話で起こされることもありました。週に何度もあるとかなりきつくなります。なんとか改善したいという思いで取り組みました。毎週月曜にチームミーティングを行い、集まったインシデントを一つひとつ見ながら、どう処理するかを話し合って設定していきました。半年から1年弱の期間はかかりましたが、夜中に起こされる回数も激減しました」（林氏）
PagerDutyでの自社運用に移行して訪れた変化に、通知の柔軟なコントロールによる恩恵がある。従来は電話とメールだけだったが、PagerDutyのスマートフォンアプリで個々のメンバーが柔軟に設定できるため、担当者のストレスが軽減された。林氏はPagerDutyアプリで重宝している機能として「Snooze」「Urgency Use Case：Support Hours」「Overrides」を挙げた。
Snoozeは、状況に応じてインシデントを一定期間保持し、対応を後回しにできる機能。移動や会議などですぐに対応できないときや、サイトの負荷がかかることがわかっている時間帯、業務時間外で翌日対応すればいいようなときに使う。Urgency Use Case：Support Hoursは、対応可能な日時を指定して、その時間帯は通知に気付きやすくして、それ以外の時間帯は控えるというもの。
林氏が最も気に入っている機能がOverrides。これは、オンコールの担当を上書きする機能だ。林氏は「週次のオンコール担当が割り当てられていても、前日の深夜に起きて対応したようなメンバーがいたら、その代わりにほかの人を割り当てることができます。私はこれを『優しさのOverrides』と呼んでいます。オンコールの負担をチームで分散できる素晴らしい機能です」と説明した。
PagerDutyをさらに使いこなして、インシデント対応の自動化を目指す
オンプレミスとパブリッククラウドのハイブリッド環境でシステムを運用しているオイシックス・ラ・大地は、従来アウトソースしていたインシデント対応をPagerDutyによって社内のメンバーで対応できるようにした。以前は週に何度も深夜対応しなければならないこともあったSREチームであったが、細やかな最適化の甲斐あって深夜対応は月に1度程度まで減った。
林氏は「PagerDutyはオンプレミスやクラウドに関係なく、通知先を設定して最適化できるツールです。メンバーのみんなも『オンコール対応が怖くなくなった』と言っています」と成果を語った。
SREチームの今後の展望として、林氏は、インシデントの自動回復にチャレンジしたいと答え、PagerDutyへの期待を込めて次のようにコメントした。
「インシデントが起きた際、自動的に修復されるのが理想です。PagerDutyが自動診断や自動修復などができるジョブスケジュールツールのRundeckを買収したので、その機能を使ってみたいと思います。たとえば、当社のシステムはJavaで開発されていて、メモリ容量が足りず処理が止まってしまったときに再起動する必要があるのですが、これを自動化できるといいなと思っています。AI機能も気になっていて、これまでのアラートの傾向から自動で判断して処理をするなど、メンバーの負担を減らす機能も使ってみたいです」（林氏）
