Técnico de soporte informático

Empiezo pidiendo al usuario una descripción precisa: qué estaba haciendo, qué esperaba y qué ocurrió realmente, porque informes vagos como "no funciona" hacen perder los primeros diez minutos si no pido detalles concretos. Reviso primero lo obvio: si el problema está aislado en una máquina o afecta a varios usuarios, si ha habido algún cambio reciente como una actualización o un cambio de permisos, y si puedo reproducirlo yo mismo. Busco en nuestra base de conocimiento interna y en el historial de tickets antes de asumir que el caso es único, porque la mayoría de los problemas "nuevos" ya han aparecido antes con una descripción ligeramente distinta. Si no encuentro coincidencia, aíslo las variables una a una en lugar de cambiar varias cosas a la vez, para saber con certeza qué cambio resolvió el problema. Documento lo que voy probando y el resultado a medida que avanzo, no solo al final, por si tengo que escalar y otra persona necesita continuar desde donde lo dejé.

Dejo por completo el vocabulario técnico y describo el problema en función de lo que el usuario va a experimentar y cuándo se resolverá, en lugar de la causa subyacente. Si la cuenta de alguien está bloqueada por un fallo de sincronización con nuestro proveedor de identidad, digo "tu cuenta necesita un restablecimiento rápido, tardará unos cinco minutos y tendrás que volver a iniciar sesión después" en lugar de explicar el fallo de sincronización. Compruebo la comprensión pidiéndole a la persona que me diga qué va a hacer a continuación, en lugar de solo preguntar "¿queda claro?", porque a menudo la gente dice que sí por cortesía aunque siga confundida. También ajusto mi ritmo al suyo: si alguien está preocupado por perder su trabajo, atiendo esa preocupación directamente antes de pasar a la solución. Con usuarios frustrados, reconozco primero la molestia causada, porque necesitan sentirse escuchados antes de poder seguir instrucciones.

Clasifico según dos ejes: cuántas personas se ven afectadas y cuánto bloquea el problema su trabajo. Una caída del sistema de nóminas que afecta a todo el equipo de finanzas tiene prioridad sobre la impresora de un solo usuario que no se conecta, incluso si ese ticket llegó primero. Marco como inmediato cualquier cosa relacionada con seguridad, pérdida de datos o un sistema de producción, sin importar quién lo haya reportado. Para el resto, trabajo más o menos por orden de llegada, pero comunico de forma proactiva: si el ticket de alguien va a esperar una hora, envío una actualización rápida en lugar de dejar que se pregunte si se recibió. También agrupo tickets de baja prioridad similares, como varias solicitudes de restablecimiento de contraseña, para no cambiar de contexto constantemente entre asuntos sin relación. Cuando realmente no puedo llegar a todo en un turno, se lo comunico a mi responsable en lugar de dejar que los tickets superen nuestro SLA en silencio.

He trabajado principalmente con Zendesk y ServiceNow para la gestión de tickets, y me siento cómodo con ambas, aunque encuentro más útil la vinculación de activos de ServiceNow cuando un problema de hardware necesita asociarse al historial de un dispositivo concreto. Para soporte remoto he usado TeamViewer y las herramientas de asistencia remota integradas en Windows y macOS, y siempre confirmo con el usuario antes de tomar el control de su pantalla en lugar de conectarme en silencio. Mantengo notas de ticket lo bastante detalladas como para que un compañero pueda retomar el caso sin tener que preguntarme, incluyendo los mensajes de error exactos y los pasos que ya probé. También uso nuestra wiki interna para documentar soluciones a problemas recurrentes, de forma que el siguiente técnico, o el propio usuario mediante autoservicio, no tenga que empezar de cero. La familiaridad con las herramientas me importa menos que el hábito de documentar con claridad, porque las herramientas cambian entre empresas pero ese hábito no.

Teníamos un pequeño grupo de usuarios que perdían la conexión VPN cada pocas horas, y la solución habitual era siempre la misma: reiniciar el cliente VPN. Había atendido el mismo ticket para los mismos tres usuarios unas seis veces en un mes antes de dejar de tratarlo como algo rutinario y revisar los registros de conexión. Los tres estaban en la misma planta del edificio y en el mismo punto de acceso wifi, y las caídas coincidían con una franja horaria concreta cada tarde. Descubrí que el punto de acceso estaba sobrecargado durante una reunión de equipo recurrente cerca de allí que consumía mucho ancho de banda. Trabajé con el equipo de red para trasladar a esos usuarios a otro punto de acceso y ajustar la configuración de canales. Los tickets dejaron de aparecer por completo. Tardó más que simplemente decirles que reiniciaran el cliente, pero probablemente ahorró al equipo unos veinte tickets al mes a partir de entonces, y me enseñó a buscar patrones entre tickets en lugar de resolver cada uno de forma aislada.

