?1.前言

為什么使用多云：

• 公有云因為其彈性、按需使用以及多地域的覆蓋等優勢，企業在高速發展的過程中往往會選擇公有云來提供應用所需的基礎設施；
• 為了高穩定性和成本最優的考慮，一般會引入多家云廠商；
• 多云部署防止單一云廠商故障導致服務完全不可用；
• 采用多云也提升了采購上的議價能力，避免單一廠商綁定，在價格談判中處于劣勢；
• 不同的云廠商在覆蓋的地域、產品的能力上不一致，引入多云可以充分發揮各廠商的服務能力和產品優勢。

多云帶來的問題：

• 公司內因為云上資源使用的業務比較多，資源新增和交付主要依賴人工溝通并在控制臺上進行操作，效率很低，在遇到大批量的資源交付服務器、數據庫和負載均衡等多產品聯合交付等場景的時候，無法滿足業務的高速迭代需求；
• 不同的業務使用的云產品不同，基本上都涵蓋了主要的IaaS和PaaS類的云產品，資源分布在多個公有云、多個云賬號下，無法準確掌握全部資源情況，尋找資源困難，難以區分哪個資源由哪個業務使用；
• 用戶在公有云控制臺上權限混亂缺乏管理，存在權限泄露問題，操作不同資源需要通過密碼登錄不同公有云不同賬號，難以批量操作，高危操作缺乏審批流程；
• 網絡配置復雜，需要學習和掌握很多專業的網絡知識，難以排查網絡連通性問題；
• 公有云成本逐步上漲，但缺乏成本的可視化，以及支持成本優化的能力

2.平臺介紹

針對上面提到的問題，多云管理平臺建設迫在眉睫，如何來幫助業務用好云，幫助云管管好云是多云管理平臺建設的最終目標。通過調研一些業內的CMP平臺，以及團隊內部多輪的討論、與業務用戶的交流，對于多云管理平臺我們定義它應該至少具備：

• 體驗友好，簡潔易用；
• 包括以下功能：
• 資源管理
• 資源編排
• 用戶管理
• 成本管理

從2022年4月開始規劃和調研，7月份第一版本發布上線，到現在經過多輪迭代，B站的多云管理平臺ARES已經在幫助業務用好云、云管管好云上邁出了堅實的一步，在降本增效方面發揮著重要的作用。

 2.1 平臺架構

圖1：平臺架構圖

• 整體采用分層架構，最頂層面向用戶，提供用戶的統一入口，用戶通過統一前端完成資源的整個生命周期的管理，同時也提供接口；
• 中間層為業務邏輯層，主要功能分為項目管理、資產管理、用戶管理、資源編排和成本管理，涵蓋云資源的增刪改查等操作以及生命周期的管理，同時也管理了多云的賬單以及云上的用戶賬號；
• 項目管理：主要是管理ARSE項目元信息，圍繞項目管理多云資源、賬號和賬單；
• 資產管理：主要是管理資源的資產信息，通過標準化，統一多云資產管理，消除多云的差異；
• 用戶管理：主要是全生命周期管理云上用戶賬號；
• 資源編排：通過資源編排能力，幫助用戶既可以自動部署單個資源，又可以處理復雜的聯動資源的部署需求；
• 成本管理：主要是對云上賬單進行分析處理，提供成本可視化和用量數據，為平臺運營提供成本優化的數據支持。
• 底層是引擎層，主要是通過IaC和api結合的形式對接各云廠商，完成所有上層動作的最終執行。

3.平臺功能

3.1 項目為中心的全局管理

為什么以項目為中心？

在ARES立項階段，最先考慮的一個問題是以什么維度來劃分資源和權限，每個用戶的資源管理邊界在哪，基于現狀，隨著業務發展，公司組織和部門會相應的調整，導致資源的歸屬會經常變動，并且從成本角度，云上的資源需要比較細粒度的進行成本拆分，基于此，參考公有云的管理邏輯，我們定義了項目的概念，作為ARSE管理多云的核心。

3.1.1 項目與資源和賬單的關系

首先，項目作為多云平臺的管理中心，公司組織是預算執行以及成本歸屬的重要單位，所以我們需要先定義項目和公司組織的關系。通過分析公司組織的特點：

1. 公司組織為樹形結構，葉子結點為業務部門；
2. 每個業務部門都會有多個業務項目，分別由不同的業務團隊負責；

