文档

资源组设计最佳实践

更新时间:

本文为您介绍资源组设计的背景、原则和最佳实践。

背景信息

当企业在云上的资源规模不断扩大时,需要及时对云上资源进行分类管理,进而提升资源管理效率,降低运维风险,减少不必要的成本浪费。

资源组是在阿里云账号下进行云上资源分类管理的一种机制,一个资源必须且只能属于一个资源组。使用资源组对资源进行分类管理后,会带来以下好处:

  • 提升管理效率:资源完成分组后,您能够以资源组为单位进行资源部署、资源监控和权限管理等,而不是单独处理各个资源。例如:如果您想限制某项目组的成员只拥有该项目组资源的权限,那么,您可以创建一个对应于该项目组的资源组,将资源先转入该资源组, 然后给项目组成员授予该资源组范围的资源操作权限。从而,该成员只拥有该资源组内资源的权限,而不是账号下所有资源的权限。尤其,当资源组内资源发生变动时,您无需修改成员的权限配置,此举降低权限配置的维护成本。

  • 降低运维风险:资源完成分组后,一个资源必须且只能属于一个资源组,所以,您无需担心一个资源被重复管理所带来的风险。例如:按资源组执行“批量修改资源名称”的运维操作,无需担心一个资源因为有多个分类,会被执行不一样的运维操作,进而导致的冲突风险。

设计原则

在设计资源组时,推荐您按照规划设计、规范执行和检查评估这三个步骤来进行设计,每一个步骤都有相对应的原则。

image.png

  • 互斥原则:划分资源组的时候,尽可能做到维度一致,这个维度可以是部门、项目、业务功能、资源部署环境等。无论以哪种维度进行划分,维度之间不能有重叠,不能导致一个资源从业务上看可以属于多个资源组。例如:“项目A”、“项目A生产环境”这两个资源组,就不符合互斥原则。如果从业务上看,一个资源确实可能被多个业务复用,可参考共享原则。

  • 全面原则:划分资源组的时候,一方面,需要考虑划分出来的资源组能够从业务上覆盖当下所有使用的资源,另一方面,还需要考虑未来业务的发展变化,减少因划分资源组的维度不合适,导致后续调整资源组带来的成本和风险。强烈建议不要使用默认资源组对资源进行分类。默认资源组是系统生成的资源组,无法删除,当一个阿里云账号的资源未明确分类时,都会被放入默认资源组,您需要用语义明确的自定义资源组对资源进行分类。

  • 共享原则:划分资源组的时候,如果确实有一些资源被多个项目或者业务复用,那么可以创建一个资源组,专门存放这些共享资源,同时在命名上加以区分。例如:某公司有2个业务系统,使用了同一个VPC资源,那么除了为每个项目分别创建一个资源组外,还需要创建一个存放共享资源的资源组,该VPC资源就可以划分到该共享资源组。

  • 权限最小化原则:按资源组授权时,需要遵循权限最小化原则,避免出现权限过大问题。例如:某公司有多个业务系统,每个系统部署了多套环境。该公司只按业务系统维度进行了资源分组,没有区分部署环境,并按照资源组范围进行授权,这样可能会导致使用开发环境资源的RAM用户具备了使用生产环境资源的权限,给生产环境的业务系统带来了一定的安全和稳定性风险。

  • 命名规范原则:资源组命名需要统一规范、简单明了、具有明确的语义、便于识别和管理。例如:资源组名称“项目A生产环境”就符合命名规范要求,而资源组名称“生产环境”就缺乏明确的业务系统含义,不符合命名规范。

  • 尽早调整原则:当您发现划分资源组的维度已不能满足未来业务的发展趋势时,需要尽早调整,避免随着业务发展,进一步加大资源组调整带来的成本和风险。例如:某公司按照部门维度划分资源组,随着业务规模的增大,在未来可见范围内,每个部门都将会拥有大量的业务系统。此时,按照部门划分资源组就不能满足权限隔离的诉求了,需要以业务系统维度来重新划分,推荐您尽早地调整资源组划分维度。

  • 清理原则:当资源组确定不再使用时,需要及时删除该资源组,减少管理成本。不建议您仅用“已废弃”、“已删除”等资源组名称标识不再使用的资源组,而不删除它。例如:某公司按照项目维度来划分资源组,创建了资源组“项目A”、“项目B”等,当项目A结束时,及时转出或释放资源组“项目A”下的资源,并删除资源组“项目A”,减少后续的管理成本。

最佳实践

某互联网公司有2个在线业务系统,由于产品功能在不断迭代发展,分别部署了测试环境和生产环境,在不同的环境下都会用到多种云资源。除了业务部门外,该公司还有财务、运维、审计合规等部门。不同职能部门对云上资源的管理诉求不同。具体如下:

  • 业务部:希望能做到只有业务系统的相关成员才能访问该系统的资源,限制非业务系统成员对资源的访问;希望能够高效检索出各自业务系统使用了哪些资源,资源是属于哪个业务系统的;希望对不同业务系统的资源做到差异化的监控管理。

  • 财务部:需要了解整个公司的资源费用情况,尤其需要了解各个业务系统使用的资源费用。

  • 运维部:需要能够对云上资源高效运维。不同业务系统有着不一样的运维标准,例如:业务系统A需要在每天凌晨2点对使用的资源进行异常巡检,希望能快速找到待运维的资源。

  • 审计合规部:要求云上的资源必须进行合规审计,符合法律法规、行业标准以及公司内部的合规要求,但不同业务系统的资源有着不一样的合规标准,希望能做到差异化的合规审计。

image.png

为了满足上述需求,该公司以“业务系统+环境”的维度进行了资源组设计,共创建了“业务系统A开发环境”、“业务系统A生产环境”、“业务系统B开发环境”、“业务系统B生产环境”共4个资源组,并给相应的公司职能人员赋予了对应资源组的权限。

使用资源组对资源分类管理后,该公司成功满足了不同职能人员对资源管理的需求。

部门/人员

需求

实现方式

相关文档

权限管理员

精细化访问控制

公司负责人使用访问控制(RAM),对不同的公司人员赋予不同的资源组权限,实现权限的精细化控制。

RAM资源分组与授权

业务部

检索和管理资源

业务开发人员使用资源中心,按照资源组进行检索,进而能查询到该业务系统使用了哪些资源。

搜索资源

差异化资源监控

业务开发人员使用云监控,按照资源组创建应用分组,按照不同业务系统的监控标准,做到差异化的监控配置管理。

使用资源组和云监控实现不同业务线资源的监控管理

财务部

管理成本和分账

财务人员使用财务单元,按照资源组进行分账,进而能分别查询到各个业务系统使用的资源费用情况。

资源组分账

运维部

差异化资源运维

运维人员使用系统运维管理(OOS)资源编排(ROS)等云上运维工具,根据资源组去圈定待运维的资源,做到差异化的运维。

审计合规部

差异化合规审计

审计人员使用配置审计,根据资源组去圈定待审计的资源,按照不同的标准创建对应的规则,做到差异化的合规审计。

使用资源组和配置审计实现多标准下的资源合规审计

  • 本页导读 (1)
文档反馈