Los problemas de red actuales requieren cada vez más de un solo ingeniero, o más de un equipo, para resolverlos. Estos problemas pueden involucrar una parte de la red (o una tecnología) con la que no está familiarizado, pueden ser esos problemas realmente complicados que deben escalarse a un ingeniero senior que tiene un "conocimiento tribal" más extenso, o pueden ser problemas que se encuentran fuera de su dominio inmediato de responsabilidad. Este tipo de resolución de problemas en colaboración no es infrecuente, y las brechas en la colaboración entre TI son significativas. NetBrainEncuesta sobre el estado de la red de ingenieros reveló la falta de colaboración como el obstáculo n.º 1 para la solución eficaz de problemas.
Entonces, ¿qué impide la colaboración dentro y entre equipos? Rara vez se debe a que hay algún tipo de obstinación intencional, una mentalidad de "nosotros contra ellos". No es que no lo hagamos want colaborar con otros ingenieros u otros grupos. No es que el personal con menos experiencia simplemente esté pasando la pelota, o que a los hombres de alto nivel les encante la extinción de incendios. La colaboración se ve obstaculizada porque es muy difícil:
Estos desafíos son aún más pronunciados cuando se habla de mitigar los problemas de seguridad de la red, cuando la colaboración efectiva a menudo puede significar la diferencia entre una respuesta oportuna y bien diseñada a una amenaza y un ataque que destruye su red.
Las grandes redes de hoy en día se someten a cambios constantes (modificaciones de interrupción/reparación, actualizaciones de dispositivos y software, evolución de la arquitectura) y los cambios son ejecutados por diferentes personas y diferentes equipos. Los diagramas de red tradicionales se vuelven obsoletos rápidamente y, con demasiada frecuencia, las notas de diseño críticas y otra documentación están incompletas (lo más probable es que no existen). Las empresas modernas tienen una comprensión dispar y descentralizada de su red, de campus a campus, de equipo funcional a equipo funcional. Los días en que los ingenieros individuales tenían experiencia en todas las áreas de una red empresarial han terminado.
Esto introduce un problema de visibilidad: no tiene una idea clara de cómo se ve realmente la red en vivo. Con demasiada frecuencia, simplemente no puede visualizar los datos críticos de TI en el momento en que se necesitan, contextualizado para su tarea particular a la mano. Los diagramas de red tradicionales son solo mapas de topología basados en iconos, donde las imágenes estáticas representan dispositivos pero carecen de inteligencia. NetBrain Dynamic Maps, por otro lado, están basados en datos: cada elemento representa un "gemelo digital" de un dispositivo de red en vivo, con cientos de atributos de datos, incluido su archivo de configuración, protocolos de enrutamiento, vecinos y más. El descubrimiento profundo (no solo a través de SNMP sino también de telnet/SSH) que construye este modelo matemático significa que la documentación que necesita para solucionar problemas de manera efectiva se mantiene y actualiza automáticamente. Usted puede crear un mapa personalizado específico para la tarea en cuestión bajo demanda: la información completa y precisa está disponible al alcance de su mano cuando más la necesita.
NetBrainEl descubrimiento profundo de significa que puede crear un mapa personalizado específico para la tarea en cuestión bajo demanda.
En pocas palabras: ahora no solo tiene un diagrama, sino una consola forense compartida con detalles prácticamente infinitos a la que puede acceder cualquier persona en cualquier lugar. Toda la información de red relevante está disponible para visualizarla directamente en el mapa, lo que facilita compartirla con otros equipos. Simplemente active o desactive los datos contextuales que necesita para el problema que está solucionando. Vea instantáneamente su diseño EIGRP u OSPF de un vistazo, verifique el estado activo/en espera de los dispositivos de conmutación por error ASA; la lista continúa. Prácticamente cualquier dato de cualquier fuente se puede capturar en un Dynamic Map — datos de rendimiento de su herramienta de monitoreo 24 × 7 (p. ej., SolarWinds), tickets abiertos de ServiceNow, datos de Splunk. Si tiene una API, NetBrain puede ingerir los datos y vincularlos al sistema de origen directamente desde el mapa.
NetBrainLa capacidad única de reunir (a) datos de telnet/SSH de cualquier dispositivo en una red de múltiples proveedores y (b) información relevante de otras fuentes a través de API REST significa que ahora también puede visualizar construcciones de SDN como la estructura de Cisco ACI como su red tradicional en una Dynamic Map. Esto es invaluable cuando se solucionan problemas de una aplicación lenta que fluye a través de la estructura ACI y la red heredada, por ejemplo.
Active o desactive prácticamente cualquier información de red, incluidos otros datos NMS, directamente en el mapa.
Ya no tendrá que enviar más archivos de registro por correo electrónico ni revisar volcados de datos basados en texto. Ya no es necesario buscar en la CLI manualmente, un dispositivo a la vez, un comando a la vez, o saltar de una pantalla a otra entre varias herramientas para juntar información.
Obtiene una visión completa de su red en un verdadero panel único donde cualquiera y todos pueden poner los datos en uso: el mapa.
El típico flujo de trabajo manual y repetitivo de solución de problemas implica mucho esfuerzo duplicado para verificar los datos. A medida que los casos se escalan entre diferentes niveles de ingenieros, generalmente los datos de diagnóstico son demasiados o demasiado escasos. Cuando estamos bajo presión, con demasiada frecuencia dejamos solo notas superficiales para los ingenieros del siguiente nivel. La información crítica se pierde en el camino o se entierra dentro de los vertederos de registros. Si usted es el próximo hombre, debe volver a ejecutar los mismos diagnósticos que hizo el tipo anterior, ya sea porque es más rápido que revisar un montón de datos de texto o porque simplemente no está seguro de que estaba preguntando al usuario. preguntas correctas. Terminas reinventando la rueda.
Pero con automatizado RunbookAsí, todos esos diagnósticos del “primer mejor paso” que siempre ejecuta se pueden realizar automáticamente, y los resultados se capturan y registran automáticamente. Los ingenieros de siguiente nivel pueden ver exactamente qué análisis ya se han realizado (y cuándo y por quién), con los resultados del diagnóstico claramente presentados en la pantalla. Dynamic Map en contexto.
Con demasiada frecuencia, termina reinventando la rueda, volviendo a ejecutar los mismos diagnósticos de solución de problemas simplemente porque puede obtener información del volcado de datos del tipo anterior.
En el siguiente ejemplo, el Runbook anotó la configuración de QoS en la parte de la red asignada, ejecutó automáticamente los comandos CLI en todos los dispositivos de una sola vez, resaltó la estrategia de cola y verificó las métricas de rendimiento de QoS. Todos los resultados de esos pasos están disponibles en el mapa. Como ingeniero de siguiente nivel, acaba de evitar el tiovivo de repetir diagnósticos.
Al solucionar problemas de QoS, RunbookLos s facilitan el intercambio de métricas de rendimiento en el mapa (recuento actual de colas, caídas totales, accesibilidad y utilización de memoria/CPU de QoS).
RunbookTambién facilitan la comunicación efectiva con otros ingenieros y otros equipos. Puede alertar a una persona en particular sobre un dispositivo o mapa en particular al escalar problemas. En el siguiente ejemplo, yo (como ingeniero de primeros auxilios) calculé la ruta AB entre un servidor web y un servidor de base de datos, ejecuté una prueba de ping y ejecuté una Qapp de supervisión de estado general (una de NetBrainLos programas personalizables de que aprovechan la automatización para extraer datos de los dispositivos de red y analizarlos) que supervisa las 5 causas principales de la lentitud de la red (estado de la interfaz y rendimiento del enlace, como retrasos, errores y utilización). Todo parecía estar bien, así que necesito pasarle el problema a un ingeniero de segundo nivel, Jason. La función @Mention identifica la solicitud de ayuda para Jason y la función #Mention especifica la URL única de la Dynamic Map donde puede encontrar todos los resultados del diagnóstico. Ahora le he dado a Jason un buen comienzo para descubrir qué es lo que está mal; no tiene que empezar desde cero.
Runbooks hacen que sea más fácil compartir información y escalar problemas al colaborar en un evento.
Una vez que se resuelve el problema, por lo general cualquier análisis post-mortem es limitado. Los datos sin procesar que recopilamos durante la solución de problemas (salida de CLI) se pierden, y es posible que haya aprendido o no algo que me ayude la próxima vez que surja este tipo de problema nuevamente (que probablemente lo hará). Si tengo suerte, Jason, el tipo al que tuve que escalar el problema, me habría mostrado lo que hizo. Pero Jason es como la mayoría de los ingenieros de redes con experiencia en la actualidad: una vez que se resuelve este problema en particular, hay un millón más en cubierta. Simplemente no tiene tiempo para explicar cómo lo hizo, simplemente lo hizo y siguió adelante.
Ahí es donde NetBrain Runbooks entrar. Podía ejecutar sus pasos de solución de problemas en el Runbook (haciendo las mismas cosas que haría manualmente, solo teniendo NetBrain ejecutarlos automáticamente) para que se documenten sobre la marcha. No se requiere codificación. La próxima vez que este tipo de problema asoma la cabeza, puedo ejecutar este Runbook y realice los mismos pasos siguientes que hizo Jason.
Básicamente, hemos transferido su conocimiento y le permitimos compartir su experiencia sin perder el ritmo.
Todo el mundo puede digitalizar su experiencia particular en Runbook flujos de trabajo sin necesidad de conocimientos especiales de programación.
Los ingenieros de red ya no tienen que preocuparse por quién está en el recurso compartido de archivos correcto, circulando carpetas impresas o confiando en un cuaderno escrito a mano encuadernado en espiral en una caja ignífuga en el NOC. En cambio, todos los equipos de datos que necesitan para trabajar juntos están contenidos dentro del NetBrain .