Cómo registrar una incidencia en FortiCare y acelerar la respuesta

Una incidencia de Fortinet se registra desde el portal de soporte FortiCare, donde se identifica el equipo o servicio afectado, se describe el problema y se adjuntan pruebas. Al enviar el formulario, el sistema asigna un número de caso que permite seguir el expediente con el equipo de asistencia técnica, conocido como TAC. Si el fallo interrumpe una actividad esencial, la llamada telefónica con ese identificador puede acelerar el contacto, aunque no sustituye la creación del ticket.

La calidad de la información inicial suele influir más que la extensión del texto: versión del firmware, alcance del fallo, hora de inicio, cambios recientes y registros pertinentes ayudan a que el diagnóstico empiece con contexto. Antes de entrar en el formulario también conviene confirmar que el activo está registrado en la cuenta y tiene cobertura FortiCare vigente. Si alguno de esos requisitos falla, el portal puede no mostrar el equipo o el caso puede atascarse antes de que el TAC llegue al problema técnico.

Lo que conviene comprobar antes de entrar en FortiCare

El primer filtro es el registro del dispositivo. La cuenta que abre la incidencia debe tener acceso al número de serie afectado y al contrato de soporte asociado. Esto cobra importancia cuando el equipo procede de otra empresa, ha cambiado de proveedor o ha llegado como sustitución de un RMA: que el aparato esté físicamente instalado no garantiza que aparezca correctamente en el inventario de la cuenta. Registro, titularidad y cobertura deben corresponderse para que el trámite avance sin gestiones administrativas añadidas.

Si el activo no aparece al intentar seleccionarlo, no siempre significa que haya un fallo en el portal. Puede estar vinculado a otra cuenta o a otro tenant, que es el espacio de gestión asignado a una organización o cliente. En entornos con varias subcuentas y proveedores de servicios gestionados, el usuario también puede carecer de permisos para consultar ese inventario. Revisar el tenant correcto y el acceso del usuario suele ser más útil que repetir varias veces la búsqueda del mismo firewall.

En equipos reemplazados mediante RMA, hay que prestar atención al vínculo entre el número de serie anterior y el nuevo. La cobertura o los derechos de soporte pueden requerir una transferencia al dispositivo de sustitución. Si esa asociación no se ha actualizado, el nuevo equipo puede figurar como si no tuviera cobertura, aunque el reemplazo se haya tramitado. Resolver el registro antes de abrir la incidencia técnica evita que el expediente se convierta en una cadena de consultas sobre licencias y propiedad del activo.

Preparar el contexto técnico que necesita el TAC

Antes de describir el fallo, reúne los datos que permiten acotar cuándo y dónde aparece. La versión exacta del firmware es un punto de partida, junto con los cambios aplicados poco antes de la incidencia: una política nueva, una modificación de SD-WAN, un cambio de enlace o una actualización pueden orientar el análisis. También importa saber si el problema afecta a un único dispositivo, a varias sedes o a todos los usuarios de un servicio. El alcance real ayuda a distinguir una avería local de una interrupción general.

Una cronología breve evita que el primer intercambio se consuma en reconstruir los hechos. Anota desde cuándo ocurre, a qué hora se han observado los episodios y qué medidas se han probado. En problemas intermitentes, especificar la zona horaria y las horas concretas permite comparar los síntomas con los registros. Si la incidencia empezó tras un cambio, indícalo sin dar por hecho que esa modificación sea necesariamente la causa: el orden temporal es una pista, no una demostración.

En una red con varios componentes, un esquema sencillo puede aclarar el recorrido del tráfico y las dependencias entre equipos. La relación entre FortiGate, FortiManager, FortiAnalyzer, FortiAP, FortiSwitch u otros servicios en la nube puede ser decisiva para reproducir un síntoma. Si el equipo se administra desde FortiManager, el identificador de la revisión o del cambio aplicado ayuda a localizar qué configuración estaba activa. Un mapa comprensible vale más que una descripción llena de siglas sin contexto.

Cómo crear el expediente y elegir el activo adecuado

Con la sesión iniciada en FortiCare, el alta suele comenzar en la sección de soporte, mediante la opción para crear un ticket. La interfaz puede cambiar con el tiempo, pero el principio es el mismo: asociar la incidencia al producto correcto y después explicar el problema. Según el tipo de servicio, el portal puede permitir localizar el activo por número de serie, nombre interno o registro del servicio en la nube. En inventarios grandes, comprueba dos veces la sede o la etiqueta del equipo antes de continuar.

Seleccionar un dispositivo parecido no es un detalle menor. Dos equipos del mismo modelo pueden estar en ciudades distintas y tener configuraciones, contactos o contratos diferentes. Si se trata de un servicio en la nube, puede aparecer como un activo lógico en lugar de como un aparato físico. El caso debe quedar asociado al componente que origina el síntoma; si todavía no está claro cuál es, explica qué elementos se han visto afectados y qué pruebas permiten relacionarlos.

