一個開發眼中的運維

在云計算時代，開發和運維的結合變得越來越重要。在DIFF論壇第一期，前新浪SAE運維主管，鄭志勇，分享了《一個開發眼中的運維》根據自己從開發人員轉型運維之后的心得，談如何把在開發上的運用抽象思維方式運用到運維領域。

1. 運維不是什么？

運維不是打雜的，運維不是客服，運維也不是服務開發的，但要做好合作。

2. 運維是什么？

運維服務于整個產品，保證架構合理，系統穩定。運維只對業務穩定負責，所有的工作都是奔著這個去的。

3. 你如何寫程序，寫程序的目的是什么？

程序是為了完成特定的功能。為了完成特定的功能，程序需要申請資源、使用資源、管理資源，功能完成后，還要釋放資源。說到底，就是跟資源打交道，和資源打交道的工具是“編程語言”。
資源包括什么？內存、CPU、磁盤、網絡、文件描述符、外部API、緩存、數據庫等，編程語言是如何管理資源的、合理的算法/架構保證了資源的合理使用，malloc/free分配內存、connec、close使用網絡等等。

4. 什么樣的程序算好程序？

正確的程序算好程序。

• 邏輯正確，使用資源盡可能的少；

• 沒有bug，沒有把機器資源耗盡；

• 穩定性好，不會異常退出；

• 可用性高，有HA方案，不會因為一臺機器（或一個進程）無法提供服務，而影響整個系統的服務；

• 沒有單點是基本要求；

• 容易擴展，只需要簡單的增加資源（CPU、內存、磁盤、機器等）就行，不需要太多人工遷數據、修改配置等；

• 容易維護，包括容易配置、容易部署、容易監控等。

5. 如何寫出好程序？

什么樣的程序不出錯？代碼少的程序錯誤少，邏輯簡單的程序錯誤少，需要管理的資源少的程序錯誤少。要復用代碼，減少代碼的數量。

• 要抽象，分層，內聚，解藕，簡化邏輯，隔離資源，才能簡化邏輯，隔離資源，限制錯誤。

• 沒有持久狀態的程序好擴展，沒有持久狀態意味著上下線機器不需要遷移數據。沒有狀態的程序也很容易做HA方案。

• 配置簡單，日志豐富，能提供程序狀態查詢的程序好運維。

• 但程序不可能沒有數據，通過集中管理數據庫，讓數據盡量只讀，預加載數據等手段隔離邏輯和數據，也能讓擴展變的容易。

6. 系統是什么？

• 系統是我們運維的目標，不了解系統是什么，就不知道如何運維。

• 系統是網絡，是機器，是程序。是把網絡，機器，程序組織起來的架構。

• 機器角色應該是盡量單一的，架構應該是數據流簡單的，基礎業務服務化的。

• 系統是動態的，運維系統首先考慮的不是當下成本，而是系統變更（擴容，上下線機器）的成本。

• 運維必需是簡單的，要考慮的一個新手，如何能盡快上手工作，而不是冗長的文檔和復雜的培訓。

7. 寫程序和做運維是類似的，甚至一樣的！程序提供單一功能，而運維搭建，維護的系統提供全部的功能，開發人員開發的程序只是整個系統的一個部分。

• 從某個角度說，開發人員做的事情越少，系統越容易穩定，因為開源的總是更靠譜。這是減少代碼，也是復用。

• 但運維卻理應比開發更不容易犯錯，因為運維只需要管理資源，而不需要應對復雜的業務邏輯。

• 這是個矛盾，因為開發負責的復雜業務邏輯，是運維負責的系統的一部分，前者不穩定，后者也別想消停。

所
以運維不懂開發，至少要懂如何控制復雜度，如何隔離故障，如何服務降級。出色的運維人員，只要精通一門語言，必然也是出色的開發（反之亦然）。但什么是出
色的運維呢？大部分運維人員，只是一個熟練的操作工人。出色的運維必然更了解系統（原理），這要讀很多書，做很多思考，有很多實踐。
只看這個cat bigfile.txt | parallel –pipe wc -l | awk “{s+=$1} END {print s}”你能不能想出parallel加速的原理是什么？

8. 你是否了解你運維的資源？

• CPU高意味著什么？你是不是應該先問問是sys，user，iowait這三個的哪個高？是單個CPU高，還是整體都搞？

• 你是否了解有的程序CPU使用率90%就有問題了，而有的350%了還沒問題？

• load高意味著cpu高嗎？內存耗盡導致load高的原理是什么？內存耗盡回導致io高嗎？

