나의 HNG 여행. 6단계: Python을 활용하여 DORA 지표 노출

소개

6단계에서는 DORA(DevOps Research)를 노출하는 임무를 맡았으며 저는 최근 Python을 사용하여 DORA(DevOps Research and Assessment) 측정항목을 노출하는 프로젝트에 착수했습니다. 이 경험을 통해 DevOps 관행과 복잡성에 대한 귀중한 교훈을 얻었습니다. 이 기사에서는 프로세스를 안내하고, 각 지표의 의미를 설명하고, 주의해야 할 몇 가지 일반적인 함정을 강조하겠습니다.

DORA 지표란 무엇입니까?
코드를 살펴보기 전에 DORA 측정항목이 무엇인지 간략하게 살펴보겠습니다.

• 배포 빈도: 조직이 프로덕션 환경으로 성공적으로 릴리스하는 빈도
• 변경 리드 타임: 제작에 투입되는 데 걸리는 시간.
• 변경 실패율: 프로덕션 실패를 초래하는 배포 비율입니다.
• 서비스 복원 시간: 생산 장애를 복구하는 데 걸리는 시간

이러한 지표는 팀이 소프트웨어 제공 성과를 측정하고 개선이 필요한 영역을 식별하는 데 도움이 됩니다.

시작하기
이러한 지표를 공개하려면 다음이 필요합니다.

• 파이썬 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 여행. 6단계: Python을 활용하여 DORA 지표 노출의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!