軟體交付效能提升四關鍵指標實踐

軟體交付效能的提升一直是軟體工程領域的重要課題。匯入 DORA 指標（DevOps 研究與評估）的四關鍵指標，能有效衡量並持續改進交付流程。這些指標並非單純的資料統計，而是團隊協作與流程最佳化的根本。透過監控佈署頻率、變更前置時間、變更失敗率和服務還原時間，團隊可以更精準地掌握交付效能瓶頸，並據此制定改進策略。在實務操作上，服務失敗的定義需要考量使用者經驗、系統穩定性和效能表現。並非所有團隊都能直接在生產環境實施，因此可以選擇最接近生產環境的測試環境，並將測試失敗視為服務失敗。

實施四關鍵指標的挑戰與實踐

監控服務失敗的困難與定義

在實施四關鍵指標的過程中，監控服務失敗（Service Failures）是最具挑戰性的任務之一。服務失敗的定義並不容易，因為它涉及到對系統穩定性和使用者經驗的判斷。一個服務失敗可以被定義為任何導致使用者無法完成預期任務的情況，無論是因為系統當機、效能下降還是其他問題。

服務失敗的定義與判斷

在定義服務失敗時，需要考慮以下幾個因素：

1. 使用者經驗：如果使用者因為系統問題而放棄使用服務，那麼這可以被視為服務失敗。
2. 系統穩定性：系統的穩定性是衡量服務失敗的重要指標。如果系統頻繁當機或出現錯誤，那麼就需要記錄為服務失敗。
3. 效能問題：即使系統沒有當機，但如果它的回應時間過長，導致使用者放棄使用，那麼這也應該被視為服務失敗。

如何記錄服務失敗

為了記錄服務失敗，通常會使用「變更失敗」（Change Failure）票據來跟蹤。票據的開啟時間代表了服務失敗的開始，而票據的關閉時間則代表了服務還原的時間。這些資料可以用來計算服務失敗的頻率和持續時間。

不在生產環境中的處理方法

並非所有的團隊都能直接在生產環境中實施四關鍵指標。在這種情況下，可以選擇「最高環境」（Highest Environment）作為替代，例如系統整合測試（SIT）、預生產（Pre-prod）或分段（Staging）環境。在這個環境中，可以將測試人員和協作團隊視為「使用者」，並將測試失敗視為服務失敗。

處理「最高環境」的關鍵

1. 定義「最高環境」：選擇一個最接近生產環境的分享環境，所有團隊都在這個環境中交付變更。
2. 視測試失敗為服務失敗：在這個環境中發生的測試失敗應該被視為服務失敗，並記錄相關資料。

資料捕捉與計算

一旦定義了相關指標，就可以開始捕捉和計算資料。儘管自動化捕捉是理想的選擇，但手動捕捉在初期階段也是可以接受的。

需要捕捉的資料

1. 成功佈署次數：記錄每天的成功佈署次數。
2. Pipeline執行時間：記錄每次變更透過Pipeline所需的時間。
3. 變更失敗票數：記錄變更失敗的票數。
4. 變更失敗票據開啟時間：記錄票據開啟和關閉的時間，以計算服務失敗的持續時間。

計算四關鍵指標

1. 佈署頻率（Deployment Frequency）：計算單位時間內的成功佈署次數。建議使用31天的平均值來減少波動。

   def calculate_deployment_frequency(deployments, time_period):
       """
       計算佈署頻率
       :param deployments: 成功的佈署次數列表
       :param time_period: 時間區間，例如31天
       :return: 佈署頻率
       """
       total_deployments = sum(deployments[-time_period:])
       return total_deployments / time_period
   

   內容解密：

   • 這個函式用於計算過去一段時間內的佈署頻率。
   • 它接受兩個引數：deployments（成功的佈署次數列表）和time_period（時間區間）。
   • 透過對過去time_period天的佈署次數進行求和，然後除以time_period，得到平均每天的佈署頻率。
   • 這樣的計算方式可以減少每日波動的影響，提供更穩定的指標。

2. 變更前置時間（Lead Time for Changes）：計算每次變更從開始到佈署所需的時間。建議計算每日的平均前置時間。

   def calculate_lead_time(lead_times):
       """
       計算變更前置時間的平均值
       :param lead_times: 每次變更的前置時間列表
       :return: 平均前置時間
       """
       return sum(lead_times) / len(lead_times)
   

   內容解密：

   • 這個函式計算變更前置時間的平均值。
   • 它接受一個引數lead_times，即每次變更的前置時間列表。
   • 透過對所有變更前置時間求和，然後除以變更次數，得到平均前置時間。
   • 這樣的計算方式可以提供一個穩定的前置時間指標，幫助團隊瞭解變更流程的效率。

