Finops成本优化企业实践-可视化篇

引言：上一章讨论了finops的一些方法论，笔者在拿到finops官方认证finops-engineer certificate之后，将方法论运用到所在项目组中，并于今年完成了40%的费用节省。在此将这些实践方法总结沉淀，与大家分享。实践包括三篇：可视化篇，可优化篇，可规划篇。这三篇里不讲太多理论，主要以实践为主，干货满满，理论部分可以看上一篇。

一、月度账单分析

1. 目的

可视化的目标，就是讲清楚你在云上花的每一笔钱。在起步阶段，不需要在这一步花费太多时间，遵从“爬、走、跑”原则，在较短时间内，把top5的cost分析清楚，后面优化阶段够你省的了。

我之前做TAM的时候，服务的一家客户，一家做ERP的公司，领导层决定做finops项目，于是上来就要先搞个可视化平台，于是平台从开发到上线三五个月过去了，还没进入优化阶段呢。

2. 方法

最省事的方法（不是最快，最快的方法是把我请过去做）：让你们的云厂商来做。找到你们的TAM，让他每月做一个月度账单汇报，并给出优化建议。

当然这个方法也有一些弊端，厂商不够了解你们的业务，不了解你们这个月做了什么事情。比如你们这个月对集群做了一次蓝绿升级，遗留了一堆实例和ebs；或者你们对跨az的eks集群扩缩容了，遗留了一堆pvc（ebs不支持跨az挂载）；或者你们对应用升级了，打了一堆计划之外的snapshot等等，厂商看着就会很懵。

自主分析，依托厂商提供的工具，以不同分组和纬度组合，得出你所需要的数据。本篇以AWS提供的cost explorer为例（阿里云、腾讯云、华为云都有类似的工具）。

3. 方向

账单分析的下一步是优化，那么优化的方向是我们需要在分析阶段break down的。不要上来就想着把最贵的干掉，确定优化方向要结合考虑业务稳定性、难易程度、人力投入成本。我推荐从以下四个优先级来做：

3.1 冗余资源

首先识别出多余的、不用的资源，删除不会有任何业务影响的资源，这部分也是比较容易识别的。例如没有使用的ec2，没有挂载的ebs，时间久远的snapshot，不再使用的vpc endpoint等等。

3.2 能快速恢复的资源

一些可快速恢复的资源，删减后可以快速恢复，对业务影响时间较短，可以放到第二优先级。常见于集群的自动扩缩容、spot节点替换、standby节点缩规格等。

3.3 人力成本投入较大的资源

前两个优先级做完后，基本可以省下一笔可观的钱，还想要继续深度优化的话，就要考虑一些投入比较大的、当然产出也比较可观的调整。比如架构优化，或者体系化地做资源整体的回收策略。

3.4 无法恢复的资源

这不一步不推荐做，尤其不推荐放在不成熟的finops阶段做。要做这不一定要把稳定性做的非常成熟再做（我计划再写一篇稳定性篇来讨论finops的稳定性如何做），简单讲，面对不可恢复的资源，要做好监控覆盖、应急预案、应急演练之后，且省无可省了，再考虑做这一步。

讲一个真实的案例（可以跳过）：某部门新上任了一位部门领导，在做成本优化时，已经在月度分析的报告中告诉了他，计算资源、网络资源的占比是最高的，存储资源其次，我们应该优先分析计算资源，但他偏不，很倔强地定了一个决策：要清理aws S3存储桶里的数据，把该删的删了，不用的放冰川层。于是拉着一帮人去分析哪个数据是给哪个业务部门用的、花多少钱、占比多少（这三个问题在没有充分打标时是非常难统计的，尤其存储大小和费用的关系，当开启了智能分层时）。S3我们没有打标签，全靠bucket name人肉分析，花了一个来月。然后开始做house keeping，用life cycle左加一条规则又加一条规则，对着20几个桶加出了快上百条life cycle policy，一点都不优雅！最错误的一步是挪到冰川层，standard是0.25 $/Gb/month，本来我们开启智能分层，自动放进归档层只需要花费0.05$/Gb/month，已经很省了，为了再省3分钱（冰川层是哦。0.002$/Gb/month），要强行挪到平川层。挪到冰川层只有两个结果：一是彻底不用（那为什么不直接删掉），二是等待恢复（恢复费用超级贵的，除非你能放三年不用）。结果挪到冰川层的第二天，欧吼有人要用数据，于是开始紧急恢复，关键还没做恢复预案，临时提单给厂商帮忙恢复，花了较多时间恢复。在下一个月的账单里S3不仅没有省钱，倒花两千美金恢复数据，等恢复之后再过一个月，我们看到节省的效果只有1500$，然而却花了几个月的人力投入。

