DevOps
DevOpsとは
DevOps は、開発(Development)と運用(Operations)を組み合わせた言葉で、両者の壁をなくして速く・安全にリリースし続けるための文化と実践の総称です。
かつては「開発チームは新機能を出したい、運用チームは安定のため変更を減らしたい」と利害が対立し、リリースは数か月に一度の一大イベントでした。DevOps はこの対立を解消し、小さな変更を頻繁にリリースする方が、実は安全という考え方に立ちます。
DevOpsを支える実践
| 実践 | 内容 |
|---|---|
| [[CI/CD]] | ビルド・テスト・デプロイを自動化し、リリースを日常作業にする |
| [[IaC]] | インフラをコードで管理し、環境構築を再現可能にする |
| [[オブザーバビリティ]] | 本番の状態を観測し、問題に素早く気づける状態を保つ |
| 自動テスト | 変更のたびに品質を機械的に確認する |
| ブレームレス文化 | 障害時に個人を責めず、仕組みの改善に集中する |
道具だけ導入しても DevOps にはなりません。「作った人が運用にも責任を持つ」(You build it, you run it)という文化の変化が本体で、ツールはそれを支える手段です。
DevOpsの成果を測る指標
DevOps の成熟度を測る指標として、Four Keys と呼ばれる4つがよく使われます。
- デプロイ頻度 — どれくらい頻繁にリリースできているか
- 変更のリードタイム — コミットから本番反映までの時間
- 変更障害率 — リリースが障害を起こす割合
- 平均復旧時間(MTTR)— 障害から復旧するまでの時間
「速さ」と「安定」の指標が両方入っているのがポイントです。優れたチームは両方を同時に達成します。トレードオフではないのです。
初学者向けポイント
- DevOps は職種名ではなく考え方です。「DevOps エンジニア」という求人は、実際には CI/CD やインフラ自動化の担当者を指すことが多いです
- まずは [[CI/CD]] のパイプラインを理解するのが入り口として最適です。自動化の恩恵を最も体感しやすい領域です
- リリース作業が「怖い・大変」なチームほど DevOps の効果が大きいと覚えておきましょう。頻度を上げるには自動化が必須になり、自動化は品質を上げます
- DevOps の考え方をサイト信頼性の分野で体系化したのが [[SRE]] です
関連技術とのつながり
- [[CI/CD]] — DevOps の中核となる自動化パイプライン
- [[SRE]] — DevOps の理念を信頼性の分野で実装した方法論
- [[IaC]] — インフラ構築をコード化する DevOps の実践
- [[オブザーバビリティ]] — 「速く直す」を支える観測の仕組み
- [[デプロイ戦略]] — 安全にリリースするための具体的な出し方
Q: DevOps が解消しようとした対立はどれ?
- [x] 変更したい開発チームと安定させたい運用チームの対立
- [ ] フロントエンドとバックエンドの技術選定の対立
- [ ] 営業部門と経理部門の予算の対立
解説: DevOps は開発(変更したい)と運用(安定したい)の壁をなくし、速さと安定を両立させる考え方です。
Q: DevOps のリリースに対する考え方として本文と合致するのはどれ?
- [ ] リリースは年に一度の大イベントにまとめるべき
- [x] 小さな変更を頻繁にリリースする方が安全
- [ ] リリースはできる限り避けるべき
解説: 変更を小さく頻繁に出すことで1回あたりのリスクが下がり、問題の特定も復旧も速くなります。
Q: Four Keys に含まれる指標の組み合わせとして正しいのはどれ?
- [ ] コード行数と会議の回数
- [ ] サーバー台数と社員数
- [x] デプロイ頻度と平均復旧時間(MTTR)
解説: Four Keys はデプロイ頻度・変更のリードタイム・変更障害率・平均復旧時間の4つで、速さと安定の両面を測ります。