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

卓越运营权衡

  • 项目

卓越运营通过实施明确的团队标准、理解责任和责任、关注客户成果以及团队凝聚力来提供工作负载质量。 这些目标的实现植根于 DevOps，它建议最大程度地减少流程差异，减少人为错误，并最终增加工作负载的价值回报。 该值不仅仅是根据工作负载组件所满足的功能要求来衡量的。 它还由团队在努力改进方面提供的价值来衡量。

在工作负载的设计阶段及其生命周期内，随着持续改进步骤的不断执行，必须考虑基于 卓越运营设计原则 和 卓越运营设计评审清单 中的建议的决策如何影响其他支柱的目标和优化。 某些决策可能有利于某些支柱，但对其他支柱构成权衡。 本文介绍工作负载团队在设计工作负载体系结构和操作时可能遇到的示例权衡。

卓越运营与可靠性的权衡

权衡：复杂性增加。 可靠性优先考虑简单性，因为简单的设计可以最大程度地减少错误配置并减少意外交互。

  • 安全部署策略通常需要应用程序逻辑与工作负载中的数据之间具有一定的向前和向后兼容性。 增加的复杂性会增加测试负担，并可能导致工作负载数据的复杂性或完整性问题。

  • 高度分层、模块化或参数化的基础结构即代码可能会增加意外配置错误的可能性，因为代码组件之间的交互非常复杂。

  • 有利于运营的云设计模式有时需要引入其他组件，例如，使用外部配置存储或在容器化应用程序平台中协调挎斗部署。 附加组件会增加系统中的交互点，从而增加故障或配置错误的外围应用。

  • 旨在独立发展以支持敏捷开发和托管的工作负载组件引入了对服务发现甚至 DNS 作为间接层的依赖关系。 服务发现可能缺乏对更改的响应能力，并且故障可能难以诊断。

权衡：增加可能破坏稳定的活动。 可靠性支柱鼓励避免可能破坏系统稳定并导致中断、中断或故障的活动或设计选择。

  • 部署小型增量更改是一种降低风险的技术，但预计这些小更改也会更频繁地交付到生产环境中。 部署可能会破坏系统的稳定，因此随着部署速率的提高，此风险也会增加。

  • 使用速度指标（如每周部署）来衡量自己的文化，并使用自动化来促进以更快的速度引入更改，也有可能在更短的时间内执行更多的部署。

  • 通过减少控制和可观测面的数量来增加密度以简化操作，也可能导致可用性风险增加，因为故障或配置错误会增加破坏稳定事件的影响半径。

卓越运营与安全性的权衡

权衡：增加外围应用。 安全支柱建议在组件和操作风险方面减少工作负载外围应用。 这种减少可最大程度地减少攻击途径，并缩小安全控制和测试的范围。

  • 围绕工作负载并支持其操作的组件（如自动化或自定义控制平面）也必须处于常规安全强化和测试的范围内。

  • 常规、临时和紧急操作会增加与工作负载的联系点。 零信任方法要求这些进程被视为攻击途径，并且必须包含在工作负载的安全控制和验证中。

  • 系统的可观测性平台收集有关工作负荷的日志和指标，这可以是信息泄露的宝贵来源。 因此，工作负载的安全性需要扩展，以保护数据接收器免受内部和外部威胁。

  • 生成代理、外部化配置和功能切换存储以及并行部署方法都会增加需要安全性的应用程序外围应用。

  • 由于较小的增量更改或“获取最新、保持最新”工作而导致的部署频率更高，会导致在软件开发生命周期中进行更多的安全测试。

权衡：增加对透明度的渴望。 安全工作负载基于保护流经系统组件的数据机密性的设计。

可观测性平台引入所有类型的数据，以便深入了解工作负载的运行状况和行为。 当团队尝试提高可观测性数据的保真度时，源系统的数据分类控制（如数据掩码）不会扩展到可观测性平台的日志和日志接收器的风险增加。

权衡：减少分段。 隔离访问和功能的关键安全方法是设计强大的分段策略。 此设计通过资源隔离和标识控制来实现。

  • 将不同的应用程序组件共置在共享的计算、网络和数据资源中，以便更轻松地管理反向分段或更难实现基于角色的分段。 并置组件可能还需要共享工作负载标识，这可能导致过度分配权限或缺乏可跟踪性。

  • 在统一的日志接收器中从整个系统收集所有日志可以简化查询和生成警报。 但是，这样做也可能使提供基于行的安全性变得更加困难或不可能，以便使用所需的审核控制来处理敏感数据。

  • 通过降低角色及其分配的粒度来简化基于属性或基于角色的安全性的管理，可能会导致权限范围不当。

卓越运营与成本优化权衡

卓越运营支柱从不推荐降低工作效率或危及工作负载投资回报的活动。 似乎将重点从交付活动转移的建议考虑了工作负荷和团队的长期最佳利益。 如果工作负荷即将停用，那么在引发这些权衡的建议上投入大量资金可能没有意义。

