なぜ DevOps が必要になったか

ここから、作ったものを動かし続ける話に入ります。

その前に、なぜ今この部が必要なのかを説明させてください。 これを知らないと、このあとの章（IaC・CI/CD・監視）が 「便利なツールの紹介」に見えてしまいます。

かつて、開発と運用は別の組織だった

2000年代まで、多くの会社ではこうなっていました。

[開発チーム]  機能を作る → 「できました」とリリース物を渡す
                ↓ 壁
[運用チーム]  受け取って本番に入れる。落ちたら対応する

そして、この2つは評価される軸が正反対でした。

変更こそが障害の最大の原因なので、運用チームが変更を嫌うのは合理的です。 しかし開発チームは変更しないと評価されません。

結果、こうなります。

□ リリースは月1回。手順書は100ページ
□ 承認が5段階。実際の作業は深夜に手作業
□ 障害が起きると「アプリのバグだ」「いや環境の問題だ」と押し付け合う
□ 開発者は本番を見たことがない。運用者はコードを読めない

DevOps はツールではない

最も多い誤解がこれです。

✕ 「CI を入れたから、うちは DevOps をやっている」
✕ 「DevOps チームを作った」          ← 新しい壁を作っただけ
○ 開発と運用の境界をなくし、同じチームが両方に責任を持つ

象徴的な言葉があります。

You build it, you run it. （作った人が、動かす）

これは責任の押し付けではなく、インセンティブを揃えるための仕組みです。

自分が夜中に起こされるなら → 落ちにくく作る
自分がログを見るなら       → 見やすいログを出す（監視とオンコール）
自分がデプロイするなら     → デプロイしやすく作る

運用のつらさが、作る人にフィードバックされる——これが本質です。

DevOps = 開発と運用を分けない、という思想
DevOps チーム = 分けている

速さと安定は、両立する

「速くリリースすると品質が落ちる」——直感的にはそう思えます。

しかし、大規模な調査（DORA レポート）の結論は逆でした。

デプロイ頻度が高いチームほど、障害が少なく、復旧も速い。

なぜか。

月1回、200個の変更をまとめてリリース
→ 障害が起きた時、200個のどれが原因か分からない
→ 切り戻すと、他の199個も戻る
→ 調査に何日もかかる

1日10回、1個ずつリリース
→ 障害が起きたら、直前の1個が原因
→ 切り戻しは一瞬
→ 数分で復旧できる

小さくすることが、速さと安全の両方を生みます。 これは開発の流れの「PR を小さくする」と、まったく同じ理屈です。

4つの指標（Four Keys）

チームの状態を測る、広く使われている指標です。

前の2つ = 速さ
後の2つ = 安定性

✕ 「コード行数」    → 増やせばいいわけではない
✕ 「バグ件数」      → 報告しなければ減る
○ 「デプロイ頻度」  → 実際に価値を届けた回数
○ 「復旧時間」      → 利用者が困っていた時間

何をすれば DevOps になるのか

具体的には、この教科書で扱ってきたものの集合です。

バラバラのツールに見えていたものが、1つの目的でつながります。

目的: 「変更を、速く、安全に、繰り返し届け続ける」

□ 障害の原因を「誰のミスか」で語る
□ リリースに毎回、部長の承認が要る
□ 運用の負担が特定の人に集中している
□ 「本番は怖いから触らない」が共有された空気になっている

SRE との関係

Google が提唱した SRE（Site Reliability Engineering） は、 DevOps という思想の、具体的な実装のひとつと説明されます。

DevOps: 開発と運用を分けない（思想）
SRE:    その実現方法（具体的な手法）

SRE 固有の概念で、実務でよく出るものが2つあります。

SLO           「99.9% 成功すれば良い」という目標を数値で決める
エラーバジェット 許容される失敗の量。使い切ったら新機能を止めて安定化に回す

SLO 99.9% = 30日で 43分までダウンしてよい

まだ余裕がある  → どんどんリリースしてよい
使い切った      → 新機能を止め、安定性の改善に投資する

プラットフォームエンジニアリング

DevOps を実践すると、次の問題にぶつかります。

「開発者が全員、Kubernetes と Terraform と監視基盤を
 深く理解しないと何もできない」

認知的な負荷が高すぎるのです。全員が全部を理解するのは現実的ではありません。

そこで近年は、共通の基盤を作るチームを置くようになりました。

[プラットフォームチーム]  デプロイ・監視・環境構築の仕組みを整備する
        ↓ 提供
[開発チーム]  簡単なコマンドや設定だけで、自分でデプロイし、運用できる

かつての運用チームとの違いは、「代わりにやる」のではなく 「自分でできるようにする」点です。

新人が今日からできること

□ 自分が書いたコードが、本番でどう動いているかを見に行く（監視とオンコール）
□ 自分の PR がデプロイされるまでの流れを、一度全部たどる
□ デプロイを怖がらず、しかし**戻し方を先に確認**してから出す（CI/CD）
□ 障害対応を見学する（エンジニアとしての立ち振る舞い）
□ ログとメトリクスを、自分の機能に入れる
□ 「これ、障害時にどうやって気づくんですか」と聞く  ← 効果が大きい

最後の質問は、設計レビューで新人が出せる最も価値のある問いの1つです。

実務の落とし穴まとめ

1. ツールを入れれば DevOps だと思う — 文化と責任の持ち方が本体
2. 「DevOps チーム」を作る — 新しい壁ができる
3. 大きなリリースをまとめて出す — 障害時に原因を特定できない
4. 障害を人のミスとして扱う — 報告されなくなり、学習が止まる
5. 開発者が本番を見たことがない — 運用しやすく作る動機が生まれない
6. 全員に Kubernetes を深く理解させようとする — 負荷が高すぎる。基盤で抽象化する
7. 速さと安定を対立させて議論する — SLO とエラーバジェットで数字にする

まとめ

• DevOps は、開発と運用が別組織で、評価軸が対立していたという 歴史的な問題への回答
• クラウドと IaC が、壁を作っていた技術的理由を消した
• ツールではなく、責任の持ち方。「You build it, you run it」で インセンティブを揃える
• 速さと安定は両立する。小さく頻繁に出すほうが、原因特定も復旧も速い
• 状態は Four Keys（デプロイ頻度・リードタイム・変更失敗率・復旧時間）で測る
• SRE は DevOps の実装のひとつ。SLO とエラーバジェットで、 感情の議論を数字の議論に変える
• 認知負荷が高くなりすぎるため、近年は プラットフォームエンジニアリングで「自分でできる」状態を作る
• 非難しない文化が無ければ、自動化だけでは機能しない

公式ドキュメント・参考資料

SRE Book は全文が無料で公開されています。 監視とオンコールと合わせて読むと、内容が立体的になります。

次の章では、その基盤となるクラウドの構成要素を見ていきます。