本文為您介紹資源群組設計的背景、原則和最佳實務。
背景資訊
當企業在雲上的資源規模不斷擴大時,需要及時對雲上資源進行分類管理,進而提升資源管理效率,降低營運風險,減少不必要的成本浪費。
資源群組是在阿里雲帳號下進行雲上資源分類管理的一種機制,一個資源必須且只能屬於一個資源群組。使用資源群組對資源進行分類管理後,會帶來以下好處:
提升管理效率:資源完成分組後,您能夠以資源群組為單位進行資源部署、資源監控和許可權管理等,而不是單獨處理各個資源。例如:如果您想限制某專案組的成員只擁有該專案組資源的許可權,那麼,您可以建立一個對應於該專案組的資源群組,將資源先轉入該資源群組, 然後給專案群組成員授予該資源群組範圍的資源操作許可權。從而,該成員只擁有該資源群組內資源的許可權,而不是帳號下所有資源的許可權。尤其,當資源群組內資源發生變動時,您無需修改成員的許可權配置,此舉降低許可權配置的維護成本。
降低營運風險:資源完成分組後,一個資源必須且只能屬於一個資源群組,所以,您無需擔心一個資源被重複管理所帶來的風險。例如:按資源群組執行“批量修改資源名稱”的營運操作,無需擔心一個資源因為有多個分類,會被執行不一樣的營運操作,進而導致的衝突風險。
設計原則
在設計資源群組時,推薦您按照規劃設計、規範執行和檢查評估這三個步驟來進行設計,每一個步驟都有相對應的原則。
互斥原則:劃分資源群組的時候,儘可能做到維度一致,這個維度可以是部門、專案、業務功能、資源部署環境等。無論以哪種維度進行劃分,維度之間不能有重疊,不能導致一個資源從業務上看可以屬於多個資源群組。例如:“專案A”、“專案A生產環境”這兩個資源群組,就不符合互斥原則。如果從業務上看,一個資源確實可能被多個業務複用,可參考共用原則。
全面原則:劃分資源群組的時候,一方面,需要考慮劃分出來的資源群組能夠從業務上覆蓋當下所有使用的資源,另一方面,還需要考慮未來業務的發展變化,減少因劃分資源群組的維度不合適,導致後續調整資源群組帶來的成本和風險。強烈建議不要使用預設資源群組對資源進行分類。預設資源群組是系統產生的資源群組,無法刪除,當一個阿里雲帳號的資源未明確分類時,都會被放入預設資源群組,您需要用語義明確的自訂資源群組對資源進行分類。
共用原則:劃分資源群組的時候,如果確實有一些資源被多重專案或者業務複用,那麼可以建立一個資源群組,專門存放這些共用資源,同時在命名上加以區分。例如:某公司有2個業務系統,使用了同一個VPC資源,那麼除了為每個專案分別建立一個資源群組外,還需要建立一個存放共用資源的資源群組,該VPC資源就可以劃分到該共用資源組。
許可權最小化原則:按資源群組授權時,需要遵循許可權最小化原則,避免出現許可權過大問題。例如:某公司有多個業務系統,每個系統部署了多套環境。該公司只按業務系統維度進行了資源分組,沒有區分部署環境,並按照資源群組範圍進行授權,這樣可能會導致使用開發環境資源的RAM使用者具備了使用生產環境資源的許可權,給生產環境的業務系統帶來了一定的安全和穩定性風險。
命名規範原則:資源群組命名需要統一規範、簡單明了、具有明確的語義、便於識別和管理。例如:資源群組名稱“專案A生產環境”就符合命名規範要求,而資源群組名稱“生產環境”就缺乏明確的業務系統含義,不符合命名規範。
儘早調整原則:當您發現劃分資源群組的維度已不能滿足未來業務的發展趨勢時,需要儘早調整,避免隨著業務發展,進一步加大資源群組調整帶來的成本和風險。例如:某公司按照部門維度劃分資源群組,隨著業務規模的增大,在未來可見範圍內,每個部門都將會擁有大量的業務系統。此時,按照部門劃分資源群組就不能滿足許可權隔離的訴求了,需要以業務系統維度來重新劃分,推薦您儘早地調整資源群組劃分維度。
清理原則:當資源群組確定不再使用時,需要及時刪除該資源群組,減少管理成本。不建議您僅用“已廢棄”、“已刪除”等資源群組名稱標識不再使用的資源群組,而不刪除它。例如:某公司按照專案維度來劃分資源群組,建立了資源群組“專案A”、“專案B”等,當專案A結束時,及時轉出或釋放資源群組“專案A”下的資源,並刪除資源群組“專案A”,減少後續的管理成本。
最佳實務
某互連網公司有2個線上業務系統,由於產品功能在不斷迭代發展,分別部署了測試環境和生產環境,在不同的環境下都會用到多種雲資源。除了業務部門外,該公司還有財務、營運、審計合規等部門。不同職能部門對雲上資源的管理訴求不同。具體如下:
業務部:希望能做到只有業務系統的相關成員才能訪問該系統的資源,限制非業務系統成員對資源的訪問;希望能夠高效檢索出各自業務系統使用了哪些資源,資源是屬於哪個業務系統的;希望對不同業務系統的資源做到差異化的監控管理。
財務部:需要瞭解整個公司的資源費用情況,尤其需要瞭解各個業務系統使用的資源費用。
營運部:需要能夠對雲上資源高效營運。不同業務系統有著不一樣的營運標準,例如:業務系統A需要在每天淩晨2點對使用的資源進行異常巡檢,希望能快速找到待營運的資源。
審計合規部:要求雲上的資源必須進行合規審計,符合法律法規、行業標準以及公司內部的合規要求,但不同業務系統的資源有著不一樣的合規標準,希望能做到差異化的合規審計。
為了滿足上述需求,該公司以“業務系統+環境”的維度進行了資源群組設計,共建立了“業務系統A開發環境”、“業務系統A生產環境”、“業務系統B開發環境”、“業務系統B生產環境”共4個資源群組,並給相應的公司職能人員賦予了對應資源群組的許可權。
使用資源群組對資源分類管理後,該公司成功滿足了不同職能人員對資源管理的需求。
部門/人員 | 需求 | 實現方式 | 相關文檔 |
許可權管理員 | 精細化存取控制 | 公司負責人使用存取控制(RAM),對不同的公司人員賦予不同的資源群組許可權,實現許可權的精細化控制。 | |
業務部 | 檢索和管理資源 | 業務開發人員使用資源中心,按照資源群組進行檢索,進而能查詢到該業務系統使用了哪些資源。 | |
差異化資源監控 | 業務開發人員使用CloudMonitor,按照資源群組建立應用分組,按照不同業務系統的監控標準,做到差異化的監控組態管理。 | ||
財務部 | 管理成本和分賬 | 財務人員使用財務單元,按照資源群組進行分賬,進而能分別查詢到各個業務系統使用的資源費用情況。 | |
營運部 | 差異化資源營運 | 營運人員使用CloudOps Orchestration Service(OOS)、Resource Orchestration Service(ROS)等雲上營運工具,根據資源群組去圈定待營運的資源,做到差異化的營運。 | |
審計合規部 | 差異化合規審計 | 審計人員使用配置審計,根據資源群組去圈定待審計的資源,按照不同的標準建立對應的規則,做到差異化的合規審計。 |