En realidad es difícil despedir a un CCIE. Y no, esto no es una amenaza velada a mi jefe. Pongámonos en la piel de la dirección por un momento. La red es una caja negra que da miedo, no puedes simplemente enchufarle un monitor VGA y ver lo que hay en la pantalla.
Hay un montón de herramientas y sistemas de monitorización diferentes, ninguno de los cuales funciona el 100% de las veces. Cuando la red está haciendo algo realmente inusual o se comporta mal de alguna manera, la respuesta nunca está clara. El problema sólo se puede discernir mirando algunos archivos de registro de aspecto loco, o peor. Si eres unSi te preguntas "¿qué puede haber peor que un archivo de registro?", es evidente que nunca has tenido que leer un rastreo de paquetes.
Para los que acaban de unirse a nosotros, esta es la segunda parte de esta serie. En este post me referiré a todos los expertos en redes como CCIEs. Si eres un CCIE, o un JNCIE, cualquier otro tipo de IE, o simplemente un arquitecto/ingeniero de redes estrella del rock, ¡cuando hablo de CCIEs estoy HABLANDO DE TI! Es una gran carpa, ven y únete a nosotros...
Así que volvamos a mi afirmación de la última vez. Un CCIE hace básicamente estas 4 cosas:
- Rompe la red - Mi último mensaje
- Arregla la red - Este puesto
- Movimientos/Aumentos/Cambios
- Gestión de proyectos
Si volvemos a ponernos en la piel de nuestro gerente, consideramos a nuestros empleados CCIE como un activo muy valioso. Muchas empresas tienen un CCIE como mucho, unas pocas tienen más de uno, y la gran mayoría de las empresas no tienen ninguno. Encontrar CCIEs, contratar CCIEs, emplear CCIEs y mantener CCIEs es difícil. Pueden ser bastante caros y a veces resulta un poco extraño interactuar con ellos. Así que, para un directivo que cuenta con uno en su plantilla, ¿cuáles son las ventajas?
Los CCIE (además de trabajar de verdad) son un poco como los seguros. Son los jefes de la organización de TI, a quienes se acude cuando las cosas están REALMENTE rotas. No pueden arreglar todos los problemas de la capa de aplicación, pero al menos pueden señalar qué sistema no está haciendo lo que debería. Así que tu CCIE, posiblemente leyendo una captura de paquetes, puede decirle a tu organización dónde está el problema. ¿Qué servidor no responde? Y si las cosas no funcionan y no tienes un CCIE, ¿qué opciones tienes?
- Llame al proveedor de la red (por ejemplo, Cisco TAC, Juniper JTAC).
- Llame a su proveedor de servicios gestionados
- Contrata a un asesor y espera que no esté demasiado ocupado para ayudarte
- Ir a StackOverflow, ChatGPT, Discord
- Contacte con su deidad local
Ninguna de estas opciones es especialmente buena. Cada una de ellas requiere cierto tiempo de espera, posiblemente el intercambio de algún dinero (o en el caso de la deidad, tu primogénito), y todas requieren que otra persona se ponga al día sobre tu entorno. Si su empresa está en crisis y tiene que esperar a que un consultor entienda su problema, acceda a sus sistemas y solucione el problema, digamos que esos minutos, horas o días van a pasar como una eternidad. Por lo tanto, si tu empresa es tan grande e importante que no puedes tolerar este retraso, contratas a un CCIE. Y tener a esa persona al final del pasillo de tu oficina es tu propia forma de seguro. Es el respaldo. La responsabilidad termina ahí.
Pero, ¿y si el CCIE no puede arreglarlo? En primer lugar, eso empujaría al CCIE al pozo mental del síndrome del impostor. Siempre hay un problema que puede desconcertar a cualquier experto, incluidos los CCIE. Por suerte, aún pueden ponerse en contacto con cualquiera de las terceras partes mencionadas anteriormente y, mientras están en espera, siguen resolviendo problemas y capturando información para ayudar a otra persona a comprender la raíz del problema. Y si se ponen en contacto con una entidad de soporte remoto como un Centro de Asistencia Técnica (TAC), actúan como manos remotas expertas, realizando todas las acciones físicas necesarias para obtener información que permita identificar el problema.
Todos los CCIE sufren el síndrome del impostor. Siempre hay algo que no podemos descifrar o arreglar y, aunque a veces resulta inquietante, es una realidad cuando manejamos equipos construidos por otra persona.
En mi último post tuve algunos momentos de mea culpa (traducción: metí la pata). Pero hubo algunos momentos en los que definitivamente NO tuve el síndrome del impostor. Hubo momentos en los que salvé el día o, como pone en mi currículum, a veces soy la hostia.
Breve historia de Josh
Me apresuré a entrar en la sede central de una empresa global de medios de comunicación y radiodifusión a las 2 de la madrugada, cuando toda la red estaba colapsada, y pasé horas resolviendo problemas y escabulléndome por el campus como un bandido hasta que encontré un interruptor viejo y polvoriento en una oficina de climatización que estaba 4 pisos por debajo del nivel de la calle en pleno Manhattan. El conmutador estaba en una habitación donde un gerente de instalaciones supervisaba el aire acondicionado de todo un campus corporativo en una pequeña pantalla, y cuando irrumpí en su habitación sin avisar a las 4 de la mañana y corrí hacia el conmutador y tiré de uno de los cables fue una escena sacada de El Señor de los Anillos. Este tipo (que claramente nunca recibía visitas y parecía que no le daba mucho el sol) estaba ciertamente asustado de que yo entrara en su guarida y me metiera con su Precious. En fin. La red volvió a la vida y salí lentamente de los túneles de vapor. GANEMOS. Lección: Como experto, debe dedicar tiempo a visitar e inspeccionar visualmente cada pieza del equipo, por remota que sea.
Una vez solucioné un problema con un Cisco 7206VXR colgado mientras estaba de vacaciones a través de una conexión telefónica irregular, utilizando a una persona completamente inexperta como mis manos en el centro de datos remoto. Por suerte tengo algo de memoria fotográfica, así que pude describir la ubicación exacta del dispositivo, así como dónde encontrar un cable auxiliar y un dongle, y dónde se encuentra el puerto de la consola en medio de un nido de cables viejos. Mi compañero remoto tuvo su primera experiencia construyendo un carro de choque y conectándose a la consola (probablemente le marqué de por vida) y una vez que supimos que el dispositivo estaba colgado lo reiniciamos. Red restablecida. En el puente de conferencias estaban mi jefe directo, el jefe de departamento y el director de una empresa recientemente adquirida que posee varios estudios de cine. Fueron efusivos en sus elogios. Colgué la llamada y me tomé (otra) piña colada. Lección: Deja cables de consola adicionales en todos los sitios que puedas. Lección 2: Disfruta de tu tiempo libre, te lo mereces.
Una vez puse fin a una semana de resolución de problemas que alguien había estado haciendo en un Nexus 7k que decidía indiscriminadamente qué paquetes reenviar. Hice un viaje al lugar para ayudar a un ingeniero junior, tardé 2 minutos en detectar el problema. "¿Por qué está torcido el chasis?". Pasan unas horas y él admite que se les cayó "una sola vez" mientras lo colocaban en su sitio. La multitud enloquece. Lección: Los equipos caídos probablemente estén defectuosos.
Yo solito resolví un problema que causaba cortes esporádicos entre dos grandes empresas de medios de comunicación que se estaban fusionando. El arquitecto de red super-senior de la otra compañía decidió que sería bonito aislar los controles administrativos poniendo dos SUP4s en un único 6509, con cada compañía controlando uno. MALA IDEA. Lección: Los supervisores redundantes deben tener configuraciones idénticas.
Salvé un importante sitio web de comercio electrónico de la caída durante el incidente del apagón de la Costa Este en 2003. Estaba en mi mesa cuando se fue la luz en el edificio. Lo primero que pensé fue: "Oh, mierda, espero no haber sido yo", y me puse manos a la obra, subiendo tres tramos de escaleras hasta un centro de colocación para comprobar qué le había pasado a nuestro centro de datos. Por suerte, el centro de datos tenía baterías de reserva, así que todo funcionaba, pero en un momento de clarividencia decidí comprobar si nuestros conmutadores centrales estaban conectados a la red eléctrica de reserva, que sería la única fuente de energía en menos de 5 minutos. Me di cuenta de que alguien había conectado mal las fuentes de alimentación redundantes a un conmutador central. Buscando algo parecido al Correcaminos, encontré un cable de repuesto y lo inserté unos 3 segundos antes de que la alimentación cambiara de la batería al generador de reserva. Si no lo hubiera hecho, toda la empresa se habría venido abajo. Lección: Sea proactivo a la hora de evaluar los escenarios de recuperación en caso de catástrofe y pruébelo todo con frecuencia.
No construyas copos de nieve
Pero no todo el mundo puede permitirse tener un experto en redes en su plantilla 24 horas al día, 7 días a la semana. Por eso existen montones de herramientas de supervisión, análisis y solución de problemas de red. Además, el sector ha avanzado mucho en los últimos 10 años. Ahora construimos redes con unos cuantos diseños bastante comunes y muchos productos aplican por defecto las mejores prácticas de diseño. De hecho, se puede diseñar una red en línea e integrar en el diseño todas las técnicas y optimizaciones utilizadas por los principales proveedores de nube. Estas mejoras no sólo eliminan los problemas de antemano, sino que las topologías de red bien diseñadas y deterministas son mucho más fáciles de solucionar si alguna vez se hereda una.
¿Son los CCIE menos valiosos ahora? Si su red está averiada, la respuesta es claramente NO, es probable que pague cualquier cantidad de dinero para que todo vuelva a funcionar. Pero el mundo ha cambiado mucho en los últimos veinte años. En realidad no utilizamos una tonelada de protocolos diferentes (RIP: DLSW, Appletalk, IPX/SPX, DECnet, Vines, etc.), y ciertas topologías y diseños de red han demostrado ser la mejor solución técnica para determinados casos de uso (por ejemplo, Leaf-Spine Clos Fabric para la conectividad de servidores de centros de datos). Lo que esto significa es que los arquitectos están construyendo unidades de red repetibles (y fiables), en lugar de algo incoherente que es difícil de solucionar. Y esto significa que es menos probable que necesites un CCIE. Seguiremos hablando de esto en la Parte 3.
Hasta la próxima.
Josh Saul ha sido pionero en soluciones de red de código abierto durante más de 25 años. Como arquitecto, construyó redes centrales para GE, Pfizer y NBC Universal. Como ingeniero en Cisco, Josh asesoró a clientes del sector financiero de Fortune 100 y evangelizó nuevas tecnologías entre los clientes. Más recientemente, Josh dirigió equipos de marketing y productos en VMware (adquirida por Broadcom), Cumulus Networks (adquirida por Nvidia) y Apstra (adquirida por Juniper). Josh vive en Nueva York con sus dos hijos y es un ávido submarinista.