五天前，張大胖負責的開發(fā)團隊向運維部門交付了一批新代碼，這是一次用戶期待已久的重要升級，部署進行得非常順利，大家都很高興。 

可是今天生產(chǎn)環(huán)境的CPU持續(xù)接近100%，有好幾臺服務(wù)器都down機了， 運維老大勃然大怒：“已經(jīng)是第三次了！ 張大胖，你們開發(fā)團隊怎么搞的？ 新代碼一上線CPU就100%！” 

張大胖自然也不甘示弱：“我們在測試環(huán)境測試得非常充分，用戶壓力比生產(chǎn)環(huán)境大多了，代碼堅如磐石，肯定是你們配置錯了什么東西！” 

“不可能，我們是嚴格按照你們要求的步驟來部署的，肯定是你們代碼的問題！” 

“那測試環(huán)境怎么就沒有問題？”

 ...... 

兩位主管吵了好久，也沒有什么好的解決方案，大家又熬了一個通宵，把代碼回滾到上個版本，燒香拜佛，希望不要再出問題。 

經(jīng)過這一番折騰，今年年底的獎金估計是懸了！ 

張大胖覺得極為郁悶， 心緒難平，黑著臉來到茶水間倒了一杯咖啡，坐在那里一邊喝一遍感慨這運維部門簡直是太難合作了！ 

看看他們新招的這些人，完全不懂業(yè)務(wù)，他們?yōu)榱艘疤颖茇熑巍?，?jīng)常說：“我不懂業(yè)務(wù)，這次上線的內(nèi)容，你要把每一步都寫得清清楚楚，我只管執(zhí)行，不問為什么，出了問題可不是我的責任。”你說氣人不氣人！ 難道他就想當個機器人嗎？ 

還有，他們運維團隊每個人側(cè)重不同，有人負責數(shù)據(jù)庫腳本執(zhí)行，有人負責Web服務(wù)器，有人負責SSO ， 我的天，每次上線前都得把一堆人拉過來開好幾次會，讓他們熟悉操作步驟。這個人部署了一次，好不容易熟悉了，下一次又換了一個人，還美其名曰這是人力資源池，能提高效率，但是新人又需要從頭兒學習，這怎么可能不出錯？！ 唉......

喝了兩杯咖啡以后，張大胖稍微平靜了一下，仔細想想，本質(zhì)原因還是軟件本身太復(fù)雜了，不但開發(fā)復(fù)雜，部署也超級復(fù)雜，每次部署就把人扒掉一層皮。 

張大胖不由地想起來這些年來自己經(jīng)歷過的軟件開發(fā)和部署流程。 

大學時候，跟著老師做一些小項目，開發(fā)、測試都是一個人搞定，部署到用戶那里也是自己做，幾乎沒出過岔子。 

畢業(yè)后進入一個小公司，做的是C/S架構(gòu)的系統(tǒng)，有了開發(fā)團隊、測試團隊之分，開發(fā)團隊把代碼寫完，交給測試團隊測試，通過以后就可以到客戶那里部署了。 

通常來說實施人員也都是開發(fā)或者測試的兄弟們兼任，自己也兼職干過，拿著部署文檔和光盤，到客戶那里嚴格按照步驟把系統(tǒng)安裝到客戶的機器上，基本上沒啥大問題，即使有了問題，現(xiàn)場調(diào)試一下也都能解決，大不了把開發(fā)的兄弟們叫過來一起熬夜。

再后來互聯(lián)網(wǎng)浪潮來臨，自己也跳槽到這家互聯(lián)網(wǎng)公司，專門做一個網(wǎng)上約車的系統(tǒng)，給用戶提供約車服務(wù)，根本不用到客戶那里去安裝軟件，公司獨立地運行、維護好這個系統(tǒng)就萬事大吉。 

但是這個網(wǎng)上約車的系統(tǒng)可比原來的單機軟件、C/S軟件要復(fù)雜得多，尤其是要面對海量用戶的高并發(fā)訪問，需要解決各種各樣的技術(shù)難題，挑戰(zhàn)巨大。系統(tǒng)不但復(fù)雜，還需要以24*7的方式運行， 靠開發(fā)或測試的兼職人員已經(jīng)無法維護了。

公司專門設(shè)立了運維（Operations）部門，負責系統(tǒng)的部署、日常維護、監(jiān)控。運維人員的地位空前提高，當然，對他們的技能的要求也空前提高。 

張大胖看過一個招聘的運維的郵件: 

熟練使用Linux, unix, windows操作系統(tǒng)； 

精通各種常用服務(wù)器軟件（tomcat, apache, nginx,redis,mysql...)的配置及優(yōu)化 

了解負載均衡和高可用的原理，如LVS,Keepalived等 

熟悉網(wǎng)絡(luò)原理，TCP/IP協(xié)議，掌握至少一種腳本語言。 

會使用各種配置管理和部署管理的工具。 

...... 

總之，運維的重要性已經(jīng)和開發(fā)差不多了。 

為了加快交付速度，前兩年，自己帶領(lǐng)著開發(fā)團隊實施了敏捷轉(zhuǎn)型，成功地把原來的瀑布開發(fā)方式轉(zhuǎn)換成了小步快跑，經(jīng)常交付的敏捷模式。  

（圖片來源：http://www./scrum） 

通過敏捷軟件開發(fā)，把需求人員，開發(fā)人員，測試人員拉到了一起，形成所謂“特性團隊”，把需求拆分成一個個獨立的，對用戶有價值的故事，按優(yōu)先級排序以后再開發(fā)、測試，甚至可以達到每兩周就能交付幾個獨立需求的程度。

 （碼農(nóng)翻身注，參見《白話敏捷軟件開發(fā)》） 

