FinOps-公有云资源管理

01 背景概述

在用户上云初期，对于云资源的管理通常处于较为松散的状态。而随着资源用量的增加以及使用到的产品种类的多样化，云上成本支出日益激增 ，企业对于成本精细化管理的诉求也愈发强烈。从使用云产品维度看，成本的计算方式从服务器计算、存储以及网络的开销用量的简单场景，演进成了不同场景化的云原生PaaS服务。对于云平台管理人员来说，使用完全托管的PaaS服务能够在免除部署运维管理成本的情况下，通过云平台工具直接对资源及上层应用统一管理，例如云监控、云安全中心、资源编排、ARMS调用链工具、SLS日志服务等。在新的平台架构下，当线上出现故障时，工程师需要有对应的服务使用权限，并对这些云平台工具快速排查定位问题。

试想一个场景，当A团队的某台服务器存在异常时，B团队的某位运维人员对该台服务器拥有对增删改查、甚至特权账号登录服务器时，在生产环境下这样的权限划分实际上是存在风险且不可靠的。除权限问题外，用户对于云上资源使用的核心诉求往往在于花最少的钱，部署业务系统。而现实情况却并非如此，当涉及到了大量分拆型、集群型资源的使用时，管理员则更倾向于基于账号维度对资源进行划分。根据康威定律，设计系统的架构受制于产生这些设计的组织的沟通结构。云平台的架构亦是如此。资源管理模型本质上是对当前组织架构中各团队的管理边界、财务边界等问题做出划分，简单地说，即哪些人对资源具有管理职能，哪些人为资源的实际用量买单，哪些人则仅仅是资源的使用者。

资源管理同时也是一个很大的话题，容量规划、运维自动化等均可纳入资源管理的体系之内，本文主要探讨的是围绕云账号下的资源使用，如何针对不同的组织架构以及企业内外部环境，综合考虑人、权、财、物的影响，帮助企业设计出最适合企业自身的资源管理模型。

公有云资源管理的最佳实践是一系列企业IT治理产品和服务的集合，针对不同的组织架构通过云平台提供的治理能力实现精细化资源管理，包括资源目录、资源组、资源共享和标签等。用户可以使用资源目录在云上构建企业业务组织关系，使用资源组和标签分层次管理云上资源，使用资源共享在企业成员之间共享云上资源。

02 云成本管理的影响

资源管理是FinOps云成本管理的必要条件，资源容器管理的颗粒度直接决定了成本洞察时能够下钻的深度。在详细介绍资源管理方案前，不妨先看下如下案例：

某企业在对资源管理整体规划时，考虑到各业务方相对独立，且每个业务部门均有对应的管理人员对平台统一管理，各部门之间独立拆账。在云平台架构规划时，云平台管理员按照不同职能部门独立划分账号给到对应业务部门使用。经过一段时间的使用之后，云资源成本急速上升。虽然云平台管理员能够识别到对应账号的用量增长情况，但对账号内的应用及业务信息知之甚少，因此只能将资源容量规划的工作转交给各账号下的管理团队，但是业务管理团队同样由于缺乏更细粒度的资源管理措施，甚至存在由业务使用方（如开发人员）获取到资源购买权限直接开通并使用资源的情况，因此云上资源成本不可避免的出现失控。

首先从组织架构来看，该企业属于纵向烟囱式管理，即除了云平台管理团队担任一级管理员以外，各业务团队委派管理人员担任二级管理员，负责对应账号下资源的购买、使用、运维等工作。资源的实际使用团队主要向二级管理员提出需求采购对应的云资源。从整体上看，虽然预算最终均由一级管理员管理，但该团队由于缺乏业务属性，并不能决定怎么花钱，以及该花多少钱。

其次是关于成本可见性问题的影响，在多账号场景下企业可通过财务托管或财务管理两种方式将资源账号统一关联到一个财务主账号下，管理员在该账号下能够查询到所有账号下的资源支出情况。如果缺少统一的资源管理策略，则难以建立起多维度的资源视图，将资源成本拆分到每一个项目或系统上。还有一部分企业按照每一个系统拆分账号，这种方案同时也会带来新的一些平台规划问题，如网络规划、用户权限管理等，不详细在此展开讨论。

最后，则是关于一些账号维度的云服务，如WAF、DDoS等产品重复购买问题。这种松散的，基于二级管理员的资源管理模式，背后实则是部门之间缺乏必要的沟通。

综上所述，不同的资源管理模型在定义”人、权、财、物“时，对成本管理，账单分析以及成本的增加等均会产生不同程度的影响。

03 资源管理策略

在了解云上资源管理的挑战和一些最佳实践之前，先一起回顾下公有云在资源管理上有哪些工具箱可以使用。

3.1 账号

公有云资源账号是使用云资源的基础，在同一个账号下，管理员通过RAM权限控制策略可以对用户授权使用、查看相关资源信息。除权限管理以外，企业在选择使用单账号、多账号管理的一个关键因素在于账单及成本的分析复杂度。

