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