Ciclo di vita di Autopilot in Microsoft Foundry

Un autopilot passa attraverso un ciclo di vita definito. Un amministratore Azure effettua il provisioning della piattaforma, uno sviluppatore compila e pubblica un progetto, un amministratore tenant lo approva e un manager assume ed esegue ogni istanza. Questo articolo descrive ogni fase, il ruolo proprietario e i punti in cui la responsabilità passa da un ruolo all'altro.

Poiché si crea un modello anziché un pilota automatico, il ciclo di vita si articola su tre livelli: il modello pubblicato una volta sola, le istanze che i team creano a partire da esso e la flotta di istanze che il tenant gestisce complessivamente. Per il modello sottostante, vedere Che cos'è un autopilot in Microsoft Foundry?

Fasi del ciclo di vita a colpo d'occhio

Chi fa quello che fa

Quattro ruoli possiedono le quattro decisioni che modellano un autopilot. Altri ruoli sono facoltativi e vengono visualizzati solo in determinati modelli di distribuzione.

Quando questi quattro non possono coprire il terreno da solo, vengono visualizzati altri due ruoli:

• Uno sponsor esecutivo aziendale interviene quando un dirigente vuole adottare Autopilot in tutta l'organizzazione e ne finanzia l'adozione.
• Un responsabile degli accessi interviene quando la persona che attiva l'istanza non può concedere ciò di cui Autopilot ha bisogno, oppure non dovrebbe essere quella che valuta il principio del privilegio minimo.

Queste decisioni non si sovrappongono e non viene tralasciato nulla di importante: l'infrastruttura su cui gira la piattaforma, il ruolo e le funzionalità del blueprint, se e come Autopilot opera nel tenant e l'impiego di ogni istanza. Ogni altra domanda si riconduce a una di esse.

La decisione dello sviluppatore implica più di quanto sembri a prima vista. Non è solo ciò che il pilota automatico può fare. Comprende anche le condizioni per cui il pilota automatico è stato progettato e testato, che definiscono l'inviluppo operativo su cui fanno affidamento tutti gli altri ruoli quando ne approvano l'adozione e l'impiego. Quando un autopilot non riesce all'esterno di tale envelope, l'errore dipende dal fatto che l'envelope sia mai stata o meno specificata.

Responsabilità rispetto alla governance

La governance determina chi può arrestare un'istanza e, per progettazione, quasi tutti possono farlo. La responsabilità determina chi è obbligato a fermarla. Questo è sempre il manager, indipendentemente da chi è in errore, perché un autopilot rotto non deve continuare a funzionare mentre il suo manager attende che qualcun altro agisca.

Un errore di accesso mostra la differenza più chiaramente. Un responsabile degli accessi configura una concessione che il manager non ha mai concesso, e l’istanza si comporta in modo anomalo di conseguenza. Il manager è ancora quello obbligato a fermarlo. L'errore e l'obbligo rimangono separati dalla progettazione.

Altri partecipanti

Due gruppi non possiedono alcuna decisione, ma sono ancora importanti.

I colleghi usano l'autopilota dove il team lavora già: in Teams, nelle e-mail e nei commenti dei documenti. Gli assegnano compiti continuativi e gli forniscono correzioni obiettive che ne aggiornano il grounding.

I referenti aziendali sono altri referenti nella stessa lavorazione. Non configurano nulla e non sono responsabili di nulla, ma possono monitorare l'istanza e bloccarla. Non possono eliminarlo o trasferirlo. Tale progettazione è intenzionale: chiunque sia abbastanza vicino al lavoro per vedere il comportamento errato di Autopilot dovrebbe essere in grado di arrestarlo. Il manager è l'unico ruolo che gestisce il pilota automatico e lo usa quotidianamente, ed è per questo che l'obbligo di fermarlo cade su di essi.

Chiunque si trovi nel tenant all'esterno del gruppo di destinatari configurato è un non-collega. Chi non fa parte del team viene bloccato per impostazione predefinita, prima ancora che Autopilot richiami un modello.

Come i modelli di distribuzione modificano i ruoli

Il modello autopilot scelto determina quali ruoli vengono visualizzati.

