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.
Para empezar , no sabía nada sobre la aplicación ni sobre el sistema de almacenamiento en cuestión. ¿Cómo se comunicaban entre sí? ¿Qué puertos se utilizaban? ¿Se trataba realmente de una interrupción total o intermitente?
En segundo lugar , la mayoría de los demás líderes de 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 fuera y luego demostrárselo a un grupo de personas que sabían poco sobre dominios de difusión, TCP/IP, listas de control de acceso y cortafuegos con estado.
En tercer lugar , la persona que lideró el proyecto no era un ingeniero full stack; en otras palabras, el jefe de proyecto no tenía un conocimiento suficiente de todas las áreas técnicas relacionadas con el incidente. Esto impidió que avanzáramos con claridad; si bien el esfuerzo fue colaborativo, también se sintió descoordinado y como si estuviéramos dando palos de ciego.
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é al solucionar los fallos de la aplicación que describí ilustran precisamente esto. Individualmente, cada líder de equipo conocía su área a la perfección, pero sabíamos muy poco de las áreas de los demás. Por ejemplo, yo no sabía cómo se comunicaba la aplicación con sus servidores backend y, hasta esta sesión de resolución de problemas, desconocía por completo 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.