如何開發一個可運維繫統的一點體會

本文來自網易雲社區

做者：施勇

咱們在開發一個複雜系統的時候，經常會強調服務化、模塊化、鬆散耦合等要求以達到高可用、高可靠及高性能等目的；比較少的人會考慮到系統的方便部署配置和運維，至少是在剛開始設計系統的時候不多考慮到運維部署方面的需求。這樣的複雜系統，在正式投入使用以後，經常會由於部署配置和運維等方面問題形成系統不穩定甚至出現異常。

根據整個系統的生命週期，運維佔據的比例和時間遠遠大於開發設計的時間，固然是排除了一些夭折的系統。因此在開發設計系統的時候，須要增強對於運維方面的重視。一個好的系統，除了受到產品用戶的歡迎以外，還須要獲得運維人員的承認，才能讓系統更加健康地發展。反之，若是一個系統運維性較差，那麼運維人員和開發人員可能會逐漸造成隔閡，進而影響整個系統的服務。

結合本身在開發和運維方面的經歷，以及多年被無數短信告警騷擾的煩惱，談談在開發設計一個系統的可運維性方面須要注意的問題。

1、配置和部署

複雜系統在開發上線及運維的過程當中，確定須要經歷各個不一樣的階段：開發測試、QA測試、上線前測試、上線、後續版本更新等。不一樣階段和環境下，系統都須要有不一樣的配置，對於配置和部署，最好能作到如下幾點：

• 提供詳細的配置和部署手冊。

• 提供適用典型場景的各個配置模板。

• 提供靈活的關鍵參數可配置，以適應各種複雜的運行環境；儘量提供在線動態修改的方式。

• 提供自動化的部署方案或腳本，在異常狀況下能自動重啓恢復。

各種系統實際運維的過程當中，常常會出現下面的狀況，須要儘可能排除：

• 針對線上環境，系統未能提供足夠的參數配置以適應其負載或優化服務。

• 系統提供了足夠多的靈活可配置的參數，但未針對線上環境進行優化配置。

• 系統程序寫死了配置目錄路徑等部分參數。

2、監控告警

一個複雜系統在實際運行過程當中，不免會出現各種沒法預見的問題。爲了讓系統在這種異常環境下還能提供穩健的服務，除了系統設計的容錯和健壯性以外，還須要的是無處不在的監控和及時的告警。

相似天網的監控

複雜系統至少須要監控：

• 系統總體服務的可用性、穩定性和性能指標。

• 外部依賴服務的可用性和穩定性；若外部依賴服務影響自身服務的性能指標，須要對外部依賴服務作好性能監控。

• 系統內部各個模塊的可用性、性能指標以及各模塊銜接的連續性。

• 系統異常日誌的監控。

• 系統後臺線程的健康狀態，這點很容易被忽略。

• 系統部署所在服務器和網絡的健康狀態。

系統須要提供對各項監控內容的查詢顯示，以便運維人員可以隨時瞭解系統的運行狀態；此外，最好可以提供查詢API，方面運維集成。

智能的告警策略

當一個複雜的系統出現問題時，須要及時報警通知到相關的運維人員。在告警策略設計時，須要考慮到：

• 不一樣的告警等級，根據系統服務異常的緣由和影響的範圍，劃分爲不一樣等級並便指導不一樣的告警策略。

• 多樣的告警方式，至少支持IM、郵件和手機短信的三種方式告警。

• 不一樣層級的告警接收人員。

告警等級	描述	告警方式和策略	告警接收人員
事故級	系統總體服務不可用或異常，形成業務損失	IM、郵件和手機短信；持續短間隔告警	運維、開發和產品業務，以及各自部門領導
故障級	系統服務不穩定，未對業務形成明顯影響	IM、郵件和手機短信；持續告警	運維、開發，以及各自負責人
異常級	故障前兆，系統可能在不久未來出現故障	IM、郵件；固定週期告警	運維和開發人員
缺陷級	系統已知的缺陷，目前不會對總體服務產生影響	郵件；當系統觸發缺陷時告警	運維或開發人員

