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

　　

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