無論是基於雲平臺還是IDC，又或者是openshift，我們搭建出的一套完整的DevOps環境，不能太依賴於其本身的穩定性以及可靠性，需要對這一套環境進行運維，運維內容包括但不僅僅限於trouble shooting、monitoring等。
今天我們會從運維的角度來聊下我們需要對一套DevOps系統如何進行維護。
一、監控
1、監控定義
觀察並記錄系統狀態變化和數據的流程。
- 狀態的變化：可以通過狀態的直接度量或者更新日誌來表示
- 數據：可以通過記錄內部組件和外部系統之間的請求和響應來記錄
支持這些功能的軟件系統即監控系統。
2、監控目的
尋找整個環境中的壞點，蒐集多層指標，記錄日誌，繪圖以及分析日誌，以及時找方法修改，恢復整個系統的健康。
下圖為AWS雲平臺某一虛機的監控狀態：
3、監控指標
大部分監控數據來自於系統的不同層級，為了實現監控的大部分指標，我們需要把整個系統包含在監控中。被監控的基本項包括輸入，資源和輸出。資源可以是軟件資源，也可以是基礎設施指標（CPU、Memory等）
監控指標主要包含以下幾項：
1）故障檢測
首先，我們需要對故障做個定義，故障是指系統中部分元器件功能失效而導致整個系統功能損壞的事件。
從Infrastructure的角度看，任何環節都有可能出現問題，如斷電，斷網，機器死機等等，由於這些問題是依賴於基礎設施的穩定性以及可靠性，用戶對該類問題沒有絕對的好辦法，但是可以做一些高可用的措施，比如異地多活，多可用區容災等。
從軟件層面看，故障可能是部分接口出問題，也可能是整個系統崩潰。
軟件故障檢測主要有三種方式：
- 監控軟件從外部對系統進行健康檢查（AWS Cloudwatch等）
- 系統內的特殊代理執行監控（自己安裝的一些代理軟件）
- 系統自己檢測到問題併發出報告
我們可以更早的發現的問題，並在軟件層面做及時的修改，以免整個系統的癱瘓。
2）性能
性能下降檢測是監控數據最為常見的用途。畢竟對於一個完善的系統，故障發生的概率遠遠比不上性能下降來的多，因此，如何及時反饋整個系統的性能以便能夠採取措施提高性能，成了一個系統能否對外提供穩定服務的關鍵。
性能的度量包括：
- 延遲：延遲是指從一個請求開始，到獲取服務端響應數據為止所經歷的時間。 這一階段會有幾個部分組成，其最主要延遲來自於網絡傳輸時間+服務器處理時間。因此，在監控處理的時候， 我們可以著重監控網絡性能以及服務器的處理性能，設置指標如服務器20s內無響應出發報警等。
- 吞吐量：吞吐量是單位時間內某個特性類型的操作數量，如每分鐘讀取硬盤數，或者每秒鐘的事物數等等。吞吐量提供了一種系統範圍的度量，延遲只關注單個客戶端。當然吞吐量的絕對值並不能說明根本問題，比如吞吐量的下降有可能是用戶數的下降。
- 使用率：資源的使用量或者使用百分比，通常在用戶感興趣的資源中插入探針來度量。比如CPU、內存、硬盤。CPU可以定義閾值超過80%報警，高使用率可以作為提前預警延遲或者吞吐量的問題，因為高的使用率會導致服務器處理性能下降，處理速度變慢，導致客戶端收到的響應變慢。
我們一起來看下一個簡單監控系統：
在監控過程中，我們需要對告警做一個過濾或者合併，比如，當CPU超過80%並保持80%以上1分鐘，那麼觸發一個報警，那麼，這種情況下，CPU超過80%，且在1分鐘內降下來，就不算一個告警，應予以過濾。
一旦監控數據被蒐集起來，那麼我們就可以做許多的事情：配置警報通知運維人員或者開發人員告知系統發生了變化，對於系統的健康狀態做一系列的報表等。
簡單明瞭的Dashboard可以將監控數據只管反饋給運維人員，當然，監控系統也允許運維人員進行深層次的log調取以及數據分析，這對錯誤診斷，RC（Root Cause）分析和決定最佳解決方案有至關重要的作用。
4、監控DevOps的過程
1）持續變更下的監控
由於雲的廣泛使用以及Devops變更是常態的特性，我們對於Devops系統的監控受到了很大的挑戰：
- 雲彈性
公有云，如AWS、Azure提供了IaaS和PaaS層的服務，他使得基礎設施資源變得唾手可得（如果錢夠的話），我們可以對虛擬機資源進行一系列的橫向或者縱向擴展，往往是簡單的鼠標點幾下就可以實現。
而且對於大多雲平臺來說，都會提供AutoScaling的服務，當你的虛機某些指標超過預設的閾值時，就會實現橫向的擴容，保證服務的可用性，或者縮減機器，減少成本。這就給監控策略以及監控方案的實施帶來了很多不便，比如代理的部署。
- 自動化的DevOps運維
他能出發很多零散的運維操作，比如升級，重配置，備份等等。持續集成和持續部署使得軟件變更更為頻繁，我們一天可能會發布幾十甚至上百個版本，每次部署都是對系統的一個變更，這也會影響到監控，因為每一次的發佈都需要更新監控數據，你不可能拿老的數據來分析新版本的問題。
我們應該儘可能的自動化警報，監控配置的過程其實也是一個DevOps的過程，它應該也需要自動化，當你提供一臺新服務器時，需要自動在監控系統中註冊這臺機器，當服務器停止時，應該自動觸發註銷流程。
2）微服務的監控
談到DevOps系統，我們就無法避開微服務，它使得可以為每個服務提供一個團隊，但是，這樣會讓你的系統變成一個深層次系統，每個外部請求都可能要穿過大量內部服務才能得到響應，如果一個服務響應很慢，那麼整個響應時間就會拉長。
在大型系統中，在任何用戶能夠忍受的範圍內，一部分的響應延緩會導致整個系統的響應不可接受。對於在具有許多節點的微服務架構中，儘早確定並修復問題節點，是一個很大的挑戰。
3）大容量分佈式數據的監控
在一個大型系統中，安裝的每個agent都有可能影響CPU、內存等性能，而且每秒鐘可能會產生數以百萬級的log數據，關於數據量，有如下考慮：
- 在很小的時間間隔內收集性能指標的開銷是巨大的
取決於系統當前的狀態，運維應該使用可變化的可調節的間隔，而不是一個固定的時間。監控顆粒度可以根據業務的重要程度做一定的區分，比如對於關鍵業務啟動詳細監控（1min）對於非關鍵業務可以啟用一般監控（5min）。
- 使用分佈式日誌或者消息系統蒐集日誌，而非自己構建
比如，分佈式日誌蒐集系統Logstash，能夠蒐集所有類型的日誌，並且在本地處理，這種類型的系統可以減少開銷，甚至在本地識別錯誤。比如Kafka，一個高性能分佈式消息系統，可以將輸入數據以及處理過程解耦。
5、小結
持續部署的實踐提高了變更的頻率——從應用到底層基礎設施，面對這種變更，需要我們的監控做實時的調整，這就要求監控本身也是自動化的；對於雲帶來的變革，監控策略和監控工具也要做響應的適應。
系統的複雜度，分佈程度和規模都在增加，指標和日誌的巨大容量要求新一代基礎設施能支持對大量的監控數據的收集、傳輸和存儲。一旦收集了大量的監控數據，為了從這些數據中篩選出有效的數據， 可能要依賴於大數據的分析。
二、NOC & MSP
可能有的朋友還不知道NOC和MSP是什麼。
1、NOC
NOC即Network Operation Center，如果要用一個直觀的概念描述NOC的話，我只能說：7*24。
不論你正在享受晚餐，還是在電影院享受二人世界，又或者你正跟兄弟們準備上高地。。。一個電話過來，所有的都得放下，因為你的系統可能正遭遇服務中斷，或者宕機，又或者被黑客攻擊，少則用戶投訴，多則損失上億。
運維本身就是一場沒有硝煙的戰爭，你必須在儘量短的時間內，給出響應，查出原因，保證損失的最小化。
對於DevOps系統來說，首先，我們需要明白的是，他的存在是為開發服務的，我們構建這一套系統的目的，就是為了減少產品從開發到上線的時間。
因此，我們必須保證DevOps系統的穩定性以及高可用性，因為你不會知道到哪個開發團隊會通宵用你的系統來構建、測試、以及發佈版本，一旦你的系統出現的問題，比如CI階段卡住或者發佈不了版本，那麼在沒有災備的情況下，開發團隊只能瘋狂的Call你。
如果你有一套在家的辦公系統，能夠隨時解決問題，倒也是一種方式，但是更多的時候，你需要對你的DevOps整個系統進行7*24小時的監控，不要等到問題發生了，開發團隊給你電話了，才被動的去尋找問題的原因，而是通過一系列的監控工具預先發現問題，把可能發現的問題扼殺在搖籃裡。
當然，不是所有問題都能夠預先發現的，很多事故的產生都具有偶發性，因此我們需要定義一個流程作為應急方案，下面是一種比較Common的流程：
對於一個NOC完整流程，當我們的系統出現警告，那麼我們就需要同時做兩件事情：
- 通知DevOps的開發團隊以及運維團隊有警告產生，那麼開發或者運營團隊需要對整個警告做一個認定，需要在規定的時間內將這個問題open；否則，就會將這個問題上報至更高一級的領導，直到問題解決為止。
- 同時，NOC Team應該對此告警做一個模擬測試，是否本地也能復現整個錯誤，如果可以復現，那麼立即將此告警上升為故障，並且通知所有干係人，直到問題在規定時間內解決為止；否則，繼續觀察整個警告的解決狀態，如果一直處於open未解決狀態，那麼NOC Team就需要一直測試，直到改警告的狀態被置為Solved。
對於NOC來說，更多的是需要在警告出現的第一時間內將流程運行起來，保證與此警告有關的干係人能夠第一時間收到消息，並且把fix的流程跑起來，同時需要對產生的告警進行常規測試，判斷該警告的嚴重的程度，決定是否要上升該警告的級別。
2、MSP
MSP即Managed Service Provider，如果說NOC是警告的過濾者，那麼MSP就是警告的終結者。
其實，MSP並不是一個新鮮的詞彙。在企業IT市場上，這個詞至少有20年以上的歷史。只不過，在國內較少被提及。因為在過去相當長的時間裡，國內企業喜歡自己建設、自己管理IT系統。
而在歐美髮達國家，託管服務早就被廣泛接受，提供這類服務的商家就被叫做managed hosting provider服務託管。
這個業務模式在歐美尤其盛行，很多大型服務提供商都在扮演服務託管的角色，為企業提供IT系統代運維或者代管理數據中心基礎設施服務直到雲的出現，才將MSP這個名詞重新提到公眾的視野，但是如今的雲MSP的概念已經有所不同。
託管服務只是雲MSP的職能之一，其他職能還包括為企業提供與公有云相關的諮詢、規劃、改造、遷移和管理服務。
對於基於雲平臺搭建的DevOps平臺，當然也是屬於我們MSP所關心的範圍。我們簡要來列舉下MSP所需要做的事情：
1）問題跟蹤
這個是所有MSP需要處理的最Common的問題，一旦系統出現問題，我們需要查看一些log來進行問題跟蹤或者歷史操作查詢，直到找到根本原因，並把問題解決。
這些可能會涉及到使用雲平臺現有的trouble shooting工具，或者自己在現有的資源上安裝agent。
但是，需要注意的是，對於安裝工具的性能需要有個清晰的認識，比如在生產環境上安裝一些重啟生效的工具是有一定風險的，因為如果不重啟，工具不生效；重啟的話，有可能會影響現有業務。
2）業務諮詢
這個不是針對於具體的Service，但是範圍也是很廣泛的，包括雲平臺架構的優化、數據庫的設計、雲平臺資源問題的諮詢等等。
這些對於MSP Team來說，都要有專業的人員對接，一旦用戶出現此類的諮詢，比如一個VPC內的EIP上限是多少，我的業務需要多少EIP，是否需要提前申請例外，雲平臺申請流程是什麼等等，需要給出比較專業的解決方案，這樣才能增強用戶的信任度。
3）資源規劃
尤其是對於雲平臺，如果說使用了雲平臺，不能把預算做到最低，那麼上雲有什麼意義？
一個好的MSP團隊應該有能力幫用戶把雲平臺的cost精算到個位數，對於當前業務所需要的雲平臺資源要有一個清晰的認識，在保證高性能和高可用的情況下，把資源的經費降到最低。
4）管理服務
- 對於用戶的權限管理
這也是一個比較科學的話題，既要保證用戶對資源的操作的最小權限，又要保證整個平臺的安全，要知道，一旦用戶的權限給錯，導致用戶有權限刪除資源，而正好他又不小心這麼做了，那麼對於整個平臺可能是災難性的。
所以，需要有專門的人員對當前的用戶權限等做嚴格的把關，保證整個平臺在權限角度的安全。
- 對於數據安全的管理
這是一個比較古老的話題，因為這是很多用戶決定是否上雲的一個關鍵點，對於這一點，我們可以建議部分上雲，關鍵數據坐落在本地的IDC，運算部分push到雲平臺上，這樣既能節省資源，也能消除用戶對於數據安全的顧慮。
當然，目前雲平臺提供的加密機制也是比較完善的，有靜態數據加密和動態數據加密等等，安全係數甚至比本地要高。
5）Dashboard
對於一個完善的MSP團隊，一個易用且功能完善的Dashboard是非常重要的，畢竟，用戶不會拿著你給的Linux操作數據一行行看
3、小結
NOC和MSP是連個聯繫緊密的模塊，NOC為MSP提供分析數據的來源，MSP為NOC分析數據以及提供九訣問題的方案。小的方面來說，一個DevOps系統需要這樣的系統支撐；大的方面來說，MSP和NOC對於一個完整的分佈式系統也是不可或缺的。
三、總結
本文對於 DevOps 系統的運維做了簡單的介紹，當然，運維的過程以及期間遇到的問題遠遠不止這些，我們需要在運維的過程中不斷髮現問題以及解決問題，直到把整個 DevOps 系統做到儘量的完善。
世界上唯一不變的就是變化，因此，對於 DevOps 的運維也不能過於死板和固守，因為基於雲平臺的架構以及對於雲平臺底層知識的匱乏，有時候基於雲平臺的底層bug，可能很難找到根本問題或者根本找不到問題，那麼，我們為什麼不能先解決問題，再去找根本原因呢？
作者：小E的私房菜來源：http://www.jianshu.com/p/83901e7c2679
