联想FinOps实践与平台工具建设之路及专家研讨

今年以来，我们举办了多期FinOps的专题分享，邀请了美图、腾讯、B站、趣丸、知乎等厂商和行业专家，分享他们在FinOps领域的经验。我们也发现越来越多的人对FinOps产生了浓厚的兴趣，而且FinOps的成熟度也在逐渐提升。

降本增效，一直以来都是IT人关注的焦点。我们坚信FinOps将成为降本增效的重要工具和有力抓手，逐渐渗透到每个单位和组织，并在未来持续发展。

12月26日晚，最后一期「UGeek大咖说」直播活动，我们邀请了中国信通院云大所研究员白璐、联想高级开发工程师彭磊、B站技术栈专家叶翠、知乎高级技术专家陈文权、招商基金架构师王洋等五位技术大咖，齐聚一堂分享各自行业在FinOps上的实践心得，共同探讨FinOps在业界的应用与发展。

下面就跟着鹿小U一起回顾本期直播的精彩内容吧！分为上下两篇，此为下篇！

直 播 回 顾

PART2：《联想FinOps实践与平台工具建设之路》-彭磊

随着联想IT和业务部门在多云使用上的增长，如何更好地理解和管理IT成本，实现成本的透明化和优化，联想多云管理团队在FinOps的实践过程中，建立了一套相关平台与工具，联想多云管理业务高级开发工程师彭磊在本次直播中分享了建设的主要内容和方法。

联想多云管理历程和挑战

>> 联想IT全球基础架构和云布局

首先联想在用云上是全球化私有云的布局。联想在中国、欧洲、美洲都有部署数据中心去做私有云的布局。第二的话就是接入大量的公有云，包括国内著名的云厂商，以及国外的一些商业厂商。基于以上两点，联想在业务上，随着业务复杂程度的增长，采取混合云的价格方式，同时也通过SD软件定义广域网专线的形式，构建一个具有全球覆盖的SD-WAN的网络。这个网络不仅提高数据传输与稳定连接的效率，还能确保全球业务的顺畅运行和数据的快速访问。

>> 混合云费用管理的困境

联想混合云管理团队通过长期的实践运营，发现在混合云费用方面存在着诸多困境：

• 多种混合云环境下账单维度不统一，无法构建统一的账单管理业务语言。

• 账单记账无法分拆到具体业务部门，具体项目，无法对项目和运维费用进行有效核算。

• 账单计费项不明确，无法追溯资源的有效使用率，造成资源使用的浪费。

• IT组织无法有效体现在IT管理上的效能，成本管理不清晰，更无从谈起二次定价，增加附加值。

• 对私有云设备计费，对容器平台计费，以及业务对售卖的服务使用了多少成本，上升为主要需求。

• 账单管理逻辑复杂，人员消耗大，自动化程度低直接影响企业业务 time to market。

FinOps工具建设理论基础

>> FinOps 概念

FinOps 是“Finance”和“DevOps”的综合体，强调运维过程中的成本管理和资源优化。

不仅仅是一个将财务和技术结合起来的领域，通过FinOps，IT和财务部门可以更好地合作，实现更好的业务成果和财务可持续性。

>> FinOps 目标

根据下图调查，很多人有理解，也有误解，大多数人以为FinOps是减少支出，把云计算助力业务发展的价值放在首位，而不是把省钱放到首位。然而，我们要把云视为成本中心，则需要将技术成本和业务成本进行相结合确定单位成本的一个指标，而不仅仅是看技术成本的开支。

因此，FinOps 的目标不是减少支出，而是优化支出。这意味着，虽然客户体验和安全性非常重要，但主要优先事项是物有所值。

>> FinOps 的三个阶段

1.  Inform-通知阶段为所有利益相关者提供所需的信息，以便于他们了解情况，从而做出有关云使用的经济高效的明智决策。

2. Optimize-优化阶段从通知阶段获得的见解，确定并采取措施来优化云支出，同时提供相同级别的性能。