账号同云资源的关系为一对多，即云资源只能归属于一个账号。虽然资源共享能够解决解决部分基础设施资源对象（例如VPC、ECS镜像等）跨账号使用问题，但是本质上对应实例的属组依然是明确的。

3.2 资源目录

资源目录（Resource Directory）是公有云面向企业客户提供的一套多级资源（账号）关系管理服务。其本质是建立一套与企业相关的，基于资源使用的关系结构。资源目录具有全局一致性的特点，方便管理者基于此关系结构，对企业内多个应用服务所对应的各种资源进行高效的规划、构建和管理。

资源目录支持基于企业的业务或生态环境，让用户方便的构建出体现资源关系的目录结构，并将企业多个账号分布到这个目录结构中的相应位置，从而形成资源间的多层级关系。企业可依赖设定的组织关系进行资源的集中管理，满足企业资源在财资、安全、审计及合规方面的管控需要。

资源目录还将向外提供越来越多的数据服务，类似账单、结算、操作跟踪以及合规审计类应用都将与它无缝对接，共同为企业提供构建在业务关系之上的服务能力。当企业的账号按照需要被分布到预设的目录结构后，企业便可以设定其中一个（或多个）账号为成员账号付款，实现统一结算，同时也可以允许权限用户进行企业所有账号的账单管理，满足其财资管控需要。

3.3 资源组

资源组是在公有云账号下进行资源分组管理的一种机制，资源组能够帮助组织解决单个公有云账号内的资源分组和授权管理的复杂性问题。如果当前的云架构如上文所述，组织内相关部门或分公司正在使用同一个公有云账号管理各个地域的所有云资源，则可以使用资源组作为资源隔离和权限管理的容器，并为每个资源组设置管理员，每个资源组管理员可独立管理资源组内的所有资源。在账单分析时，查看对应账单消费数据，从而解决不同业务的成本分摊问题。

3.4 资源共享

资源共享（Resource Sharing）是指多账号间通过共享的方式将一个账号下的指定资源共享给一个或多个目标账号使用。企业在使用公有云服务的过程中，会创建多个公有云账号，并在这些账号下订购了不同的云服务。某些场景下，企业需要在一个特定的账号下集中采购某类云资源，并希望将这些资源共享给企业中其他的公有云账号共同使用。此时，您可以使用资源共享服务解决该问题。资源共享的方式包含允许共享给任意账号和仅允许资源目录内共享两种。

3.5 标签管理

标签是云资源的标识，可以帮助用户从不同维度对具有相同特征的云资源进行分类、搜索和聚合，让资源管理变得更加轻松。标签是最为灵活的轻量级资源管理方案，同资源目录及资源组不同的是，标签不会受到账号体系的限制。

标签分为系统标签及用户自定义标签。如Dataworks、ACK等云产品，在创建时会自动添加默认系统标签属性作为标识。当企业云上资源只有几个或十几个的时候，通过人脑记忆或人工记录即可完成资源的分类。但是，随着企业云上资源不断增加（大型企业资源数量甚至成千上万），单纯依靠人工进行资源的分类变得越来越不可靠。此时，需要借助平台化能力来解决这个问题。

在实际的使用场景中，云上的资源管理者都有基于不同业务团队对资源的不同使用情况，对账单进行拆分用于内部结算的需求。这时，管理者可以使用公有云标签服务为资源绑定标签，然后使用成本分析功能等多维度查看账单，实现基于标签的成本分摊管理。

标签的使用也具备极高的灵活度，有三种不同级别维度可供选择。最常用到的是实例级别（如ECS、RDS等）的资源标签。其次是分拆型服务场景（如OSS、CDN等），分拆型云服务的分账维度往往不是账单中定义的实例维度，而是更细的分拆项维度。例如CDN的费用需要分拆到各个域名，OSS的费用需要分拆到各个Bucket，共享带宽的费用需要分拆到各个EIP，RocketMQ的费用需要分拆到不同的Topic。最后是集群型云服务场景（如Kubernetes、E-MapReduce）等。以E-MapReduce为例，用户只需要在集群维度绑定标签，该集群下的资源就会自动继承该集群的标签，以此来区分不同集群下关联的资源及产生的费用。

3.6 资源管理方式对比

上述所提到的资源管理方式，其中资源目录本质上建立的是一种跨账号维度的逻辑关系结构，而资源共享仅针对少数基础设施级别的云资源如VPC、ROS、ECS镜像等有效。本章节将着重比对账号、资源组以及标签这三者的适用场景及范围。

在资源管理的方案制定与实施中，并非是非此即彼的关系，而是随着内外部环境变化，针对企业在不同永云阶段诉求的组合使用各类方式。

3.7 资源管理设计方案

在云成本管理实践中，资源管理方案规划是一项需要长期运营并且随着组织架构、云上资源用量变化而不断做出调整的精细化治理工作。因此资源管理的方案规划需要适应来自企业内外部变化的挑战，平衡管理成本、沟通成本与资源成本之间的关系。结合以往客户在不同阶段、不同行业属性的资源管理实践经验，沉淀出一套资源管理的指导方案。

