云計算時代給大家?guī)Я撕芏鄼C遇，同時也帶來了很多挑戰(zhàn)，有人就認為隨著云的普及，運維人員將會最終消失。當(dāng)然，這個論點不免有些偏激，但云時代的確給運維帶來了很多不同，也讓運維從業(yè)人員開始思考很多問題。在近日舉辦的中國運維和安全大會上，我們就欣喜地看到了很多樂意迎接挑戰(zhàn)的同學(xué)，也有很多大牛分享了自己的經(jīng)驗與心得。

　　中國的第一代黑客，現(xiàn)任UCloud CEO的季昕華為大家分析了云計算時代為運維與安全帶來的挑戰(zhàn)和機會。首先，運維人員要有一些基本的素質(zhì)要求，其中包括懂風(fēng)水，在機房選址時是否處于地震帶，吹的什么風(fēng)向，當(dāng)?shù)仉妰r如何都是運維要考慮的;懂網(wǎng)絡(luò)，在國內(nèi)特殊的網(wǎng)絡(luò)環(huán)境下，要理解南北差異;要有體力，必要時能去機房搬服務(wù)器;還要懂操作系統(tǒng)，懂網(wǎng)絡(luò)攻擊防御等等……

　　可是大多數(shù)運維人員在公司中的地位不高，而且在行業(yè)中的薪資相對偏低，究其原因還是因為運維的從業(yè)門檻低，大家對運維的認知度不高。因此，季昕華認為，除了上述基本知識，運維人員還因具備以下三方面的素質(zhì)：

　　懂業(yè)務(wù) ，例如要能理解產(chǎn)品的用戶是一線城市還是二線城市，是PC端還是移動端，在對業(yè)務(wù)有足夠的了解的情況下，才能讓你的工作成為領(lǐng)導(dǎo)關(guān)心的事。

　　運營化 ，將運維中的意外管理變?yōu)檫^程管理，并能持續(xù)改進、持續(xù)優(yōu)化;運維要能做到四個“第一”，即第一時間發(fā)現(xiàn)問題，第一時間定位問題，第一時間解決問題和第一時間反饋問題。

　　系統(tǒng)化 ，要能通過各種系統(tǒng)來輔助運維工作，甚至要能自己開發(fā)運維系統(tǒng)。

　　目前擺在大家面前有幾個瓶頸，第一是成長空間有限，在公司的地位不高，行業(yè)內(nèi)的知名度也不高;第二是云計算可能會革掉很多運維人員的名，很多小的初創(chuàng)企業(yè)甚至都不需要運維;第三是人員轉(zhuǎn)型困難大。

　　當(dāng)然，機會也有不少，比如，互聯(lián)網(wǎng)正在快速地改變傳統(tǒng)行業(yè)，之前興起的O2O浪潮就是很好的例子，運維人員可以幫助那些傳統(tǒng)行業(yè)快速地成長;大數(shù)據(jù)的到來也為大家打開了一扇窗戶;另外就是云計算，當(dāng)你能把一個行業(yè)做精做細，就能把它挖掘成一個產(chǎn)業(yè)，例如又拍云、DNSPod、監(jiān)控寶和安全寶都是最好的例子。

　　季昕華建議大家在使用那些免費的運維服務(wù)時，如果可以，就更多地向他們付費，讓公司知道運維也是有價值的。當(dāng)臺下有開發(fā)的同學(xué)問到該如何幫助運維同學(xué)時，幾位嘉賓都講到了如果能夠做到DevOps那是最好的，不要再出現(xiàn)這樣的情況：

　　產(chǎn)品不足，開發(fā)補，開發(fā)不足運維補，運維不足客服補

　　既然云是本次大會的一個重要主題，那自然少不了云存儲的內(nèi)容。來自七牛的韓拓為大家介紹了七牛在建設(shè)云存儲方面的一些做法，他的分享分為兩部分——底層存儲和構(gòu)建于前者之上的云存儲，兩者在設(shè)計上有著截然不同的地方。

　　底層存儲有以下難點：

　　元數(shù)據(jù)管理

　　對冗余度的控制(副本的數(shù)量與成本的平衡點)

　　修復(fù)速度(直接影響存儲系統(tǒng)的可靠性，在七?；謴?fù)是集群任務(wù)，盤上數(shù)據(jù)的副本松散地保存在集群中，目前能做到在十幾分鐘到幾十分鐘內(nèi)修復(fù)2到3T的數(shù)據(jù))

　　應(yīng)對容量的增長

　　可接受的訪問速度

　　合理、有效的緩存

　　七牛在網(wǎng)絡(luò)上采用了常規(guī)的千兆局域網(wǎng)，這是考慮到了它的成熟度和成本，在機柜之間無法保證任意兩點間隨時都是千兆，甚至無法保證全聯(lián)通，而機房之間的速度，帶寬成本很高，速度與連通性都無法保證。因此，數(shù)據(jù)存儲的位置需要有一定的平衡，副本在同一機柜和不同機柜各有利弊，機房亦是如此。

