幫助盈利/提升文化/加速效率是DevOps實踐的三大目標，上世紀八十年代在制造業領域展開的那場如火如荼的精益實踐的變革還歷歷在目，而DevOps在軟件領域將要或者已經掀起的風浪也是如出一轍。

Dev+Ops = ?

傳統的Dev和Ops之間是割裂的狀態，如果Dev和Ops一起形成了DevOps的方式後將會怎樣?
產品負責人/開發/測試/運維/信息安全等相互之間不再只是相互幫助信息共享，而是作為一個整體保證整個組織的目標實現。他們通過快速的對應，迅速地部署，實現了一流的穩定性/可靠性/安全性的系統服務。
在這裏，跨職能的團隊的合作並不僅僅是為了實現用戶要求的功能，他們保障的是：快速的對應在整個價值流中不會帶來對內或者對外的混亂和困擾。

理想狀況

測試/運維/信息安全等人員會一起工作降低摩擦而使得開發人員更有效率。通過給測試/運維/信息安全人員提供自動化的自助服務，過去那些必須各個團隊的骨幹在一起才能解決的問題通過這些工具和平臺來實現，在每日的工作中，各個團隊彼此之間倚賴性大大降低，這種情況下極大地提升了效率。
這使得一個小型的團隊也能夠快速獨立的完成開發/測試/發布，將開發快速/安全/可靠地為客戶做價值的轉化。這使得組織能夠最大化開發者的生產效率，提升員工滿意度，在市場競爭中脫穎而出。這些是DevOps所帶來的結果。

現實情況

而在更多的現實世界中，不存在一個整體，到處是割裂的碎片。
開發和測試是水火不容的，仿佛雙方都是為了證明愚蠢的是對方而存在。
測試和信息安全行為的結合只是在項目的結束才會引入，一般都已經太晚基本上是走個過場，或者大體解決面上的問題。
留給我們很多手工去處理的余地，以及這些不穩定性所帶來的各種副作用。不僅僅是交付時間變長，更多的是這些工作的質量往往是不可控的，因為在這種情況下，現實情況已經成為最終出場救火隊員必須擔負這些割裂所能帶來的如同大廈將傾的趨勢，在現實的世界中這些救火隊員不斷的扮演奇跡，但是也有很多很多的失敗。成功的救火往往也能留下各種隱患，潛在以及時而出現的由此引起的問題給項目帶來很大的影響，而且無法避免地影響到顧客和業績。最終的結果就是，項目在短期目標上的失敗，整個組織對IT的各種不滿，以及由此帶來的預算收緊，同時眾多面對各種變更和不可知的質量部署的郁悶和無助的運維人員。

解決方法

怎麽辦？需要改變的是工作的方式，DevOps給我們指明了一條可行之路。

制造業的變革

為了更好的理解DevOps的變革，讓我們把目光投射到上世紀八十年代制造業的變革上。通過踐行精益原則，制造業組織成功地極其顯著地提升了生產效率，降低了交付時間，提高了產品質量以及客戶滿意度，成功的企業在殘酷的市場中贏得了一席之地。
在這場改革開始之前，制造行業平均交付時間為6周，而且只有少於70%的訂單能夠按時交付。而到2005年，隨著精益實踐的廣泛推行，平均交付時間已經少於三周，而且95%的訂單能夠按時交付。那些沒能跟上的組織失去了市場份額，他們之中的很多最終被淘汰出局。

軟件行業的變革

軟件行業是如此的相似，在上世紀七八十年代，大多數項目需要一到五年才能實現完成開發和部署，經常伴隨著極其高昂的成本，而失敗也是會帶來極其嚴重的影響和後果。
隨著Agile的踐行，新功能的開發已經降到周或者月為單位了，但是部署到生產仍然需要數周甚至數月，而且經常還會伴隨災難性的後果。
接下來隨著軟件和硬件的不斷升級，帶來了永不停息的服務的普遍實施的可能性，而Cloud更是將其全面推展開來。
DevOps的引入更是使得這些需要部署到生產的服務變成了以小時甚至以分鐘計的尋常操作，很多企業在這輪變革中已經先行，部署對他們來說已經是日常和低風險的的作業。借助於DevOps，這些企業甚至能夠在實際的環境下現行驗證他們的Idea，以確認哪些Idea能夠帶來最大程度的效益，以此來決定所要開發的功能，而這些功能最終將非常安全地被部署到生產環境之中。

