Ga naar inhoud

Integration Platform: operations

Deze pagina is voor het platformteam (de integration platform engineers, en het MCP-platformteam waar het hen ondersteunt). Ze verzamelt de reguliere taken, schaling, monitoring, lifecycle en hoe je het platform uitbreidt. De runbooks van het MCP (Operations) gelden voor de hub en spokes. Deze pagina voegt toe wat specifiek is voor integratie.

Twee beheermodellen

Het platformteam is XMMS onder een managed-service-contract, of je eigen team (Beheermodellen). Contractspecifieke zaken zoals supporturen, standby en reactiedoelen komen uit je overeenkomst. Het referentieontwerp gaat uit van standby voor het platform (niet voor de integraties) vanaf de eerste live integratie. Controleer wat voor jou geldt.

Reguliere taken

Taak Frequentie Wat
Standaardwijzigingen afhandelen Per aanvraag Aanvragen en wijzigen
Configuratie-pull requests reviewen Per aanvraag Service Bus-checklist
De belasting van de shared services bewaken Continu (alerts), regelmatige review Messaging units van Service Bus, units van API Management, processing units van Event Hubs
Groei van dead-letter en gezondheid van verbindingen bewaken Continu Service Bus-metrics en -logs
Kosten en budgetten controleren Regelmatig Shared services hebben vaste basiskosten. Kostenalerts op berichtvolume en namespace-metrics.
Componenten actueel houden Regelmatig Zie Lifecycle
De DNS-forwardinglijst reviewen Als een capability wordt toegevoegd Private endpoint DNS

Schalen

Service Hoe
Service Bus Messaging units worden handmatig geschaald. Toegestane capacitywaarden in de referentiecode: 1, 2, 4, 8, 16. Schalen kan verbindingen kort resetten: plan het als wijziging en vertel het de workload teams. Verhoog de partities van een draaiende namespace niet zonder migratieplan.
API Management Handmatig. Verhoog het aantal scale units voor de shared service en rol hem opnieuw uit. Geen downtime voor de gateway of de developer portal.
Event Hubs (voorgesteld ontwerp) Premium processing units, 1 tot 16

Monitoring en alerts

Logging breidt de MCP-logging uit.

Waar Wat er is Opmerking
Spoke van het Integration Platform Alleen de alertregels van het MCP Voeg eigen regels toe waar nodig
Service Bus Azure Monitor-metrics en Log Analytics voor doorvoer, groei van dead-letter, gezondheid van verbindingen en diagnostiek
API Management Een Application Insights-resource gekoppeld aan de Log Analytics workspace van zijn spoke Het monitoringgedeelte van het decision record is nog open
Modules in workload-spokes Logs naar de spoke-workspace, alerts en action groups per module (Modules) Sommige modules vragen extra implementatie door het workload team

Action groups sturen notificaties naar het platformteam of naar workload-eigenaren. Alerts over de eigen logica van een integratie horen bij het workload team (Je workload beheren).

Nuttige controles:

  • Dead-letter queues die groeien op de queue van een workload: vertel het het workload team. Zij sturen opnieuw in met de operatorsgroep.
  • Throttling of connection resets op de namespace: kijk naar de messaging units.
  • API-fouten: Application Insights van de API Management-instance.

Lifecycle en patching

Het platformteam houdt de platformcomponenten, de componenten van het spoke canvas en de deployment-automatisering actueel. In een managed-servicemodel is dat de serviceprovider totdat je eigen team het overneemt. Platformcode komt in releases: zie Wat te doen als een nieuwe versie wordt gereleased. Pin de herbruikbare deployment-workflow en de modulerepository op een release en verzet de pin bewust (Integratieresources uitrollen).

Een grote wijziging die meerdere layers raakt (foundation, shared service, control plane) vraagt om gecoördineerde releases en een deployment in de juiste volgorde: shared service, spoke-extensie, daarna automatisering (Service Bus-automatisering).

Standby en incidenten

Het referentieontwerp laat het MCP-platformteam vanaf de eerste live integratie standby voor het platform bieden. De integraties zelf vallen buiten die standby. Incidentafhandeling volgt het MCP (Incidentmanagement).

Het platform uitbreiden

De repository van het control plane is per component georganiseerd, dus een nieuwe component (bijvoorbeeld API Management of DNS-automatisering) staat naast de bestaande en is los uitrolbaar.

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

Volg de bestaande conventies: namen in kleine letters met koppeltekens, configuratie in JSON-bestanden die recursief worden gevonden, toegang via groepen van de vorm workload, entiteit en rol. Een nieuwe shared service doorloopt eerst de beoordeling op architectuur, operations en security (Servicetypen), en een nieuwe spoke-extensie volgt de regels van Spoke-extensies.