A política é um documento Markdown que ONE lê antes de tocar em qualquer coisa. É a diferença entre um ticket parado em uma fila e um ticket sendo trabalhado — publicá-lo é o que ativa a remediação automática.
One coisa a entender antes de escrever uma palavra: uma política só pode retirar coisas. Nenhuma frase nela concede uma ação que o produto já não permita.
Visão geral
Você não começa de uma página em branco. A página da política tem um chat que entrevista você e a redige, e ela redige com base na sua configuração real — seus tipos de problema, seus controles, sua frota — então o resultado nomeia coisas que você realmente tem em vez de um exemplo genérico.
Como usar
- Abra Compliance > Configurações de problemas de conformidade e vá para a política de remediação
- Responda à entrevista. Quais problemas você deseja que sejam trabalhados, até onde ONE deve ir sozinho e como deve se comunicar com os funcionários.
- Edite o rascunho. Ele o escreveu; você é o proprietário. Mude qualquer coisa.
- Publique. O chip muda para Remediação automática: ATIVADA.
O que vai em cada uma das quatro seções
- Escopo. Quais problemas estão incluídos e, mais utilmente, quais estão excluídos. Escreva as exclusões pelo nome exato que elas têm nas suas configurações — é muito mais fácil listar o punhado de coisas que ONE nunca deve tocar do que enumerar tudo o que pode.
- O que ONE faz por conta própria. Os reparos que deve tentar sem ser solicitado, e as situações que deve escalar sem tentar. Pense em termos de quando você preferiria ter um diagnóstico do que uma tentativa.
- Conversando com os funcionários. As circunstâncias que justificam contatar alguém, a linguagem e o registro, e o volume. One mensagem por problema é o padrão — diga aqui se você quiser que seja mais restrito, ou se certas pessoas nunca devem ser contatadas.
- Conhecimento da empresa. Os fatos sobre sua propriedade que mudam como um problema deve ser interpretado: quais distribuições você realmente utiliza, qual site tem uma rede que bloqueia o agente, qual convenção de nomenclatura marca estoque. Esta seção cresce com o tempo — ONE propõe adições e você as aprova.
Uma política para começar
Substitua cada linha disso pela sua própria realidade:
```markdown
Escopo
- Trabalhar problemas de criptografia, atualização de SO, EDR, conta de administrador e entrega de perfil em laptops macOS e Windows.
- Nunca trabalhar problemas em dispositivos no grupo de dispositivos Warehouse — esses estão em estoque e espera-se que estejam offline e não criptografados.
- Nunca trabalhar problemas de bloqueio do iCloud. Roteie-os para o TI sem tocar.
O que ONE faz por conta própria
Reenviar perfis de configuração, reexecutar scripts de controle e reinstalar software ausente sem perguntar.
Devolver ao TI, sem tentar uma correção:
- qualquer dispositivo offline por mais de 7 dias
- qualquer problema em um dispositivo que já teve 3 tickets na mesma regra
- qualquer coisa que precise de uma compra, uma licença ou um novo registro
Conversando com os funcionários
- Escreva para o funcionário apenas quando o sistema operacional precisar deles no teclado e somente depois que tudo remoto tiver sido tentado.
- One mensagem por problema. Escreva na linguagem do funcionário. Nunca nomeie um controle interno ou tela.
- Nunca escreva para funcionários da equipe executiva — encaminhe esses para o TI.
Conhecimento da empresa
- Nossa frota Linux é apenas Ubuntu 22.04 LTS.
- A rede de convidados do escritório de Berlim bloqueia o agente; dispositivos lá sincronizam apenas via VPN.
- Dispositivos nomeados STOCK-* estão em estoque e não têm funcionário designado.
Conviver com isso
- O rascunho e a versão publicada são separados: editar não muda nada até que você publique.
- Despublicar impede novos tickets de irem para ONE, mas os deixa nos que já tem — esses param com uma nota em vez de agir.
- Quando ONE propõe um fato para o conhecimento da empresa e você o aprova, a edição é atribuída a ONE e sua nota registra qual administrador a aprovou. Se o seu rascunho tiver edições não finalizadas naquele momento, ele salva a adição sem publicar e avisa você.
Dicas e melhores práticas
- Escreva Escopo como exclusões. Listar o que evitar é mais curto, mais claro e se mantém melhor do que listar o que permitir.
- Preencha o conhecimento da empresa no primeiro dia, antes do primeiro ticket. O site com a rede bloqueadora, de outra forma, gerará uma série de tickets que parecem todos dispositivos à deriva.
- Mantenha uma mensagem por problema, a menos que você tenha um motivo real. Perseguir é como uma ferramenta útil se torna uma que as pessoas silenciam.
- Use a entrevista uma vez, depois edite o texto. Reentrevistar para pequenas mudanças é mais lento do que editar quatro seções.
Solução de problemas e FAQ
Solução de problemas
-
O assistente não consegue ver suas regras, ou publicar não muda o chip.
Escreva para support@factorial.it com o nome da sua empresa, quando você publicou e uma captura de tela do chip. -
Uma adição de conhecimento foi salva, mas a política não publicou.
Você tem edições de rascunho não finalizadas. Termine ou descarte-as, depois publique. -
Uma frase parece estar sendo ignorada.
Está tentando conceder algo. Políticas só restringem, então uma frase que concede permissão não tem efeito.
FAQ
-
Precisamos usar o assistente?
Não. Ele produz um primeiro rascunho; o documento é seu para reescrever completamente.
-
A política pode autorizar uma exclusão?
Ações destrutivas permanecem fechadas, a menos que a política as abra explicitamente — e uma instrução de ticket nunca as abre por si só.
-
E se nunca publicarmos?
Tickets de conformidade ainda são abertos. Eles apenas permanecem com sua equipe.