業務と→経営責任文化

運用上の責任の文化

1）なぜそれを必要とします

テクノロジーはツールを提供しますが、人々とその行動は信頼性を生み出します。運用責任の文化は、プラットフォームを予測可能にし、災害復旧を加速し、「騒音」を減らし、インシデントを改善のための燃料に変えます。

• 「信頼性とは何か」を統一的に理解し、誰が責任を負うのか。
• 業務における透明な役割、責任、権限。
• エラーと迅速な調整を議論するための安全な環境。
• SLOのリズミカルな改善、反応時間と操作のコスト。

2）原則（文化の中核）

1.あなたはそれを構築します-あなたはそれを実行します。チームは、コードからオンコールまでのドメインの品質を所有しています。
2.SLO-first。意思決定は、SLOとエラー予算への影響によって評価されます。
3.責任のない&事実。告発のない死後、事実、データ、行動のみ。
4.小さく&リバーシブル。小さな変更、フィッシュフラッグ、カナリア、クイックロールバック。
5.声を上げる安全性。誰もが恐れることなく「赤旗」を掲げることができます。
6.意見に対する証拠。データやアーティファクトは、意見やステータスよりも重要です。
7.継続的に学びます。インシデント→仮説→実験→標準。

3）役割と所有権

ドメイン所有者（支払い/賭け/ゲーム/KYC）： SLO、オンコール、改善ロードマップ、エラー予算。
インシデントマネージャー（回転）：反応の調整、タイムライン、コミュニケーションの質。
SRE/Platform：信頼性ツール（オブザビリティ、アラート、フィッシュフラグ、カナリア）。
チームリーダー/EM：期待、能力の開発、儀式の遵守。
ビジネスの利害関係者：SLO/優先順位を調整し、リスク/妥協を受け入れます。

4）責任契約としてのSLO

唯一の真実の源：メトリックの定義、ウィンドウ、例外。
エラー予算：明示的なリスク境界→リリース/実験へのゲート。

SLOの議論： "このリリースは予算の20％を燃やしますか？».

四半期に一度の改訂：製品とビジネスと一緒に。

5）オンコールおよびインシデントの準備

明確な期待：反応時間、チャネル、権限（停止バルブ右）。
トレーニング：インシデントのエミュレーション、シャドウデューティ、DR演習。
アーティファクト：live runbook'と、エスカレーションマトリックス、更新テンプレート。
人々の世話：シフト負荷、補償、ローテーション、「英雄なし」ポリシー。

• アクセスとVPNが確認されました。
• 通知チャンネルとバックアップ連絡先は正常です。
• Runbookが30日前≤更新されました。
• 過去90日間のDR参加。

6）業務におけるコミュニケーション

ユニフォームテンプレート：インシデントの短い更新、シフト間の「ハンドオーバー」パッケージ。
決定の宣伝：重要な妥協は書面で記録されています。
グラフ上の注釈：リリース、フィーチャーフラグ、プロバイダウィンドウ。
すべてのSLOパネル：ステータスとエラー予算の透明性。

[HH: MM] P2 Games latency ↑ p99 to 420 ms (base + 28%). Canary rolled back.
ETA of the next update: 20 min. Owner: squad-games. Next steps: tuning the breaker, checking provider Y.

7）費用のない死後

事実とタイムライン：誰が、いつ、何をしたのか、データに基づいて。
全身的な原因：「犯人」ではなく、プロセス、ツール、インターフェイス。
締め切りのアクション：是正と予防。
レッスン：標準、チェックリスト、ランブックの更新。

Impact: <metrics/revenue/users>
Timeline: <UTC+TZ>
Root cause: <system cause, not personalities>
Fix now: <3 actions + owners + ETA>
Prevent: <3 process/tool improvements>
Signals to watch: <SLO/metrics>

8）儀式とケイデンス

Weekly Ops Review （30分）：SLO、インシデント、アラート、アクションの進行状況。
毎月の信頼性レトロスペクティブ：レッスン、トレンド、標準の更新。
四半期ごとの信頼性レビュー：SLO/予算の改訂、ロードマップの統合。
ゲームの日/カオス：失敗の計画シナリオとfeiloverの開発。

9）モチベーション、成長、軌跡

能力：he-call、 incident-management、 observability、 SLO-engineering、 FinOps。
キャリアレベル：信頼性の貢献の期待（イニシアチブ、死後、メンタリング）。
無形のモチベーション：認識、改善の著者、四半期の「信頼性チャンピオン」。
マテリアル：オンコール補償、SLO-KPIを達成するためのボーナス。

10）方針と行動規範（断片）

