最近，在工作中听到一些同事反馈的一个困惑：FinOps和稳定性保障的关系是否水火不容？

先说说这个问题产生的背景，最近公司在举办一次业务活动时，流量出奇不意地创下了历史新高。很不幸，在活动开始前的系统扩容因种种原因没有及时完成，为避免系统被流量打垮而启用了限流，导致用户活动体验不太好。因此在后续活动中，几乎对所有组件都进行了扩容。而这种不考虑成本的做法，是对这大半年“降低公有云成本”的做法是一个大转向。

回到问题，首先我觉得在“解题思维”上不能掉进“陷阱”。这问题的提问方式是封闭式，采用了“是否”。但这个问题是复杂的，并不是简单地非黑即白、二选一。所以，若真要有一个回答。答案必定是：不是！

为什么说FinOps和稳定性保障的关系不会是水火不容。

原因一：FinOps和稳定性保障的终极目标是一致的！

FinOps的目标是为让组织的业务价值最大化。稳定性保障的目标是通过确保业务系统可靠可用而支持业务运营，进而实现组织业务价值。

用大白话来说，FinOps就是让公有云资源利用率最大化，节省公有云成本进而让公司能赚钱。稳定性保障是确保系统可用进而让业务不中断而让公司赚钱。它俩只是实现同一目标的不同手段而已，那俩者之间就绝不可能会是水火不容。

原因二：FinOps和稳定性保障不会相互冲突矛盾或只能二选一，而是可以1+1>2!

先举例说明下FinOps和稳定性保障最让人误解为相互冲突矛盾的原因。如：FinOps日常工作中做得最多的是查看成本报表、通过资源使用监控工具等，驱动负责人对资源做降配、回收或整合。而稳定性保障在无法准确预估业务流量情况下，通常会预留较多的冗余资源，就是扩容、扩容、扩容。因此很容易造成了两者是冲突茅盾的错觉。

那为什么说两者并不冲突而是可以1+1>2 ？

在一家公司的工作实践中，会因应业务情况，如调整了活动促销模式、外部环境变化等，会让每次业务活动的流量不会是恒定不变的，也就意味对系统容量也就是稳定性保障的要求也不会是恒定不变的。应对这种不确定性，也正是稳定性保障的非常重要能力。而这种能力的基础其实是建立在公有云的在线弹性伸缩和即开即用特性之上，当业务流量评估和在线弹性伸缩这两个稳定性保障能力的准确性和时效性均达到较高水平后，自然而然就实现了1+1>2.

原因三：从实际工作中，若时间维度去看和从利益相关人的要求维度去看，短期内是会有策略的主次先后之分，但长期看必然是两者结合才是效益最大化

当业务带来的流量会有不确定性时，也意味着系统不可能100%不出问题。一但出现问题，业务方就会施加压力和提高要求。此时，扩容应该是绝大部分情况下最有效的手段了。这时，策略就是稳定性优先，要确保系统可靠可用。反之，就是FinOps优先，减少成本浪费。所以在一个较短时间周期内，会有策略的优先主次之分。但拉长时间周期来看，必然是两者结合方是效益最大化。

最后，从团队能力建设管理维度，应该关注产生这些疑惑的同事，洞察令他们产生困惑的背后原因。“解决不了问题，但解决提出问题的人的背后困惑”，可能才是正确的做法。或许是领导要求的来回摇摆、或许是他们执行时需要大量手工操作，所以引起了员工们的不爽。但需要让团队认知到，高水平的稳定性保障能力必然能自如应对这种不确定性。这并不是管理策略的来回摇摆，而是能力建设还要再上一个水平，方才能彻底摆脱这种困惑。