轉載自：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. 運維原則:
線上變更必需走配置管理。線上系統對任何人應該是隻讀的，只有配置管理程序有權寫。這樣保證了，變更是可重複的，可複製的。手工加路由，手工修改文件權限，手工配置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寫的有問題。
區分無狀態的機器和有狀態的機器，儘量把狀態集中，然後集中精力運維這些有狀態的機器。
寧可通過網絡把狀態集中也要儘量讓機器避免有狀態，無狀態的機器非常好運維。