社交和消息产品开发中的FinOps

云计算是惊人的。各种大小和形状的资源都可以通过几个命令提供。但是，冒着使用一个疲倦比喻的风险，伴随着巨大的权力而来的是巨大的责任，或者至少是巨大的成本。我的团队通过采用围绕四个原则阐述的FinOps原则，将云成本节省了40%，同时将我们的基础设施增加了一倍。

背景

社交和消息产品开发(SMPD)团队位于T-Mobile的联络中心组织内。
我们的应用程序是围绕越来越多的微服务组织的，运行在由Kubernetes组织的容器中，并由用于数据持久化、流管理、加密等的Amazon Web服务产品集合增强。

在SMPD中，我的团队专注于创建和维护平台、工具和护栏，允许产品团队以不断提高的速度和质量创新、中断和优化业务流。这个团队被称为工程效率团队。作为基础设施和平台的管理者，E2团队承担了引入FinOps原则的责任，作为每个SMPD产品质量标记的一部分。因此，即使我们的产品和服务组合不断增长和变化，基础设施团队仍专注于通过识别和减少浪费来最大限度地利用资源，同时保持在技术创新的前沿。
这些原则在最近一个实现多区域复原力的项目中得到了检验。稍后会有更多信息…

为了启动我们的FinOps责任，我们组织了四个重点领域：

1.提高整个组织的成本意识（并让它变得有趣！）
2.为资源创建和管理提供自动化护栏。
3.采用短暂环境原则减少浪费。
4.在设计时创建成本建模工具。

1.让成本意识变得有趣

我们FinOps旅程的第一步是向所有人提供服务的实际成本。忠于DevOps模型的精神，产品的运营责任完全由创建产品的团队承担。因此，使产品运行的成本完全透明是很重要的。T-Mobile Cloud Center of Excellence为每个使用云资源的团队提供了一份关于运行应用程序各个方面的成本的详细报告。从CPU和内存到网络连接成本，信息几乎是实时的。这一宝贵的工具往往只供主计长和管理层使用。我们决定向团队中的每个人提供这些信息。意识是确保资源合理配置的最大工具。这已经成为我们对我们的申请进行操作审查的一部分。每个月，基础设施团队都会审查CCoE提供的数据，并将其提交给不同的产品团队，并就潜在的优化机会提出建议。

为了提高产品团队的参与度，我们还从游戏化剧本中抽出了一页。我们定期创建团队之间的竞赛，以实现平台的一些广泛目标。例如，我们需要团队调整Kubernetes pods资源的配置大小。我们的目标是每个容器使用分配内存的60%作为配置基准。创建一个排行榜，显示每个团队的投资组合是如何实现这一目标的，在激发他们的竞争优势的同时，提高了意识。这是一个简单但非常有效的解决方案，以确保团队的参与。

2.资源创建和管理的屏障

在SMPD中，我们坚信应使决策过程尽可能贴近个人。但是，有一些需求比团队更大。安全标准就是一个很好的例子。为了实现对组织标准的遵守，E2团队正在设计自动化的护栏，以实现遵从性所需的模式，而不给开发人员带来额外的负担。我们的CI/CD管道是一个不断发展的产品，旨在在需要时实施标准。例如，管道在资源上强制执行命名约定和标记要求。当不可能实现自动化时，从模式的“为什么”开始的文档可供经常参考。我们亲切地将我们的文档系统命名为E2PEDIA。如果代码不符合我们的文档标准，管道将导致构建失败并阻止部署。

3.短暂的环境

随着资源创建和管理护栏的到位，我们向短暂环境迈进了一步。云的承诺之一是根据需要创建和销毁资源的能力。在设计颠覆性产品时，只需点击几下鼠标就能创建Redis集群的能力确实是一个游戏规则的改变者。然而，当摧毁Redis集群时，似乎不会产生同样程度的欢乐。这也不是在云提供商的商业模式中鼓励我们清理自己。我父母会很自豪的。我们的团队正在走向一个完全短暂的供应模型。所需的每一个云资源都由CI/CD管道根据请求创建，并按计划或单击按钮销毁。这确保了资源只在需要时才创建。这似乎是一个显而易见的实现习惯，但它确实要求我们用应用程序本身声明应用程序所需的所有基础结构。采用“基础设施即代码”的原则，并授权每个开发人员声明需要什么资源，是高效管理云资源的关键一步。

4.设计时的成本建模工具

我们的FinOps计划的下一步是在设计时提供成本建模工具。虽然我们不主张成本是唯一的甚至是主要的设计考虑因素，但提供这些决策影响的知识有助于形成更好的设计决策。该工具通过一个简短的调查对运行服务所需的基础结构的成本进行建模。例如，一个新的应用程序可能需要在35个Kubernetes pod上部署4个新的微服务。每个pod都有500分钟的CPU时间和256 MiB的内存。该应用程序还使用两个DynamoDB表和Kafka进行流。根据收集的信息，我们提供了与运行应用程序相关的成本的草图。结果可以保存起来，以便与不同的配置进行并排比较。这些信息还可以与一些更严格的性能测试结果进行比较，以验证设计假设。这一工具仍在进行中。我们从不同团队收集的反馈将使它随着时间的推移变得更加准确。数据驱动的决策可以做出更好的决策。

通过在多个云区域分发我们的服务并遵循主动/主动流量分发模式来提高应用程序的弹性。这意味着复制我们的基础设施和支持云服务。为了验证我们的FinOps原则，我们设定了一个目标，即在不增加今年云预算的情况下实现完全的地理冗余。

结论

管理与应用程序组合相关的成本很少是传统开发团队的预占工作。然而，我们相信，将整个团队的注意力集中在软件开发的财务方面，可以使我们在产品的设计、管理和维护方面做出更好、更有意识的决定。FinOps是对任何优秀的DevOps团队的一个补充过程。