3. Operate-运营阶段为正在进行的云成本管理和云治理建立框架，以便组织能够长期保持最佳的云使用情况和成本效率。

>> 联想引入FinOps

联想主要从成本预估、成本洞察、成本优化、成本控制四个方面来落地FinOps。

联想FinOps平台工具建设

>> 技术设计方案（云管平台部分模块）

联想整个费用管理通过公共服务，包含IM或工单等基础设施或服务来支撑费用管理。另外，资源纳管也会支撑费用管理。

从上图可以知道，联想整个费用管理的方案特点：

• 混合云计费及多维度账单

• 费用及资源优化

• API调用支持

• 可组装模块化设计

>> 主要功能模块

• 首先是成本预估，支持公有云成本预估、私有云成本预估，以及多云成本对比。

• 成本洞察，支持计量采集与计费、成本分摊、定价策略与账单调整、多云统一账单、组织/项目/成本中心账单、多维分析、穿透视图与明细。

• 成本优化，支持使用率优化、实例大小优化、自动调度、节省购买建议、节省计划分析。

• 成本控制，支持成本额度分配、预算告警、余额与收支管理、成本异常分析、成本预测。

>> 预算先行 - Pricing 定价计算器

用户在上云和申请使用云的时候，存在诸多痛点，如：

• 对云估价工具不熟悉

• 多云比价的估价需求

• 估价和申请系统分离

• 有通过规格快速搜索实例的场景

针对以上用户存在的痛点，联想提供Pricing定价计算器，支持多云资源查询估价和比价，可根据SKU规格需求推荐实例，可自定义企业内部折扣信息，支持购物车放入多云资源，且可整合企业内部工单流程。

>> 划分组织责任- 多云精细分账与分摊

在划分组织责任上，联想提供多云精细分账与分摊。先解决用户的第一个痛点，首先是账单，想必大家都看过每一朵云，它的账单结构都是不一样的。第一个是结构复杂，第二个是量大，第三则是两者是比较相关的。

另外，大多数企业会采用混合云的价格方案，这种跨云的资源划分到财务单元，是有动态策略需求的。对此，我们提供公有云与私有云的用量配置，以及更灵活性账单财务单元。同时，多费率的分摊规则目前支持包括动态构造的共享分摊体系。我们的特点是多云账单的整合与一次性拆分。例如，你在云厂商看到的，都是11朵云，但是你的企业，不止一朵云的时候，就需要根据企业实际的项目把账单全部整合在一起，再一次性拆分，而我们的账单配置的页面，以及调账任务管理是自动化的。

多云精细分摊有两个重要的部分。第一个是AWS账号级别分摊规则，这种账号级别的分摊，一般是统一采购的。第二个是财务单元分配配置，例如在配置一个财务单元以后，支持多种人的动态配置规则。需要特别提出，我们有不同的核算方式，即配置财务单元，如果选择无的话，就是正常的，就是能够接收其他共享项目的费用分摊。

财务单元分摊这一块的话。它意思就是说，财务单元费用按照比例分享给指定的财务单元说我们财务单元我就不配置这些规则了，那配置一些其他财务单元，其他的财务来帮我承担这个费用。以上就是我们提供两个比较有特色的动态规则。

当然，我们的规则不止在多云的经济分账和分摊，还有自定计费的二次定价。大家知道，企业运营费用的时候是相当复杂的，它不单是有零成本，还有管理成本，积分折扣、以及额外的采购费用，我们可以进行附加费的配置。

>> 数据洞察-账单透明可视化

前面已经配置了账单，接下来账单拉下来进行共享分摊后，需要看最终的效果，这是我们最直观能感受到的东西。

云上其实也有一些账单查询工具，但它是有一定的局限性的。我们多数据的费用，对于报表会耗时较大，为此除了提供统一报表以及企业业务固定报表，我们还提供更加灵活的自定多维度的报表，满足领导对临时汇报报表的需求。最近几年AI GC也比较火，那我们也在积极推进AI GC，通过自然语言方式生成报表报告的能力。

