El TAC de Fortinet en México: cómo funciona y cómo sacarle provecho

Algo se rompió en el FortiGate y hay que llamar a la caballería. Esa caballería es el TAC —el Technical Assistance Center de Fortinet—, y saber usarlo bien es la diferencia entre resolver en una llamada y dar vueltas una semana. La buena noticia para México: responde en español, con agentes mexicanos, y —en nuestra experiencia— rápido. La menos obvia: la velocidad del TAC no sirve de nada si del lado del cliente nadie sabe darle lo que pide.

Cómo entra un caso: el triage por criticidad

El TAC no atiende todo por la misma puerta. Primero hace un triage por severidad, y por dónde entras depende de qué tan grave es lo que te pasa. Fortinet define cuatro niveles, y vale la pena conocerlos porque clasificar bien tu caso es lo primero que acelera (o atora) la respuesta:

La regla práctica: los niveles críticos entran por teléfono; el resto, por portal o correo. Y clasificar honestamente importa en las dos direcciones. Marcar como P1 una duda de configuración quema tu credibilidad y satura la cola; pero reportar como P3, "por no molestar", un enlace productivo caído es regalar horas que el SLA de un P1 te habría dado. El nivel no es burocracia: es la palanca de urgencia.

Qué llevar para que el caso no se atore

Un caso al TAC avanza a la velocidad de la evidencia con la que llega. Lo que el ingeniero del otro lado va a pedir —y conviene tener listo antes de abrir el caso— es siempre lo mismo:

• El número de serie del equipo (y que esté registrado bajo un contrato vigente; sin eso, no hay caso que abrir).
• Una descripción concreta del síntoma: qué pasa, desde cuándo, qué cambió.
• Las salidas de diagnóstico relevantes —los comandos de consola que muestran el problema en vivo, no una captura de la interfaz. Es justo el reflejo que trabajamos en la serie de CLI de FortiGate: el que sabe pedirle al equipo la evidencia por consola arma un caso que el TAC puede resolver sin adivinar.
• Para un problema de hardware, los resultados del HQIP —la prueba que confirma la falla física, que cubrimos aparte en esta serie.
• Los logs del periodo del incidente, que es donde registrar de verdad (y no solo tener el equipo prendido) paga.

Llegar con esto convierte un ida y vuelta de tres días en una conversación de una tarde. Llegar sin ello significa que la primera respuesta del TAC será, precisamente, pedírtelo.

¿Quién abre el caso: el cliente o su proveedor?

Las dos formas existen. El titular de la cuenta puede crear tickets directamente, pero en la práctica —cuando hay un proveedor administrado de por medio— es el MSP quien lleva el caso. Tiene sentido: el MSP ya tiene el serial, el contexto, las salidas de diagnóstico y sabe traducir el síntoma del cliente al lenguaje que el TAC necesita.

Hay una excepción que suele hacer el cliente por su cuenta: la transferencia de titularidad de un equipo —cuando un FortiGate cambia de dueño y hay que reasignarlo a otra cuenta. Ese trámite lo resuelve normalmente el titular directo, no el MSP.

Lo que de verdad decide un caso: estar amparado

Y aquí está la lección que no viene en ningún manual. El TAC responde rápido, en español, bien. Pero el TAC es solo una mitad de la ecuación; la otra mitad es qué tan capaz es el lado del cliente de ejecutar lo que el TAC indica. Y ahí la diferencia entre estar amparado bajo una póliza de servicio administrado y no estarlo es, literalmente, de día y noche.

Lo hemos visto de cerca: un cliente que, por no querer pagar el servicio administrado, tardó más de una semana en siquiera lograr cargar el HQIP por TFTP para arrancar su reclamo. No fue culpa del TAC —el TAC estaba listo del otro lado. Fue que del lado del cliente no había quién montara el servidor TFTP, interrumpiera el arranque, cargara la imagen y leyera la salida. Una semana de perímetro comprometido, no por falta de soporte, sino por falta de manos que supieran usarlo. El soporte de Fortinet abre la puerta; alguien tiene que saber cruzarla.

Dónde entramos nosotros

Esa segunda mitad de la ecuación es exactamente nuestro trabajo. Cuando administramos el perímetro Fortinet de un cliente, nosotros llevamos el caso con el TAC de principio a fin: clasificamos bien la severidad, llegamos con la evidencia lista —serial, salidas de consola, HQIP, logs—, y ejecutamos de este lado lo que el TAC pide, en el momento en que lo pide. El cliente no tiene que aprender a correr un HQIP por TFTP el peor día de su año. Para eso nos tiene.