El formulario solicita una categoría o tipo de problema, una descripción y una valoración de la severidad. Las categorías pueden abarcar funciones de red, VPN, autenticación, filtrado web, hardware o licencias, entre otras. No hace falta convertir la descripción en un informe extenso: un resumen ordenado de lo que sucede, desde cuándo, a quién afecta y qué ha cambiado permite que el equipo de soporte entienda el escenario desde la primera lectura. La precisión y la cronología pesan más que un relato largo.

Describir el impacto sin inflar la severidad

La prioridad debe reflejar las consecuencias del incidente, no la frustración que provoca ni el deseo de adelantar posiciones en la cola. Una caída que impide operar, una interrupción amplia o un problema grave sin alternativa disponible no equivale a una incidencia menor que afecta a un entorno de pruebas. Describe qué servicio se ha detenido, cuántas partes de la organización están afectadas y si existe una mitigación temporal. El impacto observable es la base para clasificar la severidad.

Marcar una prioridad máxima cuando el problema está acotado o existe una alternativa puede complicar el triaje. El equipo de soporte puede revisar la clasificación y pedir más contexto, de modo que exagerar no garantiza una respuesta más rápida. También conviene actualizar la severidad si la situación cambia: si una medida de contención reduce el impacto, dejarlo reflejado ayuda a que los recursos se asignen según la urgencia actual y no según la del primer momento.

Cuando la incidencia corta una actividad crítica, el procedimiento descrito en el material de soporte es registrar primero el ticket y llamar después al TAC con el número de caso. La llamada aporta una vía rápida para comunicar la gravedad y coordinar los primeros pasos, pero no reemplaza el registro escrito ni el historial técnico. La disponibilidad de escalada telefónica puede depender del plan de soporte contratado; en niveles básicos, la gestión puede canalizarse por el portal y el chat. La cobertura determina qué canales están habilitados.

Adjuntar pruebas útiles y proteger la información

Las evidencias permiten pasar de una descripción general a un diagnóstico que pueda comprobarse. Cuando sea posible, adjunta el archivo de soporte técnico del dispositivo, los registros de eventos y capturas de las pantallas relacionadas con el síntoma. Para una incidencia de tráfico, una captura de paquetes puede mostrar qué ocurre en los puntos relevantes; para un problema de rendimiento, ayudan las métricas disponibles de procesador, memoria, sesiones, latencia o pérdida de paquetes. Cada archivo debería responder a una pregunta concreta.

El volumen por sí solo no mejora un caso. Un archivo comprimido enorme sin explicación obliga al ingeniero a buscar a ciegas, mientras que un conjunto pequeño, identificado y relacionado con una hora o una prueba facilita el análisis. Si aportas registros, indica el intervalo temporal que importa y el equipo del que proceden. En un fallo de hardware, las fotografías pueden ayudar a documentar el estado físico, siempre que permitan identificar el dispositivo y el número de serie de forma legible.

Los archivos de configuración y los registros pueden contener información sensible, como direcciones internas, nombres de usuarios o detalles de la arquitectura. Antes de adjuntarlos, aplica las reglas de seguridad de la organización y utiliza los canales autorizados para compartir información técnica. No incluyas contraseñas, claves privadas ni credenciales en la descripción del caso. Dar contexto no significa exponer secretos operativos; si una prueba requiere información especialmente delicada, la forma de compartirla debe acordarse por los canales de soporte disponibles.

El seguimiento del caso y la comunicación con el TAC

Al enviar el formulario, FortiCare genera un identificador que sirve para consultar el expediente y añadir información. Guárdalo en un lugar accesible para las personas que participan en la incidencia. Desde el caso se pueden incorporar notas y archivos, actualizar contactos y, según las opciones disponibles, ajustar la severidad o indicar una franja preferente para una intervención. El número de caso es la referencia común cuando se habla con el portal, el TAC o el equipo interno.

Si se llama por una interrupción grave, conviene comunicar de forma directa el identificador, el síntoma principal, el impacto, las acciones ya probadas y la disponibilidad para realizar pruebas. El detalle extenso puede quedar en las notas del expediente, donde se conserva junto con las evidencias. En incidencias intermitentes, registra la hora de cada episodio y cualquier relación observada con cambios de configuración o eventos de red. Así, una sesión telefónica no depende de reconstruir la historia sobre la marcha.

El contacto principal también influye en la continuidad. Si el TAC propone una sesión remota o una prueba en una ventana determinada, debe haber alguien disponible con permisos y conocimiento del entorno. Cuando intervienen un cliente, un integrador y varios proveedores, designar un punto de coordinación reduce los mensajes cruzados. Un expediente necesita una voz responsable, aunque varias personas aporten datos.

Si el caso pasa de un equipo regional a otro por diferencias horarias o cambios de turno, deja una nota reciente con el estado del problema, las pruebas realizadas y lo que queda pendiente. No confíes en que quien se incorpora lea de principio a fin cada mensaje anterior. Un resumen breve y actualizado evita repetir pasos y permite que el siguiente ingeniero retome el diagnóstico con una imagen fiable de la situación.

