?1.前言

為什么使用多云：

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

多云帶來的問題：

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

2.平臺介紹

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

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

從2022年4月開始規(guī)劃和調(diào)研，7月份第一版本發(fā)布上線，到現(xiàn)在經(jīng)過多輪迭代，B站的多云管理平臺ARES已經(jīng)在幫助業(yè)務(wù)用好云、云管管好云上邁出了堅實的一步，在降本增效方面發(fā)揮著重要的作用。

 2.1 平臺架構(gòu)

圖1：平臺架構(gòu)圖

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

3.平臺功能

3.1 項目為中心的全局管理

為什么以項目為中心？

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

3.1.1 項目與資源和賬單的關(guān)系

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

1. 公司組織為樹形結(jié)構(gòu)，葉子結(jié)點為業(yè)務(wù)部門；
2. 每個業(yè)務(wù)部門都會有多個業(yè)務(wù)項目，分別由不同的業(yè)務(wù)團隊負(fù)責(zé)；

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

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

• 一個項目可以關(guān)聯(lián)多個云賬號；
• 一個云賬號下，一個項目只能關(guān)聯(lián)一個云項目；
• 云項目的名字必須和項目相同；

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

• 對于存量資源，經(jīng)過治理，把資源按照云項目和云標(biāo)簽進行了正確的分組；
• 對于增量資源，在創(chuàng)建資源的時候根據(jù)項目和云項目的映射關(guān)系，自動歸屬資源到對應(yīng)的云項目，同時打上對應(yīng)的云標(biāo)簽；

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

3.1.2 項目與用戶權(quán)限的關(guān)系

項目定義了四種角色：研發(fā)負(fù)責(zé)人、研發(fā)成員、運維負(fù)責(zé)人和運維成員，只有是這四種角色的用戶才能對項目下的資源有限定的權(quán)限：

• 研發(fā)負(fù)責(zé)人角色權(quán)限：可以查看項目資源，發(fā)起項目資源的操作需求，作為操作工單的研發(fā)節(jié)點的審批人；
• 研發(fā)成員角色權(quán)限：可以查看項目資源，發(fā)起項目資源的操作需求；
• 運維負(fù)責(zé)人角色權(quán)限：可以查看項目資源，發(fā)起項目資源的操作需求，作為操作工單的運維節(jié)點的審批人；
• 運維成員角色權(quán)限：可以查看項目資源，發(fā)起項目資源的操作需求，作為操作工單操作前的安全確認(rèn)和執(zhí)行后的結(jié)果驗收；

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

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

• 研發(fā)角色自定義策略：對云上資源只讀的權(quán)限
• 運維角色自定義策略：對云上資源的運維操作的權(quán)限

通過云上的項目和標(biāo)簽，利用自定義策略語法里的條件語法，如下，為項目A研發(fā)角色的自定義策略，然后把用戶云賬號關(guān)聯(lián)自定義策略即可完成用戶和對應(yīng)角色權(quán)限的綁定。

{
    "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 項目與環(huán)境配置的關(guān)系

每個項目都有完整的一套或者多套環(huán)境，ARES支持用戶在項目級別配置環(huán)境，這里環(huán)境包括網(wǎng)絡(luò)環(huán)境、資源參數(shù)。

（1）網(wǎng)絡(luò)環(huán)境，用戶在提交項目創(chuàng)建的時候，可以按照業(yè)務(wù)需求配置：

• 生產(chǎn)環(huán)境和測試環(huán)境
• 選擇資源規(guī)模，平臺根據(jù)資源規(guī)模自動規(guī)劃網(wǎng)絡(luò)，創(chuàng)建業(yè)務(wù)子網(wǎng)
• 配置網(wǎng)絡(luò)訪問控制，平臺根據(jù)訪問控制自動配置安全組和選擇對應(yīng)的網(wǎng)絡(luò)VPC，比如云上私網(wǎng)VPC、混合云VPC等
• 配置公網(wǎng)，自動關(guān)聯(lián)NAT

項目創(chuàng)建后，根據(jù)配置自動在云上創(chuàng)建符合需求的網(wǎng)絡(luò)環(huán)境，為后續(xù)資源創(chuàng)建提供正確的項目網(wǎng)絡(luò)。

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

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

圖2：項目配置

圖3：配置前后數(shù)量對比

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

圖4：項目模板列表

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

 3.2 統(tǒng)一的資產(chǎn)管理

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

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

對于上述的三個問題，我們分別從產(chǎn)品標(biāo)準(zhǔn)化、屬性標(biāo)準(zhǔn)化以及數(shù)值標(biāo)準(zhǔn)化三個維度去逐個解決。

3.2.1 產(chǎn)品標(biāo)準(zhǔn)化

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

表1：多云下的云服務(wù)器產(chǎn)品

圖5：ARSE定義的標(biāo)準(zhǔn)化產(chǎn)品視圖

3.2.2 屬性標(biāo)準(zhǔn)化

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

表2：屬性標(biāo)準(zhǔn)化

圖6：ARES云服務(wù)器的屬性詳情

3.2.3 數(shù)值標(biāo)準(zhǔn)化

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

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

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

圖7：項目ARSE平臺的云服務(wù)器列表

 3.3 基于IaC的資源編排  

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

3.3.1 Terraform介紹

IaC

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

Terraform

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

這里以A云Provider為例介紹如何利用Terraform的resource來創(chuàng)建一臺云服務(wù)器

利用Terraform來創(chuàng)建云服務(wù)器

# 創(chuàng)建后端服務(wù)器
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的能力，經(jīng)過優(yōu)化來支持B站的云資源編排和管理，主要分為三個方面。

多云統(tǒng)一：

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

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

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

圖8：云主機的申請

參數(shù)模板：

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

1. 根據(jù)Terraform的語法規(guī)則，自動生成對應(yīng)產(chǎn)品的resource
2. 本地化配置產(chǎn)品的Terraform模板，按照模板生產(chǎn)Terraform文件

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

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

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

多產(chǎn)品編排：

云上資源的申請場景中，會經(jīng)常存在負(fù)載均衡和后端服務(wù)器一起申請的情況，對于這種多資源統(tǒng)一部署和編排，ARES利用了Terraform的原生編排能力，通過在負(fù)載均衡監(jiān)聽器的后端服務(wù)組的attachment的resource中聲明云服務(wù)器的resource id來實現(xiàn)，如下（以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的編排能力，我們支持了以下多種場景的編排能力：

負(fù)載均衡關(guān)聯(lián)同工單創(chuàng)建的后端服務(wù)器；

CDN部署管聯(lián)DNS自動做CNAME解析；

CDN部署關(guān)聯(lián)負(fù)載均衡或者對象存儲作為源站。

如下圖9、圖10是ARES上支持負(fù)載均衡關(guān)聯(lián)后端云服務(wù)器以及CDN關(guān)聯(lián)對象存儲作為源站的例子

圖9：負(fù)載均衡申請關(guān)聯(lián)后端服務(wù)器 

圖10：CDN關(guān)聯(lián)對象存儲域名

 3.4 安全可靠的用戶管理

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

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

3.4.1 云用戶賬號申請

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

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

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

圖11：云賬號申請流程

3.4.2 云用戶賬號登錄

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

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

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

圖12：單點登錄流程

3.4.3 云用戶賬號回收

對于擁有云賬號的用戶，一旦存在工作變動，云賬號的存在就轉(zhuǎn)變?yōu)橐粋€安全漏洞了，平臺是如何及時處理工作變動用戶的云賬號？

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

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

