更多深度文章，請關注雲計算頻道：https://yq.aliyun.com/cloud
雲棲TechDay31期，來自Docker公司的Devops理念的領軍人物和佈道者John Willis帶來DevOps的三種方式的主要演講。本文主要從為什麼要用DevOps開始談起，接著分享DevOps的三種方式，著重分析第一種方式，包括Immutable Service Delivery的Devops (Faster)、Docker (Effective) 、Supply Chain (Reliable)，最後淺談了第二種方式。
以下是精彩內容整理：
圖為美國的一家金融機構所犯的錯誤，這個金融機構是美國第二大金融結構，他們經常在做一些高頻交易、算法交易，所以需要進行非常大額的股票等等方面的金融交易，而在有一次的交易當中，由於他們的操作員手動更新了其中的一個交易系統，隨後45分鐘之內他們就損失幾十億、數千億，在24小時之後導致了這家美國最大的金融交易公司倒閉，如果犯錯就可能會導致嚴重錯誤，所以在我們使用Docker的時候，我們要非常認真的去對待自己的每一步。
在這裡可以看到美國這家期貨公司整個的報告，對於他們這次犯錯進行了一個詳細的分析，可以看到他們具體如何操作導致了嚴重的後果，所以我們要非常嚴肅對待交易系統。
為什麼要用DevOps？
DevOps具體是講文化、自動化、衡量還有分享，其實它是一個環路，看公司的文化到底是怎樣的，是否具有分享的意識，是否容易接受失敗、擁抱失敗，是否有合作的氛圍。另外大家在公司裡工作的方式又是怎樣的，是否是有計劃的，是否會對這些結果進行不斷的核實和修正，在這裡我們就用這樣的一個圖片來闡述理念，也就是說公司裡面怎樣能夠從一個初試的構想來到最終使得我們的客戶為我們的服務來支付費用，以及在此過程當中會產生怎樣的障礙，我們如何來突破障礙，如何能夠讓我們的產品更快的上市，更快的為客戶提供服務。
DevOps的三種方式
在這本書裡面我們主要包括三種方式，一種方式是如何來實現從左到右的過程，也就是說如何講一些想法，一些構思最快的最終實現交付給客戶；第二種方式，要把反饋的流程能夠最大化，如果我們能夠快速的得到反饋的話，我們就能夠更好的改進，更加速的得到我們的結果，有一些公司他們如何去接受失敗，是否對失敗持有開放的態度，同時我們知道有一些大的公司甚至有意製造一些失敗，從中快速的學習；第三種方式，一種文化，持續的去試驗和不斷的學習這種文學，在這本書當中我們有很多的例子都是來自於日本的，非常多的公司在工作當中進行了多次的改進，這是不斷的學習過程。
The first way
從左到右如何儘快的實現這種持續交付的模式，其實在持續交付方面有很多書都已經寫到過，我們列出了以下幾點：
Build quality in as early as possible（儘可能在早期時候考慮整個系統的質量問題）
Find bugs as early as possible（儘早找到bugs）
Everything gets tested（所有代碼都需要進行測試）
If it hurts, bring the pain forward（儘早的進行測試，以防止之後產生一些失敗而造成更大的影響）
Create fast feedback（更快的反饋模式）
Version control tests（進行版本控制等等各方面的測試）
Continuous testing ensures continuous improvement（持續測試確保持續改進）
關於持續交付方面的八個原則，具體如下：
1.Create a repeatable, reliable process for releasing software
2.Automate almost everything
3.Keep everything in version control
4.If it hurts, do it more frequently, and bring the pain forward
5.Build quality in
6.Done means released
7.Everybody is responsible for the delivery process
8.Continuous improvement
其實在DevOps Handbook書裡面我們講到了很多持續交付方面的內容，比如一定要把質量放在我們工作當中首要的位置，在持續交付方面其實這是一種思維模式的轉變，它能夠簡單的從項目的角度，從產品的角度去轉變思維，變成持續不斷服務，而這個服務是永遠不會停止的，除非服務已經不再提供，或者說公司已經倒閉了，在過去開發人員可能會覺得產品開發完就是完成工作，但是現在我們認為你的產品開發完交付到客戶手中，客戶不斷的去使用才是一種完成，或者說你不斷的去提供服務，它是一種一直持續的狀態。
第一種方式有個概念，我稱之為可免疫的交付，可以避免其他過程對於這個產品所產生的影響，開發人員可以在電腦上面開發產品，在生產交付之後會一直保持原來的狀態，不會被改變的，所以這就是給我們交付軟件時帶來的一大優勢，開發人員非常清楚所開發的程序、產品的狀態，因為它是可免疫的，當你去開發、測試甚至到後面的生產過程中，你仍然對產品所開發的部分內容是非常清楚的。
如果我們使用可免疫的服務交付模式，就能夠做到三點，也就是Devops (Faster)、Docker (Effective) 、Supply Chain (Reliable)，谷歌公司在打造供應鏈方面做了非常出色的工作，如果大家把這三點都做對的話，就會得到一個非常好的結果。
Faster
其實在過去的6年裡面，我們一起做了一個研究，採用心理學的機制來進行的一份調查問卷的研究，在這個研究當中我們想要找到幾方面的信息，一是在你們工作的環境當中是否願意分享，你們是否能夠擁抱接受失敗的，你們之間是否有合作；另外，還有其他問題是針對軟件開發者的，看一看你們開發產品情況是如何部署的，在產品發生變化的時候，做修改的時候成功率又是多少等等一系列的調研。我們發現在那些公司文化屬於分享、合作、願意擁抱失敗的環境之下，這部分的人他們在解決問題方面要比那些其他的人快24倍，而他們在軟件交付方面要快2500多倍，他們的動作更加快，而且更具有順應力。
在這種三角狀態之下，你是非此即彼的，你只能獲得其中一個，要麼更快，要麼更好，或者有一些情況之下，開發者想要更快的去開發產品，而我們的員工希望不要那麼快的進行改變，進行更好的工作，但是有一些統計數據和案例證明了其實我們並不是這種非此即彼的關係，這幾點都是可以同時達到的，建立起自動化跟隨它操作的模式，統計證明，這種效果不僅僅能夠做得更快，而且有更高的順應力，能夠更好的適應變化。
如果回到六年之前，當時也是DevOps剛剛開始的時候，我在那個時候去說服那些美國公司為什麼DevOps是如此的重要，其中只有3%的IT人士是瞭解DevOps的好處的，97%的其他IT人士是不瞭解其中奧妙的，而現在美國，使用DevOps的程度已經達到了百分之四五十，而中國其實或許只有3%，因為很多的競爭對手並不瞭解其中的原理，我們的調研結果和書都能夠告訴各位為什麼DevOps能夠更好。
大家可以看到，圖中是DevOps自動化部署的產品線，可以看到整個流程是這樣子的，開發人員一個交付團隊怎樣來進行工作，這裡有流程進行軟件開發，而我們知道第二步版本控制應該是強制性的做了一些工作，之後還要進行一些接受度測試等等，最後才能進行產品的發佈，整個過程當中還會有很多的反饋進來，會有一些錯誤發生，比如說代碼不對或者採用的標準不對，或者有一些安全掃描來查找漏洞再退回。但是當我們能夠更早的得到反饋，就能夠把那些原來會在後端出現的問題在前端先找出來，能夠解決這個問題付出的代價就更小了，也就是持續交付概念，它能夠幫助各位做得更快並且有更強的適應力。
比如谷歌每一天就要做一億次的測試來尋找各種問題，他們還使用單一的資源數等等各種方法，亞馬遜也是進行快速部署的一家公司，其實很多美國公司在這方面都是採用了DevOps，使得交付軟件速度非常快。
很多百年公司在五年前採用了DevOps模式進行操作，這些公司有一些是大型的零售商，有一些是保險公司，有一些是製造企業，比如：
Ticketmaster - 98% reduction in MTTR
Nordstrom - 20% shorter Lead Time
Target - Full Stack Deploy 3 months to minutes
USAA - Release from 28 days to 7 days
ING - 500 applications teams doing devops
CSG - From 200 incidents per release to 18
這裡面各種故事都是在告訴我們，由於這些公司採用了DevOos的原則，使用了Docker工具來幫助他們更好更快，並且更具有順應力。
effective
Docker在DevOps模式之下，能夠解決其中很多問題，Docker是一個非常好的工具，它能夠開發可免疫的產品交付，可以對服務進行測試，再用容器的方式進行運行，我們可以保證在生產過程當中開發的內容不會被破壞，還可以把他們做成集群，Docker還有一個數據中心，這方面也是跟阿里巴巴做了非常緊密的合作。
為什麼要選擇Docker？
DOCKER有幾種特性：Isolation、Lightweight、Simplicity、Workflow和Community。Docker的特別之處在於建立了一個工作流程，我們可以部署它管理、存儲，甚至進行各樣各樣的處理。有幾家大的公司，在這方面工作做得非常好，比如：
Riot Games：1.25 Million Builds a Year，10,000 - 14,000 Containers A Week，120 Build Jobs An Hour，30% of all Environments are Containerized；
Uber：4,000 upgrades per week，3,000 builds per week，300 rollbacks per week，Managed more than 600 services in the system。
可以看到每週更新的情況，他們使用Docker之後所帶來的一些效果。
Reliable
圖中可以看出TOYOTA是如何來勝出它的競爭對手通用的，可以看到它在兩個車型對比方面，TOYOTA的供應商方面比通用高16%，而他們增加了50%自己生產的部分，那麼，TOYOTA如何對它的供應鏈進行更加精益的管理，如何使用DevOps來提升他們的管理效率？
其實並不是針對某一個產品，而是針對理念方式。谷歌在使用DevOps方面是非常遵守原則的，而且他們也是非常的謹慎，將他們的各種供應商進行嚴格控制，另外TOYOTA在它的系統裡面，比如說物料，很多信息都是放在Docker容器裡面的，所以當我們有幾百萬的清單，就可以從Docker可免疫的容器當中非常容易的找到，假如汽車公司有一些產品問題需要去召回，使用Docker會非常容易的找到幾百萬臺售出去的汽車在什麼地方，從而進行更好的處理。
我們也探討了三種交付模式：Divergence、Convergence和Congruence。
第一種交付模式，在這種模式之下設立起系統打造APP，然後隨著時間的遷移，這些原來的內容就變得不一致了，它是一種非常混亂的狀態來管理的；
第二種交付模式，它會對系統進行更新，採用一些自動化方式的模式對系統進行更新，我們知道；
第三種模式之下，也是最好的一種模式，當你去開發的時候，設計就把它固定成一種模式，除非有意識的去更新才會發生變化，這種模式解決闡述了Docker現在的模式，這種免疫性的開發模式。
Aetna是一家非常大型的保險公司，這家保險公司採用了我們的系統之後，在過去幾年裡面對他們的調查顯示，他們在一萬行的代碼當中缺陷率從原來的10K裡面有10個，一直降到了0.1，他們也是採取了非常好的谷歌模式，還有一些公司甚至降到了0，一萬行代碼裡面沒有一個錯誤的，所以這裡其實是非常具有激情的，我們的模式是非常奏效的，成千上萬的人並不瞭解我們，所以使用這種模式能夠讓你們變得更加有競爭力。
我們在可免疫服務交付的模式之下，如果你使用DevOps就能夠讓你變得更快，使用Docker就能夠讓你更加的有效，而在供應鏈裡面能夠使你更加的可靠。
The Second Way
The Second Way – Goals：Right to Left、Find and Fix Fast和Shorten and Amplify Feedback。
在整個過程當中產生更多更快的反饋來促進工作的進行，我們的設計是為了解決失敗，解決故障而產生的，在一些案例裡面，它會有一些講述公司如何故意去關閉一些數據中心等等採用各種方式製造混亂的。而開發人員會知道這種情況的發生，在你的規模擴大了之後很有可能200毫秒salt就是一場災難，所以他們做了很多的測試，整個測試過程當中，產生了最終的一個體系，讓你們瞭解問題到底是出在什麼地方的。
The Second Way - Right to Left：
Creating a Service Reliability Culture
Fast Feedback
Understanding Monitoring
Understanding Complexity