Ciclo de vida do Autopilot no Microsoft Foundry

Um piloto automático passa por um ciclo de vida definido. Um administrador Azure provisiona a plataforma, um desenvolvedor cria e publica um blueprint, um administrador de locatário aprova e um gerente contrata e executa cada instância. Este artigo descreve cada estágio, a função que a possui e os pontos em que a responsabilidade passa de uma função para outra.

Como você cria um modelo em vez de um piloto automático, o ciclo de vida se desenrola em três camadas: o modelo que você publica uma vez, as instâncias que as equipes criam a partir dele e a frota de instâncias que seu tenant gerencia como um todo. Para o modelo por trás disso, veja o que é um piloto automático no Microsoft Foundry?

Estágios do ciclo de vida em um relance

Quem faz o quê

Quatro funções possuem as quatro decisões que moldam um piloto automático. Outras funções são opcionais e aparecem apenas em determinados padrões de implantação.

Mais duas funções aparecem quando esses quatro não conseguem cobrir o chão sozinhos:

• Um patrocinador executivo de negócios se junta quando um executivo quer o piloto automático em uma organização e o financia.
• Um gerenciador de acesso entra em cena quando a pessoa que está provisionando a instância não consegue conceder o que o Autopilot precisa ou não deve ser a responsável por avaliar o menor privilégio necessário.

Essas decisões não se sobrepõem, e nada importante fica entre elas: em que a plataforma é executada, a função e os recursos do blueprint, se e como o Autopilot opera em seu locatário e o uso de cada instância. Todas as outras perguntas se resumem a uma delas.

A decisão do desenvolvedor abrange mais do que parece primeiro. Não é só o que o piloto automático pode fazer. Também inclui as condições sob as quais o piloto automático foi projetado e testado, que formam o envelope operacional no qual todas as demais áreas confiam quando o aprovam e o adotam. Quando um piloto automático falha fora desses limites, a responsabilidade depende de se esses limites foram alguma vez explicitados.

Responsabilidade em comparação com a governança

A governança determina quem pode parar uma instância e, por design, quase todos podem. A responsabilidade determina quem é obrigado a pará-lo. Esse é sempre o gerente, independentemente de quem é o culpado, porque um piloto automático quebrado não deve continuar funcionando enquanto seu gerente espera que outra pessoa aja.

Uma falha de acesso mostra a diferença com mais clareza. Um gerenciador de acesso configura uma concessão que o gerente nunca fez e a instância se comporta mal por causa dela. O gerente ainda é o único obrigado a pará-lo. A falha e a obrigação permanecem separadas por design.

Outros participantes

Dois grupos não possuem nenhuma decisão, mas ainda importam.

Os colegas de equipe usam o Copilot onde a equipe já trabalha: no Teams, em e-mails e nos comentários de documentos. Elas lhe atribuem tarefas recorrentes e fornecem correções objetivas que atualizam sua ancoragem.

Os clientes potenciais de negócios são outros clientes potenciais no mesmo trabalho. Eles não configuram nada e respondem por nada, mas podem observar a instância e bloqueá-la. Eles não podem excluí-lo ou transferi-lo. Esse projeto é intencional: qualquer pessoa perto o suficiente da operação para perceber o piloto automático falhar deve ser capaz de interrompê-lo. O gerente é a única função que tanto rege o piloto automático quanto o usa diariamente, e é por isso que a obrigação de pará-lo recai sobre eles.

Qualquer pessoa no locatário fora do público-alvo configurado é um não companheiro de equipe. Pessoas que não fazem parte da equipe são bloqueadas por padrão, antes mesmo que o piloto automático chame um modelo.

Como os padrões de implantação alteram as funções

O padrão de piloto automático escolhido determina quais funções são exibidas.

