《一個開發眼中的運維》要點：
本文介紹了一個開發眼中的運維，希望對您有用。如果有疑問，可以聯系我們。

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

1. 運維不是什么?

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

2. 運維是什么?

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

3. 你如何寫程序,寫程序的目的是什么?

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

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

正確的程序算好程序.
1)邏輯正確,使用資源盡可能的少；
2)沒有bug,沒有把機器資源耗盡；
3)穩定性好,不會異常退出；
4)可用性高,有HA方案,不會因為一臺機器(或一個進程)無法提供服務,而影響整個系統的服務；
5)沒有單點是基本要求；
6)容易擴展,只需要簡單的增加資源(CPU、內存、磁盤、機器等)就行,不需要太多人工遷數據、修改配置等；
7)容易維護,包括容易配置、容易部署、容易監控等.

5. 如何寫出好程序?

1)什么樣的程序不出錯?代碼少的程序錯誤少,邏輯簡單的程序錯誤少,需要管理的資源少的程序錯誤少.要復用代碼,減少代碼的數量.
2)要抽象,分層,內聚,解藕,簡化邏輯,隔離資源,才能簡化邏輯,隔離資源,限制錯誤.
3)沒有持久狀態的程序好擴展,沒有持久狀態意味著上下線機器不需要遷移數據.沒有狀態的程序也很容易做HA方案.
4)配置簡單,日志豐富,能提供程序狀態查詢的程序好運維.
5)但程序不可能沒有數據,通過集中管理數據庫,讓數據盡量只讀,預加載數據等手段隔離邏輯和數據,也能讓擴展變的容易.

6. 系統是什么?

1)系統是我們運維的目標,不了解系統是什么,就不知道如何運維.
2)系統是網絡,是機器,是程序.是把網絡,機器,程序組織起來的架構.
3)機器角色應該是盡量單一的,架構應該是數據流簡單的,基礎業務服務化的.
4)系統是動態的,運維系統首先考慮的不是當下成本,而是系統變更(擴容,上下線機器)的成本.
5)運維必需是簡單的,要考慮的一個新手,如何能盡快上手工作,而不是冗長的文檔和復雜的培訓.

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

1)從某個角度說,開發人員做的事情越少,系統越容易穩定,因為開源的總是更靠譜.這是減少代碼,也是復用.
2)但運維卻理應比開發更不容易犯錯,因為運維只需要管理資源,而不需要應對復雜的業務邏輯.
3)這是個矛盾,因為開發負責的復雜業務邏輯,是運維負責的系統的一部分,前者不穩定,后者也別想消停.

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

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

1)CPU高意味著什么?你是不是應該先問問是sys,user,iowait這三個的哪個高?是單個CPU高,還是整體都搞?
2)你是否了解有的程序CPU使用率90%就有問題了,而有的350%了還沒問題?
3)load高意味著cpu高嗎?內存耗盡導致load高的原理是什么?內存耗盡回導致io高嗎?

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

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

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

1)CPU,內存,磁盤,帶寬都有對應的硬件,那些沒有硬件對應的資源呢?文件描述符,端口數,進程數是不是資源?
2)路由表,iptables,cron是不是資源?
3)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,還是添加用戶,都抽象為這三個.如果不能抽象為這三個,請再思考兩個小時.
如果系統可以由這三者全部控制,而這三者又全部寫入了配置管理,這意味著按照配置管理配置出來的系統就一定是對的.擴容,升級,機器的上線,下線從此該有多容易.而運維人員,可以通過配置管理,一覽整個系統,通過持續改進的模板,配置更容易學習,不容易出錯.

14. 監控

1)監控的正確性、業務響應時間也要同等關注的.
2)基礎監控要全面,但不一定實時報警.如果業務不受影響,又何必半夜起來處理宕機呢?如果業務有問題,全面的監控會幫你發現問題的蛛絲馬跡.

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

15. 運維技巧

1)重裝操作系統,使用puppet重新配置,是系統恢復到正確狀態的最佳途徑.理論上,新裝的機器使用puppet配置后一定是能用的,否則,就是puppet寫的有問題.
2)區分無狀態的機器和有狀態的機器,盡量把狀態集中,然后集中精力運維這些有狀態的機器.
寧可通過網絡把狀態集中也要盡量讓機器避免有狀態,無狀態的機器非常好運維.

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4591.html