現代企業的挑戰

時至今日，DevOps原則的踐行已經在一日部署上百甚至上千變更。舉個極端的例子Amazon在2011年每天大約能夠完成7000部署，而到了2015年這個數字上升到了13萬次每天。
跟上個世紀八十年的的制造業變革何其相似，這個時代的軟件行業已經在變革。快速的市場對應以及不懈的探索和努力已經成為必備的要素。無法實現的企業註定要付出失去市場的代價。就像2016年DORA的DevOps調研報告的研討會中提到的那樣，你可以不相信那些看起來好像不太符合常規邏輯的速度，但是這些確確實實的發生在我們的身邊。

軟件的紀元

這個時代，不管在哪個領域中進行的商業競爭，對價值的交付最終都將依賴於科技價值流的實現。說得再簡單一些，就像通用電器的CEO Jeffrey Immelt曾經說過的那樣，“任何一個領域和公司，如果他們還未曾將軟件引入到他們的核心業務，他們註定會被顛覆”。這不是危言聳聽，技術對於任何組織都是用於贏得競爭一席之地或者生存下去的極為重要的工具。

問題的剖析

了解了所有的這一切，讓我們來看一下這些問題的征兆，以及為什麽會發生這些問題，為什麽沒有強有力的幹預，這些問題會隨著時間變得愈發嚴重

征兆：所在組織需要改善

大多數企業需要數周甚至數月的準備來部署他們的產品，他們也不能定例地低風險地交付部署新的功能特性，甚至他們中的很多都認為，這麽快的部署需求本身就是一件很嘩眾取寵的事情。但是和當初制造業的變革一樣，這場革命實際上已經無聲無息地展開了，在這個時代快速和高水準的服務已經是必要條件，已經有很多優秀的企業先行一步，掀起了變革的浪潮。沒有危機意識的企業在上個世紀八十年代應該也有很多，沒有奮起直追的大多數在那場變革中已經消失在滾滾洪流之中。部署只是海面上的冰山，從工具到流程，從組織結構到文化，有太多的環節需要註意，而改善也已經刻不容緩。

核心的固有沖突

幾乎在每一個IT組織中，開發和運維之間都會產生一個“下行的惡性循環”，使得產品或功能交付的時間增加，質量下降，更為糟糕的是那與日俱增的技術債務。技術債務是Ward Cunningham最初提出來的一個術語，像財務債務一樣，技術債務描述了我們所做的決策可能會引起的逐漸累積的問題，隨著這些債務的不斷增加，解決這些問題也會花費越來越多的成本和時間。
開發和運維的沖突源於隔閡，他們之間像是有著一堵無形的墻，正是這道看不見的隔閡產生了諸多的問題。產生隔閡的原因在於分工和目標的不同。組織目標細化的過程中產生了在實際推行的時候相互制約的要素。具體來說，企業需要實現快速，需要提供穩定服務。

開發團隊為快速將產品推向市場作出努力，當然穩定和安全等也是必要的，在現實的世界中，這些更多是作為非功能性要素不會出現在大多數的開發人員的視線範圍，而且在大部分情況下這些也不是交付的要素。運維則需要負責穩定這個要素，兩個團隊，兩個目標，兩套KPI，相互沖突，無論是在這個地球的哪個國家，類似的隔閡和問題都一直在出現。
制造業變革運動的奠基者之一的Goldratt將這種情況稱之為核心的固有沖突（the core, chronic conflict）, 正是這種沖突帶來了螺旋下行的惡性循環。

下行的惡性循環

這種螺旋下行的惡性循環產生在現實世界中往往有下面三個簡單要素。

運維的技術債

