Zum Inhalt

Integration Platform: Betrieb

Diese Seite richtet sich an das Plattform-Team (die Integration Platform Engineers und das MCP-Plattform-Team, wo es sie unterstützt). Sie sammelt die regelmäßigen Aufgaben, Skalierung, Monitoring, Lifecycle und wie du die Plattform erweiterst. Die Runbooks der MCP (Betrieb) gelten für hub und spokes. Diese Seite ergänzt, was spezifisch für Integration ist.

Zwei Betriebsmodelle

Das Plattform-Team ist XMMS im Rahmen eines Managed-Service-Vertrags oder dein eigenes Team (Betriebsmodelle). Vertragsspezifische Punkte wie support-Zeiten, Standby und Reaktionsziele stammen aus deiner Vereinbarung. Das Referenzdesign geht von Standby für die Plattform (nicht für die Integrationen) ab der ersten produktiven Integration aus. Prüfe, was für dich gilt.

Regelmäßige Aufgaben

Aufgabe Häufigkeit Was
Standardänderungen bearbeiten Pro Anfrage Anfragen und Änderungen
pull requests für Konfiguration prüfen Pro Anfrage Service-Bus-Checkliste
Last auf den Shared Services beobachten Laufend (Alerts), regelmäßiges Review Messaging Units von Service Bus, Units von API Management, Processing Units von Event Hubs
Dead-Letter-Wachstum und Verbindungszustand beobachten Laufend Service-Bus-Metriken und -Logs
Kosten und Budgets prüfen Regelmäßig Shared Services haben feste Basiskosten. Kosten-Alerts auf Nachrichtenvolumen und Namespace-Metriken.
Komponenten aktuell halten Regelmäßig Siehe Lifecycle
Die DNS-Forwarding-Liste prüfen Wenn eine Capability hinzukommt Private endpoint DNS

Skalierung

Service Wie
Service Bus Messaging Units werden manuell skaliert. Erlaubte Capacity-Werte im Referenzcode: 1, 2, 4, 8, 16. Skalieren kann Verbindungen kurz zurücksetzen: Plane es als Änderung und sag den Workload-Teams Bescheid. Erhöhe die Partitionen eines laufenden Namespace nicht ohne Migrationsplan.
API Management Manuell. Erhöhe die Anzahl der Scale Units für den Shared Service und deploye ihn neu. Keine Downtime für Gateway oder Developer Portal.
Event Hubs (vorgeschlagenes Design) Premium Processing Units, 1 bis 16

Monitoring und Alerts

Das Logging erweitert das MCP-Logging.

Wo Was es gibt Hinweis
Spoke der Integration Platform Nur die Alert-Regeln der MCP Ergänze eigene Regeln, wenn nötig
Service Bus Azure-Monitor-Metriken und Log Analytics für Durchsatz, Dead-Letter-Wachstum, Verbindungszustand und Diagnose
API Management Eine Application-Insights-Ressource, verbunden mit dem Log Analytics workspace ihres spokes Der Monitoring-Abschnitt des Decision Records ist noch offen
Modules in Workload-spokes Logs in den spoke-workspace, Alerts und Action Groups pro module (Modules) Manche modules brauchen zusätzliche Implementierung durch das Workload-Team

Action Groups leiten Benachrichtigungen an das Plattform-Team oder an Workload-Owner. Alerts zur eigenen Logik einer Integration gehören dem Workload-Team (Deinen Workload betreiben).

Nützliche Prüfungen:

  • Dead-Letter-Queues wachsen auf der Queue eines Workloads: Sag dem Workload-Team Bescheid. Es sendet erneut mit der Operators-Gruppe.
  • Throttling oder Connection Resets auf dem Namespace: Sieh dir die Messaging Units an.
  • API-Fehler: Application Insights der API-Management-Instanz.

Lifecycle und Patching

Das Plattform-Team hält die Plattform-Komponenten, die Komponenten des spoke canvas und die Deployment-Automatisierung aktuell. In einem Managed-Service-Modell ist das der Service Provider, bis dein eigenes Team übernimmt. Plattform-Code kommt in releases: siehe Was zu tun ist, wenn eine neue Version veröffentlicht wird. Fixiere den wiederverwendbaren Deployment-Workflow und das module-Repository auf ein release und verschiebe den pin bewusst (Integrationsressourcen deployen).

Eine größere Änderung, die mehrere layers berührt (Foundation, Shared Service, Control Plane), braucht koordinierte releases und ein Deployment in der richtigen Reihenfolge: Shared Service, spoke extension, dann Automatisierung (Service-Bus-Automatisierung).

Standby und Incidents

Das Referenzdesign lässt das MCP-Plattform-Team ab der ersten produktiven Integration Standby für die Plattform leisten. Die Integrationen selbst gehören nicht zum Umfang dieses Standbys. Die Incident-Behandlung folgt der MCP (Incident Management).

Die Plattform erweitern

Das Repository der Control Plane ist nach Komponenten organisiert, sodass eine neue Komponente (zum Beispiel API Management oder DNS-Automatisierung) neben der bestehenden liegt und für sich deploybar ist.

infra/
  service-bus/            existing component
    main.tf, variables.tf, outputs.tf, providers.tf
    modules/entities/     queues, topics, access
  <new-component>/        add main.tf, variables.tf, outputs.tf, modules/
docs/
  <new-component>.md      one documentation page per component

Folge den bestehenden Konventionen: Namen in Kleinbuchstaben mit Bindestrichen, Konfiguration in JSON-Dateien, die rekursiv gefunden werden, Zugriff über Gruppen der Form Workload, Entität und Rolle. Ein neuer Shared Service durchläuft zuerst die Bewertung von Architektur, Betrieb und Sicherheit (Servicetypen), und eine neue spoke extension folgt den Regeln von Spoke extensions.