TL;DR
DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality.
我在許多演講場合，都喜歡調侃 DevOps 百家爭鳴各言爾志的現況。尤其是像 XebiaLabs 的 “Periodic Table of DevOps Tools"，用化學元素週期表來類比，傳神極了！
調侃歸調侃，但總還是得選一套說法當參考座標，議題定位才能明確。我也不喜歡太欠缺客觀性的打高空調調，尤其是涉及組織文化層面的論調。畢竟，DevOps 雖然和 agile 運動有歷史上的臍帶關係，但嚴格來說，沒有遵循《敏捷宣言》四大原則，也是能做 DevOps 的；硬是把兩個議題綁在一起，會限縮 DevOps 論述空間，很容易挑起 “it doesn’t work here” 的防禦心態。
推廣新觀念，就要從阻力最小的角度切入。
因此，我在去年 12 月 Container Summit 2015 講〈擁抱或對抗？談 Docker 對傳統 DevOps 工具鏈的衝擊〉時，首次搬出 Brian Brazil 在 “Do you have basic infrastructure?” 一文提出的三問句來破題：
You need to know:
- How to recreate your system
- How to safely change your system
- When something has gone wrong
蘇格拉底式問句，不夾帶特定前提，不偷渡既定結論，很適合拿來引導團隊思考。因此，後來我在〈DevOps 是圓的，找到立足點就是頂點〉文章、在 Ansible Workshop 課堂上，也反覆用到這三問句。
不過，私心還是希望能有一個更直述、更目標導向的操作型定義。
找了很久，偶然在 2015 年 SEI 系列的新書 DevOps: A Software Architect’s Perspective 第一章，發現我想要的操作型定義了。
SEI 這塊金字招牌，乍看之下會以為又要端出像 CMMI、PSP 那樣硬梆梆的東西。不過，瞄到書名當中有 “A Software Architect’s Perspective” 字眼，就覺得應該比較貼近第一線的實務現場。
他們的切入角度是：
Our definition of DevOps focuses on the goals, rather than the means.
很多時候，先聚焦在共有的目標上，會比過早陷入細部做法的爭論來得有用。
從「目標」角度出發，再對 DevOps 下定義，更顯得客觀中立。畢竟，不管是大機構還是小團隊，不管背後採用哪一種軟體開發流程，都能接受以下這種 DevOps 目標：
DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality.
這跟前面那三問句是相互呼應的，只不過這一回用的是更直述、更目標導向的操作型定義。
這段定義陳述，點出 DevOps 兩大目標：時間及品質：
- 時間：在「commit change」到「上線營運生效」兩者之間的時間差，要盡量縮短到某個設定的水平之內。
- 品質：不能只求上線生效，還要對品質把關，維持在某個設定的水平之上。
弄清楚 DevOps 的目標後，再看 DevOps 圈子倡議的 practices，就不覺突兀：
- Treat Ops as first-class citizens from the point of view of requirements.
- Make Dev more responsible for relevant incident handling. These practices are intended to shorten the time between the observation of an error and the repair of that error.
- Enforce the deployment process used by all, including Dev and Ops personnel.
- Use continuous deployment.
- Develop infrastructure code, such as deployment scripts, with the same set of practices as application code.
這五項 practices，都可以回溯到先前設定的 DevOps 兩大目標：時間及品質。
當然啦，同一份目標，可能衍生出不同的實作手法；此時此刻公認的 best practices，也可能在不久就被推翻。書中建議我們可以根據幾點來評估：
-
What is the particular practice you are considering?
這家 DevOps 百貨公司，大肆推銷的東西太多了，必須先針對組織的需求及現況加以評估、排序。 -
What other practices are implicit in the practice you are considering?
某些措施有隱含的前提。譬如說，想實現 continuous deployment 之前，不可能不先做 continuous integration。 -
What is the culture of your business, and what are the ramifications of your adopting this particular DevOps practice?
任何改變都有受到波及的對象，所以，想導入任何改變，都不能忽略組織及人性的抗拒力道。
這就是 SEI 出版的書 DevOps: A Software Architect’s Perspective 當中的第一章，對於 DevOps 下的目標導向定義，以及隨之鋪陳的實踐手法及考量依據。