3. 變更失敗率（Change Failure Rate）：計算變更失敗的比例。

   def calculate_change_failure_rate(total_deployments, failed_deployments):
       """
       計算變更失敗率
       :param total_deployments: 總佈署次數
       :param failed_deployments: 失敗的佈署次數
       :return: 變更失敗率
       """
       if total_deployments == 0:
           return 0
       return (failed_deployments / total_deployments) * 100
   

   內容解密：

   • 這個函式用於計算變更失敗率。
   • 它接受兩個引數：total_deployments（總佈署次數）和failed_deployments（失敗的佈署次數）。
   • 透過將失敗的佈署次數除以總佈署次數，並乘以100，得到變更失敗率的百分比。
   • 如果沒有佈署次數，函式傳回0，以避免除以零的錯誤。

4. 服務還原時間（Mean Time to Recovery）：計算從服務失敗到還原的平均時間。

   def calculate_mean_time_to_recovery(failure_durations):
       """
       計算平均服務還原時間
       :param failure_durations: 每次服務失敗的持續時間列表
       :return: 平均還原時間
       """
       return sum(failure_durations) / len(failure_durations)
   

   內容解密：

   • 這個函式計算從服務失敗到還原的平均時間。
   • 它接受一個引數failure_durations，即每次服務失敗的持續時間列表。
   • 透過對所有失敗持續時間求和，然後除以失敗次數，得到平均還原時間。
   • 這樣的計算方式可以幫助團隊瞭解在發生服務失敗時的還原效率。

四關鍵指標的實施與分析

在軟體開發與維運的世界中，四關鍵指標（Four Key Metrics）已經成為衡量團隊績效與軟體交付能力的黃金標準。這些指標包括了佈署頻率（Deployment Frequency）、變更前置時間（Lead Time for Changes）、變更失敗率（Change Failure Rate）以及服務還原時間（Time to Restore Service）。本篇文章將探討這些指標的計算方法、實施細節以及如何利用它們來提升軟體開發與維運的效率。

佈署頻率的計算與分析

佈署頻率是指在特定時間內，團隊成功佈署到生產環境的次數。這個指標反映了團隊的交付能力與自動化水平。要計算佈署頻率，我們需要收集過去一段時間內（通常是31天）的佈署資料，然後統計每天的佈署次數。

程式碼範例：佈署頻率計算

import pandas as pd

# 假設我們有一個包含佈署記錄的DataFrame
deploy_data = pd.DataFrame({
    'date': ['2023-01-01', '2023-01-01', '2023-01-02', ...],
    'deployment_id': [1, 2, 3, ...]
})

# 將日期轉換為datetime格式
deploy_data['date'] = pd.to_datetime(deploy_data['date'])

# 按日期統計佈署次數
daily_deploys = deploy_data.groupby('date').size().reset_index(name='count')

# 計算過去31天的佈署頻率
recent_deploys = daily_deploys[daily_deploys['date'] >= (daily_deploys['date'].max() - pd.Timedelta(days=31))]
average_deployment_frequency = recent_deploys['count'].mean()

print(f"過去31天的平均佈署頻率：{average_deployment_frequency}")

內容解密：

1. 我們首先匯入必要的pandas函式庫來處理資料。
2. 建立一個模擬的佈署資料DataFrame，包含日期和佈署ID。
3. 將日期欄位轉換為datetime格式，以便進行日期相關的計算。
4. 使用groupby函式按日期統計每天的佈署次數。
5. 篩選出過去31天的資料，並計算這段時間內的平均佈署頻率。

變更前置時間的計算

變更前置時間是指從提交程式碼到變更成功佈署到生產環境所需的時間。這個指標衡量了團隊的開發效率與交付能力。

程式碼範例：變更前置時間計算

# 假設我們有提交記錄和佈署記錄的資料
commit_data = pd.DataFrame({
    'commit_date': ['2023-01-01', '2023-01-02', ...],
    'deployment_id': [1, 2, ...]
})

deploy_data = pd.DataFrame({
    'deployment_id': [1, 2, ...],
    'deployment_date': ['2023-01-03', '2023-01-04', ...]
})

# 合併資料並計算前置時間
merged_data = pd.merge(commit_data, deploy_data, on='deployment_id')
merged_data['lead_time'] = pd.to_datetime(merged_data['deployment_date']) - pd.to_datetime(merged_data['commit_date'])

