業務で DevOps を本格的にしかけていくことになりました。こういったことに手を付けるには、どれだけ自分の中にその概念を腹落ちさせるのかが重要だと思っています。

DevOps とは何か

各種資料・文献での定義

「DevOps とは何か」と言われると一言では表しにくいので、それぞれの文献や資料でどのような定義がなされているか、まずは整理してみました。

興味深いのは、以下の点でした。

DevOps は組織的な取り組みであること
Gartner の用語集が定義する DevOps においては「テクノロジー」が出てくるのは DevOps の「実装」であること
「開発チーム」が「運用」まで行うとは述べられていない(あくまで協調である)こと

What is DevOps? Research and Solutions | Google Cloud

「DevOps とは、ソフトウェアデリバリーの速度とサービスの信頼性の向上、ソフトウェアの関係者間で共有するオーナー権限の構築を目的とする、組織的で文化的な仕組みです」

Definition of DevOps - IT Glossary | Gartner

「DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and it seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology — especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.」

DevOps導入指南 Infrastructure as Codeでチーム開発・サービス運用を効率化する

「Dev(開発)と Ops(運用)が密に強調・連携して、ビジネス価値を高めようとする働き方や文化を指します。DevOps では、開発と運用が協調することにより、多くのチーム間のオーバヘッドを解消することによって、省力化して開発に速さを与え、お互いの理解によって変更に柔軟性を与えます」

GitLab実践ガイド impress top gearシリーズ

「ビジネスやプロジェクトを成功させるために、組織文化とツールの両面を改善させることで、ビジネスアジリティを向上させ、リスクを低減する活動」

DevOpsとは何か？そのツールと組織文化、アジャイルとの違い - Build Insider

「DevOpsとは「開発チーム（Development）と運用チーム（Operations）がお互いに協調し合うことで、開発・運用するソフトウェア／システムによってビジネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ迅速にエンドユーザーに届け続ける」という概念である。」

DevOps とは何でないのか

定義を整理する中では「何であるのか」とともに「何でないのか」を認識することは重要です。こちらは The DevOps ハンドブックから。

The DevOps ハンドブック理論・原則・実践のすべて

作者:ジーン・キム,ジェズ・ハンブル,パトリック・ボア,ジョン・ウィリス
日経BP

Amazon

単なる "Infrastructure As Code" あるいはオートメーションではない
- 「DevOps のパターの多くは自動化を必要とするが、文化的な規範やアーキテクチャも必要とする」
DevOps は "NoOps" という意味ではない
- 「IT 運用の仕事の性質は変わるかもしれないが、従来と同じように重要な存在で有り続ける」

DevOps は何で評価されるのか

DevOps がデリバリや運用の能力を改善するものだとして、ぼくたちはそれを評価する必要があります。

Stete of DevOps 2019 では、これらの能力を評価するために以下の 5 つのメトリクスを発明し検証しています。これらのメトリクスは、Software delivery and operational (SDO) performance と呼ばれています。

Lead Time: コードが commit されてから本番環境で動作するまでの時間
Deployment Frequency: 本番環境にコードをデプロイ、あるいはエンドユーザにリリースする頻度
Change Fail: サービスがデグレードし、対応が必要になった本番環境変更の割合
Time to Restore: ユーザ影響のある問題が発生したときの復旧までの時間
Availability

このうち最初の 4 つは Four Key Metricsと呼ばれ、ThoughtWorks 社の Technology Rader 上で ADOPT として評価されているものです。

これらはトレードオフの関係にあるわけではなく、両立できるものであることがデータからも示されています。

DevOps は何によって構成されるのか

Stete of DevOps 2019 では、SDO Performance、そして組織パフォーマンスが何によって駆動されるかを以下のようにモデル化しています。

行ってみれば、このモデルの一つ一つが DevOps の構成要素ということになるでしょう。

DevOps の原則

これらは、The DevOps HANDBOOK に記載があります。

開発→運用→顧客の左から右へのワークフローを高速にする
- 継続的なビルド、インテグレーション、テスト、デプロイプロセス、オンデマンドによる環境の作成、仕掛りの削減、変更に強いシステムと組織の構築
- バッチサイズ、受け渡しの数の削減
  - Martin Fowler の呼ぶ「backlog coupling」の削減は、DevOps の思想そのもの
バリューストリームのあらゆるステージで、すばやくてコンスタントな右から左へのフィードバックフローを実現すること
1. 発生と同時に問題を知る。それにより、問題を下流に波及させない。仕事が行われている現場で品質や安全性に責任を持ち、意思決定を行えるようにする。
成功と失敗の両方から組織として学習し教訓を得ていく生産的な高信頼マネジメントの企業文化を生み出す

それぞれの原則は互いに直交しているのではなく、それぞれが密に関係しあっています。ワークフローを高速にするためには、ワークフロー上のそれぞれのタスクの中で、素早いフィードバックを作業者に返さなければなりません。それによって初めて、作業者がそのタスクに責任を持てるようになります。フィードバックを行うためには、様々なところで計測を行い可視化する必要もあるでしょう。

また、そういったフィードバックによって生まれる学びは、個人ではなく組織に対する学びに昇華させなければなりません。