>> 日臻完善-成本优化

大家在做公有云费用管理的时候没有统一的标准，包括操作不统一，然后无法全局查看多云的优化建议，甚至无法满足定制化的规则需求，且无法查看已购买RI和SP的覆盖率。

对此在成本优化上，我们回购买或修改RI/SP，然后进行订购使用覆盖率的分析。在负载策略提供调整大小建议与变更实例类型建议。

>> 成本优化策略五个阶段

通过长期的运营经验，将成本优化分为五个阶段，进行有效的闭环管理，对企业内部是管用的。

• 第一阶段是：量体裁衣，即调整是咧规格

• 第二阶段是：张弛有度，即可使用一些自动扩展的资源

• 第三阶段是：承诺用量，即节省计划

• 第四阶段是：更新迭代机型

• 第五阶段是：事后总结分析

以上，就是关于《联想FinOps实践与平台工具建设之路》的内容分享，如果大家对FinOps感兴趣，可以关注添加鹿小U（微信号：Uwin-Technology）为好友，进入技术交流群，跟技术小伙伴们一起讨论哦！

PART3：Q&A研讨会

Q1：首先让我们回归到这个话题，很多朋友们可能疑惑的是，我在什么时候去建设？当企业出现哪些指标和现象时说明企业可以考虑采用？那么在这个时候如何切入？比如说在基础能力建设上，还有人员安排方面等等。在这个话题上，来自不同行业都积累了丰富经验的四位老师分享了各自的一些经验与观点。

王洋-招商基金架构师

我们当时做这个事儿的出发点是因为基础资源的采购，领导会问这次为什么买这么多资源？为什么买这么多服务器？这些服务器到时候会给哪些业务系统去用？每次我们会有一些解释，但是就是具体来说的话还不够的量化，且从量化层面上还不够足够说服力。因此，当时我们就在想怎么能够让这个事情更有说服力，能够量化出业务系统到底使用了多少资源。然后从这个角度去做这个事儿，那什么时候开始考虑，我觉得和公司运行的阶段有关系，如果说公司目前发展阶段主要以业务发展为主体，对成本的考虑没有那么重的时候，在企业内部推的话，其带来的收益没那么大。

所以就何时介入这个事儿，我觉得一是和企业发展到一定的阶段有一定关系；第二就可能和领导者对财务这件事情的敏感程度有一定的关系；还有一个因素就是和大环境有关系，就这两年整个大环境不太好，所以大家对成本这一块的关注度也提高了。

那做这些指标的话，其实这里面指标很多了，因为其实每一个业务系统它有计算资源、网络资源、存储资源，有这种各样的监控安全，有很多资源，那么这些资源其实每一个都可以作为一个指标项来进行考察。我觉得这个事做的时候要做一个突破点，就是不要去大而全的都做，而是选择一两个点先切入进去做。

从我们这边的话，目前刚开始主要就是从计算资源开始，然后是存储资源。从这两个角度来去做这样一个事情。为什么从这两个角度切入，则是这两个角度相比较来说容易去量化，而且比较容易去接受的一个点，因为你的计算资源直接关联到了你的服务器的采购。然后你的存储资源直接关系到了你的存储容量的一些采购，这两个角度是比较直观，所以我们就选用这两个指标。关注这两个指标以后，我们会去建立一套模型，就是从业务系统的维度，从计算、存储这两个层面去把业务系统下所有的应用进行拆分，然后拆分出每一个应用它到底用了多少计算资源和存储资源，然后去做这样一个一个模型的简单计算，然后在计算完这个模型之后，每次在提这个资源申请的时候，就需要比如说有个a系统或者b系统，整个运行下来，它现在水位都很低，那这个时候你还要去申请再去买一些资源，那这个时候可能就会受到一个挑战，所以我们就给管理层提供这样一个数据，就是我当前某个业务系统，它当前水位的一个运行情况，那么在这种情况下，领导就会更好的去决策你这个资源还要不要去进一步投放。除了这一方面之外，我们还会基于现有的资源情况去做一些容量的缩减，用现在云计算的一些弹性的能力，将这些能力用下来以后，把我现有的一些资源去进行资源的回收，达到整个闭环管理的效果，然后提升资源利用率，整体降低企业运行成本，这样我们就可以看到一个比较切实的收益结果。那具体到我们这边的话，我们每年会去通过这种方式在年底的时候会形成一个报告，这个报告里面可能就是我今年一年收了多少资源，折算成物理机可能是多少存储，根据市场价来算，可能就降低到成本。

