Ciclo de vida do Autopilot no Microsoft Foundry

Um piloto automático percorre um ciclo de vida definido. Um administrador do Azure fornece a plataforma, um programador constrói e publica um blueprint, um administrador de tenant aprova-o, e um gestor contrata e executa cada instância. Este artigo descreve cada etapa, o papel que a detém e os pontos em que a responsabilidade passa de uma função para a seguinte.

Como constróis um blueprint em vez de um piloto automático, o ciclo de vida decorre em três camadas: o blueprint que publicas uma vez, as instâncias que as equipas contratam a partir dele e a frota de instâncias que o teu inquilino governa 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 num relance

Quem faz o quê

Quatro funções são responsáveis pelas quatro decisões que definem o piloto automático. Outros papéis são opcionais e aparecem apenas em determinados padrões de implantação.

Mais dois papéis surgem quando esses quatro não conseguem cobrir o terreno sozinhos:

• Um patrocinador executivo de negócios entra quando um executivo quer o piloto automático em toda a organização e financia-o.
• Um gestor de acesso entra quando a pessoa que contrata a instância não pode conceder o que o piloto automático precisa, ou não deveria ser quem julga o privilégio mínimo.

Estas decisões não se sobrepõem, e nada de importante fica por definir entre elas: a infraestrutura em que a plataforma é executada, o papel e as capacidades do modelo, se e como o piloto automático opera no seu ambiente, e a utilização de cada instância. Cada uma das restantes perguntas remete para uma delas.

A decisão do promotor abrange mais do que parece à primeira vista. Não é só o que o piloto automático pode fazer. Inclui também as condições para as quais o piloto automático foi construído e testado, que formam o envelope operacional em que todos os outros cargos confiam quando o aprovam e contratam. Quando um piloto automático falha fora desse envelope, a falha depende se o envelope alguma vez foi declarado.

Responsabilização comparada com governação

A governação determina quem pode travar uma instância e, por design, quase toda a gente pode. A responsabilidade determina quem é obrigado a impedi-la. A responsabilidade é sempre do gestor, independentemente de quem tenha a culpa, porque um piloto automático avariado não deve continuar a funcionar enquanto o seu gestor espera que outra pessoa intervenha.

Uma falha de acesso mostra a diferença de forma mais clara. Um gestor de acesso configura uma concessão que o gestor nunca fez, e a instância comporta-se mal por causa disso. O gerente continua a ser obrigado a impedir isso. Culpa e obrigação mantêm-se separadas por design.

Outros participantes

Dois grupos não são responsáveis por qualquer decisão, mas continuam a ser importantes.

Membros da equipa utilizam o Autopilot onde a equipa já trabalha: no Teams, no correio eletrónico e nos comentários dos documentos. Atribuem-lhe tarefas em permanência e fazem correções objetivas que atualizam a sua ancoragem.

Contactos de negócio são outros contactos na mesma tarefa. Não configuram nada e não respondem a nada, mas podem observar a instância e bloqueá-la. Eles não podem apagar ou transferir. Esse design é intencional: qualquer pessoa suficientemente próxima da obra para ver o piloto automático comportar-se mal deve conseguir pará-la. O gestor é o único papel que governa o piloto automático e o usa diariamente, razão pela qual a obrigação de o parar recai sobre eles.

Qualquer pessoa no tenant fora da audiência configurada não é companheira de equipa. Quem não faz parte da equipa é bloqueado por predefinição, antes de o Autopilot sequer invocar um modelo.

Como os padrões de implementação mudam os papéis

O padrão de piloto automático que escolhes determina quais os papéis que aparecem.

• Piloto automático de grupo — envolve todas as funções. É neste padrão que a divisão do gestor de acesso mais importa, porque a pessoa que pode conceder um projeto Azure DevOps raramente é o líder da equipa que trabalha com a instância.
• Autopilot para toda a empresa — tem uma única instância e um único gestor responsáveis por toda a organização, pelo que "membro da equipa" deixa de ser uma distinção relevante.
• Piloto automático pessoal — envolve apenas o programador, que normalmente é o gestor e o único utilizador.

