DevOps要從哪幾方面下手？

1、無論是基于云平臺還是IDC,又或者是openshift,我們搭建出的一套完整的DevOps環(huán)境，不能太依賴于其本身的穩(wěn)定性以及可靠性，需要對這一套環(huán)境進(jìn)行運(yùn)維，運(yùn)維內(nèi)容包括但不僅僅限于troubleshooting、monitoring等。今天我們會從運(yùn)維的角度來聊下我們需要對一套DevOps系統(tǒng)如何進(jìn)行維護(hù)。一、監(jiān)控這一部分我們來全面地聊聊監(jiān)控。1、監(jiān)控定義觀察并記錄系統(tǒng)狀態(tài)變化和數(shù)據(jù)的流程。狀態(tài)的變化：可以通過狀態(tài)的直接度量或者更新日志來表示數(shù)據(jù)：可以通過記錄內(nèi)部組件和外部系統(tǒng)之間的請求和響應(yīng)來記錄支持這些功能的軟件系統(tǒng)即監(jiān)控系統(tǒng)。2、監(jiān)控目的尋找整個環(huán)境中的壞點(diǎn)，搜集多層指標(biāo)，記錄日志，

2、繪圖以及分析日志，以及時找方法修改，恢復(fù)整個系統(tǒng)的健康。下圖為AWS云平臺某一虛機(jī)的監(jiān)控狀態(tài)：3、監(jiān)控指標(biāo)大部分監(jiān)控?cái)?shù)據(jù)來自于系統(tǒng)的不同層級，為了實(shí)現(xiàn)監(jiān)控的大部分指標(biāo)，我們需要把整個系統(tǒng)包含在監(jiān)控中。被監(jiān)控的基本項(xiàng)包括輸入，資源和輸出。資源可以是軟件資源，也可以是基礎(chǔ)設(shè)施指標(biāo)（CPU、Memory等）監(jiān)控指標(biāo)主要包含以下幾項(xiàng):1）故障檢測首先，我們需要對故障做個定義，故障是指系統(tǒng)中部分元器件功能失效而導(dǎo)致整個系統(tǒng)功能損壞的事件。從Infrastructure的角度看，任何環(huán)節(jié)都有可能出現(xiàn)問題，如斷電，斷網(wǎng)，機(jī)器死機(jī)等等，由于這些問題是依賴于基礎(chǔ)設(shè)施的穩(wěn)定性以及可靠性，用戶對該類問題沒有絕對的好

3、辦法，但是可以做一些高可用的措施，比如異地多活，多可用區(qū)容災(zāi)等。Infra機(jī)器重啟OCountVQD-Slatj£-ecI.Fa：_Sys;er*=.050。貨DO10:001100StatusChecKfaiiki_Sysem從軟件層面看，故障可能是部分接口出問題，也可能是整個系統(tǒng)崩潰。軟件故障檢測主要有三種方式：監(jiān)控軟件從外部對系統(tǒng)進(jìn)行健康檢查（AWSCloudwatch等）系統(tǒng)內(nèi)的特殊代理執(zhí)行監(jiān)控（自己安裝的一些代理軟件）系統(tǒng)自己檢測到問題并發(fā)出報(bào)告我們可以更早的發(fā)現(xiàn)的問題，并在軟件層面做及時的修改，以免整個系統(tǒng)的癱瘓。2）性能性能下降檢測是監(jiān)控?cái)?shù)據(jù)最為常見的用途。畢竟對于一個

4、完善的系統(tǒng)，故障發(fā)生的概率遠(yuǎn)遠(yuǎn)比不上性能下降來的多，因此，如何及時反饋整個系統(tǒng)的性能以便能夠采取措施提高性能，成了一個系統(tǒng)能否對外提供穩(wěn)定服務(wù)的關(guān)鍵。性能的度量包括：延遲：延遲是指從一個請求開始，到獲取服務(wù)端響應(yīng)數(shù)據(jù)為止所經(jīng)歷的時間。這一階段會有幾個部分組成，其最主要延遲來自于網(wǎng)絡(luò)傳輸時間+服務(wù)器處理時間。因此，在監(jiān)控處理的時候，我們可以著重監(jiān)控網(wǎng)絡(luò)性能以及服務(wù)器的處理性能，設(shè)置指標(biāo)如服務(wù)器20s內(nèi)無響應(yīng)出發(fā)報(bào)警等。吞吐量：吞吐量是單位時間內(nèi)某個特性類型的操作數(shù)量，如每分鐘讀取硬盤數(shù)，或者每秒鐘的事物數(shù)等等。吞吐量提供了一種系統(tǒng)范圍的度量，延遲只關(guān)注單個客戶端。當(dāng)然吞吐量的絕對值并不能說明根本

