ONE opera dentro de um limite rígido que a 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 a sua política realmente controla.
Visão Geral
Leia isso 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 das evidências que o dispositivo relatou.
- 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 a caminho, não dispositivos que se desviaram.
- Ele olha além do único ticket — para os outros problemas abertos do dispositivo e para o que aconteceu neste dispositivo e nesta regra antes. Doze tickets compartilhando uma causa são relatados como uma causa.
- Ele confirma no dispositivo, não em sua própria despachagem. Um empurrão 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 pode realmente fazer
Reaplicando a correção. Seja qual for o controle usado originalmente — um perfil, um script, uma instalação de software, um agente executor — ele repete o mesmo mecanismo. A maioria das execuções não é nada além disso, e ninguém fora da TI percebe.
Escrevendo para o funcionário, mas apenas sob restrições reais. Ele escreve quando o sistema operacional precisa de um humano presente e nada remoto resta para tentar. Então: uma mensagem, uma instrução, a linguagem do funcionário, sem terminologia interna, e nunca mais para aquele problema. Ele pede um reinício; não realiza um. Um dispositivo sem funcionário designado 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 manter |
| Precisa de um novo cadastro | Uma decisão de administrador |
| EDR nunca implantado | Nada para reparar |
| Offline, ou cadastrado em outro lugar | Fora de alcance |
Para porque é proibido — nenhuma frase de política abre essas situações por sua própria leitura:
- Limpar, bloquear, aposentar ou cancelar o cadastro de 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
- Relatar uma correção que não confirmou no dispositivo
- Continuar a escrever 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 enfeitá-la.
Dicas e melhores práticas
- Leia o teto antes de escrever sua política. A maioria do que as pessoas querem proibir já é proibido, e o resto não pode ser concedido.
- Trate um ticket devolvido como trabalho concluído. O diagnóstico é o entregável; a decisão sempre seria sua.
- Quando uma regra o sobrecarrega, abra um ticket e leia sua nota. Ele já correlacionou-os, e a resposta geralmente é um controle que não pode executar sobre aqueles dispositivos.
- Planeje seu próprio acompanhamento para mensagens a funcionários. One por problema é deliberado — ninguém está atrás disso.
Solução de Problemas e FAQ
Solução de Problemas
-
Uma nota apareceu, mas o dispositivo não foi tocado.
Trabalhe através de três causas na 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. -
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 executar ali. -
Um funcionário respondeu e nada se moveu.
Respostas de funcionários carregam informações, nunca instruções. Apenas uma nota interna de um administrador 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 funcionário?
Não — uma mensagem por problema, e ele para completamente se alguém pedir um humano.
-
Como ele sabe que uma correção funcionou?
Ele relê o dispositivo. Um empurrão bem-sucedido do lado dele não conta.