Como as camadas se encaixam

O ciclo de vida funciona em três camadas ao mesmo tempo.

• Blueprint — funciona uma vez, desde o provisionamento até à aprovação. Após a aprovação, o trabalho do programador continua como uma atividade permanente que abrange a vida útil de cada instância e termina apenas quando o blueprint é eliminado. A otimização reintroduz novas versões na fase de construção.
• Instância — funciona uma vez por contratação. Muitas instâncias estão ativas ao mesmo tempo, pelo que uma equipa pode retirar uma instância de serviço enquanto outra equipa cria outra a partir do mesmo modelo.
• Fleet — não é um palco. É a atividade permanente do administrador inquilino, e começa com a aprovação, porque é aí que a frota começa a existir.

A aprovação é o ponto em que um modelo aprovado dá origem a muitas instâncias. Eliminar o modelo propaga-se a todas as instâncias criadas a partir dele.

As atividades em pé são descritas após as fases de instância, porque é nesse ponto que têm algo a abranger.

Um único exemplo percorre cada etapa: um gestor de fluxo de trabalho, construído por uma equipa de plataforma e contratado por várias equipas. Os parágrafos de exemplo são rotulados como Exemplo e são opcionais.

A camada de esquema

As etapas do plano são executadas uma única vez. Cada instância criada a partir do blueprint herda os seus resultados.

Provisionar infraestrutura — administrador e programador do Azure

O administrador do Azure configura o ambiente e dá aos programadores as permissões mínimas necessárias para construir, testar e implementar nele. Esta configuração aplica-se ao ambiente, não ao piloto automático. Acontece uma vez, e todos os modelos aí criados herdam isso.

O administrador do Azure também prevê o que este piloto automático específico precisa para funcionar, como armazenamento para itens rastreados e memória, e concede à identidade incorporada do piloto automático acesso a esses recursos. Esta infraestrutura pertence ao blueprint, não aos dados de nenhuma equipa. Provisionar recursos e atribuir permissões são as duas coisas que os programadores não conseguem fazer por si próprios. O administrador do Azure é o único papel que termina antes de o piloto automático chegar ao utilizador: o seu trabalho termina quando o desenvolvimento pode começar.

Exemplo: Na Contoso, o administrador do Azure cria uma conta e um projeto no Foundry e implementa os modelos. Criam um Azure Container Registry, um espaço de trabalho do Log Analytics e o Application Insights, com ligações de projeto para o Azure Container Registry e o Application Insights. A identidade gerida pelo projeto recebe o AcrPull e o Log Analytics Reader. Também criam uma conta de armazenamento com duas tabelas, uma para a lista de permissões de mensagens diretas e outra para itens de trabalho rastreados. Após a criação do agente, é atribuída à sua identidade a função de Contribuidor de Dados de Tabelas de Armazenamento. Cada programador recebe o Foundry User atribuído ao projeto, o AcrPush ao registo e o Monitoring Reader.

Compilar e publicar — desenvolvedor

O programador define o papel e as capacidades do blueprint: o que faz, como se comporta — quando responde, quando permanece em silêncio, quando pede aprovação — e o que nunca deve fazer. A plataforma oferece capacidades fundamentais como memória, rotinas e autoaperfeiçoamento, pelo que o programador as habilita e configura em vez de as construir. Uma instância de desenvolvimento permite ao programador iterar sem ter de voltar a introduzir a aprovação do inquilino para cada alteração.

A publicação regista também os âmbitos de permissão declarados e dois limites máximos: quem pode recorrer ao piloto automático e o nível de acesso mais amplo que qualquer gestor pode conceder posteriormente. Juntamente com as condições para as quais o piloto automático foi construído e testado, estes valores constituem o envelope operacional em que cada função a jusante confia.

