Los 5 mejores tickets de soporte de red para automatizar
¿Qué es lo que más te frustra del soporte de red? Nada se siente mejor que jugar al detective en un problema de red oscuro y ser el héroe de TI que lo resuelve. Pero demasiado...
¿Cuántos de ustedes solucionaron un problema, se ocuparon de un caso de soporte o recibieron una llamada de un cliente relacionada con un problema de red intermitente? Me imaginaría mucho. La mayoría de las personas en algún tipo de campo relacionado con TI tienden a tener una mentalidad más analítica. Con una mente analítica, a menudo pensamos que si sigue sucediendo, debemos ser capaces de repetirlo. En la mayoría de los casos, tienes razón. Sin embargo, como he estado haciendo varias formas de trabajo de TI durante casi veinte años, puedo asegurarles que este no es siempre el caso.
Los problemas de red intermitentes son eventos que no se replican tan fácilmente. Tampoco llegan a la misma hora del día ni afectan siempre a los mismos usuarios. Como alguien que ha abordado este tipo de problemas en varios puestos, déjame decirte que es horrible encontrarlos. ¡Te sientes impotente y a veces cuestionas tu cordura!
NetBrain nos permitió identificar el problema y tener un punto de partida. Resolver cualquier problema requiere comprender el problema, y sin NetBrain, no estoy seguro de que hubiéramos sido tan rápidos en entender por dónde empezar.
Historia real: apagones intermitentes seis semanas después de una actualización
Una vez tuve un cliente que se estaba actualizando de un entorno Cisco heredado a un entorno Cisco Nexus más nuevo, cuando apareció la arquitectura 7K/5K/2K y estaba conquistando el mercado. Parte de nuestro compromiso de consultoría implicó una evaluación de la red incluso antes de comenzar. ¿Por qué? Queríamos asegurar una transición fluida a la nueva arquitectura y verificar que cada base estuviera cubierta. Nos esforzamos por no tener interrupciones, tiempo de inactividad o impacto de ningún tipo. Sin embargo, ocurren cosas que a veces están fuera de nuestro control. (¿Presagio, tal vez?)
Una vez finalizada la transición, se aprobaron todas las pruebas y todos los equipos estaban contentos. No fue una semana, dos semanas o tres semanas después que recibimos una devolución de llamada. Fue alrededor de seis semanas en sus operaciones estándar cuando el cliente llamó, preocupado porque estaban teniendo apagones intermitentes y necesitaba nuestra ayuda para entender qué estaba mal. Era un problema que aparentemente afectaba a aplicaciones aleatorias y usuarios aleatorios. Como la mayoría de las personas, no pensamos de inmediato que el nuevo núcleo del centro de datos fuera su problema. ¿Por qué? ¡Habían pasado seis semanas! La experiencia nos dijo que la mayoría de los problemas habrían ocurrido y se habrían notado dentro de las 24 horas o una semana como máximo, si es que existió alguno.
¿Por qué las soluciones NMS no solucionan el problema?
¿Qué es lo primero que hicimos? Despedido NetBrain y volvió a ejecutar un descubrimiento actualizado de la red y lo comparó con nuestro mapa posterior a la instalación. Un duplicado exacto, ni siquiera un comando CLI fue diferente entre los dos escaneos. Comenzamos a discutir cómo nada había cambiado desde que nos fuimos, lo que hizo que el director de TI y el vicepresidente se sintieran cómodos de que su equipo no se equivocara. (También nos hizo sentir muy bien). Pero no ayudó a que nadie se sintiera bien por solucionar el problema en cuestión: un gremlin intermitente que parecía causar desconexiones y agujeros negros en el tráfico.
NetBrain puede comparar prácticamente cualquier dato de red entre el estado en vivo y las instantáneas históricas con solo un clic.
Acordamos quedarnos y dejar un mapa a gran escala del campus, el centro de datos y algunos sitios remotos en modo monitor durante la noche, ~16 horas en total. Cuando volvimos al día siguiente, notamos que algunos de los promedios continuos seguían fluctuando ampliamente para el segundo Nexus 7K. ¡Finalmente, teníamos un lugar para comenzar! Comenzamos con sus soluciones de gestión de red, que incluían Splunk, SolarWinds y un puñado de otras herramientas. No vieron ningún problema la noche anterior. ¿Los extrañaron o los umbrales eran demasiado bajos?
Volviendo a NetBrain, nos dimos cuenta de que el tráfico parecía fluctuar dentro y fuera del segundo Nexus 7K, lo que no se alineaba con el patrón de tráfico de entrada/salida regular visto en el primer Nexus 7K. Corriendo en pareja, con tantos enlaces vPC como teníamos, esto era extraño.
No puedes arreglar lo que no puedes ver
¿Qué encontramos? Bueno, encontramos un error, un error intermitente que bloquearía el tráfico. Los errores son inevitables; suceden en todos los productos, software o soluciones que existen. En este caso, nos topamos con uno en particular que provocaría que los módulos de estructura del plano posterior generaran un agujero negro en el tráfico al intentar pasar datos de, por ejemplo, la ranura 3 a la ranura 2. Los módulos del plano posterior no fallaron, por lo que no hubo alertas. El blackholing del tráfico ocurriría en un desbordamiento del búfer debido a otros factores: el cliente no estaba bombeando suficientes datos para estar cerca del límite de procesamiento de datos. Un lanzamiento de código resolvió el problema. cliente feliz
NetBrain proporcionó información valiosa sobre una situación en la que todos los demás medios razonables de "lo que es normal" fallaron. Las otras herramientas podrían haber sido ajustadas para detectar lo que necesitábamos, pero también alertaría sobre demasiados problemas no serios. NetBrain nos permitió identificar el problema y tener un punto de partida. Resolver cualquier problema requiere comprender el problema, y sin NetBrain, no estoy seguro de que hubiéramos sido tan rápidos en entender por dónde empezar.
El análisis comparativo histórico con un solo clic es solo una forma NetBrain ayuda a abordar problemas intermitentes frustrantes. También puede desencadenar un análisis automatizado desde su solución de monitoreo 24×7, sistema de emisión de boletos, IDS/SIEM en el momento en que se detecta un problema.
A esto lo llamamos automatización "justo a tiempo"; mírelo en acción programando una demostración aquí: muéstrame la automatización justo a tiempo