DevOps 三D原則

在上一篇文章中說到了DevOps的三弟原則。

• 一鍵式部署(Automatic Deploy)：部署過程中，標準化部署過程，實現一鍵式部署
• 一次構建打包（Automatic Delivery）：在測試環境、UAT環境和生產環境的流轉過程中，只打包一次，軟體包按順序自動交付到各個環境，最終釋出到生產環境
• 一次配置分發（Automatic Distribution)：在生產環境釋出過程，建立統一的配置分發管理，將繁瑣的分散式環境配置一次分發到各個資料中心，簡化釋出過程。

最理想的狀態當然是能夠一鍵部署，但是很多中小企業從作坊式或者英雄主義式的方式發展到現在，想要一件部署可能需要整理很多流程，規範甚至會涉及到某些英雄程式碼的重構，設計框架的調整，必然會引起內部矛盾，在這樣的情況下我們如何推進DevOps呢？以下是個人拙見，拋磚引玉了

DevOps是一種方法論

DevOps是一種方法論，任何方法論都需要靈活的運用才能產生價值，否則就是一堆理論，毫無價值。
DevOps意在調動開發、測試、運維三方人才，進行“合體”作戰，實現快速響應，如同Flickr實現每天部署10的要求，這對產品的熱補丁提供了有效的理論支援。
想要為DevOps和應用靈活性而重塑團隊，需要領導層的勇氣和無私奉獻。當然，它也需要花費時間和金錢，並且需要在團隊成員篩選上做出艱難的決定。
為了促進DevOps戰略，調整考核和激勵機制是必要的。如果依然只根據敲出程式碼的生產力來獎勵開發人員，或者根據基礎設施的可靠性來獎勵運維人員，那麼，什麼都不會改變。相反，應該獎勵系統建立和運維的整體團隊，並且根據團隊工作的全部要素來確定獎勵。

不是所有的公司都如同Facebook的伺服器一樣多

看看 Facebook在這方面目前所處的位置吧，舉幾個例子：

• Facebook有數千名開發和運維人員，成千上萬臺伺服器。平均來說一位運維人員負責500臺伺服器（還認為自動化是可選的嗎？）他們每天部署兩次（環式部署，Deployment ring的概念）。

通過上面的例子我們知道，不是所有的公司都如同facebook的伺服器一樣多，在少量的伺服器（雲伺服器）中，手動部署也是可以支援度過轉型時期的。

DevOps是服務於持續交付

DevOps就是為了快速響應部署，持續交付，如果一個傳統企業兩年或者一年才交付一次產品，那也沒有必要實施DevOps了，但是模組化開發能夠減少軟體偏離客戶目標的可能性，讓客戶參與到軟體開發過程中，持續與客戶溝通，並且交付模組化功能能夠提高企業可信度並且增加客戶粘性。持續的交付更容易讓客戶掏錢為他的需求買單，因為他能夠看到產品的進度，一切讓客戶感覺都在他的掌握之中。

“敏捷”能為你服務

敏捷開發是實現持續交付的基礎保障，不論是scrum還是xp，無論是4周還是2周的交付週期都是持續交付的理論，這些理論可以支援系統模組化的功能持續交付客戶，並且支援自迴圈的迭代優化。
那麼為什麼要敏捷呢？
我們必須明確，公司的目的或者客戶的目的是什麼，產片儘快投入使用，加快上市時間（TTM）。
上市時間（即TTM）是指一件產品從最初的構思到最終可供使用者使用或購買這一過程所需要的時間。對於產品很快會過時的行業，TTM是一個非常重要的概念。
在軟體工程方面，所採用的方法、業務，以及具體技術幾乎每年都會變化，因而TTM就成了一個非常重要的KPI（關鍵績效指標）。
TTM通常也會被叫做前置時間（Lead Time）。

協同工作

傳統的企業是這樣的。

開發和運維之前是有一堵牆，各自都有各自的目標與願景，很容易造成兩個團隊的對立。

現在我們改變這一切，在軟體開發、測試、質量保證（QA）、整合、預生產和生產部署等方面的任何舊小團隊必須打散，因為每個小團隊都可能拖延開發週期並且帶來不可預料的問題，每個團隊都可能有自己的目的。讓訊息暢通，協同合作。
實現團隊的自迴圈，從而打破混沌之牆。

人才是根本

人心惟危，道心惟微；惟精惟一，允執厥中。
說了這麼多廢話，人、才是根本。

寫在最後

自動化部署是必然趨勢，沒有自動化的部署，風險會成指數增加。

下面看一下手工部署成功的概率

- 只需手工執行5條命令的情況下，成功部署的概率就已跌至86%。
- 如需手工執行55條命令，成功部署的概率將跌至22%。
- 如需手工執行100條命令，成功部署的概率將趨近於0（僅2%）！