Nada nesta fase dá acesso a nada. Estes valores são apenas declarações. A publicação coloca o modelo perante a governação; não põe o modelo em prática.

Exemplo: Na Contoso, o gestor de fluxo de trabalho recebe ferramentas Azure DevOps com identity passthrough, as ferramentas Microsoft 365 integradas e um rastreador personalizado de itens de trabalho. A sua lógica de resposta decide quando fala num canal e quando permanece em silêncio. O piloto automático recusa chats de grupo que incluam participantes não aprovados e devolve uma resposta no-op fixa a mensagens entre inquilinos. Antes de publicar, o programador declara os âmbitos que requerem consentimento e define os dois limites máximos.

Aprovar, configurar e dar consentimento — administrador do inquilino

Esta fase é um portão com três ações. O administrador do inquilino revê o plano publicado, concede consentimento aos seus âmbimos declarados, aprova-o e seleciona quem pode contratá-lo. O consentimento e a seleção do contratador são decisões separadas com consequências distintas: um administrador pode aprovar um plano enquanto consente apenas com parte do que foi solicitado.

É nesta fase que é tomada a decisão ao nível da frota: se o Autopilot pode operar no seu tenant e ao abrigo de que política. O consentimento governa o token, que determina que tipos de chamadas o piloto automático pode fazer. Não concede dados de equipa a ninguém.

Cada novo modelo e cada alargamento do âmbito passam novamente por esta etapa, por isso inclua tempo para a revisão do administrador nos seus planos de implementação.

Exemplo: Na Contoso, o administrador abre o pedido pendente do gestor do fluxo de trabalho no Centro de administração do Microsoft 365, aprova o conjunto de âmbitos, publica-o e nomeia os líderes de equipa da organização como responsáveis elegíveis pela contratação.

A aprovação permite a contratação

A aprovação é a condição de saída para toda a camada de blueprint: pelo menos um gestor pode agora contratar uma instância. É o único ponto onde a camada blueprint e a camada de instância se encontram. Tudo até este ponto declara e dá o seu consentimento à capacidade. Nada foi concedido ainda. Um piloto automático pode segurar todos os telescópios necessários e ainda assim não receber qualquer dado.

A camada de instância

As fases de instância funcionam uma vez por contratação. Muitas instâncias decorrem ao mesmo tempo, cada uma no seu próprio palco.

Contratação — gerente

Contratar é uma ação única, não uma fase. Cria dois objetos:

• Uma identidade de agente, um principal de serviço que autentica e detém permissões.
• Uma conta de utilizador agente, que contém uma caixa de correio, presença no Teams, um lugar no organigrama e um gestor.

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

Exemplo: Na Contoso, três líderes de equipa contratam três gestores de fluxo de trabalho a partir do mesmo blueprint. Um design é agora uma frota, e a partir deste ponto tudo acontece três vezes, de forma independente.

A bordo — gestor

A integração é onde o emprego realmente começa. O gestor configura cinco definições.

Os subsídios de acesso — adesão a grupos de segurança, um projeto Azure DevOps, um site SharePoint — são a primeira concessão de recursos empresariais em qualquer parte do ciclo de vida. Transformam um plano sólido num colega de equipa plenamente funcional.

Cada público começa apenas com o gestor e estende-se até ao limite máximo do programador, sem ir além disso. Qualquer pessoa no inquilino que esteja fora do público configurado é bloqueada por predefinição, e o Autopilot nunca invoca um modelo em nome dessa pessoa.

Consentimento e acesso são portões diferentes. Os escopos e o consentimento governam o token, que determina que tipos de chamadas são permitidas. A pertença a grupos e as funções regem a conta, que determina a que dados essas chamadas podem aceder. O Microsoft Entra ID impõe a primeira barreira. Cada recurso faz cumprir o segundo nível de controlo com base nas suas próprias listas de membros e nunca verifica se existe consentimento. No caso de uma pessoa, a TI fecha ambos os acessos muito antes do seu primeiro dia. No modo automático, ambas as etapas são novas no momento da contratação, pelo que a integração inclui tarefas que dão a sensação de que já deviam estar concluídas.

