知識星球來自：碼農翻身（微訊號：coderising）
五天前，張大胖負責的開發團隊向運維部門交付了一批新程式碼，這是一次使用者期待已久的重要升級，部署進行得非常順利，大家都很高興。
可是今天生產環境的CPU持續接近100%，有好幾臺伺服器都down機了， 運維老大勃然大怒：“已經是第三次了！ 張大胖，你們開發團隊怎麼搞的？ 新程式碼一上線CPU就100%！”
張大胖自然也不甘示弱：“我們在測試環境測試得非常充分，使用者壓力比生產環境大多了，程式碼堅如磐石，肯定是你們配置錯了什麼東西！”
“不可能，我們是嚴格按照你們要求的步驟來部署的，肯定是你們程式碼的問題！”
“那測試環境怎麼就沒有問題？”
……
兩位主管吵了好久，也沒有什麼好的解決方案，大家又熬了一個通宵，把程式碼回滾到上個版本，燒香拜佛，希望不要再出問題。
經過這一番折騰，今年年底的獎金估計是懸了！
張大胖覺得極為鬱悶， 心緒難平，黑著臉來到茶水間倒了一杯咖啡，坐在那裡一邊喝一遍感慨這運維部門簡直是太難合作了！
看看他們新招的這些人，完全不懂業務，他們為了要“逃避責任”，經常說：“我不懂業務，這次上線的內容，你要把每一步都寫得清清楚楚，我只管執行，不問為什麼，出了問題可不是我的責任。”你說氣人不氣人！ 難道他就想當個機器人嗎？
還有，他們運維團隊每個人側重不同，有人負責資料庫指令碼執行，有人負責Web伺服器，有人負責SSO ， 我的天，每次上線前都得把一堆人拉過來開好幾次會，讓他們熟悉操作步驟。這個人部署了一次，好不容易熟悉了，下一次又換了一個人，還美其名曰這是人力資源池，能提高效率，但是新人又需要從頭兒學習，這怎麼可能不出錯？！ 唉……
喝了兩杯咖啡以後，張大胖稍微平靜了一下，仔細想想，本質原因還是軟體本身太複雜了，不但開發複雜，部署也超級複雜，每次部署就把人扒掉一層皮。
張大胖不由地想起來這些年來自己經歷過的軟體開發和部署流程。
大學時候，跟著老師做一些小專案，開發、測試都是一個人搞定，部署到使用者那裡也是自己做，幾乎沒出過岔子。
畢業後進入一個小公司，做的是C/S架構的系統，有了開發團隊、測試團隊之分，開發團隊把程式碼寫完，交給測試團隊測試，透過以後就可以到客戶那裡部署了。
通常來說實施人員也都是開發或者測試的兄弟們兼任，自己也兼職乾過，拿著部署檔案和光碟，到客戶那裡嚴格按照步驟把系統安裝到客戶的機器上，基本上沒啥大問題，即使有了問題，現場除錯一下也都能解決，大不了把開發的兄弟們叫過來一起熬夜。
再後來網際網路浪潮來臨，自己也跳槽到這家網際網路公司，專門做一個網上約車的系統，給使用者提供約車服務，根本不用到客戶那裡去安裝軟體，公司獨立地執行、維護好這個系統就萬事大吉。
但是這個網上約車的系統可比原來的單機軟體、C/S軟體要複雜得多，尤其是要面對海量使用者的高併發訪問，需要解決各種各樣的技術難題，挑戰巨大。系統不但複雜，還需要以24*7的方式執行， 靠開發或測試的兼職人員已經無法維護了。
公司專門設立了運維（Operations）部門，負責系統的部署、日常維護、監控。運維人員的地位空前提高，當然，對他們的技能的要求也空前提高。
張大胖看過一個招聘的運維的郵件:
熟練使用Linux, unix, windows作業系統；
精通各種常用伺服器軟體（tomcat, apache, nginx,redis,mysql…)的配置及最佳化
瞭解負載均衡和高可用的原理，如LVS,Keepalived等
熟悉網路原理，TCP/IP協議，掌握至少一種指令碼語言。
會使用各種配置管理和部署管理的工具。
……
總之，運維的重要性已經和開發差不多了。
為了加快交付速度，前兩年，自己帶領著開發團隊實施了敏捷轉型，成功地把原來的瀑布開發方式轉換成了小步快跑，經常交付的敏捷樣式。 
（圖片來源：http://www.agilenutshell.com/scrum）
透過敏捷軟體開發，把需求人員，開發人員，測試人員拉到了一起，形成所謂“特性團隊”，把需求拆分成一個個獨立的，對使用者有價值的故事，按優先順序排序以後再開發、測試，甚至可以達到每兩周就能交付幾個獨立需求的程度。
（碼農翻身註，參見《白話敏捷軟體開發》）
成功的敏捷轉型獲得了公司的極大認可，還對外輸出了不少培訓。
雖然能頻繁地交付，但是卻不能頻繁地上線，原因很簡單：搞運維的傢伙們總是希望系統穩定、穩定、再穩定， 穩定壓倒一切。所以他們從骨子裡不想頻繁地上線，那不是給自己找麻煩嗎？
這恰恰和自己的敏捷軟體開發相反，敏捷就是要擁抱變化啊 ！
(開發要求變化，運維要求穩定，圖片創意來自 http://dev2ops.org，老劉做了重畫)
想通了這個本質矛盾，張大胖就明白自己是搞不定這個問題了，必須上層出面解決。
張大胖立刻去找CTO Bill，希望他能出點好主意。
讓張大胖沒想到的是， 運維主管老李已經在Bill辦公室裡了，張大胖心說不好，這小子也許惡人先告狀了。
Bill 一看到愁眉哭臉的張大胖，讓他先坐下，聽老李把開發和運維之間的“矛盾”和“戰爭”講完。
老李嘮嘮叨叨，說的問題和自己思考的也差不多。
Bill笑著說：“大胖，軟體的開發流程基本上就是需求->開發->測試->部署， 現在你的團隊已經把需求、開發、測試給‘團結’到一起了， 看來你又要‘團結’一個新的小夥伴了！”
“難道是老李的運維部門？”
“沒錯。”
“那是不可能的， 我們的標的都完全不同，一個要變化，一個要穩定，怎麼可能在一起玩？” 大胖非常詫異。
“不，以後我們要強調業務標的，以使用者的價值為唯一的評判標準，團隊的考核評價機制也要改變，個體和團隊的成功都要放在整個開發-運維生命週期內來進行評價，開發完成了很多使用者需求不一定是成功，運維保障系統不down機也不一定是成功！只有使用者想要的功能被及時實現了，被成功部署了，被穩定使用了才算成功。 ” CTO總是很擅長用MBA的詞彙來講話。
“就是說要求我們運維和開發緊密合作嘍？” 老李接著問道。
“是啊，現在有個熱詞叫做DevOps，就是把敏捷開發部門和運維部門之間的圍牆打通，形成閉環。”
“難道我們要再增加一個部門，叫DevOps部門？ 招聘DevOps工程師？”
“不不，如果再增加一個這樣的部門，豈不是又增加了一堵牆？ 我們本來是要打破開發和運維團隊之間的隔閡啊。其實運維部門的工作標的不僅僅是讓我們的網上約車系統更加穩定和高效，更需要支援業務的快速演化——這一點是和你們敏捷軟體開發的標的是一致的啊。”
“但我們也不能頻繁部署啊？快速和穩定的矛盾還是解決不了。”老李嘆了口氣。
“我知道張大胖的團隊正在實施微服務的改造，將來再部署的話就不是以一個巨無霸應用為單位了，而是以一個個微服務為單位，那樣就簡單得多，頻繁部署是有可能的，並且出了錯回滾也便捷得多，肯地不用你們熬夜了！”
張大胖和老李都點頭認同。
“那具體該怎麼做？”
“首先是觀唸的改變，以後你們不能互相推卸責任，互相指責，而要共同擔責了！一個專案的開發、部署、維護，是你們雙方的事情，雙方都要對業務負責，出了什麼問題，你們要通力合作，共同解決。這一點你們回去後要給組員多`洗洗腦`。”
張大胖心想，我們剛剛通力合作回滾了程式碼。
“還有，”，Bill看了一眼老李， “運維人員也要瞭解業務，Code變化帶來的影響要告知運維人員。你們開發人員工作的開發/測試環境要盡可能地和生產環境一致。”
“運維部門所要求的詳細安裝步驟實在是太煩人了！” 張大胖抱怨。
Bill說道：“我們先設定一個短期標的，把部署工作完全自動化起來。部署的指令碼由老李的運維部門主導，有問題大胖來輔助， 將來這個部署指令碼要在所有的環境都用起來！”
張大胖和老李再次點頭。
Bill又說道：“最後一點就是度量，例如失敗部署的百分比，使用者開的ticket數目，故障恢復的平均時間等等，這些老李應該比我清楚。我們會用這些度量指標去衡量DevOps做得到底怎麼樣， 最重要的是我們無論用了什麼工具、方法，如果最後沒有減少需求從提出到上線，交付給使用者使用的時間，那都是失敗。我要求你們兩個想盡一切辦法，去減少這個時間，不是一次、兩次，而是持續、穩定地交付給使用者。”
張大胖說：“這DevOps聽起來不錯，但實施起來估計難度不小啊！”
Bill說道：“我們先選定一個產品作為試點，然後再擴大推廣吧！”
（完）
●本文編號269，以後想閱讀這篇文章直接輸入269即可
●輸入m獲取文章目錄
Linux學習
更多推薦《18個技術類微信公眾號》
涵蓋：程式人生、演演算法與資料結構、駭客技術與網路安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。
