中國IDC圈12月26日報道，12月20-22日，第十一屆中國IDC財富年度大典（IDCC2016）在北京國度集會會議中心謹(jǐn)慎召開。本次大會由中國信息通信研究院、云計較成長與政策論壇、數(shù)據(jù)中心同盟指導(dǎo)，中國IDC財富年度大典組委會主辦，中國IDC圈承辦，并受到諸多媒體的大力大舉支持。

中國IDC財富年度大典作為海內(nèi)云計較和數(shù)據(jù)中心規(guī)模局限最大、最具影響力的符號性盛會，之前已樂成舉行過十屆，在本屆大會無論是規(guī)格照舊局限都"更上一層樓"，引來現(xiàn)場人員爆滿，影響力全面包圍數(shù)據(jù)中心、互聯(lián)網(wǎng)、云計較、大數(shù)據(jù)等多個規(guī)模。

會上，網(wǎng)龍云計較架構(gòu)師 阮少鈞出席本次大會并為當(dāng)天的IDC上市企業(yè)大會做 《企業(yè)在云計較架構(gòu)下的運維管理》主題演講。

網(wǎng)龍云計較架構(gòu)師 阮少鈞

以下是演講實錄：

阮少鈞：本日會分成三個部門，先講一下在云計較整個場景下運維有上來特點，包羅怎么去做一些應(yīng)對，第二個部門會講云計較的運維用什么樣的架構(gòu)去適配，第三是分享最佳實踐。

我們先看一下傳統(tǒng)運維會碰著的挑戰(zhàn)，在已往大概基本設(shè)施的運維是較量費錢的部分，此刻我們天天都在講云計較，對付老板而言，他被這些云計較的對象洗腦過今后，老板是想是否投資可以倒過來，云計較就是要花得更少，做得要好，還不能倒。所以或許會是這樣的場景。在云計較時代，交付速度越來越快，本錢越來越低，質(zhì)量越來越高，這是一個趨勢。從傳統(tǒng)的運維到開拓的整個鏈條來說，最容易遇到什么樣的環(huán)境？業(yè)務(wù)產(chǎn)生妨礙的時候，損失可用性，開拓和運維是這樣的場景。開拓說對象在運維手上，出了問題找運維，運維說代碼寫的有問題。這內(nèi)里有一個運維墻，運維墻的存在不只在質(zhì)量上難以改進，速度上，開拓說我要開拓更多的成果，我要交付更多的成果，我要更快的宣布，運維說我要不變，所以慢一點，開拓少一點。為了協(xié)調(diào)開拓和運維之間的抵牾，我們在打點上要做許多的盡力，包羅我們要做打點上的一些流程類型。這一方面的本錢開銷很大。

最近幾年較量多的叫DEVOPS，開拓媒體化。并不是說我們提了DEVOPS，來日誥日有DEVOPS.我們看看DEVOPS的整個進程怎么產(chǎn)生。首先我們先把開拓和運維都放到一個大包內(nèi)里，它們倆同時認(rèn)真一個可用性的指標(biāo)，這個在職責(zé)上先統(tǒng)一。雖然在DEVOPS初期，運維的孝敬必定大一點，運維說我做雙活，我做儲蓄，我做一些預(yù)案去防備這個系統(tǒng)宕了今后有一些處理的方案。這個時候應(yīng)用照舊很苦的，因為應(yīng)用連不到數(shù)據(jù)庫了，我們找運維說，運維一看數(shù)據(jù)庫是好的，網(wǎng)絡(luò)也沒問題，什么意思？代碼寫的有問題？所以代碼只好打日志，下次再出這個環(huán)境，開拓說沒步伐，還看不出來，我們只好預(yù)打。開拓受不了再往前走，說爽性我們在應(yīng)用層做預(yù)案算了，我們在代碼里能不能界說一些妨礙場景，分派一些錯誤碼，我們再招三千處事人員，遇到錯誤場景一二三四怎么去做。

講到這里，各人應(yīng)該都有一個別會，我們家寬待撥不上去跳出一個碼。運營商很早就在這么干了。因為有了應(yīng)用級的預(yù)案我們的可用性會獲得晉升。再往后，預(yù)案跑的較量不變了，我們能不能把它沉淀到東西，好比說一鍵擴容，好比說一鍵重啟，在呈現(xiàn)問題的時候點這些按紐讓呆板去跑，我們處理懲罰妨礙的時間又會晉升，可用性又會晉升，人肉沉淀到東西。再往后東西也較量不變了，我們能不能寫到代碼里去？把這個處事人員給干掉。碰著問題的時候代碼本身上辦理問題。所以最終我們會發(fā)明，DEVOPS進程就是人肉不絕到東西，東西不絕到沉淀到架構(gòu)的一個進程，所以將來我們就不絕地迭代。

這匯報我們，其實在云計較的時代，開拓和運維是一體的，它們之間是不絕地轉(zhuǎn)換。同時這里有個感悟，我們在互聯(lián)網(wǎng)上看到許多牛的個架構(gòu)、中間件，其實都是慢慢疊加的，其實一開始各人都很人肉。

我們再看下一個問題云計較根基上會帶來一個產(chǎn)物的分層。我們原先大概是一個鐵板，此刻可以看到許多的條理。從端到云，會造成每個運維分手到每一層，中央運維團隊被打散了。每一層都有方才提到的架構(gòu)跟運維兩個部門，而且配合地要向上一層理睬SLA，理睬質(zhì)量。這面內(nèi)里每一層都要按照底下的這層提供的SLA的理睬，再按照本身的質(zhì)量需求去抉擇架構(gòu)和運維到底要怎么做。什么意思呢？好比說我們中間這層處事API，它想做可用，他必然要看這層可以提供應(yīng)它什么樣的可用性，然后再說間隔理睬有多遠，再抉擇在架構(gòu)上做改進，照舊在運維上做增強。這內(nèi)里要小心SLA是有陷阱的，其實在企業(yè)內(nèi)部開拓的許多應(yīng)用是提不出所謂的SLA，對付一些公有云，像一些較量知名的公有云，他們的案例許多，我們認(rèn)為說它提的SLA的可信度很高，我們在這一層需要兩個行動，第一是需要擬定一些類型做準(zhǔn)入，第二還要做質(zhì)量節(jié)制。