Cuándo el problema apunta a hardware, licencias o servicios en la nube

No todas las incidencias se resuelven con un ajuste de configuración. Reinicios inesperados, errores de componentes o síntomas físicos pueden llevar a una evaluación de hardware y, si el TAC confirma que procede, a un RMA, el proceso de sustitución del equipo. El ticket inicial puede servir para mantener el diagnóstico y coordinar los pasos del reemplazo. El tipo de envío o modalidad aplicable depende del contrato: no hay una única condición logística válida para todos los clientes. El soporte contratado y la evaluación técnica determinan el trámite.

Antes de solicitar un reemplazo, el equipo técnico puede pedir comprobaciones para descartar otras causas. Según el síntoma, podrían ser necesarias pruebas cruzadas con módulos, fuentes o componentes equivalentes, o reproducir el problema bajo condiciones distintas. Para algunos modelos y versiones existe una herramienta de diagnóstico de hardware llamada HQIP. La información de referencia indica que las pruebas integradas se incorporaron desde FortiOS 5.4 en modelos de la serie E y posteriores, pero la disponibilidad concreta depende del equipo y del software instalado.

HQIP no detecta todos los fallos ni sustituye el análisis del TAC. Si se ejecuta una prueba, el resultado debe adjuntarse al caso para que soporte valore si confirma una avería o si hacen falta comprobaciones adicionales. En los procedimientos descritos para esta herramienta, se recomienda estar junto al equipo, disponer de acceso a consola y conservar copias de seguridad pertinentes antes de iniciar pruebas que puedan requerir intervención física. Un resultado fallido es una evidencia, no una autorización automática de RMA.

Las consultas de licencias también pueden tramitarse mediante el expediente cuando afectan a un activo concreto. En esos casos, importa comprobar si la suscripción está vigente y asociada al número de serie correcto. Una licencia visible en el portal pero no reconocida por el dispositivo requiere analizar la sincronización y el registro del servicio, sin asumir de antemano que el problema sea del equipo. Tras una sustitución, verificar la transferencia de derechos al nuevo número de serie evita confundir una incidencia de licenciamiento con una falta de cobertura.

Los productos de nube, como FortiManager Cloud, FortiAnalyzer Cloud o FortiSASE, pueden figurar en el inventario como servicios y no como dispositivos físicos. El canal de soporte descrito parte igualmente de FortiCare, aunque la selección del activo y las evidencias pertinentes cambien. En integraciones con varias plataformas, describe qué componente presenta el síntoma y cuál es la relación entre ellos. Identificar bien el servicio evita que el caso llegue a la cola técnica equivocada.

Los tropiezos que suelen alargar una incidencia

Uno de los errores más habituales es abrir el caso desde una cuenta genérica que nadie supervisa. Si el TAC propone una sesión o necesita confirmar un dato, la falta de una persona localizable puede detener el avance. Otro problema es dispersar la historia entre correo, chat, llamadas y mensajes internos sin trasladar al expediente los resultados importantes. El canal central permite que quien retome el caso encuentre decisiones y pruebas en un mismo sitio. La continuidad depende de que el historial no se fragmente.

También ralentiza el diagnóstico realizar cambios mientras el caso está abierto sin anotarlos. Una modificación puede corregir el síntoma, alterar su reproducción o añadir una variable nueva. Si hay que intervenir, deja constancia de qué se cambió, cuándo y con qué resultado. Registrar una prueba que no funcionó es tan útil como documentar una solución: ambas cosas reducen la posibilidad de repetir intentos y acotan las hipótesis.

Por último, no conviene enviar evidencias sin identificar ni dejar la severidad congelada cuando el impacto ya ha cambiado. Nombres de archivo comprensibles, horas precisas y notas con los resultados observados convierten el expediente en una cronología técnica, no en un cajón de documentos. Un caso ordenado permite que el soporte dedique más tiempo al diagnóstico y menos a reconstruir los hechos.

Un expediente claro cambia el ritmo del diagnóstico

El proceso se apoya en una secuencia sencilla: confirmar que el activo está registrado y cubierto, asociar el caso al producto correcto, explicar el impacto con precisión y aportar pruebas que permitan reproducir o acotar el fallo. Si la actividad está gravemente afectada, el número de caso sirve para contactar con el TAC por teléfono cuando el plan de soporte lo permite. Si el problema se estabiliza o empeora, actualiza tanto la severidad como las notas del expediente. La rapidez no depende de un truco, sino de eliminar incertidumbres.

La incidencia también deja información para el siguiente episodio. Conservar una cronología clara, documentar los cambios y resumir la causa identificada al cerrar el caso ayuda a que el equipo interno reconozca patrones en el futuro. No garantiza que el próximo fallo sea igual ni que se resuelva de inmediato, pero evita volver a empezar desde cero. En soporte técnico, un buen registro no es burocracia: es parte del diagnóstico y del relevo entre quienes mantienen la red y quienes conocen el producto.