介绍
对于第 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
此方法处理分页，确保我们在指定的时间范围内获得所有部署。
立即学习“Python免费学习笔记（深入）”；
计算 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 和数据处理的技能。
请记住，这些指标旨在指导改进，而不是作为击败团队的棍子。明智地使用它们来培养开发过程中持续改进的文化。
感谢您的阅读❤