叶翠-B站技术栈专家

B站是从2022年年初开始去落地FinOps框架的，那在2022年之前，其实我们也会做预算的管理，以及一些优化的项目，但是都没有一个整体系统化的框架。在2022年初的时候，我们了解到FinOps框架，觉得它非常适合在整个公司的云成本管理上去落地之后，然后我们在2022年年底的时候，当时的目标是做到比2021年的技术相关的成本是不增长的。当然，我们在年底的时候不只做到不增长，而且在支持业务增长的情况下，我们还做到了整个成本是负增长。在2023年，今年的我们又进一步的去完善了我们整体的FinOps的相关的不只是工具，还有成本分摊，以及包括一些优化的项目的落地。那今年，我们整个就是优化的收益会更多，我们也同样的能做到年比年的负增长，也就是说，我们其实在落地发布的两年期间，我们是做到了持续的一个成本的负增长，这是在公司的业务还在大力大幅增长的情况下做到的。

那说到企业什么时候需要去考虑到FinOps，我觉得可能有几个契机吧，当你的企业意识到云成本的管理，它遇到了问题的时候，以及你是有人力能够投入进去做这件事情，我觉得就是这个时候可以去做了，或者说当你发现你的云成本，它是有浪费的，它有优化的空间，那你觉得说我可以在这上面去有收益，也是可以开始去做管理的，或者当我们如果是你的企业的高层，他想要弄清楚你的投入产比，然后你服务一个DAU，它带来的成本和它对应的收入，想要把这个弄清楚的时候，并且你想优化这个RI的时候，那么也是时候可以去开始开展工作。

其实做FinOps，就我非常同意，刚才王老师的观点是有点击面框架，其实它很全面，但是我们企业在切入的时候，可以从你最最关心的一些问题出发。像王老师刚才说他们其实是从计算资源和存储资源开始做起的。那B站作为视频类的网站，我们的成本大头是带宽，所以我们最开始做也是从带宽去落地。包括点播带宽、直播带宽等等一系列的这些带宽的成本，我们发现从带宽的成本问题去切入，后面我们去做数据，发现缺流程，后面我们就去补流程，我们用流程把相关的这些人都串起来，然后最后去推，我们需要去做的这些技术优化的相关的优化项目。然后我们发现有资源浪费，那就去做一些资源运营相关的工作，所以我觉得企业在开始做的时候，就是切记不要铺的太开，开始就从你发现最浪费的地方是什么，就从这里切入就可以了。

因为B站是一个典型的混合云的架构，那么我们刚开始做FinOps的时候，如果你的人力很紧张的话，那么你可以follow一些就是已经大家在网上分享的经验。例如说你多云，不要绑定在某一家云上，从而获得云的议价权。你的成本抓大放小，你先做你主营业务相关的等等的这些一些小tips都可以帮助你去更好的落地FinOps。

陈文权-知乎高级技术专家

知乎在2022年上半年才正式发力FinOps，知乎是怎么做的，完全是只有账单。没有运营也没有优化。当时开始签注这件事的时候，是自上而下的对去关注这件事情。在以往的成本支出这块，研发不太关注这部分成本支出。

