你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

成本优化权衡

  • 项目

设计工作负载以在财务限制下最大化投资回报 (ROI) 时，首先需要明确定义的功能和非功能性要求。 工作和精力优先顺序策略至关重要。 基础是一个具有强烈财务责任感的团队。 团队应该对可用技术及其计费模型有深入的了解。

了解工作负载的 ROI 后，可以开始改进它。 若要提高 ROI，请考虑基于 成本优化设计原则 和 成本优化设计评审清单 中的建议的决策如何影响其他 Azure Well-Architected Framework 支柱的目标和优化。 对于成本优化，请务必避免关注成本更低的解决方案。 只关注最小化支出的选择可能会增加破坏工作负载的业务目标和声誉的风险。 本文介绍工作负载团队在考虑成本优化的目标设置、设计和操作时可能遇到的示例权衡。

成本优化与可靠性的权衡

必须根据阻止服务中断或从中恢复的成本来衡量服务中断的成本。 如果中断的成本超过可靠性设计的成本，则应投入更多资金来防止或缓解中断。 相反，可靠性工作的成本可能大于中断的成本，包括合规性要求和信誉等因素。 仅在此方案中，才应考虑可靠性设计中的策略性撤资。

权衡：复原能力降低。 工作负荷包含复原措施，以尝试避免和承受特定类型和数量的故障。

  • 为了节省资金，工作负载团队可能会低估组件或过度限制其缩放，从而使组件在需求突然激增时更有可能发生故障。

  • 将工作负载资源 (增加密度) 进行成本优化，使单个组件更有可能在需求高峰和更新等维护操作期间发生故障。

  • 删除支持复原设计模式的组件（如消息总线）和创建直接依赖项会减少自我保留功能。

  • 通过减少冗余来节省资金可能会限制工作负载处理并发故障的能力。

  • 使用预算 SKU 可能会限制工作负荷可以达到的最大服务级别目标 (SLO) 。

  • 设置硬性支出限制可以防止工作负载缩放以满足合法需求。

  • 如果没有可靠性测试工具或测试，工作负荷的可靠性是未知的，并且不太可能满足可靠性目标。

权衡：有限的恢复策略。 可靠的工作负载具有针对灾难场景的测试事件响应和恢复计划。

  • 减少工作负荷灾难恢复计划的测试或钻取可能会影响恢复操作的速度和有效性。

  • 创建或保留较少的备份会减少可能的恢复点，并增加丢失数据的可能性。

  • 由于技术协助的潜在延迟，成本较低的支持合同可能会增加工作负载恢复时间。

权衡：复杂性增加。 使用简单方法并避免不必要的或过度设计的复杂性的工作负荷通常更容易在可靠性方面进行管理。

  • 使用成本优化云模式可以添加新组件，例如内容分发网络 (CDN) ，或者将职责转移到工作负荷必须为其提供可靠性目标的边缘和客户端设备。

  • 与基于资源的缩放相比，基于事件的缩放优化和验证可能更复杂。

  • 通过数据生命周期操作减少数据量和分层数据（可能与在生命周期事件之前实现聚合数据点结合使用）会在工作负荷中引入要考虑的可靠性因素。

  • 使用不同的区域来优化成本可能会使管理、网络和监视更加困难。

成本优化与安全性的权衡

工作负荷中对机密性、完整性和可用性的损害成本必须始终与防止这种泄露的工作成本相平衡。 安全事件可能会产生广泛的财务和法律影响，并损害公司的声誉。 投资安全性是一项风险缓解活动。 经历风险的成本必须与投资相平衡。 通常，不要在安全性上妥协，以获得低于责任和同意的风险缓解点的成本优化。 通过调整解决方案大小优化安全成本是一项重要的优化做法，但这样做时请注意如下权衡。

权衡：减少安全控制。 跨多个层建立安全控制（有时是冗余的），以提供深度防御。

成本优化策略之一是寻找删除累积单位或运营成本的组件或流程的方法。 请注意，为了节省资金，删除以下示例中所示的安全组件会影响安全性。 需要仔细执行此影响的风险分析。

  • 减少或简化身份验证和授权技术会损害零信任体系结构的 显式验证 原则。 这些简化的示例包括使用预共享密钥等基本身份验证方案，而不是花费时间来了解行业 OAuth 方法，或使用简化的基于角色的访问控制分配来减少管理开销。

  • 删除传输中或静态加密以降低证书及其操作流程的成本，会使数据暴露在潜在的完整性或机密性违规中。

  • 由于相关的成本和时间投资，删除或减少安全扫描或检查工具或安全测试可能会直接影响工具和测试旨在保护的机密性、完整性或可用性。

  • 由于编录和执行修补所投入的操作时间，减少安全修补的频率会影响工作负载应对不断演变的威胁的能力。

  • 删除防火墙等网络控制可能会导致阻止恶意入站和出站流量失败。

权衡：增加工作负载外围应用。 安全支柱优先考虑减少和包含的外围区域，以最大程度地减少攻击途径和管理安全控制。

