主动进行多云成本管理的关键

塞巴斯蒂安Stadil是CEO和创始人Scalr 。

企业正在大量迁移到多云。 为什么？ 云采用者最常提及的关键驱动因素是速度，敏捷性，平台灵活性和降低的成本，或者至少是更具可预测性的成本。 具有讽刺意味的是，这些公司中有超过一半的人说，云计算成本失控是他们最大的迁移后痛点。

我们如何控制云预算？ 首先，我们需要了解我们正在使用什么。 但是，当多个团队使用多个帐户累积成本，并涉及多个云平台上多个地理位置的多个产品时，获得清晰的画面几乎是不可能的任务。 因此，基础架构和运营团队经常求助于云和成本管理解决方案以获得更好的可视性。

[入门： Azure云迁移指南 。 •教程： Google Cloud入门 。 | 通过InfoWorld的云计算新闻通讯了解云计算的最新发展。 ]

资源标记：答案不完整

团队和成本管理解决方案试图提高可见性的一种常见方法是使用标签。 标记本质上是为基础结构（服务器，数据库，存储卷等）分配名称的过程，有时还为应用程序或项目分配名称。 标签可能包含有用的信息，例如地理区域，部门，环境，服务器的目的，甚至是提供服务器的人员的姓名。 例如，我可能会在AWS的北弗吉尼亚地区配置一个数据库，并像这样标记它：

evan-mysql-us-east-1

标记有助于提高实例在何处以及如何分配预算的可见性。 标签可以增强团队从其云提供商那里获取的数据。 IT团队实施标记的最常见原因之一是防止影子IT产生的成本失控。 团队为标签创建最佳实践和准则，以包含跟踪环境中发生的一切所需的数据。

但是这种方法存在一个固有的问题：它忽略了影子IT最初开始的原因，这是为了避免IT制定的流程。 仅当IT部门可以确保每个标签正确且100％遵循准则时，标签才能成功。 随着团队跨越不同的位置并为多个私有和公共云平台提供资源，这种情况很快就变得不可能了。

这是一个例子。 在三个不同的团队中，AWS的北弗吉尼亚地区配置的三个几乎完全相同的数据库可能遵循IT准则，但最终的名称却大不相同：

evan-mysql-us-east-1
jose:database:east
rhdbva

而且，标签从本质上将基础架构和策略联系在一起，这是一个大问题。 在企业或使用大量云基础架构的任何公司中，资源始终处于不断变化的状态，并始终在改变用途。 当团队随着时间变化，变化或合并时，他们的资源也会发挥作用。 两个团队可能具有不同的标记策略，并且当它们合并或资源四处移动时，标记约定通常会被破坏。 在第一个数据库示例中，标记可能如下所示：

evan-mysql-us-east-1
evan:mysql:east:1
Evan-mysql-eats-1 （一个单词拼写错误时，您的标记策略会怎样？）
evSQLeast

中央IT部门只需拥有所有配置和标签，并确保遵循策略，就可以解决很多问题。 但这会减慢一切。 同样，这通常是首先导致影子IT的原因。

逻辑分组：部分解决方案

标记从未被用于像成本管理这样重要和细化的事物。 无论如何，监视每个应用程序或服务器的成本通常没有多大意义。 相反，企业可能会考虑如何在逻辑上将应用程序或预配置的基础架构分组为“项目”甚至团队。 然后，可以为项目和团队分配预算，从而使成本分配和报告变得更加简单，并且消除了对标签的依赖。 在云中进行配置的开发人员可以将其应用程序与他们所属的项目或与其报告的成本中心相关联。

但这只是该问题的部分解决方案。 即使团队可以验证标记的完美准确性，或者可以转移到基于项目的成本模型，但对云成本的可视性只是第一步； 这是一种成本管理的被动方法，不能完全解决问题。

考虑一下您注意到EC2实例超出其预算的时间。 您已经有了完美的标签，告诉您Jose正在使用该实例在北弗吉尼亚州或东海岸地区托管MySQL数据库。 怎么办？ 这里的问题是我们所说的无上下文可见性：您不知道关闭该计算机的后果。 您必须手动与Jose联系（假设您知道是谁），以找到继续进行的方法。

此外，您可能没有一直在监视该机器，并且仅在报告的任何时间表（周，月，季度）结束时才发现成本超支。 到那时，您可能已经晚了30或90天。 您可能对解决这种情况反应迟钝，但是那笔钱已经花掉了，您能做的最好的就是尝试更加努力地进行监控。 现在冲洗并重复一次，并为下一个预算不足做好准备。

主动的多云成本管理

主动的成本控制措施将始终在管理云预算方面更加有效。 不幸的是，目前没有什么解决方案可以帮助团队做到这一点。 我要说的最佳实践是在项目和团队级别设置预算策略，并通过自动化工具实施这些策略。 这样，可以将应用程序分组为与团队或业务部门预算相关的项目。 IT和财务部门可以为业务部门设置成本控制； 业务部门或单个团队可以设置项目预算。 这些策略可以充当护栏，确保应用程序和项目不会超出预期的预算，同时仍使团队可以通过自动自我配置等方法自由地提高工作效率。

有了这些实践，即使是在被动方面，IT和财务团队也将更深入地了解成本的来源。 他们可以灵活分配和重新分配预算，并且可以适应变化而不会丢失上下文。 此外，您将需要使用功能强大的分析引擎，该引擎可以查看应用程序和使用趋势，并为团队提出建议，以预先改善成本。 例如，成本分析可能会建议使用保留的实例，以节省大量成本，并建议合理调整工作负载，团队可以自动允许或手动批准。

通过启用主动的成本控制系统和更强大的上下文成本分析机制，可以使失控的云成本成为历史。 速度，敏捷性，灵活性和成本效益–这是多云的圣杯，也是未来。

Sebastian Stadil是Scalr的首席执行官和创始人， Scalr是NASA，Expedia，Samsung等众多公司所依赖的多云管理平台。 Stadil还是硅谷第二大用户群体SVCCG的创始人，以及卡内基·梅隆大学（Carnegie Mellon）关于企业家精神的客座讲师。 他是Google和Microsoft的云顾问委员会成员。 自2004年以来，他一直在开发利用AWS和其他云提供商的产品和服务。

-

新技术论坛提供了一个以前所未有的深度和广度探索和讨论新兴企业技术的场所。 选择是主观的，是基于我们对InfoWorld读者认为最重要和最感兴趣的技术的选择。 InfoWorld不接受发布的营销担保，并保留编辑所有贡献内容的权利。 将所有查询发送到 newtechforum@infoworld.com 。

From: https://www.infoworld.com/article/3289144/the-key-to-proactive-multicloud-cost-management.html