Una actualización de red salió mal

by Felipe Gervasi 5 de diciembre de 2017

Eran alrededor de las 2 AM cuando decidimos tomar un descanso y dirigirnos a la sala de conferencias donde había sobras de pizza de ese día. Me encanta la buena pizza, pero incluso la buena pizza no es tan buena en medio de la noche cuando la actualización de la red no va bien.

Todos los interruptores de acceso en el área de la oficina principal se cambiaron la semana anterior, y esa parte de este proyecto de actualización de interruptores se realizó sin problemas. Esta noche, sin embargo, estuvimos trabajando en el intercambio de dispositivos en la planta de fabricación principal, donde encontramos sorpresa tras sorpresa. Lo que debería haber sido un simple intercambio de interruptores de acceso directo se convirtió en una noche de angustia y heroísmo.

Me detuve durante veinte minutos para tomar una porción de pizza y beber un poco de refresco, tuve la oportunidad de hablar con mis compañeros de trabajo y con nuestro cliente, quien nos dio la documentación de la red en primer lugar. No estábamos completamente enojados el uno con el otro, pero sentí el comienzo de un sutil juego de culpas.

• ¿Cómo podrían faltar tantos interruptores en la documentación?
• ¿Por qué el cliente no nos dijo que estaba usando VoIP de forma inalámbrica y que necesitaba QoS personalizado?
• ¿Cómo no vimos todos el gran volumen de tráfico que va desde el centro de datos a la sala de control?

El alcance del proyecto no era muy diferente de los proyectos anteriores de actualización de red que había realizado, por lo que no era la tecnología real lo que era tan frustrante. Lo que fue tan difícil de digerir junto con lo que debería haber sido un gran refrigerio de medianoche fue darse cuenta de lo mal que se planeó este proyecto debido a la falta de calidad. documentación de la red y deteccion de redes.

No estábamos luchando con la complejidad de configurar una docena de superposiciones, y no estábamos luchando para encontrar una solución a un error de software. En cambio, estábamos luchando con una planificación y procesos deficientes.

Tomando una segunda rebanada, le pregunté a mi cliente si podía pensar en otros interruptores escondidos en falsos techos o bastidores montados en la pared sin documentar. No pudo, así que sugirió que diéramos un paseo para asegurarnos. No me gustó escuchar eso, considerando la hora que era, pero tampoco me gustó escuchar por primera vez que estaban usando un sistema de VoIP sobre telefonía inalámbrica que requería políticas de QoS personalizadas para funcionar de manera efectiva en sus instalaciones de fabricación.

Comenzamos nuestra búsqueda, dejando atrás a un par de ingenieros para que se relajaran y comieran el último pastel de pepperoni tibio. Mi cliente y yo tuvimos una conversación sincera sobre estos temas, lo que realmente me ayudó a desarrollar un sentido de urgencia en él.

Verá, el centro de control estaba generando suficiente tráfico para saturar el enlace troncal de 1 giga de regreso al centro de datos, pero el diseño no requería un canal de puerto o al menos un solo enlace troncal de 10 giga. Esto debería haber sido una cuestión de rutina en cualquier ciclo de actualización de la red, pero ni el cliente ni nuestra gente de preventa realizaron un análisis de tráfico de referencia.

Además, expliqué que dado que estábamos escribiendo una política de QoS personalizada sobre la marcha esta noche, no habría forma de validar realmente su efectividad hasta el día siguiente cuando la red estuviera bajo carga. Lo que deberíamos haber hecho es simular la red tanto como sea posible y enviar la configuración mediante programación. Desafortunadamente, íbamos a tener que tocar cada conmutador nuevo uno por uno para agregar la política de servicio y configuración de QoS relevante a cada puerto troncal.

Lo recuerdo asintiendo con la cabeza y ofreciéndose a ayudar a revertir los cambios de esta noche para que pudiéramos reagruparnos al día siguiente. El único problema con eso, le expliqué, era que ya eran más de las 2 am y todo lo que teníamos que hacer para retroceder sería completamente manual. No estaba seguro de si teníamos suficiente tiempo.

Decidimos seguir adelante, pero nos decidimos a trabajar toda la noche y hasta bien entrada la mañana. Alrededor de las 4 a. m., mi gerente de proyecto estaba en el lugar con grandes cantidades de café y, afortunadamente, hizo todo lo posible para mantenerse fuera de nuestro camino. Estaba agradecido por eso, ya que para entonces no todos habíamos tomado nuestro segundo aire todavía.

Mi equipo encontró varios interruptores maliciosos más que integraron en el nuevo diseño, ya que el cliente no había comprado suficientes para reemplazarlos. Busqué documentación en el sistema telefónico para poder averiguar la política de QoS, pero mi pensamiento inicial fue no molestarme y ver cómo iban las llamadas telefónicas. Sin embargo, incluso en medio de la noche sin carga en la red, nuestras llamadas de prueba fueron muy malas.

Estábamos trabajando con un déficit de información. La ausencia de un descubrimiento de red decente y una comprensión de cómo funcionaban las aplicaciones en la red nos impidió realizar lo que debería haber sido una actualización sencilla del dispositivo de red. No tuvimos en cuenta varias consideraciones importantes antes de emprender este proyecto.

Nuestro primer paso debería haber sido recopilar información sobre la red a través de la documentación y el descubrimiento de la red. Simplemente contar el número de interruptores a reemplazar no es suficiente.

NetBrain aborda esto con dinámica mapas de red que crean documentación precisa en minutos. No se necesita un equipo de ingenieros para rastrear manualmente la red para el descubrimiento de activos y topología.

Tenga en cuenta que esto es mucho más que crear una hoja de cálculo de inventario. Una actualización exitosa de un dispositivo de red comienza con la identificación de las plataformas y las versiones de software para poder planificar las funciones adecuadas en el nuevo diseño. NetBrain captura estos datos mediante programación y bajo demanda, lo que habría sido extremadamente útil para un ingeniero frustrado como yo a las 2 AM.

En segundo lugar, necesitábamos un mecanismo para evaluar las características y la sintaxis del nuevo equipo. Por ejemplo, la actualización de conmutadores de troncales de 1 giga a troncales de 10 gigas puede tener ramificaciones en el árbol de expansión o en las decisiones de enrutamiento, y esto debe probarse y evaluarse antes de que comience el temporizador de ventana de cambio.

En mi caso, necesitaba la capacidad de evaluar la configuración de QoS sobre la marcha y rápidamente. De acuerdo, es extremadamente difícil probar la configuración de QoS sin que la red esté bajo carga, pero es igual de importante probar la implementación real de la sintaxis debido a cuánto puede diferir de una plataforma a otra.

Y tercero, no teníamos forma de tocar mediante programación una gran cantidad de dispositivos. Ser capaz de hacer esto mediante programación tanto en la implementación de la configuración como en la reversión de la configuración puede convertir una actualización de red de un escenario de manos a la obra en un proyecto manejable que un solo ingeniero podría manejar.

NetBrain no puede almacenar todos sus conmutadores por usted, pero aborda la necesidad de detección dinámica de redes, documentación a pedido y mayor capacidad de programación.

Ese proyecto de actualización de la red de la organización de fabricación terminó siendo un éxito, pero trabajamos durante 30 horas seguidas con un equipo de cinco ingenieros para hacerlo realidad. El café ayudó, la pizza ayudó, pero tener las herramientas adecuadas para obtener la información que necesitábamos de antemano y bajo demanda es lo que habría salvado el día.