我們定義公司組織和項目的關系為1:N，一個項目只能歸屬為唯一一個組織，但是一個組織下可以有多個項目。

其次，云項目是云廠商控制臺的概念，雖然不同公有云的名稱不同但表示的含義是相同（比如A云叫資源組，B云叫企業項目），這里我們統一稱為云項目。根據同一個賬號下云項目是唯一的特性，我們定義項目與云賬號、云項目之間的關系：

• 一個項目可以關聯多個云賬號；
• 一個云賬號下，一個項目只能關聯一個云項目；
• 云項目的名字必須和項目相同；

最后，在公有云中，資源是可以歸屬到云項目下的，可以以云項目的粒度在云上管理資源。但是，云項目有個問題就是無法關聯所有的資源，我們這里采用定義一個云標簽來輔助資源的管理，以bili_project為key，項目名為value，利用標簽對于資源的覆蓋范圍更大這一優勢來作為云項目的補充。針對項目與云資源的關系：

• 對于存量資源，經過治理，把資源按照云項目和云標簽進行了正確的分組；
• 對于增量資源，在創建資源的時候根據項目和云項目的映射關系，自動歸屬資源到對應的云項目，同時打上對應的云標簽；

從這里可以看出，通過云項目和標簽作為中介，可以關聯項目和資源，因為賬單里可以根據資源的云項目以及標簽來定義賬單項的歸屬，所以也就定義了項目和賬單的關系，由此可以把賬單歸屬到公司部門。

3.1.2 項目與用戶權限的關系

項目定義了四種角色：研發負責人、研發成員、運維負責人和運維成員，只有是這四種角色的用戶才能對項目下的資源有限定的權限：

• 研發負責人角色權限：可以查看項目資源，發起項目資源的操作需求，作為操作工單的研發節點的審批人；
• 研發成員角色權限：可以查看項目資源，發起項目資源的操作需求；
• 運維負責人角色權限：可以查看項目資源，發起項目資源的操作需求，作為操作工單的運維節點的審批人；
• 運維成員角色權限：可以查看項目資源，發起項目資源的操作需求，作為操作工單操作前的安全確認和執行后的結果驗收；

除了平臺的用戶權限是通過項目來定義邊界外，云上賬號同樣是通過項目來定義權限邊界的，怎么實現云賬號權限的項目限定呢？

主要是利用了云上的自定義策略，對于項目級別定義了兩種角色自定義策略：

• 研發角色自定義策略：對云上資源只讀的權限
• 運維角色自定義策略：對云上資源的運維操作的權限

通過云上的項目和標簽，利用自定義策略語法里的條件語法，如下，為項目A研發角色的自定義策略，然后把用戶云賬號關聯自定義策略即可完成用戶和對應角色權限的綁定。

{
    "Version": "1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "*:Describe*",
                "*:List*",
                "*:Get*",
                "*:BatchGet*",
                "*:Query*",
                "*:BatchQuery*",
                "actiontrail:LookupEvents",
                "actiontrail:Check*",
                "dm:Desc*",
                "dm:SenderStatistics*",
                "ram:GenerateCredentialReport",
                "cloudsso:Check*",
                "notifications:Read*"
            ],
            "Resource": "*",
            "Condition": {
                "StringEqualsIgnoreCase": {
                    "*:tag/bili_project": [
                        "項目A"
                    ]
                }
            }
        }
    ]
}

3.1.3 項目與環境配置的關系

每個項目都有完整的一套或者多套環境，ARES支持用戶在項目級別配置環境，這里環境包括網絡環境、資源參數。

（1）網絡環境，用戶在提交項目創建的時候，可以按照業務需求配置：

• 生產環境和測試環境
• 選擇資源規模，平臺根據資源規模自動規劃網絡，創建業務子網
• 配置網絡訪問控制，平臺根據訪問控制自動配置安全組和選擇對應的網絡VPC，比如云上私網VPC、混合云VPC等
• 配置公網，自動關聯NAT

項目創建后，根據配置自動在云上創建符合需求的網絡環境，為后續資源創建提供正確的項目網絡。

（2）資源參數，平臺的出發點是降低用戶的資源參數選擇成本，提高資源申請的效率：

首先在項目創建完成后，用戶可以根據業務場景和資源選型，配置云服務器、RDS以及Redis等資源的參數配置，比如云服務器的鏡像、機型，RDS和Redis的版本和規格等，如圖所示，預先配置這些參數可以在資源申請階段，不必在云廠商提供的少則幾十種，多則上百種選項中篩選目標配置。優化了用戶體驗，提高了資源申請的效率，以云服務器的鏡像和機型舉例可以看出前后數量對比。