告警程序設計上，高等級的告警須要被優先處理，不能由於低等級告警過多而形成高等級告警被延遲。同時須要支持對同類告警的暫停報警功能（暫停一段時間後自動恢復監控報警），便於運維人員計劃性的維護操做。

告警內容的可讀性，對於運維人員也很是重要，特別是手機短信告警的內容，應該可以讓運維人員立刻定位到是哪一個服務器所在的服務出現了哪類問題；最惱人的告警短信是各個環境系統都是相同的內容： xx服務出現異常，請檢查郵件和log 。

設計良好的系統，須要有接入統一的報警監控中心的能力。

3、故障處理

一個複雜系統須要提供良好的故障處理機制，包括故障預見、故障現場保留、故障智能處理等。

故障預見

系統在運行過程當中，對其利用的資源和自身的運行狀態作好監控，若是預見系統可能出現不穩定等狀況，須要加以處理和告警。系統可預見的故障可能有：

• 所處的服務器硬件資源利用率上升，不久未來會到達上限，須要及時告警。

• 系統設計的有限制的資源的使用量將達到配置限額，須要及時告警。

• 系統處理效率忽然下降，及時告警。一個容錯備份的分佈式系統，需及時屏蔽處理效率地下的組件，用其它備份的組件代替。

• 系統接收處理的請求量突升或突降，及時告警。

故障現場保留

當系統出現故障後，須要對故障現場作好保留，便於後續分析、處理和改進。故障現場保留的方式一般能夠有：

• 日誌。最簡單直接的方式，但在日誌輸出格式和內容方面，須要作好設計；既要保證對系統性能影響和資源佔用足夠小，又要保留足夠的信息供運維人員和開發人員排查。

• 性能和資源監控平臺。詳細記錄服務器運行狀態和各種資源的使用狀況，能夠了解故障發生時候的服務器硬件運行狀態。

故障智能處理

一個複雜系統，必需要作到可容錯和故障的自動處理及恢復。若是系統的可容錯和故障自動恢復作得還不完善狀況下，至少須要提供可人工運維處理的接口。最怕的是系統作了部分的故障自動處理，但處理機制有問題，而且沒有提供有效的人工處理方式去解決，這個簡直是運維人員的噩夢！一個系統在交付運維的時候，運維手冊中必須包含各種故障的詳細處理方式。

系統可容錯和故障自動恢復，典型的場景有：

• 當某個依賴的底層服務異常狀況下，系統自動屏蔽依賴此服務的請求或經過升降級方式繞過異常底層服務；若不行，也必須在底層服務恢復正常後，系統能當即自動恢復。

• 系統各個模塊之間的容錯性，包括部分模塊異常或者模塊銜接出現短暫問題，當問題解決後都需能當即恢復。

• 包含多備份組件的系統，當少數備份組件出現異常時候，其它備份須要當即接管其服務，並可以自動恢復到正常狀態。

• 系統自動故障恢復，須要儘量以代價小的方式來恢復，並作到總體資源可控。

當系統出現故障時，須要及時告警，通知運維和開發人員系統故障及對應的處理方式。若是故障自動恢復須要必定時間，恢復的進度也須要按期報告。

4、小結

一個可運維和方便運維的系統，不只有助於運維人員快速掌握和上手運維，又能及時發現系統中可能存在的不穩定的異常的因素，從而促進整個系統更好更健康的發展壯大。系統的可運維性，不僅僅是系統上線以後要考慮的問題，而是要在系統設計之初就應該關注的一面，而且是貫穿到開發設計的各個階段中的。

以上僅僅是我的對可運維繫統的一點體會，但願之後能多多出現這樣的系統，助更多的運維和開發人員脫離疲於奔命救火的苦海。

網易雲免費體驗館，0成本體驗20+款雲產品！

更多網易研發、產品、運營經驗分享請訪問網易雲社區。

相關文章：
【推薦】 基於Redis+Kafka的首頁曝光過濾方案
【推薦】 知物由學 | AI時代，那些黑客正在如何打磨他們的「利器」？（一）