5、問題，比如吞吐量的下降有可能是用戶數(shù)的下降。使用率：資源的使用量或者使用百分比，通常在用戶感興趣的資源中插入探針來度量。比如CPU、內(nèi)存、硬盤。CPU可以定義閾值超過80%報(bào)警，高使用率可以作為提前預(yù)警延遲或者吞吐量的問題，因?yàn)楦叩氖褂寐蕰?dǎo)致服務(wù)器處理性能下降，處理速度變慢，導(dǎo)致客戶端收到的響應(yīng)變慢。我們一起來看下一個簡單監(jiān)控系統(tǒng):>監(jiān)控系統(tǒng)在監(jiān)控過程中，我們需要對告警做一個過濾或者合并，比如，當(dāng)CPU超過80%并保持80%以上1分鐘，那么觸發(fā)一個報(bào)警，那么，這種情況下，CPU超過80%,且在1分鐘內(nèi)降下來，就不算一個告警，應(yīng)予以過濾。一旦監(jiān)控?cái)?shù)據(jù)被搜集起來，那么我們就可以做許多的事情

6、：配置警報(bào)通知運(yùn)維人員或者開發(fā)人員告知系統(tǒng)發(fā)生了變化，對于系統(tǒng)的健康狀態(tài)做一系列的報(bào)表等。簡單明了的Dashboard可以將監(jiān)控?cái)?shù)據(jù)只管反饋給運(yùn)維人員，當(dāng)然，監(jiān)控系統(tǒng)也允許運(yùn)維人員進(jìn)行深層次的10g調(diào)取以及數(shù)據(jù)分析，這對錯誤診斷，RC(RootCause)分析和決定最佳解決方案有至關(guān)重要的作用4、監(jiān)控DevOps的過程1）持續(xù)變更下的監(jiān)控由于云的廣泛使用以及Devops變更是常態(tài)的特性，我們對于Devops系統(tǒng)的監(jiān)控受到了很大的挑戰(zhàn)：云彈性公有云，如AWS、Azure提供了IaaS和PaaS層的服務(wù)，他使得基礎(chǔ)設(shè)施資源變得唾手可得（如果錢夠的話），我們可以對虛擬機(jī)資源進(jìn)行一系列的橫向或者縱向擴(kuò)

7、展，往往是簡單的鼠標(biāo)點(diǎn)幾下就可以實(shí)現(xiàn)。而且對于大多云平臺來說，都會提供AutoScaling的服務(wù)，當(dāng)你的虛機(jī)某些指標(biāo)超過預(yù)設(shè)的閾值時，就會實(shí)現(xiàn)橫向的擴(kuò)容，保證服務(wù)的可用性，或者縮減機(jī)器，減少成本。這就給監(jiān)控策略以及監(jiān)控方案的實(shí)施帶來了很多不便，比如代理的部署。自動化的DevOps運(yùn)維他能出發(fā)很多零散的運(yùn)維操作，比如升級，重配置，備份等等。持續(xù)集成和持續(xù)部署使得軟件變更更為頻繁，我們一天可能會發(fā)布幾十甚至上百個版本，每次部署都是對系統(tǒng)的一個變更，這也會影響到監(jiān)控，因?yàn)槊恳淮蔚陌l(fā)布都需要更新監(jiān)控?cái)?shù)據(jù)，你不可能拿老的數(shù)據(jù)來分析新版本的問題。我們應(yīng)該盡可能的自動化警報(bào)，監(jiān)控配置的過程其實(shí)也是一個De

