本文為您介紹標籤設計的背景、原則、最佳實務以及相關樣本。
標籤設計的背景
當企業雲上資源只有幾個或十幾個的時候,通過人腦記憶或人工記錄即可完成資源的分類。但是,隨著企業雲上資源不斷增加(大型企業資源數量甚至成千上萬),單純依靠人工進行資源的分類變得越來越不可靠。此時,需要藉助平台化能力來解決這個問題。
在阿里雲,我們推薦您使用標籤對資源進行標記,從而實現資源的分類。每個使用者在建立資源時都要對資源的業務歸屬、財務歸屬等資源屬性進行標記,例如:按建立者、地區或專案等。否則,後續再去梳理每個資源的資源屬性往往變得事倍功半。
標籤設計的原則
互斥原則
互斥原則是指避免對同一個資源使用兩個或以上的標籤鍵。例如:如果已經使用了標籤鍵owner來標識資源的所有者,就不要再使用own、belonger或所有者等類似的標籤鍵。
集體詳盡原則
集體詳盡原則是指所有資源都必須綁定已規劃的標籤鍵及其對應的標籤值。例如:某公司有3個遊戲專案部,標籤鍵是project,則應至少有3個標籤值分別代表這 3個專案部。
集體詳盡原則是後續基於標籤維度進行資源檢索、分賬、自動化營運和存取控制的必要條件。
有限值原則
有限值原則是指為資源只保留核心標籤值,刪除多餘的標籤值。例如:某公司共有5個部門,那麼應該有且僅有這5個部門的標籤,方便管理。
有限值原則簡化了資源檢索、分賬、自動化營運和存取控制的流程。
考慮未來變化原則
考慮未來變化原則是指在設計標籤時要考慮後續工作中增加或者減少標籤值的影響,儘可能將業務邊界劃分得更加清晰一點,提高標籤修改的靈活性。例如:企業在上雲初期業務比較集中,就採用部門標籤department來管理部門相關的資源歸屬、財務歸屬和自動化營運。隨著企業的發展,這一個標籤已經承載了一些日常業務,想要區分開就需要耗費一定成本。因此,我們建議,企業在上雲初期需要先評估標籤的業務訴求,如在上述例子中則需規劃同時採用department、costcenter和ops標籤。
當您修改標籤時,可能會引起基於標籤的存取控制、自動化營運或相關賬單報表的變化。無論是公司或個人層面的業務,推薦您建立與業務相關的標籤,以便從技術、業務和安全維度管理資源。使用自動化營運來管理資源及服務時,還需要設計額外的自動化營運專用標籤,協助您完成自動化營運工作。
簡化設計原則
簡化設計原則是指在設計標籤時使用固定的標籤,簡化標籤的使用。標籤的設計盡量簡化key和value的值,滿足業務訴求即可。例如:在設計專案環境維度標籤時,測試環境相關的標籤鍵盡量統一成測試環境,不要同時保有多個,如預測試環境、正式測試環境等。
簡化設計原則可以減少由於過多的標籤鍵導致的操作報錯。
命名標準化原則
命名標準化原則是指標籤採用標準化命名格式,盡量相容不同開源工具,使後續的API整合更加便捷。例如:標籤命名涉及英文時,建議使用小寫英文字母。
標籤設計的最佳實務
某互連網公司有3個部門:業務部、市場部和營運部。每個部門管理一個或多重專案,每個專案在不同生命週期有不同環境:生產環境、開發環境、測試環境。公司營運團隊需要即時關注整個企業的資源情況,定期對每個專案的資源費用進行分賬,即時控制資源的訪問,並最終實現自動化營運。
為了滿足上述需求,該公司從以下幾個方面進行了標籤設計。
需求 | 標籤設計 | 說明 |
檢索和管理資源 | 為所有資源建立並綁定以下3個層級的標籤:
| 如果企業的組織架構層級比較深,可以考慮更高層級的標籤,例如:分公司(company)等。 |
管理成本和分賬 | 為所有資源建立並綁定成本中心標籤:
| 無 |
資源存取控制 | 限制非專案群組成員對專案內ECS等資源的訪問。 | 具體操作,請參見使用標籤限制RAM使用者管理指定的ECS執行個體。 |
自動化營運 | 建立用途標籤鍵purpose來進行日常資源巡檢,標籤值為autocheck-8am,即每日早8點自動巡檢。如果巡檢發現異常,通過資源持有人標籤owner來通知具體責任人進行處理。 | 無 |
標籤設計樣本
下表列舉了常見維度標籤設計樣本。
劃分維度 | 標籤鍵(key) | 標籤值(value) |
組織架構 |
| 相關名稱 |
業務架構 |
| 相關名稱 |
角色架構 |
|
|
用途 |
| 用途值 |
專案 |
| 據實填寫 |
業務部門(實現成本分配和業務跟蹤) |
| 據實填寫 |
財務維度責任人(確定資源負責人) | owner | 人名或郵箱等 |
財務維度客戶(識別資源服務的客戶) | 自訂或真實值 | 客戶名稱 |
財務維度專案(確定資源支援的專案) | project | 專案名稱 |
財務維度訂單 | order | 訂單分類ID |