本文來自網易云社區

作者：施勇

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

根據整個系統的生命周期，運維占據的比例和時間遠遠大于開發設計的時間，當然是排除了一些夭折的系統。所以在開發設計系統的時候，需要加強對于運維方面的重視。一個好的系統，除了受到產品用戶的歡迎之外，還需要得到運維人員的認可，才能讓系統更加健康地發展。反之，如果一個系統運維性較差，那么運維人員和開發人員可能會逐漸形成隔閡，進而影響整個系統的服務。

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

一、配置和部署

復雜系統在開發上線及運維的過程中，肯定需要經歷各個不同的階段：開發測試、QA測試、上線前測試、上線、后續版本更新等。不同階段和環境下，系統都需要有不同的配置，對于配置和部署，最好能做到以下幾點：

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

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

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

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

各類系統實際運維的過程中，經常會出現下面的情況，需要盡量排除：

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

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

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

二、監控告警

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

類似天網的監控

復雜系統至少需要監控：

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

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

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

• 系統異常日志的監控。

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

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

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

智能的告警策略

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

• 不同的告警等級，根據系統服務異常的原因和影響的范圍，劃分為不同等級并便指導不同的告警策略。

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

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

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

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

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

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

三、故障處理

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

故障預見

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

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

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

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

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

故障現場保留

當系統出現故障后，需要對故障現場做好保留，便于后續分析、處理和改進。故障現場保留的方式通常可以有：

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

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

故障智能處理

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

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

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

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

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

• 系統自動故障恢復，需要盡可能以代價小的方式來恢復，并做到整體資源可控。

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

四、小結

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

以上僅僅是個人對可運維系統的一點體會，希望以后能多多出現這樣的系統，助更多的運維和開發人員脫離疲于奔命救火的苦海。

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

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

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

轉載于:https://www.cnblogs.com/163yun/p/9674268.html

總結

以上是生活随笔為你收集整理的如何开发一个可运维系统的一点体会的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。