圖2：項目配置

圖3：配置前后數量對比

除了配置這些參數作為資源申請時候的待選參數外，平臺還提供了提前配置模板的能力，解決相同需求重復申請的問題，比如，對于某項目，可以把第一次資源申請的工單保存為模板，后續隨著業務的發展，需要追加申請資源擴容，可以直接以模板發起，不需要重新提交資源需求工單，如圖4：

圖4：項目模板列表

綜上，對于通過項目，可以高效的管理資源、權限以及成本歸屬，通過項目可以幫助用戶提高資源申請效率，這也是ARSE選擇項目作為整個平臺的管理中心的原因。

 3.2 統一的資產管理

通過上述項目的介紹，應該已經清楚整個ARES對于多云的資源是基于項目管理的，要做好統一管理，面臨以下問題需要解決：

1. 不同的云的產品叫法不一致，如何消除產品認知上的差異；
2. 云產品的屬性特別多，并且字段名也不一樣，獲取的方式也有差異；
3. 對于同一種屬性的value定義存在多云差異，如何統一；

對于上述的三個問題，我們分別從產品標準化、屬性標準化以及數值標準化三個維度去逐個解決。

3.2.1 產品標準化

ARSE針對不同云的產品名稱不一致的問題，ARES定義了云服務器、RDS、Redis、負載均衡、對象存儲等30多種標準產品（如圖5），并與云上對應產品進行映射，實現多云統一管理的需求。以標準產品中云服務器為例，將阿里云的ECS、騰訊云的CVM，華為云的ECS以及亞馬遜云的EC2等公有云云服務器類產品統一在ARES平臺定義的云服務器中管理，統一對外命名為云服務器，消除名稱上的差異。

表1：多云下的云服務器產品

圖5：ARSE定義的標準化產品視圖

3.2.2 屬性標準化

對于不同云的產品屬性差異的問題，需要標準化，對外統一屬性，如果將不同公有云的屬性直接展示給用戶，會出現表達相同含義的屬性在不同位置展示的問題，無法實現用戶統一篩選、排序和查看的需求。為此我們針對接入的產品，每個都對其屬性進行了標準化，并且把每個云的屬性和標準化的屬性映射關系記錄下來。如下表，是我們標準化云服務器部分屬性的情況，對于未進行標準化的屬性，我們也按照公有云提供的原始數據結構進行存儲，滿足少量高級用戶管理需求。

表2：屬性標準化

圖6：ARES云服務器的屬性詳情

3.2.3 數值標準化

經過產品標準化和屬性標準化后，已經實現用戶在統一視圖下查看和管理所有資源的需求，此時仍然有一個問題：對于狀態、類型、計費方式等枚舉類型的產品屬性在不同公有云的取值范圍定義都不相同，直接暴露給用戶不利于篩選，并且會造成誤解。

以公有云服務器的『狀態』屬性為例，不同公有云的取值范圍不同，ARES的方案是，按照表示的含義取交集，對于交集沒有包括的部分設置兩種狀態：異常狀態和其它狀態，所以標準化后的云服務器的狀態為：創建中、運行中、啟動中、停止中、已停止、異常、其它。用戶可以通過篩選查看對應狀態的資源。

在經過產品標準化、屬性標準化和數值標準化后，多云的資源在ARSE平臺實現語義和展示上的統一，再結合項目管理章節的介紹，用戶可以在ARSE上基于項目全局上查看到同一個項目下的資源分布，以及在單一資源類型下，基于統一的認知，可以多維度檢索資源列表信息和詳細信息，對于用戶而言，ARES“消滅了”多云，把自己打造成了云平臺，ARSE就像是編程語言中的“接口”，對外都是標準化的，沒有歧義的，而實際執行操作是每個云對于這個接口的實現。

圖7：項目ARSE平臺的云服務器列表

 3.3 基于IaC的資源編排  

資源編排是多云平臺的核心功能之一，好的資源編排能力既可以單賬號多資源聯動部署，又可以跨賬號部署資源。ARES是基于Terraform為主，API為輔來實現資源編排的，這里重點介紹Terraform。

3.3.1 Terraform介紹

IaC

