介绍
对于第 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 和数据处理的技能。
请记住,这些指标旨在指导改进,而不是作为击败团队的棍子。明智地使用它们来培养开发过程中持续改进的文化。
感谢您的阅读❤
本站部分资源来源于网络,仅限用于学习和研究目的,请勿用于其他用途。
如有侵权请发送邮件至1943759704@qq.com删除
码农资源网 » 我的 HNG 之旅第六阶段:利用 Python 公开 DORA 指标