DevOps之我見

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

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

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

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

一、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實際上是敏捷開發時代的一個產物。

人們須要這麼一個理念，可以在敏捷開發時代裏快速響應，加快迭代、部署的節奏。

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

二、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 思惟開發雲原生的應用程序 。

三、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）等更高層面的組織文化，本文就不一 一敘述了。

四、DevOps is a title or not

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

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

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

Damon Edwards有一段經典的話：

This makes DevOps someone else's problem.
You're a DBA? Don't worry about DevOps, that's the DevOps team's problem.
You're a security expert? Don't worry about DevOps, that's the DevOps team's problem.

DevOps涵蓋的內容實在太多了，能夠覆蓋整個產品的生命週期，已經不是通常意義上的「全棧」了。

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

每日干貨分享，傳遞互聯網世界有價值的訊息，盡在「技術匯」