• Autopilot di gruppo : implica ogni ruolo. Questo modello è quello in cui la separazione del ruolo di responsabile degli accessi conta di più, perché la persona che può concedere l’accesso a un progetto di Azure DevOps raramente è il team leader che lavora con l’istanza.
• Autopilot a livello aziendale — ha un'unica istanza e un unico responsabile per l'intera organizzazione, quindi "membro del team" cessa di essere una distinzione utile.
• Personal autopilot - coinvolge solo lo sviluppatore, che di solito è il manager e l'unico utente.

Come si combinano i livelli

Il ciclo di vita viene eseguito a tre livelli contemporaneamente.

• Progetto — viene eseguito una volta sola, dal provisioning fino all'approvazione. Dopo l'approvazione, il lavoro dello sviluppatore continua come attività permanente che copre la vita lavorativa di ogni istanza e termina solo quando il progetto viene eliminato. L'ottimizzazione inserisce nuove versioni nella fase di compilazione.
• Istanza — viene eseguita una sola volta per ogni assunzione. Molte istanze sono attive contemporaneamente, quindi un team può eseguire l'offboarding di un'istanza mentre un altro team ne assume uno dallo stesso progetto.
• Fleet — non è una fase. Si tratta dell'attività permanente dell'amministratore tenant e inizia con l'approvazione, perché è quando la flotta inizia a esistere.

L'approvazione è il punto in cui una progettazione approvata diventa molte istanze. L'eliminazione del modello si ripercuote su ogni istanza creata da esso.

Le attività permanenti vengono descritte dopo le fasi dell'istanza, perché questo è il punto in cui hanno qualcosa da estendere.

Un singolo esempio viene eseguito in ogni fase: un responsabile del flusso di lavoro, creato da un team della piattaforma e assunto da molti team. I paragrafi di esempio sono etichettati esempio e sono facoltativi.

Livello del progetto

Le fasi del blueprint vengono eseguite una sola volta. Ogni istanza creata dal progetto eredita i risultati.

Effettuare il provisioning dell'infrastruttura: amministratore e sviluppatore di Azure

L'amministratore Azure configura l'ambiente e concede agli sviluppatori le autorizzazioni minime necessarie per compilare, testare e distribuire in esso. Questa configurazione si applica per ogni ambiente, non per autopilot. Succede una volta, e ogni modello creato lì lo eredita.

L'amministratore di Azure effettua anche il provisioning di ciò che questo autopilot specifico deve eseguire, ad esempio l'archiviazione per gli elementi e la memoria rilevati, e concede all'identità predefinita dell'autopilot l'accesso a tali risorse. Questa infrastruttura appartiene al progetto, non ai dati del team. Il provisioning delle risorse e l'assegnazione delle autorizzazioni sono le due cose che gli sviluppatori non possono fare per se stessi. L'amministratore Azure è l'unico ruolo che termina prima che autopilot raggiunga un utente: il lavoro viene eseguito quando lo sviluppo può iniziare.

Esempio: in Contoso, l'amministratore Azure configura un account Foundry e un progetto e distribuisce i modelli. Creano un Registro Azure Container, un'area di lavoro Log Analytics e Application Insights, con connessioni di progetto per il Registro di sistema e Application Insights. L'identità gestita del progetto viene concessa a AcrPull e Log Analytics Reader. Crea inoltre un account di archiviazione con due tabelle: una per l'elenco dei mittenti consentiti nei messaggi diretti e una per gli elementi di lavoro monitorati. Dopo aver creato l'agente, alla sua identità viene assegnato il ruolo Storage Table Data Contributor. Ogni sviluppatore riceve Utente Foundry con ambito limitato al progetto, AcrPush con ambito limitato al registro e Lettore di monitoraggio.

Compilazione e pubblicazione — sviluppatori

Lo sviluppatore definisce il ruolo e le funzionalità del progetto: cosa fa, come si comporta, quando risponde, quando rimane invisibile all'utente, quando richiede l'approvazione e cosa non deve mai fare. La piattaforma offre funzionalità fondamentali, ad esempio memoria, routine e auto-miglioramento, in modo che lo sviluppatore le consenta e le configura invece di crearle. Un'istanza di sviluppo consente allo sviluppatore di eseguire l'iterazione senza immettere nuovamente l'approvazione del tenant per ogni modifica.

La pubblicazione registra anche gli ambiti delle autorizzazioni dichiarate e due limiti massimi: chi può ingaggiare Autopilot e il livello di accesso più ampio che qualsiasi manager può concedere successivamente. Insieme alle condizioni per le quali l'autopilot è stato progettato e testato, questi valori costituiscono l’envelope operativo che ogni ruolo downstream considera affidabile.

