Operationele verantwoordelijkheden¶
Iemand moet de hub beheren: incidenten, onderhoud, monitoring en standaardwijzigingen. In het managed model doet XMMS dit onder het contract. In het zelfbeheer-model doet het platformteam van de klant dit. Deze pagina somt op wat daarvoor nodig is, op basis van de scope van de managed service (Operating models).
- Managed (XMMS): gebruik dit om te zien wat de service dekt, om het contract ertegen te toetsen en om te weten wat bij de klant blijft (identity, security officer, goedkeuringen, Microsoft-supportplan, eigen workloads).
- Zelfbeheer: gebruik dit als checklist wanneer je het platform overneemt, en als definitie van je eigen service.
Checklist voor dag één (overdracht bij zelfbeheer)¶
De implementatie eindigt met een overdracht (Overdracht en rapportage). Gebruik de onderstaande tabel op dat moment.
| # | Actie | Waar |
|---|---|---|
| 1 | Laat platformalerts naar jouw team gaan. Stel de ontvangers in van beide action groups (general en die met de naam …-mgmtxpirit-…, die via de alert processing rules de landing zone-alerts ontvangt) |
<primary region>/foundation.auto.tfvars: monitor_action_group_general_email_receiver / _webhook_receiver, monitor_action_group_xpirit_email_receiver / _webhook_receiver |
| 2 | Stel het Defender for Cloud security contact in. De standaardwaarde in de code is CustomerSupport@Xebia.com |
postdeployment.auto.tfvars: security_contact_email |
| 3 | Bepaal hoe je alerting buiten kantooruren voor de hub inricht | hub_247_support (Monitoringregels) |
| 4 | Neem de eigendom over van de deployment-identiteiten (service principals in mcp.json) en hun credentials of federated credentials |
Entra ID; update-spn pipeline in de coderepository |
| 5 | Richt goedkeuringen in: branch protection op de configuratierepository, verplichte reviewers op de GitHub environment approval-required, en een Approve*-modus voor prod-runs |
Pipelines en workflows |
| 6 | Pin een codeversie die je hebt getest en plan hoe je updates oppakt | Versionering |
| 7 | Lees de Bekende problemen en controleer je entry pipelines op whatIf / mode |
Terugkerende verantwoordelijkheden¶
Technische support (incidenten en serviceaanvragen)¶
Voor de afhandelingsstappen, major incidents en het post-mortemsjabloon, zie Incidentbeheer en Post-mortems.
- Intake. Zorg voor één plek waar aanvragen en incidenten worden geregistreerd, bijvoorbeeld een ticketsysteem of een work item-board. De standaardwijzigingen in deze gids vormen je catalogus van serviceaanvragen.
- Ernstmodel (severity). Definieer ernstniveaus en reactietijden. De managed service gebruikte dit model; pas het aan op jouw behoeften:
| Ernst (severity) | Betekenis | Reactiedoel |
|---|---|---|
| 1 | Kritieke impact op het bedrijf, geen workaround | 30 minuten (alleen 24×7 met een standby-dienst; anders kantooruren) |
| 2 | Ernstige impact; delen van het platform niet beschikbaar of verminderd; er is een workaround | 2 uur (kantooruren) |
| 3 | Een functie is niet beschikbaar of werkt niet goed, geen directe impact op het bedrijf | 4 uur (kantooruren) |
- Post-mortem. Voer voor elk incident met ernst 1 binnen vijf werkdagen een root-cause-analyse uit en leg verbeteringen vast.
- Escalatie naar Microsoft. Je hebt een eigen Azure-supportplan nodig voor storingen in Azure-services.
Onderhoud¶
Zie de Onderhoudskalender.
| Taak | Hoe | Frequentie |
|---|---|---|
| Platformcode-updates (patches, minor versions) | Verhoog de code ref (Versionering), eerst canary | Per release |
| Container image en runners | container en infrastructure pipelines |
Bij elke code-update |
| Deployment SPN-secrets | update-spn pipeline, of gebruik federated credentials |
Vóór verloop |
| Spoke SPN-secrets | Geroteerd bij de eerste spoke-run na SPNSecretrotationPeriod dagen (Spoke wijzigen) |
Draai de spoke pipeline regelmatig |
| App Gateway-certificaten | Vernieuw in de App Gateway Key Vault en werk daarna key_vault_secret_id bij als je versies pint |
Vóór verloop |
| Policy-uitzonderingen | Controleer de expires_on-data |
Maandelijks |
| Drift-controle | Draai hub in Plan-modus. Elke wijziging die je niet hebt gecommit is drift: herstel die in code, of draai haar terug in Azure |
Wekelijks |
| Azure Advisor / Defender-aanbevelingen | Beoordeel ze en zet ze om in backlog-items | Maandelijks |
Servicemanagement¶
Zie Servicelevelbeheer en de Maandelijkse health check.
- Beschikbaarheid. De managed service streefde naar 99,0% maandelijkse beschikbaarheid van de hubcomponenten, exclusief gepland onderhoud, zonder enkele verstoring langer dan 20 minuten. Bepaal je eigen doel en meet het, bijvoorbeeld met Service Health- en Resource Health-alerts (AMBA) en firewall-/gateway-metrics.
- Kostenbeheer. De hub layers deployen geen budgetten. De voorbeeldconfiguratie bevat een custom policy definition
policy_definition_es_deploy_budget.json, die je kunt toewijzen (Policy assignments), of beheer budgetten in Cost Management. - Rapportage. Maandelijks: beschikbaarheid, aantallen incidenten per ernst, details van incidenten met ernst 1, en wijzigingen. Per kwartaal: trends, verbeteringen, kosten.
- Servicelevels. Hoe servicevensters, severities, beschikbaarheidsdoelen en rapportage samenhangen, staat in Governance. Wijzigingen worden ingedeeld als standard, normal of emergency (Wijzigingscategorieën).
Verdeling van verantwoordelijkheden: hub versus spoke¶
Uit het verantwoordelijkhedenmodel van de managed service (RACI). In het managed model is de kolom "platformteam" XMMS. In het zelfbeheer-model is het het eigen team van de klant.
| Gebied | Hub (platformteam) | Spoke canvas (workloadteam) |
|---|---|---|
| Netwerk: firewall, Virtual WAN/hub, gateways, DNS, App Gateway, Bastion, IP groups | Responsible & accountable | Informed |
| Inhoud van de firewall policy (welk verkeer is toegestaan) | Klant/security accountable; platformteam implementeert | Vraagt regels aan |
| IP-plan | Klant accountable | Accountable voor eigen ranges; platformteam implementeert in de spoke-JSON |
| Spoke VNet, NSG's, route tables | – | Accountable; platformteam implementeert via de spoke pipeline |
| Azure Policy-compliance (CIS, ISO 27001, MCSB) | Accountable op platformscope | Accountable voor compliance van eigen resources |
| Kostenbeheer en budgetten | Platform-subscriptions | Eigen subscription |
| Log Analytics, alerts, action groups | Platform | Eigen workspace en alerts |
| Defender for Cloud, Advisor | Platform-subscriptions | Eigen subscription |
| RBAC, PIM | Platform | Eigen groepen (via ProductTeamGroupNames) |
| Entra ID-gebruikers, -groepen, Conditional Access, SOC | Klant (identity-/securityteams) | Klant |
| Pipelines, repositories, runners | Platform | Spoke pipeline: platform; eigen app-pipelines: workloadteam |
| Management groups, subscription-inrichting, naamgevingsconventie | Platform | – |
| Spoke-tags | – | Workloadteam (spoke-JSON tags) |
| Policy initiatives op één enkele spoke | – | Workloadteam |
Een RASCI-matrix lezen¶
De onderstaande matrix gebruikt de uitgebreide RASCI-vorm. Kolommen zijn teams of rollen, rijen zijn activiteiten.
| Letter | Betekenis |
|---|---|
| R Responsible | Voert het werk uit |
| A Accountable | Is eigenaar van het resultaat en heeft het laatste woord. Maar één per activiteit. |
| S Supportive | Levert middelen voor het werk |
| C Consulted | Heeft informatie of expertise die nodig is. Tweerichtingscommunicatie. |
| I Informed | Wordt op de hoogte gehouden van voortgang of resultaat, normaal gesproken na een besluit |
Elke activiteit heeft precies één A en minstens één R. Om de tabellen kort te houden, impliceert een letter de zwakkere letters:
| Getoond | Betekent |
|---|---|
| A | Accountable, Responsible, Consulted en Informed, tenzij een kolom anders aangeeft |
| R | Responsible, Consulted en Informed |
| C | Consulted en Informed |
Heeft team 1 dus een A en team 2 een R, dan blijft team 1 accountable voor het geheel en heeft het het werk aan team 2 gedelegeerd, dat daarom ook geraadpleegd en geïnformeerd wordt. Een team met alleen een C moet bij wijzigingen worden betrokken en wordt ook geïnformeerd.
Een gangbare regel voor managed platforms
Alleen teams van de klantorganisatie zijn accountable. Het platformteam, als dat een externe partij is, is responsible. Zo blijven accountability, en daarmee de continuïteit van de service, binnen de klantorganisatie. In het zelfbeheermodel zijn beide van de klant, in twee verschillende teams of in één.
Verantwoordelijkhedenmatrix per platformgebied (voorbeeld)¶
Een uitgewerkt voorbeeld voor een platform met deze rollen. Pas de rollen aan je organisatie aan.
| Rol | Betekenis |
|---|---|
| Owner | De service owner van het platform bij de klant |
| Platform team | XMMS (managed) of de eigen platform-engineers van de klant (zelfbeheer) |
| Security | De security officer of het operationele securityteam |
| Architecture | Enterprise-architectuur |
| Workload | Het workload team (afnemer) |
Een streepje betekent: geen rol in deze activiteit.
Netwerk¶
| Activiteit | Owner | Platform team | Security | Architecture | Workload |
|---|---|---|---|---|---|
| IP-plan | A | R (wijst de adressen toe en beheert ze) | – | – | I (voor eigen ranges) |
| IP groups, virtual networks, subnets, baseline NSG-regels, Virtual WAN en hub, routering, VPN-gateways, private DNS-forwarding | A | R | – | C | – |
| NSG-regels voor de workload | – | R (via de spoke pipeline) | – | C | A |
| Azure Firewall-resource | A | R | C | C | – |
| Inhoud van de firewall policy | R | R | A | C | I |
| Application Gateway- en WAF-resource | A | R | C | C | – |
| WAF policy | C | R | A | – | I |
| Externe certificaten van de gateway | R | R | A | C | – |
| Internettoegang of internetpublicatie voor een workload toestaan | R | R | A | C | – |
Security en identiteit¶
| Activiteit | Owner | Platform team | Security | Architecture | Workload |
|---|---|---|---|---|---|
| SIEM (bijvoorbeeld Sentinel) inrichten | – | – | A | C | – |
| Securityalerts en Defender-aanbevelingen op workload-resources oplossen | C | – | C | C | A |
| Defender for Cloud inrichten | I | I | A | C | – |
| PIM-rollen en securitygroepen volgens het RBAC-model | R | – | A | C | – |
| Lidmaatschap van de groepen van de workload | – | – | – | – | A |
| Conditional access, gebruikers, enterprise applications | I | – | A | C | – |
| Service principals van spokes | R | – | A | C | – |
Governance en resources¶
| Activiteit | Owner | Platform team | Security | Architecture | Workload |
|---|---|---|---|---|---|
| Management groups en resourcebeheer | R | R | – | A | – |
| RBAC op platformscope | R | R | R | A | – |
| Infrastructuurpolicies | A | R | C | C | – |
| Securitypolicies (baseline, CIS, ISO 27001) | I | R | A | C | – |
| Security contact van de tenant | – | R | A | – | – |
| Kostenbeheer | A | R | – | – | R (eigen subscription) |
| Tenantlicenties en facturatie | A | – | – | C | – |
| Key Vault, Log Analytics, alerts, action groups, automation en storage van het platform | A | R | – | – | I (wanneer deployed als onderdeel van een spoke) |
| Self-hosted pipeline-agents | A | R | – | – | – |
Workloads en spokes¶
| Activiteit | Owner | Platform team | Security | Architecture | Workload |
|---|---|---|---|---|---|
| Spoke aanmaken, wijzigen en verwijderen | A | R | – | C | I |
| Technische monitoring en compliance van de spoke | A | R | – | C | I |
| Securitymonitoring en remediatie van de spoke | C | R | A | C | I |
| Azure-resources die de workload in zijn spoke heeft gedeployed: aanmaken, bijwerken, verwijderen, monitoren | C | – | – | C | A |
| Securitymonitoring van die resources | C | – | A | C | C |
| De bedrijfsoplossing en de monitoring ervan | C | – | C | C | A |
In een managed spoke (Servicetypen) is het platformteam R voor het aanmaken, deployen en technisch beheren van de workload-resources, samen met het workload team. Het workload team blijft A.