A autorização começa aqui, mas nunca termina. As equipas mudam, os recursos mudam e os subsídios são revogados. O piloto automático acaba por precisar de um site SharePoint que ninguém antecipou na contratação.

Quando a pessoa que está a contratar não consegue fazer estas concessões, a fase divide-se. Os gestores são profissionais do conhecimento que, muitas vezes, não têm permissões para adicionar uma conta a um grupo de segurança ou a uma organização do Azure DevOps, e o princípio do menor privilégio é uma decisão em matéria de segurança que a maioria dos líderes de equipa nunca teve de tomar. Um gestor de acesso assume esta etapa: contrata, integra e autoriza a instância, depois transfere o papel de gestor para o líder que trabalha com ela. A decisão de emprego em si não avança.

Exemplo: na Contoso, um líder define o seu fluxo de trabalho como colegas de equipa e os líderes de engenharia e produto como líderes de negócio. Adicionam a conta do agente ao grupo de segurança e à lista de distribuição da equipa, o que lhe concede acesso ao projeto do Azure DevOps e ao site do SharePoint, e dão-lhe permissão de escrita na organização do GitHub. Noutra equipa, o líder não pode conceder o projeto Azure DevOps, por isso um gestor de acesso integra a instância e entrega o papel de gestor.

Operações — gestor, colegas de equipa e responsáveis de negócio

Quatro atividades decorrem ao mesmo tempo enquanto a instância existe, e cada atividade envolve um conjunto diferente de papéis.

Utilização — colegas de equipa e gestor. O piloto automático desempenha o seu papel em todas as superfícies configuradas, incluindo mensagens diretas do Teams, chats de grupo e canais, emails e comentários de documentos. O seu contexto abrange todas as interações, independentemente da superfície ou do utilizador. Os colegas de equipa atribuem rotinas, que são instruções permanentes dadas numa única mensagem.

Observe — gestores e líderes de negócios. Analisam o que a instância fez, para quem, a que custo, e se algo precisa de ser investigado. É aqui que a responsabilização no dia a dia acontece.

Governar — gestores e líderes de negócios. Estes controlos são todos reversíveis: apertar o acesso, revogar o acesso ou bloquear a instância. Governar resulta da observação, porque bloqueias em resposta a algo que viste. O bloqueio é intencionalmente assimétrico. Qualquer pessoa suficientemente próxima da operação para identificar um problema pode parar a instância, mas só um administrador do inquilino a pode reiniciar.

Treina e personaliza — gestor. A melhoria surge através de dois canais desiguais. Correções objetivas, como uma data incorreta ou um proprietário incorreto, podem ser feitas por qualquer pessoa que trabalhe com a instância e atualizam a sua base factual. O coaching e a personalização — estilo, edições de memória e rotinas de moldagem — pertencem apenas ao gestor, que resolve automaticamente os conflitos: o que o gestor define mantém-se. O treino altera o piloto automático de uma equipa. Quando o desenvolvedor otimiza o blueprint, altera o que cada instância é.

Exemplo: Na Contoso, cada colega de equipa configura tarefas permanentes na mesma mensagem: um resumo interno de sexta-feira, um rascunho semanal externo que fica por enviar até ser aprovado por um responsável e um resumo de fim do dia que menciona todos os responsáveis com um item pendente. O gestor analisa a atividade recente da instância. Quando a instância continua a enterrar o ponto principal nos seus resumos, o líder orienta-a uma vez e o novo estilo mantém-se.

Remover a instância — gestor

