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...
Hice clic en "Responder" en mi softphone y atendí la llamada. Una parte de mí quería ignorarlo, pero este problema me había estado molestando durante demasiado tiempo.
Era uno de los chicos del equipo de Aplicaciones. A pesar de que se sentó a solo unos cientos de pies de distancia en el otro lado del edificio, se sentía como si estuviéramos a un millón de millas de distancia la mayor parte del tiempo.
El gerente de proyecto de esta nueva implementación también estaba rondando ahora. Me gustaba, pero se estaba poniendo nerviosa. El cliente y todos los demás querían que esto funcionara ayer.
"¿Podría ser un problema con las VLAN?", Preguntó la voz por teléfono.
Era una pregunta sin sentido, pero no iba a decir eso. Francamente, me sorprendió que no preguntara si era un problema con el cortafuegos, ya que suele ser donde suelen empezar estas cosas. Le aseguré que no había ningún bloqueo dentro de ninguna VLAN individual o entre las VLAN que estábamos analizando con este problema. Realmente no creía que esto fuera un problema de red, pero eso suele ser lo primero a lo que se culpa.
Llegamos a otro callejón sin salida, por lo que programamos una reunión para después del almuerzo con otros líderes de equipo.
Salí de la oficina y tomé un poco de Burger King, un placer culposo que encuentro demasiado fácil de justificar en los días estresantes. La llamada era para la 1:XNUMX p. m., lo que me molestó porque tenía que volver corriendo, pero al menos cuando me senté en mi escritorio me quedaban algunas papas fritas para comer y una Coca-Cola alta para beber.
Casi inmediatamente después de unirse a la conferencia telefónica, el gerente de seguridad comenzó a cuestionar por qué no teníamos segregación entre ciertas VLAN. Por supuesto, esto no se relacionaba con el problema en absoluto, pero me vi obligado a explicar nuestra red y cómo, en este caso, era bueno que no hubiera nada entre el servidor de aplicaciones y las bases de datos de back-end. Todo era capa 2 y, francamente, me molestó que nuestra persona de seguridad aún no conociera nuestra red.
El gerente del proyecto intervino y me preguntó cortésmente cómo solucioné los problemas de conectividad para llegar a mis conclusiones. Usó términos como "establecer nivel" y "burbujear", que escuché pero descarté sumariamente como un galimatías.
¿Cómo se suponía que debía responder? Era inteligente, lo sabía, pero no sabía nada sobre redes. Empecé a hablar sobre el rastreo de caminos y ese tipo de cosas que inmediatamente dieron como resultado que alguien pusiera cortafuegos en el camino. Al principio no sabía quién había mencionado eso, creo que fue uno de los muchachos del equipo de aplicaciones.
Puse los ojos en blanco, pero al menos resultó que alguien del equipo de almacenamiento o de aplicaciones, no estoy seguro de cuál, empezó a hablar de tiempos de espera.
¡Bingo!
Salté con entusiasmo para confirmar lo que dijo y expliqué que la conectividad está bien si los servidores están hablando pero se agotan. Aseguré que no había configuraciones que causaran tiempos de espera, especialmente porque era toda la capa 2 entre los dispositivos. Esto, por alguna razón, todo el grupo aceptó. Finalmente comenzamos a hacer algunos progresos.
Este problema estaba en el lado de la aplicación de la casa, pero se necesitaron varias reuniones para explorar posibles problemas de red con personas que solo tenían un conocimiento superficial de redes. Ciertamente había un deseo de colaborar, y nos reímos mucho después de que se resolvió el problema, pero el proceso para llegar allí fue doloroso.
Nombre, no sabía nada sobre la aplicación o el almacenamiento de back-end en cuestión. ¿Cómo se comunicaban realmente entre ellos? ¿Qué puertos se estaban utilizando? ¿Fue realmente un apagón completo o fue intermitente?
Segundo, la mayoría del resto de los líderes del equipo sabían muy poco sobre redes, pero asumieron de inmediato que ese era el problema. Eso significaba que primero tenía que asegurarme de que no lo era y luego demostrárselo a un grupo de personas que sabían poco sobre dominios de transmisión, TCP/IP, listas de control de acceso y firewalls con estado.
Código , la persona que lideró el cargo no era un ingeniero completo o, en otras palabras, el gerente del proyecto no tenía una comprensión razonable de todas las áreas técnicas relacionadas con el incidente. Esto significaba que no avanzábamos en una dirección clara; el esfuerzo fue ciertamente colaborativo, pero también se sintió inconexo y como si estuviéramos filmando en la oscuridad.
No creo que mi experiencia sea única. Muchos de nosotros, los profesionales de la tecnología, hemos experimentado el juego de la culpa en un intento de colaboración. El conocimiento tribal entre los silos sigue siendo muy real en la TI empresarial, y aunque puede haber un ingeniero de pila completa y un gerente de proyecto ocasionales con un conocimiento técnico profundo, en general todavía estamos lidiando con equipos aislados y un intercambio mínimo de conocimientos.
Los problemas que enfrenté en el solución de problemas de la aplicación Describí ilustrar esto mismo. Individualmente, cada líder de equipo conocía muy bien su área, pero sabíamos muy poco de las áreas de los demás. Por ejemplo, no sabía cómo se comunicaba la aplicación con sus servidores backend y, hasta esta sesión de solución de problemas, no sabía qué servidores se comunicaban entre sí.
Además, la gente de la aplicación no sabía que estos servidores en particular no tenían cortafuegos entre ellos. Tengo que preguntarme cuánto tiempo discutieron esa teoría antes de crear el incidente en nuestro sistema de emisión de boletos.
Y además de eso, el gerente del proyecto que manejaba el incidente no tenía una visión unificada de los aspectos técnicos del incidente más allá de los correos electrónicos mal redactados y las notas ambiguas en el ticket.
Cuando los equipos colaboran en un problema o diseño específico, compartir información es fundamental. Pero a menudo es difícil compartir o dar sentido a información aleatoria de alto nivel. Los archivos de registro, los volcados de datos, el correo electrónico y las notas de tickets tienen su lugar, pero necesitamos una mejor solución para cerrar la brecha entre los equipos que intentan colaborar en la oscuridad.
Automatizar los pasos de solución de problemas más comunes con los que nos gusta comenzar es una forma de obtener una línea de base de información que se comparte fácilmente. De hecho, una herramienta de automatización sofisticada debe ir más allá de la simple automatización de las tareas de solución de problemas más comunes, sino también ejecutar una variedad de comandos show relacionados con la plataforma para obtener una línea base en el momento en que ocurre el problema.
Varios equipos podrían entonces acceder a la misma información al mismo tiempo para analizarla, tanto en profundidad técnica como en formato gráfico, democratizando así el conocimiento que de otro modo estaría en manos de equipos individuales o, peor aún, de ingenieros individuales.
No soy un experto en almacenamiento y no soy un gurú del desarrollo de aplicaciones. Mi conjetura es que en la mayoría de las organizaciones empresariales, los ingenieros todavía se especializan en una o solo unas pocas áreas como yo. Si vamos a avanzar rápidamente para identificar la causa de la lentitud en una aplicación o por qué una ruta en nuestra infraestructura está completamente rota, necesitaremos trabajar juntos.
Una cultura de colaboración que rechace el juego de la culpa y utilice herramientas que democraticen el conocimiento y lo hagan fácilmente disponible entre los equipos es el camino a seguir, no acumularlo en nuestras unidades locales y, ciertamente, no culpar primero a la red.