什么是DevOps？
本文轉載自公眾號? 碼農翻身
五天前，張大胖負責的開發團隊向運維部門交付了一批新代碼，這是一次用戶期待已久的重要升級，部署進行得非常順利，大家都很高興。
可是今天生產環境的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說道：“我們先選定一個產品作為試點，然后再擴大推廣吧！”
—————END—————
喜歡本文的朋友們，歡迎長按下圖關注訂閱號程序員小灰，收看更多精彩內容
DevOps 運維
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
相關文章
