オンコール運用をPagerDutyへ - 移行して見えてきたこと

オンコール運用をPagerDutyへ ― 移行して見えてきたこと PagerDuty Tech Hub 2026 Akari Yamabuki Kensuke Kumaki © Finatext Holdings Ltd.

株式会社Finatext Finatext グループ ● グループのミッション "金融を "サービス" として再発明する" ○ 事業領域ごとにグループ会社やチームを設立してサービスを展開 ○ 国内のメンバー数 450人弱, うちエンジニア 120人程度 金融インフラストラクチャ データAI フィンテックシフト Brokerage Data AI Service Fintech SHIFT 証券サービスのインフラを提供する データとAIを利活用したサービスを提供する 金融サービス・ソリューションを提供する Insurtech Data AI Solution 保険サービスのインフラを提供する エンタープライズのデータAI基盤の構築を支援す る Credit 貸金・クレジットサービスのインフラを提供する Financial Research データで官公庁や機関投資家の意思決定を支援す る © Finatext Holdings Ltd. 1

登壇者紹介 ● 山吹 明里（Akari Yamabuki) ○ 株式会社 Finatext ○ Brokerage domain エンジニア ○ インフラエンジニア ○ X: @gurany_tou ● 熊木 健介（Kensuke Kumaki） ○ 株式会社 Finatext ○ Insurtech domain エンジニア ○ バックエンドエンジニア ○ X: @k_kumaki_ © Finatext Holdings Ltd. 2

はじめに ● 移行の背景 ○ これまで利用していたon-callツールがサービス終了になることがわかったので、 約6ヶ月かけてPagerDutyへ移行した ● 本セッションの内容 ○ それぞれのシステムや運用体制に合わせて、既存のon-call運用をどのように PagerDuty上に設計・移行したのか ○ 実際の移行を通して得られた知見や運用上の工夫、今後取り組んでいきたいこと © Finatext Holdings Ltd. 3

Brokerage domainでの取り組み © Finatext Holdings Ltd. 4

Brokerage domainのシステム構成 ● サービスによって、異なるon-callローテーションで運用している ● dev / stg / prod毎にアラートの通知先となるSlackチャンネルが異なる パートナーサービスA パートナーサービスB dev 環境 stg 環境 prod 環境 dev 環境 stg 環境 prod 環境 ・Slack通知: #service-a-dev-alert ・Slack通知: #service-a-stg-alert ・on-call: 開発チームA ・Slack通知: #service-b-dev-alert ・Slack通知: #service-b-stg-alert ・on-call: 開発チームB ・Slack通知: #service-a-prod-alert ・Slack通知: #service-b-prod-alert ... ••• 証券インフラストラクチャ（BaaS）- 基盤となるマイクロサービス prod 環境 dev 環境 stg 環境 ・Slack通知: #baas-dev-alert ・Slack通知: #baas-stg-alert © Finatext Holdings Ltd. ・on-call: 複数チームでのローテーション ・Slack通知: #baas-prod-alert 5

PagerDuty Serviceの基本設計 設計方針： サービス × 環境単位で PagerDuty Serviceを構成 ● BaaS・パートナーサービス × 環境でPagerDuty Serviceを作成 ● 本番環境のPagerDuty Serviceには、それぞれの運用体制に応じた Escalation Policyを個別に設定 【構成例： パートナーサービスAの場合】 パートナーサービスA (dev) PagerDuty Service パートナーサービスA (stg) PagerDuty Service パートナーサービスA (prod) PagerDuty Service service-a-dev service-a-stg service-a-prod © Finatext Holdings Ltd. #service-a-dev-alert #service-a-stg-alert #service-a-prod-alert 開発チームA用 Escalation Policy 6

Global Orchestrationによるルーティング BaaSではon-callに関して以下の要件があった ● 基本は複数チームで構成される共通のon-callローテーションへ通知したい ● 特定サービスでは、障害発生時に緊急対応が必要なため、担当の開発チームに直接 エスカレーションしたい -> 要件を満たすため、Global Orchestrationを採用 ● サービスからアラートを送る時に制御用ラベルを含めるようにし、 そのラベルに応じてEscalation Policyをoverrideするか制御する 通常 共通 on-call 用 Escalation Policy Alert BaaS (prod) Global Orchestration 担当開発チーム用 Escalation Policy 特定サービス © Finatext Holdings Ltd. 7