• Piloto automático de grupo – envolve todas as funções. Esse padrão é onde a divisão do gerenciador de acesso é mais importante, pois a pessoa que pode conceder um projeto Azure DevOps raramente é o líder da equipe que trabalha com a instância.
• Piloto automático em toda a empresa — tem uma instância e um gerente responsável por toda a organização, portanto “colega de equipe” deixa de ser uma distinção útil.
• Piloto automático pessoal – envolve apenas o desenvolvedor, que geralmente é o gerente e o único usuário.

Como as camadas se encaixam

O ciclo de vida ocorre simultaneamente em três camadas.

• Blueprint – é executado uma vez, desde o provisionamento até a aprovação. Após a aprovação, o trabalho do desenvolvedor continua como uma atividade permanente que abrange a vida útil de cada instância e termina somente quando o blueprint é excluído. A otimização alimenta novas versões novamente no estágio de build.
• Instância – executada uma vez para cada contratação. Muitas instâncias estão em execução ao mesmo tempo, então uma equipe pode desativar uma instância enquanto outra contrata uma direto do mesmo blueprint.
• Frota – não é uma etapa. É a atividade contínua do administrador do locatário, e começa com a aprovação, pois é nesse momento que a frota começa a existir.

A aprovação é o ponto em que um projeto aprovado se torna várias instâncias. A exclusão do blueprint se aplica em cascata a todas as instâncias criadas a partir dele.

As atividades restantes são descritas após os estágios da instância, porque esse é o ponto em que elas têm algo a abranger.

Um único exemplo percorre todas as etapas: um gerenciador de fluxo de trabalho, criado por uma equipe de plataforma e adotado por muitas equipes. Os parágrafos de exemplo são rotulados como Exemplo e são opcionais.

A camada de projeto

Os estágios do projeto são executados apenas uma vez. Cada instância criada a partir do blueprint herda seus resultados.

Provisionamento de infraestrutura — administrador e desenvolvedor do Azure

O administrador do Azure configura o ambiente e fornece aos desenvolvedores as permissões mínimas necessárias para criar, testar e implantar nele. Essa configuração se aplica por ambiente, não por piloto automático. Acontece uma vez, e cada modelo criado lá herda isso.

O administrador do Azure também provisiona o que esse Autopilot específico precisa para funcionar, como armazenamento para itens rastreados e memória, e concede à identidade interna do Autopilot acesso a esses recursos. Essa infraestrutura pertence ao blueprint, não aos dados de nenhuma equipe. Provisionar recursos e atribuir permissões são as duas coisas que os desenvolvedores não podem fazer por si mesmos. O administrador do Azure é a única função que termina antes que o piloto automático chegue a um usuário: seu trabalho é feito quando o desenvolvimento pode começar.

Exemplo: na Contoso, o administrador do Azure configura uma conta e um projeto do Foundry e implanta os modelos. Elas criam um Registro de Contêiner do Azure, um workspace do Log Analytics e um Application Insights, com conexões do projeto para o Registro de Contêiner do Azure e o Application Insights. A identidade gerenciada do projeto é concedida a AcrPull e Log Analytics Reader. Eles também criam uma conta de armazenamento com duas tabelas, uma para a lista de permissões de mensagem direta e outra para itens de trabalho rastreados. Depois que o agente é criado, à sua respectiva identidade é concedida a função Colaborador de Dados de Tabela de Armazenamento. Cada desenvolvedor obtém o Usuário do Foundry com escopo para o projeto, o AcrPush com escopo para o Registro e o Leitor de Monitoramento.

Compilar e publicar – desenvolvedor

O desenvolvedor define a função e os recursos do blueprint: o que ele faz, como ele se comporta – quando ele responde, quando permanece em silêncio, quando pede aprovação — e o que ele nunca deve fazer. A plataforma fornece funcionalidades fundamentais, como memória, rotinas e auto-aperfeiçoamento, de modo que o desenvolvedor os habilite e configure em vez de configurá-los. Uma instância de desenvolvimento permite que o desenvolvedor itere sem inserir novamente a aprovação do locatário para cada alteração.