運維的目標是保持應用程序和基礎框架持續運行以使得組織能夠交付服務給到最終顧客。但是由於應用程序和基礎框架及其復雜，缺少文檔，以及難以置信的脆弱，這使得運維人員每天都必須面對和處理的事情。當我們救火的時候總是想再抽空順便就把這些個問題修復，但是一直沒有抽到空，而這樣的技術債務則在不斷地增長。
而且，當這些日漸脆弱的系統所支持的是創造利潤的關鍵業務時，問題會變得更加復雜，本來能夠對應的問題也會因為擔心和憂慮以及沒有非功能性機能的保障而信息不足。問題越積越多，一個小小的改動，最終都可能引起多米諾骨牌效應。所以每次只能最少限的修改，只能頭痛醫頭，腳痛醫腳。CSA根本問題分析對應？分析後有錢改麽？敢改麽？這樣的結果造成了大家每日都在接觸到的現實世界的一幕一幕。

難以兌現的許諾

理想的項目，缺錢給錢，缺人給人，項目範圍穩定，變更管理有序，在Q（Quality）C（Cost）T(Time)三角進行管理的經驗豐富的PM也遊刃有余。
而現實的世界是，很多項目是要錢沒有，資源有限，根本無變更管理。即使是這樣的項目也在搶著做的情況下，基於各種場景，很多難以兌現的許諾就這樣被添加了。比如項目管理上稱之為鍍金的行為，實際的項目中往往是給強勢的外部以真金白銀的無底線自殘。
然而最終這些許諾會壓到開發團隊那裏，給原本就不太寬裕的項目進度狠狠地來上一刀。這些任務的往往兼具難度大/工期緊/經費少/人手不足等諸多明顯標誌，完成任務已經是精疲力竭，至於技術債務，自然會進一步的積累不斷升高。

最後一根稻草

螺旋下行的惡性循環還差最後一根稻草。只需要在來一點，每件事情都復雜一點點，每個人都再忙一點點。一點一點，每個人都變得越來越忙，工作時間越來越長，交流時間越來越短，任務列表越堆越高。每個人的工作都和別人的工作緊密相關，一個小的動作都可能帶來很大的失敗，自然而然，對變更充滿畏懼和排斥。工作需要更多的溝通/協調/批準，各個團隊必須等待更長一點時間以確保所依賴的部分已經完成。扯皮和吵架變成為了自保的必備生存技能。
這種情況下，部署的時間越來越長，更要命的是，開始變得容易出問題了，而對這些問題的救火行為消耗了大量的時間和成本，使得原本可以著手對付那高壘的技術債務的最後一絲機會也喪失殆盡。到了這個時候，就是英雄輩出的時代，對待那基本上已經困難重重的系統，非常規的能力出眾的個人或者小的團體的非常規的努力，保證系統能夠運行的同時繼續推高系統的技術債務，為下一次爆發提供了良好的條件。

為何如此常見

這種情況對我們來說是如此常見，知道了下行的惡性循環是如何發生的，但是為什麽會這樣普遍存在呢？
每個IT組織都有快速和穩定兩個相反的目標，最終形成了Goldratt所說的核心的固有沖突，為這種存在提供了基礎。
另外還有一點，現代社會中，不管被意識到與否，各行各業的任何一家公司都是科技公司，科技在各個行業的滲透已經超出了大多數人的想象，思維方式的轉變勢在必行。正如一位資深的軟件負責人所言：“所有的公司都是科技公司不管他們自己認為他們自己在什麽領域。一家銀行也只是有著銀行營業許可的IT公司而已。”在作咨詢的時候，我們也經常會跟客戶說, 在這個時代，”Your software is not part of your business, it is your business”，其實都是一樣的道理。是否最終的發展像Jeffrey Immelt所說的那樣可能還需要時間的檢驗可以拭目以待，但是對任何企業來說這都是一場輸不起的賭博。

成本

在下行的惡性循環中的很多人，被迫面對怪獸一般的系統，那種憂郁/孤立無援/無助甚至絕望的心情估計只能是如人飲水，冷暖自知了，由此帶給個人家庭的傷害也是無法估量的。但是這個世界花在IT上的成本確是清楚的。比如IDC和Gartner都曾發布過，2011年全球花在IT上的錢大體是GDP的5%，這個數字高達3.1萬億美元。試想一下即使一個很小的比例與這3.1萬億一起計算，在經濟上付出了多大的成本不言自明。