Nulla in questa fase concede l'accesso a qualsiasi elemento. Questi valori sono solo dichiarazioni. La pubblicazione sottopone il progetto alla governance; non lo mette in pratica.

Esempio: In Contoso, il responsabile del flusso di lavoro ottiene gli strumenti di Azure DevOps con passaggio dell'identità, gli strumenti integrati di Microsoft 365 e un sistema personalizzato di monitoraggio degli elementi di lavoro. La logica di risposta decide quando parla in un canale e quando rimane invisibile all'utente. Autopilot rifiuta le chat di gruppo che includono partecipanti non approvati e restituisce una risposta no-op fissa ai messaggi tra tenant diversi. Prima della pubblicazione, lo sviluppatore dichiara gli ambiti che richiedono il consenso e imposta entrambi i limiti.

Approvare, configurare e fornire il consenso - Amministratore tenant

Questa fase consiste in un'attività di controllo con tre azioni. L'amministratore tenant esamina il progetto pubblicato, concede il consenso agli ambiti dichiarati, lo approva e seleziona chi può assumerlo. Il consenso e la selezione del responsabile dell’assunzione sono decisioni separate con conseguenze distinte: un amministratore può approvare un modello acconsentendo solo a una parte di quanto richiesto.

Questa è la fase in cui viene presa la decisione a livello di flotta: se Autopilot può operare nel tenant e in base a quale criterio. Il consenso regola il token, che determina i tipi di chiamate che autopilot è mai autorizzato a effettuare. Non concede a nessuno i dati del team.

Ogni nuovo progetto e ogni ambito esteso entrano nuovamente in questa attività di controllo, quindi includere il tempo di revisione dell'amministratore nei piani di implementazione.

Esempio: In Contoso, l'amministratore apre la richiesta in sospeso per il responsabile del flusso di lavoro nell'interfaccia di amministrazione di Microsoft 365, acconsente al set di ambiti, la pubblica e designa i responsabili dei team dell'organizzazione come addetti alle assunzioni idonei.

L'approvazione abilita l'assunzione

L'approvazione è la condizione di uscita per l'intero livello del progetto: almeno un manager può ora assumere un'istanza. È l'unico punto in cui il livello blueprint e il livello dell'istanza si incontrano. Quanto precede dichiara e acconsente alla funzionalità. Non è stato ancora concesso nulla. L'autopilot può disporre di tutti gli ambiti necessari e comunque non riuscire ad accedere ad alcun dato.

Livello dell'istanza

Le fasi dell'istanza vengono eseguite una volta per ogni assunzione. Molte istanze sono in esecuzione contemporaneamente, ciascuna in una fase diversa.

Assunzione - responsabile

L'assunzione è una singola azione anziché una fase. Crea due oggetti:

• Un'identità dell'agente, un'entità servizio che autentica e contiene le autorizzazioni.
• Un account utente agente, che contiene una cassetta postale, una presenza di Teams, una posizione nell'organigramma e un manager.

La persona che assume autopilot diventa il suo manager.

Esempio: in Contoso tre responsabili del team assumono tre responsabili del flusso di lavoro dallo stesso progetto. Un progetto diventa ora una flotta, e da questo momento in poi tutto si verifica tre volte, in modo indipendente.

A bordo — responsabile

L'onboarding è il momento in cui il rapporto di lavoro inizia davvero. Il manager configura cinque impostazioni.

Le concessioni di accesso, ovvero l'appartenenza al gruppo di sicurezza, un progetto di Azure DevOps, un sito SharePoint, sono la prima concessione di risorse aziendali ovunque nel ciclo di vita. Trasformano un progetto valido in un collega operativo.

Ogni gruppo di destinatari inizialmente comprende solo il manager e si estende fino al livello massimo dello sviluppatore, e non oltre. Chiunque nel tenant che non rientra nei destinatari configurati è bloccato per impostazione predefinita e Autopilot non richiama mai alcun modello per conto di tali utenti.