4. 维度

列出top5 的资源，没打标签之前先以service纬度列出，可以是饼状图或者柱状图，主要先定下我们优化的service，定了主要优化目标后，再继续往下细拆。

例如，我把成本按照service分组，可以看出70%的成本来自于ec2，而14%的成本来自于S3，那么接下来我的分析重心就是ec2。

再往下拆，在ec2里面，instance占比67%，other占比33%，再把other细拆：流量占到大头（流量费用即图中的interZone-in, interZone-out），ec2的流量来源于实例之间跨AZ的访问，我们发现是一个大数据的应用集群部署在了3个AZ上，而它每次做map-reduce时在集群内部就会产生大量跨AZ调用，导致流量费用升高。于是有了action1：调整应用集群的部署AZ来减少流量费用。再看图中存在gp2的使用，gp2相比gp3较贵，性能也差，应该全部替换或删除掉。于是有了action2：替换gp2为gp3，清理没有挂载的卷。

对于ec2的instance分析，我们可以打上应用的标签（注意，如果要展示费用明细，不同维度的过滤方式可能会有重叠，比如按照应用分析，A应用的ec2总费用会包含ebs、ec2之间的流量、snapshot），如下图所示，在确定应用的比重之后，可以继续细分，比如按照实例类型、api调用等。具体计算资源的优化方案会在规划篇详细介绍。

接下来是存储的细分，这里的存储特指对象存储，而非EBS存储卷，因为通常来讲对象存储的占比会是一个大头，EBS只是很小一部分，而且随着EC2的优化就被优化掉了。以AWS S3为例，S3存储桶有一个天然优势，即它自带一个key，就是它的name。所以我们可以得到每个存储桶所花的费用占比，所以我们可以很明确地得出哪个桶是我们最需要关注的。如图：

对于S3有两个维度，一个是存储维度，一个是请求维度，这两个维度，都必须搞清楚它的细节以及计费规则，才可有效优化。我们先从存储维度谈起，S3的存储分为如下几层：

在存储维度，有很关键的一步，就是开启智能分层，让数据自动归类，不需要琢磨着把它放到冰川层。如果想针对某个桶做house keeping，那么可以先过滤出具体的桶名，再以存储的维度展示，那么归档层占比较大的桶，就是我们首先做house keeping的对象。

下一个是请求维度，按照请求维度可以看到具体哪个桶的读写请求最多，再结合access log，查询出是什么应用在调用数据，是否合理。

例如下图，可以看到二月份的list bucket和get object请求特别多，可以进一步查询是哪个服务的调用增长。

5. 灵活运用api过滤和cloudtrail

在展示的时候，AWS的cost explorer还提供了一个很好的维度，即api。例如上图中ec2-other和s3 request都是通过api过滤出来的，可以详细看到里面的内容。

结合使用cloudtrail来定位具体费用，通过cloudtrail可以看到具体的资源、对象、时间、账号的事件。例如S3中某个请求在某一天调用频繁，可通过cloudtrail追踪具体是哪个账号在调用。

6. 指标

还记得公式 费用 = 单位时间资源使用量 * 费率 吗？其中的费率可以作为我们观测的主要指标，例如RI覆盖率、saving plans覆盖率。当覆盖率接近100%时，才证明我们充分利用了RI和saving plans。

如图，在周一到周五时，我们对集群扩容，从而使用的按需实例较多，没有被saving plans完全覆盖；而周末对集群缩容，刚好让所有的实例都被saving plans覆盖住。后续在做计划性的扩缩容时，可参考这一指标。

二、异常检测告警

1. 阈值告警

分析报告通常一个月做一次，但如果遇到天级别的问题，那么可以设置阈值告警，例如可以针对某一应用设置天级别的阈值，当超出阈值时发送邮件告警。

2. 异常告警

开启AWS 异常告警功能，当费用忽高忽低时，会发出警告。

三、关联服务费用

有一些服务的费用会相互关联，比如：

当glue频繁调用S3时，S3的读写请求费用会增高，如果开启了kms加密传输，那么kms加密解密的费用也会增加，guardduty扫描S3 bucket的费用也会增加（在guarduty里也能看出具体哪个桶费用最高，也是一个辅助分析的方式）。