DevOps文化とDORA 4指標｜クラウドインフラ

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：SREとは・SLI/SLO/エラーバジェット　|　関連：CI/CDとは・パイプライン・インシデント対応とポストモーテム

要点（BLUF）

DevOps＝開発（Dev）と運用（Ops）の壁を壊し、一緒に速く安全に届ける文化。ツールでなく文化・働き方が本体。SRE はその実装の1つ。
配信能力を測る客観指標が DORA の4指標：デプロイ頻度・変更リードタイム（速度系）と変更失敗率・MTTR（安定系）。
重要な発見：速度と安定はトレードオフではなく両立する。高パフォーマンス組織は4指標すべてが優れている。

概念 ── DevOps は文化

かつて開発は「速く出したい」、運用は「壊したくない」と対立し、間に壁（サイロ）がありました。DevOps はこの壁を壊し、両者が同じ目標（速く・安全に届ける）を共有する文化です。CI/CD（CI/CDとは・パイプライン）・IaC（IaCとは・宣言的構成）・可観測性（メトリクス・ログ・トレース（3本柱））は、その文化を支える道具であって、文化そのものではありません。

「DevOps をやっているか」は曖昧になりがち。そこで客観的に測るのが DORA 指標です。

仕組み ── DORA の4指標

DORA（DevOps Research and Assessment）が長年の調査で見出した、配信能力を表す4つの指標（要最新確認の最新版定義）。

flowchart TB
    subgraph speed["速度（スループット）"]
      d1["デプロイ頻度：どれだけ頻繁に本番リリースするか"]
      d2["変更リードタイム：commit から本番稼働までの時間"]
    end
    subgraph stability["安定（品質）"]
      d3["変更失敗率：デプロイのうち障害を起こした割合"]
      d4["MTTR：障害からの平均復旧時間"]
    end

指標	何を測るか	良い状態	効く施策
デプロイ頻度	リリースの頻度	高い（1日複数回）	CI/CD・小さなバッチ
変更リードタイム	commit→本番の時間	短い	パイプライン自動化（CI/CDとは・パイプライン）
変更失敗率	障害を招いた変更の割合	低い	自動テスト・カナリア（デプロイ戦略（ローリング・ブルーグリーン・カナリア））
MTTR	復旧までの平均時間	短い	ロールバック・ポストモーテム（インシデント対応とポストモーテム）

仕組み ── 速度と安定は両立する

直感に反しますが、DORAの中心的発見は「速い組織ほど安定している」。理由は、小さく頻繁に出すほど1回の変更が小さく、

壊れたときの原因切り分けが速い（変更が小さい）
ロールバックが軽い（デプロイ戦略（ローリング・ブルーグリーン・カナリア））
レビューしやすく失敗率が下がる

つまり速度を上げる施策（自動化・小さいバッチ）が、そのまま安定も上げる。大きな変更を稀に出す方が、実はリスクが高い。エラーバジェット（SREとは・SLI/SLO/エラーバジェット）が「速度の上限」を、DORAが「速度と安定の現在地」を示します。

近年は5つ目として信頼性（運用パフォーマンス）が議論される。指標の定義・ベンチマークは毎年更新されるので要最新確認。

なぜ測るのか

改善の的を絞るため：4指標のどれが弱いかで、打ち手が変わる（リードタイムが長い→パイプライン改善、MTTRが長い→ロールバック/オンコール改善）。感覚でなくデータで。
速度と安定の両取りを正当化するため：「速く出すと壊れる」という思い込みを、データで覆す。小さく頻繁が正解だと示せる。
文化を可視化するため：DevOps は曖昧になりがち。指標で現在地と進捗を共有し、組織の会話を噛み合わせる。

⚠️ よくある誤解・落とし穴

「DevOps＝ツール導入」→ ツールは手段。**文化（壁を壊す・共有する）**が本体。ツールだけ入れても指標は伸びない。
「デプロイ頻度だけ追う」→ 失敗率・MTTRを無視すると、速いが壊れる組織に。4指標をバランスで。
「指標を個人評価に使う」→ 数字を作るための歪み（隠蔽・ゲーミング）を生む。チーム改善のために使う。
「リードタイムを手作業で短縮」→ 持続しない。自動化（CI/CD・GitOpsと自動化）で構造的に短く。
「DORAの定義・ベンチマークを古い数字で固定」→ 毎年更新される。要最新確認。

対応ラボ

なし（文化・指標トピック）。リードタイム/デプロイ頻度を支える自動化は CI/CDとは・パイプラインのラボで、MTTR を縮める復旧は GitOpsと自動化（git revert）で体験できる。