Zuordnung der täglichen DevOps-Arbeit zu agentischen Möglichkeiten

Abgeschlossen

Sie verfügen jetzt über eine funktionierende Definition von agentischen DevOps und verstehen, was Agents von der Automatisierung trennt. Die nächste Frage ist praktisch: Wo in Ihrer täglichen Arbeit spielt agentische Unterstützung tatsächlich eine Rolle?

Nicht jede DevOps-Aufgabe ist ein guter Kandidat. Die Aufgaben, die den größten Wert zurückgeben, teilen in der Regel ein konsistentes Profil:

• Sie sind häufig.
• Sie erfordern das Abrufen von Kontext aus mehreren Quellen.
• Sie erzeugen strukturierte Ausgaben, die in vorhandene Workflows eingespeist werden.
• Und sie verbrauchen unverhältnismäßig viel Zeit im Verhältnis zu der Entscheidung, die sie ermöglichen.

Durch das Abgleichen Ihrer Arbeit mit diesem Profil erhalten Sie einen priorisierten Ausgangspunkt.

Den DevOps-Lebenszyklus zu agentischen Möglichkeiten abbilden.

Der DevOps-Lebenszyklus (manchmal auch als Software Development Lifecycle oder SDLC bezeichnet) bietet Ihnen einen natürlichen Frame für diese Zuordnung. Gehen Sie durch jede Hauptphase, und Sie werden feststellen, dass sich die wertvollsten agentischen Möglichkeiten um Punkte gruppieren, an denen Informationssynthese und Urteilsvermögen die primären Engpässe sind. Häufig ist es keine technische Ausführung.

Planen und Nachverfolgen der Arbeit

Die Arbeitsaufgabenverwaltung sieht einfach auf der Oberfläche aus, aber es kumuliert erheblichen Aufwand: Übersetzen von Anforderungsdokumenten in Geschichten, Kategorisieren von Elementen mit den richtigen Bereichspfaden, Verknüpfen verwandter Arbeiten, Schätzen des Aufwands von der Beschreibung allein und Beibehalten von Beschreibungen, während sich das Design weiterentwickelt.

Azure DevOps Boards enthält jetzt KI-generierte Zusammenfassungen für Arbeitsaufgaben und Sprints und hilft Teams dabei, den Status des Backlogs zu verstehen, ohne jedes Element vollständig zu lesen. GitHub Copilot kann Arbeitselementbeschreibungen aus Spezifikationsdateien generieren, den PR-Verlauf analysieren, zugehörige Backlogelemente anzeigen und eingehende Fehler durch Abgleich mit bekannten Mustern selektieren.

Für Plattformteams mit hohem Arbeitsvolumen, die Backlogs über mehrere Anwendungsteams hinweg verwalten, reduziert diese Unterstützung auf Phasenebene den Planungsaufwand, der regelmäßig Sprintverpflichtungen verzögert.

Code und Überprüfung

Hier wird der Wert von GitHub Copilot am besten verstanden – Inlinevorschläge, Codegenerierung aus natürlicher Sprache und Testgerüst. Bei erfahrenen DevOps-Ingenieuren unterscheiden sich jedoch in dieser Phase die Anwendungsfälle mit dem höchsten Wert von denen der Anwendungsentwickler.

Die Erstellung von Infrastruktur-as-Code (IaC) ist ein primäres Ziel. Diese Aufgaben sind kontextreich und wiederholend. GitHub Copilot geht gut mit ihnen um, während Sie die Ausgabe überprüfen und genehmigen. Beispiele sind das Generieren von Bicep Vorlagen aus einer Ressourcenarchitektur, das Konvertieren von ARM-Vorlagen in Bicep und das Aktualisieren vorhandener Vorlagen, um neue Benennungskonventionen oder Richtlinienanforderungen widerzuspiegeln.

Die Dockerfile-Erstellung folgt demselben Muster. Copilot generiert eine Basisimageauswahl, Layer-Sortierung und Buildstufenstruktur aus einer einfachen Sprachbeschreibung der Laufzeitanforderungen Ihrer App. Sie überprüfen und passen an, bevor Sie ein Commit ausführen.

-Authoring der YAML-Pipeline von Azure DevOps (oder GitHub Actions) ist ebenfalls gut geeignet. Eine mehrstufigen Pipeline in natürlicher Sprache zu beschreiben und Copilot den anfänglichen YAML-Code erstellen zu lassen, ist schneller als die Referenzdokumentation für jede Aufgabe und die Auslösersyntax nachzuschlagen. Es ist besonders hilfreich, wenn Sie eine vorhandene Pipeline an eine neue Umgebung anpassen oder eine neue Bereitstellungsphase hinzufügen. Oder das Migrieren von Pipelines über DevOps-Plattformen hinweg wird einfacher.

Die Vorbereitung der Codeüberprüfung ist ein weiterer starker Kandidat. Vor einer PR-Überprüfung können GitHub Copilot eine strukturierte Beschreibung der Änderungen generieren, Dateien hervorheben, die sicherheitsrelevante Änderungen enthalten, und Flagmuster, die historisch mit Produktionsvorfällen in Ihrem Repository korrelieren. Dieses Vorgehen reduziert die kognitive Belastung für den Prüfer, ohne dessen Urteilsvermögen zu verdrängen.

Produzieren und testen

Pipelinefehler sind ein hochfrequentes Ereignis mit hoher Ablenkung in jedem DevOps-Team. Das Diagnostizieren eines Fehlers umfasst in der Regel das Lesen von Buildprotokollen über mehrere Phasen, das Überprüfen von Konfigurationsabweichungen zwischen Umgebungen und den Quervergleich von aktuellen Abhängigkeitsänderungen – alles, während eine Person auf Ergebnisse wartet.