IaC（Infrastructure as Code）基礎設施即代碼，就是用代碼來定義和管理基礎設施，Hashicorp 公司創建Terraform是IaC中的優秀代表，盡管它不是唯一的 —— 所有主要的云提供商都有自己的 IaC，谷歌提供 Google Cloud Deployment Manager，AWS 提供 CloudFormation，微軟的 Azure 提供 Azure Resource Manager，Terraform因為是開源的并且和平臺無關，所以廣受歡迎。

Terraform

Terraform提供了一套基礎設施管理的聲明式的框架，主流云廠商都實現了各自云的Provider，Terraform 通過provider與不同的云集成。provider是 Terraform 插件，用于與外部 API 進行交互。每個云供應商都會維護自己的 Terraform provider，使 Terraform 能夠管理該云中的資源。provider使用 Go 語言編寫的，并作為二進制文件分發到Terraform注冊表上。它們負責進行身份驗證、發出API請求以及處理超時和錯誤。在這個注冊表中，有數百個已經發布的提供程序，它們協同起來，使你能夠管理數千種不同的資源。

這里以A云Provider為例介紹如何利用Terraform的resource來創建一臺云服務器

利用Terraform來創建云服務器

# 創建后端服務器
resource "Acloud_instance" "server_attachment" {
  count                      = 1
  image_id                   = "ubuntu_18_04_64_20G_alibase_20190624.vhd"
  instance_type              = "ecs.n4.large"
  instance_name              = "test"
  security_groups            = "sg-mj7itgyeohjw2ebvyrl"
  internet_charge_type       = "PayByTraffic"
  internet_max_bandwidth_out = "10"
  availability_zone          = "cn-hangzhou-A"
  instance_charge_type       = "PostPaid"
  system_disk_category       = "cloud_efficiency"
  vswitch_id                 = "vsw-uf66iu2bxce23ityocdx"
}

3.3.2 Terraform實踐

介紹了Terraform后，我們接下來講解ARES如何利用Terraform的能力，經過優化來支持B站的云資源編排和管理，主要分為三個方面。

多云統一：

Terraform雖然可以使用代碼管理基礎設施，但是面對公有云，Terraform并沒有解決多云異構的問題，還是需要每家廠商提供完善的Provider，需要用戶針對不同的Provider去寫tf文件，所以對于用戶還是沒有屏蔽多云的差異，ARSE從業務層去解決了多云統一的問題。主要思路為：

• 對于第三節介紹的產品標準化和屬性標準化，把經過標準化后的屬性作為變量名，前端按照變量名對產品屬性進行定義，對于多個廠商只需要定義一次，所有前端用戶選擇的value對于不同的廠商賦值給相同一份變量
• 前端賦值后經過后端接口根據云廠商的不同，根據映射的對應云廠商的terraform的字段進行賦值，調用實際的廠商的Provider插件進行資源請求的執行

如圖以云主機為例，不管選擇的賬號，ARES需要用戶填寫的label都是一致的，不因多云而改變，提供一致的用戶體驗。

圖8：云主機的申請

參數模板：

每一次用戶提交需求，前端變量值映射到后端的tf文件都需要重新生成一份tf文件，這里有兩種方案：

1. 根據Terraform的語法規則，自動生成對應產品的resource
2. 本地化配置產品的Terraform模板，按照模板生產Terraform文件

考慮到基于語法自動生成Terraform相關文件有一定的難度，我們選擇第二種方案，我們利用Terraform的variable關鍵字，定義多云下每個產品的模板，比如main_alicloud_template.tf文件，所有變量的value引用variable進行填充，這里有兩個關鍵點：

1. value為多云統一后的變量名，比如云主機的機器名均為var.hostname
2. 每個變量名按照variable文件的格式生成對應的變量聲明和定義

做到如上兩點，每當用戶提交需求的時候會自動生成含有每個變量聲明和定義的variable.tf文件，同時實例化一份模板文件main.tf，組成一份可執行的完整tf環境

多產品編排：

云上資源的申請場景中，會經常存在負載均衡和后端服務器一起申請的情況，對于這種多資源統一部署和編排，ARES利用了Terraform的原生編排能力，通過在負載均衡監聽器的后端服務組的attachment的resource中聲明云服務器的resource id來實現，如下（以A云為例）：

resource "Acloud_slb_server_group_server_attachment" "server_attachment" {
  ...
  server_group_id = Acloud_slb_server_group.server_attachment.id
  server_id       = Acloud_instance.server_attachment[count.index].id
  ...
}

利用Terraform的編排能力，我們支持了以下多種場景的編排能力：

