DevOps之我見

又是一個火得一塌糊塗的概念，最早看到這個辭彙的時候是在2015年。

彼時距離「DevOps」這個術語誕生已有六年之久，後知後覺的我，開始意識到DevOps的先進性和重要性。

現如今（2017年），DevOps已誕生了8年了，與此同時，一年一度的「DevOpsDays」盛會也在北京順利舉辦，而且身為DevOps之父的Patrick Debois也親自參加了。

可見國內的DevOps圈子已相當活躍了，致力於DevOps實施落地的公司也會越來越多了，這方面， ThoughtWorks算是業界的領跑者了。

1、Definitions and History

這一切還要從敏捷開發說起。

2008年的時候敏捷開發已經相當流行了，所以才會是不是有關於敏捷開發的大會，其中有一場在加拿大多倫多舉辦的Agile Conference，來自比利時的Patrick Debois發表了題為 《Agile Infrastructure & Operations》 的演講，可以認為，正是從大概這個時間點開始，DevOps 的概念逐漸開始萌芽。

時隔一年，在加州舉辦的 O』Reilly Velocity 2009 上，Flickr 的工程師 John Allspaw 和 Paul Hammond 發表了題為《10+ Deploys per Day: Dev and Ops Cooperation at Flickr》的演講，雖然沒有直接提出來 DevOps 這一叫法，但是一般都認為這時候 DevOps 的思想已經誕生，這次演講也成為 DevOps 這一稱呼出現的契機。

Flickr 的這個演講，主要介紹了開發和運維圍繞著共同目標，如何緊密合作，實現 1 天之內完成 10 次以上的軟體發布，這也和維基百科上對 DevOps 的定義是一致的。

同年，Patrick Debois便發起了名為「DevOpsDays」的活動，這也標誌著 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. ——from wikipedia

根據維基百科上的定義，DevOps 強調開發人員和運維人員（IT人員）的合作，實現軟體交付和基礎設施變更的自動化。它旨在建立一種可以快速、頻繁、可靠地構建、測試和發布軟體的文化。

一句話來說， DevOps 其實是一種思想、一組最佳實踐、以及一種文化。

說得更冠冕堂皇一點，DevOps 是指開發人員和運維人員精誠合作，迅速為用戶提供最新的功能，保持系統的穩定運行，為用戶提供最大的商業價值。

這麼說起來，DevOps其實是敏捷開發時代的一個產物。

人們需要這麼一個理念，能夠在敏捷開發時代里快速響應，加快迭代、部署的節奏。

可能開發技術足夠好了，然而運維能力卻無法跟上。但運維能力提升了，卻未必能與開發技術很好的融合。當兩者經歷了磨合期之後，我們又該考慮所造就的產品的質量是否達標。

2、Toolchain

這部分的是被談及到最多的內容，畢竟這也是DevOps落地的重要環節之一。

你稍微關注一下Puppet，Chef，ControlTier 等社區，就不難理解為什麼人們會把這些工具認為是開發和運維之間的橋樑。

再比如「Infrastructure as code」「Continuous Integration」「Continuous Delivery」等概念/工具，都是和DevOps息息相關的。

由於 DevOps 通常是跨部門的工作模式，所以單一的工具並不能足以完成日常工作，而需要使用多種工具來支撐。

整個工具鏈貫穿了開發和運維的整個生命周期，每個節點都分布了一個或者多個工具，工具的選擇或者自實現都需要考慮對整個生命周期的影響。

代碼管理：代碼編輯器、Code Review工具、版本管理工具等。

打包和構建：npm、maven、Docker、Jenkins 等，最近都是很火的工具。

CI/CD：各種 CI 工具和服務，比如 DroneIO、Wercker、Travis CI、CircleCI、Codeship等。

配置管理（或 Automated infrastructure ）：實現基礎設施即代碼（Infrastructure as Code），比如 Ansible、Chef、Puppet 等。

監控：各種開源組件，ELK 全家桶、InfluxDB、Grafana、Graphite 等。

發布系統：Codeship、Jenkins 等都可以使用。

ChatOps： Slack、HipChat，以及國內的 bearychat 等。

其他可能需要的工具需求也很多，比如灰度發布、A/B 測試、滾動更新等。

除了上面說的這些開源工具、SaaS 服務，也有一些管理平台服務，比如 AWS ，提供一套服務、流程來方便我們基於 DevOps 思維開發雲原生的應用程序 。

3、Culture

如果說工具鏈是DevOps的血肉，那麼文化則是DevOps的靈魂。

這部分也是本文要著重闡述的內容。

這兩天看過太多關於開發人員與運維人員撕x的文章，因為這對於解釋DevOps在實際工作中的好處是非常有利的證據。

首先，我們說說著名的「Wall of confusion」。附上一張經典的圖片：

實在是不要太形象！

實際上確實存在一個矛盾點：