# 計算過去31天內的平均前置時間
recent_lead_times = merged_data[merged_data['deployment_date'] >= (merged_data['deployment_date'].max() - pd.Timedelta(days=31))]
average_lead_time = recent_lead_times['lead_time'].mean()

print(f"過去31天的平均變更前置時間：{average_lead_time}")

內容解密：

1. 準備提交記錄和佈署記錄的資料。
2. 透過deployment_id合併這兩份資料。
3. 計算每個佈署的變更前置時間（佈署日期 - 提交日期）。
4. 篩選出過去31天的資料並計算平均前置時間。

變更失敗率的計算

變更失敗率是指導致生產環境失敗的變更次數佔總變更次數的比例。這個指標反映了團隊的變更品質。

程式碼範例：變更失敗率計算

# 假設我們有變更失敗記錄和總佈署次數的資料
failure_data = pd.DataFrame({
    'date': ['2023-01-01', '2023-01-02', ...],
    'failure_count': [2, 0, ...]
})

total_deploys = daily_deploys  # 從前面的範例中取得

# 合併資料並計算失敗率
merged_data = pd.merge(failure_data, total_deploys, on='date')
merged_data['change_failure_rate'] = merged_data['failure_count'] / merged_data['count']

# 計算過去31天的平均變更失敗率
recent_failure_rates = merged_data[merged_data['date'] >= (merged_data['date'].max() - pd.Timedelta(days=31))]
average_change_failure_rate = recent_failure_rates['change_failure_rate'].mean()

print(f"過去31天的平均變更失敗率：{average_change_failure_rate * 100}%")

內容解密：

1. 準備變更失敗記錄和總佈署次數的資料。
2. 合併這兩份資料並計算每天的變更失敗率。
3. 篩選出過去31天的資料並計算平均變更失敗率。

服務還原時間的計算

服務還原時間是指從檢測到故障到還原服務所需的時間。這個指標衡量了團隊的故障處理能力。

程式碼範例：服務還原時間計算

# 假設我們有故障記錄的資料
failure_tickets = pd.DataFrame({
    'created_at': ['2023-01-01 10:00', '2023-01-02 12:00', ...],
    'resolved_at': ['2023-01-01 11:00', '2023-01-02 13:00', ...]
})

# 計算每個故障的還原時間
failure_tickets['time_to_restore'] = pd.to_datetime(failure_tickets['resolved_at']) - pd.to_datetime(failure_tickets['created_at'])

# 計算過去120天的平均還原時間
recent_failures = failure_tickets[pd.to_datetime(failure_tickets['resolved_at']) >= (pd.to_datetime(failure_tickets['resolved_at']).max() - pd.Timedelta(days=120))]
average_time_to_restore = recent_failures['time_to_restore'].mean()

print(f"過去120天的平均服務還原時間：{average_time_to_restore}")

內容解密：

1. 準備故障記錄的資料，包含故障建立時間和解決時間。
2. 計算每個故障的還原時間。
3. 篩選出過去120天的資料並計算平均還原時間。

圖表呈現：四關鍵指標儀錶板

  graph LR
    A[佈署頻率] --> B[儀錶板]
    C[變更前置時間] --> B
    D[變更失敗率] --> B
    E[服務還原時間] --> B
    B --> F[歷史資料]
    B --> G[定義與計算方法]

圖表翻譯：
此圖展示了四關鍵指標如何整合到一個儀錶板中。佈署頻率、變更前置時間、變更失敗率和服務還原時間這四個指標被集中展示，並附帶歷史資料和相關的定義與計算方法，幫助團隊更好地理解和監控這些指標。

四關鍵指標視覺化呈現與團隊協作最佳化實踐

在軟體開發與交付流程中，視覺化呈現四關鍵指標（DORA指標）對於團隊理解與最佳化績效至關重要。本文將探討如何有效地視覺化這些指標，以及它們如何促進團隊討論、理解和改進軟體交付流程。

佈署頻率視覺化

圖表設計與解讀

佈署頻率是衡量團隊軟體交付能力的關鍵指標。我們採用時間序列柱狀圖來呈現每日的佈署次數，同時在圖表底部顯示當日佈署次數和總佈署次數，以提供即時與整體的資料對比。

  graph LR
    A[每日佈署次數] --> B(柱狀圖呈現)
    C[總佈署次數] --> D(數值顯示)
    E[平均佈署頻率] --> F(趨勢線顯示)
    G[DORA評級] --> H(績效指標顯示)

