En el momento en que se escribió este artículo, la búsqueda en un conocido sitio de trabajo con la frase 'Ingeniero de redes' arrojaba alrededor de trescientas ofertas en toda Rusia. Para comparar, la búsqueda con la frase 'Administrador de sistemas' devuelve casi 2.5 mil vacantes, mientras que 'Ingeniero DevOps' casi 800.
¿Significa esto que los ingenieros de redes ya no son necesarios en la época de las nubes dominantes, Docker, Kubernetes y el ubicuo Wi-Fi público?
Vamos a averiguarlo (c)
Vamos a conocernos. Me llamo Alexey y soy ingeniero de redes.
He estado trabajando con redes durante más de 10 años y más de 15 años con varios sistemas *nix (he manejado tanto Linux como FreeBSD). He trabajado en operadores de telecomunicaciones, grandes empresas que se consideran 'empresariales', y en los últimos años he estado en una fintech 'joven y audaz', donde las nubes, DevOps, Kubernetes y otras palabras aterradoras, que inevitablemente harán que yo y mis colegas seamos innecesarios. Algún día. Quizás.
disclaimer: 'En nuestra vida no todo es así, siempre y en todas partes, y algo, a veces y en lugares' (c) Maxim Dorofeyev.
Todo lo que se escribe a continuación puede y debe considerarse como la opinión personal del autor, sin pretender ser la última palabra en la verdad, y ni siquiera una investigación completa. Todos los personajes son ficticios, todas las coincidencias son casuales.
Bienvenido a mi mundo.
¿Dónde se pueden encontrar ingenieros de redes?
1. Operadores de telecomunicaciones, empresas de servicios y otros integradores. Aquí todo es simple: la red para ellos es un negocio. Venden conectividad directamente (operadores) o brindan servicios para la creación/mantenimiento de redes de sus clientes.
Aquí hay mucha experiencia, pero no tanto dinero (si no eres director o un exitoso gerente de ventas). Sin embargo, si te gustan las redes y estás al inicio de tu camino, una carrera en el soporte de algún operador no muy grande es, incluso ahora, un punto de partida ideal (en las empresas federales todo está muy guionizado y hay poco espacio para la creatividad). Además, las historias sobre cómo es posible ascender de ingeniero de guardia a gerente de nivel C en unos pocos años también son bastante reales, aunque raras, por razones obvias. Siempre hay una necesidad de personal, ya que la rotación es una realidad. Esto tiene sus pros y sus contras: siempre hay vacantes, pero por otro lado, a menudo, los más activos/inteligentes se van rápidamente, ya sea por ascenso o a otros lugares más
2. Condicional «empresa». No importa si su actividad principal está relacionada con TI o no. Lo importante es que tiene su propio departamento de TI, que se encarga de asegurar el funcionamiento de los sistemas internos de la empresa, incluidos las redes en las oficinas, los canales de comunicación en las sucursales, etc. Las funciones del ingeniero de redes en tales empresas pueden ser desempeñadas ‘a tiempo parcial’ por un administrador de sistemas (si la infraestructura de red es pequeña, o si un contratista externo se encarga de ella), y el especialista en redes, si es que existe, puede supervisar también la telefonía y el SAN (no es un detalle menor). Los salarios varían — dependen en gran medida de la rentabilidad del negocio, el tamaño de la empresa y la estructura. He trabajado tanto con empresas donde los Cisco se ‘cargaban a barreales’, como con empresas donde la red se construía con excremento, palos y cinta aislante azul, y los servidores no se actualizaban, prácticamente, nunca (no hace falta decir que no se preveían reservas). Aquí hay mucho menos experiencia, y casi con seguridad estará en el ámbito del duro vendor-lock, o ‘cómo hacer algo de la nada’. Personalmente, allí me pareció extremadamente aburrido, aunque a muchos les gusta — todo es bastante pausado y predecible (si hablamos de grandes empresas), ‘dora-ha-bajato’, etc. No menos de una vez al año, algún gran proveedor dice que ha ideado otro sistema mega-súper-poderoso, que automatiza todo ahora mismo y que todos los administradores de sistemas y redes pueden ser despedidos, dejando a un par para presionar botones en una interfaz bonita. Sin embargo, la realidad es que, incluso si abstraemos del costo de la solución, los especialistas en redes no desaparecerán de allí. Sí, es posible que en lugar de la consola vuelva a haber una interfaz web (pero ya no de un equipo específico, sino de un gran sistema que gestiona decenas y cientos de esos equipos), pero el conocimiento de ‘cómo está todo organizado por dentro’ seguirá siendo necesario.
3. Empresas de productos, cuyo beneficio proviene del desarrollo (y, a menudo, explotación) de algún software o plataforma — ese mismo producto. Por lo general, son pequeñas y ágiles, aún están lejos de la escala de las empresas grandes y su burocratización. Es aquí donde abundan esos devops, kuberos, Docker y otras palabras aterradoras, que sin duda convertirán la red y a los ingenieros de redes en un relícto innecesario.
¿Qué diferencia a un especialista en redes de un administrador de sistemas?
En la comprensión de las personas ajenas a IT, no significa nada. Ambos miran a una pantalla negra y escriben algo que parece un hechizo, a veces murmurando maldiciones en voz baja.
Desde la perspectiva de los programadores, es quizás solo un ámbito de especialización. Los administradores de sistemas gestionan servidores, los administradores de red manejan conmutadores y routers. A veces lo hacen mal, y todos sufren las consecuencias. En caso de algún problema extraño, los de red también tienen su parte de culpa. Just because fuck you, that’s why.
En realidad, la principal diferencia radica en el enfoque del trabajo. Tal vez, entre los administradores de red es donde más se escucha el enfoque de «¡Funciona, no lo toques!». Generalmente, se puede hacer algo (dentro de un único proveedor) de una sola manera, toda la configuración del dispositivo está a la vista. El costo de un error es alto, a veces demasiado alto (por ejemplo, tendrás que recorrer cientos de kilómetros para reiniciar un router, mientras miles de personas se quedarán sin conexión, una situación bastante habitual para un proveedor de servicios).
A mi juicio, precisamente por eso, los ingenieros de red están extremadamente motivados a mantener la estabilidad de la red (y los cambios son el principal enemigo de la estabilidad); además, su conocimiento se adentra más en la profundidad que en la amplitud (no necesitas saber configurar decenas de demonios diferentes, necesitas conocer las tecnologías y su implementación en un fabricante específico de hardware). Por eso, un administrador de sistemas que encontró en Google cómo configurar VLAN en un dispositivo Cisco, no es aún un ingeniero de red. Y es poco probable que pueda mantener de manera efectiva (así como solucionar problemas) una red medianamente compleja.
Pero, ¿por qué necesitas un ingeniero de red si tienes ofrezca una gran cantidad de espacio en disco.?
Por un costo adicional (y si eres un cliente muy grande y querido, incluso puede ser gratis, «por amistad»), los ingenieros del centro de datos configurarán tus conmutadores según tus necesidades, y quizás incluso ayudarán a establecer la conexión BGP con los proveedores (si tienes tu propia subred direcciones ip para anunciar).
El problema principal es que el centro de datos no es su departamento de TI, sino una empresa separada cuyo objetivo es obtener beneficios. Esto incluye obtener ingresos de usted como cliente. El centro de datos proporciona racks, les suministra electricidad y refrigeración, y también ofrece cierta conectividad "predeterminada" a Internet. Con base en esta infraestructura, el centro de datos puede alojar su hardware (colocación), alquilarle un servidor (servidor dedicado) o proporcionar servicio gestionado (por ejemplo, OpenStack o K8s). Sin embargo, la administración de la infraestructura de los clientes no suele ser la actividad principal del centro de datos, porque este proceso implica mucho trabajo, es difícil de automatizar (y en un centro de datos normal se automatiza todo lo que es posible), y es aún más difícil de estandarizar (cada cliente es único) y, en general, puede dar lugar a reclamaciones (“me configuraron el servidor y ahora se cayó, ¡ustedes son los culpables!”). Así que, si el proveedor de hosting le ayuda en algo, tratará de hacerlo de la manera más sencilla y básica posible. Hacerlo de manera complicada no es rentable, al menos desde el punto de vista del esfuerzo requerido por los ingenieros de ese proveedor (aunque hay situaciones particulares, ver el descargo de responsabilidad). Esto no significa que el proveedor de hosting por obligación hará todo mal. Pero no es seguro que él haga precisamente lo que usted realmente necesitaba.
Aparentemente, es algo bastante obvio, pero en mi experiencia me he encontrado varias veces con que las empresas empezaron a depender de su proveedor de hosting un poco más de lo que debían, y esto no terminó bien. Tuve que explicar detalladamente que ningún SLA cubrirá las pérdidas por inactividad (hay excepciones, pero normalmente son muy, MUY caras para el cliente) y que el proveedor de hosting no está informado sobre lo que sucede en la infraestructura de los clientes (más allá de indicadores muy generales). Y además, el proveedor tampoco hace copias de seguridad en su nombre. La situación es aún más complicada si tiene más de un proveedor de hosting. En caso de algún problema entre ellos, seguramente no aclararán por usted lo que realmente salió mal.
Los motivos aquí son exactamente los mismos que al elegir entre 'equipo propio de administradores vs. outsourcing'. Si los riesgos están calculados, la calidad satisface y el negocio está de acuerdo, ¿por qué no intentarlo? Por otro lado, la red es una de las capas más básicas de la infraestructura, y difícilmente vale la pena dejarla en manos de externos si ya mantienes todo lo demás tú mismo.
¿Cuándo se necesita un ingeniero de redes?
A continuación, hablaremos específicamente sobre las empresas de productos modernas. Con los operadores y las empresas grandes está más o menos claro: no ha habido muchos cambios en los últimos años y siempre han necesitado ingenieros de redes. Sin embargo, en el caso de las 'jóvenes y audaces', la situación no es tan sencilla. A menudo, colocan su infraestructura completamente en la nube, así que ni siquiera necesitan administradores, excepto los de esas mismas nubes, por supuesto. La infraestructura, por un lado, es bastante simple en su diseño, pero, por otro lado, está bien automatizada (ansible/puppet, terraform, ci/cd... bueno, ya sabes). Pero incluso aquí hay situaciones en las que no se puede prescindir de un ingeniero de redes.
Ejemplo 1, clásico
Supongamos que la empresa comienza con un servidor con una dirección IP pública, que se encuentra en un centro de datos. Luego el número de servidores aumenta a dos. Después más... Tarde o temprano, surge la necesidad de una red privada entre los servidores. Porque el tráfico 'externo' está limitado tanto en ancho de banda (no más de 100 Mbit/s, por ejemplo) como en volumen de datos transferidos al mes (diferentes proveedores tienen diferentes tarifas, pero el ancho de banda hacia el exterior, por lo general, es mucho más caro que una red privada).
El proveedor de alojamiento agrega a los servidores tarjetas de red adicionales y las conecta a sus interruptores en un vlan separado. Entre los servidores, aparece una red local 'plana'. ¡Conveniente!
El número de servidores está aumentando, el tráfico en la red privada también — copias de seguridad, replicaciones, etc. El proveedor de servicios de alojamiento se ofrece a trasladarte a conmutadores separados, para que no interfieras con otros clientes y ellos no interfieran contigo. El proveedor instala algunos conmutadores y los configura de cierta manera — probablemente dejando entre todos tus servidores una red plana. Todo funciona bien, pero en un momento dado comienzan los problemas: periódicamente aumentan las latencias entre los hosts, en los registros hay quejas sobre un número excesivo de paquetes ARP por segundo, y un pentester al auditar ha dominado toda tu red local, rompiendo solo un servidor.
¿Qué se debe hacer?
Dividir la red en segmentos — VLANs. Configurar una dirección propia en cada VLAN, asignar una puerta de enlace que redirija el tráfico entre las redes. En la puerta de enlace, configurar ACL para restringir el acceso entre segmentos, o incluso colocar un cortafuegos separado al lado.
Ejemplo 1, continuación
Los servidores están conectados a la red local con un cable. Los conmutadores en los racks están conectados entre sí de alguna manera, pero cuando hay una falla en un rack, se caen otros tres vecinos. Existen esquemas, pero hay dudas sobre su actualidad. Cada servidor tiene su dirección pública, que es proporcionada por el proveedor de servicios y está vinculada al rack. Es decir, al mover el servidor, es necesario cambiar la dirección.
¿Qué se debe hacer?
Conectar los servidores mediante LAG (Link Aggregation Group) con dos cables a los conmutadores en el rack (también hay que reservarlos). Reservar las conexiones entre racks, transformarlas en "estrella" (o el ahora popular CLOS), para que la caída de un rack no afecte a los demás. Destacar racks “centrales”, donde se ubicará el núcleo de red y donde se conectarán otros racks. Además, organizar la asignación de direcciones públicas, obtener de tu proveedor (o de RIR, si es posible) un bloque de direcciones que anunciarás al mundo por tu cuenta (o a través del proveedor).
¿Puede hacer todo esto un "administrador de sistemas" común, que no tenga conocimientos profundos en redes? No estoy seguro. ¿Lo hará el proveedor de servicios? Puede que lo haga, pero necesitarás un pliego de condiciones bastante detallado, que también deberá ser redactado por alguien. Luego tendrás que asegurar que todo se haga correctamente.
Ejemplo 2. Nube
Supongamos que tienes una VPC en alguna nube pública. Para acceder desde la oficina o desde la parte on-prem de la infraestructura a la red local dentro de la VPC, necesitas configurar una conexión a través de IPSec o un canal dedicado. Por un lado, IPSec es más barato, ya que no necesitas comprar hardware adicional; puedes configurar un túnel entre tu servidor con dirección pública y la nube. Pero, hay retrasos, un rendimiento limitado (ya que el canal necesita ser cifrado), además de conectividad no garantizada (porque el acceso se realiza a través de internet convencional).
¿Qué se debe hacer?
Establecer la conexión a través de un canal dedicado (por ejemplo, en AWS esto se llama Direct Connect). Para ello, hay que encontrar un operador asociado que te conecte, determinar el punto de acceso más cercano a ti (tanto para el operador como para la nube) y, finalmente, configurar todo. ¿Se puede hacer esto sin un ingeniero de redes? Seguramente, sí. Pero cómo solucionar problemas sin él en caso de fallos ya no es tan claro.
También pueden surgir problemas de disponibilidad entre nubes (si tienes un entorno multicloud) o problemas de latencia entre diferentes regiones, etc. Sin duda, ahora hay muchas herramientas que aumentan la transparencia de lo que ocurre en la nube (como Thousand Eyes), pero estas son herramientas para ingenieros de redes, no un sustituto.
Podría mencionar una docena de ejemplos similares de mi experiencia, pero creo que queda claro que en un equipo, a partir de cierto nivel de desarrollo de infraestructura, debe haber al menos una persona (y mejor aún, más de una) que sepa cómo funciona la red, pueda configurar el equipo de red y resolver problemas si surgen. Créeme, tendrá mucho en qué ocuparse.
¿Qué debe saber un ingeniero de redes?
No es necesario (y a veces, incluso perjudicial) que un ingeniero de redes se dedique solo a la red y a nada más. Aunque no tomemos en cuenta la opción de infraestructura que vive casi completamente en la nube pública (que, de hecho, se está volviendo cada vez más popular), y hablemos, por ejemplo, de nubes on-premises o privadas, donde solo con "conocimientos al nivel de CCNP" no se avanza.
Además, más allá de las redes en sí mismas, hay un campo infinito para el estudio, incluso si te concentras solo en una dirección (redes de proveedores, empresas, centros de datos, wifi…)
Por supuesto, muchos de ustedes recordarán Python y otra «automatización de redes», pero esto es solo una condición necesaria, no suficiente. Para que un ingeniero de redes «se integre exitosamente en el equipo», debe ser capaz de comunicarse en el mismo idioma tanto con desarrolladores como con colegas administradores/devops. ¿Qué significa esto?
- Debe no solo trabajar en Linux como usuario, sino también administrarlo, al menos a nivel de un sysadmin junior: instalar el software necesario, reiniciar un servicio caído, escribir una simple unit de systemd.
- Comprender (aunque sea a grandes rasgos) cómo funciona la pila de red en Linux, cómo está estructura la red en hipervisores y contenedores (lxc / docker / kubernetes).
- Por supuesto, debe ser capaz de trabajar con ansible/chef/puppet o cualquier otro sistema de SCM.
- Es necesario mencionar por separado SDN y redes para nubes privadas (por ejemplo, TungstenFabric o OpenvSwitch). Este es otro vasto ámbito de conocimiento.
En resumen, he descrito al típico especialista en forma de T (como se dice ahora). No parece nada nuevo, sin embargo, por experiencia en entrevistas, no todos los ingenieros de redes pueden presumir de tener conocimientos en al menos dos de los temas de la lista anterior. En la práctica, la falta de conocimientos «en áreas relacionadas» dificulta enormemente no solo la comunicación con colegas, sino también la comprensión de los requisitos que el negocio exige a la red, como la infraestructura más básica del proyecto. Sin esta comprensión, se vuelve más difícil defender su punto de vista de manera argumentada y «venderlo» al negocio.
Por otro lado, esa misma costumbre de «entender cómo funciona el sistema» proporciona a los ingenieros de redes una ventaja muy buena sobre diversos «especialistas de perfil amplio», que saben sobre tecnologías a través de artículos en Habr/Medium y chats en Telegram, pero no tienen idea de los principios en los que funciona determinado software. Y como se sabe, conocer ciertos patrones puede reemplazar el conocimiento de muchos hechos.
Conclusiones, o simplemente TL;DR
- El administrador de redes (al igual que el DBA o el ingeniero VoIP) es un especialista de perfil bastante específico (a diferencia de los administradores de sistemas/devops/SRE), cuya necesidad no surge de inmediato (y puede no aparecer durante mucho tiempo, de hecho). Pero cuando surge, es difícil reemplazarlo con experiencia externa (outsourcing o administradores generales "que también monitorean la red"). Lo que es aún más triste es que la demanda por estos especialistas es baja, y, condicionalmente, en una empresa con 800 programadores y 30 devops/administradores, puede haber solo dos ingenieros de red que manejan perfectamente sus responsabilidades. Es decir, el mercado ha sido y sigue siendo bastante, bastante pequeño, y para conseguir un buen salario, aún menos.
- Por otro lado, un buen ingeniero de redes en el mundo moderno debe conocer no solo las redes (y cómo automatizar su configuración), sino también cómo interactúan con los sistemas operativos y el software que funciona sobre esas redes. Sin esto, será extremadamente difícil entender lo que tus colegas están solicitando y comunicar de manera justificada tus deseos/requisitos hacia ellos.
- No hay nube, solo es otro ordenador de alguien más. Es importante entender que el uso de nubes públicas/privadas o servicios de proveedores de hosting "que te hacen todo llave en mano" no elimina el hecho de que tu aplicación aún utiliza la red, y los problemas con esta afectarán el funcionamiento de tu aplicación. Tu elección es dónde estará el centro de competencias que será responsable de la red de tu proyecto.
Fuente: habr.com