8、vOps的過程,它應(yīng)該也需要自動化，當(dāng)你提供一臺新服務(wù)器時，需要自動在監(jiān)控系統(tǒng)中注冊這臺機(jī)器，當(dāng)服務(wù)器停止時，應(yīng)該自動觸發(fā)注銷流程。2）微服務(wù)的監(jiān)控談到DevOps系統(tǒng),我們就無法避開微服務(wù)，它使得可以為每個服務(wù)提供一個團(tuán)隊(duì)，但是，這樣會讓你的系統(tǒng)變成一個深層次系統(tǒng)，每個外部請求都可能要穿過大量內(nèi)部服務(wù)才能得到響應(yīng)，如果一個服務(wù)響應(yīng)很慢，那么整個響應(yīng)時間就會拉長。在大型系統(tǒng)中，在任何用戶能夠忍受的范圍內(nèi)，一部分的響應(yīng)延緩會導(dǎo)致整個系統(tǒng)的響應(yīng)不可接受。對于在具有許多節(jié)點(diǎn)的微服務(wù)架構(gòu)中，盡早確定并修復(fù)問題節(jié)點(diǎn)，是一個很大的挑戰(zhàn)。3）大容量分布式數(shù)據(jù)的監(jiān)控在一個大型系統(tǒng)中，安裝的每個agent都有可

9、能影響CPU、內(nèi)存等性能，而且每秒鐘可能會產(chǎn)生數(shù)以百萬級的10g數(shù)據(jù)，關(guān)于數(shù)據(jù)量，有如下考慮：在很小的時間間隔內(nèi)收集性能指標(biāo)的開銷是巨大的取決于系統(tǒng)當(dāng)前的狀態(tài)，運(yùn)維應(yīng)該使用可變化的可調(diào)節(jié)的間隔，而不是一個固定的時間。監(jiān)控顆粒度可以根據(jù)業(yè)務(wù)的重要程度做一定的區(qū)分，比如對于關(guān)鍵業(yè)務(wù)啟動詳細(xì)監(jiān)控（1min）對于非關(guān)鍵業(yè)務(wù)可以啟用一般監(jiān)控（5min）。使用分布式日志或者消息系統(tǒng)搜集日志，而非自己構(gòu)建比如，分布式日志搜集系統(tǒng)Logstash,能夠搜集所有類型的日志，并且在本地處理，這種類型的系統(tǒng)可以減少開銷，甚至在本地識別錯誤。比如Kafka,一個高性能分布式消息系統(tǒng)，可以將輸入數(shù)據(jù)以及處理過程解耦。5

10、、小結(jié)持續(xù)部署的實(shí)踐提高了變更的頻率一一從應(yīng)用到底層基礎(chǔ)設(shè)施，面對這種變更，需要我們的監(jiān)控做實(shí)時的調(diào)整，這就要求監(jiān)控本身也是自動化的；對于云帶來的變革，監(jiān)控策略和監(jiān)控工具也要做響應(yīng)的適應(yīng)。系統(tǒng)的復(fù)雜度，分布程度和規(guī)模都在增加,指標(biāo)和日志的巨大容量要求新一代基礎(chǔ)設(shè)施能支持對大量的監(jiān)控?cái)?shù)據(jù)的收集、傳輸和存儲。一旦收集了大量的監(jiān)控?cái)?shù)據(jù)，為了從這些數(shù)據(jù)中篩選出有效的數(shù)據(jù),可能要依賴于大數(shù)據(jù)的分析。、NOC&MSP可能有的朋友還不知道NOC和MSP是什么1、NOCNOC即NetworkOperationCenter,如果要用一個直觀的概念描述NOC的話，我只能說：7*24。不論你正在享受晚餐，還

