Azure Well-Architected Framework 是一个设计框架，可通过帮助工作负载执行以下操作来提高工作负载的质量：
- 具有弹性、可用性和可恢复性。
- 尽可能安全。
- 提供足够的投资回报。
- 支持负责任的开发和运营。
- 在可接受的时间范围内完成其目的。
架构设计始终由业务目标驱动，必须考虑投资回报率 （ROI） 和财务限制。要考虑的典型问题包含：
- 分配的预算是否能够让您实现目标？
- 应用程序及其操作的支出模式是什么？什么是优先领域？
- 您将如何通过提高利用率或减少资源来最大化资源投资？
本模块中描述的概念并不包括工作负载中的成本优化，但它们代表了设计工作负载时的核心原则和一些关键方法。若要全面了解所有架构良好的框架支柱，请在开始规划和设计体系结构时访问 Azure 架构良好的框架。
本模块中的每个单元都侧重于一个设计原则以及与该原则相关的三种方法。每个单元中的方法都通过使用示例来支持，以帮助演示如何将它们应用于实际场景。这些例子都是基于一家虚构的公司。
学习目标
在本模块结束时，您将了解成本优化支柱的五项原则，并了解以下每种方法的三种方法：
- 建立了解预算、费用、报告和成本跟踪的团队文化
- 只花钱，实现最高投资回报
- 最大限度地利用资源和运营
- 在不重新设计、重新协商或牺牲需求的情况下提高效率
- 随着工作负载的发展，不断调整投资规模
先决条件
- 使用数据存储、计算和网络等核心基础设施技术构建或运营解决方案的经验
- 具有构建或操作系统以解决业务问题的经验
制定成本管理规则
建立一种具有预算、费用、报告和成本跟踪意识的团队文化。
成本优化在组织的各个层面进行。了解您的工作负载如何与组织目标和 FinOps 实践保持一致非常重要。 通过了解业务部门、资源组织和集中审计策略，您可以将标准化的财务系统和方法应用于您的工作负载。
示例场景
Contoso 组织并主办贸易展览。 Contoso 看到了通过内部开发移动应用程序来提高贸易展览门票销售流程效率的机会。 以下场景遵循从构思到实施的开发过程，重点关注成本优化问题。 该移动应用程序是用 .NET 编写的 Web 应用程序，托管在 Azure 应用服务基础结构上，并使用 Azure SQL 数据库作为其数据库。
开发成本模型
开发成本模型。 这项基本工作是建立财务跟踪系统的先决条件。
成本模型有助于细分费用并估计和预测总拥有成本，包括基础设施、支持和实施。 它使您能够及早识别成本驱动因素，并预测使用量增长或减少将如何影响工作负载的预计业务模型中的总体收入和支出。
Contoso 的挑战
- 进入构思阶段，工作负载团队无法预测提供此类体验的总拥有成本是多少，特别是当票务系统通常处理突发需求时。 他们知道他们希望从小处开始并随着时间的推移而增长，但他们不知道如何对此进行建模以预测构建和维护工作负载的增量方法的成本。
- 如果没有这些初步估计，将很难为项目获得初始资金并预测长期资金需求。
应用方法和结果
- 工作负载团队花费一些时间对各种场景中的估计成本进行建模：他们知道构建工作负载所需的资源类型，并查看可以支持不同负载模式的不同配置，以了解其 Azure 成本最初可能是什么样子 随着时间的推移。
- 他们使用粗略估计的基础设施成本，结合对团队支出和产品收入的估计来构建成本模型。
- 然后，该模型允许他们开始预测成本，并了解成本如何随着使用量的增加而增加。 他们知道，随着架构和运营决策的确定，他们可以改进模型以提高其预测能力。
估计实际预算
估算涵盖所有不可协商的功能和非功能需求、人员和培训成本以及提供预期增长的流程的实际预算。
您将能够设定财务界限并建立方法来根据分配的预算检查您的支出。 当超过某些阈值时，您还会收到通知，这可以防止租户范围、资源范围和应用于预算的其他范围出现超支。
Contoso 的挑战
- 在此场景中，应用程序处于设计阶段，初始资源 SKU 已确定。
- Contoso 需要为移动票务工作负载分配资金。
- 不能允许工作负载以空白支票运行。 需要为工作量确定切合实际的预算，因为预分配不足可能会危及工作量时间表和成功，而过度分配可能会导致不必要的前期支出，与短期工作量需求不符。
应用方法和结果
- 随着成本模型通过更精确的数字得到完善，团队为利益相关者提供了一个经过高度置信度估计且可以维护的预算。
- 预算到位后，工作负载架构师就可以开始针对财务限制进行设计。随着对实施和必要操作的了解越来越多，工作负载团队预计需要重新进行一些协商。
- 他们想要一个小的缓冲，但最终将通过遵守预算分配来推动财政责任。
鼓励上游沟通
鼓励从架构师到应用程序所有者的上游沟通。
当您根据反馈采取行动时，成本就会降低，反馈应该被视为与数字数据一样有意义。 您将利用员工的意见来推动现实的设计变更和业务战略，从而为他们提供支持。
Contoso 的挑战
- Contoso 的移动票务工作负载已成功实施并投入生产。
- 在分析一段时间内的使用模式后，工作负载团队成员发现实施并没有真正针对成本效率进行优化。
- 由于项目管理和财务人员似乎对迄今为止工作负载的成功感到满意，因此他们不知道是否应该说些什么。
应用方法和结果
- 鼓励工作负载团队“像对待自己的一样使用它”，因此当他们看到当前设计的替代方法可以在不牺牲安全性、可靠性或性能的情况下满足应用程序的功能需求时，他们有权向产品管理层提出意见， 但以更具成本效益的方式。
- 因此，工作负载团队将他们的发现提供给利益相关者，并讨论设计变更的利弊。
- 设计变更得到批准并实现了成本节约。
以成本效益的心态进行设计
只花您需要的钱来实现最高的投资回报。
每个架构决策都会产生直接和间接的财务影响。 了解与构建与购买选项、技术选择、计费模型和许可、培训、运营等相关的成本。
给定一组要求，优化并做出与成本相关的权衡决策，这仍然有效地解决工作负载的跨领域问题。
示例场景
Contoso Manufacturing (CM) 运行定制的仓库管理系统 (WMS) 来处理其位于南美洲的四个仓库，他们决定是时候更新该解决方案并将其迁移到云中。 他们正在考虑对当前解决方案进行直接迁移，或者使用现代云工具进行全新构建。 CM 的高级领导层希望控制成本，并询问工作负载团队的领导者如何以保持成本效率为目标进行迁移。
WMS 解决方案是一个在 IIS 上运行的 .NET 应用程序，并使用 SQL Server 作为其数据库。
衡量工作负载设计的总成本
衡量技术和自动化选择产生的总成本，同时考虑对投资回报 (ROI) 的影响。 设计必须在所有功能和非功能要求的可接受范围内工作。 设计还必须灵活以适应预测的演变。 考虑采购、培训和变革管理的成本。
实施考虑投资回报率的平衡方法可以防止过度设计，过度设计可能会增加成本。
Contoso 的挑战
- 工作负载工程团队很高兴能够将此工作负载转移到云中，加入其他已经进行云原生开发的 CM 团队。
- 他们意识到应用程序中的技术债务，并希望通过重写大量应用程序代码并为许多组件迁移到新的云原生解决方案来解决它。
- 工程团队希望借此机会将系统完全重新设计为微服务，并将其托管在 AKS 上，这对团队来说是一项新的但令人兴奋的技术。
应用方法和结果
- 虽然工作负载团队明确希望在云迁移过程中进行大规模重构，但他们意识到工作负载需要保持其投资回报率。 保持工作负载的投资回报率可能会让团队转向使用不需要大量新工程团队培训的解决方案，并且他们将无法在迁移过程中对工作负载进行大量重写。
- 工作负载团队采用务实的方法来设计系统，确保其保持成本效益，并在预期参数内工作，并且不会过度设计。 为了确保维持投资回报率并高效执行迁移，他们认为最好的方法是采用云中的同类解决方案，例如 Azure 应用服务。
- 在迁移过程中，他们将有选择地解决一些技术债务，使他们能够在平台进入Azure后进一步发展该平台，并将考虑投资回报率作为选择过程的一部分。
完善设计
通过优先考虑可以降低总体成本、不需要额外投资或不会对功能产生重大影响的服务来微调设计。 优先级应考虑带来高投资回报率的业务模式和技术选择。
您将能够探索更便宜的选项，这些选项可能会实现资源灵活性或动态扩展，或者您可能会证明使用现有投资的合理性。 优先级参数可能会考虑关键工作负载、运行时和操作所需的成本，以及可能帮助团队更有效地工作的其他成本。
Contoso 的挑战
- 现有工作负载托管在超融合 (HCI) 设备上，团队的成本中心将收取计算、网络和存储成本。
- 该工作负载已在 Windows 虚拟机上部署预生产和生产环境。
- 具有自托管运行器的 GitHub Actions 用于执行 GitHub Actions 作业。
应用方法和结果
- 在评估了多个云原生选项后，团队决定将 Web 组件迁移到 Azure 应用服务将提供 Windows IIS 应用程序兼容性，而无需进行重大更改，并且不需要大量培训。
- 该团队决定继续将 GitHub Actions 与自托管运行器结合使用，但它们将迁移到虚拟机规模集，并且能够在不使用时扩展到零节点。
设计您的架构以支持成本护栏
通过平台解决方案、策略、基础设施和应用程序设计模式或自动化实施成本护栏，以帮助确保您的云环境成本保持在预算范围内。
通过治理策略或内置应用程序设计模式执行可以防止意外或未经批准的收费。
Contoso 的挑战
- 现有的系统没有成本护栏，而且很少改变，因此没有什么动力去建立这样的护栏。
- HCI 环境的所有者设置了适用于该工作负载的资源限制，有效地阻止该工作负载消耗过多的计算和存储资源。
- 该团队担心迁移到云会带来产生意外成本的风险，并且不确定如何最大限度地降低该风险。
应用方法和结果
- 该团队自行学习 Microsoft 成本管理解决方案。
- 该团队计划为 Azure 应用服务计划设置规模限制。
- 该团队计划为某些价格较高的虚拟机 SKU 设置拒绝策略，以禁止部署这些 SKU。
- 该团队计划实施自动化来帮助控制存储成本。某些数据类型将根据上次访问日期等标准自动从热存储移动到冷存储或归档存储。这种类型的自动化在 HCI 环境中是不可能的。
使用优化设计
最大限度地利用资源和运营。 将它们应用于解决方案协商的功能和非功能需求。
服务和产品提供各种功能和定价等级。 购买一组功能后，请避免未充分利用它们。 寻找最大化您在该层的投资的方法。 同样，根据当前的生产工作负载，不断评估计费模型，找到更适合您的使用情况的计费模型。
示例场景
Contoso 大学目前正在托管一个商业现成 (COTS) 解决方案，允许大学教师创建和更新本学年的课程，并且是学生使用这些课程的主要注册门户。 该解决方案与软件即服务 (SaaS) 教育管理系统进行定制集成，他们希望最终在几年内将所有功能迁移到该系统。 与此同时，他们希望优化定制集成组件的成本。
COTS 产品的技术解决方案通常被视为黑匣子，但其数据库是 Azure Database for MySQL。 自定义集成是一个 Azure 持久功能，它在 Azure 应用服务中的标准服务计划上呈扇形运行。 此应用程序服务以前托管过一个大学网站，但现在情况已不再如此。 这个持久功能是一个由专用 Azure 存储帐户支持的 Python 应用程序，该帐户每晚执行从 MySQL 数据库到 SaaS 的 API 的同步。
在可行的情况下使用基于消费的定价
可能有一些服务提供基于消耗的定价，这意味着您只需为服务的使用付费，并且您可以在不需要时关闭该服务以停止产生费用。 如果您的工作负载组件只是偶尔使用，那么与为组件付费以使其 24/7/365 运行相比，这可以帮助最大限度地减少浪费的成本。
通过使用基于消费的定价，您只需为实际使用的量付费。 当您预计不会full time使用工作负载计算时，此选项是一个不错的选择。
Contoso 的挑战
- 同步作业通常每晚在特定时间运行大约一个小时。 其历史表现一直令人满意。 故障很少见，并且在当前配置中可以很好地处理瞬态故障。
- 由于同步作业所需的计算每天仅使用大约一小时，而且无论使用情况如何，他们都会按 24 小时付费，因此工作负载团队对当前设计的替代方案很感兴趣。
- 该团队曾考虑编写一个脚本，每天晚上在同步运行后关闭服务，并在第二天重新部署它，但这种解决方案会带来很高的风险和复杂性。
应用方法和结果
- 团队分析了作业历史记录，发现该函数运行的最长时间不到两个小时。 他们将专用计划的成本与最坏情况下的 Azure Functions 消耗计划的成本进行比较，并得出结论认为消耗计划会更便宜。
- 团队进行了性能测试以确保性能足够，他们注意到运行时间略有增加，但仍在可接受的范围内。
- 通过使用消耗计划可以降低工作负载的总体成本，因为它们仅在作业执行时产生成本。
优化您的高可用性设计
如果您已支付资源费用，则作为恢复计划的一部分，优先部署主动-主动或仅主动模型，而不是主动-被动模型。
如果您的设计默认使用主动-被动模型，则您可能拥有本来可以使用的闲置资源。 转换为主动-主动可能使您能够满足负载均衡和规模爆发要求，而不会超支。 如果您可以使用仅主动模型来满足恢复目标，则可以完全消除这些资源的成本。
Contoso 的挑战
- COTS 应用程序使用配置为同区域高可用性的 Azure Database for MySQL 灵活服务器，它在与主服务器相同的可用区域中提供备用服务器。 他们还启用了自动备份。
- 该工作负载的 RPO 相对较长，为 12 小时，而 RTO 在上课期间为 3 小时。
- 根据之前的恢复测试，团队知道他们可以通过自动故障转移到备用服务器来满足 RPO 和 RTO 目标。 他们还测试了从备份恢复数据库，并且可以满足此场景中的目标。
应用方法和结果
- 工作负载团队重新评估高可用性设计的优势与两倍于单个实例的服务成本。
- 该团队测试了构建新实例并从备份恢复数据库，他们对仍符合恢复目标感到满意，因此决定消除备用实例。
- 团队更新了灾难恢复计划以反映新的恢复策略，并通过新配置实现成本节约。
保持您的云环境中没有未使用的资源和数据
定期严格审查未使用的资源和数据的部署并停用它们。 随着时间的推移，过去出于某种目的所需但不再使用的资源和数据可能会残留在您的云环境中，并产生不必要的成本。 请保持环境清洁，以帮助优化成本效率。
关闭未使用的资源并在不再需要时删除数据可以减少浪费并释放资金，以便您可以将它们投资到其他地方。
Contoso 的挑战
- 该大学历来对退役解决方案采取保守方法，担心它们可能需要恢复到之前的配置。 这种谨慎态度导致放弃在一个或多个环境中运行数月的服务，在某些情况下这些服务已经被遗忘。
- 当发现废弃服务时，通常是偶然的，因为没有正式的流程来审查此类服务的环境。
应用方法和结果
- 该团队将应用服务的停用添加到待办事项中，作为从应用服务迁移到耐用功能的消费托管的一部分。 作为下一个冲刺的一部分，他们将关闭所有环境中的应用服务部署。
- 为了帮助主动检测废弃的资源，团队在 Azure Advisor 中设置警报以通知他们未使用的资源。
- 团队实施了一项新政策，要求团队每月对预生产环境进行全面审查，每季度对生产环境进行全面审查，以识别废弃的资源。 找到的任何废弃资源都将添加到积压工作中以进行退役。
速率优化设计
无需重新设计、重新协商或牺牲功能或非功能需求即可提高效率。
利用机会优化现有资源和运营的效用和成本。 如果不这样做，您就会不必要地花钱，而不会增加任何投资回报率。
示例场景
Contoso 的商业智能 (BI) 团队为各个业务部门托管一套 GraphQL API，以便在不授予直接数据库访问权限的情况下访问整个组织的数据存储。 他们多年来一直在构建这些 API，并发现版本控制很重要，因此他们现在通过单个消费层 API 管理网关上的版本化端点公开其 API。
API 管理实例背后是三个 AKS 集群，它们托管公开的 API。 其中一个运行 Windows 节点池，用于使用 .NET 4.5 编写的 API，一个 Linux 集群，用于使用 Java Spring 编写的 API，还有一个是从运行 dotnet core API 的先前团队继承的 Linux。 这些集群现在全部归 BI 团队所有，并且仅用于这些 API。 虽然管理三个集群并不理想，但它们一直在按预期工作，因此不会受到影响。
作为企业的成本中心，BI 团队正在寻找优化其费率的方法，以降低运营成本。
在可行的情况下整合基础设施
与其他资源、工作负载甚至团队共置使用。优先选择能够更轻松地实现更高密度的服务。考虑潜在的权衡，尤其是在安全边界方面。
整合您的基础设施将帮助您优化云成本。随着密度的增加，运行工作负载所需的资源量会减少。 这种降低降低了单位成本和管理成本。
Contoso 的挑战
- 工作负载团队根据 Microsoft 基准架构指南设计了 AKS 基础架构，该指南建议每个集群至少运行三个节点。 这种配置使团队能够支持三个集群中的九个系统节点。
- 该团队每月对集群应用三次补丁和更新。
应用方法和结果
- 经过测试，团队决定可以将所有 API 组合到具有三个用户节点池的单个集群中，同时实现与原始集群相同的性能和操作系统特征。
- 将 API 整合到一个集群后，系统节点池整合到四个节点，从而节省了五个虚拟机的成本。
- 该团队现在还可以简化集群上的修补和升级流程，因为他们只需管理一个集群。
- 他们的下一个成本节约目标是评估将两个 Linux 节点池合并为一个，以进一步减少运营开销。
利用预订和其他基础设施折扣
通过承诺和预购买进行优化，以利用针对预计不会随时间变化且成本和利用率可预测的资源类型提供的折扣。此外，与您的许可团队合作影响未来的购买协议计划和续订。
Microsoft 为特定资源和资源类别的可预测和长期承诺提供折扣费率。 资源在使用期间的成本较低，并且可以在使用期间摊销。
通过让您的许可团队了解当前和预测的资源投资，您可以在您的组织签署协议时帮助他们调整承诺规模。 在某些情况下，这些预测和承诺可能会影响您组织的价格表，这有利于您的工作负载成本以及使用相同技术的其他团队。
Contoso 的挑战
- 现在，该团队已经整合到一个集群上，消除了他们之前承担的一些多余的计算和操作负担，他们有兴趣寻找其他措施来降低集群的成本。
- 由于 BI 团队对 AKS 平台感到满意，他们计划在可预见的未来继续使用它，甚至可能会增加其使用量。
应用方法和结果
- 由于 AKS 构建在虚拟机规模集之上，因此团队研究了 Azure 预留。 他们知道用户节点所需的预期 SKU 和规模单位。
- 他们购买三年期预留，涵盖系统节点池和每个用户节点池的最小节点实例数。
- 通过这次购买，团队知道他们在满足计算需求的同时允许工作负载随着时间的推移而增长。
可行时使用固定价格计费
当资源的利用率较高且可预测并且有类似的 SKU 或计费选项可用时，请切换到固定价格计费，而不是基于消耗的资源计费。
当利用率较高且可预测时，固定价格模型通常成本较低，并且通常支持更多功能。使用它可以提高您的投资回报率。
Contoso 的挑战
- 目前，API 管理实例均部署为消费层 SKU。在评估 API 的使用模式后，他们了解到这些 API 在全球范围内使用，有时甚至使用量很大。 团队决定分析当前计费模型和固定价格模型之间的成本差异。
应用方法和结果
- 执行成本分析后，团队发现，考虑到当前的使用模式，从Consumption迁移到Standard tier的总体成本会稍微便宜一些。 随着明年服务的增长，成本差异可能会变得更加明显。 尽管固定定价模型不能反映请求的弹性特征，但有时预购计费模型是正确的选择。
- 作为额外的好处，使用Standard tier允许使用Private Endpoint进行入站连接，团队一直渴望为工作负载实现这一点。
- 在这种情况下，切换 SKU 对于使用目的和通过私有端点实施可能实现的额外网络分段的额外好处都是有意义的。
随着时间的推移进行监控和优化
随着您的工作负载随着生态系统的发展而不断调整投资规模。
昨天重要的事情今天可能不重要。 当您通过生产工作负载评估进行学习时，预计架构、业务需求、流程甚至团队结构都会发生变化。 您的软件开发生命周期 (SDLC) 实践可能需要发展。 外部因素也可能会发生变化，例如云平台、其资源和您的协议。
您应该仔细评估所有变更对成本的影响。 定期监控变化和投资回报率趋势，并评估是否需要调整功能和非功能需求。
示例场景
Contoso Air 为航空公司提供行李跟踪解决方案。 该工作负载托管在 Azure 中，在 AKS 上运行，数据库为 Cosmos DB，并使用Event Hubs进行消息传递。 工作负载部署在美西和美东地区。
持续评估和优化您的环境和支持成本
通过使用成本跟踪系统，持续评估和优化资源、数据和付费支持的成本。 是否存在可以退役、替换、重建或重构的未充分利用的资源？
您可以通过避免为未充分利用的资源付费来降低成本。 了解定价指标可以帮助您做出更符合您的成本模型的决策。 它还可以防止不必要的计费。调整大小或删除未充分利用的资源，甚至更改 SKU，都可以降低成本。
您还可以通过评估与技术供应商的支持合同的使用情况并调整其规模来节省一些成本。
Contoso 的挑战
- 工作负载团队的预算始终低于预算，因此成本效率的优化并不是优先考虑的事项。
- 他们计划明年提高工作负载的可靠性，并且知道这样做会增加他们的 Azure 成本，可能会使工作负载超出预算。 他们正在考虑要求增加明年的预算。
应用方法和结果
- 该团队决定，在要求更多资金之前，他们将评估当前的 Azure 和支持成本，以寻找潜在的节省机会。 他们调查现有成本跟踪系统中按资源、按资源组和按标签的成本细分，并注意到一些预期外的支出。
- 该团队发现，他们的环境中运行着一些虚拟机，这些虚拟机用于已弃用的构建系统，并且不再需要，Azure 存储中有大量旧数据可以移动到更便宜的层，并且他们正在付费与云提供商签订支持合同，其中包括他们未使用的咨询时间。
- 该团队通过删除未使用的虚拟机并将旧数据移至存档存储来优化 Azure 成本。 他们开始与云提供商更密切地合作，以充分利用他们的咨询服务。
- 该团队在backlog中添加了一项重复任务，以评估未来的工作负载成本。
不断审查和完善您的工作量
根据 ROI 数据不断调整架构设计决策、资源、代码和工作流程。
定期审查指标、性能数据、计费报告和功能使用情况可能会导致微调，从而降低成本。
Contoso 的挑战
- 由于该团队历来一直保持在预算范围内，因此他们没有考虑现有功能的替代方法。 相反，他们的大部分规划都集中在构建新功能上。
- 通过初步评估发现浪费后，他们决定查看当前组件的其余部分以寻找优化机会。
应用方法和结果
- 团队发现他们分配的资源多于低优先级流所需的资源，并且可以安全地缩减分配的吞吐量，同时保持其性能要求。 具体来说，他们可以摆脱过度配置来处理峰值负载，而是实施基于队列的负载均衡系统。
- 他们还发现，他们的计算平台上选定的 SKU 中添加了一项新功能，取代了一些身份验证代码。 使用此功能将意味着需要维护和测试的代码更少。
优化您的部署环境
对不同的SDLC环境进行区别对待，并部署适当数量的环境。生产环境应该是您的主要成本驱动因素。
您可以通过了解并非所有环境都需要模拟生产来节省资金。 非生产环境可以具有不同的功能、SKU、实例计数，甚至日志记录。
您还可以通过按需创建预生产环境并在不再需要时将其删除来节省成本。
Contoso 的挑战
- 工作负载团队在预生产环境上的花费比在生产环境上的花费更多。 虽然这对于某些场景可能很重要，但对于这种工作负载来说似乎太过分了。
- 预生产环境的构建与生产环境非常匹配。 工作负载团队希望在较低环境中拥有与生产环境非常接近的近似值，因为这使他们高度确信生产中的行为将与较低环境相匹配。
应用方法和结果
- 经过仔细评估后，团队决定他们可以接受一些额外风险的权衡，以实现因环境之间存在一定差异而带来的成本节省。
- 该团队决定将一些测试环境并置到同一基础设施中，并在一夜之间关闭未使用的环境。
- 该团队还找到了向左移动的机会，并在本地开发人员工作站上进行内循环开发和测试。
- 通过寻找在预生产环境和开发实践中做出小的妥协的方法，他们释放了预算，并将其充分用于自动化工作。
总结
在本模块中，你了解了 Azure 架构完善框架的成本优化支柱的五个关键原则。
成本优化的工作负载不一定是低成本工作负载。 存在重大权衡。 战术方法是被动的，只能在短期内降低成本。 为了实现长期的财务责任，您需要制定一个具有优先级、持续监控和可重复流程的战略，重点关注优化。
当您确定业务需求的优先级以与技术需求保持一致时，您可以调整成本。 但是，您应该预期在想要优化成本的领域需要进行一系列权衡，例如安全性、可扩展性、弹性和可操作性。 如果解决这些领域的挑战的成本很高，并且没有正确应用这些原则，您可能会做出冒险的选择，转而选择更便宜的解决方案，最终影响组织的业务目标和声誉。