運維工做與持續進階

最近在總結2010年來的公司的運維進展，順便拜讀了馮大輝 前輩關於網站運維方面的文章。運維是對當前互聯網中一個較爲特殊的領域(其實每一個領域都有特殊的地方)，套用前輩的話就是「運維的工做包括(但不限於) 軟硬件部署、網絡管理、應用程序維護、安全、容量規劃、故障修復等等 」。可能有人以爲和傳統的公司IT管理員沒啥區別，其實最大的區別就是你面臨的用戶羣體不一樣，數量不一樣，服務質量的等級不一樣。因此，若想作好運維工做，對涉及的領域要儘量的精通，善於應變，快速解決問題，同時作好大量的預防工做。

 

如何衡量運維的工做質量？系統的可用性和系統的實效時長成反比，是對運維工做的最重要指標。可用性不能單純用某一天去衡量，而應該使用年做爲單位，甚至有可能須要過好幾年，才能評論這個員工的工做質量。爲何這麼說呢？打個比方，一個公司剛上線一套新的服務，那麼運維工做人員可能採用了新的服務器(性能很好，容量評估過大)。新的服務可能訪問量不多，那麼也許在很長一段時間內整套系統的負載很小，因爲硬件獲得了很好的保證，因此在很長一段時間內多是運行良好的(甚至出來問題也沒有人發現)。至少上面的假設說明，短短的一段時間不能說明一個團隊的運維工做如何。

 

如下是我根據實際工做中獲得改善運維工做的一些看法。

 

系統結構的合理化

調整系統結構(硬件、軟件部署結構)，在合理的人力支出狀況下，提升系統的可用性是一個很是重要的手段，也是提升可用性的根本之源。

• 創建合理的冗餘，並增強自動化工做。冗餘是系統組件發生故障時獲得快速切換，提供無中斷服務是重要基礎，處於各類緣由，系統服務和質量可能會持續性的發生變化，應付這些變化，也須要持續合理的對系統結構進行調整(好比添加硬盤也是一種)。例如數據庫的冗餘，簡單的Master/Slave方案也是提升信心的手段，甚至還可使用Slave來緩解Master查詢的壓力。當前我所負責的平臺雖然在不少組件的部署上有這方面的意識，但合理性還有待改善，同時也須要提供必定的測試演練來完善。尤爲是一些遊戲服務組件中，當前僅僅是提供了冗餘的設備，但冗餘的服務組件以及更智能的自動化切換一直沒有完善。web平臺這邊因爲設備有限，雖然在各個組件上都實現了冗餘，但還缺少自動化切換。

• 提升系統的穩定性，這點須要從設計、開發方面着手。系統的設計應該朝着可以提供部分停機維護、升級、切換髮展；從系統結構、代碼上提供系統的穩定性，減小由於某類異常致使影響到其餘組件。我曾經發現一個核心繫統總的積分排行功能設計缺陷致使數據庫長時間鎖，從而又致使整個核心沒法提供服務。

• 整套系統還須要考慮Qos，避免帶寬被非核心的服務佔用過多。爲此，從設計、部署上就要把那些大量佔用帶寬的服務和核心服務進行區分。例如對於網站，將圖片、大文件等使用另外的域名提供服務，並在網絡上進行區分，可讓核心網站獲得更多的帶寬保障，另外使用不一樣的域名存圖片、樣式文件等可讓客戶有更快的併發，並減小客戶端由於cookie等無用信息佔用的帶寬。

• 備份(甚至是儘量實時的)，對各種應用數據，尤爲是不可恢復的信息作好備份，避免單點失效，因此備份須要存放到其餘設備上，備份策略須要不斷的完善，並進行合理的演練。不一樣的服務組件有不一樣的備份形式，例如用戶的圖片(以及其餘一些文件)，可使用rsync按期備份到另外的存儲服務器，利用dump/restore這組程序實現全量、增量的備份，固然結合lvm snapshot以及一些合理的按期腳本，就能實現開源高可靠的容災方案了(數據庫的物理備份也能夠用這招)。

監控

 

監控是測試系統可用性的手段，甚至能在災難擴大前解決問題。監控的目標包括

• 對操做系統的一些重要指標進行監控，例如CPU、內存、存儲、進程狀態、網絡狀態。你可使用nagios輕鬆的實現這類監控，固然你還須要對其閥值的合理性進行全面評估。

• 對業務組件、中間件的監控，例如mysql的健康狀態(鏈接數、鎖)，tomcat的線程數。這類監控能告訴咱們業務組件的健康狀態，須要不斷完善這類監控，但這類的監控也是很難顧全的，由於這類組件容易出現」部分異常」，或者由於應用程序致使一些異常，甚至是必須在特定的業務流程中才重現。

• 業務流程監控，俗稱業務撥測，模擬用戶、客戶端的業務來進行業務完整性測試。若是你的運營系統只是一個普通的web服務，根據你當前的一些業務採集幾個核心的url，仍是能大致知道整個web服務是否正常運行的。可是如何運營系統了有一些特殊服務，好比遊戲服務平臺，那你可能須要開發與之對應的一些業務模擬程序(厄，機器人)來進行測試了，固然，也能夠經過各類辦法採集服務組件的信息來監控，但這畢竟不是最終用戶的感覺(或實際操做結果)。