组织架构是企业的流程运转、部门设置及职能规划等最基本的结构依据，常见的组织形态包括中心化管理以及业务自治两种形态。中央集权制的组织通常会有统一的云平台管理团队对网络、安全、基础设施等统一管理，各业务团队提出需求后，交由该团队负责具体实施。业务团队仅作为资源的使用方即可。而业务自治型的组织架构会将业务生产管理的职能下放给业务团队，形成二级管理员角色，平台管理团队仅在涉及到重大的架构改造过程中参与其中。需要注意的是集中化管理和业务自治实际上处于光谱的两端，企业需依据其自身实际情况对“人、权、财、物”这四个核心能力定义职能边界。

资源管理设计核心实质上是关于在不同时期如何平衡管理复杂度及精细化治理之间的关系，因此同用户处于不同用云阶段、不同规模的资源用量，人员数量有密切关系。不建议在上云初期，立即对云资源管理设计出较为复杂的管理方案，提升资源管理的学习成本和实施成本。同时，也应考虑当前架构需要满足未来架构可扩展的能力。

4 资源管理最佳实践

4.1 上云初期

当企业开始业务使用时，由于资源用量相对较少，账单的拆分及成本核算等需求相对较弱，因此在上云初期企业对云上资源管理的核心诉求主要体现在资源隔离及权限隔离上。

资源隔离性需求一般可通过账号隔离及网络隔离实现。通过账号隔离，不仅能满足资源在实际使用时与不同环境、业务线的网络隔离，同时也满足用户对于资源权限管理的基础需求。对于未来架构扩展而言，将生产及测试资源放置于不同的账号下能够有效实现不同角色对于资源创建、访问、删除等运维管理的实际业务需求，避免因权限过大，或跨职能角色等问题导致的资源误操作所引发的生产故障。

对于运维管理等中心化平台管理系统，可将其独立部署于一个账号下，并通过VPC对等连接将该网络环境与不同环境资源打通，避免重复创建资源所产生的管理成本。

4.2 成本中心增加

当成本中心逐步增加之后，企业对于分账管理的需求开始显现，云平台资源管理架构依据团队职能划分可以基于账号维度或是资源组维度构建。在该阶段，虽然云资源账号开始增加，但是并未达到一定量级，对复杂度影响可控。

1 . 账号维度划分

基于账号维度划分的划分原则是两个部门、团队之间的关系耦合性弱，互不隶属，且团队内各自有专业的职能部门对账号内资源进行管理。但划分维度不宜过细，如果是同一管理团队对其进行管理，则没有必要按照不同系统维度划分云账号。

2 . 资源组维度划分

通过资源组维度划分的方式，是在满足成本拆分到不同业务线的同时，最小化地降低管理复杂度。管理团队多为同一团队。由下图所示：账号的划分维度以环境维度划分。

3 . 多账号资源组管理

当企业内较独立的成本中心超过3个时，由上文所述，资源管理的难度将面临新的挑战，除了业务资源外，包括安全、运维、网络等资源的管理权限、成本分摊等进一步细化。除了基于不同业务划分资源外，共享型资源随着组织内部各职能团队的明确定义，也进一步拆分到不同的账号下。

此时，平台管理员可通过资源目录实现对多账号、资源组场景下财务、配置审计、操作审计等业务需求的统一管理。

网络部门：负责管理平台级的资源划分。如云企业网、边界路由器VBR、CDN流量产品等。

安全部门：负责管理WAF、DDoS、云防火墙等设备。

4 . 基于标签对资源管理

当用户需要对公有云整体资源分组，而不再是对单个产品分组时，可以考虑使用标签对资源更为精细化的分组。资源组和资源标签本质上都是在配置资源的映射关系，但标签更为灵活。资源组和资源的关系是一对一的，而资源标签和资源的关系则是多对多的，对于一些PaaS级服务来说，资源组管理的方式略显灵活度不足。而标签管理在成本分析又或是运维管理时，可以实现用户基于不同维度对资源管理的核心诉求。

在标签实践初期，标签设计不应该要求团队应用打上过多标签，这只会引起对标准执行的抵触，最终导致不合规。标签设计的最佳实践通常是结合组织及业务架构、分账逻辑的直接体现。因此在规划标签时，便应该确保每个有权限申请创建资源的用户均需要参与到标签规范的制定当中。在规划标签规则时的常见的问题是不同的角色由于核心诉求不同，因此只能从自己的视角去看待如何规划使用标签，技术负责人一般会从研发效能层面设计标签体系，但并没有办法满足财务分账的诉求。标签体系的设计需要考虑将财务结算、分账体系以及未来云资源费用优化纳入其中。

在实际使用标签时，也会存在不少问题，在创建资源时，未能及时绑定标签，导致了基于标签分账时的准确性，又或者在运维管理过程中，由于缺少标签导致的管控风险。针对该部分资源，可以使用配置审计查找未绑定指定标签的资源。

来源于 公众号 云原生Lab