PagerDutyを用いたアラート対応改善の取り組みとTips紹介

はじめに

こんにちは！freee の Enabling SRE チームに所属している阿部寛明 (uryy)と申します。freeeのシステムを運用する際にはDatadogからの通知をもとにアラート対応するケースが多いのですが、組織拡大により従来の方法ではうまくワークしない箇所もでてきたので改善に取り組んでおります。今回はその一環で進めているPagerDuty導入の取り組みとその際に気づいたTipsについて紹介します。

PagerDutyについて

PagerDutyは監視ツールやアプリケーションからのアラートを受けてインシデント発生を担当者にオンコール通知するプラットフォームサービスです。オンコール機能だけでなく、受け取ったアラートのトリアージやシフトに基づいたエスカレーションも可能となっています。freeeでは下記図のようなシステム連携の環境構築を進めています。

現在のアラート通知

現状のアラート通知は下記図となっており、業務時間内はSlackチャネルに通知し業務時間外はSRE マネージャーにオンコール通知する形となっています。

この状況の問題点としては、アラート検知時の対応者が偏る傾向にあることや対応のナレッジが属人化されてしまう点があげられます。また、業務時間外の電話通知は内製ツールを利用しているのですが柔軟なエスカレーションルールが組めない点も課題としてあり、組織拡大してメンバーが増える中で解消したいモチベーションが強まってきました。

PagerDuty導入後のアラート通知

そこで、Pagerdutyを経由させることで改善を図れないかということになり導入を進めています。導入後のアラート通知は下記図となり、PagerDutyでトリアージした上で担当に通知する形となります。トリアージについては、類似アラートをグルーピングするAlert Grouping機能*1 を用ることで不要なインンシデント対応を抑えたり、アラートの仕分けを行うOrchestration機能*2 を用いてアラート内容に合わせた通知先を設定したいと考えています。これから運用設計をした上で順次導入していく予定です。

Tips紹介

ここからは、導入を進めるなかで分かったことや気づきについていくつか紹介します。

Datadogからのアラート連携について

Datadogからのアラート連携は公式Docs 通りに進めると比較的簡単にできます。設定は簡単ですが、PagerDuryへの連携方法はService*3 に直接アラートを送る方法と Event Orchestration*4 を通してアラートを送る方法がありどちらを利用すればいいのか少し迷いました。Serviceとはチームが運用・管理等するコンポーネントのことで、Event Orchestrationはアラート内容に基づいてServiceにルーティングするための仕組みとなります。複数のチームにまたぐようなアラートを受け取る場合、Serviceだとアラート通知側(Datadog)とPagerduty側で複数の設定が必要になり手間となります。一方、Event Orchestrationの場合、Event Orchestrationの一機能である Global Orchestration*5 を利用することで複数のServiceにまたいだアラートを一元的に受け取ることができるので設定箇所が１つで済みます。

トリアージ関連

アラートの仕分け

Global Orchestrationを用いてアラートを仕分ける方法は下記図のように条件分岐を追加していくことで実装できます。

ルールはアラート内容を元に作成できるので、特定のキーワードやタグ情報に基づいてServiceに通知させることが可能です。例えば、下記アラートのalert_priority に基づいてルールを設けたい場合は

[TEST] Pagerduty Alert invoice が発生しました

{
    "class": "query_alert_monitor",
    "component": "avg(last_5m):avg:kubernetes_state.deployment.replicas_desired{*} > 100",
    "custom_details": {
        "alert_priority": "P1",
        "body": "@pagerduty-hoge 
テストアラートです 

2021-07-22 13:45:10 [INFO] User '34521' started session
2021-07-22 13:46:15 [DEBUG] User '34521' requested resource 'Homepage'
2021-07-22 13:46:17 [WARNING] Slow response time for 'Homepage' resource
2021-07-22 13:47:25 [DEBUG] User '34521' requested resource 'ProductPage'
2021-07-22 13:48:30 [ERROR] 'ProductPage' resource not found
2021-07-22 13:49:01 [INFO] User '34521' ended session

（略）

イベントルールの設定画面の event.custom_details.alert_priority を使い設定できます。下記図では event.custom_details.alert_priority が P1 にマッチする条件となります。

加えて条件にマッチした場合のアクションを設定できます。「Add incident note」機能を用いると簡単な手順やURLリンクを記載できるので、アラートと紐づけることで対応効率化に繋げられそうでした。実際にどの粒度の情報を載せると良さそうなのかは社内で検討中です。

グルーピング

Paderdutyでは検知したアラートを全てインシデント起票するのではなく、類似するアラートや特定の条件にマッチしたアラートをグループピングすることでノイズ低減ができます。グルーピングの方式は３つあるのですが、その中でもIntelligent Alert Grouping は PagerDuty側のアルゴリズムで類似アラートをグルーピングしてくれます。ノイジーなアラート通知を削減したいfreeeにとっては嬉しい機能でした。Intelligent Alert Grouping はマネージドサービスとして利用する形になりますが、ユーザーで設定したい場合は Alert Content か Time only を利用する形となります。

エスカレーションについて

トリアージ後、アラート通知を受けるメンバーをアサインするのはEscalation Policies機能*6 で設定します。Escalation Policiesの設定方法は２通りあり、直接ユーザをアサインする方法と、あらかじめスケジュールを作成した上でアサインする方法です。freeeのように複数の組織があり組織毎にエスカレーションルールを柔軟に変更したり組織をまたぐエスカレーションを実装したい場合は後者の方がマッチしていそうでした。

スケジュール方式の場合、以下のようにレイヤー毎に輪番を設定し各レイヤーをマージした Final Schedule が実際にオンコール対応するスケジュールとなります。

作成したスケジュールを元にEscalation Policiesを作成します。下記の場合、Team Aのオンコール担当が取れないと30分後にTeam Bのオンコール担当にエスカレーションされます。

このあたりの設定をGUI上から行うと煩雑になってしまうのでTerrafrom化は必要な箇所だと思いました。

Slack連携について

SlackのようにPagerDutyから連携する先の設定はExtensions機能から行います。SlackにはPagerDuty appがあり、/pd コマンドでPagerDutyの各種操作ができます。例えば、/pd trigger コマンドを使うとSlack上からインシデント作成ができます。

kodekloud.slack.com

また、Slack設定にあるCreate a Slack thread for all incidents を ON にすることで、インシデント毎にSlackチャネルを作成できるので、Slack上でインシデント毎にチャネルを分けて対応するインシデント運用が可能になります。

チャネルを分けるメリットとして、PagerDutyのポストモーテムにはTimeLine機能があり連携先の情報を時系列で取り込むことができるのですが、Slackの場合はチャネルを指定してから取り込むのでまとまっていると楽に取り込めます。障害対応時の時系列情報をまとめるのは手間なことが多いですが、こういった機能を使うことで効率化が図れそうです。