PagerDuty で「普通のオンコール・シフト」を組む

はじめに

平素は大変お世話になっております。
クイックガードのパー子です。

システムの正常稼働に責任を持つエンジニアにとって、好むと好まざるとにかかわらずオンコール (緊急時の保守サポート体制) は馴染み深いものです。

特に我々 MSP (Managed Service Provider) は、お客様の代わりとなってオンコールを引き受ける保守サービスが主要な業務のひとつであり、複数のお客様に対して安定かつ持続的に 24時間365日のオンコール体制を維持するために日々研鑽を重ねております。

一方、ご自身でオンコールを担当されているお客様からはオンコール・シフトの組み方についてアドバイスを求められることも多く、今回はそんなご相談の中から 1つ、PagerDuty で「普通のオンコール・シフト」を組むやり方をご紹介します。

普通のオンコール・シフト

この記事では「普通のオンコール・シフト」を次のように定義します。

• メイン担当者 + サブ担当者のペアで一次受けをする。
• 週末を含む 1週間ごとに担当者ペアをローテーションする。
• 二次受け以降はマネージャ職など特定のスタッフで固定する。

これが世間一般で普通なのかはわかりませんが、個人的にはこのようなオンコール・シフトをよく目にします。:)

月曜日の朝から翌週の月曜日の朝に次の担当者へ引き継ぐまで、週末を含めて丸々 1週間を担当します。

オンコール発生時はなるべくメイン担当者が引き受けますが、メイン担当者の反応がない場合はすかさずサブ担当が応答します。
タイミングが悪くどちらの担当者も応答できない場合は、二次受けにエスカレーションされます。

通常、二次受けメンバーはマネージャなどの管理職が務め、基本的にローテーションせずに固定されます。
(というか、ローテーションを組めるほどマネージャ級の人数はいないでしょう。)

また、運用的にはシフトを組んでそれで終わりということはなく、スタッフ個々の事情による突発的なシフト変更に対応できる必要があります。

• 突然の退職や入院など、計画外のローテーション改訂がある。
• 一人一人のプライベートの都合でスタッフ同士の一時的な交代がある。

つまり、ローテーション表の組み替えが簡単にできるのはもちろんのこと、ローテーション表は変更せずに臨時かつ一時的に当番を交代できる必要があるのです。

実現方法

On-call schedule (オンコール・スケジュール) を使います。

これを使うことで、複数のスタッフによる任意のスパンでのローテーションを組むことができます。

インシデントの発生を誰にどの順序で発報するかを規定する Escalation policy (エスカレーション・ポリシー) では、「誰に」の対象として、特定のスタッフだけでなくオンコール・スケジュールを指定することもできます。

したがって、この例 のようにスタッフを 2チームに分けて、それぞれのチームについて定義したスケジュールをエスカレーション・ポリシーにぶら下げることで、今回の要件を実現することができます。

チーム編成の例

具体的にどうチームを編成するのがよいのでしょう？

例えば Aさん 〜 Fさんの 6名がシフトに入る場合を考えます。

基本パターン

チームと言いつつも人員を割らずに、メインとサブの両方に 6名全員を登録する方式。

この際、メイン、サブともに A » B » … » F というローテーション順は同じながら、サブのほうを 1週オフセットします。

このようなローテーションを組むことで、「まずサブ担当でウォームアップしてから翌週メイン担当に臨む」というリズムが生まれます。

メイン:

サブ:

わかりやすいようにメインとサブをサイド・バイ・サイドで並べてみました。
(PagerDuty上の操作では並べることができないので、ちょちょいと画像を加工してみました。)

シニア＆新人パターン

パターンその2。

シニア級のスタッフが補佐に控えつつ、メインを新人に張らせて経験を積ませたいパターンです。

このようにチームを編成した場合、オンコール・スケジュールは以下になります。

メイン (新人):

サブ (シニア):

メイン、サブを並べると。

人員の入れ替え

続いて、人員を入れ替える場合を考えます。

増員

Gさんが増える場合を考えてみましょう。
(Fさんの後ろに参加します。)

【基本パターン】の場合は、第6週目 (メイン担当者: Fさん、サブ担当者: Aさん) のタイミングを 除いて いつでも追加できます。

第6週目に何も工夫せず Gさんを追加すると、

このようにペアがずれてしまい、「サブ担当でウォームアップ » 翌週にメイン担当」のリズムが崩れてしまいます。
(注: 周期をわかりやすくするため、画像ではローテーションのスパンを 2日にしています。)

「Handoff time」や「Changes should take effect at」をうまく調整して、翌週から Gさんが加わるようにするとよいでしょう。

このように、Gさんが参加するタイミングを工夫することで、周期の規則性を維持できます。

なお、【シニア＆新人パターン】の場合はメインとサブで人員が分かれているので、いつ追加してもこのような周期の問題は発生しません。

減員

次に人が減った場合。

Cさんが退職したケースを考えます。

【基本パターン】の場合、担当週でないか、または、サブ担当の週の場合はそのまま Cさんを削除して OK です。
次の Dさんが前倒しで当番になります。

一方、Cさんがメイン担当の週の場合は単純に削除はできません。

もし削除してしまうと、

このように、メイン担当者とサブ担当者が同じスタッフになってしまいます。

解決策としては、単純にサブ担当も併せてスライドさせてしまうのが簡単でよいでしょう。

本来は続けてサブ » メインと 2週間にわたって担当すべきところ、Dさんは 1週間で済んでいるのでお得ですね。:)

【シニア＆新人パターン】の場合は特に考慮する点はありません。
どのタイミングであっても単純に Cさんを削除してしまって OK です。

当番の交代

スケジュールの Override (オーバーライド) で一時的に当番を上書きできます。

例えば Bさんの都合が悪く Dさんに当番を代わってもらう場合は、以下のスクリーンショットのように、Bさん、Dさん両方のオーバーライドを作成します。

「Configuration Layers」が本来のローテーション表で、「Override Layers」にて Bさんと Dさんを交代。
結果として、最終的なオンコール・シフトである「Final Schedule」で表されるように、Bさんと Dさんが一時的に入れ替わったシフトが出来上がりました。

まとめ

本記事では、意外にわかりづらい「普通のオンコール・シフト」を PagerDuty で組む方法を紹介しました。

「メイン担当 + サブ担当のペアを 1週間ごとにローテーションする」という体制を、On-call schedule を用いて実現しました。

また、チーム編成のパターンと、突発的な人員の入れ替えが発生した際の注意点を見てきました。
Override を利用することで、スタッフ同士の一時的な交代も簡単に行えることもわかりました。

今回は使いませんでしたが、Schedule restrictions と Schedule layers を駆使することで 極めてアートな オンコール・シフトを組むこともできます。

PagerDuty でちょっと複雑なオンコール・シフトを組む際のご参考になれば幸いです。

今後ともよろしくお願い申し上げます。