中國idc圈訊，開放數據中心峰會（odcc2020）在北京召開，峰會圍繞數據中心新基建為主題，有數據中心領域及相關行業的眾多專家與會。在9月16日智能監控與管理分論壇上，騰訊科技（深圳）有限公司運營開發leader王鎮做了以《基礎網絡devops的最佳實踐》為主題的精彩演講。
我是來自騰訊的王鎮，給大家的主題是《基礎網絡devops的最佳實踐》，我講的內容跟前兩位同事分享的有點不一樣。我們對于基礎架構的運營系統一般都會分南向和北向兩塊，前面兩位講的更多是南向跟設備相關的這些內容，我下面的分享主要是北向跟上層業務，基礎架構是干什么的？上面跑了很多應用也是運營系統需要對接起來的，今天主要跟大家分享基礎網絡的運營系統怎么去做devops。
一、首先有一個問題：為何需要devops？
devops并不是一個很新的概念，騰訊基礎架構運營系統發展過程經歷了剛開始時候的人工、腳本、工具化、自動化，現在逐步邁入到數據化階段，在devops發展過程中根據自身的運營經驗和實踐去決定了devops可能是解決當前突出矛盾的一個比較好的方式。
總結過去有哪些比較突出的矛盾？
1、運營需求總是層出不窮，但每個運營需求提出之后，后面專業的開發總是要花比較多時間，因為開發過程有自己固有的規律，不可能今天提這個需求，明天就把開發功能放到線上去了，它后面要經過需求分析、代碼編寫、測試、持續維護的過程，過程時間非常長，肯定是沒法去滿足層出不窮的上層需求。
2、運營和開發是兩個團隊，他們之間的專業背景、知識以及所面臨的問題是不一樣的，有這樣的矛盾存在。
3、騰訊過去幾年在云業務或云網絡業務已經快速發展，我們除了內部海量用戶外，還有些騰訊云公有云業務，2年開始對外開放，私有云客戶逐步加入進來，我們對應基礎架構運營系統服務的對象逐步豐富了，需要運營系統具備二次開發能力，這樣devops的需求也慢慢展現出來了。
二、如何理解devops？
devops并不是一個新技術，這是國內一個前輩根據過去多年經驗所總結出來的一個devops標準分級模型，有1-5級，通過了國際化標準認證。devops沒有帶來新技術，所有技術都可以在devops開發模式里應用出來，主要目的是為了提升應用開發效率，解決上頁所提到的三個主要矛盾，解決的方式是以人為本，解決運營和開發供需的矛盾，從人性出發去解決深層次挑戰。
這是devops應用開發的現狀，是devops開發現有的成果，分兩方面：第一，devops的應用，是去運營服務器、運營網絡、運營基礎數據中心的這些運維人員自己在devops平臺上所開發的上層應用。第二，基礎應用，原有專業開發基于同一套平臺上做的應用開發。這樣傳統的運營跟開發都基于同一套devops平臺互相做融合，踐行了一句話——“吃自己的狗糧”，怎么理解這句話？它有兩方面含義：對于運營同學來說，把自己的需求落實到devops平臺里，devops平臺出來上層有什么問題，他首先會從自身層面出發會反思這些需求或者業務邏輯是不是有問題，對專業開發人員會看同一個devops平臺開發應用出了問題之后，是不是哪些功能沒有完善、哪些地方出了bug，雙方會從自身角度去完善已知問題，雙方關系會越來越融洽，說明了怎樣以人為本。
devops最關鍵的前提是要把我們的運營事務流程化，過去去騰訊內部工具化、自動化、數據化繞不開的一個前提是把所有的運營事務流程化，我們把過去騰訊那么多年的經驗做了總結，整理成這樣5個級別，我們現在大概處在level3級別，level3的重要參考依據是：1、體系化，所有運營事務都有對應流程跟它一一匹配，做到“無流程不運營”狀態，杜絕很多線下操作的環節，如果大家對資產這塊線下操作，現場更換硬盤或設備板塊，如果沒有線上流程對接，很可能換的這個板卡跟型號對接不起來，帶來比較多的問題。
2、部分流程完成生命周期管理，為什么要講生命周期？流程上線之后如果沒有持續維護，久而久之，流程可用性和穩定性就得不到保證了。
3、完善ola/sla的管理，每個流程有自己的可執行時間，每個任務節點需要有預定完成時間，這里從數據化層面把流程做到可運維。
4、工具快速敏捷迭代，這涉及到二次開發能力，我們運營系統不單是服務內部，很有可能有非常多外部客戶，特別是小型私有云客戶也需要用到。右手邊是展示了我們把運營事務集中，業務邏輯落地到流程圖的方式展現出來，這是其中一個例子。
三、如何建設devops系統？
我們應用了一個ddd模式自上而下去設計devops平臺基礎模塊，重點關注ddd領域層。建立devops平臺，主要有四個大模塊需要建立起來：
第一塊，流程可編排。右手邊有個流程圖，運營人員根據自己日常運營需求把業務邏輯用流程圖的方式編排出來，編排過程需要提供流程畫布，讓大家通過上層業務邏輯通過流程圖展現出來。
第二塊，每個流程圖有很多任務節點，每個任務節點只是擺在那里而已，它的工作是什么呢？它底層有個任務管理、應用管理模塊去實現這里面具體的任務節點。
第三塊，數據運營。每個流程建立起來之后，怎么知道這個流程執行的效果如何？歷史流程執行效率怎樣？運營事務當前能力成熟度怎樣？都需要在我們流程里提取數據做事后分析，意思是我們可以做個數據化的運營。這里面依賴重要一點，運營節點里面需要有非常細的打點信息，打點信息回來之后形成歷史數據積累，后面做數據化運營工作就非常便利了。
第四塊，異常管理。異常管理是做devops監控的，devops平臺可以用來監控基礎設施，但是devops平臺本身也需要一個監控，我怎么知道這個平臺當前運營的狀態怎樣、它的健康度有沒有受損？所以這里有個異常管理模塊。
四、我們如何建設devops系統？
devops平臺也分南向和北向，從南到北分三個層次：
第一層，面向設備命令模板。把很多設備的硬件建模、配置都做成一個模板的形式，這樣就可以減少網絡運營人員對于不同廠商設備需要去定制很不一樣的命令參數，這些很不一樣的命令參數都以模板形式封裝起來了。
第二層，業務函數。
第三層，業務流程。業務函數和業務流程都是跟上層應用相關的，這里我們不是用模板形式把它封裝起來，而是從軟件開發角度用sdk方式把它包裝起來。如果很多業務函數、業務流程如果具有是復用性的，都做成sdk的方式封裝起來，并且通過標準化接口在sdk里暴露出來，而且這個sdk里具備服務發現的功能。
總體一個原則，設備和業務邏輯都需要經過抽象和標準，盡可能減少開發代碼的寫入，這里有個標題叫“無代碼化開發”，并不是說一行代碼都不寫，而是說盡量以可配置、可復用模式減少寫代碼的工作量，因為畢竟運維人員不是專業的開發，他們想用拖拽或者可配置的方式把業務邏輯通過這個流程接起來。
建設devops系統有一個開發生命周期的管理，開發工作要經歷幾個步驟？第一，做需求管理，第二，寫代碼開發，第三，做流程管理、任務調度管理、異常管理，這里內容比較多，我就開發管理模塊具體來講，因為這塊是跟運維同學打交道最多的地方。接到一個開發需求之后提供一個便捷的ide，就是在哪里寫這個代碼，剛開始c 有一個，現在寫python也有，但這些比較專業的id工具都有上手的門檻，使用id工具以培訓課程的方式推薦給大家做些宣導。代碼寫完之后做代碼管理、單元測試、持續集成、持續部署，這些配套的過程都需要建立起來，這些在我們內部已經有很成熟的管理體系了，我們借用業界成熟的通用組件和內部高效的組件，可以快速把devops平臺這幾個模塊搭建起來。
devops系統建立起來怎么部署？剛開始只有一套部署方式是內部docker化部署，但是這幾年devops平臺在騰訊云外部私有云用戶里也有部署，所以我們也做了單機部署的方式，總體原則是希望devops平臺做到簡單可依賴，而且接口可以開放出來提供底層能力，這當然要根據用戶具體需求，到底它是需要底層設備的掌控能力？還是需要底層設備的流量 數據？我們開放出來，基礎信息已經抽象提煉好放到統一的存儲空間里，有標準化的http接口對外提供出來，都是可以按需去提取的。devops平臺沒有任何一個界面，界面方式是由各個終端用戶自己去定制的，我們提供的是標準化的api接口。
再講講運維devops平臺相關的產品化控制臺。除了要面向多用戶，剛開始運營系統是面向開發人員，但是后面除了開發人員外，還有運營人員也需要開放這個能力。第二塊，底層能力，流程圖流程跑的情況怎樣、任務調度管理線程怎樣、權限管理，這些都需要開放出來，讓上層運營人員可定制的方式進行迭代，盡量減少專業開發人力的投入。
這里我們設計了一個培訓認證體系。devops平臺具備一定的門檻，不是新人進來花一兩周時間就能接觸到devops平臺或者基于devops平臺開發上層應用，所以我們會有培訓體系，完成開發知識基礎課程、devops功能開發、demo流程實戰之后會給他上崗證，根據不同層次、不同級別頒發證書。例如有些同學只是寫寫硬件模板、設備模板、配置模板，有不同級別分別去頒發。還有些高階的同學從南到北，從上層應用到設備的命令模板都可以處理好，這種給他頒發級別比較高的證書。
五、devops平臺最差實踐
既然devops有最佳實踐，也有最差實踐，過程中并不是一帆風順的，總結過程中的兩方面：
第一，我們做得不夠的地方。例如研發效率低下，例如有些同學介入開發之后在本地開發時由于網絡策

B2C網站運營數據
阿里阿里云服務器ecs
域名未來發展趨勢如何？域名有怎樣的前景？
根據需要我需要將該域名過戶給周鴻靜先生
我注冊的賬戶里面已經充上費用了
云虛機
淺談微信商城系統如何運營
你對租用游戲服務器的方式了解多少？