DevOps：更好的方式

與傳統方式不同，DevOps協調各個部門向著組織共同目標協同努力同時改善工作的環境和文化，正是因為如此，它才能在這麽短的時間內得到了眾多人群的青睞而得到了迅速的發展。

DevOps：打破下行的惡性循環

理想狀況下，小型的開發團隊也能實現自己的機能特性，在類生產環境中驗證正確性，能將他們的代碼快速安全地部署到生產環境。代碼的部署是可預期的日常行為，部署不再是必須等待到周五下班然後開始倒計時在周一開始之前必須完成的噩夢。運維人員終於可以在工作日進行例行的部署作業。而客戶對此一無所知，只有在他們發現新的可用機能或者被修改好了的bug時，才會意識到部署的動作已經完成。
在整個過程之中，每個操作都需要有快速的反饋，每個人都能快速地看到他們的動作所帶來的影響和結果。當變更的代碼提交到版本庫中之後，自動測試開始在類生產環境中運行以確認此次變更是否達到能夠部署到生產環境中的標準。
自動測試幫助發現更多的問題而不致於留下很多的技術債務，通過自動測試的確認，發現的技術債務立即解決而不是等待日後再行處理。
不同於傳統的非黑即白的部署，經過測試的代碼，可以早早的放到生產環境之中，除了內部用戶和一些被選擇的特定用戶，其他所有用戶均此時均不會意識和看到或者使用到此部分部署的機能，而且也不會被此部分功能所影響。這樣在生產環境通過內測或者小部分用戶的試行方式極大的提高了信息安全相關的保障。
即使出現問題，也可以快速回滾到上一個版本以避免無法對外提供正常服務。整個部署是可控的，可預測的，可回滾的，低風險的。
相比於畏懼出錯/重於懲罰的文化，高度信任和協作的文化更加被推崇。只有這樣，有些問題點才會被提出來而不是裝作不知道被藏起來。畢竟，我們只有先看到問題才能去解決這些問題。同時即使當問題發生的時候，啟動的也不是問題追責機制，而是無追責的事後檢討或者反省活動，不是為了懲罰某人，而是為了避免下次同樣的問題再次出現，組織級別的學習和成長使用這種方式不斷展開。這是一個理想的狀況，各種企業都在使用自己的方式去實現自己的DevOps。

DevOps：業務價值

正如DORA的DevOps調研報告中所提到的那樣，通過對多達25，000職業技術人員的調研，發現踐行了DevOps的高效能人員相比於低效者，在很多方面都展現出很大的優勢。比如:

DevOps: 規模開發線性等效

當開發人員的數目增加的時候，由於規模效應所增加的溝通/協作等額外作業不可避免的對個體開發者產生比較明顯的影響。就像人月神化中所解釋的那樣，當項目遲延時，增加開發者時，不但會降低個體開發者的效率，同樣會降低整體的效率。
而DevOps則從另外一個角度，告訴我們，當我們有合適的架構，合適的技術實踐，合適的文化氛圍 ，小的團隊也能高效地完成作業。同時，大規模的團隊也同樣適合DevOps，正像google前管理者Randy Shoup在google中所觀察到的那樣，“數千人的團隊，架構和實踐依然能使得小團隊像初創公司那樣產生不可思議的超高效率”。
下面這張DORA在2015年做的調查結果清晰地展示了當人數上升時候踐行DevOps的高效能人員所組成的團隊依然能夠保證著小團隊的線性增長效率。

總結

DevOps不是櫥窗裏面的展品，也不是舊酒裝新瓶的噱頭。應該像上個世紀八十年代精益實踐浪潮的優秀企業那樣，認真思考組織的不足，努力修煉內功，踏踏實實地改進，像Google/Amazon/Netflix那樣實踐，在新的改革中抓住機會。

Referrence

再分享一下我老師大神的人工智能教程吧。零基礎！通俗易懂！風趣幽默！還帶黃段子！希望你也加入到我們人工智能的隊伍中來！https://blog.csdn.net/jiangjunshow

DevOps企業實踐指南 1 DevOps能為我們帶來什麽