Vendita di abbonamenti

Articolo
2025-05-04

La vendita di sottoscrizioni offre un meccanismo di piattaforma per l'emissione programmatica di sottoscrizioni ai team delle applicazioni che devono distribuire attività. Il diagramma seguente mostra dove la vendita di abbonamenti si inserisce nei cicli di vita della piattaforma e dei processi di carico di lavoro.

La distribuzione automatica delle sottoscrizioni si basa sul concetto di democratizzazione delle sottoscrizioni e la applica alle zone di destinazione dell'applicazione. Con la democratizzazione delle sottoscrizioni, le sottoscrizioni, non i gruppi di risorse, sono le unità principali di gestione e scalabilità del carico di lavoro. Per altre informazioni, vedere:

Perché la distribuzione automatica di abbonamenti?

La distribuzione automatica delle sottoscrizioni offre diversi vantaggi alle organizzazioni che devono distribuire i carichi di lavoro in Azure. Standardizza e automatizza il processo di richiesta, distribuzione e governance delle sottoscrizioni per le zone di destinazione dell'applicazione. La vendita di sottoscrizioni semplifica il processo di creazione della sottoscrizione e la inserisce nella governance dell'organizzazione, affinché i team delle app possano concentrarsi meglio sulla distribuzione dei carichi di lavoro con maggiore sicurezza ed efficienza.

Processo semplificato: Il sistema di gestione delle sottoscrizioni offre una porta d'ingresso ufficiale per i team di sviluppo delle applicazioni per richiedere le sottoscrizioni, eliminando la necessità di gestire autonomamente il processo di sottoscrizione.
Velocità migliorata: I team delle applicazioni possono accedere alle zone di destinazione delle applicazioni più rapidamente ed eseguire l'onboarding dei carichi di lavoro.
Governance efficiente: Il team della piattaforma può applicare la governance nelle zone di destinazione delle applicazioni con un sovraccarico minimo.

Come implementare la distribuzione automatica delle sottoscrizioni

La vendita di abbonamenti coinvolge tre team. Il Cloud Center of Excellence (CCoE) stabilisce la logica di business e il processo di approvazione. Quando si è pronti, i team dell'applicazione effettuano richieste di sottoscrizione. Il team della piattaforma usa la richiesta per creare e configurare la sottoscrizione prima di distribuire la sottoscrizione al team dell'applicazione. Il team dell'applicazione aggiorna il budget, distribuisce il carico di lavoro e stabilisce le operazioni. Le indicazioni seguenti forniscono altri dettagli su ogni passaggio del processo di distribuzione automatica delle sottoscrizioni. Per altre informazioni, vedere Linee guida per l'implementazione della gestione delle iscrizioni.

I team della piattaforma possono distribuire molte opzioni e tipi di sottoscrizione ai team delle applicazioni. Questi tipi sono definiti linee di prodotto perché si riferiscono ai principi e alle procedure di progettazione della piattaforma. Per altre informazioni sulla scelta dell'opzione più adatta alle proprie esigenze, vedere Linee di prodotti per la distribuzione automatica di sottoscrizioni comuni.

Stabilire la logica di business e il processo di approvazione

Per implementare il modello di distribuzione automatica delle sottoscrizioni, è necessario stabilire un processo di approvazione che raccoglie informazioni essenziali sulla sottoscrizione. Il Cloud Center of Excellence (CCoE) deve programmare il processo di approvazione e stabilire regole business relative alle informazioni da raccogliere.

Automatizzare il processo. È consigliabile automatizzare il processo di acquisizione e approvazione delle richieste di sottoscrizione per un provisioning più rapido e una migliore conformità.

Eseguire l'integrazione con gli strumenti esistenti. Dovresti integrare il processo di approvazione per la distribuzione delle sottoscrizioni nel tuo strumento di gestione dei servizi IT (ITSM) esistente. L'integrazione può semplificare il processo di approvazione, ridurre il lavoro manuale e migliorare l'efficienza riducendo al contempo gli errori. Semplifica inoltre la manutenzione nel tempo e aiuta a creare report di conformità per i controlli.

Connettersi alla pipeline di distribuzione. È consigliabile associare la logica di business del processo di approvazione alla pipeline di distribuzione della sottoscrizione gestita dal team della piattaforma. I flussi di lavoro di Azure Pipelines o GitHub Actions sono soluzioni comuni per la pipeline di distribuzione delle sottoscrizioni.

Raccogliere i requisiti in fase di assunzione. La logica di business deve consentire ai team dell'applicazione di richiedere una sottoscrizione e fornire i requisiti di sottoscrizione. Questi requisiti devono includere budget previsti, proprietari di sottoscrizioni, aspettative di rete e classificazione della criticità aziendale e riservatezza. La raccolta di queste informazioni all'inizio del processo definisce i parametri di distribuzione e i bisogni di approvazione degli stakeholder. Il processo di assunzione deve anche fornire al team della piattaforma informazioni sufficienti per inserire il carico di lavoro nella gerarchia del gruppo di gestione.