11、是在電影院享受二人世界，又或者你正跟兄弟們準(zhǔn)備上高地。一個電話過來，所有的都得放下，因?yàn)槟愕南到y(tǒng)可能正遭遇服務(wù)中斷，或者宕機(jī)，又或者被黑客攻擊，少則用戶投訴，多則損失上億。運(yùn)維本身就是一場沒有硝煙的戰(zhàn)爭，你必須在盡量短的時間內(nèi)，給出響應(yīng)，查出原因，保證損失的最小化。對于DevOps系統(tǒng)來說，首先，我們需要明白的是，他的存在是為開發(fā)服務(wù)的，我們構(gòu)建這一套系統(tǒng)的目的，就是為了減少產(chǎn)品從開發(fā)到上線的時間。因此，我們必須保證DevOps系統(tǒng)的穩(wěn)定性以及高可用性，因?yàn)槟悴粫赖侥膫€開發(fā)團(tuán)隊(duì)會通宵用你的系統(tǒng)來構(gòu)建、測試、以及發(fā)布版本，一旦你的系統(tǒng)出現(xiàn)的問題，比如CI階段卡住或者發(fā)布不了版本，那么在沒有災(zāi)

12、備的情況下，開發(fā)團(tuán)隊(duì)只能瘋狂的Call你。如果你有一套在家的辦公系統(tǒng)，能夠隨時解決問題，倒也是一種方式，但是更多的時候，你需要對你的DevOps整個系統(tǒng)進(jìn)行7*24小時的監(jiān)控，不要等到問題發(fā)生了，開發(fā)團(tuán)隊(duì)給你電話了，才被動的去尋找問題的原因，而是通過一系列的監(jiān)控工具預(yù)先發(fā)現(xiàn)問題，把可能發(fā)現(xiàn)的問題扼殺在搖籃里。當(dāng)然，不是所有問題都能夠預(yù)先發(fā)現(xiàn)的，很多事故的產(chǎn)生都具有偶發(fā)性，因此我們需要定義一個流程作為應(yīng)急方案，下面是一種比較Common的流程:/MSPFm對于一個NOC完整流程，當(dāng)我們的系統(tǒng)出現(xiàn)警告，那么我們就需要同時做兩件事情：通知DevOps的開發(fā)團(tuán)隊(duì)以及運(yùn)維團(tuán)隊(duì)有警告產(chǎn)生，那么開發(fā)或者運(yùn)營

13、團(tuán)隊(duì)需要對整個警告做一個認(rèn)定，需要在規(guī)定的時間內(nèi)將這個問題open；否則，就會將這個問題上報(bào)至更高一級的領(lǐng)導(dǎo)，直到問題解決為止。|同時，NOCTeam應(yīng)該對此告警做一個模擬測試，是否本地也能復(fù)現(xiàn)整個錯誤，如果可以復(fù)現(xiàn)，那么立即將此告警上升為故障，并且通知所有干系人，直到問題在規(guī)定時間內(nèi)解決為止；否則，繼續(xù)觀察整個警告的解決狀態(tài)，如果一直處于open未解決狀態(tài)，那么NOCTeam就需要一直測試，直到改警告的狀態(tài)被置為Solved。對于NOC來說，更多的是需要在警告出現(xiàn)的第一時間內(nèi)將流程運(yùn)行起來，保證與此警告有關(guān)的干系人能夠第一時間收到消息，并且把fix的流程跑起來，同時需要對產(chǎn)生的告警進(jìn)行常規(guī)測

14、試，判斷該警告的嚴(yán)重的程度，決定是否要上升該警告的級別。2、MSPMSP即ManagedServiceProvider，如果說NOC是警告的過濾者，那么MSP就是警告的終結(jié)者。其實(shí)，MSP并不是一個新鮮的詞匯。在企業(yè)IT市場上，這個詞至少有20年以上的歷史。只不過，在國內(nèi)較少被提及。因?yàn)樵谶^去相當(dāng)長的時間里，國內(nèi)企業(yè)喜歡自己建設(shè)、自己管理IT系統(tǒng)。而在歐美發(fā)達(dá)國家，托管服務(wù)早就被廣泛接受，提供這類服務(wù)的商家就被叫做managedhostingprovider月艮務(wù)托管。這個業(yè)務(wù)模式在歐美尤其盛行，很多大型服務(wù)提供商都在扮演服務(wù)托管的角色，為企業(yè)提供IT系統(tǒng)代運(yùn)維或者代管理數(shù)據(jù)中心基礎(chǔ)設(shè)施服務(wù)直

