いきなりですが、先に制約による課題と解決策を記載しておきます。

※この課題の数字で導入を諦めるかたもいるので、まず書かさせて頂きます。

前回の記事で、エスカレーションポリシーの階層で設定できるスケジュールは
10個ですってのを記載してます。

通知される担当が最大10人までの場合だと、1スケジュール=1名で設定して、
10スケジュール作成してエスカレーションポリシーにセットする事で対応は可能です・・・が、24時間・365日でかつ数多くのシステムを預かっているcloudpackのような規模だと、そのスケジュール作成のルールでは簡単にオーバーフローしてしまいます汗。

逃げの手としてエスカレーションポリシーの階層で制御する事も可能ですが普通は

  • ①階層目
    • 監視メンバーA・監視メンバーB・監視メンバーC
  • ②階層目
    • 監視メンバーA・監視メンバーB・監視メンバーC＋リーダー層
  • ③階層目
    • 監視メンバーA・監視メンバーB・監視メンバーC＋リーダー層＋責任者

とエスカレーションのランクが上がる毎に通知されるメンバーが増えていきます。

またメンバーも1週間に二日間の休みがあるので、スケジュールには二日間の休みを
設定する必要もあり、エスカレーションポリシーの制約からスケジュールを複数のメンバーで使い回す必要がありますが、pagerdutyは何とUIの設定からだと１週間のうち、
二日間は休みと言う当たり前の設定を”簡単”に設定する方法がありません・・・汗。

例えば7月7日のスケジュールAに担当のX1さんを設定すると、スケジュールAには
X1さんを週間か毎日の設定は出来ますが、その日付から未来総てX1さんは休みなしで
設定されてしまいます汗。

  • ①7月7日〜7月10日がX1さん
  • ②7月11日〜7月12日がX2さん
  • ③7月13日〜7月15日がX1さん

という設定をする為には、①を入力した後に7月11日開始で②の設定をして
7月13日開始で③の入力を個別にする必要があります。

ちなみに間違って②を再度入力するともれなく未来日付が②で上書きされて③の日程が
消えてしまいます・・・

UI的には、スケジュールで設定されている担当の方をクリックする

20150713213447

とスケジュールを別の担当者に設定するOverride機能

20150713213514

があるのですが、スケジュールがドラスティックに変わったり、そもそも沢山のメンバーをいちいち入力するのって運用として破綻しているので、比企はgoogle spred seetに
スケジュールを記載したものをgoogle apps scriptでpagerdutyのAPIをコールするように
落とし込むスクリプトを作成し対応しました・・・

※上記には記載していませんが、スケジュールの使い回しのパターンとして、
違う時間帯のメンバーを一つのスケジュールに登録する事も出来ますが、
通常のUIでそれをやるのはさらに難易度が高いのでAPI呼び出しにより自動化を進めたほうが、後の運用コストを考えても絶対に楽です。

なお、いつもならここでコードもはっつけるところなのですが、cloudpackの運用は
複雑なので、汎用性もありませんし、汎用性のあるコードも書けますが、それは現状本筋ではないので、導入される方は自前でお願いしますw

APIのリファレンスは下記

Schedules API

cloudpackでは表でスケジュールを管理しており、それをpagerdutyのスケジュールだけの運用に置き換えようと思いましたが、スケジュールを作成する人にpagerdutyのUIで
作ってと言うと間違いなく発狂するぐらい、スケジュール機能は最低限の事しか
現状は出来ないので、運用を考えた場合に是非API呼び出しでの自動化の実装の工数は考えてください。

他にも同業他社で必要な実際の課題に対する運用のノウハウもあったりしますが、
さすがにそこはピンポイントすぎるので開示せずに、汎用的なノウハウとかを
書いて行きたいと思います。

元記事はこちら

「【cloudpack 大阪 BLOG】pagerduty始めました・・・[いきなりの制約回避編 スケジュールとエスカレーションポリシーのハマりどころ]」