A publicação também registra os escopos de permissão declarados e dois limites máximos: quem pode usar o Autopilot e o nível de acesso mais amplo que qualquer gerente pode conceder posteriormente. Juntamente com as condições para as quais o piloto automático foi criado e testado, esses valores formam o envelope operacional em que cada função downstream confia.

Nada nesta fase concede acesso a nada. Esses valores são apenas declarações. Publicar coloca o blueprint diante da governança; não o coloca em prática.

Exemplo: na Contoso, o gerente do fluxo de trabalho recebe as ferramentas do Azure DevOps com propagação de identidade, as ferramentas internas do Microsoft 365 e um rastreador personalizado de itens de trabalho. Sua lógica de resposta decide quando fala em um canal e quando permanece em silêncio. O Autopilot recusa chats de grupo que incluem participantes não aprovados e retorna uma resposta não operacional fixa para mensagens entre locatários. Antes da publicação, o desenvolvedor declara os escopos que precisam de consentimento e define os dois tetos.

Aprovar, configurar e fornecer consentimento — administrador do locatário

Esse estágio é uma porta com três ações. O administrador do locatário examina o blueprint publicado, consente com os escopos declarados, aprova-o e seleciona quem pode usá-lo. O consentimento e a seleção do contratante são decisões separadas, com consequências distintas: um administrador pode aprovar um blueprint ao consentir apenas com parte do que ele solicitou.

É nessa etapa que a decisão no nível da frota é tomada: se o Autopilot pode operar no seu locatário e de acordo com qual política. O consentimento rege o token, que determina que tipos de chamadas o piloto automático tem permissão para fazer. Ele não concede dados de equipe a ninguém.

Cada novo modelo e cada ampliação de escopo passam novamente por essa etapa, portanto inclua o tempo de revisão do administrador em seus planos de implantação.

Exemplo: Na Contoso, o administrador abre a solicitação pendente do gerente de fluxo de trabalho no Centro de administração do Microsoft 365, consente com o conjunto de escopos definido, publica-a e nomeia os líderes de equipe da organização como contratantes qualificados.

A aprovação permite a contratação

A aprovação é o critério de saída para toda a camada do blueprint: agora, pelo menos um gerente pode provisionar uma instância. É o único ponto em que a camada de blueprint e a camada de instância se encontram. Tudo até este ponto declara e consente com a funcionalidade. Nada foi concedido ainda. Um piloto automático pode ter todos os escopos necessários e ainda assim não obter dado algum.

A camada de instância

Os estágios de instância são executados uma vez por contratação. Muitas instâncias são executadas simultaneamente, cada uma em sua própria fase.

Contratação – gerente

A contratação é uma única ação em vez de uma fase. Ele cria dois objetos:

• Uma identidade de agente, uma entidade de serviço que autentica e tem permissões.
• Uma conta de usuário do agente, que contém uma caixa de correio, a presença do Teams, um lugar no organograma e um gerente.

A pessoa que contrata o piloto automático torna-se seu gerente.

Exemplo: na Contoso, três líderes de equipe contratam três gerentes de fluxo de trabalho do mesmo blueprint. Um projeto agora é uma frota, e tudo daqui em diante acontece três vezes, de forma independente.

Integrar – gerente

É na integração que o trabalho realmente começa. O gerente define cinco configurações.

As concessões de acesso — associação de grupo de segurança, um projeto Azure DevOps, um site de SharePoint — são a primeira concessão de recursos empresariais em qualquer lugar no ciclo de vida. Eles transformam um plano promissor em um colega de equipe funcional.

Cada público-alvo começa apenas com o gerente e se estende até o limite máximo do desenvolvedor, sem ultrapassá-lo. Qualquer pessoa no locatário que esteja fora do público-alvo configurado é bloqueada por padrão, e o Autopilot nunca invoca um modelo em nome dessa pessoa.

