【正文】 稱為 ”DevOps”的風(fēng)潮從歐洲發(fā)端，迅速席卷了北美和澳洲 ──現(xiàn)在以 Flickr、 Twitter為代表的一干互聯(lián)網(wǎng)公司競(jìng)相以快速發(fā)布、頻繁發(fā)布為榮：這廂 Flickr做個(gè) PPT叫 ”每天 10次部署 ”，那邊 Twitter就在演講里有意無(wú)意地說(shuō) ”每天部署幾十次 ”。 從而 避免 將技術(shù) 或方法論 誤用于不適合的場(chǎng)景 ，這一點(diǎn)非常重要 。最終公司損失了無(wú)數(shù)的金錢，大家也都失業(yè)了。但只要您把它看作是一種文化的演進(jìn)，讓交付團(tuán)隊(duì)與運(yùn)維團(tuán)隊(duì)互相學(xué)習(xí)，互相幫助，成為真正的跨功能一體化團(tuán)隊(duì)，為客戶提供更好的服務(wù)，最終也就達(dá) 到了它的目標(biāo)。如果沒(méi)有業(yè)務(wù)目標(biāo)或者我們所做的事情根本對(duì)實(shí)現(xiàn)業(yè)務(wù)目標(biāo)都沒(méi)有助益又會(huì)怎樣呢？糟糕， 我們所做的一切都變成了一種愛好 。盡管每個(gè)企業(yè) 的組織結(jié)構(gòu)圖各不相同，但是為了有個(gè)共同的討論點(diǎn)，我們能夠非常容易的將其劃分為開發(fā)陣營(yíng)與運(yùn)維陣營(yíng)（當(dāng)然，現(xiàn)實(shí)世界遠(yuǎn)比這復(fù)雜和無(wú)趣）。把 DevOps 變成一個(gè)新職位名稱或特定角色是一件非常危險(xiǎn)的事情。 企業(yè)依靠他們來(lái)應(yīng)對(duì)不斷變化的需求。 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 開發(fā)人員把一個(gè)軟件版本 “扔 ”給墻對(duì)面的運(yùn)維人員。 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 企業(yè) 的需求分析 企業(yè)的 需求 1. 快速響應(yīng) 傳統(tǒng)觀念中規(guī)模龐大、發(fā)布周期長(zhǎng)達(dá)數(shù)月乃至數(shù)年的軟件產(chǎn)品研發(fā)方式正在發(fā)生變化。 通過(guò)引入自動(dòng)化測(cè)試、測(cè)試 驅(qū)動(dòng)開發(fā)、持續(xù)集成等敏捷實(shí)踐，開發(fā) /測(cè)試階段的質(zhì)量保障活動(dòng)能夠得到有效改善。 DevOps 是一組流程、技術(shù)與工具的統(tǒng)稱，用于促進(jìn)開發(fā)、技術(shù)運(yùn)營(yíng)和質(zhì)量保障部門之間的溝通、協(xié)作與整合。 o 用 Puppet 或 Chef 等工具自動(dòng)化環(huán)境設(shè)置、軟件安裝 /配置等操作，將配置信息轉(zhuǎn)化為源代碼，實(shí)現(xiàn)環(huán)境配置的版本控制。顯而易見，投入精力將 DevOps落到實(shí)處，我們應(yīng)該會(huì)更加高效、更加敏捷和減少挫敗感。開發(fā)和運(yùn)維分別按照不同的節(jié)奏進(jìn)行。因?yàn)闆](méi)有人對(duì)軟件質(zhì)量有信心，比如不能肯定它是否能夠處理生產(chǎn)環(huán)境中那么多的負(fù)載。 通過(guò)自動(dòng)化基礎(chǔ)設(shè)施、共享版本控制、自動(dòng)化構(gòu)建和部署、共享度量體系、強(qiáng)化溝通機(jī)制等手段， Flickr 在保證網(wǎng)站穩(wěn)定性和性能的同時(shí)，達(dá)到了每天能部署 10 次以上的需求響應(yīng)水平，同時(shí)在開發(fā)團(tuán)隊(duì)與運(yùn)營(yíng)團(tuán)隊(duì)之間建立起互相尊重、彼此信任的協(xié)作關(guān)系。 軟件的發(fā)布過(guò)程是一個(gè)整體系統(tǒng)，需要對(duì)其進(jìn)行端到端的流程優(yōu)化。但是，如果你不改變企業(yè)文化，兌現(xiàn) DevOps的承諾將非常困難。 2. 深層模型系統(tǒng) 它的版本系統(tǒng)清晰的描述了軟件系統(tǒng)相關(guān)的 所有組件 、 策略 和 依賴性 ，從而可以簡(jiǎn)單的根據(jù)需要復(fù)制一個(gè)系統(tǒng)或在無(wú)沖突的情況下引入變化。 ? 提測(cè) 是指某個(gè)項(xiàng)目開發(fā)完成后，在正式 上線前，將其提交給測(cè)試組進(jìn)行測(cè)試的活動(dòng)。之后，開發(fā)人員會(huì)填寫 上線申請(qǐng)單 ，經(jīng)運(yùn)維人員確認(rèn)后，運(yùn)維人員操作進(jìn)行 上線部署工作 。比如開發(fā)人員在提測(cè)前，需要在項(xiàng)目管理平臺(tái)上申請(qǐng)?jiān)擁?xiàng)目的 4 位版本。 使用 Hudson 平臺(tái)后，通過(guò)插件即可調(diào)用自動(dòng)化腳本，完成提測(cè)版本的標(biāo)識(shí)。似乎各角色之間的溝通介質(zhì)只有各自的 交付物 。 原來(lái)，各角色僅關(guān)注于自己本身的工作，雖然大家都同處于一個(gè)項(xiàng)目中，但各自劃分了領(lǐng)地 ，產(chǎn)品經(jīng)理就 應(yīng)該將 MRD 寫得清清楚楚，如果開發(fā)人員認(rèn)為不清楚，那就回去再改。如下圖所示： 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 另外，該產(chǎn)品的一個(gè)重要特征是需要不斷地嘗試調(diào)整程序算法策略，以得到最佳的流量效果，而這種調(diào)整的頻率較高（至少每周一次）。所以，所 有任務(wù)完成之前，應(yīng)用程序一直處于不可用狀態(tài)。之后，開發(fā)人員會(huì)從主干上拉出項(xiàng)目分支，并在該分支上進(jìn)行開發(fā)。也許只有行業(yè)頂尖的公司，或者新成立的公司會(huì)有這樣的嘗試。 “基礎(chǔ)設(shè)施即代碼（ Infrastructure as code） ”、 “模型驅(qū)動(dòng)自動(dòng)化（ model driven automation） ”和 “持續(xù)性部署（ continuous deployment） ”都是可以劃歸 DevOps 旗下的概念。只有當(dāng)人們?cè)敢庀嗷ソ徽劊P(guān)心相互的工作時(shí) ，你才能更多更快的創(chuàng)造商業(yè)價(jià)值。 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 ? 團(tuán)隊(duì)穩(wěn)定性。 ? 可視化度量軟件交付過(guò)程，以便快速識(shí)別問(wèn)題、持續(xù)改善。一旦軟件應(yīng)用正式上線以后，業(yè)務(wù)方面往往害怕變更。 業(yè)務(wù)敏捷性承諾， 在企業(yè)權(quán)益集團(tuán)作出決策和開發(fā)者進(jìn)行響應(yīng)之間能夠緊密互動(dòng)和快速反饋 。 擁有成熟的項(xiàng)目自動(dòng)化機(jī)制和能力，開發(fā)團(tuán)隊(duì)能幫助運(yùn)營(yíng)團(tuán)隊(duì)更快地建立發(fā)布與維護(hù)過(guò)程的自動(dòng)化體系，從而實(shí)現(xiàn)軟件價(jià)值的持續(xù)交付。 通過(guò)強(qiáng)有力的發(fā)布協(xié)調(diào)機(jī)制來(lái)彌合開發(fā)與運(yùn)營(yíng)之間的技能鴻溝和溝通鴻溝；采用電話會(huì)議、即時(shí)消息、企業(yè)門戶（ wiki、 sharepoint）等協(xié)作工具來(lái)確保所有相關(guān)人員理解變更的內(nèi)容；使用統(tǒng)一的流程和工具，例如故事墻、燃盡圖、在線項(xiàng)目管理工具（ 例如 Mingle、 JIRA）、配置管理工具（例如 Subversion、Git、 Mercurial）等。 ? 開發(fā)團(tuán)隊(duì)與運(yùn)營(yíng)團(tuán)隊(duì)通常屬于不同的部門。 ? 開發(fā)人員對(duì)非功能性需求缺乏關(guān)注，并且沒(méi)有相應(yīng)驗(yàn)證環(huán)境，導(dǎo)致非功能性缺陷。 本來(lái)應(yīng)該一帆風(fēng)順的部署過(guò)程最后變成一場(chǎng)救火行動(dòng)，經(jīng)過(guò)反復(fù)測(cè)試之后才讓生產(chǎn)環(huán)境恢復(fù)到正常狀態(tài)。即使在某些工具類型上有一些重疊之處，使用方式也完全不同。湯普森（ Lee Thompson）和安德魯 被劃分為不同階段的部署以及其它技術(shù)常被用于減少?gòu)氐撞还ぷ鞯娘L(fēng)險(xiǎn)，但真相是，我常常發(fā)現(xiàn)我不得不在產(chǎn)品環(huán)境下運(yùn)行測(cè)試以得到可信的結(jié)果。 因?yàn)樾屡d的 DevOps 運(yùn)動(dòng)主要是技術(shù)人員在推動(dòng)，所以很容易理解為什么人們很興奮的直接去討論工具。但是我們失去了真正做事的動(dòng)力， 到處是效率低下的工作、浪費(fèi)、沖突和部 門間的孤立 。 與 DevOps 具有相同理念的術(shù)語(yǔ)很多，例如 敏捷運(yùn)維 （ Agile Operations）、 敏捷基礎(chǔ)設(shè)施（ Agile Infrastructure） 和 Dev2Ops。 于是非常沮喪的運(yùn)維部門開始記錄各種問(wèn)題，源源不斷的給開發(fā)部門提 Issue。 Flickr發(fā)展了自己的 DevOps能力，使之能夠支撐業(yè)務(wù)部門 “每天部署 10次 ”的要求 ──如果一個(gè)組織要生產(chǎn)面向多種用戶、具備多樣功能的應(yīng)用程序，其部署周期必然會(huì)很短。 集群配置說(shuō)明 .................................................................... 錯(cuò)誤 !未定義書簽。 bailingout錯(cuò)誤 !未定義書簽。 算法介紹 ........................................................................... 錯(cuò)誤 !未定義書簽。 Slave(60,245上 )配置 .............................................................. 錯(cuò)誤 !未定義書簽。 目的 ....................................................................................... 錯(cuò)誤 !未定義書簽。 下載 ....................................................................................... 錯(cuò)誤 !未定義書簽。 測(cè)試 ....................................................................................... 錯(cuò)誤 !未定義書簽。 Hadoop的系統(tǒng)監(jiān)控 ................................................................. 錯(cuò)誤 !未定義書簽。 解決 hadoop OutOfMemoryError問(wèn)題： ............................. 錯(cuò)誤 !未定義書簽。一說(shuō)起做互聯(lián)網(wǎng)，你要是還在走倆月一個(gè)版本的發(fā)布周期呀，你都不好意思跟人打招呼 ──等你做出新版本，用戶都跑競(jìng)爭(zhēng)對(duì)手那兒去啦。 一個(gè)熟悉的例子：部署軟件產(chǎn)品 下面是一個(gè)大家都基本熟悉的例子：部署軟件產(chǎn)品。終極的失敗。 DevOps不是個(gè)技術(shù)問(wèn)題，而是個(gè)業(yè)務(wù)問(wèn)題 當(dāng)然， DevOps 不乏反對(duì)者。想想 吧，有誰(shuí)會(huì)傻到給愛好付薪水呢。 如上圖所示，在開發(fā)和運(yùn)維之間存在著一面混亂之墻，在這種情況下，大部分早期DevOps 的注意力都放在在改善 部署活動(dòng) 上。例如這會(huì)導(dǎo)致以下錯(cuò)誤端點(diǎn)：你是一個(gè) DBA？或者是一個(gè)安全專家？那么不用擔(dān)心 DevOps，因?yàn)槟鞘?DevOps 團(tuán)隊(duì)的問(wèn)題。因此他們被鼓勵(lì)盡可能進(jìn)行變革。后者拿到該版本產(chǎn)品后開始準(zhǔn)備將其部署。在 “快魚吃慢魚 ”的互聯(lián)網(wǎng)時(shí)代，上市時(shí)間（ Time To Market）成為衡量軟件組織能力的重要因素：能快速接納需求、快速完成開發(fā)、快速上線投入使用的軟件產(chǎn)品，才能有效占領(lǐng)市場(chǎng)、吸引用戶。然而對(duì)于客戶和最終用戶來(lái)說(shuō)，不論哪個(gè)環(huán)節(jié)引入的缺陷都同樣會(huì)給業(yè)務(wù)造成損失。 “DevOps”這個(gè)名稱即是指開發(fā)（ dev）與運(yùn)營(yíng)（ op）的無(wú)縫融合。 o 用 Capistrano 等工具自動(dòng)化軟件產(chǎn)品的部署，實(shí)現(xiàn)部署過(guò)程的版本控制。有些人可能會(huì)反駁稱 DevOps是一個(gè)遙不可及的目標(biāo)，但這并非說(shuō)我們不應(yīng)該去嘗試實(shí)現(xiàn)它。實(shí)際上，產(chǎn)品部署之間的長(zhǎng)期間隔使得一個(gè)團(tuán)體的敏捷工作變成了它一直試圖避免的瀑布生命周期。 3. “它在我的機(jī)器上沒(méi)有問(wèn)題！ ”常常聽說(shuō)開發(fā)人員這么說(shuō)，而運(yùn)維團(tuán)隊(duì)的確遇到了麻煩。 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 圖 4：全球最大的圖片分享網(wǎng)站 Flickr 每天有超過(guò) 10 次部署上線 [7] 案例 II：某在線社交網(wǎng)站 該網(wǎng)站從 2020 年開始運(yùn)營(yíng)，目前擁有超過(guò) 3000 萬(wàn)注冊(cè)用戶。 ThoughtWorks 采用精益價(jià)值流改善（ Lean Value Stream Improvement）作為 DevOps 建設(shè)的框架，并在其中嵌入針對(duì)軟件構(gòu)建、發(fā)布、運(yùn)營(yíng)的知識(shí)和實(shí)踐，以迭代方式管理改善活動(dòng)，全程以可視化形式直觀展現(xiàn)工作進(jìn)展?fàn)顟B(tài)，從而最大程度地保障改 善得以成功實(shí)施?？疾煲粋€(gè)企業(yè)的主導(dǎo)文化時(shí)，你需要緊密關(guān)注如何評(píng)價(jià)和判斷企業(yè)業(yè)績(jī)。 3. 人工任務(wù) 的自動(dòng)化 在依賴關(guān)系發(fā)現(xiàn)、系統(tǒng)構(gòu)造、配置、更新和回滾等過(guò)程中，減少人工干涉。對(duì)于客戶來(lái)說(shuō)， 提測(cè) 這個(gè)動(dòng)作本身并不增加什么價(jià)值，但也需要花費(fèi)一定的時(shí)間。如圖所示。拿到 4 位版本后，才能提交平臺(tái)統(tǒng)一編譯。 ? 統(tǒng)一配置信息源 ——將所有的配置項(xiàng)全部放在 Subversion 庫(kù)中進(jìn)行版本控制；并根據(jù)應(yīng)用環(huán)境的不同，分別保存在 Dev， Test 和 Online 三個(gè)目錄中。 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 現(xiàn)在，各角色都能夠共同合作，以項(xiàng)目的最終交付為目標(biāo)，積極討論需求，優(yōu)化實(shí)現(xiàn)。 小結(jié) 通過(guò)以上改進(jìn)措施，讓團(tuán)隊(duì)的合作方式發(fā)生了重大變化，從 碉堡防御 走向了 戰(zhàn)線統(tǒng)一 。部 署配置信息分散在各處。 每個(gè)開發(fā)人員會(huì)將需求分解成多個(gè)技術(shù)任務(wù)后開發(fā)。如果涉及到多模塊，每個(gè)模塊的開發(fā)人員會(huì)對(duì)各自負(fù)責(zé)的模塊進(jìn)行 詳細(xì)設(shè)計(jì) ，給出大致的 開發(fā)計(jì)劃 ，并 商定聯(lián)調(diào)時(shí)間點(diǎn) 。 讓數(shù)據(jù)說(shuō)話 有人評(píng)論說(shuō)： 針對(duì)目前國(guó)內(nèi)情況， DevOps 還是很遙遠(yuǎn)。如果你關(guān)注 Puppet、 Chef或 ControlTier 等工具社區(qū)，那么你可能已經(jīng)意識(shí)到人們對(duì)在開發(fā)和運(yùn)維工具之間建立橋梁的重大關(guān)注。開始 DevOps，意味著開始了一場(chǎng)你的 程序員和系統(tǒng)管理者的 心態(tài) 的轉(zhuǎn)變。如果缺乏高層領(lǐng)導(dǎo)的關(guān)注，或者如果高層領(lǐng)導(dǎo)只把 DevOps 看作小范圍、技術(shù)性的改善， DevOps 建設(shè)將很難收到預(yù)期的效果。 ? 減少發(fā)布和運(yùn)營(yíng)中的 浪費(fèi)，提高運(yùn)營(yíng)團(tuán)隊(duì)的工作效率。 作為 DevOps 的倡導(dǎo)者，獨(dú)立 IT 咨詢師 Patrick Debois 認(rèn)為， DevOps 對(duì)下述問(wèn)題的解決有很大幫助： 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 1. 對(duì)變更的恐懼 。對(duì)于多數(shù)機(jī)構(gòu)來(lái)說(shuō)，迭代項(xiàng)目管理方法 Scrum 是敏捷的代名詞。 ? 持續(xù)集成。 ? 加強(qiáng)開發(fā)與運(yùn)營(yíng)協(xié)調(diào)。開發(fā)人員通常在公司內(nèi)的桌面電腦上工作，運(yùn)營(yíng)人員經(jīng)常在客戶現(xiàn)場(chǎng)、在服務(wù)器上工作。造成這一現(xiàn)象的原因有： ? 開發(fā)人員對(duì)生產(chǎn)環(huán)境缺乏了解，在代碼中引入了只有在生產(chǎn)環(huán)境才會(huì)暴露的缺陷。 沒(méi)有一個(gè)可靠的方式來(lái)把環(huán)境回滾到此前已知的正常狀態(tài)?？匆幌麻_發(fā)者要求和日常使用的常見工具，再看一下系統(tǒng)管理員，你會(huì)發(fā)現(xiàn)兩者存在很大不同，開發(fā)人員沒(méi)有興趣使用運(yùn)維人員的工具，反之亦然；而且兩部分工具之間也不存在重要的集成。 混亂之墻 正如李 缺乏大規(guī)模的集群，缺少獨(dú)特的硬件，缺乏足夠的用戶數(shù)，這一切都會(huì)決定測(cè)試是否充分，結(jié)果是否可信。 實(shí)際上，當(dāng)我們明確我們的 DevOps 問(wèn)題究竟是什么