移行で一番悩んだ点 「平日営業時間中はon-call担当の電話を即座に鳴らさない」というルールをどう実現するか 既存のon-call運用 ● 平日営業時間中：Slack通知 → 10分間Ackなし→ on-call ● 営業時間外：即時on-call → Schedule × Escalation Policyで既存運用を再現 ● PagerDutyBotというダミーユーザをLevel 1に配置し、Scheduleで平日営業時間中のみアサイン ● 10分間AckされなければLevel 2のon-call担当者へエスカレーション ● 営業時間外はアサインなしになるため、即座にLevel 2のon-call担当者へエスカレーション 【営業時間中／営業時間外の挙動】 Level 1 平日営業時間中 営業時間外 PagerDutyBot アサインなし 10分 Ackなし Level 2 on-call担当者 on-call担当者 (即時呼び出し) © Finatext Holdings Ltd. 8

Insurtech domainでの取り組み © Finatext Holdings Ltd. 9

Insurtech Domainの構成 PagerDutyのサービス設計 Datadogで検知したアラートをPagerDutyで集約・管理し、オンコール担当者に通知 監視基盤 Datadog メトリクス / ログ / アラート クライアント PagerDuty アラート送 信 Technical Service Business Service (サービス単位) (インシデント管理) TS: core コア基盤 (全社共有) TS: BFF-A メール通知 保険会社A BFF 一括配信 External Status Page 保険会社B BFF (外部公開) Criticalのみ 各社BFF TS: BFF-B on-call担当者 (エスカレーション) 1. コア基盤で全体を監視 2. サービス単位のインシデント管理 3. IaCでの一元管理 • コア障害は全クライアントに影響する構造 • Technical Serviceでコア/BFF単位を管理 • アラート設定をコード管理 (IaC) • 共通基盤のメトリクス/ログをDatadogで 監視 • Business Serviceで集約し通知 • サービス追加・変更を安全＆再現性高く運 用 © Finatext Holdings Ltd. 10

PagerDutyの機能 External Status Page （PagerDutyで把握したサービス影響を、顧客・パートナーへの情報発信につなげる） 社内（PagerDuty） 社外（顧客・パートナー） インシデント対応とサービス影響の把握 専用URLから稼働状況を確認・購読 Incident Business Service 障害の発生を検知・対 応 • アラートの集約 • エスカレーション • 障害対応の迅速化  顧客に提供するサービス 単位 影響を 把握 Inspire 保険サービス ●Operational（正常） ●Impacted（影響あり）  顧客・パートナー External Status Page 社外関係者が稼働状態を直接確 認 稼働状況 ステータ ス 外部公開 リアルタイムなシステム状態  専用URLか ら 確認  Subscribe（自動通知） 障害発生・復旧時に自動で通知を受信 障害・復旧情報 影響範囲と対応タイムライン  ステータス更新 メンテナンス等の事前連絡 PagerDuty内のインシデント対応を、顧客へのリアルタイムな情報発信までつなげる © Finatext Holdings Ltd.

Incident Management External Status Page導入 ― 障害時の顧客連絡を O(n) から O(1) へ Before After 個別連絡・手動対応 (課題の核心) 一括自動配信・リアルタイム共有 コア障害発生時、各保険会社へ個別に状況を連絡。タイムラグと連絡コストが発生。 External Status Pageを連動し、1回の更新で全顧客へ即時自動配信。 障害発生 エンジニア (PagerDuty等) (障害対応) タイムラグ 外部への情報発信 PagerDuty Business Service External Status Page 保険会社 A 保険会社 A 保険会社 B エンジニア (障害復旧に集中) 保険会社 C 保険会社 N 保険会社 B 保険会社 C 保険会社 N ● クライアント数が増えるほど連絡コストが増大 O(n) ● 1回のステータス更新で全社へ即時自動配信 O(1) ● 復旧作業と問い合わせ対応が並行発生し、エンジニアの集中を阻害 ● 顧客への透明性向上 & 問い合わせ対応工数を大幅削減 ● エンジニアが障害復旧に専念できる体制を実現 © Finatext Holdings Ltd. 12

まとめ PagerDutyへの移行を通して見えてきたこと ● 既存運用をベースに、PagerDutyの機能を活かした運用へ ○ Service / Escalation Policy / Orchestration / Scheduleを組み合わせ、各ドメイ ンの運用に合わせて設計 ○ PagerDutyへの移行を通じて、オンコールだけでなくインシデント対応全体を改善 ○ External Status Pageにより、障害時の顧客連絡まで効率化 ● 移行を運用改善のきっかけにする ○ 既存運用を棚卸しし、PagerDutyの機能を活用して、よりシンプルで継続的に改善 できる運用へ © Finatext Holdings Ltd. 13