Consentimento e acesso são portas diferentes. Escopos e consentimento regem o token, que determina quais tipos de chamadas são permitidas. O pertencimento a grupos e as funções governam a conta, determinando quais dados essas chamadas podem acessar. O Microsoft Entra ID aplica a primeira porta. Cada recurso aplica o segundo nível de controle com base em suas próprias listas de membros e nunca verifica o consentimento. Para uma pessoa, a TI fecha as duas portas muito antes do primeiro dia. Para um Autopilot, as duas portas são novas no momento da contratação, então o processo de integração inclui trabalhos que parecem que já deveriam ter sido concluídos.

A autorização começa aqui, mas nunca termina. As equipes mudam, os recursos mudam e as concessões são revogadas. O piloto automático eventualmente precisa de um site de SharePoint que ninguém antecipou na contratação.

Quando a pessoa que contrata não pode fazer essas concessões, o estágio se divide. Os gerentes são profissionais do conhecimento que muitas vezes não têm permissão para adicionar uma conta a um grupo de segurança ou a uma organização do Azure DevOps, e o privilégio mínimo é uma decisão de segurança que a maioria dos líderes de equipe nunca precisou tomar. Em vez disso, um gerenciador de acesso assume esse estágio: ele contrata, integra e autoriza a instância e, em seguida, transfere a função de gerente para o líder que trabalha com ela. A decisão de contratação em si não muda.

Exemplo: Na Contoso, um líder define seu fluxo de trabalho como colegas de equipe e os líderes de engenharia e de produto como líderes de negócios. Adiciona-se a conta do agente ao grupo de segurança e à lista de distribuição da equipe, o que concede acesso ao projeto do Azure DevOps e ao site do SharePoint, e concedes-se a ela acesso de gravação à organização do GitHub. Em outra equipe, o líder não pode conceder o projeto Azure DevOps, portanto, um gerenciador de acesso integra a instância e entrega a função de gerente.

Operar – gerente, colegas de equipe e clientes potenciais de negócios

Quatro atividades são executadas simultaneamente enquanto a instância existir, e cada atividade envolve um conjunto diferente de papéis.

Use – colegas de equipe e gerente. O Autopilot desempenha sua função nas interfaces em que foi configurado, incluindo mensagens diretas do Teams, chats em grupo e canais, emails e comentários em documentos. Seu contexto abrange cada interação, independentemente da superfície ou do usuário. Os colegas de equipe atribuem rotinas, que são instruções permanentes fornecidas em uma única mensagem.

Observar – gerente e líderes de negócios. Eles revisam o que a instância fez, para quem, a que custo, e se algo precisa ser investigado. A responsabilidade diária acontece aqui.

Governar – gerente e líderes de negócios. Esses controles são todos reversíveis: restringir o acesso, revogar o acesso ou bloquear a instância. Governar decorre da observação, porque você bloqueia em resposta a algo que viu. O bloqueio é intencionalmente assimétrico. Qualquer pessoa próxima o suficiente do trabalho para identificar um problema pode parar a instância, mas apenas um administrador do locatário pode iniciá-la novamente.

Treinar e personalizar – gerente. A melhoria chega por meio de dois canais desiguais. Correções objetivas, como uma data incorreta ou um responsável errado, podem vir de qualquer pessoa que trabalhe com a instância e atualizar seu contexto. A orientação e a personalização — estilo, edições de memória e rotinas de ajuste — cabem exclusivamente ao gerente, o que resolve os conflitos automaticamente: o que o gerente define prevalece. O treinamento altera o piloto automático de uma equipe. Quando o desenvolvedor otimiza o blueprint, isso muda o que cada instância é.

Exemplo: na Contoso, cada colega da equipe define trabalhos permanente em uma única mensagem: um resumo interno de sexta-feira, um rascunho semanal externo que permanece sem ser enviado até que um líder o aprove e um resumo do fim do dia que menciona todos os responsáveis com um item em aberto. O gerente analisa a atividade recente da instância. Quando a instância continua enterrando o ponto principal em suas respectivas recapitulações, o líder o treina uma vez e o novo estilo se mantém.

Desligar a instância – gerente

