LoginSignup
6
1
@ymotomu(Moto Yamada)inPagerDuty 株式会社

PagerDuty 設定ガイド (動員編5) - Serviceの作成

Last updated at Posted at 2022-12-25

Serviceを定義し、各Serviceの責任範囲と関係者(Stakeholder)、その他のServiceとの依存関係を明確にします。
これにより、インシデントの発生を適切なチームに通知し、その影響範囲や進捗状況をリアルタイムで関係者に共有できるようになります。

Business Service と Technical Service

Serviceには2種類あり、1つはBusiness Service、もう1つがTechnical Serviceです。
Services_Business_and_Technical.jpg

Business Service

  • エンドユーザーの存在するサービス
  • 例: ECウェブサイト、ECモバイルアプリ、外部API等
  • 経営者やカスタマーサービスなどの関係者(主にエンジニア以外)に対して、サービスの状況を伝えるために利用します。

Technical Service

  • Business Serviceが正常に稼働するために必要な技術コンポーネント(マイクロサービス等)
  • 例: ユーザー認証、決済プロセス、CMS、API Gateway等
  • 各Technical ServiceにはEscalation Policyを紐付け、インシデント発生時の通知先を指定します。
  • PagerDutyのドキュメントで、単にServiceと呼ぶ場合はTechnical Serviceを指します。

Technical Service の作成

(1) Service > Service Derectory を開き、"New Service"をクリックします。

(2) Serviceの名称と説明を記入し、"Next"をクリックします。
Screen Shot 2022-12-25 at 15.12.17.png

(3) Serviceに紐付けるEscalation Policyを「新しく作成する」または「既存のEscalation Policyを選択」します。
Screen Shot 2022-12-25 at 15.17.34.png

(4) Event Intelligence ライセンスが有効な場合は、ノイズ削減機能1(Alert GroupingとTransient Alerts)の設定画面が表示されます。特に理由がなければ、推奨設定のまま"Next"をクリックします。

(5) Serviceに直接紐付けたいIntegration2があれば、選択後Creat Serviceをクリックします。
Serviceの紐付けは後からでもできるため、"Create service without an integration"をクリックしても問題ありません。

Screen Shot 2022-12-25 at 15.24.12.png

Business Service の作成

(1) Services > Business Services を開き、"New Business Service"をクリックします。

(2) Serviceの名称と説明を記入し、"Create Business Service"をクリックします。
Screen Shot 2022-12-25 at 15.29.19.png

Service間の依存関係を設定

(1) Services > Service Directory を開きます。

(2) 依存関係を設定するServiceを開き、"Service Dependencies"タブをクリックします。

(3) "Edit Services"をクリックし、依存関係のあるServiceを追加します。
Screen Shot 2022-12-25 at 15.33.37.png

Service Graph

Services > Service Graph を開くと、Service間の関係をグラフィカルに確認できます。
また、各Serviceで発生しているインシデントが、どのServiceに影響を及ぼしているかも分かります。
ServiceGraph_Impacts.png
矢印の向きは、影響を及ぼす方向を表しています。上記の例では、もしAPI GWで障害があれば、矢印の先のPayment Process, Login, モバイルCMSの各サービスに影響する可能性があります。

Service間の依存関係は、Service Graph上で追加・変更することも可能です。
ServiceGraph_edit.gif

Service Graphに何も表示されない場合は、「Business Serviceが作成されていない」または「Business Serviceと他Serviceの依存関係が設定されていない」可能性があります。

ベストプラクティス

Technical Serviceの分け方

Technical Serviceをどのように分けるべきか、というのはよくいただく質問です。
最初は大きな単位(チーム毎に1つのServiceなど)で分けておき、実際に運用をする中で必要に応じて分割や依存関係の設定を進めることをおすすめしています。

Global Integrationを利用すれば、(監視ツール側の設定を変更することなく)PagerDuty側の設定だけで割り当てるServiceをすぐに変更できます。

Serviceは必ず1つのチームが完全に責任を持つ範囲で分割する

Serviceの分割において守るべき原則は、あるServiceに責任を持つチームは必ず1つであることです。複数のチームに責任がまたがってしまうと、通知先(Escalation Policy)が適切に設定できません。

