乾貨丨運維圈必讀10篇精選技術文章

 

InfoQ 是一個關注中高階技術人的社群媒體

——追蹤技術圈新聞熱點時事深度解讀；

圈點行業內KOL觀點灼見；

聚焦技術領域中的360行；

不斷豐富、改變、突破著的為技術人呈現的內容矩陣。

現在向大家推薦10篇優秀文章，這些文章來自微信公眾號InfoQ，如果您對各類技術感興趣，推薦關注微信公眾號：InfoQ。

長按識別二維碼可輕鬆關注 InfoQ

 

1、騰訊遊戲業務運維實踐分享

塗彥，騰訊互動娛樂運維總監：2005 年進入網路遊戲行業， 長期從事遊戲運維一線支撐服務與團隊管理工作，在遊戲運維領域有豐富的實戰經驗。2010 年加入騰訊遊戲，親歷公司遊戲業務和運維團隊的高速增長並深度參與主導了運維轉型、遊戲雲平臺建設、運維四化實踐等關鍵專案，對遊戲運維發展有深刻的理解。目前正在努力推動網際網路行業運維標準的制定工作。

運維們在遊戲雲平臺上源源不斷地將技術方案與產品運營相結合， 在標準化、自動化、服務化、產品化的運維理念影響下，通過藍鯨平臺將運維的服務能力持續覆蓋騰訊遊戲300+業務。在實踐過程中我們深深體會到，運維服務對於產品運營的重要性以及對於運維未來發展的關鍵性。此次論壇希望通過騰訊遊戲運維服務能力實踐分享，與大家一起探討運維發展未來與運維標準建設。

掃描二維碼關注 InfoQ 公眾號後，傳送數字 101 即可閱讀原文。

 

2、OPPO服務化架構系統監控難題解決方案

眾所周知，系統監控一直是擁有複雜IT架構的企業所面臨的一個重要問題，而這也並不是每家企業都能夠輕鬆解決的技術挑戰。OPPO後端系統規模近幾年快速發展，系統重構以後採用了服務化的架構，各系統之間耦合降低，開發效率得到了很大的提升。然而在服務化帶來了好處的同時，難於監控的問題也一併出現。

為了解決這些問題，OPPO公司自行開發了一套監控系統，並結合第三方監控系統，形成了從App請求開始到後端處理過程的完整監控體系。OPPO監控系統的簡稱為OMP(OPPO Monitor Platform)，歷時半年開發，分為兩期上線，現在已全面接入OPPO線上專案。 

掃描二維碼關注 InfoQ 公眾號後，傳送數字 102 即可閱讀原文。

 

3、運維的本質：視覺化

沒有比“視覺化”更好的一個詞能概括運維的本質，而“視覺化”又應該分成兩部分：視覺化的服務交付和視覺化的服務度量！

對於運維來說，提供一種高效、一致性、透明化、面向使用者的服務是運維的價值所在，這樣就要求運維遮蔽其提供的服務背後的所有實現細節。運維的自動化最終要實現視覺化，複雜的運維工作流必須通過視覺化來表達，視覺化後的自動化才能讓所有人理解一致、執行一致、結果一致。

“除了上帝，一切人都必須用資料說話”，這是運維人員必須恪守的信條。資料的視覺化能力非常重要，需要在面向整體和麵向某個業務流上都有實現。視覺化的能力就代表了運維的能力，視覺化的程度越高，運維的能力越高。那麼你現在到底視覺化了哪些運維服務，並能進行度量呢？

掃描二維碼關注 InfoQ 公眾號後，傳送數字 103 即可閱讀原文。

 

4、運維2.0，危機前的自我拯救

運維的今天，內憂外患。運維危機，已非盛世危言、或譁眾取寵。

怎麼辦？暴風雨和奇點同時逼近，而運維的分化，或許只是時間的問題。

為此，我提出新觀點：運維2.0——這也是運維最後的機會。

運維好比是池塘裡的魚，不管水域大小，都有一塊自留地。但某天，突然來了一頭鯨魚，目標不是魚而是水…… 所以運維的任務需隨之而變——在水被吸乾之前，提前上岸。

運維2.0，就是那個帶我們跳出池塘投身大湖的武器。

掃描二維碼關注 InfoQ 公眾號後，傳送數字 104 即可閱讀原文。

 

5、雲端計算時代的資料庫運維體系

通過對比企業資料庫運維模式和雲資料庫（以下簡稱RDS）的運維區別，說明在雲端計算時代，運維變成了一種服務，作為公共計算服務的一部分服務於廣大企業。這時候雲資料庫運維面臨的機會和挑戰。

陳長城, 阿里技術保障 資料庫高階專家, 2008年慕名加入淘寶DBA團隊，成為一名專職Oracle DBA，兩年後作為淘寶去IOE的主要實施人，對淘寶核心系統的資料庫架構進行改造，經過3年架構演變，完成去IOE。之後著手建設統一的資料庫自動運維平臺DBFree，不斷迭代至今。支撐了歷年的雙11大促，和去年的異地多活架構，滿足異地多IDC同時進行交易。 一直負責阿里集團資料庫基礎技術，2014年同時負責阿里雲資料庫的基礎運維，喜歡在工作中探索新的模式，通過運維繫統和生產系統的有機結合，讓運維工作智慧化，DBA經驗服務化。

掃描二維碼關注 InfoQ 公眾號後，傳送數字 105 即可閱讀原文。 

 