Un usuario reportó corrupción de datos intermitente en una hoja de cálculo compartida que varias personas editaban a la vez. Descarté las causas obvias: versión del navegador, extensiones y conflictos de sincronización de archivos locales, pero la corrupción seguía ocurriendo de forma impredecible. Tras unos noventa minutos de investigación sin una pista clara, reconocí que probablemente era un problema de sincronización del backend que superaba lo que podía diagnosticar desde el cliente, así que escalé al equipo de nivel dos con un informe completo: lo que ya había probado, las marcas de tiempo exactas de cada incidente de corrupción y la lista de usuarios implicados. Seguí involucrado en lugar de entregarlo por completo, ya que era quien más contexto tenía sobre el patrón de aparición. Resultó ser una condición de carrera en el servicio de sincronización que el nivel dos corrigió con un parche. Intento escalar basándome en una señal clara de que he llegado al límite de lo que puedo diagnosticar, no en un límite de tiempo por sí solo, porque escalar demasiado pronto le hace perder tiempo al nivel dos repitiendo comprobaciones que yo podría haber hecho.

Una directiva me llamó furiosa porque había perdido el acceso a una presentación veinte minutos antes de una reunión del consejo. La dejé explicarse sin interrumpirla, reconocí lo estresante que era el momento, y le fui indicando claramente lo que estaba haciendo mientras lo hacía, en lugar de quedarme callado mientras investigaba. Resultó que su cuenta se había cerrado automáticamente por una política de seguridad tras una advertencia de expiración de contraseña que ella había descartado. Restablecí su sesión y la reconecté en unos cuatro minutos, y luego envié un breve seguimiento explicando qué había pasado para que no le sorprendiera de nuevo. No intenté explicar la causa técnica mientras estaba bajo presión, porque eso no era lo que necesitaba en ese momento. Después, avisé a nuestro equipo de seguridad de que la advertencia de expiración era demasiado fácil de descartar sin darse cuenta, lo que llevó a un pequeño cambio de texto que redujo tickets similares.

Mi primer paso es la contención, no la investigación: desconecto la máquina de la red, ya sea deshabilitando el adaptador de red de forma remota si tengo ese acceso o desconectándola físicamente, para detener cualquier propagación o filtración de datos antes de hacer cualquier otra cosa. No apago la máquina de inmediato, porque eso podría perder evidencia volátil en memoria que nuestro equipo de seguridad pueda necesitar. Documento lo que el usuario reportó haber notado, la hora exacta, y cualquier acción reciente como abrir un archivo adjunto o hacer clic en un enlace. Escalo de inmediato a nuestro equipo de seguridad en lugar de intentar solucionarlo yo mismo, ya que la investigación de una vulneración queda fuera del alcance estándar del soporte informático y una mala gestión puede destruir evidencia. Mientras espero a seguridad, compruebo si otras cuentas del mismo usuario muestran actividad sospechosa, como inicios de sesión desde ubicaciones inusuales, para reportarlo también. También aviso al responsable del usuario si la cuenta tiene acceso a sistemas sensibles, porque la contención a veces debe extenderse más allá de un solo dispositivo.

Empiezo pidiendo al usuario que me muestre exactamente lo que intenta hacer, porque compartir pantalla suele revelar contexto que una descripción escrita no capta. Si no conozco el software, lo digo directamente en lugar de adivinar, y consulto nuestra documentación interna o contacto con quien lo configuró originalmente. Busco patrones de software que sí conozco: la mayoría de las herramientas heredadas siguen convenciones habituales sobre gestión de archivos, permisos o archivos de configuración, así que a menudo puedo acotar dónde está probablemente el problema aunque no tenga un conocimiento profundo. Tengo cuidado al hacer cambios en sistemas heredados sin entender el impacto completo, porque el software antiguo suele tener dependencias no documentadas. Si una solución requiere un cambio del que no estoy seguro, lo pruebo de forma reversible, por ejemplo guardando una copia del archivo de configuración antes de editarlo, en lugar de editar directamente. Documento lo que voy aprendiendo sobre el sistema a medida que avanzo, porque el conocimiento de herramientas heredadas suele existir solo en la cabeza de unas pocas personas y desaparece cuando se van.

Mantengo una lista de tickets que me costaron o me llevaron más tiempo del esperado, y la reviso periódicamente para encontrar huecos en mi conocimiento en lugar de esperar a que me asignen formación. Sigo las notas de versión de los proveedores de las herramientas que más soportamos, en particular nuestro proveedor de identidad y nuestra plataforma de gestión de dispositivos, porque muchos tickets se remontan a una actualización reciente que cambió un comportamiento por defecto. Formo parte de un par de comunidades de soporte informático en línea donde la gente comparte soluciones para problemas que aún no han llegado a la documentación oficial, lo cual suele ser más rápido que esperar al soporte del proveedor. Cuando aprendo una herramienta nueva, intento realmente romperla en un entorno de pruebas en lugar de limitarme a leer sobre ella, porque el instinto de resolución de problemas solo se adquiere habiendo provocado y solucionado problemas uno mismo. También hago sesiones breves de intercambio de conocimiento con el equipo cuando resuelvo algo inusual, para que el aprendizaje no se quede solo conmigo.