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:
1. How to recreate your system
2. How to safely change your system
3. When something has gone wrong

蘇格拉底式問句,不夾帶特定前提,不偷渡既定結論,很適合拿來引導團隊思考。因此,後來我在〈DevOps 是圓的,找到立足點就是頂點〉文章、在 Ansible Workshop 課堂上,也反覆用到這三問句。

不過,私心還是希望能有一個更直述、更目標導向的操作型定義。

找了很久,偶然在 2015 年 SEI 系列的新書 DevOps: A Software Architect’s Perspective 第一章,發現我想要的操作型定義了。

DevOps: A Software Architect's Perspective

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,就不覺突兀:

  1. Treat Ops as first-class citizens from the point of view of requirements.
  2. 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.
  3. Enforce the deployment process used by all, including Dev and Ops personnel.
  4. Use continuous deployment.
  5. Develop infrastructure code, such as deployment scripts, with the same set of practices as application code.

這五項 practices,都可以回溯到先前設定的 DevOps 兩大目標:時間及品質。

當然啦,同一份目標,可能衍生出不同的實作手法;此時此刻公認的 best practices,也可能在不久就被推翻。書中建議我們可以根據幾點來評估:

  1. What is the particular practice you are considering?
    這家 DevOps 百貨公司,大肆推銷的東西太多了,必須先針對組織的需求及現況加以評估、排序。

  2. What other practices are implicit in the practice you are considering?
    某些措施有隱含的前提。譬如說,想實現 continuous deployment 之前,不可能不先做 continuous integration。

  3. 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 下的目標導向定義,以及隨之鋪陳的實踐手法及考量依據。