说了很多理论和体系，输出了课程，今天我稍微整体回顾了全部过程后，还是有些担心，担心大家在看过了高级的体系框架，听了一些我在分享中主客观的表达，还是会回到一个出发点的三连问：“我该如何开始？怎么进行交付？怎么运营？”
回顾了下之前做的一些小而美的方案输出，还是一种思路，这比较像我的风格~因为我们需要的是思路，不是需要解决问题的人（拿来主义）。至少在这里我比较希望大家这么思考，别把自己的高度做低了，也切勿把脑子的灵活度做懒了。
大道至简，大道理总是用一两句简单的话就能说明白的，好比真传一句话，假传万卷书，这种社会现象充斥着我们日常工作生活，还有更重要的是影响我们近乎正确看待一件事物的‘出发点’。自从2022年开始，成本优化（云财务管理）等近义词就热闹了起来，好似一个可以改变世界的新文明被发现了一般，这里没有贬义的口气。而正是这般热闹的现象里，我差点被影响到。
因为总是有些自成体系的前辈、后辈在看过一点点FinOps社区内容后，开始布道，大致的几个内容方向是这样：
1、合理规划实例选择（使用竞价实例）
2、利用云平台的伸缩方式
3、动态检测与降配
4、避免不必要的浪费
。。。。
其实我稍微复盘了下个人的内容，我可能是没法写出这样的文字，因为片面的总结了一些个人所知所得，除了想表现佐证自己的能力外，更多的是对这个社区的敬畏之心不够。
我们从成本管理的视角来分析，首先第一件事情是要做什么？成本的识别，那成本的识别第一步做什么？给运行的各种云服务打上TAG以及分组
纵观各大云厂商关于云成本方面的知识体系，以AWS为表达，在成本优化的文章里，最早的cost optimization 系列文章能追溯到2013年，而这里面第一件事就是教用户合理使用TAG和COST Tools。
国内2022年以后的重视，这也是一种进步，这里引入一张图，大家看看这种体验如何？
notes：Google的在compute dashboard上，直接会体现recommendation vm size，即：这就是我在分享里提到的right resizing策略，也是6R策略中我重点分解的。不过请注意，任何一家公有云厂商都没办法在线状态下完成resizing的动作，必须reboot。
顺着聊，reboot这个动作会产生多少影响？（业务连续性治理体系里的故事）我想这可大可小，也许只有运维工作者才能理解这里面的浅深。
所以作为读者多少能感受到我对国内这种断章取义式的发声的担忧，因为我们的圈子是封闭的，搜索面也是封闭的。这种影响会直接带来一个错误的认知根。
好了，我尽量克制自己，毕竟要做一个清醒的人很难立得住人设，又或者说尝试叫醒圈子里的朋友的成本极大的。大可不必去试着去做，但是这里从学习积累的维度要分享的关键，就是要让大家理解不要关注速成、价值转述、能力bypass。这些都是一个人走向浮躁的特征，非长期主义的工作者~如果你正在靠近这个特征，如果你愿意，可以尝试调整了下。
因为有节奏的慢，就是快。有时候你习惯了快，就是慢。这不是24个月内能反思的，而是36/48个月才能感知到。
————————方案构成“骨架”
回到今天的主题，我们做云的成本优化第一步，一定要回归到本质问题——我能对哪些做优化？以一个简单的业务背景来分析和推进。从两个维度着手：理论可优化空间和实际可优化空间
1.在传统应用（三层allinone）的云部署环境里：
1.1 可研究降本空间来自于：
核心成本点位——云服务器（CPU/RAM/HDD）
配套成本点位——网络资源（IN/OUT）
1.2 实际可优化空间来自于：
配套成本点位——网络资源（IN/OUT）
2.在接近云原生部署的解耦的云部署环境里
2.1 可研究降本空间来自于：
核心成本点位——云服务器（CPU/RAM/HDD）
付款方式点位——按量/包月
配套成本点位——网络资源（IN/OUT）
配套成本点位——其他paas服务
2.2 实际可优化空间来自于：
核心成本点位——云服务器（CPU/RAM/HDD）
付款方式点位——按量/包月
为什么会有这样的结论，我道明下原因。在成本优化项目里，必须要面对三个大问题。
第一个大问题：预算成本的年评估（一次性年初预算投入评估）
问题1：一次性评估，后半年增长，预算超，有背书风险
问题2：合同新增或修改，也是企业技术部门比较想避开的点（除非一开始签框架，但也是接近总包做法）
第二个大问题：预算过半的变动难
问题1：对于技术部门评估技术，这不难。但退费和按量产生的预测出现变动，无科学合理的纸质背书，换句话说：“优化的结果，从内部来讲无人保证”
问题2：技术团队无责任关联成本使用，陷入降本就是’找事‘的责任旋涡。
第三个大问题：业务影响范围面广
问题1：从外部的服务团队能保证，但务必会涉及我说的reboot，时间可能就变相拉长了交付期。几乎等同于迁移后的报障问题。（大家或多都了解，资源缩减对应用资源占用会造成一些影响）
那对于FinOps这件事情来讲，它核心的价值依赖高度开放的工作文化来讲的，是有价值。但水土不服的原因，也许就是以上我提到的这几点，所以要想做，就得从最开始做，或者途中小范围试点做。这样避雷的效果会更好。
切记太关注如何’炫技‘，这是不负责任的（不看业务）典型特征。至少在很多互联网的团队里，这些炫技就是’笨蛋‘的行为，职业生涯经常做过山车，没办法做到削峰、平谷。如果避雷，就是用大道至简的一句话解释：“明白了压力在哪，你就知道如何投入资源”。做MSP公司，知道89101112自然月份项目多，招人也大都是在这些日子。那从人力的维度是不是尽可能的在降低人力的闲置率。
类比到云服务的投入上来说，我知道了压力在哪里？我改在哪个地点（时间）放大负载（扩容）是不是也很清晰了？没错，就是这样。压力在哪，扩缩容就在哪！
聊个具体的工作例子，容器集群的用例，背景情况~
- 生产环境是100%跑在公有云上
- 业务遍布世界各地，在新加坡、印度、拉美和国内。且国内多个集群跑在不同的云厂商上，这就决定了我们的所有方案都必须是通用的
- 流量比较规律，高峰低谷也比较明显（流量特征决定预测的预测效果）
优化对象定义：
- 云服务器采购成本优化
- 提供清单
- 服务器利用率优化
- 提供performance
优化手段界定：
- 容器集群技术（HPA、request/limit）
- 分析已有yaml的request/limit的设定根据，运行日志
- 合理性分析
- 产品购买方式
- 提供预算分摊模型（总预算/12）
- 提供支付方式和支付记录
怎么干？
- 基于流量特点，采用二八原则。20%固定采购（包年包月）80%动态采购（payasyougo），匹配的采购策略——saving plan（节省计划）+竞价实例
- 成果：follow traffic feature 解决 over provision 静态规划
- 基于HPA集群特征，参考业务架构无损的设计，划定特征①的扩缩容时间窗口
- 成果：使用limit/request控制20%负载和80% 动态调度
- 成果：不断基于历史数据，计算出业务的最优匹配规则（算法）
注意事项：
- 动态调度背后的资源，全使用竞价（需要关注随时中断实例的风险）
- 调整策略resizing，就是关心成本大头（云服务器，同样担心和上面一样）
这时，大家可能会问，老师你不是说要先识别成本嘛，为什么直接开干了？其实不然，这类场景就是我们直接上项目的处境。如果按照阶段来说明STAGE 1（past） ———STAGE 2 （in process）———STAGE 3（feature）。
我们一般都在STAGE 2（in process） 状态，因为客户找到你的时候，多数情况是在STAGE2的“运行状态”中。所以识别的空间肯定是有的，但不一定够。在此用例中就是这样~客户已经基本确认了几个方向的事情，我们直接进入主题并展开细节讨论即可。
即核心放方案思维就是上面这部分的描述，不多。但就是成本优化的第一件事情，但这是在全面理解了FINOPS的工作框架后，直接有思路的进入状态——直接开场行为。这是成熟度把握的问题，而不是跳跃成熟的学习，直接照搬看似成熟较高的“招数”来侃侃而谈。
算是一气呵成，中间接了个电话，确实有些情绪在里面，请大家客观阅读理解（吐槽）