GitHub Copilot in Azure DevOps kann Pipelineausführungsfehler zusammenfassen, Diagnoseschritte basierend auf dem Fehlermuster vorschlagen und dabei helfen, den Kontext zu rekonstruieren, der zu dem Fehler führte. Bei Testfehlern können der ungewöhnliche Testverlauf korreliert, kürzliche Änderungen am betroffenen Codepfad dargestellt und hypothesengesteuerte Untersuchungsnotizen generiert werden.

Der Azure DevOps MCP-Server erweitert dies, indem er Copilot strukturierten Echtzeitzugriff auf den Buildverlauf, die Pipelinedefinitionen und die Ausführungsergebnisse Ihres Projekts ermöglicht, sodass Abfragen in natürlicher Sprache wie "Welche Pipelines sind in den letzten zwei Wochen am häufigsten fehlgeschlagen und was die häufigsten Fehlertypen sind?" gestellt werden können.

Freigeben und Bereitstellen

Das Änderungsrisiko ist der Ort, an dem DevOps-Techniker erhebliche beurteilungsintensive Anstrengungen unternehmen. Bei der Bewertung, ob eine Änderung sicher bereitgestellt werden kann, muss der Umfang der Codeänderungen mit der Kritizität des Bereitstellungsziels, der aktuellen Vorfallhistorie und allen offenen Ausnahmen von Richtlinien korreliert werden.

Der Bereitstellungs-Agent von Azure Copilot unterstützt die Bereitstellung von Azure-Ressourcen durch natürliche Sprache, indem er Bicep- oder Terraform-Konfigurationen erstellt, die auf den Best Practices des Azure Well-Architected Frameworks basieren und vor der Ausführung zur Überprüfung bereitgestellt werden.

Dies ersetzt keine Änderungsbeiratsprozesse – es beschleunigt die Grundlagen, von denen diese Prozesse abhängen.

Ein weiterer Bereich mit hohem Wert ist die IaC-Driftanalyse. Das Ausführen von Bicep what-if oder Terraform plan gilt als Standardpraxis. Die Interpretation dieser Ergebnisse über eine große Menge an Ressourcen hinweg und die Entscheidung, welche Abweichungen akzeptabel sind und welche ein Compliancerisiko darstellen, ist jedoch zeitaufwändig. Agenten können Driftanalyse-Ergebnisse mit Richtliniendokumentationen synthetisieren und die Elemente hervorheben, die menschlicher Entscheidungen bedürfen.

Betreiben und Überwachen

Azure Copilot-Agents für Observability, Resilienz und Problembehandlung zielen direkt auf die operative Hälfte der DevOps-Schleife. Für Teams, die Azure-Workloads erstellen und ausführen, reduzieren diese Agents die Zeit zwischen der Warnmeldung und dem Identifizieren der Ursache.

Der Observability-Agent ruft Metriken, Protokolle und Abhängigkeitszuordnungen ab, um eine Synthese davon bereitzustellen, was vor einem Vorfall geändert wurde. Der Problembehandlungs-Agent führt die Diagnoseschritte für allgemeine Azure Ressourcenprobleme durch. Der Resilienz-Agent (Azure SRE-Agent) bewertet Ihre bereitgestellten Ressourcen für Zonenredundanzlücken, fehlende Sicherungsrichtlinien und Wiederherstellungskonfigurationsprobleme und zeigt dann Handlungsempfehlungen an.

Für Plattform-Engineering-Teams ist der Optimierungs-Agent besonders nützlich: Er vergleicht Ihre Ressourcennutzungsdaten mit den Azure Advisor Empfehlungen und generiert priorisierte Aktionslisten, die auf die Kosten- und Zuverlässigkeitsziele Ihres Teams abgestimmt sind.

Anwenden eines Prioritätsframeworks

Mit Möglichkeiten über den gesamten DevOps-Lebenszyklus hinweg benötigen Sie eine Möglichkeit, zu entscheiden, wo sie beginnen sollen. Anwenden von drei Filtern:

• Häufigkeit: Wie oft tritt dieser Vorgang auf? Tägliche Vorgänge erzielen mehr akkumulierte Zeitersparnis als monatliche Vorgänge.
• Kontextbreite: Wie viele Quellen benötigen Sie bei dieser Aufgabe? Aufgaben, für die der Kontext von fünf Stellen gleichzeitig berücksichtigt werden muss, sind ideale Kandidaten für die Agents.
• Entscheidungsrückkehr: Wie einfach können Sie das Ergebnis rückgängig machen? Umkehrbare Aufgaben mit geringem Auswirkungsradius sind bessere Kandidaten für die Erstbereitstellung als Produktionsvorgänge mit hohem Schadenpotenzial.

Die Selektierung der Pipelinefehler wird in allen drei Szenarien hoch bewertet. Die Autorisierung der Bereitstellung für die Produktion weist eine niedrige Umkehrbarkeit auf und sollte unabhängig von der Ausgereiftheit der agentischen Verfahren immer in menschlicher Verantwortung bleiben.

Tipp

Beginnen Sie mit Aufgaben in den Phasen Build, Test und Codeüberprüfung . Sie sind hochfrequent, risikoarm und bieten Ihnen konkrete Erfahrungen mit dem Agentenverhalten, bevor Sie Agenten auf Produktionsvorgänge anwenden.

Diese Priorisierung informiert direkt, wie Sie Autonomiegrenzen festlegen – das Thema der nächsten Einheit.