負載均衡關聯同工單創建的后端服務器；

CDN部署管聯DNS自動做CNAME解析；

CDN部署關聯負載均衡或者對象存儲作為源站。

如下圖9、圖10是ARES上支持負載均衡關聯后端云服務器以及CDN關聯對象存儲作為源站的例子

圖9：負載均衡申請關聯后端服務器 

圖10：CDN關聯對象存儲域名

 3.4 安全可靠的用戶管理

由于ARES還在迭代中，對于云上資源的運維操作接入并不完善，用戶還是會需要采用云賬號登錄控制臺進行資源的運維，比如調整數據庫的參數，配置告警策略等。所以當前現狀下，云賬號還是用戶運維資源不可或缺的輔助手段。

由于云賬號屬于公有云，它的安全性相對于內部平臺的賬號不可控，比如用戶的權限和密碼的管理，賬號的回收等等。為此，ARES針對云賬號全生命周期管理進行了設計和支持，保證云賬號的安全可靠。

3.4.1 云用戶賬號申請

對于云用戶賬號的申請需要滿足以下條件：

1. 必須是項目的四種角色之一
2. 必須選擇項目，不能是全局賬號

除了條件之外，最主要的還是云賬號的獲取必須走申請流程，流程里配置了用戶的直屬領導審批，如下圖所示。

圖11：云賬號申請流程

3.4.2 云用戶賬號登錄

使用云用戶賬號登錄存在以下問題：

1. 如果某個用戶需要申請的賬號比較多，管理賬號密碼就顯得很痛苦；
2. 由于密碼是用戶自己管理，容易泄漏，造成云上資源存在一定的安全風險。

通過調研業界的做法，ARSE基于云廠商原生支持的SSO能力和公司內部的單點登錄，實現了基于內部IDP認證的云上賬號單點登錄，整體邏輯如圖，優點是把云賬號的登錄跳轉到內部的身份認證，只需要用戶掃描登陸內部企業微信就可以實現一鍵登錄到云上進行資源的管理。不需要鍵入密碼，因為云上開啟了SSO的功能，即使密碼泄漏，外部用戶也無法登錄到云控制臺。

圖12：單點登錄流程

3.4.3 云用戶賬號回收

對于擁有云賬號的用戶，一旦存在工作變動，云賬號的存在就轉變為一個安全漏洞了，平臺是如何及時處理工作變動用戶的云賬號？

• 首先，因為單點登錄的開啟，云上的賬號的申請都是和用戶內部的唯一身份名進行綁定的；
• 其次，ARES利用公司內部接口，可以獲取到離職人員的名單列表。

基于以上兩點，平臺可以定時獲取離職人員，并且和云賬號所綁定的用戶進行比對，一旦發現用戶處于離職狀態會第一時間自動關閉云賬號的控制臺登錄權限，為了防止誤操作，關閉登錄權限后一段時間內才會去清退刪除賬號。（如圖13所示）

圖13：云賬號的在離職狀態管理

 3.5 多維度的成本管理

整個成本的管理包括業務前期的需求評估階段，廠商和產品選型階段，資源創建階段，資源的巡檢以及賬單的分析。

圖14：資源不同階段的成本優化方式

3.5.1 申請階段

需求評估

需求評估的主要流程：

• 對于業務的上云需求，我們會跟業務方進行技術側的溝通，了解業務的架構，從技術上給出資源選擇建議以及可能滿足需求的云廠商；
• 業務技術側對于至少三家云廠商的產品進行技術測試；
• 采購側根據測試結果以及云資源的成本，給出性價比最高的廠商；

資源選型

資源選型主要包含兩個方面；

• 性能測試：云資源的基準測試是評估其性能的最主要途徑，通過Unixbench和SPECCPU我們針對主流廠商的常用云服務器進行了基準測試，并且測試數據作為智能推薦的參考因素，幫助業務合理的選擇云服務器的類型，后續也會針對MySQL和Redis等云資源做性能測試;
• 智能推薦：對于業務用戶來說，在選擇云服務器的機型的時候并沒有足夠的數據支撐，同時在不同的廠商之間如何決策該選哪一家性價比最優一直是一個頭疼問題，為此ARES針對該場景提供了智能推薦的功能；

以云服務器智能推薦為例，通過調研各大云廠商提供的機型選擇相關的參考指標：

我們選取CPU，MEM以及規格類型作為推薦時用戶可以篩選項，根據篩選項輸出滿足用戶需求的按照成本排序后的機型，整體邏輯如圖15所示。