O offboarding é a única ação de instância irreversível. A conta de utilizador do agente é removida, as suas associações são revogadas e o seu acesso termina imediatamente. Apenas uma equipa é afetada, e nenhuma outra instância é afetada. Nada pode ser restaurado.

A decisão pertence ao gestor, e é o único julgamento que mais ninguém pode fazer: se a instância ainda oferece valor suficiente para justificar a sua execução. Os administradores podem agir com base em sinais ao nível de toda a frota, mas não conseguem ver se uma instância individual ainda justifica o seu custo. O offboarding não é uma versão mais forte dos controlos na fase de operação. Todas as ações nessa etapa podem ser anuladas, mas o processo de saída não, pelo que é uma etapa separada.

Exemplo: Na Contoso, um fluxo de trabalho termina e o seu líder desliga a sua instância. As suas subscrições foram revogadas. Os outros dois gestores do grupo de trabalho não são afetados.

Plano permanente e atividades da frota

Duas atividades decorrem durante toda a vida útil de cada instância: a operação do projeto pelo promotor e a gestão da frota pelo administrador do inquilino.

Executar o modelo — programador

O programador governa, observa, avalia e otimiza o blueprint. Observam implementações em produção sem receber, por predefinição, conteúdo de conversas privadas. Filtram a telemetria por versão e por instância para monitorizar os lançamentos, e fazem avaliações contra o envelope operacional para o qual o piloto automático foi construído e testado. As correções são disponibilizadas como novas versões que são distribuídas por todas as instâncias.

Uma nova versão que expande o seu âmbito não contorna a governação. As permissões adicionadas obrigam a voltar a passar pelo ecrã de consentimento. A restrição aplica-se ao teto, e não à alteração em si, razão pela qual a decisão do administrador do inquilino se mantém em vigor, em vez de ser pontual.

O programador também tem governação ao nível do plano. Podem bloquear o plano que enviaram e, como toda a gente, não podem desbloqueá-lo. Não confundas esta atividade com o coaching que um gestor faz. O programador altera aquilo que cada instância é. Um gestor altera o comportamento de uma instância.

Gerir a frota — administrador de inquilinos

O administrador inquilino observa, governa e assegura a frota desde o momento em que um plano é aprovado. Um único registo lista cada contratado com a sua equipa, modelo e versão, bem como todas as ações atribuídas à sua identidade. O administrador detém o controlo mais alargado sobre o sistema: bloquear o modelo pára todas as instâncias de uma só vez, porque cada token de instância remete para a credencial do modelo.

Esse controlo reflete a forma como os projetos falham. Um defeito de planta é sempre sistémico. Se um gestor de fluxo de trabalho enviar e-mails para fora do tenant, isso não significa que uma instância de uma equipa esteja a comportar-se incorretamente. Cada instância tem a mesma falha e aguarda as mesmas condições. O bloco aplica-se ao projeto, não à instância que alguém por acaso notou.

Desativar e eliminar o esquema — administrador do inquilino e programador

Um plano tem duas saídas.

• Desativar — um administrador do inquilino impede novas adesões, e o blueprint termina quando deixarem de existir instâncias ativas. A descontinuação impede novas contratações sem afetar as instâncias atuais.
• Eliminar — todas as instâncias criadas a partir do blueprint são removidas com ele. Delete é o equivalente, ao nível do blueprint, à remoção de uma única instância por um gestor.

Essa diferença é a linha que organiza todo o ciclo de vida. Todos os controlos nas fases de operação e nas atividades permanentes podem ser anulados. Apagar um plano não pode.

Conteúdo relacionado

• O que é um autopilot no Microsoft Foundry? explica o modelo de identidade e por que razão os autopilots usam modelos.
• Início rápido: Crie o seu primeiro Autopilot abrange o provisionamento, a criação, a publicação, a aprovação e a ativação da sua primeira instância.
• A integração do Microsoft Agent 365 com o Foundry cobre sincronização de registos, recolha de dados e residência de dados.