業務における役割と責任
1）役割を正式化する理由
明確な役割割り当てにより、MTTA/MTTRを削減し、灰色領域を排除し、リリースを高速化し、SLO/コンプライアンスを再現可能にします。役割=責任+権限+インターフェイス（誰に書くか、誰をエスカレートするか、どのような決定が承認されるか）。
2）基本的なRACIモデル
R （Responsible）-作業を行います。
A（説明責任）-最終的な責任を負い、決定を下します。
C（コンサルティング）-エキスパート、前/中に相談。
I （Informed）-SLAによって通知されました。
3）ロールカタログ（説明と責任）
3.1インシデントコマンダー（IC）
目的：SEV-1/0事件への対応をリードします。
権限：SEV、フリーズリリース、スイッチトラフィック、エスカレートを宣言します。
主なタスク：タイムライン、意思決定、フォーカス保持、タスク割り当て、Go/No-Go。
アーティファクト：インシデントカード、SLA更新、最終AAR。
3.2 P1/P2オンコール（プライマリ/セカンダリ）
目的：最初の応答および技術的な行為。
P1：トリアージ、プレイブックの実行、ICとの通信。
P2：バックアップ、複雑な変更、コンテキスト保持、嵐で-サブストリームを取ります。
3.3 SRE/プラットフォームエンジニア
目的：プラットフォームの信頼性と手すり（SLO、アラート、GitOps、オートスケール、DR）。
タスク：SLI/SLO、アラート衛生、プログレッシブリリース、コードとしてのインフラストラクチャ、容量、観測可能性。
インシデント中：ルート診断、ロールバック/フォールバック、degrade-UXを有効にします。
3.4サービスオーナー/プロダクトオーナー
目的：ビジネスの意味でのサービスの質。
タスク：SLO/優先順位の定義、リリース/ウィンドウの調整、Go/No-Goへの参加。
Comms：いつ、何を顧客に伝えるかを決定します。
3.5リリースマネージャ
目的：安全な変更配達。
タスク：リリースのオーケストレーション、ゲートのチェック、カナリア/ブルーグリーン、リリースの注釈、インシデントのフリーズ。
3.6 CABチェア/チェンジマネージャー
目的： 変更リスク管理
タスク：RFCプロセス、計画/バックアップ、競合カレンダー、高リスク承認。
3.7 RCAリード/問題管理者
目的：事件後の報告、CAPA。
目的：タイムライン、証拠的因果性、修正/防止するアクション、D+14/D+30コントロール。
3.8セキュリティ（IRリード、AppSec/CloudSec）
目的：セキュリティとインシデント対応。
タスク：トライアージセキュリティイベント、キー回転、分離、フォレンジック、規制通知、WORM監査。
3.9 DataOps/Analytics
目的：データおよびパイプラインの信頼性。
目標：鮮度/品質（DQ）、データ契約、系統、バックフィル、SLA BI/レポート。
3.10 FinOps
目的：管理された価値。
タスク：クォータ/リミット、レポート$/ユニット、予算ゲート、最適化（ログボリューム、出口、予約）。
3.11コンプライアンス/法的
目的：規制および契約上の遵守。
タスク：通知条件、証拠の保持/不変性、パブリックテキストの調整。
3.12 サポート/Comms
目的：顧客/社内ステークホルダーとのコミュニケーション。
タスク：ステータスページ、更新のモックアップ、メッセージの頻度と明確さ、フィードバックの収集。
3.13ベンダーマネージャ/プロバイダの所有者
目的：外部プロバイダ（PSP/KYC/CDNなど）との関係。
タスク：エスカレーション、SLA/OLA、バックアップルート、ウィンドウ調整。
4）シフトとエスカレーションの役割
シフト：P1/P2+IC-of-the-day （P1と結合しないでください）。
タイムエスカレーション：P1→P2 （ackなしで5分）→IC （10分）→デューティマネージャー（15分）。
静かな時間：P2/P3信号は目覚めません；セキュリティ信号-常に。
5）相互作用のインタフェース（誰と誰とどのように）
IC ↔リリースマネージャ：フリーズ/ロールバックソリューション。
IC ↔ Comms：テキストと頻度を更新します。
SRE ↔ DataOps： SLO-gardrailsにおけるビジネスSLI（決済の成功、データの鮮度）。
セキュリティ↔法的：セキュリティインシデントのレポート、通知期間。
ベンダー所有者↔ IC：プロバイダのステータス、スイッチオーバー/フォールバック。
6）役割別KPI（ベンチマーク）
IC：時間に宣言して下さい、Comms SLAの承諾、SEV-1/0によるMTTR。
P1/P2： MTTA、 Time-to-First-Action、％はPlaybookをフォローします。
SRE/Platform： SLOカバレッジ、アラート衛生、％オートロールバック成功。
Release Manager： Change Failure Rate、 On-timeウィンドウ、Mean Rollback Time。
RCAの鉛：Postmortemの調達期間、CAPAの完了/Overdueは、≤ 5-10％を再開します。
セキュリティ：含んでいる平均時間、秘密/Certの回転時間。
DataOps： Freshness SLO Adherence、 Success Rate Backfills。
Comms：ステータス精度、クレーム率/インシデント。
FinOps： $/unit、％ QoQ節約、クォータ準拠。
7）ロールカードテンプレート
7.ICカード1枚
Role: Incident Commander
Scope: SEV-1/0 (prod)
Decisions: declare SEV, freeze deploy, traffic shift, rollback/failover
Runbooks: rb://core/ic, rb://comms/status
SLA: TTD ≤10m, first comms ≤15m, updates q=15–30m
Escalations: Duty Manager (15m), Exec On-call (30m)7.2 P1/P2カード
Role: Primary/Secondary On-call (service: checkout-api)
Runbooks: rb://checkout/5xx, rb://checkout/rollback
Tools: logs, traces, SLO board, feature flags
SLA: Ack ≤5m, first action ≤10m, handover at shift boundaries7.3リリースマネージャーカード
Role: Release Manager
Gates: tests, signatures, active_sev=none, SLO guardrails green 30m
Strategy: canary 1/5/25%, blue-green optional, auto-rollback on burn
Evidence: release annotations, diff configs, dashboards before/after8）プロセスと役割の参加（要約）
A-説明責任、R-責任、C-コンサルティング、I-インフォメーション。
9）チェックリスト
9.1役割の割り当て
- 各ロールには、所有者、代理人、およびカバレッジエリアがあります。
- 承認（決定ができるもの）について説明します。
- プレイブックとリンクを結合します。
- 反応/通信によるSLAを公開しました。
- CMDBでは、各サービスの役割を利用できます。
9.2シフトと引き渡し
- シフトカード更新（アクティブインシデント、リスク、ウィンドウ）。
- JIT/JEAが検証済みにアクセスします。
- チャンネルへのエコーメッセージ「change accepted/passed」。
9.3ポストインシデント
- AAR実施、RCA割り当て。
- 所有者/期限付きCAPA、 D+14/D+30コントロール。
- プレイブック/アラート/ポリシーを更新しました。
10）アンチパターン
不明確な「誰が決める」→遅延と重複した努力。
P1と組み合わせたIC-リーダーシップの喪失。
Legal/Commsとの合意なしのパブリックコム。
Release Managerとgates→CFR成長なしのリリース。
役割の予約なし（病気/休暇）。
プロセスの代わりに「英雄主義」：手動で保存しますが、手すりを修正しません。
役割はCMDB/サービスカタログ→失われたエスカレーションに反映されません。
11）ツールに埋め込む
ChatOps： '/who oncall'、'/declare sev1'、 '/freeze'、'/rollback'、 '/status update'。
ディレクトリ/CMDB：サービスには、オーナー、オンコール、SLO、ダッシュボード、プレイブック、ウィンドウがあります。
Alert-as-Code：各ページには所有者とデフォルトのPlaybookがあります。
GitOps： IC/リリースソリューションはリリースアノテーションとチケットに反映されます。
12）役割分配の成熟度の指標
ディレクトリ内の役割のカバレッジ：重要なサービスの100％を≥します。
オンコールSLA： Ack p95 ≤ 5分；Page Storm p95を管理下に置きます。
Postmortem SLA：ドラフト≤ 72h；CAPA完了率≥ 85％です。
変更ガバナンス：RFC/CAB ≥ 95％で％高リスク変化。
Comms： Adherence ≥ 95％、 Quplaint Rate： QoQ。
13）ミニテンプレート
13.1サービス用RACI（リポジトリ内のファイル）
yaml service: payments-api roles:
owner: team-payments oncall: oncall-payments ic: ic-of-the-day raci:
incident: {A: ic-of-the-day, R: oncall-payments, C: security,data, I: mgmt,comms}
releases: {A: release-manager, R: dev,platform, C: security, I: support}
changes: {A: cab, R: owner, C: sre,security, I: affected-teams}
postmortem: {A: rca-lead, R: owner, C: security,data, I: mgmt}13.2役割プロファイル（Markdown）
Role: Duty Manager
Purpose: Escalation and SEV-1/0
Powers: Assign ICs, reallocate resources, approve freeze
Inputs: # war-room channel, SLO dashboards, IC reports
Outputs: resolutions, post-factual report, CAPA escalations14）ボトムライン
ロールが透明で、権限が与えられ、ツールに組み込まれている場合、操作は堅牢です。ロールカタログ、RACI、各ロールの明確なインターフェイスとメトリクスは、インシデント、リリース、変更を管理プロセスに変換します。意思決定が迅速に行われ、リスクが制御され、ユーザーは安定したサービスを利用できます。