成功的敏捷轉(zhuǎn)型獲得了公司的極大認可，還對外輸出了不少培訓(xùn)。 

雖然能頻繁地交付，但是卻不能頻繁地上線，原因很簡單：搞運維的家伙們總是希望系統(tǒng)穩(wěn)定、穩(wěn)定、再穩(wěn)定， 穩(wěn)定壓倒一切。所以他們從骨子里不想頻繁地上線，那不是給自己找麻煩嗎？ 

這恰恰和自己的敏捷軟件開發(fā)相反，敏捷就是要擁抱變化啊 ！

 (開發(fā)要求變化，運維要求穩(wěn)定，圖片創(chuàng)意來自 http://，老劉做了重畫) 

想通了這個本質(zhì)矛盾，張大胖就明白自己是搞不定這個問題了，必須上層出面解決。 

張大胖立刻去找CTO Bill，希望他能出點好主意。 

讓張大胖沒想到的是， 運維主管老李已經(jīng)在Bill辦公室里了，張大胖心說不好，這小子也許惡人先告狀了。 

Bill 一看到愁眉哭臉的張大胖，讓他先坐下，聽老李把開發(fā)和運維之間的“矛盾”和“戰(zhàn)爭”講完。 

老李嘮嘮叨叨，說的問題和自己思考的也差不多。 

Bill笑著說：“大胖，軟件的開發(fā)流程基本上就是需求->開發(fā)->測試->部署， 現(xiàn)在你的團隊已經(jīng)把需求、開發(fā)、測試給‘團結(jié)’到一起了， 看來你又要‘團結(jié)’一個新的小伙伴了！” 

“難道是老李的運維部門？” 

“沒錯?！?nbsp;

“那是不可能的， 我們的目標都完全不同，一個要變化，一個要穩(wěn)定，怎么可能在一起玩？” 大胖非常詫異。

“不，以后我們要強調(diào)業(yè)務(wù)目標，以用戶的價值為唯一的評判標準，團隊的考核評價機制也要改變，個體和團隊的成功都要放在整個開發(fā)-運維生命周期內(nèi)來進行評價，開發(fā)完成了很多用戶需求不一定是成功，運維保障系統(tǒng)不down機也不一定是成功！只有用戶想要的功能被及時實現(xiàn)了，被成功部署了，被穩(wěn)定使用了才算成功。 ” CTO總是很擅長用MBA的詞匯來講話。 

“就是說要求我們運維和開發(fā)緊密合作嘍？” 老李接著問道。 

“是啊，現(xiàn)在有個熱詞叫做DevOps，就是把敏捷開發(fā)部門和運維部門之間的圍墻打通，形成閉環(huán)?！?/span>

 “難道我們要再增加一個部門，叫DevOps部門？ 招聘DevOps工程師？” 

“不不，如果再增加一個這樣的部門，豈不是又增加了一堵墻？ 我們本來是要打破開發(fā)和運維團隊之間的隔閡啊。其實運維部門的工作目標不僅僅是讓我們的網(wǎng)上約車系統(tǒng)更加穩(wěn)定和高效，更需要支持業(yè)務(wù)的快速演化——這一點是和你們敏捷軟件開發(fā)的目標是一致的啊?！?/span>

 '但我們也不能頻繁部署??？快速和穩(wěn)定的矛盾還是解決不了。'老李嘆了口氣。

 '我知道張大胖的團隊正在實施微服務(wù)的改造，將來再部署的話就不是以一個巨無霸應(yīng)用為單位了，而是以一個個微服務(wù)為單位，那樣就簡單得多，頻繁部署是有可能的，并且出了錯回滾也便捷得多，肯地不用你們熬夜了！' 

張大胖和老李都點頭認同。 

 “那具體該怎么做？” 

 “首先是觀念的改變，以后你們不能互相推卸責任，互相指責，而要共同擔責了！一個項目的開發(fā)、部署、維護，是你們雙方的事情，雙方都要對業(yè)務(wù)負責，出了什么問題，你們要通力合作，共同解決。這一點你們回去后要給組員多`洗洗腦`?！?/span>

 張大胖心想，我們剛剛通力合作回滾了代碼。

 “還有，”，Bill看了一眼老李， “運維人員也要了解業(yè)務(wù)，Code變化帶來的影響要告知運維人員。你們開發(fā)人員工作的開發(fā)/測試環(huán)境要盡可能地和生產(chǎn)環(huán)境一致?！?nbsp;

“運維部門所要求的詳細安裝步驟實在是太煩人了！” 張大胖抱怨。

Bill說道：“我們先設(shè)定一個短期目標，把部署工作完全自動化起來。部署的腳本由老李的運維部門主導(dǎo)，有問題大胖來輔助， 將來這個部署腳本要在所有的環(huán)境都用起來！”

 張大胖和老李再次點頭。 

Bill又說道：“最后一點就是度量，例如失敗部署的百分比，用戶開的ticket數(shù)目，故障恢復(fù)的平均時間等等，這些老李應(yīng)該比我清楚。我們會用這些度量指標去衡量DevOps做得到底怎么樣， 最重要的是我們無論用了什么工具、方法，如果最后沒有減少需求從提出到上線，交付給用戶使用的時間，那都是失敗。我要求你們兩個想盡一切辦法，去減少這個時間，不是一次、兩次，而是持續(xù)、穩(wěn)定地交付給用戶?！?/span>

張大胖說：“這DevOps聽起來不錯，但實施起來估計難度不小?。　?/span>

Bill說道：“我們先選定一個產(chǎn)品作為試點，然后再擴大推廣吧！”

（完）