シフト計画

1）目標と枠組み

• SLOクリティカルプロセスの保証範囲（預金、レート/決済、結論、KYC/AML）；
• 1日のいつでもMTTA/MTTRを削減
• 労働法および内部方針（週末/休憩/夜）を遵守します。

2）役割とサポートのレベル

L1 （NOC/Operations）：プライマリ・トリアージ、ランブック実行、エスカレーション。
L2（ドメインオンコール）：支払い、ゲーム/コア、データ/インフラ-深い診断と修正。
L3 （SRE/Platform/Dev）：構成変更、パッチ、緊急リリース。
IC/CL （Incident Commander/Comms Lead）：インシデントと通信を管理します。
デューティマネージャー（シフト別）：人員配置、リスク、凍結ウィンドウを確認します。

3）シフトと回転モデル

3.1 24 × 7カバレッジ

8 × 3（3 8時間）：昼（08：00-16：00）、スイング（16：00-00：00）、夜（00：00-08：00）。管理が簡単で、より多くの従業員が必要です。
12 × 2（2 12時間）：昼（08：00-20：00）、夜（20：00-08：00）。ハンドオーバーが少なく、疲労のリスクが高くなります。
太陽の後：EU→AMER→APACの最低の夜；分散コマンドが必要です。

3.2回転テンプレート（例）

パナマ/ピットマン（2-2、3-2、2-3）：長い週末と12時間交互に（厳密な疲労制御が必要です）。
4-on/4-off （12h）： 12時間のための4日、4日；よいオートメーションのL1のために適した。
5 × 8（クラシック）：L2/L3+コールナイト/週末。

3.3通話中の義務

プライマリ/セカンダリ：各ドメインにプライマリおよびセカンダリのオンコールがあります。
シャドウオンコール：プライマリーの翼の下で新しいエンジニアを訓練します。

4）状態と収縮の計算（収縮）

4.1基本FTE式

FTE = (coverage hours per week/productive FTE hours per week) × (1 + shrinkage)

収縮には、休暇/病気休暇/トレーニング/1：1/レトロ/管理時間（通常は20-35％）が含まれます。

• 168時間の適用範囲/35生産的な時間/週≈ 4。8
• 収縮と30％→4。8 × 1。3 ≈ 6.2 FTE（安定性のための7への円形）。

4.2ピークプラン

イベント（トップマッチ、トーナメント）のピークファクターを追加：カレンダーウィンドウで+10-25％ FTE。過去のアラート/トラフィックプロットを使用します。

5） SLOカバレッジとリスクウィンドウ

重要な時間のマトリックスを構築する（現地プライムタイムのGEO/支払い方法）。
スロットごとの最小構成を設定します（例えば、Night： L1 × 2、 L2-Payments × 1 on-call、 L2-Games × 1 on-call、 rotationによるIC）。
リリース/マイグレーションの場合は、リリースガード（オプションL2/SRE）を期間および+60分のポストモニタリングに割り当てます。

6）ハンドオーバー（シフト移動）

1.SLO/アラートとオープンインシデントのステータス。

2.ウィンドウでの計画作業+リスク。

3.ブロッカー/待機（PSP/KYCプロバイダ、規制）。

4.合意されたcommプラン（ステータスページ、パートナー）。

5.シフト構成と通話中の連絡先を確認します。

ハンドオーバーのチェックリストはwiki/botにある必要があります。プロトコル-var-roomまたは交換可能なチャネル。

7）カレンダーおよび取り替え

計画の地平線：8-12週；交換-遅くとも2週間（不可抗力を除く）。
凍結期間：主要なイベント/休日-重要な役割の休暇の禁止（後で補償）。
Buddy-rule：同じドメイン/資格のエンジニアまたは追加の影でのみ交換できます。

8）プラットフォームインテグレーション

アラート：アクティブなシフトとドメイン（P1→pager+varルーム）によるルーティング。
Incident bot： teams '/rota'、'/whoisoncall'、 auto-mentions IC/CL。
リリース：シフトスケジュールと同期するCAB；オフカバレッジリリース-禁止。
ステータスページ：ボットで確認したアクティブシフトからのCL。

