雲計算時代的運維與安全

　　雲計算時代給大家帶了很多機遇，同時也帶來了很多挑戰，有人就認為隨著雲的普及，運維人員將會最終消失。當然，這個論點不免有些偏激，但雲時代的確給運維帶來了很多不同，也讓運維從業人員開始思考很多問題。在近日舉辦的中國運維和安全大會上，我們就欣喜地看到了很多樂意迎接挑戰的同學，也有很多大牛分享了自己的經驗與心得。

　　中國的第一代黑客，現任UCloud CEO的季昕華為大家分析了雲計算時代為運維與安全帶來的挑戰和機會。首先，運維人員要有一些基本的素質要求，其中包括懂風水，在機房選址時是否處於地震帶，吹的什麼風向，當地電價如何都是運維要考慮的;懂網絡，在國內特殊的網絡環境下，要理解南北差異;要有體力，必要時能去機房搬服務器;還要懂操作系統，懂網絡攻擊防御等等……

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

　　懂業務 ，例如要能理解產品的用戶是一線城市還是二線城市，是PC端還是移動端，在對業務有足夠的了解的情況下，才能讓你的工作成為領導關心的事。

　　運營化 ，將運維中的意外管理變為過程管理，並能持續改進、持續優化;運維要能做到四個“第一”，即第一時間發現問題，第一時間定位問題，第一時間解決問題和第一時間反饋問題。

　　系統化 ，要能通過各種系統來輔助運維工作，甚至要能自己開發運維系統。

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

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

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

　　產品不足，開發補，開發不足運維補，運維不足客服補

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

　　底層存儲有以下難點：

　　元數據管理

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

　　修復速度(直接影響存儲系統的可靠性，在七牛恢復是集群任務，盤上數據的副本松散地保存在集群中，目前能做到在十幾分鐘到幾十分鐘內修復2到3T的數據)

　　應對容量的增長

　　可接受的訪問速度

　　合理、有效的緩存

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

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

　　例如，常見的故障有：

　　機房內故障

　　網卡(斷線、降速)

　　網線(斷線、降速)

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

　　機櫃級聯故障

　　機房間故障

　　區域性網絡故障(機房出口斷網)

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

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

　　在網絡安全上，除了必要的基礎防御之外，更重要的是業務層面的防護，公有雲的基本原則是開放，任何服務可以無條件暴露於公網，機房間的交互與客戶無差別，不組VPN。

　　雲存儲構建於基礎存儲之上，它要能提供極高的上傳、下載速度，有極高的可用性，有極高的可靠性，有豐富的附加功能(縮略圖、水印等等)，方便的網絡訪問。

　　它的難點在於：

　　雲存儲屬於終端網絡，它直接面對用戶，情況復雜;它是最外層的接入點，前端沒有機會做遮擋，對各種指標要求高。

　　廣域網基礎設施普遍質量不高，要基於99%可用的基礎設施來提供99.999%的服務。

　　提到基礎設施，機房的網絡是個大問題，網絡延時可以從幾毫秒大到幾千毫秒，吞吐速度從幾十Mbps到幾Kbps，而且帶寬平均成本也不便宜。機房的可用性並不理想，經常會有鏈路故障，甚至是大面積、區域性掉線、降速，不僅機房間有問題，機房內也會頻繁故障，小城市、小運營商用戶會有個例無法訪問的現象(七牛為用戶提供了下載SDK，在APP和Web上連接到本區域節點下載不到內容時，可通過SDK連接備用域名和IP)。

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

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

　　一定要在第一時間發現攻擊的征兆，及時作出反應。

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

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

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

　　架構設計

　　配置要點

　　智能腳本

　　他對比了Squid、Varnish、Nginx、Apache Traffic Server(ATS)和HAProxy的強弱，目前又拍大量使用了ATS，集群規模已經超過200台，ATS的集群功能現在還不完善，可以通過 Nginx在前面做一層一致性Hash的轉發，規避ATS的集群問題。另外他也強調了HAProxy強大的HTTP頭解析能力，是用來充當防御層的合適選擇。可以根據具體的用途進行選擇：

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

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

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

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

　　架構是需要持續改進的，又拍雲的CDN就經過了這樣一個過程：

　　智能DNS區域化(又拍雲負責部署節點，通過DNSPod實現智能節點選擇，自動選擇離用戶最近的節點，以此實現全網加速)

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

　　後端管理不直觀(使用OpenCDN來提供多節點CDN管理平台)

　　CC和DDoS可能會交叉進行，用HAProxy加後端存儲，是應對小流量攻擊的，如果在承受范圍內，可以選擇不切節點，但是如果遇到大流量DDoS攻擊，可以立刻選擇切節點。邵海楊強調到防御DDoS攻擊，要靠技術、靠業務，更要獲取高層的支持 。

　　在講了很多公有雲相關的技術之後，支付寶的章邯為大家帶來了一些與支付寶的私有雲環境有關的內容，他介紹了支付寶私有雲中的以業務為核心的監控產品。

　　在支付寶，除了常規的運維監控和應用監控，還有更多其他的訴求，例如業務監控、合作伙伴監控和SOA環境監控。

　　章邯特別強調了一個概念——業務分析，它在支付寶的監控體系中起著至關重要的作用：

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

　　確定故障范圍——不同的業務特征，代表了不同的故障影響范圍;不同的影響范圍，應急人員有不同的策略

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

　　業務與應用的關系——通過監控不同的業務，可以快速定位故障

　　業務與業務的關系——雖然沒有系統間的直接關系，但業務直接確實有可能會存在相互的影響

　　業務與運維策略的關系——例如，確定機房引流，流量的分配

　　業務與管控策略的關系——管控策略有很多，比如分組、降級、限流和引流，管控策略的制定和業務是息息相關的

　　很多公司都會采用在系統中埋點的做法進行監控，而支付寶則采用了業務分析結合現象分析的做法來進行實時故障應急處理。章邯指出：

　　埋點需要對所有服務器做埋點檢查，而故障的原因是無窮的，往往可以從現象症狀上來判斷故障的原因。

　　隨後，他簡單介紹了一下支付寶內部基於日志的監控解決方案XFlush，其中借鑒了Percolator、Storm、Spark、 HayStack、GFS和RDDS的很多思想。XFlush追求的是低侵入性