La auto remediación pone a ONE a cargo de sus tickets de cumplimiento. Funciona a partir de la evidencia en lugar del título, vuelve a intentar lo que hizo el control original, contacta al/la empleado/a solo donde la solución realmente requiere que alguien esté frente a la máquina, y devuelve cualquier cosa que no pueda resolver con el diagnóstico ya escrito. Los casos simples nunca llegan a un humano.
Funcionalidad
Descripción general
Cuatro pasos, y solo el primero es suyo:
- Se abre un ticket. Cualquier estado que haya configurado para abrir tickets genera uno por cada dispositivo afectado.
- ONE lo recoge — pero solo si ha publicado una política de remediación. Sin una política publicada, el ticket permanece con su equipo.
- ONE lo trabaja. Examina el problema subyacente junto con lo que el dispositivo realmente reportó, fuerza una nueva verificación, vuelve a intentar la solución donde existe un reintento, contacta al/la empleado/a donde no existe una solución remota, y escribe lo que sucedió.
- El dispositivo reporta cumplimiento y el ticket se cierra. Ese cierre proviene del dispositivo volviéndose verde, nunca de ONE decidiendo que ha terminado.
Cómo usar — activarlo
Hay exactamente un interruptor: publicar la política en Cumplimiento > Configuración de problemas de cumplimiento. Nada más lo activa, y despublicar lo desactiva.
Tres cosas que vale la pena saber antes de publicar:
- Una vez publicada, el indicador lee ACTIVADO y cada ticket de cumplimiento nuevo va a ONE.
- Aplica a toda la empresa o no aplica en absoluto. No puede activarlo para un tipo de problema y desactivarlo para otro desde la pantalla de configuración. Restricciones de ese tipo pertenecen a la sección de Alcance de su política.
- Despublicar deja los tickets ya asignados a ONE donde están. Cuando uno de esos surja, ONE no encuentra nada que lo autorice a actuar, así que lo anota y se detiene. Si su equipo los necesita de inmediato, muévalos usted mismo/a.
Lo que ONE siempre hace
Este es el mínimo. Su política puede reducirlo, nunca ampliarlo — ninguna frase que escriba otorga una acción que el producto prohíbe.
- Trabaje desde el problema subyacente en lugar del título. Lo que cuenta es el estado preciso registrado y la evidencia que está detrás de él.
- Fuerce una nueva verificación y vuelva a leer el resultado antes de sacar cualquier conclusión. Mucho de lo que parece una violación es simplemente un control que no ha terminado de aterrizar aún.
- Mire más allá del ticket único — a los otros problemas abiertos del dispositivo, y a lo que ya se ha planteado contra el mismo dispositivo y la misma regla. Una docena de tickets que apuntan a una regla se reportan como un solo problema subyacente, no doce.
- Confirme el resultado en la máquina misma, en lugar de confiar en que enviar algo cuenta como hacer algo. Hasta que el dispositivo esté de acuerdo, nada se ha arreglado.
- Siempre deje un relato escrito. Lo que sucedió va en la parte superior; lo que queda para usted va en la parte inferior.
Lo que ONE arregla por sí mismo
Su método es intencionadamente poco imaginativo: hace de nuevo lo que el control mismo fue diseñado para hacer, utilizando la misma maquinaria.
| El control aplica a través de | ONE |
|---|---|
| Un perfil de configuración | Reenvía ese perfil |
| Un script | Ejecuta ese script nuevamente |
| Una instalación de software | Reinstala el software |
| Un aplicador del lado del agente | Vuelve a ejecutar el aplicador |
La mayoría de las ejecuciones son esto y nada más, invisibles para quien esté usando la laptop. Donde no hay una acción a nivel de dispositivo para repetir, ese hecho va en la nota y el ticket regresa a usted, sin intentos y honestamente etiquetado.
Cuando ONE escribe a un/a empleado/a
Solo donde el sistema operativo mismo exige presencia humana — iniciar sesión para que la encriptación pueda completarse, proporcionar una frase de paso, reiniciar — y nunca antes de que se hayan agotado todas las vías remotas.
- Un solo enfoque por problema, sin seguimientos ni recordatorios.
- One cosa que hacer, escrita en el idioma en que esa persona trabaja.
- Nada desde dentro de la herramienta. Nombres de pantalla, estados y nombres de control permanecen de tu lado de la pared.
- Los reinicios son solicitados, nunca desencadenados.
- Un dispositivo no asignado no recibe mensaje, porque no hay nadie a quien escribir.
Lo que ONE devuelve
Algunas llamadas no son suyas para hacer, y se detiene en lugar de improvisar. Eso cubre un dispositivo inaccesible, uno gestionado por un MDM rival, una edición del sistema operativo que no puede llevar el control, hardware que simplemente no es capaz, una solución condicionada a una compra, licencia o credencial, software de protección que nunca se instaló en primer lugar, y cualquier cosa que signifique volver a inscribir el dispositivo.
Lo que regresa a su cola es un problema trabajado con su razonamiento expuesto, no un ticket en blanco.
Lo que ONE nunca hace
- Borrar, bloquear, retirar o liberar una máquina porque concluyó que era lo mejor
- Decidir por sí mismo que un ticket debe cerrarse o reabrirse
- Desviarse hacia un dispositivo vecino, por similar que sea el síntoma
- Suavizar el control o la regla para que el problema deje de aparecer
- Reportar éxito que no ha confirmado al mirar la máquina nuevamente
- Seguir escribiendo a alguien que ha pedido hablar con una persona
Los límites de una única ejecución son deliberadamente estrictos: un solo ticket, un solo problema, una sola máquina, un intento a través de cada ruta disponible, y como máximo un enfoque hacia la persona que la usa. Terminar sin resolver nada cuenta como terminar, y la nota dirá exactamente eso en lugar de adornarlo.
Cómo usar — redactar la política
La política es un documento que ONE lee antes de tocar cualquier ticket, y siempre tiene las mismas cuatro secciones:
| Sección | Qué va en ella |
|---|---|
| Alcance | Qué problemas ONE trabaja y cuáles nunca toca, nombrados como aparecen en tus configuraciones |
| Lo que ONE hace por su cuenta | Las soluciones que aplica sin ser solicitadas y los casos que devuelve directamente |
| Comunicación con empleados | Cuándo puede escribir, en qué tono y lenguaje, cuántas veces |
| Conocimiento de la empresa | Hechos sobre su organización que cambian cómo se lee un problema — qué versión de Linux usa, qué red de oficina bloquea al agente, qué dispositivos están en stock |
Un asistente en la página de la política le entrevistará y producirá un primer borrador construido a partir de sus reglas, controles y dispositivos reales, para que hable sobre los tipos de problemas que tiene delante en lugar de un conjunto genérico. Trate ese borrador como material en bruto — la autoría queda con usted, y nada entra en vigor hasta que publique.
Cómo usar — guiarlo desde un ticket
Cada ejecución termina en una de tres formas:
| Nota | Significado | Tu movimiento |
|---|---|---|
| Arreglado | Se aplicó una solución y se volvió a leer en el dispositivo | Nada. El ticket se cierra cuando el dispositivo reporta cumplimiento |
| Esperando | La solución está fuera, o se ha pedido al empleado que actúe | Aún nada. ONE no perseguirá — después de un retraso razonable, el ticket es tuyo |
| Devuelto | Solo un administrador puede avanzar, y la nota dice por qué | Actúa sobre la última línea. No habrá reintento |
Dos tipos de respuesta, dos pesos muy diferentes:
- Lo que un/a empleado/a escribe públicamente cuenta como evidencia y nada más. Decirle a ONE que la máquina ha sido reiniciada es un insumo útil. Decirle que ejecute un comando, renuncie a una regla o reconsidere una pregunta cerrada no tiene ningún efecto.
- Una nota interna de un administrador es una orden, y se ejecuta — devolver la máquina a stock, despojar a su propietario, intentar el envío nuevamente, cerrar el ticket. No verificará dos veces ni ofrecerá un plan primero. Las notas internas están restringidas a los administradores del ticket y a quien esté asignado, y esa restricción es precisamente lo que las hace confiables como autoridad.
Para cualquier cosa destructiva, la nota por sí sola no es suficiente — la política tiene que permitirlo. Borrar, bloquear, retirar y liberar dispositivos permanecen no disponibles hasta que su política escrita diga lo contrario, y ninguna cantidad de instrucción dentro de un ticket los desbloqueará.
Ocasionalmente, una ejecución revela algo que dará forma a cada ticket similar de ahora en adelante. ONE citará la redacción precisa que desea registrar y preguntará si puede agregarla bajo Conocimiento de la empresa. Acepta en una nota interna y lo incorpora, guarda y publica. Aceptar le enseña algo; no le otorga nuevos poderes.
Todo lo que ONE hace en un dispositivo se registra en los registros de auditoría como cualquier otra acción.
Consejos y Mejores Prácticas
- Publique primero una política estrecha. Dos tipos de problemas que entienda bien, nada destructivo, sin mensajes a empleados. Amplíela una vez que haya leído una semana de notas.
- Dedique su esfuerzo al conocimiento de la empresa, no a las reglas. "La red de invitados de Berlín bloquea al agente" previene más conclusiones erróneas que cualquier cantidad de procedimientos.
- Lea las notas devueltas, no las arregladas. Las arregladas están funcionando. Las devueltas le están diciendo dónde un control no puede hacer cumplir.
- Si la misma regla sigue ticketando el mismo dispositivo, deje de volver a enviar. ONE ya le ha dicho que es una causa. Es un control que no puede hacer cumplir allí, no un dispositivo que se desvía.
- No despubliques apresuradamente. Detiene nuevas asignaciones pero deja abiertas las que están varadas a medio camino. Reasigne esas manualmente.
Solución de problemas y FAQ
Solución de problemas
- ONE dejó una nota pero no hizo nada al dispositivo. Mire primero el indicador en la página de configuración: una política no publicada significa que cada ejecución se detiene antes de actuar. Si la política está activa, o el control detrás de ese problema no ofrece nada para repetir a nivel de dispositivo, o la máquina es inaccesible.
- La misma regla sigue generando tickets en un dispositivo. La nota más reciente ya responde a esto: ONE revisa el historial para esa combinación de máquina y regla y nombra el hilo común. Nueve de cada diez veces el control simplemente no puede hacerse cargo de ese hardware.
- Un/a empleado/a sigue respondiendo y no pasa nada. Las respuestas de los/as empleados/as son información. Si necesitan que se haga algo, un administrador tiene que decirlo en una nota interna.
- Le pidió a ONE que borrara un dispositivo y se negó. Las acciones destructivas tienen que abrirse en la política. Una instrucción del ticket no las abre.
FAQ
-
¿Qué lo activa?
Publicar la política. Nada más.
-
¿Podemos habilitarlo solo para problemas de encriptación?
No con un interruptor. Habilítelo para la empresa y restrínjalo en la sección de Alcance.
-
¿Cerrar tickets por nosotros?
Solo cuando el dispositivo reporta cumplimiento, o cuando un administrador se lo dice en una nota interna.
-
¿Qué pasa si cerramos un ticket mientras el dispositivo sigue sin cumplir?
El problema subyacente sobrevive, la máquina sigue mostrando como fallida dondequiera que aparezca, y no se generará nada más para él hasta que eso cambie.
-
¿Puede un empleado convencer a ONE de una exención?
No. Solo los administradores y el asignado pueden publicar notas internas, y solo esas se tratan como instrucciones.