由于成本的降低和業務的便捷性，越來越多的企業將自己的IT系統遷移到云端，但在遷移的過程中，面對一個新的環境，從基礎設施的部署到云平臺的挑戰都十分的具有挑戰性，如何保證云遷移的安全？如何減少遷移風險？如何權衡線上穩定性和敏態交付？成為了企業IT管理者十分關注的問題。

今天為我們解答以上問題的嘉賓，是來自浙江移動的云智能平臺運維架構師史軍艇老師。希望通過匯集史軍艇老師的研究成果和實踐經驗，帶大家了解云原生環境下存在的安全問題，規避云上可能會遇到的問題，保障云原生應用的運行穩定性。

史軍艇

浙江移動 云智能中心運維架構師 

• 8年應用優化及SRE經驗，2013年起從事應用運維、穩定性提升、架構優化等工作；專注于穩定性體系建設及分布式系統架構治理。樂于研究新解決方案及新技術。目前負責浙江移動線上系統應用架構治理和穩定性體系建設工作，并作為浙江移動混沌工程負責人，推動中國移動集團內演練方案實施。 

主要觀點

個人認為，要解決這些問題，需要從企業層面建設一套的穩定性體系，包括架構設計、上線變更、故障抵御、線上治理，貫穿整個過程。而這其中表達的意思，穩定性不至于故障抵御，更要往前看，從架構設計開端，去做高價值交付。實踐過程中，我們衍化出一些有效的工程，比如流量回放、灰度發布、混沌工程、平面逃生等，保障了每一個過程的平穩鏈接，確保上云風險降到最低。 

Q1云原生下，如何權衡線上穩定性和敏態交付?

穩態（穩定性）和敏態，就是我們說的雙態模式。我理解應該是敏態催生了云原生，而后云原生又推動了穩定性。正如我們所說，云原生是從傳統“原子時代”跨越到“比特時代”的，它的具體表現形式是容器化支撐+微服務體系，配套而生的就是DevOps和持續交付，而這一切確實都是為了核心業務的快速迭代為出發點的。

因此，我們需要穩定性體系/SRE體系來給予運營端足夠的信心，浙江移動在穩定性方面確實也摸索了很多年，我們算是傳統行業中運維轉型走得比較早的。研發眼中是DevOps，我們眼中就是OpsDev，這兩者并不沖突。在整個穩定性體系中，除了基本的故障抵御體系外，Ops必須要把步子往前邁，邁過上線發布，邁到架構管控及設計，這樣和線上治理組合起來才是一整套交付護航體系。其中涉及到的工程實踐，就會用到灰度發布、混沌工程、多可用區之上的自智網絡能力等，用此去保證交付質量、上線質量和運行質量。

Q2云環境下的災備如何進行設計？

我這里主要聊一下應用服務的災備設計，相信數據庫的變化會相對小一點。對于應用架構，云環境下會涉及到復雜的微服務調用，以及容器云平臺的計算資源控制管控，另外還有公用依賴的一些公共組件。我們會建議企業做雙平面/雙可用區設計，這里的平面縱深會比較深，從容器云的管理（mesos、marathon、k8s），還是公共組件、配置中心、注冊中心、緩存平臺等，當然還包括上層應用，都需要進行雙活雙平面改造。這樣才能在保證流量的前提下，可以在兩套不同的環境下精確倒換、逃生。

像資源相對富足的公司，或者說針對核心業務，愿意再多投入一點點資源的，可以再適配一個10%-20%的小平面，用于形成更為完善的逃生能力、發布能力、演練能力。

Q3相比于傳統災備架構，云環境的災備架構規劃會有哪些異同點？

個人覺得傳統的災備主要考慮的是高可用，我們只要關注雙機房、實例冗余負載等，相對簡單清晰。而如上個問題提到的，云環境下的災備架構考慮的層次會更深，在傳統架構災備要求的前提下，需要貫通每一層的平面級拆分。另外，因為云環境從實例調用層面的可閱讀性會大大降低，所以導致普通的高可用，可能在故障處置上會有一定劣勢。建議采用單元化的設計，從流量入口就具備調度能力，做好準確自動的平面逃生，當然該有的觀測性等配套要求也會更高。

Q4企業原先生產環境復雜，導致上云遷移和業務重構難度大。對此，有什么可參考的落地步驟和技術路線嗎？

研發和SRE兩條腿走路，并且要步調一致，一起走。因為大型系統的上云其實是一個非常大的工程，或者是有較大風險的工程。從研發層面，原有的復雜調用，該拆就拆，從設計方案中，去考慮拆分的可行性，而這個時候，SRE就需要一起參與，通過非功能的視角，去進行紙牌推演、沙盤推演，可以和研發互相pk。從工程保障角度，我們要確保割接方案的快速回退，老的環境并行保存等注意事項。新環境在通過紙牌推演后，進入到上線前的實戰演練驗收，這個時候可以通過回放的流量去模擬驗證。在發布工程中，用灰度的滾動發布模式，確保平滑割接過渡。?