本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 与 SaaS 产品的网络访问相关的开发指标
<a name="assessment-engineering-dev"></a>

**Topics**
+ [部署频率、部署时间和冲刺速度](#assessment-engineering-dev-velocity)
+ [灵活性和功能交付](#assessment-engineering-dev-features)
+ [更改失败率](#assessment-engineering-dev-failure-rate)
+ [代码质量和工程团队绩效](#assessment-engineering-dev-performance)
+ [技术债务减免](#assessment-engineering-dev-debt-reduction)
+ [可扩展性、容量和性能](#assessment-engineering-dev-scalability)

## 部署频率、部署时间和冲刺速度
<a name="assessment-engineering-dev-velocity"></a>

为了优化开发周期的效率，了解网络堆栈配置对冲刺速度的影响至关重要。

### 高分标准
<a name="assessment-engineering-dev-velocity-high-score-criteria"></a>

网络堆栈配置经过简化和自动化，并且需要最少的人工干预。它不会显著影响冲刺速度。任何团队成员都可以执行网络堆栈配置和重新部署。这减少了瓶颈和对专业资源的依赖。

### 低分指标
<a name="assessment-engineering-dev-velocity-low-score-indicators"></a>

配置网络堆栈需要大量的故事点。这表明这是一个复杂而耗时的过程，会影响新功能的开发。频繁重新部署网络堆栈会产生大量的时间和成本开支。网络配置任务需要专业的工程专业知识，这会造成瓶颈并减慢开发周期。

### 自我评估问题
<a name="assessment-engineering-dev-velocity-self-assessment-questions"></a>
+ 部署过程中涉及哪些手动步骤（如果有）。它们如何影响部署频率和时间？
+ 部署失败时如何处理回滚。它们对部署频率和恢复时间有何影响？
+ 在设置新环境时，配置网络堆栈需要多少故事点？
+ 在开发过程中，频繁地重新部署网络堆栈会带来多少额外的成本和时间开销？
+ 网络堆栈的配置取决于专业的工程专业知识，还是可以由任何团队成员管理的任务？

## 灵活性和功能交付
<a name="assessment-engineering-dev-features"></a>

网络接入方法可以影响工程团队有效创新和部署新功能的能力。

### 高分标准
<a name="assessment-engineering-dev-features-high-score-criteria"></a>

网络接入方法提供了快速、无缝部署功能所需的灵活性。它支持多种通信协议、单向和双向通信以及消息大小。它不会对开发过程或创新施加重大限制。

### 低分指标
<a name="assessment-engineering-dev-features-low-score-indicators"></a>

由于缺乏支持的通信协议、消息大小不灵活或对特定技术和相关专家资源的依赖，网络访问方法限制了团队推出新功能的能力。这可能会导致开发周期变慢，并阻碍服务的发展。

### 自我评估问题
<a name="assessment-engineering-dev-features-self-assessment-questions"></a>
+ 网络接入方法如何影响团队开发和部署新功能的灵活性？
+ 网络访问方法中是否存在限制对某些通信协议或技术的支持的限制？
+ 该方法如何促进或限制将新技术和创新整合到服务中？
+ 网络接入方法如何影响开发时间表和产品路线图？

## 更改失败率
<a name="assessment-engineering-dev-failure-rate"></a>

部署新服务或功能时，您选择的网络访问方法可能会影响更改失败率。更好的控制通常意味着更大的灵活性，但也会增加配置错误的可能性，例如在管理复杂的路由设置时。

### 高分标准
<a name="assessment-engineering-dev-failure-rate-high-score-criteria"></a>

您可以对网络堆栈进行更改，同时将故障风险降至最低。存在足够的测试机制，存在高效的回滚机制，有效的监控可帮助您快速识别和解决问题。

### 低分指标
<a name="assessment-engineering-dev-failure-rate-low-score-indicators"></a>

网络访问方法在变更过程中容易出现故障。测试选项有限，部署策略复杂，或者监控和故障排除能力不足。需要多方参与故障排除会议。这可能会导致停机时间增加并降低 SaaS 产品的可用性。

### 自我评估问题
<a name="assessment-engineering-dev-failure-rate-self-assessment-questions"></a>
+ 在更新网络堆栈时，有哪些措施可以降低变更失败的风险？
+ 是否有全面的测试和验证流程？
+ 系统能以多快的速度从失败的更改中恢复？ 是否有有效的回滚流程？
+ 是否有主动监控和警报系统，以便在网络堆栈变更期间和之后快速检测和解决问题？
+ 网络堆栈部署的历史更改失败率是多少。从过去的事件中吸取了哪些教训？
+ 网络访问方法如何促进或限制变更的实施。这种方法能否最大限度地减少服务中断？
+ 当您部署涉及网络访问方法的变更时，影响 SaaS 产品在生产环境中的可用性的风险是什么？

## 代码质量和工程团队绩效
<a name="assessment-engineering-dev-performance"></a>

网络访问方法可能会间接影响 SaaS 产品的代码质量。网络访问缺乏标准化可能会迫使工程团队支持多种集成方法，这可能会导致代码库膨胀。这反过来又会阻碍团队开发深度和控制代码质量的能力，而这正是维持高绩效工程团队所必需的。

### 高分标准
<a name="assessment-engineering-dev-performance-high-score-criteria"></a>

得益于代码模块化和跨支持的网络访问方法的可重用性，工程团队可以保持专注。网络访问方法与现有的部署管道和自动测试策略兼容。

### 低分指标
<a name="assessment-engineering-dev-performance-low-score-indicators"></a>

由于集成和维护过多的网络接入方法所带来的开销，工程团队的绩效会降低。有些方法会显著增加复杂性，产生技术债务，或者需要开发变通方法来解决能力缺失或不足的问题。

### 自我评估问题
<a name="assessment-engineering-dev-performance-self-assessment-questions"></a>
+ 网络接入方法如何管理网络可变性？
+ 您是否需要开发其他代码来处理连接中断？
+ 新的网络接入方法是与现有方法无缝集成，还是需要大量的定制开发？
+ 采用新的网络接入方法需要在多大程度上进行变革？ 现有的代码库和自动测试能否得到有效利用？
+ 使用所选的网络访问方法部署或重新部署服务有多容易或困难？ 可以经常这样做吗？ 是否存在对专家资源的依赖？
+ 网络接入方法是促进还是使遵守编码标准和最佳实践变得复杂？
+ 该方法 time-to-market对新功能或修复有何影响？

## 技术债务减免
<a name="assessment-engineering-dev-debt-reduction"></a>

在评估网络接入方法对技术债务的影响时，应考虑其可扩展性、可观察性和安全能力。

### 高分标准
<a name="assessment-engineering-dev-debt-reduction-high-score-criteria"></a>

随着客户群的扩大，该方法有效地简化了基础架构管理。它提供了强大的可观测性功能 out-of-the-box。这促进了高效的监控和维护。

### 低分指标
<a name="assessment-engineering-dev-debt-reduction-low-score-indicators"></a>

网络接入方法无法充分保护通信渠道，也缺乏足够的定性指标观测工具。随着客户群的增加，可能还需要对基础架构管理进行额外的开发，或者可能需要解决可靠性问题的变通方法。

### 自我评估问题
<a name="assessment-engineering-dev-debt-reduction-self-assessment-questions"></a>
+ 网络接入方法如何影响基础设施的长期可扩展性？ 它能否以最少的额外投资促进无缝增长？
+ 随附的可观测性工具有多全面？ 它们是否允许主动监控和解决问题？
+ 随着时间的推移，网络访问方法对代码库的维护和演进有何预期影响？
+ 该方法能否很好地与现有和计划中的基础架构集成。是否需要进行重大更改或补充？

## 可扩展性、容量和性能
<a name="assessment-engineering-dev-scalability"></a>

要确定网络接入方法对于 SaaS 产品的适用性，必须分析其在需求增加时如何保持最佳性能。

### 高分标准
<a name="assessment-engineering-dev-scalability-high-score-criteria"></a>

网络接入方法无缝促进了扩展。它在请求处理期间保持低延迟，并且可以有效地处理流量峰值。无论流量水平如何增加，它都能提供稳定的性能，并且不会对增长施加运营限制。

### 低分指标
<a name="assessment-engineering-dev-scalability-low-score-indicators"></a>

网络接入方法无法有效扩展，可能是由于固有的带宽限制或基础设施容量不足。资源配置和管理会增加复杂性或产生依赖关系。由于延迟、抖动和吞吐量变化增加，服务性能会降低，尤其是在拥挤的网络条件下。

### 自我评估问题
<a name="assessment-engineering-dev-scalability-self-assessment-questions"></a>
+ 网络接入方法如何适应越来越多的租户及其数据量？
+ 它本质上是否可以扩展以满足未来的需求？
+ 采取了哪些措施来确保性能保持一致，即使在流量高峰期或快速扩展事件中也是如此？
+ 该方法如何处理网络延迟和抖动？ 是否有优化数据吞吐量和最大限度减少延迟的机制？
+ 网络接入方法能否适应不同的网络条件？ 它能否为每位客户提供单租户体验？
+ 网络接入方法对底层基础设施有什么影响？ 它是否需要对现有系统进行重大升级或更改？