Il consenso e l'accesso sono barriere diverse. Gli ambiti e il consenso regolano il token, che determina quali tipi di chiamate sono consentiti. Le appartenenze ai gruppi e i ruoli disciplinano l'account, che determina a quali dati tali chiamate possono accedere. Microsoft Entra ID impone la prima attività di controllo. Ogni risorsa applica la seconda attività di controllo ai propri elenchi di appartenenze e non controlla mai il consenso. Per una persona, l'IT chiude entrambi i gate molto prima del primo giorno. Per un sistema automatico, entrambi i gate sono nuovi al momento dell'assunzione, quindi l’onboarding comprende attività che danno l’impressione di essere già state svolte.

L'autorizzazione inizia qui ma non viene mai completata. I team cambiano, le risorse cambiano e le autorizzazioni vengono revocate. Alla fine, Autopilot ha bisogno di un sito SharePoint che nessuno aveva previsto al momento dell’assunzione.

Quando l'assunzione di persone non può effettuare queste concessioni, la fase si divide. I manager sono knowledge worker che spesso non hanno i diritti per aggiungere un account a un gruppo di sicurezza o a un'organizzazione Azure DevOps e il privilegio minimo è un giudizio sulla sicurezza che la maggior parte dei lead del team non ha mai dovuto fare. Un gestore degli accessi entra invece in gioco in questa fase: si occupa dell’assunzione, cura l’onboarding e autorizza l’istanza, quindi trasferisce il ruolo di manager al responsabile che la utilizza. La decisione di assunzione stessa non cambia.

Esempio: in Contoso, un responsabile imposta il proprio flusso di lavoro su membri del team e i responsabili tecnici e di prodotto come responsabili aziendali. Aggiungono l'account dell'agente al gruppo di sicurezza e al gruppo di distribuzione del team, ed è questo che gli consente di accedere al progetto Azure DevOps e al sito SharePoint; inoltre, gli concedono l'accesso in scrittura all'organizzazione GitHub. In un altro team, il responsabile non può assegnare il progetto Azure DevOps, quindi un gestore degli accessi effettua l'onboarding dell'istanza e trasferisce il ruolo di responsabile.

Operatività - responsabile, colleghi e dirigenti aziendali

Quattro attività si svolgono contemporaneamente per tutta la durata dell’istanza, e ciascuna attività coinvolge un diverso insieme di ruoli.

Utilizzo - colleghi e manager. Autopilot svolge il proprio ruolo nelle aree configurate, inclusi i messaggi diretti di Teams, le chat di gruppo e i canali, la posta elettronica e i commenti dei documenti. Il contesto si estende a ogni interazione, indipendentemente dalla superficie o dall'utente. I membri del team assegnano routine, ossia istruzioni permanenti fornite in un unico messaggio.

Osservazione — manager e dirigenti aziendali. Verificano cosa ha fatto l'istanza, per chi, a quale costo e se ci sia qualcosa da indagare. La responsabilità quotidiana si verifica qui.

Governare — manager e responsabili aziendali. Questi controlli sono tutti reversibili: restringere l'accesso, revocare l'accesso o bloccare l'istanza. La governance deriva dall'osservazione, perché si interviene bloccando in risposta a qualcosa che si è osservato. Il blocco è intenzionalmente asimmetrico. Chiunque sia abbastanza vicino al lavoro per vedere un problema può interrompere l'istanza, ma solo un amministratore tenant può avviarla di nuovo.

Coaching e personalizzazione — responsabile Il miglioramento arriva attraverso due canali diversi. Correzioni oggettive, come una data errata o un proprietario sbagliato, possono provenire da chiunque lavori con l'istanza e ne aggiornano il contesto di base. Coaching e personalizzazione — stile, modifiche alla memoria e routine di configurazione — spettano esclusivamente al manager, che risolve automaticamente i conflitti: prevale ciò che imposta il manager. Il coaching cambia il pilota automatico di un team. Quando lo sviluppatore ottimizza il progetto, cambia ciò che ogni istanza è.

Esempio: In Contoso, i membri del team impostano ciascuno le attività ricorrenti in un unico messaggio: un riepilogo interno del venerdì, una bozza settimanale esterna che rimane non inviata finché un responsabile non la approva e un riepilogo di fine giornata che menziona ogni responsabile con un'attività aperta. Il responsabile esamina l'attività recente dell'istanza. Quando l'istanza continua a nascondere il punto principale nei suoi riepiloghi, il responsabile la guida una volta e il nuovo stile si mantiene.

Offboarding dell'istanza — responsabile

