你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
卓越运营权衡因素
卓越运营通过实施明确的团队标准、理解责任和责任、关注客户成果和团队凝聚力提供工作负载质量。 这些目标的实现植根于 DevOps 中，它建议将进程差异降至最低，减少人为错误，并最终增加工作负荷的价值回报。 该值不只是根据工作负荷组件提供的功能要求进行度量。 这也由团队在努力改进方面提供的价值来衡量。
在工作负荷的设计阶段及其生命周期内，随着持续改进步骤的采取，请务必考虑基于卓越运营设计原则和设计评审清单中的建议决策如何影响其他支柱的目标和优化。 某些决定可能会有利于一些支柱，但对其他人构成权衡。 本文介绍在设计工作负荷体系结构和操作时工作负荷团队可能会遇到的示例权衡。
卓越运营与可靠性的权衡
权衡：复杂性增加。 可靠性优先于简单性，因为简单设计可最大程度地减少配置错误并减少意外的交互。
安全部署策略通常需要在应用程序逻辑与工作负荷中的数据之间实现某种程度的向前和向后兼容性。 这增加了复杂性会增加测试负担，并可能导致工作负荷数据的复杂性或完整性问题。
由于代码组件之间交互的复杂性，高度分层、模块化或参数化基础结构可能会增加意外配置错误的可能性。
有利于操作的云设计模式有时需要引入其他组件，例如，使用外部配置存储或在容器化应用程序平台中协调 sidecar 部署。 额外的组件和添加的间接层增加了系统中的交互点，增加了故障或配置错误的外围应用。
旨在独立演变以支持敏捷开发和托管的工作负载组件将服务发现依赖项作为间接层引入。 服务发现可能缺乏对更改的响应能力，并且故障可能难以诊断。
部署小型增量更改是一种缓解风险的技术，但这些小更改也有望更频繁地交付到生产环境。 部署可能会破坏系统稳定，因此，随着部署速率的增加，这种风险也会增加。
一种以每周部署等速度指标来衡量自己的区域性，并且使用自动化，可以更快地引入更改，也有可能在较短的时间段内执行更多部署。
通过减少控制和可观测性表面的数量来简化操作的密度也会增加可用性风险，因为故障或配置不当会增加不稳定事件的影响半径。
与安全性的卓越运营权衡
围绕工作负荷并支持其操作（如自动化或自定义控制平面）的组件还必须在常规安全强化和测试的范围内。
常规、即席和紧急操作会增加与工作负荷的联系点。 零信任方法要求这些进程被视为攻击途径，并且必须包含在工作负荷的安全控制和验证中。
系统的可观测性平台收集有关工作负荷的日志和指标，这可以是信息泄露的宝贵来源。 因此，工作负荷的安全性需要进行扩展，以保护数据接收器免受内部和外部威胁。
生成代理、外部化配置和功能切换存储，并排部署方法将增加需要安全性的应用程序外围应用。
由于小型、增量更改或“获取最新、保持最新”的努力导致部署频率较高，因此在软件开发生命周期中会产生更多的安全测试。
可观测性平台引入所有类型的数据，以便深入了解工作负荷的运行状况和行为。 当团队尝试在可观测性数据中达到更高的保真度时，源系统的数据分类控制（如数据掩码）的风险增加，不会扩展到可观测平台的日志和日志接收器。
在共享计算、网络和数据资源中并置不同的应用程序组件，使管理更容易反向分段或使基于角色的分段更难实现。 共置组件可能还需要共享工作负荷标识，这可能会导致权限过度分配或缺乏可跟踪性。
从统一日志接收器中跨系统收集所有日志可以使查询和生成警报更加轻松。 但是，这样做也使得提供基于行的安全性更加困难或不可能，以便使用所需的审核控制来处理敏感数据。
通过减少角色的粒度及其分配，简化基于属性或基于角色的安全性的管理可能会导致权限范围不当。
通过成本优化实现卓越运营权衡
卓越运营支柱从不推荐降低工作效率或危及工作负荷投资回报的活动。 似乎将重点从交付活动转移的建议考虑到工作负荷和团队的长期最佳利益。 如果你的工作负荷即将接近其日落日期，那么对触发这些权衡的建议进行高度投资可能没有意义。
实施安全部署做法（即使更改相对较小）可能会导致同时部署的资源数量增加。 这些模式需要部署应用程序或基础结构组件的多个并发实例，以便以受控方式转移流量。 这种增加在使用不可变基础结构方法的工作负荷中更为明显。
该团队可能需要引入其他工作负荷组件，以便实现操作上一致的云设计模式或工作负荷自动化。 例如，为了支持部署敏捷性，他们可能会添加网关路由组件。 为了支持更好的配置管理，他们可能会添加外部配置存储。 为了支持租户生命周期事件，他们可能会生成控制平面。 这些资源还会影响预生产环境的成本。
通过隔离增加预生产环境以提高开发和测试体验的数量也会增加资源数量。 这些资源不用于根据生产需求提供供应，会增加解决方案的成本。
在资源计数、SKU 和数据量方面，将预生产环境与生产环境的奇偶一致性提高了质量保证过程。 随着奇偶校验的增加，成本也会增加。
尽管遥测数据不是直接资源，但为了提高可观测性平台的有效性，需要持久保存此数据。 大多数操作数据存储的定价基于引入速率和卷的组合。 通常，随着低延迟、高多样性遥测的增加，成本也会增加。 对于多区域部署，这些操作数据接收器应按区域部署，因此任何每资源成本都会成为一个因素。
花费时间创建和优化健康、负责任的支持结构和事件响应的工作负荷团队正在为工作负荷的用户提供有价值的服务。 随着支持工作量的增加（例如正式的通话轮换），通常由于业务关键性的变化，这些活动的成本也会增加。 这种成本增加可能是员工增加的结果，也可以以从交付活动转向支持职能的注意力的形式间接产生。
培训是工作负荷团队个人持续改进过程的关键部分。 在个人扩充期间，此培训可以是正式的或自我定向的。 随着训练时间的增加，可用于直接开发工作负荷的时间会减少。 当训练不基于角色或与工作负荷或其未来密切相关时，培训方面的投资会减少。
用于保护工作负荷的可靠性、安全性和性能效率的标准化例程操作任务需要时间来定义、优化和执行。 这一次不会直接花在交付上。 这些任务的一些示例包括全面的变更影响分析、更改控制过程、彻底测试和增加的修补程序管理。 随着这些任务的频率、全面性或运营负担增加，投入的时间也随之增加。
工作负荷团队购买工具和硬件来支持在整个软件开发生命周期（SDLC）中执行的活动，包括规划和设计、开发和测试和监视。 在这个空间中用于工具的市场正在增长。 工具以通常对应于工具的特性和功能的各种价格点提供。 除了免费产品/服务之外，这些工具会产生初始许可费用，这些费用可能是每个用户、每设备或站点范围的。 它们通常需要持续的维护合同。 可能需要建立新的供应商关系。 下面是与卓越运营原则相关的预期工具或硬件支出的一些示例：
- 要求和积压工作管理
- 体系结构设计工具
- UI/UX 设计工具
- 代码和资产托管
- 代码和低代码开发环境
- 自动化工具
- 开发和质量保证工作站
- 开发和部署管道
- 测试执行和跟踪
- 可观测性工具
卓越运营与性能效率的权衡
工作负荷的可观测性框架要求体系结构中的组件分配时间和资源来创建、收集和流式传输日志和指标。 这些数据点有助于确保能够进行有效的警报和监视，以确保可靠性、安全性和性能。 随着检测级别的增加，系统资源的压力也可能增加。
某些部署模型（例如蓝/绿部署）可能用于安全部署的工作负荷可能会在生产应用程序平台上引入并行部署。 这些部署需要先发制人的缩放来提供足够的供应以满足未来的需求，或者将大部分休眠部署保留一段时间才能支持回滚。
许多部署模型需要使用网关路由访问模式，这可能会导致延迟。 此延迟根据相关流的性能目标预算进行绘制。
一些支持“随时间而独立更改”方法的云设计模式，以支持增量改进的理想，可能会导致延迟，因为遍历其他组件。 网关、消息代理或防腐层可能会引入此延迟。
相关链接
探索其他支柱的权衡：