B 站多雲管理平臺建設

本期作者

    SYS 平臺    

B 站系統部平臺團隊，

負責全站基礎設施管理平臺化和自動化、

混合雲 IaC、資源運營 CMDB 等業務系統研發

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 平臺定義的雲服務器中管理，統一對外命名爲雲服務器，消除名稱上的差異。

Rx0gLj

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

圖片

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

3.2.2 屬性標準化

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

ZxcvST

表 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 針對該場景提供了智能推薦的功能；

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

AJlRm5

我們選取 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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/qsAve3D8RBW46Htzked0NA