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 é redigida de acordo com sua configuração real — seus tipos de problemas, seus controles, sua frota — assim, 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ê quer 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: ATIVADO.
O que vai em cada uma das quatro seções
- Escopo. Quais problemas estão dentro e, mais útil, quais estão fora. Escreva exclusões pelo nome exato que têm em 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 solicitação, e as situações que deve escalar sem tentar. Pense em termos de quando você preferiria ter um diagnóstico do que uma tentativa.
- Falando 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 executa, qual site tem uma rede que bloqueia o agente, qual convenção de nomenclatura marca o estoque. Esta seção cresce ao longo do 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
- Problemas de criptografia de trabalho, atualização de SO, EDR, conta de administrador e entrega de perfil em laptops macOS e Windows.
- Nunca trabalhe problemas em dispositivos no grupo de dispositivos do Armazém — esses estão em estoque e devem estar offline e não criptografados.
- Nunca trabalhe problemas de bloqueio do iCloud. Roteie-os para a 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 à TI, sem tentar um conserto:
- 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
Falando com os funcionários
- Escreva para o funcionário apenas quando o sistema operacional precisar deles no teclado, e somente uma vez que tudo remoto tenha 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 problemas para a 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é você publicar.
- Despublicar impede que novos tickets cheguem a 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 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 envelhece 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, caso contrário, gerará um fluxo de tickets que parecem dispositivos à deriva.
- Mantenha uma mensagem por problema, a menos que você tenha uma razão real. Perseguir é como uma ferramenta útil se torna uma que as pessoas silenciaram.
- Use a entrevista uma vez, depois edite o texto. Reentrevistar para pequenas mudanças é mais lento do que editar quatro seções.
Resolução de Problemas e FAQ
Resoluçã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 foi publicada.
Você tem edições de rascunho não finalizadas. Termine ou descarte-as, depois publique. -
Uma frase parece estar sendo ignorada.
Ela está tentando conceder algo. Políticas estreitam apenas, então uma frase que concede permissão não tem efeito.
FAQ
-
Temos que usar o assistente?
Não. Ele produz um primeiro rascunho; o documento é seu para reescrever completamente.
-
A política pode autorizar uma limpeza?
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 se abrem. Eles apenas permanecem com sua equipe.