• 彼の呼び出しは、SLOが脅かされたときにリリース/機能を一時停止することができます。
• この決定は、リスクが排除された後に修正されます。

• phicheflagsとカナリアでのみ主要な変更。
• SLOメトリクスによる自動化；偏差→一時停止/ロールバック。

• すべての重要な情報は、プライベートソリューションなしで共通のチャネルにあります。
• ETS（ステータスまでの推定時間）は、P1/P2のインシデントには必須です。

11）カルチャーメトリクス（成熟度KPI）

SLOカバレッジ：正式に説明されたSLO/アラートを持つクリティカルパスの割合。
Pre-Incident Detect Rate：劣化段階で傍受されたインシデントの割合。
MTTR/MTTD：四半期ごとのダイナミクス。
Change Failure Rate：リリース後のプルバック/リグレッション。
Postmortem Action SLA：時間通りに終了したアクションの割合。
Alert Fatigue Index： On-call/shiftアラート。
ハンドオフ品質スコア：シフト間の通過品質。
心理的安全性パルス：短い定期的な調査（匿名）。

12）実装チェックリスト

• ドメイン、所有者、オンコールおよびSLOが定義されています。
• ストップバルブ、死後および通信ポリシーが採用されました。
• SLOパネルとリリースアノテーションを上げました。
• 儀式が開始されました：毎週Opsレビューとテンプレートのハンドオーバー。
• 死後テンプレートとアクショントラッカーが開発されました。
• 第1回ゲームデー/DRエクササイズが開催されました。
• 文化KPIを設定し、毎月レビューします。

13）アンチパターン

ヒーローのカルト：システムの修正の代わりに最後の分で保存します。
人々の欠点：原因ではなく「犯人」を見つける。
隠されたソリューション：プライベートチャット、「口頭契約」。
夜の大きなリリース：旗やカナリアはありません。
アクションなしの指標：レポートがあり、ソリューションはありません。
混沌としたハンドオーバー：テンプレートと受け入れの確認はありません。

14）ツールとアーティファクト（最小）

所有者とのSLO/alertディレクトリ。
Runbookリポジトリ（ドメイン別、更新≥毎月）。
テンプレート：ポストモーテム、ハンドオーバー、インシデントの更新、劣化計画。
SLOの概要、インシデント、安全性の変更、プロバイダ。
アクティビティトラッカー：SLAと所有者を持つ単一のバックログ。

15） HR回路への埋め込み

オンボーディング：SLO、オンコール、ポストモーテムでのトレーニング。
パフォーマンス評価：信頼性と文化への貢献はパフォーマンス評価の一部です。
メンタリング：シャドウデューティ、ペアインシデント管理。
パルス調査：四半期ごとの安全性/燃焼性評価。

16） 30/60/90-スタートアッププラン

• ドメイン所有者とオンコールを割り当て、少なくともSLO （p95、成功率）で修正します。
• 停止弁および死後の方針を採用して下さい、型板を承認して下さい。
• 毎週Opsレビューと引き渡し儀式を開始します。

• 2つのゲームデイ/DRエクササイズを行い、SLOとチェンジセーフティパネルを上げます。
• 1-2クリティカルサービスでSLO経由でカナリアとオートゲートを構築します。
• カルチャーメトリック（MTTR、 Action SLA、 Pulse survey）を実行します。

• トレンド分析、SLO/予算の更新、ロードマップへの改善の統合。
• 「Reliability Champion」とメンタリングプログラムを紹介します。
• 回顧的な結果に基づいて儀式やポリシーを調整します。

17）テンプレート（フラグメント）

scope: P1/P2 and repeated P3 timeline: ≤72 hours format: impact, timeline, root cause, actions (now/prevent), owners/due dates review: monthly on Reliability Review blameless: specifying personalities only as a fact of time stamp

SLO summary     Incidents and ETAs    Providers and quotas    Releases/Canaries    Risks/observations     Action items

- Ficheflags/canary set up
- SLO alerts and annotations included
- Rollback plan and "safe mode" defined
- Provider windows considered
- Responsible on-call confirmed

18） FAQ

Q：テクニックだけでなく「文化」をどう測るのですか？
A： Pulse-poll（心理的安全性）、Action SLA postmortems、公共の意思決定の共有、HQSハンドオーバーを入力します。

Q：「ヒロイズム」についてどうすればいいですか？
A：ありがとうございますが、ヒロイズムを必要としないように体系的な変化を記録してください。パフォーマンスでは、単なる「偉業」ではなく、予防と改善を検討してください。

Q：文化の価値をビジネスにどのように納得させますか？
A： Show connection： MTTR/Change Failure Rateの低減→変換/収益の増加、罰金や深夜ページの減少、予測可能なリリース。