ここでいう「責任を持つ」とは「インシデント解決のための初動対応を行う」という意味です。

「現在はSREとインフラチームに同時に通知している」といった場合は、どちらが初動対応の責任を持つのか明確にした方が、MTTAの短縮やオンコール対応の負担軽減に繋がるかもしれません。責任範囲が明確でない(他のメンバーがやってくれるかも)という状態ではMTTAは長くなる傾向があることと、本来必要ないメンバーにも通知や対応が発生している可能性があるためです。

例えば「初動対応に責任を負うのはインフラチームとし、インフラチームの初動対応後、必要があればSREにエスカレーションし、協力して対応する」とした場合、Escalation Policyで通知を受けるのはインフラチームにしておき、初動対応後に必要に応じて Add Responders を使ってSREチームを追加招集することができます。

Service分割に影響を与える要素: 影響範囲(依存関係)

あるServiceに責任を持つチームは必ず1つと述べましたが、1つのチームが複数のServiceに責任を持つことは問題ありません。
他Serviceとの依存関係が異なる場合は、インシデント発生時の影響範囲が明確になるよう、同じチームが責任をもつ範囲であっても複数Serviceに分割することがあります。

ServiceGraph_Impacts.png

上記のFront EndとPayment ProcessはどちらもInfra大阪チームが責任を負っています。「適切な担当者に通知を行う」という目的だけであれば、2つに分けずに1つのServiceとして設定しても問題ありません。

しかし、ここではFront EndとPayment Processは影響範囲(依存関係)が異なるため、Serviceを分けて管理することにしました。Payment Processに問題があればWebサイトとモバイルアプリ双方に影響がありますが、Front Endに問題があれば影響を受けるのはWebサイトのみです。

なお、Serviceを分割する場合にEscalation Policyまで分ける必要はありません。
初動対応を行うメンバーが同じであれば、同じEscalation Policyを複数のServiceで利用できます。

Service分割に影響を与える要素: 運用指標(MTTA/MTTR等)

Analytics > Insights のService Performanceレポートでは、Service毎にMTTA/MTTR/Resonse Effortなどの指標を見ることができます。これらの指標を可視化・管理したい単位で分割してください。

  • MTTA (Mean Time to Acknowledge): インシデント発生から対応開始(最初にAckされる)までの時間
  • MTTR (Mean Time to Resolve): インシデント発生から解決(Resoveステータスに変更)されるまでの時間
  • Response Effort: 全てのResponderが、インシデント対応に費やした延べ時間

Insights_ServicePerformance.png

アンチパターン: Technical Serviceを監視ツール毎に分割してしまう

ありがちな誤ったServiceの分割方法は、監視ツール毎にTechnical Serviceを作成することです。

Serviceを分ける際に考えるべきは、チーム間の責任分界点や他Serviceとの依存関係です。
どの監視ツールを利用しているかはこれらと関係がないため、通知先を適切に設定できなかったり、インシデントの影響範囲が把握できなくなります。

AlertのSeverityに合わせて、Urgencyを動的に変更する

各Serviceは、デフォルトでは全てのAlertをUrgency Highで扱うよう設定されています。
Dynamic Notificaionを有効にすることで、Alertに含まれるSeverityの値を元に、UrgencyのHigh/Lowを動的に変更できます。

(1) Services > Service Directory から対象のServiceを開きます。
(2) Settingsタブ内のAssign and Notify欄で"Edit"をクリックします。
(3) "How should responders be notified?"のプルダウンメニューから、"Dynamic notifications based on alert severity"を選択します。
Screen Shot 2022-12-25 at 21.20.48.png

PagerDuty設定ガイド 目次

検知編 | トリアージ編 | 動員編 | 解決編 | 学習編

  1. 通知を受けるまでの設定の流れ
  2. ユーザーの追加と通知設定
  3. On-call Scheduleの作成
  4. Escalation Policyの作成
  5. Serviceの作成 << イマココ
  6. 通知テストの実施
  7. Slack等との連携

参考リソース

  1. ノイズ削減機能の詳細ついては、「トリアージ編」を参照ください。 ↩

  2. Integrationの詳細ついては、「検知編」を参照ください。 ↩

6
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
6
1