2022年9月份开始做这件事的时候，我们一开始第一个阶段，我们是先做了第一件事，怎么才能把账算准？账算准，然后我们唯一的目标，我们先不考虑优化，我们说先把账算准，先让各个业务，各个团队，各个角色。先能感知到成本从哪儿来，花到哪去了？第一个目标我们大概用了两个月时间，我们就上线了第一版的成本系统，那不叫成本运营系统，成本系统我们只做了一件事，就把成本账算出来。那么这样算出来，我们当时做了两件事，第一个是定价。我们把整个知乎的语音产品，大数据平台、计算平台，gpu计算平台。全部商品化。商品化了以后，然后我们就开始做分摊，发现很多问题，就是怎么算得准。这个时候就要去做用量，一般情况下账单就是用量乘以定价，实际上定价对我们这边不是什么太大问题，因为我们知乎整个基础设施底座是在云上。所以云采购成本多少钱，我们定价跟随着这个云产品的定价，对我们是进入采购成本和售出成本基本上能打平的会留一点，但是基本上打平了，所以这个定价不是什么样的问题。

其次分得准，那就要去做治理了。治理花一段时间。有些是第一次进行治理，第一轮治理完了以后基本上把账算清楚了。所以说到年底的时候，我们居然把这个账算清。2023年的时候我们有了明细的账单以后，我们开始进行运营策略，刚才叶老师说的特别好。我们只能抓大放小。当时怎么做，把知乎的100多项云产品资源，当时盘了146项云产品资源。但是实际上按照排完序下来发现，前十项产品占了80%的产品成本。

现在成本运营系统是有账单模型，有运营策略。有优化策略，系统性相对比较完善的。那在这完善的过程中，也参考了很多，包括B站之前写了一个很好的分享文章，参考了很多思路，当时借鉴了很多分享的一些思路。所以说现在这套成本运营系统说在知乎内部相对来说已经适应下来了。现在再问我最大收益是啥，第一是优化了一些成本，取得了一些收益。第二个就是说已经把成本意识在产研层面增强，哪怕我去申请部署上线一个业务要过多少盒？扩大容器上下几个破的，那很可能就要考虑，我需要这么多盒儿，这个成本儿意识现在特别明显。那有了成本意识以后，无论是从业务的负责人到各个团队的研发层面。我们在做这件事的时候，我们在做一些指标的时候，就会很支持这份工作，他们甚至会把这些指标写进到自己工作的OKR中，那这就是一个好现象，把成本当做工作的一部分。

彭磊-联想高级开发工程师

我们现在整个团队，是从运维和研发就是云管的团队。当时我们团队来使用公共运营服务的时候，我们第一个月的账单只有100块钱。100元左右虽然不多，但是我们已经有一个成本管理的意识了。

成本管管理上，我们团队的定位是多云管理团队，那我们必须要构建属于自己的成本管理，那也得益于我们。实际上我们整个团队，它是紧随其后的，但之前的话我们没有说是做我们内心想的是一个成本管理，但当时文化或者理念还没有进入到我们这边。我们当时有自己的一个云管平台工具，当时拿到了CMDB的一些使用量，这些数据也算是一种契机吧。

然后第三点就是我们的业务是递进的，包括看之前我们PPT也讲到了我们联想它是一个混合云的价格实施方案，就是有不同的业务团队来找我们团队进行一个开通资源，然后去帮他运营资源的时候，然后包括每个月账单递增的时候，我们整个成本管理就变得急切起来了。那做这件事情往前追溯的话，这边我们会在2020年的时候，当时我们针对的是AWS这一块，因为我们整个联想业务，包括国内、海外的一些业务，我们会用到一个AWS的资源，那我们在运营的过程，我们也发现了有大量资源的浪费。资源浪费还是挺明显的，经常有一些空闲的资源。还有就是通过这样的形式，我们发现AWS的资源上面没有什么标签，我们也找不到谁来申请这个资源的时候，我们就想对AWS这边入手，那恰好的各大云厂商他都有自己的理念。我们当时没有一蹴而就，我们首先想到进行一个商务谈判，当时我们的整个公有云是的支出已经是非常大了，那我们实际上第一件事情并不是完全想到就去构建一个工具，而是商务谈判，咱们去拿到了一些大客户的一些折扣进行议价，第二的话就是每一朵云都有自己的成本优化，或者是洞察的一些工具，那对于一些公司，他确实没有研发力量，咱们可以使用他的这些工具去做数据分析，然后通过打标签的方式把它定位出来，在初级阶段可以。可以帮助到大多数团队解决问题。然后随着业务的递增，实际上我们就想到的是构建自己的公有云，或者混合云和私有云的这样一个成本管理工具。