6、1號店自動化運維構建

運維自動化是目前熱門的研究領域，我們以1號店的運維實踐作為依據，首先介紹1號店運維自動化的基礎平臺CMDB的架構和應用，然後在此基礎上介紹運維自動化核心子系統構的構建及系統間的整合，突出講解一下目前流行的puppet的特點以及整合。

希望我們通過以下的內容分享，幫助大家少走彎路： 運維自動化的規劃和架構。 1號店運維大閉環及3大核心閉環。 伺服器下層閉環。（購買到進資源池前） 伺服器上層閉環。（上架到回收） 業務閉環。（業務變更） CMDB的構建及心得。 運維自動化產品puppet的選型及和CMDB的整合與應用。

掃描二維碼關注 InfoQ 公眾號後，傳送數字 106 即可閱讀原文。

 

7、海量線上交易背後的運維監控體系建設

每天，在攜程網上都有巨量的線上旅遊交易發生，而其背後有一個相當複雜的軟體體系和基礎設施在支撐。伴隨業務的飛速發展，生產環境的釋出越來越頻繁，基礎架構的變更也越來越密集，網站穩定性面臨從所未有的挑戰。

從去年開始，新的監控體系開始被打造，從人員組織，工具開發，流程定義上都不斷改進和磨合。如今監控工具已經能做到先於人發現網站問題，為故障恢復爭取了時間，成為提高網站可用性的利器。在此基礎上，我們還開發了監控工具的移動端，使得網站支援人員能夠方便快捷的檢視系統報警和關鍵監控資料，進一步縮短網站故障時間。

本次分享主要介紹攜程網的監控體系打造的思路，提高監控有效性採取的一些方法和工具，並展望攜程監控平臺一體化，移動化的未來發展方向。

掃描二維碼關注 InfoQ 公眾號後，傳送數字 107 即可閱讀原文。

 

8、趕集運維之九天探月

崔華，趕集網高階技術經理、自動化運維專家.趕集網運維平臺負責人，近10年運維及開發經驗，2011年加入趕集，一直致力於自動化運維建設，經歷了“阿波羅平臺”誕生變遷的全過程。負責管理應用運維團隊，對服務層運維方面提供保障，同時推進運維標準化及規範化；曾任完美世界運維平臺開發負責人，具有豐富的自動化運維專案開發和管理經驗。 

面對亂象叢生的開發模式，面對複雜多變的業務場景，面對眾 多紛雜的系統平臺，趕集運維挑戰重重； 從無到有，從小到大，由分散到整合，由無序到流程。。。還有我們正在由工具走向平臺化的今天； 我們經歷了重構甚至推翻重搞，經歷了數不清的從黎明到黑暗， 又從黑暗到黎明， 經歷了使用者的無數吐槽與點贊，經歷了太多太多。 如何目睹起飛的過程？ 如何清晰地看到那一輪明月？ 希望能夠通過這些“經歷”來和大家一起分享“趕集阿波羅平臺”的前身今世，以及我們規劃建造這個“飛船”時 遇到的坑和得到的贊。

掃描二維碼關注 InfoQ 公眾號後，傳送數字 108 即可閱讀原文。

 

9、招商銀行故障處理實踐——應急標準化方法論

張春林，招商銀行資料中心技術管理室主管，十二年金融業IT運維從業經驗，涉足的專業領域包括基礎網路運維、應用交付運維、業務連續性管理、自動化運維管理、技術架構管理，曾負責招商銀行重要系統災備建設專案、招商銀行總行負載均衡專案、招商銀行分行負載均衡專案、應急管理專案等，在負載均衡技術、高可用架構、災備和應急管理、自動化運維等領域積累了豐富的實戰經驗，曾被邀請在F5使用者大會發表演講。

對於大型商業銀行而言，由於業務對資訊系統的依賴，資訊系統的可用性成為關係到財務收益和聲譽風險的重要因子，而應急處置效率又是影響可用性的關鍵因素之一。如何快速有效地處置突發事件，既是商業銀行的內在管理需要，也是外部監管要求。本文通過定性和定量結合的方式，全面分析可能影響應急處置效率的各個環節和要素，提出了提升應急處置效率的方法，並基於分析結果和筆者實踐，總結了一套應急標準化方法論，可為聽眾起到拋磚引玉、開拓思路的作用。

掃描二維碼關注公眾號後，傳送數字 109 即可閱讀原文。

 

10、小米運維架構師談運維自動化實踐之路

這裡的自動化主指自動化部署，它涵蓋的範圍很廣泛，包括搭環境、修改配置、線上升級、擴容、遷移，以及帶來的所有關聯變更等等。 部署系統一直作為運維基礎設施的核心元件，緊密的將監控、名字服務、配置管理等關聯起來。 對於持續整合，配合hudson和本地部署工具，可以串聯整個軟體生命週期的自動化；對於服務穩定性來說，可以通過資源隔離及增加排程來自動運維服務，提高服務可用性。

伏曄，小米運維架構師，微博: @幸福哥V，從事網際網路運維8年，曾在百度負責自動化運維專案及擔任運維技術委員會主席。2013年加入小米，任職運維架構師，負責應用運維及運維自動化工作。 

掃描二維碼關注 InfoQ 公眾號後，傳送數字 110 即可閱讀原文。

 

更多幹貨文章，請掃描下方二維碼關注 InfoQ 公眾號：