以下是精彩内容整理：
在這裡可以看到美國這家期貨公司整個的報告，對于他們這次犯錯進行了一個詳細的分析，可以看到他們具體如何操作導緻了嚴重的後果，是以我們要非常嚴肅對待交易系統。
為什麼要用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（持續測試確定持續改進）
關于持續傳遞方面的八個原則，具體如下：
- Create a repeatable, reliable process for releasing software
- Automate almost everything
- Keep everything in version control
- If it hurts, do it more frequently, and bring the pain forward
- Build quality in
- Done means released
- Everybody is responsible for the delivery process
-
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
本文為雲栖社群原創内容，未經允許不得轉載，如需轉載請發送郵件至[email protected]；如果您發現本社群中有涉嫌抄襲的内容，歡迎發送郵件至：[email protected] 進行舉報，并提供相關證據，一經查實，本社群将立刻删除涉嫌侵權内容。