圖13：云賬號的在離職狀態(tài)管理

 3.5 多維度的成本管理

整個成本的管理包括業(yè)務(wù)前期的需求評估階段，廠商和產(chǎn)品選型階段，資源創(chuàng)建階段，資源的巡檢以及賬單的分析。

圖14：資源不同階段的成本優(yōu)化方式

3.5.1 申請階段

需求評估

需求評估的主要流程：

• 對于業(yè)務(wù)的上云需求，我們會跟業(yè)務(wù)方進行技術(shù)側(cè)的溝通，了解業(yè)務(wù)的架構(gòu)，從技術(shù)上給出資源選擇建議以及可能滿足需求的云廠商；
• 業(yè)務(wù)技術(shù)側(cè)對于至少三家云廠商的產(chǎn)品進行技術(shù)測試；
• 采購側(cè)根據(jù)測試結(jié)果以及云資源的成本，給出性價比最高的廠商；

資源選型

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

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

以云服務(wù)器智能推薦為例，通過調(diào)研各大云廠商提供的機型選擇相關(guān)的參考指標(biāo)：

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

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

圖16：資源選型效果圖

3.5.2 運行階段

資源巡檢：

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

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

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

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

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

1. 未綁定云服務(wù)器的云硬盤；
2. 未綁定實例的彈性公網(wǎng)IP；
3. 沒有監(jiān)聽器的負(fù)載均衡實例；
4. 持續(xù)狀態(tài)異常的云服務(wù)器；

結(jié)合前面介紹的資產(chǎn)管理，根據(jù)本地數(shù)據(jù)庫中的資產(chǎn)信息就可以實現(xiàn)閑置資源的定期巡檢。

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

賬單分析：

通過導(dǎo)入賬單，對賬單進行分析，可以能夠可視化的展示成本的總體情況，項目維度以及組織維度的成本構(gòu)成，并且通過定義每個資源類型的計量標(biāo)準(zhǔn)計算用量用于業(yè)務(wù)確認(rèn)：

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

4.展望

ARES多云平臺從業(yè)務(wù)日常的需求出發(fā)，結(jié)合一線資源交付人員的經(jīng)驗，參考業(yè)界的CMP產(chǎn)品的能力，建設(shè)成一個符合B站業(yè)務(wù)用戶使用習(xí)慣和云管用戶管理方式的平臺，最大程度的支持業(yè)務(wù)”用好云“，云管”管好云"，利用平臺化的能力和數(shù)字化運營助力降本增效。

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

• 持續(xù)完善成本優(yōu)化相關(guān)的能力，幫助業(yè)務(wù)降本增效；
• 基于容器服務(wù)和云原生架構(gòu)，實現(xiàn)多云環(huán)境下的自動遷移和伸縮能力；
• 托管私有云，建設(shè)成統(tǒng)一的混合云管理平臺。

5.參考資源想·

• 維基百科-安全斷言標(biāo)記語言：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站系統(tǒng)部平臺團隊，負(fù)責(zé)全站基礎(chǔ)設(shè)施管理平臺化和自動化、混合云IaC、資源運營CMDB等業(yè)務(wù)系統(tǒng)研發(fā)