DevOps
開発チームと運用チームの協働を促進し、ソフトウェアのデリバリーと品質を継続的に改善する文化・プラクティスの総称
DevOps とは
DevOps は、Development (開発) と Operations (運用) の壁を取り払い、ソフトウェアのビルド・テスト・リリース・運用を一体的に行う文化とプラクティスの総称である。2009 年の DevOpsDays カンファレンス (ベルギー) で Patrick Debois が提唱し、急速に広まった。
単なるツールの導入ではなく、組織文化の変革を伴う点が本質だ。CI/CD パイプラインを構築しても、開発チームと運用チームが別々のサイロで働いていれば DevOps とは言えない。
DevOps 以前の問題
従来の開発プロセスでは、開発チームが「新機能を速くリリースしたい」、運用チームが「システムを安定させたい」という相反する目標を持ち、対立構造が生まれていた。
- 開発チームがコードを「壁の向こう」に投げ、運用チームがデプロイする
- 本番障害が起きると「開発のバグだ」「運用の設定ミスだ」と責任の押し付け合い
- リリースは月 1 回の大規模デプロイ。変更量が多いため障害リスクが高い
- 障害の原因調査に数日かかる (開発者が本番環境にアクセスできない)
DevOps の 3 つの道 (Three Ways)
Gene Kim が「The Phoenix Project」「The DevOps Handbook」で体系化した 3 つの原則。
第 1 の道 - フローの高速化
コードの変更が本番に反映されるまでのリードタイムを短縮する。
- CI/CD パイプラインで自動ビルド・テスト・デプロイ
- Infrastructure as Code でインフラの変更もコードレビュー対象に
- 小さな変更を頻繁にリリースし、1 回あたりのリスクを下げる
第 2 の道 - フィードバックの増幅
本番環境の状態を開発に素早くフィードバックする。
第 3 の道 - 継続的な学習と実験
失敗から学び、改善を繰り返す文化を醸成する。
- ポストモーテム (障害振り返り) を blame-free で実施
- カオスエンジニアリングで意図的に障害を注入し、耐障害性を検証
- 20% ルールや Hack Day で技術的負債の解消と実験を奨励
CALMS フレームワーク
DevOps の成熟度を評価するフレームワーク。
| 要素 | 意味 | 具体例 |
|---|---|---|
| Culture | 協働と信頼の文化 | blame-free ポストモーテム |
| Automation | 手作業の自動化 | CI/CD、IaC、自動テスト |
| Lean | 無駄の排除 | WIP 制限、バリューストリームマッピング |
| Measurement | 定量的な計測 | DORA メトリクス (後述) |
| Sharing | 知識の共有 | 内部ドキュメント、勉強会、ペアプログラミング |
DORA メトリクス
Google の DORA (DevOps Research and Assessment) チームが特定した、DevOps の成熟度を測る 4 つのメトリクス。
| メトリクス | Elite | High | Medium | Low |
|---|---|---|---|---|
| デプロイ頻度 | オンデマンド (1 日複数回) | 週 1〜月 1 | 月 1〜半年 1 | 半年以上 |
| リードタイム | 1 時間未満 | 1 日〜1 週間 | 1 週間〜1 ヶ月 | 1 ヶ月以上 |
| 変更失敗率 | 0〜15% | 16〜30% | 16〜30% | 46〜60% |
| 復旧時間 | 1 時間未満 | 1 日未満 | 1 日〜1 週間 | 6 ヶ月以上 |
SRE との関係
SRE (Site Reliability Engineering) は DevOps の具体的な実装の 1 つで、Google が提唱した。DevOps が「文化と原則」を定義するのに対し、SRE は「エラーバジェット」「SLO」「トイル削減」など具体的なプラクティスを提供する。Google の Ben Treynor は「SRE は DevOps のインターフェースを実装したクラスだ」と表現している。
DevOps のプラクティス
DevOps のプラクティスを以下に整理する。
| プラクティス | ツール |
|---|---|
| CI/CD | GitHub Actions, CodePipeline |
| IaC | SAM, CloudFormation, Terraform |
| モニタリング | CloudWatch, X-Ray |
| 自動テスト | Vitest, Playwright |
| ChatOps | Slack + Lambda |
# CI/CD パイプライン
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- run: npm ci && npm test
- run: sam build && sam deploy
# インフラの変更もコードレビュー
git checkout -b feature/add-sqs
# template.yaml を変更
git push && gh pr create
より深く学ぶには関連書籍が役立つ。
この記事は役に立ちましたか？
関連用語
CI/CD
コードの変更を自動的にビルド・テスト・デプロイするパイプライン
Infrastructure as Code
インフラの構成をコードで定義し、バージョン管理・自動化・再現性を実現する手法
SRE
Site Reliability Engineering の略で、ソフトウェアエンジニアリングの手法でシステムの信頼性を向上させる実践
DORA メトリクス
ソフトウェアデリバリーのパフォーマンスを測定する 4 つの指標
GitOps
Git リポジトリを唯一の正として、インフラとアプリケーションの状態を宣言的に管理する運用手法
プラットフォームエンジニアリング
開発者の生産性を向上させる内部プラットフォームを構築・運用する実践