archi bot Documentação do produto

Esta tradução é gerada por máquina (beta). O guia em inglês é a fonte oficial.

Operadores

Administração de locatário para operadores

Opere a superfície de Acesso do operador — escolha o limite da conta e, em seguida, trabalhe membros, permissões, destinos de espaços de trabalho, política de cobrança, SSO e evidências de integração a partir de uma única mesa gerenciada pelo Console.

Operadores de plataformaAdministradores de plataformaAdministradores de cliente

Última atualização

Superfície de Acesso do operador renderizada pelo Console com dados seguros, mostrando a mesa de operações do cliente sem tokens de serviço ou segredos expostos.
Exemplo renderizado pelo Console com dados seguros: os operadores gerenciam a mesa de operações do cliente a partir de uma única rota. Tokens de serviço e credenciais nunca são exibidos aqui.

Para que serve a superfície de Acesso

A superfície do operador em /tenants é intitulada Operações de acesso no Console, e a área de trabalho dentro dela é a Mesa de operações do cliente. É uma única rota gerenciada pelo Console onde as equipes de plataforma escolhem um limite de conta uma vez e, em seguida, executam todo o ciclo de entrega: escopo de acesso e identidade, membros e permissões, roteamento de destinos de espaços de trabalho, prontidão de cobrança, ambientes persistentes, evidências do Shared Drive e showback de uso.

A mesma rota mostra uma visão de autoatendimento aos administradores de cliente para que possam confirmar seu acesso, enviar detalhes de SSO, trabalhar a lista de verificação de integração e convidar sua equipe. Os rótulos e as ações disponíveis mudam conforme seu papel: operadores e administradores de plataforma veem suporte multicliente e trabalho de configuração aprovado, enquanto administradores de cliente veem apenas sua própria conta.

Use-a como controle de lançamento. Aprove o limite da conta, a barreira de cobrança, o acesso do locatário, o roteamento de destinos e a transferência de uso antes que um cliente comece a criar espaços de trabalho.

Escolha primeiro o escopo

Sempre confirme o cliente faturável, o locatário e o escopo de membros antes de alterar qualquer coisa. A maioria das ações tem escopo de cliente e impõe o cliente selecionado quando há um presente. Em um cluster novo, execute primeiro o bootstrap e a verificação de escopo — ela responde como quem você está conectado, qual conta de cliente você está gerenciando, onde os espaços de trabalho serão executados e se o uso pode ser atribuído a esse cliente — antes de testar fluxos posteriores de espaço de trabalho ou cobrança.

Se os rótulos de acesso de SSO estiverem vazios, páginas posteriores como o Analytics podem não saber qual escopo de cliente usar. Reentre via SSO antes de testar a criação de espaços de trabalho.

Subguias ao longo da mesa

A Mesa de operações do cliente agrupa seu trabalho em subguias ao longo do topo da superfície. Mova-se por elas aproximadamente nesta ordem durante um lançamento.

SubguiaO que você faz lá
OverviewConfirme o limite ativo de cliente ou locatário e salte para as superfícies que gerenciam suporte, revisão, ambientes, armazenamento, cobrança e auditoria.
CustomersRegistros de clientes, política de cobrança, integração e transferência de API.
MembersA lista de membros do cliente e do locatário.
PermissionsPolítica de recursos e metapermissões por associação.
TargetsRoteamento de espaços de trabalho e aliases de modelos.
OnboardingLista de verificação, configuração de SSO, ciclo de vida e histórico de notificações.

As faixas do Overview espelham o ciclo operacional: acesso do cliente, alteração revisada, evidência de QA, ambiente candidato, promoção e revisão de cobrança. As ações rápidas no Overview abrem Customers, Members, CI & Review, Environments, Shared Drive, política de cobrança, Analytics e histórico de auditoria.

Disponibilidade de ações (o mapa CRUD)

O selo do mapa CRUD mostra quais caminhos de criação, atualização e exclusão são alcançáveis na sessão atual e por que os demais não são. Leia-o quando uma ação parecer ausente. Por exemplo, ele explica que as contas de cliente ainda não têm rota de exclusão — mova o ciclo de vida para suspenso, desligamento (offboarding) ou fechado em vez disso — e que algumas ações são restritas a operadores porque impulsionam cobrança, atribuição ou o limite da conta.

