【正文】 IT 融合程度，改善軟件交付 “最后一公里 ”的質(zhì)量和效率，為實現(xiàn)業(yè)務(wù)敏捷打好基礎(chǔ)。開發(fā)人員通常缺乏服務(wù)器管理的技能，運(yùn)營人員通常缺乏軟件編程的技能。 ? 缺乏針對生產(chǎn)環(huán)境的回歸測試，導(dǎo)致缺陷不能及時被發(fā)現(xiàn)。如何縮短發(fā)布和運(yùn)維工作的周期，已經(jīng)成為困擾很多軟件組織領(lǐng)導(dǎo)者的問題。 阿爾斯帕瓦（ John Allspaw）所指出的那樣， 開發(fā)和運(yùn)維之間的協(xié)作需求在部署之前就已存在，同時也會在部署之后的長時間之內(nèi)繼續(xù)存在 。當(dāng)然，期間如果發(fā)生一個問題，開發(fā)人員會被要求來幫助進(jìn)行排障。下圖雖然是一個抽象化場景，但是如果你經(jīng)歷過這一過程，一定會感覺到它的真實性。他們都認(rèn)為自己的做法是正確的。 角色認(rèn)知不同 ? 以開發(fā)為中心的人 通常認(rèn)為， 變化會帶來回報。 ThoughtWorks 很早就認(rèn)識 到發(fā)布與運(yùn)營對于成功交付的重要性。但是， DevOps 不應(yīng)該是一個單一的位置或職稱。一個系統(tǒng)如何從它當(dāng)前的狀態(tài)遷移到未來我們所希望達(dá)到的狀態(tài)？這一點很少被納入考慮， DevOps運(yùn)動對這個容易出錯的領(lǐng)域格外關(guān)注 。 可惜的是， DevOps 必須從某個地方開始，于是我們碰到了一個幾乎非常普遍的問題：開發(fā)者文化與運(yùn)維文化之間存在的沖突和脫節(jié)。敏捷深度關(guān)注于改善一個主要的 IT 功能（ 交付軟件 ），同時， DevOps 關(guān)注于對跨 IT 功能的 流程和交互 的改善（它拉伸了整個開發(fā)生命周期的長度，使其包括了運(yùn)維）。實現(xiàn)業(yè)務(wù)目標(biāo)是我們得到薪水和花時間做事的原因。 業(yè)務(wù) 流程 與 DevOps的 關(guān) 系 在任何公司里，最根本的業(yè)務(wù)流程都是這樣： 使一個最初的想法經(jīng)過流程最終賺到錢 。 盡管大家對 DevOps 的看法不盡相同。它是人們?yōu)榱思皶r生產(chǎn)軟件產(chǎn)品或服務(wù)，以 滿足某個業(yè)務(wù)目標(biāo)，對開發(fā)與運(yùn)維之間相互依存關(guān)系的一種新的理解?？蛻簦ㄒ约肮蓶|、投資方和管理層）則成了蒙受損失的失敗方。 【 運(yùn)維部門 】 接到產(chǎn)品后，運(yùn)維部門每個人的心中都充滿了恐懼。 1 概述 作 什么 事情 之前，第一步是要知道 What（是什么），然后是 Why（為什么），最后才是 How 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 （怎么做）。于是很自然地，當(dāng)別人開始熱火朝天地講 DevOps，咱們這兒 ”敏捷運(yùn)維 ”還是幾家互聯(lián)網(wǎng)巨頭的王謝堂前燕。 經(jīng)過幾年的醞釀， 敏捷 和 運(yùn)維 這兩個領(lǐng)域終于各自受到了足夠的重視，并順理成章地有了交集。 hadoop歷史 ............................................................................ 錯誤 !未定義書簽。 : Could not obtain block: ..................... 錯誤 !未定義書 簽。 刪除節(jié)點 ........................................................................... 錯誤 !未定義書簽。 6 Hadoop的應(yīng)用 ............................................................................. 錯誤 !未定義書簽。 5 架構(gòu)分析 ...................................................................................... 錯誤 !未定義書簽。 啟動 Hadoop ..................................................................... 錯誤 !未定義書簽。 執(zhí)行 .................................................................................. 錯誤 !未定義書簽。 所需軟件 ........................................................................... 錯誤 !未定義書簽。 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 DevOps入門實戰(zhàn)手冊 北京寬連十方數(shù)字技術(shù)有限公司 技術(shù) 研究 部 （ 2020年 9月 ） 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 目錄 1 概述 ......................................................................................................................... 4 什么是 Hadoop？ ................................................................................................ 5 為什么要選擇 Hadoop？ .......................................................... 錯誤 !未定義書簽。 支持平臺 ........................................................................... 錯誤 !未定義書簽。 免密碼 ssh設(shè)置 .................................................................. 錯誤 !未定義書簽。 初始化文件系統(tǒng) ................................................................ 錯誤 !未定義書簽。 運(yùn)行的進(jìn)程查看 ................................................................ 錯誤 !未定義書簽。 綜合架構(gòu)分析 ......................................................................... 錯誤 !未定義書簽。 新增節(jié)點 ........................................................................... 錯誤 !未定義書簽。 能夠啟動 datanode，但無法訪問，也無法結(jié)束的錯誤 ....... 錯誤 !未定義書簽。 8 附錄 ............................................................................................. 錯誤 !未定義書簽。 “生產(chǎn) ”與 “產(chǎn)品 ”便是上述三者之于 Web 2的不同。 IT技術(shù)的潮流，向來是澳洲比英美慢兩三年，中國又比澳洲慢兩三年。未來，我希望 DevOps成為一等公民，并且逐漸在非云計算的公司普及開。然后他們把自己的 “ 杰作 ” 一股腦的甩給了運(yùn)維部門，后者還沒能完全接手，前者已經(jīng)迫不及待的開始了慶功會。 2) 運(yùn)維部門比較笨，他們不懂新技術(shù) —— 為什么他們沒法實現(xiàn)最新的技術(shù)呢？為什么他們這么落伍呢？ 3) 在我的機(jī)器上運(yùn)行的沒問題啊 ?? 兩個部門之間的交流很快變成了一場暴風(fēng)驟雨。那么，到底什么是 DevOps呢？ WikiPedia上說： DevOps是軟件開發(fā)、運(yùn)維和質(zhì)量保證三個部門之間的溝通、協(xié)作和集成所采用的流程、方法和體系的一個集合。 總之， 在思想上 ， DevOps 是敏捷理念向運(yùn)維領(lǐng)域的延伸； 在流程上 ，它是 “需求 ”到 “上線 ”全線貫通的關(guān)鍵； 在工具及技術(shù)準(zhǔn)備上 ，虛擬技術(shù)、云計算以及各類工具的日趨成熟，為這場變革奠定堅實的基礎(chǔ)。 盡管在解決 DevOps 問題的方案中，技術(shù)是個關(guān)鍵的組成部分，但是， DevOps 它自己本質(zhì)上是個業(yè)務(wù)問題 。 如果沒有業(yè)務(wù)流程 這一上下文，還會發(fā)生什么事呢？我們的工作將失去意義并最終消失。 我喜歡將敏捷和 DevOps 描述為兩個相關(guān)聯(lián)的思想，它們都有一個共同的祖先，這個祖先就是 精益 ，但是它們關(guān)注了不同的層面。經(jīng)過一年的觀察和思考，事實證明，我們正在解決的是對所有企業(yè)來說最大的問題之一： 如何面 對市場壓力做出盡可能迅速的反應(yīng)從而實現(xiàn)業(yè)務(wù)目標(biāo) 。 DevOps 有如下的特征： 1) 編寫復(fù)雜應(yīng)用的能力， 而不僅僅是簡單的腳本 顯而易見的必要條件 2) 關(guān)注穩(wěn)定性和無故障時間 北京寬連十方數(shù)字技術(shù)有限公司 公開 內(nèi)部公開 √ 機(jī)密 絕密 穩(wěn)定性和無故障時間永遠(yuǎn)對 DevOps們充滿吸引力 3) 額外關(guān)注狀態(tài)間的遷移 在開發(fā)領(lǐng)域，我發(fā)現(xiàn)人們很少跳出功能點本身考慮軟件。 10) 分布或者超級分布式環(huán)境 關(guān)于 DevOps的澄清 現(xiàn)在某些系統(tǒng)管理員正在試圖把自己的崗位名稱改為 “DevOps”。 。相互沖突的 動機(jī) 、 流程 和 工具 導(dǎo)致 了這面 “墻 ”的存在。 開發(fā)人員和運(yùn)維人員認(rèn)識世界的方法，以及各自所處的角色，存在根本性的差別。有人將其稱為一個 “版本發(fā)布（ Release） ”，有人則稱其為一次 “部署（ deployment） ”，但有一件事情是公認(rèn)的，問題可能會隨之而來。由于開發(fā)和運(yùn)維之間的腳本、配置、過程和環(huán)境存在差別，這一部署過程實際上也是首次被執(zhí)行。正如約翰 不能有效縮短部署上線的周期，就無法真正實現(xiàn)快速響應(yīng)業(yè) 務(wù)需求、快速實現(xiàn)業(yè)務(wù)價值。 ? 部署和維護(hù)工作缺乏自動化，在發(fā)布過程中手工操作引入缺陷。 ? 開發(fā)團(tuán)隊與運(yùn)營團(tuán)隊的技能結(jié)構(gòu)不同。需要從運(yùn)營維護(hù)工作本身的特點出發(fā)，引入符合客觀情況的流程、技術(shù)和工具，才能有效改善運(yùn)營維護(hù)工作的質(zhì)量和效率。精益生產(chǎn)的很多原則，例如縮短交付周期、消除浪費(fèi)、重視價值流動、拉動式生產(chǎn)、質(zhì)量內(nèi)建等，在 DevOps 中都得到了體現(xiàn)。 借助強(qiáng)大的部署自動化手段和標(biāo)準(zhǔn)化的環(huán)境管理來降低部署操作的成本、確保部署任務(wù)的可重復(fù)性、減少部署出錯的可能性?？梢园衙艚蒈浖_發(fā)看作精益思想在需求、研發(fā)階段的實施， DevOps 則是精益思想在發(fā)布、運(yùn)營階段的實施（如圖 3）。 從開發(fā)或運(yùn)維的一線人員的觀點來看， DevOps可以讓他們從眾多煩惱中解脫出來。開發(fā)和運(yùn)維人員 需要明白，它們僅僅是一個統(tǒng)一業(yè)務(wù)流程中的一部分。 但是，當(dāng)你從企業(yè)角度回顧一下整個 開發(fā) 運(yùn)維周期 ，敏捷 方法的相關(guān)優(yōu)勢通常會變得非常模糊。 能解決的具體問題 您可能會說： “我們的日常工作中不是一直需要各部門間的緊密協(xié)作嗎？ ”然而，就象很多敏捷實踐（比如迭代開發(fā)、每日構(gòu)建）一樣，它們在 “敏捷 ”一詞出現(xiàn)之前就已被應(yīng)用到工作中，但敏捷讓這些實踐有機(jī)地結(jié)合在一起，發(fā)揮出前所未有的作用。所以對于任何變更都可能需要一個冗長的流程來保證。 敏捷開發(fā)現(xiàn)已漸成主流。 案例 I： Flickr Flickr 是全球最大的圖片共享網(wǎng)站。以下列舉幾項最常見的風(fēng)險： ? 跨部門協(xié)作。DevOps 要求開發(fā)團(tuán)隊和運(yùn)營團(tuán)隊（尤其是運(yùn)營團(tuán)隊）掌握更全面的技能，尤其是項目自動化技能。如果你的程序員他們要做的只是把代碼交給測試部門 (或編譯服務(wù)器上 )，或，更糟糕的，一旦把代碼提交的版本控制庫中就算完事，那你們還有很長的路要走。 4 如何實施 DevOps？ 如何將 DevOps落到實處？ 和多數(shù)新出現(xiàn)的話題一樣， 發(fā)現(xiàn)問題的共性特點要比找到解決方案容易的多 。 統(tǒng)一標(biāo)準(zhǔn)化的流程 要從軟件交付的全局出發(fā)，加強(qiáng)各角色之前的合作 ，整個開發(fā) 運(yùn)維生命周期必須被看作一個端對端過流程。索羅夫曼（ Jake Sorofman）提出如下建議： 1. 一個版本控制軟件庫 它可以確保所有系統(tǒng)產(chǎn)品在整個版本發(fā)布生命周期中被很好的定義，且能夠?qū)崿F(xiàn)一致性共享，同時保持最新信息。在公司內(nèi)部，我們現(xiàn)在 : ? 建立了 Puppet 的版本控制庫。 DevOps 真的離我們有那么遠(yuǎn)嗎？ DevOps 應(yīng)該從哪里開始呢？ 讓我們看一看百度某產(chǎn)品線在半年內(nèi)的變化吧。象百度這樣的互聯(lián)網(wǎng)企業(yè)，產(chǎn)品線多得數(shù)不清，幾乎每個產(chǎn)品線每周都有新功能部署。當(dāng)調(diào)通之后，開發(fā)人員再 申請?zhí)釡y 。 總而言之，突出的 問題表現(xiàn) 在： 1. 同一角色多個人員的合作開發(fā)； 2. 各角色部門之間的協(xié)作以各自的產(chǎn)品物為目標(biāo)，如 MRD、產(chǎn) 品代碼、測試用例、上線操作單； 3. 基于人機(jī)交互方式的內(nèi)部流程管理平臺。 ? 基于流程平臺的溝通。 ? 常規(guī)的例行工作很難自動化。 從上面這些內(nèi)容中，我們不難發(fā)現(xiàn)，流程中更傾向于將問題推遲到后面解決（比如最后集成聯(lián)調(diào)），將工具（平臺、郵件、即時通訊）作為協(xié)作的基礎(chǔ)，而角色間的溝通幾乎完全依賴于前一個環(huán)節(jié)的產(chǎn)物（比如 MRD、產(chǎn)品代碼、上線步驟）。每開發(fā)完成一個用戶故事，就進(jìn)行測 試，并用自動化測試進(jìn)行覆蓋。測試人員只管按照 MRD 中內(nèi)容來測試，有問題通過內(nèi)部工作流平臺提交問題單。