　　在故障方面，除了要將故障視為常態(tài)，更要能明確地知道要面對哪些故障，它們的成因、概率和影響范圍。

　　例如，常見的故障有：

　　機房內(nèi)故障

　　網(wǎng)卡(斷線、降速)

　　網(wǎng)線(斷線、降速)

　　交換機(整體故障、單口故障、VLAN故障)

　　機柜級聯(lián)故障

　　機房間故障

　　區(qū)域性網(wǎng)絡(luò)故障(機房出口斷網(wǎng))

　　DNS解析故障(服務(wù)器之間DNS)

　　對于機房內(nèi)的故障，不需要投入太多的資源成本做額外的高可用方案。

　　在網(wǎng)絡(luò)安全上，除了必要的基礎(chǔ)防御之外，更重要的是業(yè)務(wù)層面的防護，公有云的基本原則是開放，任何服務(wù)可以無條件暴露于公網(wǎng)，機房間的交互與客戶無差別，不組VPN。

　　云存儲構(gòu)建于基礎(chǔ)存儲之上，它要能提供極高的上傳、下載速度，有極高的可用性，有極高的可靠性，有豐富的附加功能(縮略圖、水印等等)，方便的網(wǎng)絡(luò)訪問。

　　它的難點在于：

　　云存儲屬于終端網(wǎng)絡(luò)，它直接面對用戶，情況復(fù)雜;它是最外層的接入點，前端沒有機會做遮擋，對各種指標(biāo)要求高。

　　廣域網(wǎng)基礎(chǔ)設(shè)施普遍質(zhì)量不高，要基于99%可用的基礎(chǔ)設(shè)施來提供99.999%的服務(wù)。

　　提到基礎(chǔ)設(shè)施，機房的網(wǎng)絡(luò)是個大問題，網(wǎng)絡(luò)延時可以從幾毫秒大到幾千毫秒，吞吐速度從幾十Mbps到幾Kbps，而且?guī)捚骄杀疽膊槐阋?。機房的可用性并不理想，經(jīng)常會有鏈路故障，甚至是大面積、區(qū)域性掉線、降速，不僅機房間有問題，機房內(nèi)也會頻繁故障，小城市、小運營商用戶會有個例無法訪問的現(xiàn)象(七牛為用戶提供了下載SDK，在APP和Web上連接到本區(qū)域節(jié)點下載不到內(nèi)容時，可通過SDK連接備用域名和IP)。

　　七牛對數(shù)據(jù)進行了跨機房冗余，除了可靠性，更多地是為了可用性考慮;數(shù)據(jù)同步采用了分級異步同步的策略，最熱的數(shù)據(jù)秒級異步同步，而冷數(shù)據(jù)則會批量同步;成本方面，冗余度的提升并未造成線性的成本提升，同時，異步同步還能智能地利用昂貴的帶寬資源。

　　提供云存儲的又拍云，為大家?guī)砹伺cCDN與DDoS防御方面的一些經(jīng)驗。邵海楊先是介紹了兩種DDoS的主要攻擊類型，即緩慢性CC攻擊和致命流量攻擊，在他的日常工作中，遇到較多的是后者，來得快去得也快，不差錢的主經(jīng)常選擇這種方式。他指出：

　　一定要在第一時間發(fā)現(xiàn)攻擊的征兆，及時作出反應(yīng)。

　　黃冬曾經(jīng)表示過，要防御DDoS，直接交給CDN就行了。邵海楊的觀點與他不謀而同，自建CDN有以下考量：

　　硬件成本(1U的機箱放多塊主板，成本大約在一萬五到兩萬之間)

　　帶寬成本(雙線帶寬貴，做CDN加速不需要雙線，只需要單線機房即可，每兆大約只需1塊多)

　　架構(gòu)設(shè)計

　　配置要點

　　智能腳本

　　他對比了Squid、Varnish、Nginx、Apache Traffic Server(ATS)和HAProxy的強弱，目前又拍大量使用了ATS，集群規(guī)模已經(jīng)超過200臺，ATS的集群功能現(xiàn)在還不完善，可以通過 Nginx在前面做一層一致性Hash的轉(zhuǎn)發(fā)，規(guī)避ATS的集群問題。另外他也強調(diào)了HAProxy強大的HTTP頭解析能力，是用來充當(dāng)防御層的合適選擇?？梢愿鶕?jù)具體的用途進行選擇：

　　反向代理(路由加速，隱藏主節(jié)點)：HAProxy>Nginx>Varnih>ATS>Squid

　　緩存加速(靜態(tài)加速、節(jié)省帶寬、邊緣推送)：ATS>Varnish>Squid>Nginx>HAProxy

　　防御功能(快速解析、過濾匹配)：HAProxy>Nginx>ATS>Squid>Varnish