Algumas entradas que vale a pena conhecer:

  • Conta de cliente — apenas para operadores, porque o registro da conta impulsiona cobrança, ciclo de vida e atribuição. Administradores de cliente podem enviar dados de integração, mas não podem alterar o registro faturável.
  • Members — criar, atualizar e excluir exigem direitos de administrador de locatário; rotas com escopo de cliente impõem o cliente selecionado.
  • Chaves de API do Archibot — disponíveis na etapa de transferência ao cliente. Segredos brutos são exibidos uma única vez.
  • Notifications — administradores de cliente podem ler seu histórico de notificações; o envio permanece restrito a operadores.

Ajuda no aplicativo

Cada painel traz um controle de ajuda contextual. A ação Explicar operações de acesso abre uma caixa de diálogo que reformula as quatro perguntas de configuração e um glossário em linguagem simples: uma conta de cliente é a empresa faturável, um locatário é a fatia de acesso ao Console para essa empresa, um destino de espaço de trabalho é o cluster de execução onde os espaços de trabalho são executados, e uma chave de API é a forma como o Archibot ou a automação chama a API com escopo de cliente. A caixa de diálogo é contexto somente leitura; fechá-la o retorna ao mesmo escopo. Use-a quando não tiver certeza se um rótulo ausente ou um escopo vazio está bloqueando um teste posterior.

Guias Customers e de integração

Abra a subguia Customers para trabalhar uma única conta. Cada registro de cliente carrega sua própria faixa de guias:

  • Profile — identidade da conta.
  • Plan — ciclo de vida, padrões e nível de serviço.
  • Onboarding — lista de verificação e histórico do ciclo de vida.
  • Billing — revisão de cobrança e política de preços.
  • API — acesso à API com escopo de cliente.

A guia Onboarding abre suas próprias subguias: Details (contexto da conta e contatos), SSO setup (compartilhar ou revisar metadados do IdP), Checklist (o registro de lançamento compartilhado), Lifecycle (histórico de estados) e Notifications (histórico duradouro de notificações). O status e as notas da lista de verificação se tornam o registro de lançamento compartilhado em vez de e-mail ou chat por canais paralelos.

Membros e permissões

Na subguia Members, os operadores podem convidar, criar, atualizar, transferir, desabilitar e remover membros dentro do locatário selecionado. (Administradores de cliente podem convidar, criar, atualizar, desabilitar e remover, mas não transferir.) Use o administrador de locatário com moderação — a maioria dos usuários deve ser membro do locatário, a menos que gerenciem convites ou evidências de integração.

A subguia Permissions abre o editor de Políticas de permissão, que define o acesso derivado do papel, as permissões de recursos personalizadas e as metapermissões para cada associação no escopo selecionado.

Editor de Políticas de permissão do Console com métricas de Controles de política à esquerda e o Editor de política de membro à direita.

Trabalhe o editor em três movimentos:

  1. Use Controles de política e Filtros e busca para restringir a lista e, em seguida, escolha um membro. Os blocos de métricas (Modelos de papel, Políticas personalizadas, Concessões meta, Administradores) mostram como o escopo está distribuído.
  2. No Editor de política de membro, escolha o Modo de política. Modelo de papel calcula as permissões efetivas a partir do papel e do status selecionados; Concessões personalizadas salva os arrays de recursos e metapermissões diretamente na associação.
  3. Aplique uma Concessão predefinida como pacote inicial, ajuste concessões individuais na matriz de recursos e, em seguida, escolha Salvar política. Use Limpar seleção para voltar sem salvar.

As concessões predefinidas dão um pacote conhecido que você pode ajustar:

  • Administrador de locatário — administração completa do locatário e do cliente com delegação controlada.
  • Líder de espaço de trabalho — ciclo de vida do espaço de trabalho, gravação no Shared Drive e gestão de revisão de CI.
  • Gerente de cobrança — Analytics, faturas, limites de gasto e preços de recursos sem controle do espaço de trabalho.
  • Auditor — visibilidade somente leitura em todas as operações além de autoridade de exportação de auditoria.