站在開發人員的角度考慮，BOSS們的商業宏圖需要靠這幫人去實現，在這個商場如戰場，險惡叢生，瞬息萬變的社會，產品的形態是不會一成不變的，在發展的道路上，多少會有一些調整。這是一個求變的過程，怎麼變？那還得靠程序員哥哥們咯！所以，他們的思路是產品隨時會變，所以在設計系統架構的時候額外小心，萬一有什麼沒考慮到，釀成大錯就不好了。

正所謂：客戶虐我千百遍，我待客戶如初戀。

站在運維人員的角度考慮，那又是另外一番場景了。有變動，就意味著需要重新打包，部署，這個過程不能保證每次都百分百成功，當這種意外發生了，運維人員是很操心的。

最怕Dashboard突然彈出一條通知，郵箱里突然躺著一封告警郵件，手機突然收到一條簡訊，還有運維經理突然的關心。。。

正所謂：小改怡情，大改傷身，強改灰飛煙滅。

更糟糕的是，萬一這是一家跨國企業，開發和運維部門分散在世界不同的位置，這就更加深了彼此之間的隔閡了。

除此之外，開發和運維兩個部門的「甩鍋事件」也是時有發生的。

開發人員認為應用完成開發了一個版本，接下來就是運維人員的工作了。

專業點的開發人員會寫好腳本，做好配置，寫好REAME，傳給對應的運維人員。

當運維人員接下這個部署任務後，可能跟開發人員用的不是同一套環境，或者不是一樣的工具，拿著腳本隨手就是一改，沒有腳本的話，就按之前的工作，重新走一遍流程。

上圖非常形象的反映了「甩鍋事件」的過程。

最好的情況是運維人員在重複之前的工作，最壞的情況是運維人員之間搞出了bug，最後還把鍋甩給QA部門。

DevOps的目標是工程效率最大化，它本身也只是一種方法論，是為了實現工程效率最大化的目標而存在的。

簡單來講，就是打破「Wall of Confusion」，並尋找到新的「制衡點」。

DevOps理念的可貴之處在於可以讓我們從產品的整個生命周期考慮，或者說是從一個更高的視角（公司層面）考慮問題，先上一張圖：

上圖將整條業務線（Business Process）分解成了三個步驟：

• Biz，即業務部門。
• Dev，即開發部門。
• Ops，即運維部門。

他們仨彼此之間都有一堵牆。

業務部門與開發部門的隔閡可以用敏捷開發（Agile Development）打破。在商業驅動的前提下，敏捷開發其實是一種以低成本且有效的快速適應市場環境變化的能力。

當然，在開發人員看來，部署的次數增加了，release版本的錯誤率降下來了，線上fix的時間縮短了等等，都是敏捷開發的現象。

因為敏捷開發不是本文的重點，故不再展開闡述。

開發部門與運維部門的隔閡則可以用DevOps打破。

首先需要解決的就是上述提及的「甩鍋」問題，Patrick Debois在《Devops from a sysadmin perspective》一文中主張了兩種文化：Culture of collaboration、Culture of sharing。

開發部門和運維部門是事實上的兩個部門，但是應該讓他們走得更近。

instead of separating developers and operations as we used to do, we need to bring them together more closely.

目的就是去了解彼此的工作，更具體一點，就是了解各自的工作流程，以及用到的一些輔助實現手段，並試圖去達成一致。

開發人員輔助運維人員建立持續交付模型，運維人員輔助開發人員搭建運行環境，將開發，測試，UAT，生產等多個環境保持一致。

Patrick Debois甚至主張開發人員和運維人員結對工作，運維人員在部署之前，會與對應的開發人員進行討論評估影響，以免造成更嚴重的後果。

對於各種Metrics，運維部門也不能藏著掖著，要將它們分享給公司的其他部門，以便讓其他部門的人也能從中學到一些東西。與所有利益干係人一起做事後檢查，並進行改進。

與此同時，這也改變了度量和監控的焦點，從運維人員的快速修復變成了及時反饋到整個組織。目標就是從整體上進行優化，而不僅僅是局限在自己工作的部分。

關於尊重（Respect），信賴（Trust），不埋怨（Avoiding Blame）等更高層面的組織文化，本文就不一 一敘述了。

4、DevOps is a title or not

既然DevOps這麼重要，那就成立一個「DevOps」部門，然後招聘一幫DevOps工程師。

這麼做也有一定的道理，畢竟Amazon還專門出了一個「DevOps工程師」的認證（Certified DevOps Engineer），想必這個title會一直存在下去。

當然，大多數還是反對的聲音，最起碼Patrick Debois不認為DevOps是一個職位或者部門。

Damon Edwards有一段經典的話：

This makes DevOps someone elses problem.

Youre a DBA? Dont worry about DevOps, thats the DevOps teams problem.

Youre a security expert? Dont worry about DevOps, thats the DevOps teams problem.

DevOps涵蓋的內容實在太多了，可以覆蓋整個產品的生命周期，已經不是一般意義上的「全棧」了。

歸根結底，我們要招的不是DevOps工程師，而是了解DevOps方法論的相關人員，他們可以是開發人員，項目經理，測試人員，運維人員等等。

推薦閱讀：