Con il processo di approvazione, i team delle applicazioni possono iniziare a effettuare richieste di sottoscrizione.

Effettuare una richiesta di sottoscrizione

Il servizio di gestione delle sottoscrizioni offre un processo standard per i team delle applicazioni per richiedere una sottoscrizione. È importante socializzare la disponibilità dei distributori automatici di sottoscrizioni e assicurarsi che le richieste di sottoscrizione siano facili da effettuare. Dopo che il team dell'applicazione ha inviato una richiesta di sottoscrizione, il team della piattaforma assume il controllo del processo. Il team della piattaforma mantiene il controllo fino a quando non crea la sottoscrizione e distribuisce la sottoscrizione al team dell'applicazione.

Configurare la rete

L'automazione delle sottoscrizioni deve configurare i componenti di rete necessari e deve essere sufficientemente flessibile per soddisfare le esigenze di ogni team dell'applicazione. Come indicazioni generali, non usare mai indirizzi IP sovrapposti in un singolo dominio di routing. È possibile aggiungere o eliminare lo spazio degli indirizzi di una rete virtuale senza tempi di inattività se i requisiti di dimensione cambiano. Per altre informazioni, vedere:

Usare lo strumento IPAM (Gestione indirizzi IP). Si dovrebbe usare e integrare un sistema di Gestione indirizzi IP nel processo di vendita per semplificare l'assegnazione degli indirizzi IP. Per ulteriori informazioni e indicazioni su IPAM, consultare gli strumenti di gestione degli indirizzi IP.

Concedere al team dell'app autonomia. È necessario concedere ai team dell'applicazione i diritti per creare subnet e anche alcune reti virtuali nella sottoscrizione. La squadra della piattaforma dovrebbe sempre creare reti virtuali che si connettono a un hub centrale.

Applicare la governance della rete. Il team della piattaforma deve applicare la governance della rete virtuale tramite (1) criteri di Azure assegnati alla gerarchia dei gruppi di gestione, o (2) Gestione Rete Virtuale di Azure e Regole di Amministrazione della Sicurezza. Per ulteriori informazioni, vedere Governance guidata dalle politiche e Come bloccare le porte ad alto rischio.

Determinare il posizionamento dell'abbonamento

Il team della piattaforma dovrebbe usare i requisiti di reti informatiche e governance per collocare la sottoscrizione nella gerarchia del gruppo di gestione. Devono anche esaminare i limiti di quota della sottoscrizione prima di creare la sottoscrizione. Per altre informazioni, vedere Personalizzare l'architettura della zona di destinazione di Azure per soddisfare i requisiti.

Identificare il gruppo di gestione corretto. I gruppi di gestione consentono di organizzare e gestire le sottoscrizioni e le distribuzioni dei carichi di lavoro. Individuare o creare un gruppo di gestione che applichi i criteri necessari per la classificazione e le esigenze di ogni carico di lavoro.

Creare un'automazione flessibile. L'automazione deve essere sufficientemente flessibile (1) per distribuire più sottoscrizioni e (2) adattarsi ai limiti del servizio di sottoscrizione.

Più sottoscrizioni: Alcuni carichi di lavoro necessitano di diverse sottoscrizioni. Ad esempio, alcuni carichi di lavoro hanno diverse istanze che sono separate per abbonamento. In alternativa, le architetture SaaS che usano risorse dedicate per cliente usano spesso decine di sottoscrizioni.
Limiti del servizio di sottoscrizione: Un'azienda con diverse migliaia di sottoscrizioni dovrebbe disporre di un'automazione che possa distribuire carichi di lavoro in una vecchia sottoscrizione o colocare carichi di lavoro in una sottoscrizione unica per evitare i limiti. Per altre informazioni, vedere Domande frequenti sulle zone di destinazione di Azure.

È possibile richiedere aumenti di quota manualmente usando il portale di Azure dopo il provisioning. È più semplice automatizzare questo processo usando le API disponibili. Tuttavia, la richiesta di quota può avere esito negativo, pertanto è necessario eseguire uno script per gestire eventuali errori. Per altre informazioni, vedere Microsoft.Capacity, Microsoft.Quota e Microsoft.Support

Creare e configurare la sottoscrizione

È ora possibile creare e configurare la sottoscrizione richiesta. L'obiettivo è creare un processo ripetibile e coerente. Automatizzare la maggior parte del processo di creazione e configurazione della sottoscrizione possibile.

Usare l'infrastruttura come codice (IaC). Una strategia comune per la distribuzione automatica delle sottoscrizioni consiste nel creare e configurare la sottoscrizione a livello di codice tramite IaC. È necessario un contratto commerciale per creare una sottoscrizione di Azure a livello di codice, ma è possibile automatizzare tutti gli aspetti della configurazione della sottoscrizione senza un contratto commerciale. Per altre informazioni, vedere:

Esistono esempi di moduli bicep e Terraform per l'adozione di un modello di distribuzione automatica delle sottoscrizioni indipendentemente dalla registrazione in un contratto commerciale. È consigliabile usare GitHub actions o Azure Pipelines per orchestrare l'automazione.

