DevOps是IT交付過程令人興奮和具有深遠意義的轉變。承諾很誘人： 從根本上提高生產力，更低的成本和更可靠的系統。

那么，你應該跟隨潮流，讓你的IT部門去參與開發運營融合（DevOps），對吧？大家都開始干了，所以你也別落后。***的問題不是干不干，而是怎樣干，從哪里入手？

首先，走出去，招聘一些DevOps人才。等等，DevOps可不是一個崗位哦。

好吧，你應該創建一個DevOps工作組或者部門，對嗎? 在一個DevOps主管的帶領下，你可以訓練出一個偉大的DevOps團隊——再等等！！——DevOps既不是一個部門，也不是一種職能。

好吧，如果它不是一個崗位、 一個職能或一個部門，那DevOps到底是什么？

DevOps是文化、 流程、 技術和人。DevOps戰略是將許多學科融合為一套有凝聚力的組織原則。DevOps是一種新的IT系統交付方法，承諾更快交付、更高質量、終結全球饑荒、獲得永生！好吧，也許不包括***兩個……DevOps也意味著IT組織在時間、經歷和資源各方面的龐大的投入。

DevOps也就是應用程序開發和系統運維的融合 可以改造和提升IT交付能力。DevOps概念同樣也極易被濫用，所以我認為應該立一個警示牌。警告：DevOps濫用可能導致丟飯碗、 業務中斷、和CEO郁悶地匯報。

DevOps為什么不容易

首先，讓我們弄清楚DevOps“不是什么”。DevOps不是Chef、Puppet或者Salt Stack，或者任何其它工具、腳本環境或者技術。雖然自動化是DevOps的核心理念，但它不等于自動化。

DevOps也不會是你組織里深層次技術和專業技能的替代品。去專業化，并不意味著你要解雇你所有的Linux或者Oracle專家。

對于高度集中的科技公司例如Yahoo 、Facebook或Yammer，那里的所有DevOps主管想要取得DevOps成功非常艱難。對于傳統企業，特別是大型分布式組織，在整體意義上的DevOps成功往往是不可能實現的。

為什么這么難？一個原因：文化。

DevOps要求深層次的文化和組織變革。需要改變行為習慣 ——要改變的太多太多。這意味著大家要扔掉奉行了幾十年的顯規則和潛規則。你不得不告訴老部下們，大部分他們知道的和每天做的事物都已經過時了。

IT組織結構調整很容易。我可以把開發人員和運維人員安排在同一個房間，安排他們完成工作，這也是一種顯式的調整。但是，這兩個不同的群體的人，帶著多年不一樣的培訓經歷和不同的技能，真能夠融入DevOps組織嗎？要知道，他們可能來自不同的星球！

怎樣搞定DevOps

想要為DevOps和應用靈活性而重塑你的團隊，需要領導層的勇氣和無私奉獻。當然，它也需要花費時間和金錢，并且需要在團隊成員篩選上做出艱難的決定。

為了促進DevOps戰略，調整考核和激勵機制是必要的。如果你依然只根據敲出代碼的生產力來獎勵開發人員，或者根據基礎設施的可靠性來獎勵運維人員，那么，什么都不會改變。相反，應該獎勵系統創建和運維的整體團隊，并且根據團隊工作的全部要素來確定獎勵。

圍繞業務系統而不是職責來組織工作，這就是DevOps打破IT分組壁壘的寓意。一個團隊應該有開發人員創建代碼，從用戶界面到業務邏輯和數據結構，也應該有運維人員負責操作自動化和部署。

人們需要知道他們需要對什么樣的系統負責，而并不僅僅是毫無責任地從一個系統換到另一個系統。唯一的例外是專家。

團隊待在一起，共同為他們的應用和系統負責。

不要制造一個團隊支持太多應用的局面。在這個預算縮減的年代很難考慮周全，但是經歷這種融合轉變之后，你的團隊將更加富有成效，并且不需要額外人員就能應對需求的增長。

你需要充足的專家參與項目和為團隊提供支持 ——這些人都是不同學科的大師和專家。他們為系統提供支持，但是不會長期指派給某一個系統。他們不需要對這些系統負責。

全面自動化 —— 部署、 升級、 擴展、 維護、 數據衛生、 測試、 監測、 安全和策略管理。在自動化方面投入巨資，目標是100%的自動化，不考慮低于90%的可能性。但是，全面自動化也可能會引起自動化泛濫。集中審查和調整可以控制Chef或Puppet腳本庫的無序增長。

針對整個團隊進行獎勵和表彰。成功離不開大家共同的努力，同樣，問題需要整個團隊自我反省。系統團隊應該承認專家們的貢獻 ，對表現杰出的專家給予獎勵。

圍繞建設運營融合的原則制定新的企業體系結構標準。這將確保系統符合運維的需求。

DevOps戰略必須獲取本組織自頂向下的全面支持。整個行政領導團隊 ——不只是***信息官 ——應知道它為什么重要和怎樣使它取得成功。

請記住，這是重大的文化和組織變革，多分配些時間開展培訓和組織開發活動。如果你變革得太快而忘了和您的所有團隊步調一致，你將整天陷入失誤和沖突——***滿盤皆輸。