DevOps 是什么不是什么
一、DevOps 到底是什么不是什么?
DevOps 到底是不是一個職位，還是像敏捷、精益一樣是一種思想、***實踐?
如果我們看看最近的招聘信息，職位可謂五花八門：技術經理、架構師、布道師、開發總監什么的，當然也有比較新的職位名稱，比如數據科學家、運維開發工程師。
不過總體說來主流的分類方式還是分為兩大類：開發工程師(Development)和運維工程師(Operations)，即便是所謂的 DevOps 工程師，也更多是偏運維的成分更多一些。
不過大叔覺得，運維工程師的名字應該叫基礎設施工程師( Infrastructure engineer )更合適一些。
我們這兩年經?？吹紻evOps這個詞，也有很多專門以 DevOps 為主題的大會。大多數人可能對這個詞的定義并不明確，其實即使整天口頭 DevOps 的人，也不一定就完全理解 DevOps 的真正內涵，很有可能就是從字面上的簡單理解。
為了更好地理解 DevOps 奧義，我們不妨先從 DevOps 的起源和背景開始說起。
二、DevOps出現的背景
隨著計算機技術的發展，工作內容更細分化、專業化，所以工作職責也逐漸分出開發( Development )和運維( Operations )兩個完全獨立的角色，更多的也都是處于獨立的部門。
運維人員看重的是保障系統的穩定性、可靠性和安全性，而開發人員則想著如何盡快發布新的版本，增加新的功能，這兩者本身就是一種矛盾和沖突，盡管他們的共同目標都是為用戶提供軟件產品或服務。
10 幾年前的軟件開發模式也比較單一，基本上市瀑布模式，也有一些采用了螺旋模型。基本上一個項目基本設計兩月，詳細設計兩個月，開發三個月，測試二個月，上線，總體下來，6 個月算是比較小的項目了，大的項目花費數年的時間也是屢見不鮮。
同時，隨著云計算技術和平臺的出現和迅速普及，基礎設施變得更容易獲得，也變得可編程化，所以開發者可以更容易的進行基礎設施方面的工作，比如創建服務器、 RDS 數據庫，部署應用等。拿 AWS 來說，就提供了非常方便的工具、API 和操作界面，開發者可以通過拖拖拽拽來部署一套網站系統，而不必進行任何底層系統工作。
三、從敏捷開始
進入互聯網時代，唯快不破。
這時候軟件開發的特點，就是快速迭代。feature1 開始，一周設計、一周開發，一周測試，之后上線;在第二周的測試的同時，開發人員已經進入第二輪 feautre2 的開發了。功能的交付間隔變小，交付速度變快;同時，因為能快速的從用戶獲得反饋，試錯成本也變低。
正如《大教堂與集市》這本書提到過這么一句話：
| Release early. Release often. And listen to your customers. |
也就是說，我們盡量提早發布、頻繁發布，然后傾聽用戶的聲音。
2008年的時候敏捷開發已經相當流行了，而在開發之外，比如運維、IT或者銷售等部門，敏捷的認知程度還很低。
DevOps 出現的一年之前，2008 的加拿大多倫多，舉辦了 Agile 2008 conference ，比利時的獨立咨詢師 Patrick Debois ( http://www.jedi.be/blog/ )發表了題為 《Agile Infrastructure & Operations》 的演講，可以認為，正是從大概這個時間點開始，DevOps 的概念逐漸開始萌芽。
***份 paper 《Agile Infrastructure & Operations》：
http://www.jedi.be/presentations/agile-infrastructure-agile-2008.pdf
Patrick Debois 本人即做過開發，也做過運維，更了解兩種角色的異同。因此，他在本次敏捷大會上，介紹了讓開發部門做 Product Owner(Scrum用語)，在數據中心或者基礎設施工作中實施敏捷的案例。
四、DevOps概念的萌芽
在加州舉辦的 O’Reilly Velocity 2009 上，Flickr 的工程師 John Allspaw 和 Paul Hammond 發表了題為《10+ Deploys per Day: Dev and Ops Cooperation at Flickr》的演講，雖然沒有直接提出來 DevOps 這一叫法，但是一般都認為這時候 DevOps 的思想已經誕生，這次演講也成為 DevOps 這一稱呼出現的契機。
O’Reilly 主辦的 Velocity 大會知名度非常高，但是其大會內容相對于開發來說，更多的是側重于運維的內容。其實這個大會本身也是我們所說“開發和運維的分離(割裂)”的證明之一。
Flickr 的這個演講，主要介紹了開發和運維圍繞著共同目標，如何緊密合作，實現 1 天之內完成 10 次以上的軟件發布，這也和維基百科上對 DevOps 的定義
是一致的。該演講也同時指明了，由于開發和運維在組織上的割裂，會導致互相之間的利益沖突，而沖突則會導致大家偏離組織最初的、統一的、整體的目標。其實銷售和開發、銷售和運維之間也有類似問題存在。銷售要快速滿足客戶需求，開發偏保守，一般不敢輕易承諾;同樣，運維對開發也像開發對銷售一樣保守，更看重穩定性，不愿輕易改變。
利益沖突導致的問題愈演愈重，一定會發生各種狗血的劇情，完全超出開發或者運維本職工作范圍之內。
Patrick Debois 也觀看了這場演講的視頻，并在這之后發起了 Devopsdays ( http://www.devopsdays.org/ )活動，這也標志著 DevOps 的開始普及。DevOps 這一叫法真正出現，也是源于 2009/10/30 在比利時舉辦的 DevOpsDays Ghent 2009 活動。
第二份 paper 《10+ Deploys per Day: Dev and Ops Cooperation at Flickr》： http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
五、DevOps不是什么
先說說 DevOps 不是什么，以此來和大家探討一下之前很多人可能存在的對 DevOps 的誤解。
DevOps 不是一種職位，因此所謂的 DevOps 工程師到底是什么?是不是就是具備很強編碼能力的運維(或者叫基礎設施工程師更合適)。
DevOps 也不是一個部門，不是 DevOps 工程師的集合。
那面對招聘信息或者自稱 DevOps 工程師的事情該怎么看呢?其實既然大家都有這個“誤解”，也不必矯枉過正，就好比主角或角色的“角”，到底是念 júe ，還是念 jiǎo 一樣，我們按照自己的習慣念就好了，到了現在，感覺這些字的念法已經沒有對錯之分了。
話說 AWS 有一個認證 DevOps 工程師( Certified DevOps Engineer ，https://aws.amazon.com/certification/certified-devops-engineer-professional/ )，所以 DevOps 工程師這一職位/角色可能會一直存在下去吧。
DevOps 也不意味這 Dev 和 Ops 要歸屬統一部門，向同一領導報告。只要觀念和認識沒有變化，認識不到大家的共同目標，沒有采取積極的溝通方式，即使在同一個團隊，不同角色的人也很難做到統一思想、團結一致向前看。
六、DevOps到底是什么
根據維基百科上的定義，DevOps 強調開發人員和運維人員(IT人員)的合作，實現軟件交付和基礎設施變更的自動化。它旨在建立一種可以快速、頻繁、可靠地構建、測試和發布軟件的文化。
一句話來說， DevOps 其實是一種思想、一組***實踐、以及一種文化。說得更冠冕堂皇一點，DevOps 是指開發人員和運維人員精誠合作，迅速為用戶提供***的功能，保持系統的穩定運行，為用戶提供***的商業價值。
七、DevOps的基礎
大體來說，DevOps 可以認為是 一組工具 + 企業文化。
1. 工具集(toolchain)
由于 DevOps 涉及到各個部門以及軟件開發的整個生命周期，所以我們需要使用多種軟件來支撐我們的 DevOps 實踐。比如至少在這些方面，我們已經有很多非常好用的工具可以選擇了：
- 代碼管理：編輯器、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 思維開發云原生的應用程序，也有一些像 Docker cloud 這樣的提供基于 Docker 容器的管理平臺，國內的靈雀云也是這樣一個基于 DevOps 理念打造的開發、運維一體化的企業級容器云平臺 。
2. 組織文化
在企業文化方面，DevOps 推崇尊重(Respect)、信賴(Trust)、正視失敗(Healthy attitude about failure)、不埋怨(Avoiding Blame)等。當然，這幾條只是 2009 年 Flickr 的工程師演講中講到的幾點，實際上范疇還要更廣泛的多，每個組織都需要自己定制。
其實這是一門管理學。DevOps 成功的關鍵在于文化，沒文化真可怕，即使是開發、運維肩并肩坐著，一塊吃飯、睡覺，開發也還是原來那個開發，運維也還是原來那個運維。
除了上面提到的工具和文化，我們還可以總結出很多 DevOps 的其他因素，比如人(People)的思想和思考方式、開發和運維的流程(Process)、精益(Lean)、自動化(Automation)、測量(Measurement，請參考 指標驅動開發(MDD) )、共享(Sharing)、溝通(Communication)、PDCA/OODA 等。
管理學的理論、工具也是多如牛毛，能利用的都該利用。
那這里可能大叔重點說一下同理心(Empathy)，也叫做換位思考，在溝通過程中，主動去了解他人的想法、理解他人的立場和感受，站在他人的角度思考和處理問題。同理心是一個雙方向的對話，是一種解決沖突和滿足雙方需求的途徑。
沒有同理心、沒有互相理解，即使我們強制采取 DevOps 的方法和實踐，強制一天部署一次，強制自動化，也只能是暫時的，不能獲得組織內的認同和理解，不能實現真正的 DevOps 。同理心讓 Ops 認識到原來快速、頻繁的發布并沒什么大驚小怪的，也沒什么好可怕的;讓開發人員意識到自己寫了多么愚蠢、性能低劣、安全漏洞多的軟件。正是同理心的作用，才能讓 Dev 和 Ops 團結起來為用戶提供***的服務和產品。
八、DevOps不只有 Dev 和 Ops
DevOps 只有 Dev 和 Ops 還是不夠的。
其實在 《Agile Infrastructure & Operations》 中，Patrick Debois 就列舉了三個角色(部門)：
- Developer(開發、測試)
- IT(基礎設施、服務器、網絡設備)
- Operation( helpdesk、用戶支持)
DevOps 雖然名字來源于開發和運維的縮寫，但是無論從我們前面看到的兩篇演講內容，還是維基百科的定義，除了開發人員之外，還有一個角色是 IT ，當然很多傳統的大公司可能會將運維算入到 IT 部門。
而現實中，其實 DevOps 的涵蓋范圍可能會更廣：除了開發(包括測試)、運維和IT，還會涉及到項目經理、產品經理，甚至和銷售、市場、HR以及財務等各個部門的人也會產生聯系，跨職能部門互相合作，完成某一項目或任務。
【本文為51CTO專欄作者“徐磊”的原創稿件，轉載請通過作者微信公眾號devopshub獲取授權】
