【導(dǎo)讀】為什么要選擇Hadoop？

　　

【正文】 s意味著什么 ？ DevOps 是一種一起討論和一起工作的文化。開始 DevOps，意味著開始了一場(chǎng)你的 程序員和系統(tǒng)管理者的 心態(tài) 的轉(zhuǎn)變。只有當(dāng)人們?cè)敢庀嗷ソ徽?，關(guān)心相互的工作時(shí) ，你才能更多更快的創(chuàng)造商業(yè)價(jià)值。只有在這種情況下，尋找培養(yǎng) DevOps 文化的方法和工具才會(huì)有意義。 4 如何實(shí)施 DevOps？ 如何將 DevOps落到實(shí)處？ 和多數(shù)新出現(xiàn)的話題一樣， 發(fā)現(xiàn)問題的共性特點(diǎn)要比找到解決方案容易的多 。 DevOps 是一種能力 ， 如何獲得這種能力呢？ 實(shí)現(xiàn) DevOps 相關(guān)解決方案 關(guān)鍵有 以下三點(diǎn) 需要關(guān)注 ： 評(píng)價(jià)和鼓勵(lì)改變文化 改變文化和激勵(lì)系統(tǒng)從來不是一件易事。但是，如果你不改變企業(yè)文化，兌現(xiàn) DevOps的承諾將非常困難?？疾煲粋€(gè)企業(yè)的主導(dǎo)文化時(shí)，你需要緊密關(guān)注如何評(píng)價(jià)和判斷企業(yè)業(yè)績(jī)。評(píng)價(jià)的內(nèi) 容將影響和刺激行為的發(fā)生。開發(fā) 運(yùn)維生命周期中的所有當(dāng)事方需要明白，在更大的企業(yè)流程中自己只是其中一部分。個(gè)體和團(tuán)隊(duì)的成功都要放在整個(gè)開發(fā) 運(yùn)維生命周期內(nèi)來進(jìn)行評(píng)價(jià)。對(duì)于許多機(jī)構(gòu)來說，這是一個(gè)轉(zhuǎn)變，不再是孤立的來進(jìn)行業(yè)績(jī)?cè)u(píng)價(jià)，每一個(gè)團(tuán)隊(duì)不再是基于自己的團(tuán)隊(duì)來評(píng)價(jià)和判斷業(yè)績(jī)好壞。 統(tǒng)一標(biāo)準(zhǔn)化的流程 要從軟件交付的全局出發(fā)，加強(qiáng)各角色之前的合作 ，整個(gè)開發(fā) 運(yùn)維生命周期必須被看作一個(gè)端對(duì)端過流程。流程的不同階段可以采取不同的方法，只要這些流程可以被組合到一起創(chuàng)建一個(gè)統(tǒng)一的流程。與評(píng)價(jià)和激勵(lì)的問題相似的是，實(shí)現(xiàn)這個(gè) 統(tǒng)一的流程時(shí)每個(gè)組織可能會(huì)有略微不同的需求。 統(tǒng)一的工具 這是大多數(shù) DevOps 討論一直在關(guān)注的領(lǐng)域。這一點(diǎn)不令人吃驚，因?yàn)楫?dāng)技術(shù)專家在考慮解決一個(gè)問題時(shí)，第一反應(yīng)往往就是直接跳轉(zhuǎn)到工具討論上。如果你關(guān)注 Puppet、 Chef或 ControlTier 等工具社區(qū)，那么你可能已經(jīng)意識(shí)到人們對(duì)在開發(fā)和運(yùn)維工具之間建立橋梁的重大關(guān)注。 “基礎(chǔ)設(shè)施即代碼（ Infrastructure as code） ”、 “模型驅(qū)動(dòng)自動(dòng)化（ model driven automation） ”和 “持續(xù)性部署（ continuous deployment） ”都是可以劃歸 DevOps 旗下的概念。 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 關(guān)于把 DevOps 變?yōu)楝F(xiàn)實(shí)需要哪些類型的工具，杰克 索羅夫曼（ Jake Sorofman）提出如下建議： 1. 一個(gè)版本控制軟件庫 它可以確保所有系統(tǒng)產(chǎn)品在整個(gè)版本發(fā)布生命周期中被很好的定義，且能夠?qū)崿F(xiàn)一致性共享，同時(shí)保持最新信息。開發(fā)和 QA 機(jī)構(gòu)能夠從中取得相同平臺(tái)版本，生產(chǎn)機(jī)構(gòu)部署已經(jīng)被 QA 機(jī)構(gòu)驗(yàn)證過的相同版本。 2. 深層模型系統(tǒng) 它的版本系統(tǒng)清晰的描述了軟件系統(tǒng)相關(guān)的 所有組件 、 策略 和 依賴性 ，從而可以簡(jiǎn)單的根據(jù)需要復(fù)制一個(gè)系統(tǒng)或在無沖突的情況下引入變化。 3. 人工任務(wù) 的自動(dòng)化 在依賴關(guān)系發(fā)現(xiàn)、系統(tǒng)構(gòu)造、配置、更新和回滾等過程中，減少人工干涉。自動(dòng)操作變?yōu)楦咚?、無沖突和大規(guī)模系統(tǒng)管理的命令和控制基礎(chǔ)。 應(yīng)選擇那些支持腳本化、無需人機(jī)交互界面的強(qiáng)大管理工具，比如各種受版本控制的script，以及類似于 Nagios 這樣的基礎(chǔ)設(shè)施監(jiān)控工具，類似于 Puppet、 Chef 這樣的基礎(chǔ)設(shè)施配置管理工具。 目前 從開發(fā)到運(yùn)維的生命周期中存在許多不同的工具 ，它覆蓋了 監(jiān)控 、 準(zhǔn)備 、 配置管理以及 控制 等方面，逐漸形成該領(lǐng)域中流程及工具標(biāo)準(zhǔn)化的生力軍 , 工具選擇和執(zhí)行決策需要根據(jù)它們對(duì)端到端生命周期的 影響來決定 。 作為 DevOps 運(yùn)動(dòng)的實(shí)踐者， ThoughWorks 的 IT 主管 Ajey Gore 介紹說：在ThoughtWorks 內(nèi)部，我們已經(jīng)在全球 22 個(gè)辦公室的 500 多臺(tái)服務(wù)器和虛擬機(jī)上安裝了Puppet。在公司內(nèi)部，我們現(xiàn)在 : ? 建立了 Puppet 的版本控制庫。 ? 每個(gè) Puppet 服務(wù)器每 30 分鐘會(huì)檢查一次版本控制庫。如果發(fā)現(xiàn)有變更，就會(huì)進(jìn)行本地更新，并重新啟動(dòng)服務(wù)器。 ? Puppet 服務(wù)器也檢查 puppet 腳本，反過來重新啟動(dòng)版本控制庫。 ? 如果有 Puppet 服務(wù)器出了問題， Nagios 就會(huì)告訴我們那臺(tái)服務(wù)器上的 Puppet 沒有運(yùn)行，我們就可以修復(fù)它了。 讓數(shù)據(jù)說話 有人評(píng)論說： 針對(duì)目前國內(nèi)情況， DevOps 還是很遙遠(yuǎn)。也許只有行業(yè)頂尖的公司，或者新成立的公司會(huì)有這樣的嘗試。大多數(shù)的企業(yè)還未開始進(jìn)行敏捷的推進(jìn)，傳統(tǒng)的重重阻 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 礙會(huì)使敏捷的推進(jìn)進(jìn)程遙遙無期。 DevOps 真的離我們有那么遠(yuǎn)嗎？ DevOps 應(yīng)該從哪里開始呢？ 讓我們看一看百度某產(chǎn)品線在半年內(nèi)的變化吧。首先要說明 以下 兩個(gè)百度術(shù)語。 ? 提測(cè) 是指某個(gè)項(xiàng)目開發(fā)完成后，在正式 上線前，將其提交給測(cè)試組進(jìn)行測(cè)試的活動(dòng)。對(duì)于客戶來說， 提測(cè) 這個(gè)動(dòng)作本身并不增加什么價(jià)值，但也需要花費(fèi)一定的時(shí)間。 ? 上線 是指某個(gè)項(xiàng)目驗(yàn)證合格后，將其部署到服務(wù)器的過程，其中包括 上線申請(qǐng) 和 實(shí)際部署 兩個(gè)活動(dòng)。 也許在各公司中對(duì)這兩個(gè)活動(dòng)叫法不同，但在軟件生命周期中， 提測(cè) 、 上線 這兩件事無論花 多 長時(shí)間，大家可能都不會(huì)感到奇怪。下面兩張圖是該產(chǎn)品線進(jìn)行改進(jìn)之后的對(duì)比數(shù)據(jù)。 從圖中不難看出，提測(cè)和上線部署的效率已大大提高。象百度這樣的互聯(lián)網(wǎng)企業(yè)，產(chǎn)品線多得數(shù)不清，幾乎每個(gè)產(chǎn)品線每周都有新功能部署。僅從這兩個(gè)數(shù)據(jù)來看，其收益可想而知。 流程建模 既然 DevOps 關(guān)注于價(jià)值交付 的全過程，那就讓我們看看該產(chǎn)品線常見的交付過程吧。 對(duì)于單個(gè)項(xiàng)目來說，它大體上是一個(gè)典型的瀑布開發(fā)過程。首先是 需求收集與整理 ， 撰寫 MRD(Marketing Requirement Document)或總體設(shè)計(jì) 后，進(jìn)行 評(píng)審 。如果涉及到多模塊，每個(gè)模塊的開發(fā)人員會(huì)對(duì)各自負(fù)責(zé)的模塊進(jìn)行 詳細(xì)設(shè)計(jì) ，給出大致的 開發(fā)計(jì)劃 ，并 商定聯(lián)調(diào)時(shí)間點(diǎn) 。之后，開發(fā)人員會(huì)從主干上拉出項(xiàng)目分支，并在該分支上進(jìn)行開發(fā)。當(dāng)?shù)阶詈舐?lián)調(diào)點(diǎn)時(shí)，幾個(gè)開發(fā)人員才會(huì)在將代碼合在一起，進(jìn)行 聯(lián)調(diào) 。當(dāng)調(diào)通之后，開發(fā)人員再 申請(qǐng)?zhí)釡y(cè) 。測(cè)試人員接到提測(cè)申請(qǐng)單后 ，進(jìn)行 測(cè)試 ，記錄 Bug，通知開發(fā)人員修復(fù)，直 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 致質(zhì)量達(dá)到標(biāo)準(zhǔn)。之后，開發(fā)人員會(huì)填寫 上線申請(qǐng)單 ，經(jīng)運(yùn)維人員確認(rèn)后，運(yùn)維人員操作進(jìn)行 上線部署工作 。如圖所示。 開發(fā)的復(fù)雜性還在于：該 產(chǎn)品線有很多并行項(xiàng)目 ，為了避免互相干擾可能帶來的沖突，每個(gè)項(xiàng)目啟動(dòng)后都會(huì)重新在主干上拉出分支，在上線前才進(jìn)行合并。如下圖 所示。 另外，并行項(xiàng)目太多，導(dǎo)致每個(gè)開發(fā)人員會(huì)同時(shí)參與多個(gè)處于不同階段的項(xiàng)目。那些周期較長的項(xiàng)目雖然會(huì)被分解成多個(gè)迭代，但每個(gè)迭代內(nèi)都是同樣的開發(fā)流程，只是最后僅有一次上線而已。 總而言之，突出的 問題表現(xiàn) 在： 1. 同一角色多個(gè)人員的合作開發(fā)； 2. 各角色部門之間的協(xié)作以各自的產(chǎn)品物為目標(biāo)，如 MRD、產(chǎn) 品代碼、測(cè)試用例、上線操作單； 3. 基于人機(jī)交互方式的內(nèi)部流程管理平臺(tái)。 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 發(fā)現(xiàn)浪費(fèi) 從精益思想出發(fā)，為了盡早交付價(jià)值，必須首先 找出整個(gè)流程中的浪費(fèi) ，并將其消除，從而提高流程效率，讓 一個(gè)想法從提出到實(shí)現(xiàn) 可在最短時(shí)間里完成。那么，浪費(fèi)到底表現(xiàn)在哪里呢？ ? 一些不必要的多分支開發(fā)，合并后發(fā)生問題的風(fēng)險(xiǎn)高。 多個(gè)項(xiàng)目中可能都要修改同一個(gè)模塊的代碼，每次在最后合并代碼時(shí)都會(huì)出現(xiàn)一些問題，非常痛苦，尤其是修改比較大的時(shí)候，合并及修復(fù)時(shí)間較長。 ? 推遲問題被發(fā)現(xiàn)的時(shí)間。 每個(gè)開發(fā)人員會(huì)將需求分解成多個(gè)技術(shù)任務(wù)后開發(fā)。所以，所 有任務(wù)完成之前，應(yīng)用程序一直處于不可用狀態(tài)。當(dāng)最后在一起聯(lián)調(diào)時(shí)，常常會(huì)發(fā)現(xiàn)一些意想不到的問題。 ? 基于流程平臺(tái)的溝通。 在提測(cè)環(huán)節(jié)中，溝通完全基于內(nèi)部項(xiàng)目管理平臺(tái)和即時(shí)消息工具或 Email。比如開發(fā)人員在提測(cè)前，需要在項(xiàng)目管理平臺(tái)上申請(qǐng)?jiān)擁?xiàng)目的 4 位版本。拿到 4 位版本后，才能提交平臺(tái)統(tǒng)一編譯。如果編譯失敗，那么問題解決后還要再次申請(qǐng) 4 維版本。如果成功，則在項(xiàng)目管理平臺(tái)上填寫表單，回答一系列的問題（比如，是否做過單測(cè)？測(cè)了哪些功能點(diǎn)？部署步驟是什么？），發(fā)起提測(cè)工作流，管理平臺(tái)會(huì)自動(dòng)發(fā)送電子郵件給相關(guān)測(cè)試人員，通知 他們進(jìn)行測(cè)試。測(cè)試人員收到該提測(cè)工作流后，必須在平臺(tái)上進(jìn)行相關(guān)確認(rèn)操作，通知開發(fā)人員已收到該版本。如果測(cè)試人員對(duì)部署和測(cè)試內(nèi)容有疑問的話，還會(huì)通過即時(shí)通訊工具或郵件與開發(fā)人員進(jìn)行確認(rèn)。 ? 常規(guī)的例行工作很難自動(dòng)化。 上線部署也需要通過內(nèi)部平臺(tái)來完成。開發(fā)人員拿到已測(cè)試通過的 4 位版本后，先要登錄到內(nèi)部平臺(tái)，再提交上線申請(qǐng)單，填寫上線步驟。當(dāng)運(yùn)維人員收到上線步驟后，再將其 翻譯 成平臺(tái)可以識(shí)別的 半自動(dòng)上線步驟，再讓平臺(tái)來執(zhí)行。如果運(yùn)維人員不理解上線步驟，就要和開發(fā)人員通過電子郵件或即時(shí)通訊工作等進(jìn)行反復(fù)確認(rèn)。部 署配置信息分散在各處。如下圖所示： 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 另外，該產(chǎn)品的一個(gè)重要特征是需要不斷地嘗試調(diào)整程序算法策略，以得到最佳的流量效果，而這種調(diào)整的頻率較高（至少每周一次）。當(dāng)需要調(diào)整策略時(shí)，開發(fā)人員修改代碼后重新進(jìn)行編譯打包，由于產(chǎn)品代碼發(fā)生變化，所以測(cè)試人員仍需要進(jìn)行大量的回歸測(cè)試，而運(yùn)維人員在部署時(shí)也需要 將對(duì)二進(jìn)制文件包進(jìn)行整體部署，整個(gè)周期比較長。 從上面這些內(nèi)容中，我們不難發(fā)現(xiàn)，流程中更傾向于將問題推遲到后面解決（比如最后集成聯(lián)調(diào)），將工具（平臺(tái)、郵件、即時(shí)通訊）作為協(xié)作的基礎(chǔ)，而角色間的溝通幾乎完全依賴于前一個(gè)環(huán)節(jié)的產(chǎn)物（比如 MRD、產(chǎn)品代碼、上線步驟）。那么我們使用哪些對(duì)策進(jìn)行優(yōu)化，達(dá)到消除浪費(fèi)的目的呢？ 應(yīng)對(duì)措施 無人工干預(yù)方式的腳本 自動(dòng)化 ? 自動(dòng)化提測(cè) ——由于已做到了每日集成，所以每天都有可測(cè)試的版本，開發(fā)人員不再需要為提測(cè)進(jìn)行專門的準(zhǔn)備工作，只要從成功構(gòu)建的列表中選擇一個(gè)給測(cè)試人員就可以了。 使用 Hudson 平臺(tái)后，通過插件即可調(diào)用自動(dòng)化腳本，完成提測(cè)版本的標(biāo)識(shí)。 ? 統(tǒng)一配置信息源 ——將所有的配置項(xiàng)全部放在 Subversion 庫中進(jìn)行版本控制；并根據(jù)應(yīng)用環(huán)境的不同，分別保存在 Dev， Test 和 Online 三個(gè)目錄中。 ? 常規(guī)流程腳本化 ——經(jīng)過各角色的共同討論和可行性分析，最后配置上線部署的 實(shí)施方案是：由開發(fā)人員將產(chǎn)品二進(jìn)制包與配置項(xiàng)進(jìn)行剝離，這樣僅做策略調(diào)整時(shí)，測(cè)試人員只要對(duì)已修改的配置項(xiàng)進(jìn)行相關(guān)測(cè)試即可。運(yùn)維人員用一系列的腳本代替了內(nèi)部運(yùn)維平臺(tái)的手工上線操作，再通過 Hudson 平臺(tái)的插件，以 Click Button的方式達(dá)到了一鍵式部署。 盡早 發(fā)現(xiàn)問題，解決問題 ? 需求細(xì)分，及時(shí)開發(fā)，及時(shí)驗(yàn)證 ——將需求拆分成端到端可測(cè)試的需求（即 用戶故事 ），這些需求一般可在 3 天內(nèi)完成。在實(shí)現(xiàn)每個(gè)需求之前，開發(fā)人員與測(cè) 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 試人員進(jìn)行充分溝通，對(duì)需求與驗(yàn)收條件達(dá)成共識(shí)。每開發(fā)完成一個(gè)用戶故事，就進(jìn)行測(cè) 試，并用自動(dòng)化測(cè)試進(jìn)行覆蓋。 ? 主干開發(fā)，分支提測(cè) ——將原來的多個(gè)分支進(jìn)行合并，統(tǒng)一在主干上開發(fā)，每周結(jié)束時(shí)拉出一個(gè)分支，進(jìn)行提測(cè)，一旦發(fā)現(xiàn)問題，就在主干上修復(fù)。 ? 持續(xù)集成 ——為了確保每次提交質(zhì)量，對(duì)主干開發(fā)建立持續(xù)集成環(huán)境，開發(fā)人員和自動(dòng)化測(cè)試人員都嚴(yán)格遵守持續(xù)集成紀(jì)律 Checkin Dance。 新的開發(fā)流程如下圖所示。 分支開發(fā)策略變更為 Single Branch 模式。 小結(jié) 通過以上改進(jìn)措施，讓團(tuán)隊(duì)的合作方式發(fā)生了重大變化，從 碉堡防御 走向了 戰(zhàn)線統(tǒng)一 。 原來，各角色僅關(guān)注于自己本身的工作，雖然大家都同處于一個(gè)項(xiàng)目中，但各自劃分了領(lǐng)地 ，產(chǎn)品經(jīng)理就 應(yīng)該將 MRD 寫得清清楚楚，如果開發(fā)人員認(rèn)為不清楚，那就回去再改。開發(fā)人員只管按照 MRD 上的內(nèi)容進(jìn)行開發(fā)，很少考慮可測(cè)性和易測(cè)性問題。測(cè)試人員只管按照 MRD 中內(nèi)容來測(cè)試，有問題通過內(nèi)部工作流平臺(tái)提交問題單。運(yùn)維人員只管根據(jù)開發(fā)人員提交的上線操作單進(jìn)行操作。似乎各角色之間的溝通介質(zhì)只有各自的 交付物 。 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 現(xiàn)在，各角色都能夠共同合作，以項(xiàng)目的最終交付為目標(biāo)，積極討論需求，優(yōu)化實(shí)現(xiàn)。因?yàn)榻巧g的這種緊密合作讓所有人對(duì)不同角色都有了深入的了解。開發(fā)人員耐心為產(chǎn)品經(jīng)理解釋技術(shù)實(shí)現(xiàn)，說明計(jì)劃安排，測(cè)試人員與開發(fā)人員 共同討論驗(yàn)收條件，避免遺漏需求。開發(fā)人員讓運(yùn)維人員了解架構(gòu)設(shè)計(jì)， 細(xì)心聽取運(yùn)維人員的建議，進(jìn)行技術(shù)改造，使部署工作更快捷有效。 通過這些活動(dòng)，大家都認(rèn)識(shí)到原有內(nèi)部管理平臺(tái)僅是個(gè)公文流轉(zhuǎn)的支撐平臺(tái)，要想提高工作效率，就要將這種 辦公自動(dòng)化工具 進(jìn)一步提升為 全面自動(dòng)化工具 ，使所有人更關(guān)注于端到 端的價(jià)值，而非各角色之間的分界點(diǎn)。