圖15：資源選型智能推薦流程

圖16：資源選型效果圖

3.5.2 運行階段

資源巡檢：

在資源運行階段，對于成本優化我們一般從兩個方面著手：

1. 低利用率資源降配；
2. 閑置資源及時清退；

首先，低利用率資源降配的主要流程是：

• 定義業務和成本關心的監控指標，例如：云服務器和云數據庫，我們主要關注CPU和內存的利用率，所以選取兩個監控項來體現資源的使用情況；
• 利用云上的接口獲取利用率的監控數據，因為考慮到云上的接口查詢頻率，我們定義每5分鐘查詢一次數據，每天對這些數據進行峰值和均值的計算并且持久化；
• 這里出于數據存儲的成本考慮，我們只把統計后的數據保存下來，這樣對于單個實例，每天三個數據（最大值，最小值以及均值），數據量相當于全部保存的縮小了100倍，可以保存更長時間的數據；
• 定義巡檢的規則，例如：設置云服務器的CPU利用率均值<10%，內存利用率均值<10%；
• 按照規則每天對數據庫中的利用率統計數據進行分析，并且生成滿足規則條件的實例列表；
• 拿到實例列表后會輸出給業務方，作為業務方降本的數據支撐

其次，對于閑置資源，根據實際使用場景，我們定義了以下幾種閑置資源：

1. 未綁定云服務器的云硬盤；
2. 未綁定實例的彈性公網IP；
3. 沒有監聽器的負載均衡實例；
4. 持續狀態異常的云服務器；

結合前面介紹的資產管理，根據本地數據庫中的資產信息就可以實現閑置資源的定期巡檢。

從低利用率資源到閑置資源的巡檢，ARSE不斷探索資源優化和技術降本的可能性，助力業務更加合理的使用云上資源。

賬單分析：

通過導入賬單，對賬單進行分析，可以能夠可視化的展示成本的總體情況，項目維度以及組織維度的成本構成，并且通過定義每個資源類型的計量標準計算用量用于業務確認：

• 成本可視化：按照時間，展示成本的變化情況，方便成本和采購團隊關注業務在公有云上的成本；
• 成本構成：展示基于一個項目下的成本的構成情況，并且能夠多級下鉆，有利于用戶分析業務的成本構成，及時知曉成本大頭，確定降本的方向；
• 用量確認：在賬單里存在多個計費項（例如：云服務器有實例規格的計費項，公網帶寬的計費項，云硬盤存儲計費項等），為了方便業務用量確認，我們定義了用量標準（例如：云服務器，我們定義CPU核數作為云服務器的用量標準），每個月平臺按照既定的用量標準計算用量后，業務可以針對該用量數據和業務實際使用的資源用量作對比，確認賬單用量無誤。

4.展望

ARES多云平臺從業務日常的需求出發，結合一線資源交付人員的經驗，參考業界的CMP產品的能力，建設成一個符合B站業務用戶使用習慣和云管用戶管理方式的平臺，最大程度的支持業務”用好云“，云管”管好云"，利用平臺化的能力和數字化運營助力降本增效。

目前，ARSE多云管理平臺還處于不斷迭代和完善的過程中，未來平臺的主要建設方向包括：

• 持續完善成本優化相關的能力，幫助業務降本增效；
• 基于容器服務和云原生架構，實現多云環境下的自動遷移和伸縮能力；
• 托管私有云，建設成統一的混合云管理平臺。

5.參考資源想·

• 維基百科-安全斷言標記語言：https://zh.wikipedia.org/wiki/%E5%AE%89%E5%85%A8%E6%96%AD%E8%A8%80%E6%A0%87%E8%AE%B0%E8%AF%AD%E8%A8%80
• 維基百科-SAML 2.0：https://zh.wikipedia.org/wiki/SAML_2.0
• Terraform：https://developer.hashicorp.com/terraform
• Provider：https://registry.terraform.io/providers/aliyun/alicloud/latest/docs/resources/instance#system_disk_description
• https://www.shuzhiduo.com/A/RnJW4ZkB5q/
• https://www.jianshu.com/p/2bd3bcba8f9f
• https://developer.hashicorp.com/terraform
• ??http://c.biancheng.net/view/9813.html??

本期作者：    SYS平臺    ?B站系統部平臺團隊，負責全站基礎設施管理平臺化和自動化、混合云IaC、資源運營CMDB等業務系統研發