9. 是否正確的監控了資源？

監控了磁盤使用率，是不是也監控了磁盤的io能力，raid卡呢？磁盤損壞呢？監控了網卡使用率，是不是也監控了丟包率？

10. 資源是否一定對應硬件？

• CPU，內存，磁盤，帶寬都有對應的硬件，那些沒有硬件對應的資源呢？文件描述符，端口數，進程數是不是資源？

• 路由表，iptables，cron是不是資源？

• MySQL主從，第三方REST接口是不是資源？

11. 為什么要盡量把一切抽象為資源？

還記得剛才說程序要講抽象么，為什么linux一切皆文件？一切運維對象都抽象為資源后，就可以用盡量統一的方法來管理（配置，監控）。
如果新上線一臺機器無比容易，為什么還要費盡修復刪除的/usr目錄呢，把它當成新機器重做上線就行了。

12. 運維原則:

1. 線
   上變更必需走配置管理。線上系統對任何人應該是只讀的，只有配置管理程序有權寫。這樣保證了，變更是可重復的，可復制的。手工加路由，手工修改文件權限，
   手工配置ip，手工配置nfs，手工起虛擬機等等。一切在線上手工做的操作，于團隊都是無益的，因為團隊失去了一次改進配置管理的機會。任何操作不是想我
   就這一臺機器，而是想我有1000臺機器怎么辦。

2. 上線業務必需先問，如何保證HA，如何擴展，如何運維/監控。這三個問題不解決，謹慎上線，當然上線必需使用配置管理上線。

3. 隔離復雜度，要簡化，抽象。抽象指角色抽象。運維眼中沒有計數用的mc，和緩存用的mc，運維眼中只有mc，于是所有的mc都來自mc池，mc池通過puppet配置，創建mc的過程編程了簡單的
   puppet配置。一旦把自己管理的所有業務抽象/分拆為幾種有限的“業務”，緩存、mysql、httpd等，一切就簡單了。例如我們有緩存池、數據庫池、redis池、httpd池。（參考:4、5）

4. 先解決問題，然后是以后如何避免此類問題，后者更重要。

5. 不犯第三次錯誤（重復的問題不出現第三次）。第一次算不知道，第二次算不小心，第三次特么是故意的吧。如果每個問題都能徹底有效解決（最終落實到配置變更和監控），問題就會越來越少。

6. 時刻思考如何“偷懶”，運維越清閑，系統越穩定。

13. 配置管理是如何管理資源的？

1. 包，所有線上的軟件/腳本都是通過(rpm)包管理的。

2. 文件，所有的變更“持久化”都是通過文件。程序的配置文件，sysctl，iptables，route，cron等凡是能用配置文件控制的一切。

3. 進程，所有的進程都是用配置管理啟動的，或者通過配置管理寫文件到系統啟動目錄，例如rc3.d。

你能相到的一切，無論是配置keepalived，還是添加用戶，都抽象為這三個。如果不能抽象為這三個，請再思考兩個小時。
如果系統可以由這三者全部控制，而這三者又全部寫入了配置管理，這意味著按照配置管理配置出來的系統就一定是對的。擴容，升級，機器的上線，下線從此該有多容易。而運維人員，可以通過配置管理，一覽整個系統，通過持續改進的模板，配置更容易學習，不容易出錯。

監控

1. 的正確性，業務響應時間也要同等關注的。

2. 基礎監控要全面，但不一定實時報警。如果業務不受影響，又何必半夜起來處理宕機呢？如果業務有問題，全面的監控會幫你發現問題的蛛絲馬跡。

如果memcache偶爾響應慢，你怎么能想到是swap導致的呢？全面的監控可以幫你發現這一點。把業務邏輯抽象為資源，可以統一業務監控和基礎監控。（監控如何算全面，參考8、9）

運維技巧

1. 重裝操作系統，使用puppet重新配置，是系統恢復到正確狀態的最佳途徑。理論上，新裝的機器使用puppet配置后一定是能用的，否則，就是puppet寫的有問題。

2. 區分無狀態的機器和有狀態的機器，盡量把狀態集中，然后集中精力運維這些有狀態的機器。
   寧可通過網絡把狀態集中也要盡量讓機器避免有狀態，無狀態的機器非常好運維。

文章來源：http://mp.weixin.qq.com/s?__biz=MjM5NzU0MzU0Nw==&mid=204904538&idx=1&sn=9766898fa2f11582c630f8b33c0697cb#rd