Blog · Guías para el responsable TIC
«No va internet»: cómo acotar el problema antes de llamar a nadie
Son las nueve y cuarto de la mañana y una clase no puede empezar porque alguien avisa de que «no va internet». El mensaje puede llegar desde un profesor, desde secretaría o incluso a través de conserjería, pero casi siempre llega igual: sin más información. Y detrás de esas tres palabras puede haber problemas completamente diferentes, desde un portátil que no se ha conectado correctamente hasta un punto de acceso sin servicio, una plataforma externa caída o una avería del operador.
«No va internet» puede significar muchas cosas
En un centro educativo, donde una incidencia puede dejar esperando a todo un grupo, el objetivo inicial no debería ser averiguar inmediatamente cuál es la causa exacta. Lo primero es acotar dónde está el problema. Saber si afecta a una persona, a un aula, a una planta o al centro entero permite que quien vaya a resolver la incidencia empiece a trabajar mucho antes y evita hacer cambios innecesarios en una red que quizá está funcionando correctamente.
Desde el aula, muchos fallos diferentes se perciben exactamente igual. El profesor abre una página y no carga. Para él, internet no funciona. Pero técnicamente puede estar ocurriendo que el portátil no haya recibido conexión de red, que el wifi tenga un problema, que el centro no tenga salida a internet o simplemente que la plataforma que intenta utilizar esté temporalmente fuera de servicio.
Por eso uno de los errores más habituales es empezar reiniciando equipos antes de saber qué está pasando. Reiniciar el router, un switch o un punto de acceso puede incluso conseguir que el problema desaparezca, pero eso no significa que hayamos averiguado cuál era la causa: si funciona, no se ha aprendido nada y la avería volverá; si no funciona, se ha destruido la evidencia y hay dos incidencias en lugar de una.
Antes de tocar nada merece la pena dedicar tres o cuatro minutos a hacer unas pocas preguntas. En muchas ocasiones no permitirán saber todavía qué componente está fallando, pero sí reducirán muchísimo el número de posibilidades. Al terminar quizá no sepa qué ha fallado, pero sabrá dónde no hace falta mirar.
La primera pregunta: ¿a quién le pasa?
Esta es probablemente la comprobación que más información aporta y, al mismo tiempo, una de las que menos veces acompaña al aviso inicial. Cuando alguien dice «no funciona internet» suele hablar únicamente de lo que está viendo en su dispositivo. El alcance no se supone: se comprueba. Preguntar si al compañero de al lado le funciona, si en el aula contigua hay conexión o si en secretaría trabajan con normalidad son treinta segundos que ahorran media hora, y hay que hacerlo antes de subir a ningún armario.
Si solo falla un portátil y el resto de la clase está trabajando normalmente, no tiene mucho sentido empezar revisando la conexión general del centro. El problema estará probablemente en ese dispositivo, su configuración, su usuario o su acceso a la red. Si, en cambio, todos los equipos de un aula tienen dificultades mientras la clase de al lado trabaja con normalidad, la investigación cambia y podemos centrarnos en los elementos que dan servicio a esa zona.
Si falla una planta entera, la atención puede dirigirse hacia el armario de comunicaciones o el enlace que la conecta con el resto de la red. Y si no tiene conexión ningún usuario del centro, entonces sí tiene sentido comprobar la salida general a internet, el cortafuegos o la conexión del operador.
Hay otro escenario importante: que el problema afecte a todos los usuarios que utilizan una misma aplicación, independientemente del aula en la que estén. En ese caso la red puede estar funcionando perfectamente y ser el propio servicio el que tenga la incidencia.
La segunda pregunta: ¿qué es exactamente lo que no funciona?
«No me funciona nada» y «no puedo entrar en la plataforma educativa» suelen acabar describiéndose de la misma manera, aunque el diagnóstico sea completamente distinto. Por eso hay que pedir siempre un ejemplo concreto: qué estaba intentando hacer la persona, y qué aparece en pantalla cuando lo intenta.
Si el usuario puede navegar por otras páginas pero no acceder a una plataforma determinada, la conexión a internet existe. En ese momento hay que comprobar si el problema está en el propio servicio, en la autenticación del usuario o en algún elemento relacionado con esa aplicación. Y la comprobación es inmediata: entrar en esa misma plataforma desde una conexión que no pase por la red del centro, por ejemplo los datos móviles de un teléfono. Si tampoco funciona, la incidencia está fuera del edificio. La mayoría de plataformas educativas publican además una página de estado donde anuncian las interrupciones, y tenerla localizada evita muchas salidas en falso.
También puede ocurrir lo contrario: los servidores, impresoras u otros recursos internos siguen funcionando, pero ningún equipo consigue acceder a internet. Eso ya aporta una pista completamente distinta, porque indica que una parte importante de la infraestructura interna sigue operativa y que el problema probablemente está más cerca de la salida del centro.
La tercera pregunta: ¿falla el wifi o falla también la conexión por cable?
Otra comprobación sencilla parte la instalación por la mitad y se responde sin herramientas. Si en la misma zona un ordenador conectado por cable navega correctamente y los dispositivos wifi no, todo lo que va desde la salida a internet hasta ese armario está funcionando, y el problema queda encerrado en la red inalámbrica o en su sistema de autenticación. Si falla también por cable, hay que subir un nivel.
También hay que diferenciar entre tener poca cobertura y estar conectado sin internet. Son dos situaciones que desde fuera pueden parecer iguales, pero tienen causas diferentes. Un dispositivo que apenas ve la red wifi puede tener un problema de cobertura o del punto de acceso que debería atender esa zona. En cambio, un equipo que muestra una señal excelente, se conecta correctamente pero no puede navegar está indicando otra clase de problema, y añadir más cobertura no solucionaría nada. Por eso conviene preguntar qué aparece en la lista de redes, y no solo si «va el wifi».
Las diferentes redes del centro también ayudan a acotar. Si la wifi del profesorado funciona y la del alumnado no, resulta poco probable que el problema esté en la cobertura radioeléctrica. Ambas están llegando desde la misma infraestructura física, y habrá que revisar qué diferencias existen entre sus configuraciones, autenticación o políticas.
La cuarta pregunta: desde cuándo ocurre, y qué cambió
La siguiente pregunta es desde cuándo ocurre. Una red que funcionaba ayer y ha dejado de hacerlo esta mañana plantea un escenario diferente al de un dispositivo que nunca ha conseguido conectarse correctamente: lo primero apunta a un cambio reciente, lo segundo a un alta pendiente.
Detrás de muchas incidencias existe algún cambio reciente, aunque nadie lo relacione. Puede haberse actualizado un equipo durante la noche, haberse realizado una obra en una zona del edificio, producido un corte eléctrico o caducado un certificado en una fecha que nadie tenía apuntada. Incluso algo aparentemente poco tecnológico puede afectar al servicio: un armario que quedó sin ventilación, un equipo que se desconectó para utilizar el enchufe o un cable que se movió durante unos trabajos.
Preguntar simplemente «¿ha cambiado algo?» casi siempre recibe un no, porque quien responde piensa únicamente en cambios informáticos. Suele resultar más útil preguntar qué se ha hecho recientemente en esa zona, y preguntárselo a quien corresponde: a mantenimiento, a limpieza, a la empresa que hizo la obra o al compañero que montó el carro de portátiles.
Esta cuestión cobra especial importancia al inicio del curso. Durante el verano pueden haberse acumulado obras, movimientos de aulas, equipos nuevos, cambios de personal y configuraciones que nadie ha utilizado todavía con el centro lleno. Por eso septiembre suele concentrar incidencias que realmente comenzaron semanas antes.
Después de acotar, las comprobaciones deben seguir un orden
Cuando ya sabemos a quién afecta y qué está fallando, tiene sentido empezar a realizar comprobaciones técnicas. La regla es hacerlas de dentro hacia fuera y desde el equipo donde ocurre el problema: el del despacho está en otra parte de la red y dará una respuesta que no sirve. El orden importa más que las herramientas, y saltar al último escalón es lo que hace que se llame al operador por un latiguillo suelto.
No es necesario que dirección o un profesor sepan realizar estas pruebas. Esta parte corresponde normalmente al responsable TIC o al servicio de soporte. Lo importante es entender que existe un orden lógico, y que cuanta más información haya recogido el centro antes de abrir la incidencia, menos tiempo tendrá que dedicar el técnico a descubrir desde cero qué está ocurriendo.
- ¿El equipo ha recibido dirección de red? Si no tiene ninguna, o tiene una de las que el sistema se autoasigna cuando nadie responde, no está hablando con la red: mire el cable, el puerto o el servicio que reparte direcciones.
- ¿Llega a los equipos de dentro del centro? Si tiene dirección pero no alcanza nada de la red local, está conectado pero aislado, lo que apunta al puerto o al segmento en el que ha quedado.
- ¿Resuelve nombres? Si llega por dirección numérica y no por nombre, el problema es el servicio de nombres: la causa clásica del «internet va lentísimo» que en realidad es «tarda en empezar y luego va bien».
- ¿Sale al exterior? Si resuelve y aun así no llega fuera, mire el camino de salida: el filtrado, el proxy si lo hay o el propio enlace.
- ¿Está en pie el enlace del operador? Sus indicadores, su portal de estado y, si hay monitorización, el histórico de la última hora. Se confirma en un minuto.
También hay que saber cuándo dejar de investigar
Cuando una clase está parada, el tiempo cuenta. El responsable TIC podría seguir probando posibilidades durante una hora y acabar encontrando la causa, pero quizá para entonces ya se haya perdido toda la sesión. Por eso el límite de tiempo hay que ponérselo antes de empezar: cuando ya se lleva media hora, es tarde para ponérselo.
Durante el horario lectivo, unos diez o quince minutos son una referencia razonable para intentar acotar una incidencia antes de escalarla. Si después de ese tiempo todavía no está claro qué ocurre y hay alumnos esperando, cinco minutos más tampoco lo aclararán, y normalmente tiene más sentido pedir ayuda que continuar haciendo pruebas.
Además, hay determinadas situaciones en las que conviene escalar antes: si el problema afecta a todo el centro, si existen indicios de fallo de hardware o alimentación, si el operador confirma una incidencia en la zona o si el servicio afectado está gestionado por un proveedor externo.
Mientras se trabaja en el diagnóstico, la prioridad durante horario lectivo sigue siendo que la actividad pueda continuar. En ocasiones eso significará encontrar una solución provisional y analizar después la causa con más tranquilidad, con el centro ya vacío. Pero tiene un precio: al restablecer el servicio se pierde la evidencia, así que el orden correcto es apuntar primero y tocar después.
Cinco datos pueden ahorrar muchísimo tiempo
No hace falta preparar un informe cada vez que falla algo. La nota escrita durante la avería vale mucho más que el recuerdo posterior, y basta con que existan la hora, el sitio y lo que se probó.
- Hora en que empezó y hora en que se recuperó, aunque sean aproximadas.
- Quién lo reporta, desde qué espacio y con qué equipo, del centro o personal.
- Alcance comprobado: a quién más le pasa y a quién no.
- Qué se probó y con qué resultado, incluido lo que no cambió nada, que también descarta.
- Qué se reinició o se tocó, y a qué hora.
Las notas rinden más en las averías intermitentes
Decir «el wifi a veces va mal por la mañana» aporta muy poco, y son justamente esas averías las que desgastan. En cambio, disponer de varias incidencias registradas con hora, aula y usuarios afectados permite empezar a encontrar patrones: puede coincidir siempre con una zona, con determinado grupo, con una hora concreta o con el momento en que se pone en marcha algún equipo.
También facilita enormemente reclamar una incidencia a un operador o a un proveedor externo. Poder indicar que el servicio cayó a las 10:12, se recuperó a las 10:27 y afectó a todo el edificio aporta mucha más información que comunicar simplemente que «esta mañana internet ha funcionado mal».
Con el tiempo, este mismo hábito permite construir algo todavía más valioso: conocimiento sobre la propia infraestructura. Saber qué armario da servicio a cada zona, tener las rosetas etiquetadas, saber qué punto de acceso cubre cada aula o a quién se llama para cada plataforma reduce mucho el tiempo necesario para resolver la siguiente incidencia.
La mejor incidencia es la que se detecta antes de que llegue al aula
Acotar bien un aviso ayuda mucho cuando ya existe un problema. Pero una red bien gestionada debería permitir detectar una parte de esas incidencias antes de que un profesor tenga que informar de ellas.
Si un punto de acceso deja de responder durante la madrugada, un enlace entre armarios se cae o un equipo crítico muestra problemas, la monitorización puede generar una alerta antes de que empiecen las clases. Eso permite intervenir con otra tranquilidad y, en muchos casos, resolver la situación antes de que tenga impacto sobre alumnos y profesores.
En PenwinEdu monitorizamos 24/7 las redes que gestionamos y atendemos las incidencias con un tiempo de respuesta inferior a cuatro horas hábiles. Pero la ventaja de trabajar durante años con centros educativos va más allá de recibir una alarma. Conocemos la diferencia entre una incidencia que afecta a un despacho y otra que deja parada un aula; sabemos que determinadas actuaciones pueden esperar a la tarde mientras que otras necesitan resolverse durante la clase, y entendemos que el objetivo de la tecnología es que el centro pueda seguir funcionando.
Resolver rápido empieza por entender bien qué está fallando
Cuando alguien dice «no va internet», la solución no debería empezar reiniciando equipos al azar. Empieza averiguando a quién afecta, qué servicio falla, si ocurre por cable y por wifi y desde cuándo está sucediendo. Cuatro preguntas sencillas pueden reducir muchísimo el problema y permitir que el responsable TIC o el servicio de soporte lleguen antes a la causa.
En PenwinEdu utilizamos esa información junto con la monitorización de la infraestructura para diagnosticar las incidencias con mayor rapidez y, siempre que sea posible, adelantarnos a ellas. Porque un buen soporte informático no consiste únicamente en acudir cuando algo deja de funcionar: consiste en conocer la red, entender cómo trabaja el centro y conseguir que una incidencia tecnológica interfiera lo menos posible en una clase.