多雲管理，愷英實戰之道
講師簡介
徐巍
上海愷英網路科技有限公司
高階總監
剛剛幾位演講嘉賓，一位關注高可用；另外一位關注網路。我現在待的是一家很有特點的公司，整個基礎設施，90%的跑在公有云，也有一些物機房，我認為挺符合現在的混合雲架構，所以我的演講題目是愷英網路的多雲實踐之道。
1.自我介紹和現狀
首先做一下自我介紹，從畢業至今，我一直從事運維及技術保障相關工作，至今十來年，之前是在線上視訊，後續在一些線上交易系統公司，目前在一家遊戲公司，做了很多年的IAAS和PAAS相關的事情，也親歷過數次公司業務從1到100，爆發式增長。
愷英網路是一家有超過10年曆史的遊戲公司，研發和平臺並重，經過多年發展，形成了以研發運營於一體的遊戲平臺，在基礎設施這塊，基於遊戲場景，形成了託管IDC和多公有云的彈性計算平臺。
2. 問題
由於歷史原因，愷英的混合雲環境存在著一些歷史包袱，簡單的來說，就是567，有5個物理託管IDC，6朵雲，7家CDN供應商，定位相對模糊，缺乏頂層規劃，導致有些混亂，管理成本高昂。
這種混亂的狀態就會帶來一些問題：
1、穩定性的問題，某公有云嚴重故障導致公司關鍵業務長時間中斷，還有某IDC掉電導致業務中斷8小時以上；
2、效率的問題，眾所周知，遊戲對速度的要求極高，需要能快速部署，快速上線，而如此複雜的底層環境無法保證高效的資源交付與程式碼上線；
3、成本問題，供應商越多，資源越分散，管理難度越高，就會導致很多不必要的浪費，以及閒置，也不利於商務談判，成本無法做到相對較優。
穩定性問題主要體現在哪些方面呢？這麼多雲，幾乎每年每朵雲都會掛1次或者多次，各個業務分佈在各個雲中，有的還相互有依賴，必然導致故障的概率變得很高。
同時，多種雲，如果都是通過portal操作，必然會涉及到每個人的操作習慣，以及許可權管理等問題，會導致安全、以及標準化導致的影響穩定性的潛在風險。
配置管理也會是問題，人員離職，許可權是否記得回收，上萬伺服器規模下，每天都有機器建立和銷燬，通過頁面和指令碼操作一定沒有未來。
效率問題主要體現在不同人的習慣和熟練度不一樣，成千上萬的機器通過頁面來建立，完全無法保證質量和交付效率，質量不好，重複確認和返工，更會拖慢效率，同時人員的變動，導致操作習慣的變化會出更大的問題。
另外成本問題也不可忽視，去年，我們在線上發現一些機器在那兒閒置著，其中有一臺是有60多T磁碟空間的虛擬機器，因為業務變化，95%的空間都是浪費的，這臺機器一個月的成本是6萬塊，應該閒置了有至少小半年，這就是多少錢了？仔細盤點，你就會發現伺服器、IP、硬碟、物件儲存誰建立的？什麼時間建立的？怎麼建立的？為誰建立的？成本怎麼分攤？這些問題搞不清楚。
3. 多雲之道
解決這些問題要有巨集觀的規則。
1、Design for failure。剛才小米的演講也提過，我經常跟雲供應商溝通，開會的時候，有句話我也經常說：“你們所有的雲都是不可完全信任的，一定會crash的”，我們一定要為失敗而設計，我們的人會犯錯，公有云會掛，程式碼會出BUG，網路會出問題，整個網際網路的架構就是要在這些不確定性因素下，儘量確保可靠性，降低出問題的概率。
2、簡單即好用。所有的東西一定是越簡單越好，越複雜越不可靠。目前愷英有很多的雲和物理託管IDC，我們需要仔細思考，是否真的需要這麼多的雲和物理IDC，這些東西的定位是什麼？能不能做減法？舉一個例子，有很多新的技術、產品和想法，我們要慎重地去評估和考量究竟要不要引入。有時候“用好”一個工具遠遠比用“好的”一個工具重要。
3、只有標準化才有未來，標準化才有自動化，自動化才有平臺，平臺化才有資料，有了架可流動可計算的資料，才有現在大家都在聊的 AIOPS 的可能。
首先我們要思考邊界在哪裡？愷英的業務分幾類，有一類是遊戲業務，其實我沒有遊戲背景，對遊戲相關業務的理解不是很深刻，在座的不知道有沒有遊戲公司的技術？國內的頁遊、手遊裡面存在著一個很有特點的場景，單區單服，一個VM裡面有nginx、C++、cache、db，整個遊戲區服全部的東西都在裡面，使用者訪問的整個生命週期基本都可以在這臺VM裡面完成，無需對外互動，同時單個區服的人數都是有限制的，一般最高3000-5000玩家同時線上。
如果要擴容，就直接再起一臺，這叫scale out，而無需scale up，這種場景的特點主要是相對獨立，同時對全域性可靠性的要求相對較低，單個區服故障不影響其他的節點，也不影響大盤，可做分散式部署，這類需求所需的資源節點我們稱之為邊緣節點。
愷英還有一部分業務是遊戲平臺，它與其他的網際網路應用沒有太大的區別，本質上就是使用者的註冊、登陸、支付等等一系列的東西，對可靠性要求較高，同時也會有大量的互動，並有較高的釋出頻率，基於這些特點，我們把他定位為核心業務，需要放置在核心節點。
再後面，我會簡單地講到康威定律，工作這麼多年，越來越深刻領悟到一切架構的設計與你組織的架構是有密切的關係。如果你組織架構存在著一些混亂和不合理，基於屁股決定腦袋原理，業務架構不可能好得了，這也就是康威定律，後面我會展開來講。
基於以上思考，我們的IAAS架構如下，整個網路分為核心節點和邊緣節點，平臺類的業務全部集中在核心節點上，通過異構雙活確保核心業務可用，資料落地到自建託管IDC，確保資料安全，同時遊戲業務分散到各個邊緣節點，做多雲部署，分散風險，從巨集觀上保證整體的可控。
標準化怎麼做呢？我的建議是就像造房子，從地基打起，一層層的壘，夯實，主要包括機房、網路、伺服器、OS、software、application等等。
舉個例子，server這一層，我們建立了一張資源對映表，愷英內部會有一個自定義伺服器型號，同時和各個公有云的相同配置和效能的伺服器資源建立對映關係，這樣就對使用者遮蔽了各個雲的差異，當然這個對映關係的建立需要經過測試，確保效能和配置，以及價格處在相對一致的水準。
在我的理解裡面，做運維其實歸根到底就是兩件事情： 第一，資源的生命週期管理。一個資源從建立到上線，從故障到恢復，從變更到回收，整個生命週期的管理。而資源包含很多，IP、網路、儲存、域名等等，每一種關鍵資源都需要從整體上收口，從流程上把控，誰能做得更精細，誰就能做得更好，生孩子容易養孩子難，相信在座的諸位爸爸媽媽深有體會。
Workflow，他是一個面向使用者的編排工具，主要目的是規範輸入，讓使用者做選擇題，而不是問答題，本質上而言，它就是一個表單系統，生成你所需要的計算資源、儲存資源或者資料庫資源等等的東西的資訊，併發送給下一個核心應用resource gateway。當然，目前這個工單系統面向的主要使用者是運維，後續會逐步面向研發和業務。
Resource Gateway 是整個多雲自動化體系中很核心的一環，他會遮蔽各個雲的差異，實現對使用者的透明，確保資源建立，並把資料落到CMDB和服務樹，保證所有的資源從生到死是統一收口的，並且是標準化的。
resource gateway 呼叫雲的api建立資源後，會通過作業平臺執行初始化，如安裝監控agent，優化相關核心配置，收集主機資訊等等一系列的操作，確保每一臺經過這個流程交付的機器均滿足生產需求，配置一致，完全可控。
多雲資源管理的整個體系不僅僅只是上面的一塊了，還有大量的相關子系統，如監控體系、日誌、以及各個關鍵資源的管理，如DB，cache，DNS解析、甚至域名備案和證書管理等等，這一切的關鍵是需要確保這些資料在各個系統基於某些流程準確、及時的流動起來，能流轉的資料才是有用的資料，死的資料沒有任何價值，計算機，乃至人類社會，一定要有輸入和輸出，才有價值。
這一塊呢，主要是從各個維度，視覺化的來看資源的使用情況，關注供應商管理和成本就可以從供應商的角度來看，哪些多哪些少；關注業務就會看哪個部門資源多，分佈是怎麼樣的？哪個業務變化比較大？有了這個工具，資源管理員，還有老闆就可以很容易的獲取到巨集觀資源的使用情況，為決策提供資料支援。
剛剛那些東西里面有很多的一些細節，涉及到一些特別重要的東西：資料。怎麼保證這些資料能很好的流動？怎麼及時發現一些異常資料？每個異常資料背後的深刻原因是什麼？這些都需要一個旁觀者去探索和發現，所以我們專門建了巡檢系統，每天或者每週對各個資源，業務的狀態做巡檢，併產生報表。
這些報表可能不是很好看，但是會從各個角度去統計，提供資料，我們就能及時地發現一些程式碼的BUG或者流程的不完善等等之前沒有考慮的問題，不斷FIX它，讓它逐步收斂到我們所期望的狀態，這個事情一定是要先收口再來治理，同時就是一些細節，一點點去扣，一點點治理下去，細節是魔鬼，執行是王道。
容量與成本這一塊，我們還在開發過程中，所以沒有放圖。成本控制這塊我有些思考，一個公司高速增長的階段，之前我覺得成本很重要，現在看起來不是那麼重要了。怎麼說呢，之前我還就職於一家電商公司的時候，整個IAAS建設，兩年花了10個億，花到我心疼的感覺，就經常challenge業務，你為什麼要那麼多資源？能不能程式碼寫好點，少要點資源？後面我才逐漸理解，公司業務高速增長，成本一定要為效率讓步，你省了一個億，也許降低效率，導致公司少融一輪資或者對IPO造成一些麻煩，損失遠遠不止1個億，正確的做法應該是站在全域性思考，後續公司發展到一定的階段或者平穩期，再來齊心協力擠水分。
成本這一塊，關鍵的是需要把成本和利用率關聯起來，從幾個維度來看，從供應商來看，哪個雲的利用率很低？從業務來看，哪個業務的利用率很低，同時成本又比較高，收入還一般？我們需要把這些應用找出來，和業務一起優化。
成本優化是一件對大家都很痛的事情，特別是業務方，很有可能對這個事情有所牴觸，所以需要量化，並且和kpi掛鉤，並通過技術手段給業務方最直接的建議，減少業務調整的成本，並告訴業務你已經節省了多少多少錢，通過紅黑榜push業務，逐步形成一個良好的機制，常態化，而不是運動化。
應用的生命週期這塊，由於主題原因，今天不會展開太多，主要是通過CICD，實現程式碼的持續整合和生產環境部署，並提供給研發自助式使用。很多網際網路公司每天幾百幾千次釋出，運維一般都不太介入，CD的核心能力主要是灰度和一鍵回滾，能效團隊可以基於這個判斷一個團隊的釋出成功率，如果回滾的比例偏高說明是有問題的。
4. 挑戰與應對
剛剛談的是多雲管理的東西。接下來會重點給大家聊聊其他的東西，有了多雲只能解決一部分穩定性、效率和成本的問題。在絕大部分非技術驅動的公司，業務與技術這一塊始終有很多的博弈，技術在短期內往往被高估，長期而言卻會被低估，我所從事的工作是偏向後臺技術的，屁股決定腦袋，我就會認為技術非常重要，但是最近這幾年的經歷，讓我發現業務更重要。
在很多公司，如果你站在CEO的角度來看，技術只是一個支撐的作用，這個時候他不會去關注技術重構的需求，或者有穩定性的需求，站在業務角度來看，就是我要上新的業務，老的業務要變化，這就意味著變更和快速開發，快速迭代，但穩定性的問題其實還在那裡。
看看這張圖片，想象一個場景，一輛在高速上狂奔的汽車，或者一架正在飛行的客機，老闆關注的是跑得快慢，但要想跑得快就要不斷的換輪子和發動機和變速箱，升級配置，重新架構設計，但這個過程車或者飛機還不能停。目前很多大點的公司的CTO其實挺慘，偏向於大中臺，管運維、安全、大資料、架構、中介軟體的，管這一攤偏向於業務支撐的體系，不怎麼碰業務了。在這個過程中，業務的實際需求，和這些需求帶給後端技術的潛在穩定性、效率的需求其實是有些衝突的，從而對雙方產生很多的挑戰。
康威定律和技術債，前天一個頭條的朋友跟我聊一個底層的技術問題，聊完我的感受是這樣的，一個產品或一個應用為什麼能出現？他一定和公司的組織架構有關係，公司的組織架構決定了技術體系的架構甚至於產品的架構，為什麼有一些產品的誕生？因為有組織的誕生。組織一定是分層次和團隊的，每個團隊有自己的核心利益，比如說負責運維的，要做到最好是怎麼樣的，不準變更，一個月或者一個星期變更一次，不準擴容，或者上線什麼業務要通知我，這樣運維可以保證不出問題。
但是業務就活不了，也許業務老闆正在談一輪融資，正在準備IPO上市，業務沒有十倍和百倍的增長，公司就死掉了。所以一定要從全域性來看，站在老闆的角度或者更高的角度來看問題。為了全域性，區域性要做一些妥協，我們要全域性最優，而不是區域性最優。
做技術的人，很多人都是完美主義者，我要把技術做得很牛，我要把產品逐步迭代達到一個很理想的狀態。學過經濟學的人會發現一個問題，一個叫“邊際”的概念，你考試的時候從30分到60分隨便弄弄就可以了，從60分到90分要努力，再從90分到100分不容易，你的邊際成本是遞增的，邊際收益是遞減的，這裡有一個“二八原則”，80%的問題一般都是20%的因素導致，抓大放小即可。
前幾年，我還是有一點技術潔癖的，因為某些技術問題，我會跟老闆吵架，要資源來做現在看起來收益很小但投入很多的事情，當時總被老闆challenge，現在回過頭來想，技術債一定要有的，為什麼呢？有債務就是借用了槓桿的力量，給業務更好的支撐了。技術債的關鍵在於什麼？程式碼的重構和架構的更新是不是要繼續，說白了就是利息是否還得上，利息還得上，這個債就不會導致整個資金鍊的斷裂，技術人員，特別是技術管理者需要做好這個平衡。
舉個例子，我們的網站發生了什麼很嚴重的故障，導致整個網站宕機。你作為CTO，你去跟老闆談，現在技術難度很大，可能三五個月把網站停止更新和釋出，你看哪個老闆會同意？如果你跟老闆說，保障業務的同時，做重構和業務更新，老闆說，你去弄吧，他才不關心你要不要重構呢，只要不影響業務就行，所以 要不要重構，要不要還債是CTO和技術要自己想好，並平衡好和業務的關係。
如果大家關注新聞的話，就會發現今年以來，市面上常見的各大雲廠商都掛了1到數次了，所以請大家記住一句話，所有的雲都是不靠譜的，宕機一定會發生的，一定不能有單點，不能把自己的身家性命寄託在別人的手裡，特別是單獨的某一家。
防禦性程式設計有很多的東西，比如說我們的業務一定要有關鍵路徑與非關鍵路徑區分，主路徑怎麼理解？不可降級。如線上交易系統的下單、支付不可降級，非關鍵路徑是哪些？如風控(金融行業這塊應該是關鍵路徑)，風控服務出現問題，可以臨時把他降級掉，業務支付的時候不再過風控稽核。 限流，各個電商公司在具備一些活動的時候從客戶端，到服務端都需要都一些限流控制，確保核心服務不會被突發性流量壓垮，能在極端情況下提供有損服務。
降級與熔斷，我的理解就是一前一後，降級在事前，熔斷在事後，降級就是大促的時候先把非關鍵路徑的部分服務降級，減少業務處理鏈條的長度，而熔斷是在業務層有一些防禦措施，如說多次請求之後就不再請求，避免雪崩。同時，還需要有一些補償與恢復的預案，在真正發生問題時，有一些補償和業務機制，特別是一些公司做了雙活，一定有概率會發生資料髒掉的情況，如果這樣怎麼辦，一定要先想好。依賴和被依賴這塊呢，我之前有一次很深刻的經歷，業務的主路徑做了很多的優化，沒有問題，但是卻被一個非主路徑業務異常給拖死了，關鍵路徑依賴了非關鍵路徑導致整個服務的不可用。
監控和告警，這個東西的重要性不言而喻，就像一輛汽車只有底盤、剎車、發動機與變速箱是不夠的，你還需要速度表，油量表，還有後視鏡等等配套的裝置，也就是監控系統，監控本身不難，不管是zabbix，還是prometheus，各種監控工具都發展得比較成熟了，關於在告警，如何避免被告警淹沒？如何精準定位？這一塊還有很長的路要走。
現在很多人提AIOPS，AIOPS在運維領域目前有兩個地方比較好實施：一是監控；二是基於利用率和成本分析，來指導機型或者容器顆粒度優化，以及採購分析這一塊。有些公司，如阿里等有在做類似這樣的事情。告警這一塊我們也還只是做一些簡單告警收斂，聚合等等，還做不到告警的智慧化判斷，還有很長的路要走。
Chaos monkey與SOP，我們公司業務相對簡單一點，並且經過前期的治理，已經具備災備演練的實施能力，目前每個月會做一些故障演練，舉個例子，一個業務有很多的應用，我們稱之為APP，你可以以業務為單元，一組APP為整體做一些跨機房演練，逐個業務的演練。這裡我們發現了一個大bug，有一天我們做整體的機房級演練，做了故障模擬後，突然發現整個運維平臺不可用了，更不要談進行機房級業務切換，後面仔細覆盤。
發現整個演練涉及到很多運維工具的切換，甚至包括VPN、SSO等基礎服務的跨機房可用，這些東西都是基於運維平臺的，於是我們啟動了運維平臺的演練，從VPN到堡壘機，從DNS服務到SSO，再到監控系統，DB管理系統，這些東西都要做到長期的演練。
談多雲管理，安全還是要提兩句。年前我有被上海市信管局的人叫過去喝茶了，為什麼呢？因為信管局，網信辦，還有工信部目前對網際網路安全的要求越來越高了，而隨著新的《網路安全法》的頒佈與實施，發生大規模資訊洩露等安全問題會對公司，和相關人員造成很嚴重的影響，最惡劣的情況是公司網站關停，相關人員蹲監獄了，所以這個時候一定要深刻理解安全，保護好公司，也保護好自己。
至於安全怎麼做，我只能算半個門外漢了，總體而言，從組織架構上對安全加以重視，從流程制度上樹立頂層框架，建立起事前預防，事中緊急處理預案，事後覆盤改進的技術解決方案，同時和公司內部PR，業務各個部門做好協調，同外部白帽子、信管局等各個相關人員處理好關係，形成良性的治理環境，邊收口邊治理，踏雪有痕。
說故障之前，我想說幾句話，聰明的人看別人跌倒了，自己不跌倒；一般的人是自己跌倒，爬起來不再跌倒；愚蠢的人一而再再而三地跌倒。
故障發生了後，我們一定要查詢根因是什麼？是流程的問題？技術的問題？還是人的問題？人肯定是會犯錯，是意識問題還是能力問題？有沒有辦法減少人犯錯的可能性？很多公司或者團隊都做過這麼一個事情，某一個人操作失誤導致故障，於是改進方案就是再找一個人做double check，還要簽字什麼的，這種手段短期相對有效，長期一定無效，一定要通過技術手段或者流程，配合不斷的意識上強化責任心來解決，我們相信我們的小夥伴，同時也明確人會犯錯，但需要儘量減少。
整體來說，一個技術團隊的很重要就是工程師文化的培養和積累，熱愛技術，希望用技術解決問題，同時注重文件和不斷的覆盤，你們將戰無不勝！
5. 一點心得
未來的雲都是基礎設施，像水和電一樣，單純做IAAS或者Paas的人會越來越少。而作為技術人員，需要關注底層，關注業務，關注資料，用資料說話，才能體現自己的價值。舉個例子，這個業務跑得有點不好，什麼叫好，什麼叫不好，一切東西都要可量化，不量化的東西都是耍流氓。Design for failure，康威定律，還是回到人的架構，組織架構要合理，權責要明晰對等，業務架構層次化，邊界要相對清晰，中間連線可控，否則這個過程要不斷抽象迭代，會比較麻煩。
最後一句話送給大家“未長夜痛哭者，不足以語人生”。在你經歷過痛徹心肺的傷痛後，在一次次跌倒爬起後，請記住，所有光鮮亮麗的背後一定是苦難。
說明：以上為上海愷英網路科技有限公司高階總監徐巍在 GOPS 2019 · 深圳站的分享。
DOIS 2019 · 北京站，DevOps 落地，從這裡開始
7月5日~6日，我們在北京等您~
點選閱讀原文，立即訂票