我的 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中文网其他相关文章！