一個開發眼中的運維

在雲計算時代，開發和運維的結合變得越來越重要。在 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. 區分無狀态的機器和有狀态的機器，盡量把狀态集中，然後集中精力運維這些有狀态的機器。

   甯可通過網絡把狀态集中也要盡量讓機器避免有狀态，無狀态的機器非常好運維。