資訊專欄INFORMATION COLUMN
摘要：資源包括什么內存磁盤網絡文件描述符外部緩存數據庫等，編程語言是如何管理資源的合理的算法架構保證了資源的合理使用，分配內存使用網絡等等。
在云計算時代，開發和運維的結合變得越來越重要。在DIFF論壇第一期，前新浪SAE運維主管，鄭志勇，分享了《一個開發眼中的運維》根據自己從開發人員轉型運維之后的心得，談如何把在開發上的運用抽象思維方式運用到運維領域。
運維不是打雜的，運維不是客服，運維也不是服務開發的，但要做好合作。
2. 運維是什么？運維服務于整個產品，保證架構合理，系統穩定。運維只對業務穩定負責，所有的工作都是奔著這個去的。
3. 你如何寫程序，寫程序的目的是什么？程序是為了完成特定的功能。為了完成特定的功能，程序需要申請資源、使用資源、管理資源，功能完成后，還要釋放資源。說到底，就是跟資源打交道，和資源打交道的工具是“編程語言”。
資源包括什么？內存、CPU、磁盤、網絡、文件描述符、外部API、緩存、數據庫等，編程語言是如何管理資源的、合理的算法/架構保證了資源的合理使用，malloc/free分配內存、connec、close使用網絡等等。
正確的程序算好程序。
邏輯正確，使用資源盡可能的少；
沒有bug，沒有把機器資源耗盡；
穩定性好，不會異常退出；
可用性高，有HA方案，不會因為一臺機器（或一個進程）無法提供服務，而影響整個系統的服務；
沒有單點是基本要求；
容易擴展，只需要簡單的增加資源（CPU、內存、磁盤、機器等）就行，不需要太多人工遷數據、修改配置等；
容易維護，包括容易配置、容易部署、容易監控等。
5. 如何寫出好程序？什么樣的程序不出錯？代碼少的程序錯誤少，邏輯簡單的程序錯誤少，需要管理的資源少的程序錯誤少。要復用代碼，減少代碼的數量。
要抽象，分層，內聚，解藕，簡化邏輯，隔離資源，才能簡化邏輯，隔離資源，限制錯誤。
沒有持久狀態的程序好擴展，沒有持久狀態意味著上下線機器不需要遷移數據。沒有狀態的程序也很容易做HA方案。
配置簡單，日志豐富，能提供程序狀態查詢的程序好運維。
但程序不可能沒有數據，通過集中管理數據庫，讓數據盡量只讀，預加載數據等手段隔離邏輯和數據，也能讓擴展變的容易。
6. 系統是什么？系統是我們運維的目標，不了解系統是什么，就不知道如何運維。
系統是網絡，是機器，是程序。是把網絡，機器，程序組織起來的架構。
機器角色應該是盡量單一的，架構應該是數據流簡單的，基礎業務服務化的。
系統是動態的，運維系統首先考慮的不是當下成本，而是系統變更（擴容，上下線機器）的成本。
運維必需是簡單的，要考慮的一個新手，如何能盡快上手工作，而不是冗長的文檔和復雜的培訓。
7. 寫程序和做運維是類似的，甚至一樣的！程序提供單一功能，而運維搭建，維護的系統提供全部的功能，開發人員開發的程序只是整個系統的一個部分。從某個角度說，開發人員做的事情越少，系統越容易穩定，因為開源的總是更靠譜。這是減少代碼，也是復用。
但運維卻理應比開發更不容易犯錯，因為運維只需要管理資源，而不需要應對復雜的業務邏輯。
這是個矛盾，因為開發負責的復雜業務邏輯，是運維負責的系統的一部分，前者不穩定，后者也別想消停。
所以運維不懂開發，至少要懂如何控制復雜度，如何隔離故障，如何服務降級。出色的運維人員，只要精通一門語言，必然也是出色的開發（反之亦然）。但什么是出色的運維呢？大部分運維人員，只是一個熟練的操作工人。出色的運維必然更了解系統（原理），這要讀很多書，做很多思考，有很多實踐。
只看這個cat bigfile.txt | parallel --pipe wc -l | awk "{s+=$1} END {print s}"你能不能想出parallel加速的原理是什么？
CPU高意味著什么？你是不是應該先問問是sys，user，iowait這三個的哪個高？是單個CPU高，還是整體都搞？
你是否了解有的程序CPU使用率90%就有問題了，而有的350%了還沒問題？
load高意味著cpu高嗎？內存耗盡導致load高的原理是什么？內存耗盡回導致io高嗎？
9. 是否正確的監控了資源？監控了磁盤使用率，是不是也監控了磁盤的io能力，raid卡呢？磁盤損壞呢？監控了網卡使用率，是不是也監控了丟包率？
10. 資源是否一定對應硬件？CPU，內存，磁盤，帶寬都有對應的硬件，那些沒有硬件對應的資源呢？文件描述符，端口數，進程數是不是資源？
路由表，iptables，cron是不是資源？
MySQL主從，第三方REST接口是不是資源？
11. 為什么要盡量把一切抽象為資源？還記得剛才說程序要講抽象么，為什么linux一切皆文件？一切運維對象都抽象為資源后，就可以用盡量統一的方法來管理（配置，監控）。
如果新上線一臺機器無比容易，為什么還要費盡修復刪除的/usr目錄呢，把它當成新機器重做上線就行了。
線上變更必需走配置管理。線上系統對任何人應該是只讀的，只有配置管理程序有權寫。這樣保證了，變更是可重復的，可復制的。手工加路由，手工修改文件權限，手工配置ip，手工配置nfs，手工起虛擬機等等。一切在線上手工做的操作，于團隊都是無益的，因為團隊失去了一次改進配置管理的機會。任何操作不是想我就這一臺機器，而是想我有1000臺機器怎么辦。
上線業務必需先問，如何保證HA，如何擴展，如何運維/監控。這三個問題不解決，謹慎上線，當然上線必需使用配置管理上線。
隔離復雜度，要簡化，抽象。抽象指角色抽象。運維眼中沒有計數用的mc，和緩存用的mc，運維眼中只有mc，于是所有的mc都來自mc池，mc池通過puppet配置，創建mc的過程編程了簡單的
puppet配置。一旦把自己管理的所有業務抽象/分拆為幾種有限的“業務”，緩存、mysql、httpd等，一切就簡單了。例如我們有緩存池、數據庫池、redis池、httpd池。（參考:4、5）
先解決問題，然后是以后如何避免此類問題，后者更重要。
不犯第三次錯誤（重復的問題不出現第三次）。第一次算不知道，第二次算不小心，第三次特么是故意的吧。如果每個問題都能徹底有效解決（最終落實到配置變更和監控），問題就會越來越少。
時刻思考如何“偷懶”，運維越清閑，系統越穩定。
13. 配置管理是如何管理資源的？包，所有線上的軟件/腳本都是通過(rpm)包管理的。
文件，所有的變更“持久化”都是通過文件。程序的配置文件，sysctl，iptables，route，cron等凡是能用配置文件控制的一切。
進程，所有的進程都是用配置管理啟動的，或者通過配置管理寫文件到系統啟動目錄，例如rc3.d。
你能相到的一切，無論是配置keepalived，還是添加用戶，都抽象為這三個。如果不能抽象為這三個，請再思考兩個小時。
如果系統可以由這三者全部控制，而這三者又全部寫入了配置管理，這意味著按照配置管理配置出來的系統就一定是對的。擴容，升級，機器的上線，下線從此該有多容易。而運維人員，可以通過配置管理，一覽整個系統，通過持續改進的模板，配置更容易學習，不容易出錯。
的正確性，業務響應時間也要同等關注的。
基礎監控要全面，但不一定實時報警。如果業務不受影響，又何必半夜起來處理宕機呢？如果業務有問題，全面的監控會幫你發現問題的蛛絲馬跡。
如果memcache偶爾響應慢，你怎么能想到是swap導致的呢？全面的監控可以幫你發現這一點。把業務邏輯抽象為資源，可以統一業務監控和基礎監控。（監控如何算全面，參考8、9）
運維技巧重裝操作系統，使用puppet重新配置，是系統恢復到正確狀態的最佳途徑。理論上，新裝的機器使用puppet配置后一定是能用的，否則，就是puppet寫的有問題。
區分無狀態的機器和有狀態的機器，盡量把狀態集中，然后集中精力運維這些有狀態的機器。
寧可通過網絡把狀態集中也要盡量讓機器避免有狀態，無狀態的機器非常好運維。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/7889.html
摘要：虎牙直播運維負責人張觀石張觀石，擁有余年網站開發架構運維經驗目前關注互聯網服務可靠性系統工程運維平臺的規劃建設網站高可用架構等方面在音視頻傳輸質量評估微服務運維方面積累了豐富的經驗。 showImg(https://segmentfault.com/img/bVbjqGq); 虎牙直播運維負責人張觀石 張觀石，擁有10余年網站開發、架構、運維經驗；目前關注互聯網服務可靠性系統工程、運維...
摘要：本文是根據虎牙直播運維負責人張觀石月日在攜手魅族百度云主辦的第十三期魅族開放日虎牙直播平臺實踐演講中的分享內容整理而成。英雄聯盟是全球最大的電子競技賽事，目前正在如火如荼進行，從今天開始進入了總決賽的淘汰賽階段了。 showImg(https://segmentfault.com/img/bVblQM9?w=1080&h=720); 本文是根據虎牙直播運維負責人張觀石10月20日在ms...
摘要：作者介紹王藝，百度云智能運維架構研發負責人。年轉向運維方向，作為智能運維架構方向的技術負責人，致力于為百度智能運維平臺和產品提供高性能高可用可擴展的系統架構和基礎設施。持續的數據建設，是智能運維建設的關鍵。 作者介紹王藝，百度云智能運維架構研發負責人。2010年加入百度，先后負責百度鏈接庫、百度志愿計算、百度統一資源管理的研發，經歷過千億級網頁鏈接的洗禮，也調度過數十萬量級的服務器，熱衷于直...
摘要：當云平臺出現網絡故障系統故障等問題，這對云租戶用戶有時甚至是致命的，所以不少是由高級別開發人員轉型而來。目前國內各大云廠商也基本都提供了應用運維平臺，包括騰訊藍鯨阿里華為等。 DevOps 全鏈路 下圖是我們熟知的軟件研發環節，在迭代頻率高的研發組織里，一天可能要經歷多次如下循環。對于用戶群體龐大或者正在經歷大幅業務擴張的企業研發組織，除了重點關注應用的快速上線之外，如何保障應用的高可...
閱讀 892·2021-10-13 09:39
閱讀 1481·2021-10-11 10:57
閱讀 2589·2019-08-26 13:53
閱讀 2538·2019-08-26 12:23
閱讀 3680·2019-08-23 18:30
閱讀 3745·2019-08-23 18:08
閱讀 2524·2019-08-23 18:04
閱讀 2959·2019-08-23 16:28
