かんばんガイド · リーンの基礎
DevOpsとは？文化、プラクティス、メトリクス
DevOpsは、ソフトウェア開発とIT運用を結びつけ、チームが変更を迅速かつ確実に届けられるようにするための文化的価値観、プラクティス、ツールの集まりです。アジャイルとリーンの考え方を、コードから顧客までの全工程に広げるものです。
要点
- DevOpsは共通の目標のもとに開発と運用を結びつけます。
- CALMSと「3つの道」がその原則をまとめています。
- デプロイ頻度、リードタイム、変更失敗率、復旧時間で測定します。
起源
DevOpsという言葉は2009年頃、Patrick Debois氏がベルギーのゲントで最初のDevOpsDaysカンファレンスを開催したときに生まれました。変化を求める開発者と安定を求める運用担当者の間にある壁への不満から発展したものです。
CALMSモデル
| 要素 | 意味 |
|---|---|
| 文化 | 開発と運用の責任共有と協働 |
| 自動化（Automation） | ビルド、テスト、インフラ、デプロイを自動化する |
| リーン | 小さなバッチ、WIPの制限、フローの重視 |
| 測定（Measurement） | フロー、品質、ユーザーの成果を測定する |
| 共有（Sharing） | 知識、ツール、教訓を共有する |
3つの道
『The Phoenix Project』と『The DevOps Handbook』によって広まりました：
- フロー： 開発から運用、そして顧客への作業の流れを速める。
- フィードバック： 運用とユーザーから開発への迅速なフィードバックを生み出す。
- 継続的な学習と実験： 失敗から学び、改善する文化を築く。
主なプラクティス
- 継続的インテグレーションと継続的デリバリー.
- Infrastructure as Code（コードとしてのインフラ）。
- 自動テストと監視。
- フィーチャーフラグを使った小規模で頻繁なリリース。
- 自らサービスを構築し運用するチーム。
- 非難しないインシデント事後レビュー。
DevOpsのパフォーマンスの測定
DORAの研究プログラムは、ソフトウェアデリバリーの4つの主要指標を広めました：
- デプロイ頻度： どれくらいの頻度でリリースするか。
- 変更のリードタイム： コミットから本番環境まで。
- 変更失敗率： 問題を引き起こしたリリースの割合。
- サービス復旧時間： 障害からどれだけ早く復旧するか。
このトピックの無料テンプレート
よくある質問
DevOpsは役割ですか、それとも文化ですか？
主に文化とプラクティスの集まりです。多くの組織には、自動化とツールに注力する「DevOpsエンジニア」という役割もあります。
DevOpsはかんばんとどう関係しますか？
どちらもフロー、小さなバッチ、可視性を重視します。多くの運用チームやプラットフォームチームが作業管理にかんばんを使っています。
DevOpsとは、簡単に言うと何ですか？
DevOpsは、ソフトウェア開発とIT運用を結びつけ、チームがソフトウェアをより速く、より確実に構築、リリース、運用できるようにする働き方です。
DevOpsはいつ始まりましたか？
この言葉は2009年頃、Patrick Debois氏がベルギーのゲントで最初のDevOpsDaysカンファレンスを開催したときに生まれました。
DevOpsにおけるCALMSとは何の略ですか？
文化（Culture）、自動化（Automation）、リーン（Lean）、測定（Measurement）、共有（Sharing）：DevOpsの主要な要素をまとめたモデルです。
DevOpsにおける4つのDORA指標とは？
デプロイ頻度、変更のリードタイム、変更失敗率、サービス復旧時間です。ソフトウェアデリバリーの速度と安定性の両方を測定します。
DevOpsの「3つの道」とは？
開発から運用へのフロー、双方向の迅速なフィードバック、そして継続的な学習と実験の文化です。
DevOpsはアジャイルの一部ですか？
DevOpsはアジャイルの考え方を開発の先、リリースと運用にまで広げます。アジャイルはソフトウェアの構築を速め、DevOpsはそれを安全にユーザーへ届けるまでを速めます。
DevOpsと継続的デリバリーの違いは何ですか？
継続的デリバリーは、ソフトウェアを常にリリース可能な状態に保つための具体的な技術的プラクティスです。DevOpsはより広い文化とプラクティスの集まりであり、継続的デリバリーはその重要な一部です。参考： 継続的デリバリー.
DevOpsエンジニアは何をしますか？
DevOpsエンジニアは通常、デプロイパイプライン、インフラの自動化、監視を構築・保守し、開発チームと運用チームの協働を支援します。
DevOpsにおける非難しないインシデント事後レビューとは？
障害発生後に行うレビューで、誰を責めるかではなく、システムの何が問題の発生を許したかに焦点を当てます。それにより、人々が情報をオープンに共有し、チームが学べるようにします。