L'offboarding è l'unica azione irreversibile sull'istanza. L'account utente dell'agente viene rimosso, le appartenenze vengono revocate e l'accesso termina immediatamente. È coinvolto un solo team e nessun’altra istanza viene interessata. Non è possibile ripristinare nulla.

La decisione spetta al responsabile, ed è l'unica valutazione che nessun altro può esprimere: se l'istanza offra ancora un valore sufficiente da giustificarne il funzionamento. Gli amministratori possono agire in base agli indicatori dell’intera flotta, ma non possono vedere se una singola istanza giustifica ancora il proprio costo. L'offboarding non è una versione più forte dei controlli nella fase operativa. Tutti i controlli in quella fase possono essere annullati, mentre l'offboarding non può esserlo, per questo è una fase separata.

Esempio: in Contoso, un flusso di lavoro termina e il dirigente esegue l'offboarding della propria istanza. Le sue iscrizioni sono revocate. Gli altri due gestori del flusso di lavoro non sono interessati.

Attività di progetto e flotta permanenti

Due attività si svolgono per l'intero ciclo di vita operativo di ogni istanza: l'utilizzo del blueprint da parte dello sviluppatore e la gestione della flotta da parte dell'amministratore del tenant.

Gestire il progetto - Sviluppatore

Lo sviluppatore controlla, osserva, valuta e ottimizza il progetto. Osservano le distribuzioni in produzione senza ricevere per impostazione predefinita il contenuto delle conversazioni private. Filtrano i dati di telemetria per versione e per istanza per controllare le implementazioni e eseguono valutazioni sulla busta operativa per cui è stato creato e testato autopilot. Le correzioni vengono fornite come nuove versioni che scorrono in tutte le istanze.

Una nuova versione che estende gli ambiti non ignora la governance. Le autorizzazioni aggiunte fanno rientrare nuovamente nell'attività di controllo di consenso. L'attività di controllo si applica al tetto massimo anziché alla modifica in sé, motivo per cui la decisione dell'amministratore del tenant rimane valida anziché essere una tantum.

Lo sviluppatore mantiene anche la governance a livello di progetto. Possono bloccare il progetto fornito e, come tutti gli altri, non possono sbloccarlo. Non confondere questa attività con il coaching che fa un manager. Lo sviluppatore modifica ciò che è ogni istanza. Un manager modifica il comportamento di un'istanza.

Gestire la flotta - Amministratore tenant

L'amministratore tenant osserva, controlla e protegge la flotta dal momento in cui un progetto entra in approvazione. Un singolo registro elenca ogni nuova risorsa con il rispettivo team, il modello e la versione, unitamente a tutte le azioni attribuite alla sua identità. L'amministratore detiene il livello di controllo più ampio nel sistema: bloccare il blueprint interrompe tutte le istanze contemporaneamente, perché ogni token di istanza rimanda alla credenziale del blueprint.

Tale controllo riflette il modo in cui i progetti hanno esito negativo. Un difetto del progetto è sempre sistemico. Se un responsabile di un flusso di lavoro invia un'e-mail al di fuori del tenant, non significa che l'istanza di un team stia avendo un malfunzionamento. Ogni istanza presenta lo stesso difetto e attende le stesse condizioni. Il blocco si applica al progetto, non all'istanza che a qualcuno è capitato di osservare.

Ritiro ed eliminazione del progetto — amministratore del tenant e sviluppatore

Un progetto ha due uscite.

• Ritiro : un amministratore tenant arresta i nuovi assunti e il progetto termina quando non rimangono istanze attive. Il ritiro impedisce assunzioni future senza influire sulle istanze correnti.
• Elimina : ogni istanza creata dal progetto viene rimossa con essa. Delete è l'equivalente, a livello di blueprint, della rimozione di una singola istanza da parte di un manager.

Questa differenza è la linea che organizza l'intero ciclo di vita. Ogni controllo nelle fasi operative e le attività permanenti possono essere annullati. Non è possibile eliminare un progetto.

Contenuti correlati

• Che cos'è un pilota automatico in Microsoft Foundry? spiega il modello di identità e perché i piloti automatici usano i progetti guida.
• Avvio rapido: creare il primo autopilot copre il provisioning, la creazione, la pubblicazione, l'approvazione e l'attivazione della prima istanza.
• L’integrazione di Microsoft Agent 365 con Foundry include la sincronizzazione del registro, la raccolta dei dati e la residenza dei dati.