• 對監控服務器的監控，才能最大可能保證監控是順利的。例如，你能夠創建兩套nagios監控，雙方相互監控對方。

 

• 對於監控的完善，咱們應儘量使用成熟的方案，流行的開源工具實現監控，儘可能避免本身編寫(腳本、代碼)，經驗告訴咱們，本身編寫的東西每每是不完善的，有時候會帶來更大的問題，甚至影響被監控的對象。

平常工做中須要不按期的檢查系統、中間件等各個監控點，以確保他們實際中沒有出現問題，而且能根據各類人工檢查和總結來完善監控系統。除了這些常規監控外，安全性檢查，日誌分析，補丁，入侵監控，漏洞掃描等也是平常須要完成的工做。

 

報警、應急處理

如何能獲得快速的報警：

• 短信，有必定的延遲性，依賴於短信提供商。好比當前咱們使用飛信(非官方)，那麼飛信的客戶端組件、飛信服務器、短信服務器都是咱們沒法控制的。緩解、解決辦法：每日發送測試短信；監控發送短信的返回碼，若是不正確，則再發送到139郵箱(也依賴於網絡的健康)。更加改善的辦法，購買短信發送客戶端。

• IM，一些IM支持報警，好比使用XMPP開放的客戶端，也依賴於網絡的健康。

• 郵件，也依賴於網絡的健康，及時性不強。

• 按期訂閱，firefox的插件支持查閱nagios的狀態接口來獲取各個監控項的報警。

故障處理流程和速度，監控內容的增多，意味着可能須要更多的人力去處理應急故障，明確的故障處理流程和責任人，以及經驗的積累有助於快速解決故障。另外，演習也是一個加快故障處理，積累經驗的好辦法。尤爲是對大災難，咱們須要經過演習來完善應付方案，好比數據庫的損害、硬件的損害。

 

測試、容量規劃、分析預測

面對不斷的變化和發展，對於系統將來一段時間內的狀態和反應須要有合理的 評估。評估的基礎有如下兩方面提供：

• 測試，搭建合理的測試模型，能監測到系統在預估的測試模型下的表現。

• 基線創建，基線的創建在網絡質量、服務器性能這方面尤其重要，從基線的發展中能瞭解到系統對服務質量的演變，併爲容量規劃提供依據，開源中cacti、ganglia是一些很好軟件。

流程規範

流程規範是對長遠的保障，也是避免人爲故障的手段。運維面對的流程規範主要有兩方面

• 業務應用程序維護、升級帶來的變化。爲了保證可用性，發生這些變化時最好有明確的文檔指導，甚至是須要使用文檔指導在測試環境下進行模擬變動，以減小在生產環境下變動時帶來的問題。

• 服務系統、環境、結構等的修改。好比服務的搬遷，咱們須要詳細的搬遷方案和模擬演練，對修改須要進行歸檔，以備查閱。

知識積累管理

運維涉及大量的知識，不僅僅是技術性的知識，也有和業務系統相關的業務知識。只有保管好這些知識，才能不斷的在團隊中流傳和使用，使團隊人員能快速解決問題。當前衆多互聯網技術團隊使用wiki管理這些知識，wiki能很好的維護這些文檔的變動，也提供良好的查閱方式。

 

團隊人員還須要對外界的資訊進行收集和吸取，尤爲是各種漏洞的公佈，補丁的修改，這類信息對運維相當重要。同時須要不斷吸取新知識，以改善運維工做。

 

團隊建設和管理、工做安排

總得來講，運維工做須要團隊成員有強烈的責任心，高度自覺和技術敏感度。網絡上衆多人反映本身公司的運維工做人員，閒，天天就是喝茶。運維工做是一個可多可少的活，也是容易讓人偷懶的活。
根據以往經驗總結，能夠從如下方面提升成員的工做質量：

• 工做的劃分。工做的劃分能夠分爲縱向切割和橫向切割，縱向切割較爲簡單，須要成員具有足夠的實力，把系統按物理設備、按服務組件切割任務，使每一個成員負責一部分，相互間干擾較小。橫向切割能夠理解爲技術等級劃分工做，技術能力較弱的負責有完善模型的工做，好比已經有良好的監控系統，技術若者進行例行檢查，技術強者在出現故障作後盾提供援助。

• 責任制，責任制和工做劃分有密切的關係。若是做爲橫向切割，負責例行檢查的人對於那些可預知、可發現的問題，因人爲的忽略，最終致使系統故障，那麼負責檢查的人須要對此負責任。縱向切割時，負責人須要解決本身所負責的任務，不能及時處理時須要申請援助。人的責任心、積極性也能夠從故障發生的頻度，可預防性，應急速度、總結經驗等過程當中獲得反饋。

• 技術性監工，也稱技術型考覈。對於成員所負責的任務，作出的技術性方案、實現進行分析評審，以查找可能存在的漏洞和弊端，減小人爲失誤。