优化成本的云设计模式有时需要引入其他组件。 这些附加组件会增加工作负载的表面积。 必须保护组件及其中的数据，可能采用系统中尚未使用的方式。 这些组件和数据通常受合规性约束。 可引入组件的模式示例包括：

  • 使用静态内容托管模式将数据卸载到新的 CDN 组件。

  • 使用附属密钥模式卸载处理并保护对客户端计算的资源访问。

  • 使用 Queue-Based 负载均衡模式通过引入消息总线来平滑成本。

权衡：删除分段。 安全支柱优先考虑强分段，以支持目标安全控制的应用和控制爆炸半径。

共享资源（例如在多租户情况下或在共享应用程序平台上共置多个应用程序）是一种通过增加密度和减少管理面来降低成本的方法。 这种增加的密度可能会导致安全问题，如下所示：

  • 共享资源的组件之间的横向移动更容易。 危及应用程序平台主机或单个应用程序可用性的安全事件也具有较大的爆炸半径。

  • 共置资源可能共享工作负载标识，并且访问日志中没有有意义的审核线索。

  • 网络安全控制必须足够广泛，以涵盖所有共置资源。 此配置可能会违反某些资源的最低特权原则。

  • 在共享主机上共置不同的应用程序或数据可能会导致将合规性要求和安全控制扩展到本来会不限定范围的应用程序或数据。 范围扩大需要对共置组件进行额外的安全审查和审核工作。

成本优化与卓越运营的权衡

权衡： (SDLC) 容量的软件开发生命周期受损。 工作负载的 SDLC 过程提供严谨、一致性、特殊性和优先级，以更改工作负载中的管理。

  • 减少测试工作以节省时间以及与测试人员、资源和工具相关的成本，可能会导致生产中出现更多 bug。

  • 延迟偿还技术债务以将人员精力集中在新功能上可能会导致开发周期变慢，整体灵活性降低。

  • 取消文档的优先次序，将人员工作集中在产品开发上可能会导致新员工的入职时间更长，影响事件响应的有效性，并损害合规性要求。

  • 缺乏培训投资会导致技能停滞，降低团队采用新技术和做法的能力。

  • 删除自动化工具以节省资金可能会导致人员在不再自动化的任务上花费更多时间。 它还会增加错误和不一致的风险。

  • 减少规划工作（如范围划分和活动优先级）来削减开支可能会增加由于规范模糊和实施不力而返工的可能性。

  • 避免或减少持续改进活动（如回顾和事后报告），使工作负荷团队专注于交付，可能会错失优化例程、计划外和紧急流程的机会。

权衡：可观测性降低。 为了帮助确保工作负荷具有有意义的警报和成功的事件响应，必须具有可观测性。

  • 减少日志和指标量以节省存储和传输成本会降低系统可观测性，并可能导致：

    • 创建与可靠性、安全性和性能相关的警报的数据点更少。
    • 事件响应活动的覆盖范围差距。
    • 与安全性或合规性相关的交互或边界的可观测性有限。

  • 成本优化设计模式可将组件添加到工作负荷，从而增加其复杂性。 工作负荷监视策略必须包括这些新组件。 例如，某些模式可能会引入跨多个组件的流，或者将进程从服务器转移到客户端。 这些更改会增加关联和跟踪信息的复杂性。

  • 减少对可观测性工具的投资和有效仪表板的维护可能会降低从生产中学习、验证设计选择和通知产品设计的能力。 这种减少还会妨碍事件响应活动，并使得更难实现恢复时间目标和 SLO。

权衡：延迟维护。 工作负荷团队应及时有序地使代码、工具、软件包和操作系统进行修补和更新。

  • 让与工具供应商的维护合同过期可能会导致错过优化功能、bug 解决方案和安全更新。

  • 为了节省时间，增加系统修补程序之间的时间可能会导致错过 bug 修复或缺乏针对不断发展的安全威胁的保护。

成本优化与性能效率的权衡

成本优化和性能效率支柱都优先最大化工作负载的价值。 性能效率强调满足性能目标，而无需花费超过必要的费用。 成本优化强调在不超出性能目标的情况下最大化工作负载资源产生的价值。 因此，成本优化通常会提高性能效率。 但是，存在与成本优化相关的性能效率权衡。 这些权衡可能会使达到性能目标更加困难，并阻碍正在进行的性能优化。

权衡：资源预配不足或规模不足。 性能高效的工作负荷有足够的资源来满足需求，但即使使用模式波动，也不会有过多的未使用开销。

  • 通过缩小资源来降低成本可能会剥夺应用程序的资源。 应用程序可能无法处理严重的使用模式波动。

  • 限制或延迟缩放以限制或降低成本可能会导致供应不足，无法满足需求。

  • 大幅缩减以降低成本的自动缩放设置可能会使服务无法为突然的需求高峰做好准备，或者导致频繁的缩放波动 () 。

权衡：随着时间的推移，缺乏优化。 评估功能更改、使用模式更改、新技术和不同方法对工作负载的影响是提高效率的一种方式。

  • 限制对开发性能优化专业知识的专注，以便确定交付优先级，可能会错失提高资源使用效率的机会。

  • 删除访问性能测试或监视工具会增加未检测到的性能问题的风险。 它还限制了工作负荷团队在度量/改进周期上执行的能力。

  • 忽略容易导致性能下降的区域（如数据存储）可能会逐渐降低查询性能并提升整体系统使用率。

了解其他支柱的权衡：