我的 HNG 之旅。第六階段：利用 Python 公開 DORA 指標

介紹

對於第 6 階段，我們的任務是公開 DORA（DevOps 研究），我最近開始了一個使用 Python 公開 DORA（DevOps 研究和評估）指標的專案。這次經驗教會了我關於 DevOps 實踐和複雜性的寶貴經驗。在本文中，我將引導您完成整個過程，解釋每個指標的含義，並強調一些需要注意的常見陷阱。

DORA 指標是什麼？
在深入研究程式碼之前，我們先簡單討論一下 DORA 指標是什麼：

• 部署頻率：組織成功發佈到生產環境的頻率。
• 更改的前置時間：提交到投入生產所需的時間。
• 更改失敗率：導致生產失敗的部署百分比。
• 恢復服務的時間：從生產故障中恢復需要多長時間。

這些指標可協助團隊衡量其軟體交付效能並確定需要改進的領域。

開始使用
要開始公開這些指標，您需要：

• Python 3.7 或更高版本
• GitHub 帳戶和個人存取權令牌
• GitHub API 基礎知識

首先，安裝必要的函式庫：

pip install requests prometheus_client

程式碼結構
我將 Python 腳本建置為一個名為 DORAMetrics 的類別。這是其初始化的簡化版本：

class DORAMetrics:
    def __init__(self, github_token, repo_owner, repo_name):
        self.github_token = github_token
        self.repo_owner = repo_owner
        self.repo_name = repo_name
        self.base_url = f"https://api.github.com/repos/{repo_owner}/{repo_name}"
        self.headers = {
            'Authorization': f'token {github_token}',
            'Accept': 'application/vnd.github.v3+json'
        }

        # Define Prometheus metrics
        self.deployment_frequency = Gauge('dora_deployment_frequency', 'Deployment Frequency (per day)')
        self.lead_time_for_changes = Gauge('dora_lead_time_for_changes', 'Lead Time for Changes (hours)')
        self.change_failure_rate = Gauge('dora_change_failure_rate', 'Change Failure Rate')
        self.time_to_restore_service = Gauge('dora_time_to_restore_service', 'Time to Restore Service (hours)')

此設定可讓我們與 GitHub API 互動並為每個 DORA 指標建立 Prometheus 指標。

從 GitHub 取得資料
最具挑戰性的方面之一是從 GitHub 檢索必要的資料。以下是我取得部署的方式：

def get_deployments(self, days=30):
    end_date = datetime.now()
    start_date = end_date - timedelta(days=days)

    url = f"{self.base_url}/deployments"
    params = {'since': start_date.isoformat()}
    deployments = []

    while url:
        response = requests.get(url, headers=self.headers, params=params)
        response.raise_for_status()
        deployments.extend(response.json())
        url = response.links.get('next', {}).get('url')
        params = {} 

    return deployments

此方法處理分頁，確保我們在指定的時間範圍內獲得所有部署。

計算 DORA 指標
讓我們看看我是如何計算部署頻率的：

def get_deployment_frequency(self, days=30):
    deployments = self.get_deployments(days)
    return len(deployments) / days

這個簡單的計算為我們提供了指定時間段內每天的平均部署數量。

變更準備時間
計算變更的提前期更為複雜。它需要將提交與其相應的部署相關聯：

def get_lead_time_for_changes(self, days=30):
    commits = self.get_commits(days)
    deployments = self.get_deployments(days)

    lead_times = []
    for commit in commits:
        commit_date = datetime.strptime(commit['commit']['author']['date'], '%Y-%m-%dT%H:%M:%SZ')
        for deployment in deployments:
            if deployment['sha'] == commit['sha']:
                deployment_date = datetime.strptime(deployment['created_at'], '%Y-%m-%dT%H:%M:%SZ')
                lead_time = (deployment_date - commit_date).total_seconds() / 3600  # in hours
                lead_times.append(lead_time)
                break

    return sum(lead_times) / len(lead_times) if lead_times else 0

此方法計算每次提交與其對應的部署之間的時間差。需要注意的是，並非所有提交都會導致部署，因此我們只考慮那些會導致部署的提交。最終結果是平均交貨時間（以小時為單位）。
我在這裡面臨的一項挑戰是將提交與部署相符。在某些情況下，部署可能包括多個提交，或提交可能不會立即部署。我必須根據可用數據做出假設，這可能需要針對不同的開發工作流程進行調整。

更改失敗率
確定變更失敗率需要分析每個部署的狀態：

def get_change_failure_rate(self, days=30):
    deployments = self.get_deployments(days)

    if not deployments:
        return 0

    total_deployments = len(deployments)
    failed_deployments = 0

    for deployment in deployments:
        status_url = deployment['statuses_url']
        status_response = requests.get(status_url, headers=self.headers)
        status_response.raise_for_status()
        statuses = status_response.json()

        if statuses and statuses[0]['state'] != 'success':
            failed_deployments += 1

    return failed_deployments / total_deployments if total_deployments > 0 else 0

此方法計算失敗的部署數量，並將其除以部署總數。這裡的挑戰是定義什麼構成「失敗」的部署。如果最近的狀態不是“成功”，我認為部署失敗。
值得注意的是，這種方法可能無法捕捉所有類型的故障，尤其是成功部署後發生的故障。在生產環境中，您可能希望與監控或事件管理系統集成，以實現更準確的故障檢測。

使用 Prometheus 公開指標
為了讓這些指標可供 Prometheus 抓取，我使用了 prometheus_client 函式庫：

from prometheus_client import start_http_server, Gauge

# In the main execution block
start_http_server(8000)

# Update metrics every 5 minutes
while True:
    dora.update_metrics()
    time.sleep(300)

這會在連接埠 8000 上啟動伺服器並每 5 分鐘更新一次指標。

常見陷阱
在這個專案中，我遇到了幾個挑戰：

• API 速率限制：GitHub 限制您可以發出的 API 請求數量。我必須實現分頁並注意更新指標的頻率。
• 令牌權限：確保您的 GitHub 令牌具有讀取部署和提交的必要權限。
• 數據解釋：確定什麼構成「部署」或「失敗」可能是主觀的。我必須根據現有數據做出假設。
• 恢復服務的時間：這個指標特別具有挑戰性，因為它通常需要來自事件管理系統的數據，而僅透過 GitHub 的 API 無法獲得這些數據。

結論
使用 Python 公開 DORA 指標是一次富有啟發性的經驗。它加深了我對 DevOps 實踐的理解，並提高了我使用 API 和資料處理的技能。
請記住，這些指標旨在指導改進，而不是作為擊敗團隊的棍子。明智地使用它們，在您的開發過程中培養持續改進的文化。
感謝您的閱讀❤

以上是我的 HNG 之旅。第六階段：利用 Python 公開 DORA 指標的詳細內容。更多資訊請關注PHP中文網其他相關文章！