Usare i tag per la gestione dei costi. È consigliabile automatizzare l'assegnazione coerente dei tag a ogni sottoscrizione per la gestione dei costi e la creazione di report in Gestione costi Microsoft. Anche se si ricevono report di fatturazione con i contratti commerciali, Gestione costi offre una maggiore funzionalità. Ad esempio, è possibile creare report per le sottoscrizioni con tag specifici. Per altre informazioni, vedere Come usare i tag nei dati sui costi e sull'utilizzo e raggruppare e allocare i costi usando l'ereditarietà dei tag

Utilizzare sottoscrizioni produttive e non-produttive. Nella richiesta di una nuova sottoscrizione è necessario specificare se il carico di lavoro è per Production o DevTest. Gli ambienti DevTest comportano costi di risorse inferiori, ma hanno altri termini. Nota L'offerta DevTest non è disponibile per il Contratto Microsoft Partner. Per altre informazioni, vedere:

Configurare controlli di accesso basati sulle identità e sui ruoli (RBAC). La gestione dell'accesso alle risorse all'interno di una sottoscrizione di Azure è fondamentale per mantenere un ambiente sicuro e conforme. Per controllare l'accesso, è essenziale configurare identità e RBAC. Questa configurazione comporta la designazione di un proprietario della sottoscrizione, la creazione di gruppi di Microsoft Entra per gestire l'accesso e la creazione di identità di automazione per distribuire i carichi di lavoro.

Designare un proprietario di una sottoscrizione. L'automazione dell'erogazione della sottoscrizione deve designare un proprietario della sottoscrizione al momento della creazione. La richiesta di sottoscrizione deve acquisire queste informazioni al momento della registrazione. I proprietari delle sottoscrizioni possono essere solo utenti o entità servizio nella directory di sottoscrizione selezionata. Non è possibile selezionare gli utenti della directory guest. Se si seleziona un'entità servizio, immettere il relativo ID app.
Creare gruppi di Microsoft Entra. Oltre al proprietario della sottoscrizione, è necessario assicurarsi che il processo di vendita usi la struttura del gruppo Microsoft Entra per gestire l'accesso alla sottoscrizione. Per l'accesso con privilegi elevati (ad esempio, scrittura), è consigliabile usare PIM per i gruppi. L'automazione di questo processo di creazione non deve violare le procedure consigliate, ad esempio la limitazione del numero di proprietari di sottoscrizioni e l'uso del livello minimo di accesso richiesto.
Stabilire le identità del carico di lavoro. Le identità del carico di lavoro (principali del servizio) usate per la distribuzione del carico di lavoro spesso hanno permessi elevati nell'ambito di sottoscrizione. Il processo di richiesta di sottoscrizione deve raccogliere le esigenze di identità del carico di lavoro nella fase iniziale. Il processo di distribuzione automatica deve creare queste identità e assegnare l'accesso appropriato alla sottoscrizione. È importante notare che l'identità di carico di lavoro non può usare PIM e riceve accesso continuo alle risorse. È consigliabile usare le identità gestite per evitare la necessità di gestire i segreti. Per altre informazioni, vedere l'area di progettazione delle identità.

Consegnare al team dell'applicazione. Dopo aver creato la sottoscrizione, il team della piattaforma deve passare la sottoscrizione al team dell'applicazione.

Aggiornare il budget della sottoscrizione

Le squadre della piattaforma e del carico di lavoro condividono la responsabilità della salute finanziaria della sottoscrizione. La distribuzione deve creare un budget di sottoscrizione in base alle informazioni contenute nella richiesta di sottoscrizione. L'applicazione deve aggiornare il budget per soddisfare le proprie esigenze quando ricevono la sottoscrizione. I budget sono utili per controllare la spesa rispetto all'utilizzo corrente e previsto, ma non sono limiti rigidi. È consigliabile creare avvisi relativi al budget per notificare ai proprietari della sottoscrizione se il carico di lavoro sta per superare la soglia di budget. Per i servizi condivisi, come la Gestione API, si può prendere in considerazione l'uso delle regole di allocazione dei costi di Azure per ridistribuire i costi tra le sottoscrizioni che consumano.

Distribuire il carico di lavoro e gestire

Il team dell'applicazione deve avere autonomia per creare le risorse necessarie per il carico di lavoro e gestire le operazioni. Il team della piattaforma rimane responsabile della governance delle sottoscrizioni. Man mano che cambiano i requisiti di governance di un carico di lavoro, il team della piattaforma deve spostare le sottoscrizioni nel gruppo di gestione che soddisfa meglio le esigenze del carico di lavoro. È possibile automatizzare lo spostamento usando Bicep o Terraform. Per altre informazioni, vedere:

Passaggi successivi

Esaminare le sottoscrizioni o le linee di prodotto che è possibile distribuire ai team delle applicazioni. Stabilire un ottimo punto di partenza per soddisfare diversi scenari.

Stabilire linee di prodotto comuni vendita di abbonamenti

Condividi tramite