工作负载的 Power Platform 卓越运营权衡
卓越运营通过实施明确的团队标准、理解责任和问责制、关注客户结果和团队凝聚力来支持工作负载质量。 这些目标的实现基于 DevOps，它建议最大程度地减少流程差异，减少人为错误，并最终增加工作负荷的价值回报。 该值不仅根据工作负载组件提供的功能要求来衡量。 它还由团队在努力改进方面提供的价值来衡量。
在工作负载的设计阶段以及在其生命周期中，随着持续改进步骤的采取，重要的是要考虑基于 Operational Excellence 设计原则 的决策和 Operational Excellence 设计评审清单中的 建议如何影响其他支柱的目标和优化。 某些决策可能有利于某些支柱，但对其他支柱构成权衡。 本文介绍工作负荷团队在设计工作负荷体系结构和操作时可能遇到的权衡示例。
卓越运营与可靠性的权衡
权衡：增加复杂性。 可靠性优先考虑简单性，因为简单的设计可以最大程度地减少错误配置并减少意外交互。
安全部署策略通常需要应用程序逻辑与工作负荷中的数据之间具有一定的向前和向后兼容性。 增加的复杂性会增加测试负担，并可能导致工作负荷数据的复杂性或完整性问题。
高度分层、模块化或参数化的结构可能会增加意外错误配置的可能性，因为工作负荷组件之间的交互非常复杂。
有利于运营的云设计模式有时需要引入更多组件，例如，使用 secret store 或依赖 Application Insights 附加组件增加了系统中的交互点，增加了发生故障或配置错误的可能性。
部署小的增量更改是一种降低风险的技术，但用户希望这些小的更改能够更频繁地交付到生产环境中。 部署可能会破坏系统的稳定，因此随着部署速率的提高，此风险也会增加。
使用速度指标（例如每周部署）来衡量自己的文化，并使用自动化来促进以更快的速度引入更改，也有可能在更短的时间内执行更多的部署。
通过减少控制和可观察性点的数量来增加密度以简化操作也可能导致可用性风险增加，因为故障或配置错误会增加不稳定事件的影响。
卓越运营与安全性的权衡
围绕工作负荷并支持其操作的组件（例如自动化或自定义控制平面）也必须处于常规安全强化和测试的范围内。
例行、计划外和紧急操作会增加与工作负载的接触点。 零信任方法要求将这些流程视为漏洞，并且必须包含在工作负载的安全控制和验证中。
系统的可观测性平台收集有关工作负荷的日志和指标，这可以是信息泄露的宝贵来源。 因此，工作负荷的安全性需要扩展，以保护数据接收器免受内部和外部威胁。
生成代理、外部化配置和功能切换存储都会增加需要安全性的应用程序外围应用。
由于小的增量更改或“获取最新，保持最新”的工作而导致的部署频率较高，这会导致软件开发生命周期（SDLC）中进行更多的安全测试。
可观测性平台引入所有类型的数据，以便深入了解工作负荷的健康状况和行为。 当团队尝试获得可观测性数据的更高保真度时，源系统的数据分类控件（例如数据掩码）不能扩展至可观测性平台的日志和日志接收器的风险较高。
将不同的应用程序组件共置在共享的环境和数据资源中，以便更轻松地管理反向分段或更难实现基于角色的分段。 共置组件可能还需要共享工作负荷标识，这可能导致过度分配权限或缺乏可跟踪性。
在统一的日志接收器中从整个系统收集所有日志可以简化查询和生成警报。 但是，这样做也会使提供基于行的安全性以使用所需的审计控制来处理敏感数据变得更加困难或不可能。
通过降低角色及其分配的粒度来简化基于属性或基于角色的安全性的管理，可能会导致权限范围不当。
卓越运营与体验优化的权衡
需要大量资源的用户体验开发可能会降低优先级，这可能会导致体验缺乏工作负载用户所需的可用性、交互和视觉设计。
用户界面开发通常在更快的迭代和交付周期中完成，这可能会给团队的 SDLC 流程带来压力。
卓越运营与绩效效率的权衡
- 工作负载的监控框架要求架构中的组件分配时间和资源来创建、收集和流式传输日志和指标。 这些数据点有助于确保能够有效地发出警报和监控，以实现可靠性、安全性和性能。 随着检测级别的增加，系统资源的压力也可能增加。
- 一些支持“随时间独立更改”方法以支持增量改进理想的云设计模式可能会因遍历其他组件而引入延迟。