本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 與 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>
+ 網路存取方法如何容納越來越多的租戶及其資料磁碟區？
+ 是否本質上可擴展以滿足未來需求？
+ 採取哪些措施來確保效能一致，即使在尖峰流量期間或快速擴展事件？
+ 該方法如何處理網路延遲和抖動？ 是否有機制可最佳化資料輸送量並將延遲降至最低？
+ 網路存取方法是否可以適應不同的網路條件？ 它可以為每個客戶提供單一租戶體驗嗎？
+ 網路存取方法對基礎基礎設施有何影響？ 是否需要對現有系統進行重大升級或變更？