　　此外，選擇的系統(tǒng)最好還要能支持文件讀取和匹配，支持熱加載生效和可插拔式的緩存組件靈活組合。

　　架構(gòu)是需要持續(xù)改進的，又拍云的CDN就經(jīng)過了這樣一個過程：

　　智能DNS區(qū)域化(又拍云負責(zé)部署節(jié)點，通過DNSPod實現(xiàn)智能節(jié)點選擇，自動選擇離用戶最近的節(jié)點，以此實現(xiàn)全網(wǎng)加速)

　　大規(guī)模日志分析(如何從日志中提取惡意代碼進行分析?又拍云在Nginx中增加了一個模塊，將最近的URL保存在內(nèi)存中，以便實時分析，此外還有一個Hadoop集群分析日志)

　　后端管理不直觀(使用OpenCDN來提供多節(jié)點CDN管理平臺)

　　CC和DDoS可能會交叉進行，用HAProxy加后端存儲，是應(yīng)對小流量攻擊的，如果在承受范圍內(nèi)，可以選擇不切節(jié)點，但是如果遇到大流量DDoS攻擊，可以立刻選擇切節(jié)點。邵海楊強調(diào)到防御DDoS攻擊，要靠技術(shù)、靠業(yè)務(wù)，更要獲取高層的支持 。

　　在講了很多公有云相關(guān)的技術(shù)之后，支付寶的章邯為大家?guī)砹艘恍┡c支付寶的私有云環(huán)境有關(guān)的內(nèi)容，他介紹了支付寶私有云中的以業(yè)務(wù)為核心的監(jiān)控產(chǎn)品。

　　在支付寶，除了常規(guī)的運維監(jiān)控和應(yīng)用監(jiān)控，還有更多其他的訴求，例如業(yè)務(wù)監(jiān)控、合作伙伴監(jiān)控和SOA環(huán)境監(jiān)控。

　　章邯特別強調(diào)了一個概念——業(yè)務(wù)分析，它在支付寶的監(jiān)控體系中起著至關(guān)重要的作用：

　　實時BI——有時不是為了排查故障，而是為了確認沒有問題

　　確定故障范圍——不同的業(yè)務(wù)特征，代表了不同的故障影響范圍;不同的影響范圍，應(yīng)急人員有不同的策略

　　業(yè)務(wù)與合作伙伴——比如銀行，單個銀行下跌，可能是銀行的問題，所有銀行下跌，可能是支付寶的問題

　　業(yè)務(wù)與應(yīng)用的關(guān)系——通過監(jiān)控不同的業(yè)務(wù)，可以快速定位故障

　　業(yè)務(wù)與業(yè)務(wù)的關(guān)系——雖然沒有系統(tǒng)間的直接關(guān)系，但業(yè)務(wù)直接確實有可能會存在相互的影響

　　業(yè)務(wù)與運維策略的關(guān)系——例如，確定機房引流，流量的分配

　　業(yè)務(wù)與管控策略的關(guān)系——管控策略有很多，比如分組、降級、限流和引流，管控策略的制定和業(yè)務(wù)是息息相關(guān)的

　　很多公司都會采用在系統(tǒng)中埋點的做法進行監(jiān)控，而支付寶則采用了業(yè)務(wù)分析結(jié)合現(xiàn)象分析的做法來進行實時故障應(yīng)急處理。章邯指出：

　　埋點需要對所有服務(wù)器做埋點檢查，而故障的原因是無窮的，往往可以從現(xiàn)象癥狀上來判斷故障的原因。

　　隨后，他簡單介紹了一下支付寶內(nèi)部基于日志的監(jiān)控解決方案XFlush，其中借鑒了Percolator、Storm、Spark、 HayStack、GFS和RDDS的很多思想。XFlush追求的是低侵入性、增量計算、不保存原始數(shù)據(jù)、保證時效性、保證數(shù)據(jù)準(zhǔn)確性、保證可擴展性、避免冗余計算和計算邏輯可擴展性。為了實現(xiàn)上述內(nèi)容，甚至還實現(xiàn)了一套定制的分布式文件系統(tǒng)XStore，它的特點是能夠無限擴展，純粹為周期統(tǒng)計計算和固話監(jiān)控點常見而定制，能做到極低的IO，提供高速、無IO的元數(shù)據(jù)檢索。

　　數(shù)據(jù)庫的運維也是運維的重要工作，作為一個運維大會，自然少不了數(shù)據(jù)庫相關(guān)的內(nèi)容，ThinkInLAMP創(chuàng)始人馬駿和MySQL技術(shù)專家金官丁分別為大家?guī)砹撕芏郙ySQL數(shù)據(jù)庫運維相關(guān)的經(jīng)驗分享。而來自金山網(wǎng)絡(luò)的安全專家趙閩還和大家講述了很多與Android安全相關(guān)的故事，在一個個的故事里讓大家感到移動端的安全也是個重要的領(lǐng)域，金山的火眼系統(tǒng)值得關(guān)注。