As metapermissões controlam quem pode delegar papéis, conceder ou revogar permissões, aprovar exceções, gerenciar modelos de política, aprovar acesso de suporte, exportar evidências de auditoria ou aprovar elevação de emergência (break-glass). Conceda-as apenas a associações que administram a política de acesso. Cada concessão de recurso é salva por ID de permissão estável para que a futura imposição do backend consuma a mesma política.

Destinos de espaços de trabalho e padrões

O Create Workspace só pode rotear espaços de trabalho para uma conta depois que um destino de espaço de trabalho é anexado, portanto anexe um destino antes da criação de espaços de trabalho do cliente. Na subguia Targets, você confirma a URL de execução do espaço de trabalho, o modo de autenticação do destino, os aliases de modelos e os provedores de Git suportados. Os aliases de modelos mantêm estáveis os nomes visíveis ao cliente; os campos de token de serviço nos destinos permanecem apenas para operadores.

Use Padrões do espaço de trabalho para definir os valores em nível de organização com os quais o Create Workspace deve começar para este cliente.

Cobrança e preços de recursos

A guia Billing cobre a prontidão de cobrança, a transferência para o Stripe e a política de preços de recursos. O estado de cobrança é a barreira de criação de espaço de trabalho: registre o trilho de pagamento e marque a conta como teste aprovado ou verificada antes da criação de espaços de trabalho do cliente.

Painel de Política de preços de recursos do Console com origem da política, substituições do cliente, chaves padrão e os presets de estimativa Piloto, Equipe e Empresa.

A Política de preços de recursos sobrepõe os padrões de implantação para a contabilidade de Analytics e excedentes de um único cliente. O painel mostra a origem da política, quantas chaves estão explicitamente definidas para o cliente e as chaves padrão de base da configuração de implantação. Substitua os termos do cliente aqui apenas quando uma cotação, plano de serviço ou acordo empresarial usar alocações ou tarifas diferentes e, em seguida, escolha Salvar política.

Os presets de preços estimados dão pontos de partida de lançamento que você pode ajustar antes de cotar:

  • Piloto — alocação inicial para uma equipe de implementação validando CI, revisão, QA e um Shared Drive pequeno.
  • Equipe — alocação de trabalho para uma equipe de cliente ativa com ciclos repetidos de revisão/QA e uso moderado do Shared Drive.
  • Empresa — alocação maior para planejamento de implantação multiequipe, QA intenso e maior armazenamento de ambientes persistentes.

Use Começar a partir dos padrões de implantação para redefinir o editor. Registre o rótulo da versão do modelo de preços para a cotação ou revisão de política. O Stripe continua sendo a fonte autoritativa para faturas, pagamentos e registros de receita — as entradas de preços do Console são termos de operador ou de cliente, não payloads de provedor, e os eventos de fatura do Stripe atualizam o histórico de pagamentos automaticamente.

Configuração de SSO

Os administradores de cliente enviam o tipo de IdP, domínios, claims, grupos, URLs de callback e usuários de teste na guia SSO setup para que a ISM possa mapear o acesso com segurança. Para OIDC, colete URLs de discovery; para SAML, colete URLs de metadados e detalhes de validação de callback. Os operadores revisam os metadados enviados na mesma guia. Os rótulos de acesso de SSO vêm do provedor de identidade e determinam qual visão geral, ações de configuração e escopo de cliente o Console expõe.

Mantenha os dois pacotes de notas separados

  • Detalhes enviados pelo cliente e Contexto de lançamento da ISM são visíveis ao cliente. Use-os para contexto que o cliente pode revisar com a ISM.
  • Notas internas do operador são apenas da ISM e não devem aparecer nas respostas de integração com escopo de cliente.

Em cada campo — visível ao cliente ou interno — mantenha fora credenciais, detalhes de pagamento, chaves privadas e links de convite. O ciclo de vida de integração e o histórico de notificações são registros duradouros; o envio de e-mail permanece restrito por trás do remetente de notificações.

Guias relacionados

Concluído quando

  • O escopo de cliente e locatário selecionado está correto antes de qualquer alteração.
  • O contexto visível ao cliente e as notas internas do operador são mantidos em seus próprios pacotes.
  • Um destino de espaço de trabalho é anexado antes de um cliente criar espaços de trabalho.
  • Credenciais, detalhes de pagamento, chaves privadas e links de convite ficam fora de cada campo.