权衡：增加资源支出。 工作负荷的主要成本驱动因素是其资源成本。 部署更少的资源、调整资源大小并减少消耗通常有助于降低成本。

  • 即使更改相对较小，实施安全部署做法也可能导致并发部署的资源数增加。 这些模式需要部署应用程序或基础结构组件的多个并发实例，以便以受控方式转移流量。 在使用不可变基础结构方法的工作负荷中，这种增长更为明显。

  • 团队可能需要引入其他工作负载组件，以实现操作一致的云设计模式或工作负载自动化。 例如，为了支持部署敏捷性，他们可能会添加网关路由组件。 为了支持更好的配置管理，他们可能会添加外部配置存储。 为了支持租户生命周期事件，他们可能会生成控制平面。 这些资源还会影响预生产环境的成本。

  • 通过隔离增加预生产环境的数量来改善开发和测试体验也会增加资源数。 这些资源不用于根据生产需求提供供应，会增加解决方案的成本。

  • 在资源计数、SKU 和数据量方面，提高预生产环境与生产环境的奇偶一致性可改善质量保证过程。 成本随着奇偶校验的增加而增加。

  • 尽管遥测数据不是直接的资源，但为了实现可观测性平台的有效性，需要保留此数据。 大多数操作数据存储的定价基于引入速率和数量的组合。 通常，随着低延迟、高多样性遥测量的增加，成本也会增加。 对于多区域部署，这些操作数据接收器应按区域部署，因此任何按资源成本都成为一个因素。

权衡：减少对交付活动的关注。 工作负载团队成员通过高效执行与其功能一致的任务来增加工作负载价值。

  • 花时间创建和完善健康且负责任的支持结构和事件响应的工作负载团队正在为工作负载的用户提供有价值的服务。 例如，随着支持工作量的增加 (，正式的待命轮换) ，通常是由于业务关键性的变化，这些活动的成本会增加。 这种成本增加可能是员工增加的结果，也可能是间接引起从交付活动转移到支持职能的注意力形式。

  • 培训是工作负载团队个人持续改进过程的关键部分。 在个人扩充期间，此培训可以是正式的，也可以是自我指导的。 随着训练时间的增加，用于直接开发工作负荷的时间量会减少。 如果培训不基于角色或与工作负载或其未来特别相关，则培训投入会减少。

  • 用于保护工作负荷的可靠性、安全性和性能效率的标准化日常操作任务需要一段时间才能定义、优化和执行。 这一时间不会直接花在交付上。 这些任务的一些示例包括全面的更改影响分析、更改控制过程、彻底测试和增强的修补程序管理。 随着这些任务的频率、全面性或操作负担的增加，投入的时间也随之增加。

权衡：增加工具需求和多样性。 成本优化支柱建议减少工具蔓延、合并供应商，并对所有工具采购采用适当规模的方法。

工作负荷团队购买工具和硬件来支持在整个软件开发生命周期 (SDLC) 中执行的活动，包括规划和设计、开发和测试以及监视。 这个领域的工具市场正在增长。 工具以各种价格提供，通常对应于工具的特性和功能。 除免费产品/服务之外，这些工具会产生初始许可成本，这些成本可能是每个席位或站点范围的。 它们通常还需要持续维护合同。 可能需要建立新的供应商关系。 下面是与卓越运营原则相关的预期工具或硬件支出的一些示例：

  • 要求和积压工作管理
  • 体系结构设计工具
  • UI/UX 设计工具
  • 代码和资产托管
  • 代码和低代码开发环境
  • 自动化工具
  • 开发和质量保证工作站
  • 开发和部署管道
  • 测试执行和跟踪
  • 可观测性工具

卓越运营与性能效率的权衡

权衡：提高资源利用率。 性能效率支柱建议根据工作负载的要求分配尽可能多的可用计算和网络。

  • 工作负载的可观测性框架要求体系结构中的组件分配创建、收集和流式传输日志和指标的时间和资源。 这些数据点有助于确保实现有效的警报和监视，以确保可靠性、安全性和性能。 随着检测级别的增加，系统资源的压力也可能增加。

  • 某些部署模型（例如工作负荷可能用于安全部署的蓝/绿部署）可能会在生产应用程序平台上引入并行部署。 这些部署需要抢占式缩放来提供足够的供应以满足未来需求，或者将大部分休眠部署保留一段时间以支持回滚。

权衡：延迟增加。 为了创建高性能工作负载，团队会寻找减少工作负载执行其任务所消耗的时间和资源的方法。

  • 许多部署模型需要使用网关路由访问模式，这可能会导致延迟。 此延迟与相关流的性能目标预算有关。

  • 某些支持“随时间推移独立更改”方法以支持增量改进理想的云设计模式可能会由于遍历其他组件而引入延迟。 网关、消息传递中转站或防损坏层可能会引入此延迟。

了解其他支柱的权衡：