PagerDutyの導入で確実に対応できるオンコール体制を確立
PagerDuty導入の検討は萬治氏が入社した2019年から行われていた。インシデント対応の基本的なルールづくりと導入の検証などを経て、2020年3月にはPagerDutyの利用を開始した。導入はスムーズにできたが、新しいルールのメンバーへの定着には苦労した。
「メンバーに電話がかかるようになったので、導入後は現場の戸惑いも見られました。そこで、インシデントの優先順位を決めてアラートを減らす仕組みを作る活動をしていきました。電話を減らし、インシデント対応を効率化する前向きな活動を行っていることの理解をしてもらい、新しい運用ルールの賛同を得ていきました」（萬治氏）
萬治氏は各チームと対話しながら、アラートの定義をして、部門や担当者を明確にするよう設定を行った。また、重要度の高いインシデントで電話をコールした後に対応中、別のインシデントのコールが重ならないような工夫もした。誰かがインシデント対応中は現在の状況をとらえているはずだから、その間のアラート発報は不要だという判断だ。
チームごとの週次のオンコール当番2名は、プライマリとセカンダリがあり、セカンダリの人がユーザーサポート担当者となり、緊急対応が必要な時にはプライマリ担当にオンコールを届けるフローとなっている。
「以前はチャンネルに投稿されたインシデントをみんなで見て、誰かが対応していたのですが、リアクションする人もいれば、しない人もいますので、状況が判断しにくかったのです。PagerDutyの導入によって担当者が明確になるメリットを感じています」（萬治氏）
アラート件数の減少もPagerDuty導入効果の一つだ。特にロードバランサーは、かつて週に60件の重要度の高いアラートが発報されていたが、今では全く発報されない週も多くなった。萬治氏らのチームは、ロードバランサーチームのプロダクション会議に参加して、アラートの種類や件数を調べて解決していったのだ。
萬治氏が気に入っているPagerDutyの機能に「routing_key」（Integration Key）がある。文字列ひとつでどのサービスチームに通知をするかの指定に使っている。「インシデントを発行するときに、認証情報などのアクセスキーなどを管理したり、サービスを特定する識別子を設定したりするなど、管理するものが増えることが考えられますが、routing_keyだけで管理できるのはとても便利です」（萬治氏）
