Meine HNG-Reise. Stufe sechs: Nutzung von Python zur Offenlegung von DORA-Metriken

Einführung

Für Stufe 6 wurden wir mit der Offenlegung von DORA-Metriken (DevOps Research) beauftragt, und ich habe kürzlich ein Projekt gestartet, um DORA-Metriken (DevOps Research and Assessment) mithilfe von Python offenzulegen. Diese Erfahrung brachte mir wertvolle Lektionen über DevOps-Praktiken und die Feinheiten von In diesem Artikel werde ich Sie durch den Prozess führen, erklären, was die einzelnen Metriken bedeuten, und einige häufige Fallstricke hervorheben, auf die Sie achten sollten.

Was sind DORA-Metriken?
Bevor wir uns mit dem Code befassen, besprechen wir kurz, was DORA-Metriken sind:

• Bereitstellungshäufigkeit: Wie oft eine Organisation erfolgreich für die Produktion freigibt.
• Vorlaufzeit für Änderungen: Die Zeit, die ein Commit benötigt, um in die Produktion zu gelangen.
• Änderungsfehlerrate: Der Prozentsatz der Bereitstellungen, die einen Fehler in der Produktion verursachen.
• Zeit bis zur Wiederherstellung des Dienstes: Wie lange dauert die Wiederherstellung nach einem Produktionsausfall.

Diese Metriken helfen Teams, ihre Softwarebereitstellungsleistung zu messen und Bereiche mit Verbesserungspotenzial zu identifizieren.

Erste Schritte
Um mit der Offenlegung dieser Metriken zu beginnen, benötigen Sie:

• Python 3.7 oder höher
• Ein GitHub-Konto und ein persönliches Zugriffstoken
• Grundkenntnisse der GitHub-API

Installieren Sie zunächst die erforderlichen Bibliotheken:

pip install requests prometheus_client

Die Codestruktur
Ich habe mein Python-Skript als Klasse namens DORAMetrics strukturiert. Hier ist eine vereinfachte Version der Initialisierung:

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)')

Dieses Setup ermöglicht es uns, mit der GitHub-API zu interagieren und Prometheus-Metriken für jede DORA-Metrik zu erstellen.

Daten von GitHub abrufen
Eine der größten Herausforderungen bestand darin, die erforderlichen Daten von GitHub abzurufen. So habe ich Bereitstellungen abgerufen:

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

Diese Methode übernimmt die Paginierung und stellt sicher, dass wir alle Bereitstellungen innerhalb des angegebenen Zeitrahmens erhalten.

Berechnung der DORA-Metriken
Schauen wir uns an, wie ich die Bereitstellungshäufigkeit berechnet habe:

def get_deployment_frequency(self, days=30):
    deployments = self.get_deployments(days)
    return len(deployments) / days

Diese einfache Berechnung gibt uns die durchschnittliche Anzahl der Einsätze pro Tag über den angegebenen Zeitraum.

Vorlaufzeit für Änderungen
Die Berechnung der Vorlaufzeit für Änderungen war komplexer. Es war erforderlich, Commits mit ihren entsprechenden Bereitstellungen zu korrelieren:

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

Diese Methode berechnet den Zeitunterschied zwischen jedem Commit und der entsprechenden Bereitstellung. Es ist wichtig zu beachten, dass möglicherweise nicht alle Commits zu einer Bereitstellung führen. Daher berücksichtigen wir nur diejenigen, bei denen dies der Fall ist. Das Endergebnis ist die durchschnittliche Durchlaufzeit in Stunden.
Eine Herausforderung, mit der ich hier konfrontiert war, bestand darin, Commits den Bereitstellungen zuzuordnen. In einigen Fällen kann eine Bereitstellung mehrere Commits umfassen oder ein Commit wird möglicherweise nicht sofort bereitgestellt. Ich musste auf der Grundlage der verfügbaren Daten Annahmen treffen, die möglicherweise an unterschiedliche Entwicklungsabläufe angepasst werden mussten.

Fehlerrate ändern
Zur Bestimmung der Änderungsfehlerrate ist eine Analyse des Status jeder Bereitstellung erforderlich:

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

Diese Methode zählt die Anzahl der fehlgeschlagenen Bereitstellungen und dividiert sie durch die Gesamtzahl der Bereitstellungen. Die Herausforderung bestand hier darin, zu definieren, was eine „fehlgeschlagene“ Bereitstellung darstellt. Ich habe eine Bereitstellung als fehlgeschlagen angesehen, wenn ihr letzter Status nicht „Erfolgreich“ war.
Es ist zu beachten, dass dieser Ansatz möglicherweise nicht alle Arten von Fehlern erfasst, insbesondere solche, die nach einer erfolgreichen Bereitstellung auftreten. In einer Produktionsumgebung möchten Sie möglicherweise eine Integration in Ihr Überwachungs- oder Incident-Management-System für eine genauere Fehlererkennung.

Metriken mit Prometheus offenlegen
Um diese Metriken für Prometheus zum Scrapen verfügbar zu machen, habe ich die prometheus_client-Bibliothek verwendet:

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)

Dadurch wird ein Server auf Port 8000 gestartet und die Metriken werden alle 5 Minuten aktualisiert.

Häufige Fallstricke
Während dieses Projekts bin ich auf mehrere Herausforderungen gestoßen:

• API-Ratenbegrenzung: GitHub begrenzt die Anzahl der API-Anfragen, die Sie stellen können. Ich musste die Paginierung implementieren und darauf achten, wie oft ich die Messwerte aktualisiere.
• Token-Berechtigungen: Stellen Sie sicher, dass Ihr GitHub-Token über die erforderlichen Berechtigungen zum Lesen von Bereitstellungen und Commits verfügt.
• Dateninterpretation: Die Bestimmung, was eine „Bereitstellung“ oder einen „Fehler“ darstellt, kann subjektiv sein. Ich musste auf der Grundlage der verfügbaren Daten Annahmen treffen.
• Zeit bis zur Wiederherstellung des Dienstes: Diese Metrik war eine besondere Herausforderung, da sie normalerweise Daten aus einem Vorfallmanagementsystem erfordert, die nicht allein über die GitHub-API verfügbar sind.

Fazit
Das Offenlegen von DORA-Metriken mithilfe von Python war eine aufschlussreiche Erfahrung. Es vertiefte mein Verständnis der DevOps-Praktiken und verbesserte meine Fähigkeiten im Umgang mit APIs und Datenverarbeitung.
Denken Sie daran, dass diese Kennzahlen als Leitfaden für Verbesserungen gedacht sind und nicht als Maßstab dienen, mit dem man Teams schlagen kann. Setzen Sie sie mit Bedacht ein, um eine Kultur der kontinuierlichen Verbesserung in Ihrem Entwicklungsprozess zu fördern.
Vielen Dank fürs Lesen ❤

Das obige ist der detaillierte Inhalt vonMeine HNG-Reise. Stufe sechs: Nutzung von Python zur Offenlegung von DORA-Metriken. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!