ONE trabalha dentro de um limite rígido que sua política não pode expandir. Este artigo traça esse limite: o piso do que sempre faz, o teto do que nunca faz, e o meio-termo que sua política realmente controla.
Visão geral
Leia isto antes de escrever uma política. Saber onde estão o piso e o teto diz quais das suas frases farão algo e quais já estão garantidas — ou já são impossíveis.
O piso: seis coisas que faz em cada execução
Nenhuma dessas é opcional e nenhuma pode ser desligada.
- Ele vai para o problema, não para o título. O título do ticket é um rótulo; a decisão vem do status exato e da evidência que o dispositivo reportou.
- Ele verifica seu mandato. Nenhuma política publicada significa nenhuma ação, em nada.
- Ele relê o dispositivo antes de concluir. Este ponto é mais importante do que parece: uma grande parte dos dispositivos "não conformes" são configurações que ainda estão em andamento, não dispositivos que se desvirtuaram.
- Ele olha além do único ticket — para os outros problemas abertos do dispositivo e para o que aconteceu com este dispositivo e esta regra antes. Doze tickets compartilhando uma causa são reportados como uma única causa.
- Ele confirma no dispositivo, não em sua própria despachagem. Um push que foi aceito não é uma correção até que o dispositivo diga que sim.
- Ele escreve uma nota. Primeira linha: o que aconteceu. Última linha: a única coisa que resta para você.
O meio: o que realmente pode fazer
Reaplicando a correção. Qualquer que seja o controle usado originalmente — um perfil, um script, uma instalação de software, um agente executor — ele repete esse mesmo mecanismo. A maioria das execuções é apenas isso, e ninguém fora de TI percebe.
Escrevendo para o/a funcionário/a, mas apenas sob restrições reais. Ele escreve quando o sistema operacional precisa de uma presença humana e nada remoto resta para tentar. Então: uma mensagem, uma instrução, a linguagem do/a funcionário/a, nenhuma terminologia interna, e nunca mais para aquele problema. Ele pede uma reinicialização; não realiza uma. Um dispositivo sem funcionário/a designado/a não recebe mensagem alguma.
O teto: onde para
Dois tipos diferentes de parada, e vale a pena diferenciá-los.
Para porque só você pode decidir — o ticket volta com o diagnóstico já feito:
| Situação | Por que precisa de você |
| Edição de SO inadministrável | Nada para empurrar |
| Hardware abaixo do que a correção precisa | Nada para empurrar |
| Precisa de uma compra, licença ou credencial | Não é ONE para gastar ou segurar |
| Precisa de um novo registro | Uma decisão administrativa |
| EDR nunca implantado | Nada para reparar |
| Offline, ou registrado em outro lugar | Fora de alcance |
Para porque é proibido — nenhuma frase da política abre essas por conta própria:
- Limpar, bloquear, aposentar ou desregistrar um dispositivo
- Fechar ou reabrir um ticket por iniciativa própria
- Tocar em um segundo dispositivo, por mais semelhante que seja
- Editar o controle ou a regra para que o problema desapareça
- Reportar uma correção que não foi confirmada no dispositivo
- Continuar escrevendo para alguém que pediu um humano
One execução, um escopo: One ticket. One problema. One dispositivo. One tentativa por mecanismo. One mensagem.
Uma execução que termina com o problema ainda aberto é um resultado correto, não uma falha — e a nota diz isso em vez de disfarçá-lo.
Dicas e melhores práticas
- Leia o teto antes de escrever sua política. A maior parte do que as pessoas querem proibir já está proibido, e o resto não pode ser concedido.
- Trate um ticket devolvido como trabalho finalizado. O diagnóstico é o entregável; a decisão sempre seria sua.
- Quando uma regra te sobrecarrega, abra um ticket e leia sua nota. Ele já correlacionou os problemas, e a resposta geralmente é um controle que não pode ser aplicado àqueles dispositivos.
- Planeje seu próprio acompanhamento para mensagens de funcionários/as. One por problema é deliberado — ninguém está atrás disso.
Resolução de problemas e FAQ
Resolução de problemas
-
Uma nota apareceu, mas o dispositivo não foi tocado.
Trabalhe através de três causas em ordem: nenhuma política publicada, um controle sem nada repetível por dispositivo, ou um dispositivo que está offline. Ele devolve dispositivos offline em vez de colocar trabalho neles. -
Os tickets continuam reaparecendo no mesmo dispositivo e regra.
Leia a nota mais recente — ela os correlaciona e nomeia a causa compartilhada, que é quase sempre um controle que não pode ser aplicado ali. -
Um/a funcionário/a respondeu e nada se moveu.
Respostas de funcionários/as carregam informações, nunca instruções. Apenas uma nota interna de um/a administrador/a direciona isso.
FAQ
-
Uma política pode permitir que ele limpe um dispositivo?
Apenas se a política abrir explicitamente ações destrutivas. Sua própria leitura de um ticket nunca as abre.
-
Ele continuará lembrando um/a funcionário/a?
Não — uma mensagem por problema, e ele para completamente se alguém pede um humano.
-
Como ele sabe que uma correção funcionou?
Ele relê o dispositivo. Um push bem-sucedido do lado dele não conta.