通过借鉴一些行业分享的经验，我们就想去做财务单元，把账单跟内部的项目关联起来。然后逐步的又把账单绑定到成本中心，去做更复杂的规则。实际上整个账单形成了一个灵活的配置，帮助我们构建了一个动态化的策略，和我们实际企业中相关的项目中使用云的一些费用绑定起来，然后才会分析阶段，会把我们的一些账单报表对账，保持云成本的出账户，跟财务的一个对账，这些都是保持一致的，以后我们就考虑去优化这些东西。比如调整大小，还有就是去做这种R I、SP的这些覆盖率进行分析。后面我们又会想到就是每朵云其实都不一样，就是我们针对每朵云，大多数就是主流的，都做到了一些使用承诺折扣，还有就是预存实力的这样一个策略的利用率和使用率和覆盖率的分析，做完以后，我们很多时候还是会手动去控制它的一些大小。到第三阶段我们就想说，其实对于运营，它是业务部门在用，然后但是具体就是我们是作为一个运营部门的话，那我们去主动去帮他调整这些规规格大小其实是不太合理的，也就是说我们不清楚它的业务，那我们会考虑到把账单数据权限给到具体的一个业务部门，让他自己去看到这些报表数据，看到他的一个使用率、覆盖率，让他自己管控，然后可以去配置一些动态的策略额度。

Q2：在联想建设过程中是否有通用的能力模块，然后以及大家在实践中是如何运营来优化云成本的？

彭磊-联想高级开发工程师

首先我们做优化云支出，首先第一个必须要清晰就是调整于支出，而不是去节省。我们最终的目的就是要达到一个，你用到了一个好的云资源。然后第二的话就是你的交付。你买的这个资源，它确实是相对于比较便宜一点。

第二个要去减少使用，就是使用率的一个优化。我们减少资源的使用来避免成本的浪费。我举个例子就是这种自动调度就是终止这种闲置的资源，调整超规格的资源，还有减少非高峰期时间运行的资源数。比如说周末一些业务根本不会运行，可以停止资源的使用。

第三点就是要减少支出。费率优化怎么讲，为持续使用资源就是长期稳定使用资源支付更少的费用，能很快想到的就是比如说改变云计费的结构。我们常聊到的就是按需调整。最后一点就是。你得想办法去优化自己的技术架构，当然最后一点是最困难的，然后通过这样几种方式可以从。可以适当的去优化自己速度，当然每一个企业落地是不一样的。这边就做一个参考。

Q3：优化云成本这方面的一些能力？

陈文权-知乎高级技术专家

成本这块儿我们当时做了几个策略：第一个是会去做一些多云比较。因为知乎的技术，刚才说了知乎的底座是多云。阿里，华为，腾讯，百度等大概有七家云运营商，那多云比价有一个很难的点是啥？就是说同一个产品不同规格在不同云上的差异模型不能统一。这个时候就很麻烦。