15、到云的出現(xiàn)，才將MSP這個名詞重新提到公眾的視野，但是如今的云MSP的概念已經(jīng)有所不同。托管服務(wù)只是云MSP的職能之一，其他職能還包括為企業(yè)提供與公有云相關(guān)的咨詢、規(guī)劃、改造、遷移和管理服務(wù)。對于基于云平臺搭建的DevOps平臺，當(dāng)然也是屬于我們MSP所關(guān)心的范圍。我們簡要來列舉下MSP所需要做的事情：1）問題跟蹤這個是所有MSP需要處理的最Common的問題，一旦系統(tǒng)出現(xiàn)問題，我們需要查看一些10g來進(jìn)行問題跟蹤或者歷史操作查詢，直到找到根本原因，并把問題解決。這些可能會涉及到使用云平臺現(xiàn)有的troubleshooting工具，或者自己在現(xiàn)有的資源上安裝agent。但是，需要注意的是，對于安

16、裝工具的性能需要有個清晰的認(rèn)識，比如在生產(chǎn)環(huán)境上安裝一些重啟生效的工具是有一定風(fēng)險的，因?yàn)槿绻恢貑?，工具不生效；重啟的話，有可能會影響現(xiàn)有業(yè)務(wù)。2）業(yè)務(wù)咨詢這個不是針對于具體的Service，但是范圍也是很廣泛的，包括云平臺架構(gòu)的優(yōu)化、數(shù)據(jù)庫的設(shè)計(jì)、云平臺資源問題的咨詢等等。這些對于MSPTeam來說，都要有專業(yè)的人員對接，一旦用戶出現(xiàn)此類的咨詢，比如一個VPC內(nèi)的EIP上限是多少，我的業(yè)務(wù)需要多少EIP,是否需要提前申請例外，云平臺申請流程是什么等等，需要給出比較專業(yè)的解決方案，這樣才能增強(qiáng)用戶的信任度。3）資源規(guī)劃尤其是對于云平臺，如果說使用了云平臺，不能把預(yù)算做到最低，那么上云有什么意

17、義？一個好的MSP團(tuán)隊(duì)?wèi)?yīng)該有能力幫用戶把云平臺的cost精算到個位數(shù)，對于當(dāng)前業(yè)務(wù)所需要的云平臺資源要有一個清晰的認(rèn)識，在保證高性能和高可用的情況下，把資源的經(jīng)費(fèi)降到最低。4）管理服務(wù)對于用戶的權(quán)限管理這也是一個比較科學(xué)的話題，既要保證用戶對資源的操作的最小權(quán)限，又要保證整個平臺的安全，要知道，一旦用戶的權(quán)限給錯，導(dǎo)致用戶有權(quán)限刪除資源，而正好他又不小心這么做了，那么對于整個平臺可能是災(zāi)難性的。所以，需要有專門的人員對當(dāng)前的用戶權(quán)限等做嚴(yán)格的把關(guān)，保證整個平臺在權(quán)限角度的安全。對于數(shù)據(jù)安全的管理這是一個比較古老的話題，因?yàn)檫@是很多用戶決定是否上云的一個關(guān)鍵點(diǎn)，對于這一點(diǎn)，我們可以建議部分上云，關(guān)鍵數(shù)據(jù)坐落在本地的IDC,運(yùn)算部分push到云平臺上，這樣既能節(jié)省資源，也能消除用戶對于數(shù)據(jù)安全的顧慮。當(dāng)然，目前云平臺提供的加密機(jī)制也是比較完善的，有靜態(tài)數(shù)據(jù)加密和動態(tài)數(shù)據(jù)加密等等，安全系數(shù)甚至比本地要高。5)Dashboard對于一個完善的MSP團(tuán)隊(duì)，一個易用且功能完善的Dashboard是非常重要的，畢竟，用戶不會拿著你給的Linux操作數(shù)據(jù)一行行看3、小結(jié)NOC和MSP是連個聯(lián)系緊密的模塊，NOC為MSP提供分析數(shù)據(jù)的來源，MSP為NOC分析數(shù)據(jù)以及提供九訣問題的方案