Servicebeschreibung¶
Diese Seite beschreibt, was das Agentic Developer Portal bietet, was jedes Feature braucht, bevor es Daten zeigt, und wo der Service endet. Die Namen, Standardwerte und Zeitpläne sind die des Referenzdesigns. Deine Plattform kann abweichen. Frag dein Plattform-Team, welche Features in deiner Umgebung aktiviert sind.
Der Service in Kürze¶
| Aspekt | Beschreibung |
|---|---|
| Lieferung | Ein Portal pro Kundenumgebung (meist Nicht-Produktion und Produktion), deployt in den eigenen Azure-subscriptions des Kunden |
| Code-Basis | Eine gemeinsame Code-Basis und ein Container-Image für alle Kunden. Features werden per Konfiguration aktiviert, nicht durch kundenspezifischen Code. |
| Updates | Neue Versionen werden für alle Kunden veröffentlicht und Umgebung für Umgebung ausgerollt (Deployment und Umgebungen) |
| Daten | Alle Daten, die das Portal sammelt, verarbeitet und speichert, bleiben in den Azure-subscriptions des Kunden (Architektur) |
| Benutzer | Personen aus dem Entra-ID-Tenant des Kunden, die zu den erlaubten Gruppen gehören (Authentifizierung und Zugriff) |
| Kosten | Die Azure-Ressourcen des Portals laufen auf der Azure-Rechnung des Kunden. Features wie Cost Insights und KI-Agenten fügen Ressourcen und damit Kosten hinzu. |
Features¶
| Feature | Was der Benutzer sieht | Braucht | Seite |
|---|---|---|---|
| Workloads und Domänen | Explorer-Seiten für workloads und Domänen, Entity-Seiten mit Owner, Domäne, Abhängigkeiten und subscriptions | subscriptions mit tags für workload und Owner sowie Benutzer und Gruppen aus Entra ID | Catalog und Entity-Modell |
| Organisationsansicht | Eine Seite für Organisationen (Kunden) und ihre Domänen | Feature-Flag features.organisation |
Catalog und Entity-Modell |
| Cost Insights | Monatliche Kosten pro subscription, workload, Team und Domäne | Cost-Insights-Ressourcen und Kosten-Exporte (Cost-Insights-Einrichtung) | Insights |
| Network Insights | Blockierte Firewall-Anfragen, Application-Gateway-Zugriffe und WAF-Logs auf der workload-Seite | Azure-Firewall- und Application-Gateway-Diagnose in Log Analytics | Insights |
| Security Insights | Secure Score und Empfehlungen | Microsoft Defender for Cloud auf den subscriptions | Insights |
| Compliance Insights | Compliance-Matrix pro Regulatory-Standard | Mit Azure Policy zugewiesene Regulatory-Compliance-Initiativen | Insights |
| KI-Agenten | Eine Chat-Seite mit den aktivierten Agenten | Ein Azure-AI-Foundry-Konto und Agent-Konfiguration (KI-Einrichtung) | KI-Agenten |
| MCP-Server und Inspector | Ein Server für Editoren und Agenten und eine Seite, um seine Tools auszuprobieren | Immer vorhanden. Zugriff per Token oder Anmeldung | MCP-Server |
| Module Registry | Liste, Detail und Download von Terraform-Modulen | Feature-Flag features.moduleRegistry und eine Registry-API |
Module Registry |
| Dokumentation (TechDocs) | Dokumentationsseiten von Services, deren Repository eine mkdocs.yml enthält |
Siehe den Hinweis unten | |
| Software-Templates (Create) | Templates für Standardänderungen | Feature-Flag features.scaffolder, nur in der Umgebung des Anbieters |
Konfiguration |
Features unterscheiden sich pro Umgebung
Die Lieferdokumente der Quelle besagen, dass jeder Kunde den vollen Funktionsumfang der deployten Version bekommt. Der Code aktiviert jedoch mehrere Features per Konfiguration (Feature-Flags, eine angebundene Kosten-Datenbank, Agent-Einstellungen). Lies die Tabelle als „was es gibt“ und frag dein Plattform-Team „was in meiner Umgebung aktiv ist“. Beschreibe deinen Benutzern nur, was tatsächlich deployt ist.
TechDocs
Das TechDocs-Backend ist Teil des Portals, und das Liefermaterial nennt TechDocs unter den Self-Service- Fähigkeiten. Ein Feature-Flag im Code schaltet den Dokumentationseintrag nur für die eigene Umgebung des Anbieters und für die lokale Entwicklung ein. Kläre mit deinem Plattform-Team, ob TechDocs für dich aktiviert ist.
Daten, die das Portal verarbeitet¶
| Daten | Quelle | Gespeichert in |
|---|---|---|
| Catalog-Entities, Beziehungen, Agent-Konversationen, Security- und Compliance-Ergebnisse, Netzwerk-Inventar | Azure Resource Graph, Azure DevOps, Microsoft Graph (Entra ID), das Portal selbst | Der PostgreSQL-Datenbank des Portals in der Kundenumgebung |
| Kostendaten | Azure-Cost-Management-Exporte, von Azure Data Factory eingelesen | Storage Accounts und einer Azure-SQL-Datenbank in der Kundenumgebung |
| Firewall- und WAF-Logzeilen | Log-Analytics-workspaces des Kunden | Bei Bedarf abgefragt, nicht dauerhaft kopiert |
| Secrets und Schlüssel des Portals | Von Terraform und der Deployment-pipeline erstellt | Dem Key Vault der Umgebung |
Das Modell, das Agent-Prompts beantwortet, wird aus dem eigenen Azure-AI-Foundry-Konto des Kunden bereitgestellt. Der Konversationsverlauf wird in der PostgreSQL-Datenbank des Portals gespeichert, nicht in Foundry.
Was der Service nicht tut¶
- Keine Änderungen an Azure-Ressourcen. Das Portal liest. Agenten und die MCP-Tools bereiten pull requests in Repositories vor. Sie mergen sie nicht.
- Kein kundenspezifischer Code. Eine Anfrage, die ein Feature für einen einzelnen Kunden braucht, wird als separate Arbeit behandelt und vom Solution Lead des Anbieters entschieden. Sie ändert die gemeinsame Code-Basis nicht für einen Kunden.
- Keine Daten außerhalb der Kundenumgebung. Der Anbieter kopiert keine Kundendaten in seine eigene Umgebung.
- Keine Abdeckung außerhalb des lesbaren Scopes. Das Portal zeigt nur subscriptions, die seine Managed Identity lesen kann. Eine subscription außerhalb der gewährten management group ist nicht sichtbar.
- Keine Vertragsbedingungen auf diesen Seiten. Support-Zeiten, Reaktionszeiten und Service Levels richten sich nach deiner Vereinbarung. Das Liefermaterial der Quelle vermerkt, dass die Formulierung der operativen Garantie und der Offboarding-Regelung noch zu bestätigen ist. Diese Seiten nennen keines von beidem.
Verantwortlichkeiten¶
| Plattform-Team | Workload-Team | |
|---|---|---|
| Das Portal deployen, aktualisieren und überwachen | Ja | |
| Dem Portal Lesezugriff in Azure, Entra ID und Repositories geben | Ja (Administratoren des Kunden genehmigen) | |
| Die Datenquellen gesund halten (Defender for Cloud, Policy-Zuweisungen, Diagnose, Kosten-Exporte) | Ja, für Teile im Besitz der Plattform | Für Ressourcen im Besitz des workloads |
| subscriptions mit workload und Owner taggen | Ja, für spokes, die die Plattform deployt | Für tags, die die Plattform nicht setzt |
| Workloads im Catalog besitzen, auf Empfehlungen und Policy-Findings reagieren | Ja | |
| Von Agenten vorbereitete pull requests prüfen | Ja, für die Plattform-Konfiguration | Ja, für Repositories, die das Team besitzt |
Die allgemeine Aufteilung steht unter Verantwortlichkeiten.