举个例子，比如说同一个机器多少内存？阿里和百度说我们和腾讯比不了，我们就是比较好，那价格就是比较高，那这个时候我们就要解决这个问题。究竟是用哪个好？比如说同样的八核16G。腾讯比阿里会便宜一些。那么能不能用腾讯？不一定，得看稳定性，得做POT测试，完了以后来权衡一下。这个时候我们就要去做一个分析，非常琐碎的工作，怎么把这个模型统一起来。我们当时做了很多工作，比如说机器室内不同机型。不同配置。我们要做收缩。在线业务我们不可能提供那么多繁杂的机型。知乎之前有几十种机型。我们看一下做急性的收缩，把这种配置尽量减到一个模型。我们配置类型尽量单一，也不需要单一吧，尽量减少不能提供那么多科学的机型了。那么多科研进行这样子的话，我们的比价就没法比了，现在知乎正在往这个方向走，比如说容器机型可能将来就提供单一的几种机型，那存储很可能将来就有一两种机型。

第二个，实际上我们在优化支出上面，我们在技术侧也做了一些事情，尤其是跟你的业务贴合起来的话。现在很多公司都在做，且都做很长时间了，那知乎也是起步相对比较晚，当时在线同步上来以后，整个机器的利用率有提升了将近有七八个点，这个效果还是很明显的。还有一个是去观察整个知乎内部的各个资源的使用的合理情况。怎么叫合理，你这个业务里边你用的是存储主力是存储，那么你业务里边主力用的是计算。主流应用是计算，那这个时候我们就要看业务本身，看它资源的配比方式是不是合理的。很可能它业务线的存储很多，它的计算和它的存储，它不成比例，那可能就更浪费了。那这个时候，我们需要跟业务的优先的负责人，来共同治理。

Q4：现在很多企业在落地实践的时候，它已经不仅仅局限于云了，还涉及到整个IT资源。那么接下来的这个问题就是关于IT资源精细化运营的难题解决方案。在IT资源管理的过程中，大家都曾面临过那些挑战，并且是如何解决这些挑战？

王洋-招商基金架构师

招商基金在落地FinOps的过程中遇到两个方面的难题。第一个是关于模型的建立，我们做的整个核心理念，就是以业务系统为中心。业务系统中心把业务系统下使用的资源都拎起来，但是又从落地的角度来讲，刚开始只关注了计算和存储，但是在设计模型的时候，其实并不是只关注了计算和存储。那么第一条就是在设计这个模型的时候，怎么去合理的去把这些维度给建立起来，建立哪些维度，这是一个理论层面的东西，但是你具体落地下来的话，是要和我们的CMDB做结合的。那和CMDB做结合的时候，这就涉及到第二个问题就是CMDB的治理问题。如果CMDB里的数据不准，或者CMDB当时在设计的时候，理念和整体的架构不一致，又会带来一个冲突点，那这个时候你就是需要去调整你的php里面的模型，或者说去把CMTV里的数据进行一些调整和优化，这也是第二个问题，为解决存在的问题，主要是对CMDB层面做一些调整和一些资源的优化，通过优化来解决问题的治理。

在这个基础上，还有一个问题，就是当一切都准备好了，这就面临了第三个问题，就是在做资源的生命周期回收的时候，又带来一个问题。我们知道有些生产环境，它是不能随便去做停机的动作的，那么你想做这件事儿的话，就有几种做法。第一种就是这种重要的生产信用，可能前端比如说可以通过灰度的方式，或者说节流的方式，把流量转到一边，然后对一个节点进行调整，这是一种方式；那第二种方式就是有一些业务它确实有一定的停机窗口，那么就需要去做缩容，这件事匹配到它的停机窗口上。这个时候其实也是在流程里面需要去做优化的，因为默认情况下，我们的资源申请的资源回收的流程和它的这个窗口变更流程是两个流程。那你需要把这两个东西给贴合起来。那实际中我们遇到的一个挑战点，第三种情况就是即使有一些资源，它是可以让你去做回收的，但你在回收的时候，可能还是要去关注到周边的一些应用的可用性各方面的指标，其实这个东西你还要去做相应的配套的一些东西，就类似于你可以把它当做一个变更来看待，还要去按照变更的一些流程去做相应的一些辅助的措施，所以这几个方面我觉得就是都要去把它做好，才能把这几个问题给解决掉。