私のHNGの旅。ステージ 6: Python を活用して DORA メトリクスを公開する

導入

ステージ 6 では、DORA (DevOps Research) を公開する任務を負っていました。最近、Python を使用して DORA (DevOps Research and Assessment) メトリクスを公開するプロジェクトに着手しました。この経験は、DevOps の実践とその複雑さについての貴重な教訓を私に教えてくれました。この記事では、API の操作手順を説明し、各指標の意味を説明し、注意すべきいくつかの一般的な落とし穴について説明します。

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 からデータを取得しています
最も困難な点の 1 つは、必要なデータを 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

この単純な計算により、指定された期間における 1 日あたりの平均デプロイメント数が得られます。

変更のリードタイム
変更のリードタイムの​​計算はさらに複雑でした。コミットを対応するデプロイメントと相関させる必要がありました:

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

このメソッドは、各コミットとそれに対応するデプロイメントの間の時間差を計算します。すべてのコミットがデプロイメントにつながるわけではないため、デプロイメントにつながるコミットのみを考慮することに注意することが重要です。最終結果は、時間単位の平均リードタイムです。
ここで私が直面した課題の 1 つは、コミットをデプロイメントに一致させることでした。場合によっては、デプロイメントに複数のコミットが含まれる場合や、コミットがすぐにデプロイされない場合があります。入手可能なデータに基づいて仮説を立てる必要があったため、さまざまな開発ワークフローに合わせて調整が必要になる可能性があります。

失敗率の変更
変更失敗率を決定するには、各展開のステータスを分析する必要がありました:

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の旅。ステージ 6: Python を活用して DORA メトリクスを公開するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。