1. 背景
某政務雲平臺某雲區由於滿足某政府機構合規考核要求及業務開展的需求，需要在年底前完成專有云版本v3.8到v3.12的升級。由於兩個版本的雲管平臺不一致（v3.8對應DTcenter，v3.12對應ASCM），且作為用戶接觸雲產品控制檯的入口，絕大部分的雲產品管控功能都需要接入雲管平臺實現，所以雲管平臺上的任何變化都會直接影響用戶體驗。經過初步測試，該雲平臺上線各產品在ASCM雲管平臺上存在86個關鍵功能點與DTcenter不一致，該雲平臺運維常用的603個功能點中ASCM上有104個功能相比DTcenter缺失，且在多個場景下DTcenter用戶遷移到ASCM後存在權限不一致的風險。基於以上原因，升級過程中雲管平臺DTcenter到ASCM的平滑切換成為了整個升級過程中的最大挑戰之一，該項工作順利與否將直接影響該政務雲平臺各局點的平臺版本升級進度和客戶業務使用穩定度。
2.風險點分析
和其他項目相比，該政務雲平臺各廳局用戶對DTcenter的使用深度和依賴度更高，現有的遷移方案無法有效支撐該雲平臺的雲管平臺遷移，深入對比兩個平臺的差異並評估差異帶來的風險就成了優先級最高的工作。在全面瞭解ASCM後，根據雲平臺用戶對DTcenter的使用情況我們識別出了以下幾類關鍵風險點。
2.1 切換過程不支持雙跑、回退
問題描述：根據現有的遷移方案，在進行遷移時不支持同個產品在兩個雲管平臺雙跑且雲產品遷移到ASCM後沒有回退DTcenter方案，一旦出現無法預知的嚴重問題時可能會因為沒有備用方案遭到用戶投訴。
解決方案：通過申請演練環境，組織升級遷移演練來直接模擬生產環境的實際情況，通過測試提前預知可能的風險，並與ASCM團隊溝通要求在切換過程中得到高優先支持。
2.2 未對深度使用DT權限體系的場景進行測試
問題描述：從ASCM提供的遷移測試報告來看，之前的測試主要在驗證遷移數據的正確性，而沒有對遷移後的用戶使用體驗和複雜權限問題進行充分驗證；該政務雲平臺各局點對於DTcenter權限體系深度使用，用戶權限控制相比其他項目嚴格很多，權限範圍有任何擴大或縮小都會受到用戶挑戰。
解決方案：通過深入瞭解ASCM的權限體系來模擬對比遷移前後同一個賬號對相同雲產品資源的權限差異，具體評估方法在下文詳述。
2.3 不滿足雲平臺安全需求
問題描述：雲平臺安全等保需要雲管平臺具備用戶敏感信息加密和雙因素認證功能，在v3.12上ASCM不具備上述安全功能，且組織安全管理員權限不符合雲平臺使用場景。
解決方案：推動ASCM團隊在hotfeature中增加相關安全功能。
2.4 兩個雲管平臺功能存在較大差異
問題描述：DT和ASCM是兩個團隊在專有云不同版本上輸出的兩個不同產品，雖然都是雲管平臺，但從雲產品功能到平臺自身功能都有很大差異，如果直接切換會給存量用戶的使用帶來非常直接的影響，如果影響範圍過大會直接導致用戶投訴。
解決方案：通過全面對比DTcenter和ASCM間的功能差異點來挖掘雲平臺應用場景中的關鍵差異，重點關注ASCM相比DTcenter缺失的功能，具體評估方法在下文詳述。
2.5 遷移過程中存在雲管平臺與雲產品版本不一致的情況
問題描述：集測團隊給出的升級策略和ASCM團隊給出的遷移策略中，各雲產品的升級/遷移順序之間有衝突，兩個團隊對齊給出整體方案後，我們發現在升級遷移過程中部分產品需要升級到高版本後在低版本的DTcenter上使用一段時間後才能進行遷移，但沒有人保證所有產品在升級到3.12後在DTcenter上依然可用。
解決方案：與集測團隊對接獲取已知在低版本DTcenter上不可用的雲產品，儘量在升級後立刻切換到ASCM上使用。要求ASCM團隊提供雲產品升級後DTcenter不兼容應急方案，以備不時之需。
2.6 切換後與雲平臺運營平臺的對接
問題描述：雲平臺的研發團隊為該雲的運營開發了運營平臺進行雲產品的運營管理工作，該平臺之前直接對接DTcenter，雲管平臺切換後需要重新與ASCM對接。
解決方案：聯繫雲平臺研發團隊儘早整理切換內部風險，與ASCM產品團隊提前對接需要的接口和數據，在產品升級後能平滑對接到ASCM，不影響正常使用。
3.功能兼容滿足度評估
由於DTcenter與ASCM是兩個版本的兩個完全不同的雲管平臺，兩者的功能差異大是可想而知的，所以需要進行功能兼容滿足度評估來確認切換到ASCM後平臺依然支持用戶常用功能，避免因重要功能下線導致用戶投訴。
從功能兼容角度來看，DTcenter切換ASCM過程中主要涉及雲產品功能兼容和控制檯自身功能兼容兩方面，應主要從ASCM與DTcenter功能差異對比出發，重點關注有哪些功能是DTcenter具備而ASCM目前不具備的，結合一線同學的評審意見來評估功能兼容滿足度，最後得出功能兼容滿足度的整體結論。
3.1 雲產品功能兼容滿足度
由ASCM與各雲產品接入關係圖可以看出，已接入ASCM的雲產品控制檯可分為三大類：OneConsole類控制檯、自研類控制檯和跳轉類控制檯。其中，跳轉類控制檯雲產品在DTcenter和ASCM上都是跳轉到自己的獨立控制檯上操作使用，無需關注其功能兼容性。自研類控制檯為ASCM自主開發，這類產品的前端功能由ASCM團隊完全負責；OneConsole類控制檯使用OneConsole架構，這類產品的前端功能主要由各產品自行控制，涉及權限或用戶等信息的需要ASCM共同配合。
圖1：專有云v3.12 ASCM對接雲產品控制檯方案
3.2 控制檯自身功能兼容滿足度
除了接入雲產品的功能外，雲管平臺本身也有很多用戶依賴的權限，包括首頁展示、組織用戶管理、日誌報表、運營計費、監控報警、任務工單等多個方面，需要根據每個項目的實際情況評估差異帶來的影響。對於雲平臺的用戶使用場景來說，v3.12上ASCM不支持或存在缺陷的重要功能包括系統報表、操作日誌和部分重要監控項，已推動ASCM團隊在hotfeature版本中解決上述問題。
4.權限體系切換評估
與功能差異相同，DTcenter與ASCM在權限體系上的差異也是很大的。客觀來說，ASCM相比DTcenter的權限體系在安全程度和合理性上更進一步。但云平臺項目切換工作的痛點在於，對DTcenter權限體系的深度使用導致用戶的某些使用習慣在ASCM的權限體系中被認為是不合理的，然而強行改變存量用戶資源或功能的使用權限又會被用戶挑戰甚至投訴。兩個雲管平臺間的差異主要有以下幾點：
4.1 角色權限
雖然在進行平臺切換時DTcenter上的賬號角色會被映射到ASCM上，但兩個雲管平臺上的同名角色對相同雲產品的權限並不完全相同，主要體現在資源使用人、資源監察員、組織安全管理員這三類角色中。
影響舉例：資源使用人在ASCM上對於NAS產品權限組、數據庫產品變更配置等等多個產品權限與DTcenter上的權限不一致。
解決方案：使用自定義角色替代ASCM預置角色。ASCM提供了自定義角色功能，可以按照每個項目不同的需求量身訂做不同的角色權限，只需要在遷移時使用遷移工具將DTcenter預置角色制定映射到自定義角色，再根據實際需求修改自定義角色中的權限點就可以了。
4.2 三權分立
ASCM的權限體系中，三權分立的概念是與DTcenter權限體系差異比較大的部分。在這裡“三權”分別指：平臺管理員(super)、運營管理員(admin)和安全類角色，這三類角色的分工和菜單各不相同。平臺管理員(super)負責實現控制產品菜單、運營管理員賬號創建和雲產品規格管理等雲管平臺管理配置功能，運營管理員(admin)負責管理組織用戶和雲產品資源等日常運營工作，安全類角色負責使用安全類雲產品和操作日誌審計。
影響舉例：DTcenter中admin賬號可以對所有賬號賦任何權限，而在ASCM的三權分立體系下admin賬號只能授權自己有權限的雲產品和管理類菜單，像操作日誌這樣的安全類菜單權限只能由安全類角色控制，導致原來大部分可以查看操作日誌的用戶遷移ASCM後都無法看到操作日誌菜單入口。
解決方案：由於操作日誌涉及安全審計，ASCM這樣較嚴格的權限控制較DTcenter更加合理。可以在遷移前收集用戶需求，甄別確實有查看操作日誌需求的用戶，為這些用戶授予組織安全管理員或其他安全類角色，使這些用戶可以在需要使用操作日誌時切換到安全類角色正常使用。
4.3 權限分離
ASCM努力進行控制檯權限與數據面權限的分離，控制檯權限即在ASCM上進行的操作，數據面權限即使用ak進行的操作。接入AS-API的產品控制檯權限不再受RAM控制，由ASCM的角色權限點控制，數據面權限全部由RAM控制，這也是ASCM承諾不影響用戶業務的原因。另外，未接入AS-API的產品並未進行權限分離，使用方式與DTcenter相同，全部權限由RAM控制。
影響舉例：切換到ASCM後OSS授權發生改變，不再將添加進項目中的賬號進行自動RAM授權。
DTcenter上的賬號被加入到項目後會自動被賦予該項目下所有OSS的RAM權限，而ASCM認為這樣的操作會增加業務層的安全風險，賬號在ASCM上被加入項目後只應該有控制檯相關權限而不應該有RAM權限。
解決方案：在項目中添加新的賬號後如果子賬號有需求則主賬號為子賬號進行手動RAM授權。ASCM在3.12 hotfeature中還增加了數據權限功能，因此還可以在數據權限界面為子賬號進行白屏授權，不過該功能目前支持的雲產品有限，大多數產品的RAM授權還是需要依賴RAM角色管理。
4.4 項目隔離
項目隔離本身在DTcenter上也存在，是指雲產品資源只能歸屬於一個項目，其他項目成員即使屬於同個部門下也無法訪問和使用該資源。但在DTcenter上，以大數據、中間件等雲產品為代表的跳轉類產品中項目隔離並未實現，普遍只做到了部門隔離，即同部門下所有項目內成員都能訪問和使用同一個資源。由於ASCM通過as-api接入了更多產品的控制檯權限，所以相比DTcenter更多雲產品有了項目隔離的概念，包括datahub、blink、ACK、MQ、ADS等。這些產品在DTcenter上只進行了部門隔離，可能會被作為同部門下多個項目的共用資源，但在ASCM的項目隔離情況下就只能歸一個項目單獨使用。
影響舉例：datahub資源proj1在DTcenter上直接歸屬在部門X下，同部門的A項目中的a賬號和B項目中的b賬號在授權後都可以使用proj1。遷移到ASCM後proj1只能歸屬在X部門的一個項目下，a和b不能同時在控制檯上使用proj1。
解決方案：根據業務梳理共用資源，將共用資源歸屬到一個新的項目中，再將原來需要跨項目共用一個雲資源的賬號加入共用資源所在的項目中。
5.切換過程
雖然從操作角度講升級和遷移互不影響，但從用戶接受度出發，產品分批遷移至ASCM一定比一次性全部遷移更容易適應且影響更可控，這樣升級和遷移就是互相伴隨的過程。在此介紹雲平臺場景下從專有云v3.8.2 DTcenter切換到v3.12 ASCM的過程，其他版本的DT切換ASCM過程可能略有不同，需要聯繫ASCM團隊確認。
（1）底座升級到v3.12。
（2）增量部署V3.12 ASCM及相關組件。
（3）部署數據遷移工具。
（4）企業中心數據遷移：利用數據遷移工具將組織、資源集、賬號、用戶、角色&權限從DTcenter遷移到ASCM，保證跳轉類雲產品在底座+雲產品升級到v3.12版本後在ASCM上繼續可用。
（5）按照升級遷移順序對各雲產品進行升級和遷移。
（6）DTcenter配額、報警規則遷移。
（7）雲產品升級、DTcenter切換ASCM完成。
注意事項
（1）同一款雲產品不能在兩個雲管平臺同時使用，建議遷移前在ASCM上關閉所有云產品菜單，每遷移一個產品在ASCM上將該產品菜單開啟，基本功能測試通過後立即關閉DTcenter上的產品菜單。
（2）跳轉類產品的數據不在雲管平臺存放，所以這類產品無需遷移，升級後可直接在ASCM上使用。
（3）產品分批遷移過程中如果有新建賬號的需求需要在DT上先開通賬號然後使用遷移工具推送到ASCM。
（4）企業中心數據遷移後需要修改tag參數以改變跳轉產品的登錄鑑權。
（5）已知在升級後無法在低版本DTcenter上使用的雲產品有：dataworks、ACK、Blink、QuickBI、ADS，這部分產品需要儘快切換到ASCM上。
（6）用戶數據加密功能需要在所有遷移工作完成後開啟。
6.結語
經過3個月的評估、準備、演練等前期準備，某政務雲平臺該雲區在v3.8升級到v3.12的過程中順利將雲管平臺由DTcenter切換到了ASCM，且切換過程中沒有因平臺切換產生嚴重問題導致用戶投訴。雖然各項目對DTcenter的使用情況不一樣，但都可以從以下方面出發來整理思路進行準備和評估工作：
（1）對比DTcenter與ASCM在項目關注領域的差異
（2）根據項目實際情況從多個方面識別關鍵風險
（3）評估功能兼容滿足度
（4）評估權限體系切換影響度
（5）必要情況下準備測試環境進行遷移演練
在進行DT切換ASCM工作的準備評估和實際開展過程中，特別感謝雲平臺團隊內部和ASCM團隊的許多同學對該項工作的順利進行給予了大力支持，也希望本篇經驗分享可以幫助更多項目從DTcenter順利切換到ASCM平臺。
我們是阿里雲智能全球技術服務-SRE團隊，我們致力成為一個以技術為基礎、面向服務、保障業務系統高可用的工程師團隊；提供專業、體系化的SRE服務，幫助廣大客戶更好地使用雲、基於雲構建更加穩定可靠的業務系統，提升業務穩定性。我們期望能夠分享更多幫助企業客戶上雲、用好雲，讓客戶雲上業務運行更加穩定可靠的技術，您可用釘釘掃描下方二維碼，加入阿里雲SRE技術學院釘釘圈子，和更多雲上人交流關於雲平臺的那些事。