9）チームの持続可能性と健康

労働基準：夜/週末-追加料金と休暇。行の最大夜（例えば、≤ 3）。
休憩：短い休憩は2-3時間ごとに；12hで-必須の2つの長い。
疲労時計：時間/週の制限、ルール「1シフトあたりN P1以下」。
心理的サポート：重いP1、コンプタイムの後の報告。

10）複数の地域および後日

ブランド/テナントを地域（EU/LATAM/APAC）と地域L1およびドメインL2で分けます。
地域ICは、地域横断インシデントにおけるグローバルICにエスカレートします。
リスクと作業の移転に伴う毎日のクロスリージョンハンドオーバー（15分）。

11）政治家とRACI

ポリシー「Shift&On-Call」：誰がどのように、いつ、どのように進むか;置換；tardiness；予約してください。
SoD/アクセス： IC/CL/金融取引-個別の役割；JITはボットのみでブーストします。
RACI：各シフトには、IC （A）、デューティマネージャー（A/R）、 L1/L2 （R）、 コンプライアンス/Sec （C）、マネジメント（I）があります。

12）ツールとデータ

単一のカレンダー（属性：ドメイン、地域、連絡先、予約）。
シフトロードのダッシュボード：アラート/時間、インシデント/タイプ、リリース/ウィンドウ。
Justice Reports（フェアシェア）：人々による夜/週末のカバレッジ。
収縮が自動的にカウントされるようにHR/PTOとの統合。

13）品質指標（KPI/KRI）

適用範囲率：完全な鋳造物との％時間。
スロットによるMTTA/MTTR：昼/夕方/夜。
ハンドオーバーの欠陥：不足しているチェックリスト項目の数。
Pagerの疲労：alert/person/week；night calls （target）。
交換SLA：開始の48時間前≤交換によるクローズドシフトの％。
トレーニングカバレッジ：新しいオペレータのためのシャドウスロットとのシフトの共有。
Fair-Share Index：従業員による夜間/休日の均等性。

14）導入ロードマップ（4〜8週間）

ネッド。1-2：アラート/ピークの履歴を収集し、SLOクリティカルなウィンドウを決定します。モデル（8 × 3またはフォローザサン）を選択し、FTEと収縮を計算します。
ネッド。3-4： publish Policy 「Shift&On-Call」、 enable handover-checklist、 run general calendar and bot commands '/whoisoncall'、'/handover'。
ネッド。5-6：デバッグのエスカレーションと置換、公正共有レポートの追加、CAB/リリースとシフトの同期、フリーズ・ウィンドウの入力。
ネッド。7-8：バーンアウトとハンドオーバーの品質、夜間の構成の修正、シャドウプログラムの立ち上げ、IC/CL認証。

15）パターンとアーティファクト

ハンドオーバーチェックリスト（10ポイント）：SLO、インシデント、作品、リスク、リリース、プロバイダ、アクセス、ステータスページ、オープンチケット、スタッフ。
交換SOP：交換を発行する方法、入場基準、連絡先を予約します。
フリーズカレンダー：イベント/祝日およびRTO/リリースの禁止。

16） Antipatterns

ドメイン分離なしのすべてのための1つのオンコール。
制限や休憩なしで連続して12時間の夜。
IC/CL/CLの可用性なしで数時間でリリース。
チェックリストとメモなしで「音声で」ハンドオーバーします。
収縮→慢性的なアンダーセットを無視します。
ゼロシャドウプログラム→人間の脆弱性とSPOF。

合計

シフト計画は、FTEと収縮の計算、正直な回転と健康保護、厳格なハンドオーバー、アラート/ChatOps/CABとの統合などのエンジニアリング作業です。このフレームワークは、予測可能な24 × 7のSLOカバレッジ、迅速なインシデント対応、およびチームバーンアウトなしのビジネス弾力性を提供します。