圖表翻譯： 此圖示展示了佈署頻率的視覺化呈現方式。左側的柱狀圖顯示了每日的佈署次數，右側的趨勢線則展示了整體的佈署頻率變化，而底部的指標則顯示了根據DORA評分的績效等級。

關鍵資料呈現

• 平均每日佈署次數
• 31天總佈署次數
• 95百分位佈署資料
• 趨勢線分析

前置時間視覺化分析

圖表設計特點

前置時間（Lead Time）視覺化同樣採用柱狀圖，但特別加入了佈署次數的灰色陰影繪製，以提供額外的背景資訊。

  graph LR
    A[前置時間] --> B(柱狀圖呈現)
    C[佈署次數背景] --> D(灰色陰影繪製)
    E[平均前置時間] --> F(關鍵指標顯示)

圖表翻譯： 此圖表展示了前置時間的變化趨勢。柱狀圖顯示了每日的前置時間，而灰色陰影部分則代表當日的佈署次數，為資料分析提供了額外的參考。

資料解讀重點

1. 平均前置時間變化趨勢
2. 最長前置時間記錄
3. 與佈署頻率的關聯性分析
4. DORA評級對應的績效水平

變更失敗率視覺化實踐

特點分析

變更失敗率的視覺化採用了不同的呈現方式。由於大多數情況下的失敗次數為零或個位數，因此很容易識別出異常情況。

  graph LR
    A[變更失敗率] --> B(柱狀圖呈現)
    C[佈署次數對比] --> D(同圖表對比呈現)
    E[失敗率百分比] --> F(關鍵指標顯示)

圖表翻譯： 此圖表清晰地展示了變更失敗率的分佈情況。透過與佈署次數的對比，可以快速判斷失敗率是否與佈署頻率有關。

重點觀察指標

• 失敗次數分佈情況
• 與佈署活動的相關性分析
• 總失敗率百分比
• 穩定性趨勢分析

服務還原時間視覺化

特點與實踐

服務還原時間（Time to Restore Service）的視覺化採用了較長的時間跨度（120天），以更好地觀察趨勢變化。

  graph LR
    A[還原時間分佈] --> B(柱狀圖呈現)
    C[前置時間對比] --> D(同圖表對比呈現)
    D[還原時間中位數] --> E(關鍵指標顯示)

圖表翻譯： 此圖表展示了服務還原時間的變化趨勢，並與前置時間進行對比，有助於全面評估系統的還原能力。

重點關注指標

1. 還原時間中位數
2. 有效還原次數統計
3. 穩定性趨勢分析
4. 與前置時間的對比關係

綜合儀錶板設計

前頁設計重點

綜合儀錶板（Four Key Metrics Front Page）整合了四個關鍵指標的主要資料和圖表，實作了以下功能：

1. 即時顯示關鍵指標資料
2. 整合佈署頻率和前置時間圖表
3. 根據團隊關注點動態調整呈現內容

實踐效果

1. 提升團隊對關鍵指標的理解
2. 促進跨功能團隊討論
3. 加速問題識別和解決
4. 強化團隊自主最佳化能力

團隊協作與持續改進

討論與理解

團隊每週集體討論四關鍵指標，討論內容隨著時間推進逐步深入：

1. 初期：指標定義與理解
2. 中期：資料分析與問題識別
3. 後期：改進方案制定與實施

團隊自主最佳化

1. 流程現代化需求提出
2. 品質改進措施實施
3. 團隊結構最佳化建議

實踐心得

透過視覺化和資料驅動的方式，四關鍵指標的實施不僅提升了團隊的軟體交付績效，也促進了團隊的協作與自主改進能力。這種資料驅動的文化變革，為團隊帶來了持續的改進動力。

內容解密：

本章節詳細闡述了四關鍵指標的視覺化呈現方式及其在團隊協作中的實踐應用。透過多個視覺化圖表的設計與解讀，團隊能夠更直觀地理解軟體交付流程中的關鍵指標，從而促進團隊討論、問題識別和持續改進。

1. 進一步最佳化視覺化工具的整合度
2. 擴充套件資料分析的深度與廣度
3. 強化團隊間的協作與知識分享

實踐建議

1. 建立標準化的視覺化範本
2. 定期進行團隊資料解讀培訓
3. 鼓勵團隊自主提出改進方案

透過這些持續的改進與實踐，團隊能夠更好地利用四關鍵指標來最佳化軟體交付流程，從而實作更高的績效水平。