一個開發眼中的運維

轉載自：http://segmentfault.com/a/1190000000348370

在雲計算時代，開發和運維的結合變得愈來愈重要。在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池。（參考:四、5）

4. 先解決問題，而後是之後如何避免此類問題，後者更重要。

5. 不犯第三次錯誤（重複的問題不出現第三次）。第一次算不知道，第二次算不當心，第三次特麼是故意的吧。若是每一個問題都能完全有效解決（最終落實到配置變動和監控），問題就會愈來愈少。

6. 時刻思考如何「偷懶」，運維越悠閒，系統越穩定。

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

1. 包，全部線上的軟件/腳本都是經過(rpm)包管理的。

2. 文件，全部的變動「持久化」都是經過文件。程序的配置文件，sysctl，iptables，route，cron等凡是能用配置文件控制的一切。

3. 進程，全部的進程都是用配置管理啓動的，或者經過配置管理寫文件到系統啓動目錄，例如rc3.d。

你能相到的一切，不管是配置keepalived，仍是添加用戶，都抽象爲這三個。若是不能抽象爲這三個，請再思考兩個小時。
若是系統能夠由這三者所有控制，而這三者又所有寫入了配置管理，這意味着按照配置管理配置出來的系統就必定是對的。擴容，升級，機器的上線，下線今後該有多容易。而運維人員，能夠經過配置管理，一覽整個系統，經過持續改進的模板，配置更容易學習，不容易出錯。

監控

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

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

若是memcache偶爾響應慢，你怎麼能想到是swap致使的呢？全面的監控能夠幫你發現這一點。把業務邏輯抽象爲資源，能夠統一業務監控和基礎監控。（監控如何算全面，參考八、9）

運維技巧

1. 重裝操做系統，使用puppet從新配置，是系統恢復到正確狀態的最佳途徑。理論上，新裝的機器使用puppet配置後必定是能用的，不然，就是puppet寫的有問題。

2. 區分無狀態的機器和有狀態的機器，儘可能把狀態集中，而後集中精力運維這些有狀態的機器。寧肯經過網絡把狀態集中也要儘可能讓機器避免有狀態，無狀態的機器很是好運維。