O desligamento é a única ação na instância irreversível. A conta de usuário do agente é removida, suas associações são revogadas e seu acesso termina imediatamente. Apenas uma equipe é afetada e nenhuma outra instância é tocada. Nada pode ser restaurado.

A decisão pertence ao gerente, e é o único julgamento que ninguém mais pode fazer: se a instância ainda fornece valor suficiente para justificar a execução dela. Os administradores podem agir com base em sinais de toda a frota, mas não conseguem ver se uma única instância ainda justifica seu custo. O desligamento não é uma versão mais robusta dos controles no estágio de operação. Cada controle ali pode ser desfeito, mas o desligamento não, por isso é uma etapa separada.

Exemplo: na Contoso, um fluxo de trabalho é concluído, e seu respectivo responsável desliga a instância. Suas associações são revogadas. Os outros dois gerentes de fluxo de trabalho não são afetados.

Atividades contínuas de projeto e de frota

Duas atividades são executadas durante toda a vida operacional de cada instância: a operação do blueprint do desenvolvedor e o gerenciamento da frota do administrador do locatário.

Operar o blueprint – desenvolvedor

O desenvolvedor rege, observa, avalia e otimiza o blueprint. Observam implantações de produção sem receber conteúdo de conversa privada por padrão. Eles filtram a telemetria por versão e por instância para acompanhar as implantações e executam avaliações em relação ao envelope operacional para o qual o piloto automático foi projetado e testado. As correções são disponibilizadas como novas versões que chegam a todas as instâncias.

Uma nova versão que amplia seus escopos não ignora a governança. As permissões adicionadas voltam a passar pela porta de consentimento. A porta se aplica ao limite, e não à alteração em si, razão pela qual a decisão do administrador do locatário permanece em vigor, em vez de ser pontual.

O desenvolvedor também tem governança no nível do blueprint. Eles podem bloquear o modelo que enviaram e, assim como todos os outros, não podem desbloqueá-lo. Não confunda essa atividade com o treinamento que um gerente faz. O desenvolvedor muda o que cada instância é. Um gerente altera o comportamento de uma instância.

Gerenciar a frota — administrador de locatários

O administrador do tenant monitora, gerencia e protege a frota desde o momento em que um modelo entra em processo de aprovação. Um único Registro lista cada contratação com sua respectiva equipe, blueprint e versão, juntamente com cada ação atribuída à sua respectiva identidade. O administrador detém o maior nível de controle no sistema: bloquear o blueprint interrompe todas as instâncias de uma só vez, pois cada token de instância está vinculado à credencial do blueprint.

Esse controle reflete como os blueprints falham. Um defeito de projeto é sempre sistêmico. Se um gerente de fluxo de trabalho envia um email para fora do locatário, isso não significa que a instância de uma equipe específica esteja apresentando mau funcionamento. Cada instância carrega a mesma falha e aguarda as mesmas condições. O bloco se aplica ao modelo, não à instância que alguém tenha notado por acaso.

Desativar e excluir o blueprint – administrador de locatário e desenvolvedor

Um blueprint tem duas saídas.

• Desativar – um administrador de locatário interrompe novas contratações e o blueprint termina quando nenhuma instância ativa permanece. A desativação impede contratações futuras sem afetar as instâncias atuais.
• Excluir — todas as instâncias criadas a partir do blueprint são removidas junto com ela. Excluir é o equivalente, na camada de blueprint, a um gerente removendo uma única instância.

Essa diferença é a linha que organiza todo o ciclo de vida. Todos os controles nos estágios de operação e as atividades em pé podem ser desfeitos. Não é possível desfazer a exclusão de um blueprint.

Conteúdo relacionado

• O que é um piloto automático no Microsoft Foundry? explica o modelo de identidade e por que os pilotos automáticos usam blueprints.
• Início Rápido: Criar seu primeiro Autopilot abrange provisionamento, criação, publicação, aprovação e contratação de sua primeira instância.
• Integração do Microsoft Agent 365 com o Foundry abrange a sincronização do registro, a coleta de dados e a residência de dados.