Al momento de escribir este artículo, una búsqueda en un sitio de trabajo popular de la frase "Ingeniero de redes" arrojó alrededor de trescientas vacantes en toda Rusia. A modo de comparación, una búsqueda de la frase "administrador del sistema" arroja casi 2.5 mil vacantes y "ingeniero de DevOps", casi 800.
¿Significa esto que los networkers ya no son necesarios en tiempos de nubes victoriosas, Docker, Kubernetes y Wi-Fi público ubicuo?
Vamos a resolverlo (c)
Vamos a familiaricémonos. Mi nombre es Alexey y soy networker.
He estado involucrado en redes por más de 10 años y he estado trabajando con varios sistemas *nix por más de 15 años (tuve la oportunidad de jugar tanto con Linux como con FreeBSD). Trabajé en operadores de telecomunicaciones, grandes empresas que se consideran “empresariales”, y recientemente he estado trabajando en fintech “joven y atrevida”, donde nubes, devops, kubernetes y otras palabras aterradoras que definitivamente nos harán innecesarios a mí y a mis colegas. . Algún día. Tal vez.
Descargo de responsabilidad: “En nuestra vida, no todo está siempre y en todas partes, sino algo, a veces en algunos lugares” (c) Maxim Dorofeev.
Todo lo escrito a continuación puede y debe considerarse la opinión personal del autor, que no pretende ser la verdad última, ni siquiera un estudio completo. Todos los personajes son ficticios, todas las coincidencias son aleatorias.
Bienvenido a mi mundo.
¿Dónde puedes conocer a los networkers?
1. Operadores de telecomunicaciones, empresas de servicios y otros integradores. Aquí todo es sencillo: la red para ellos es un negocio. Venden directamente conectividad (operadores) o brindan servicios para lanzar/mantener las redes de sus clientes.
Aquí hay mucha experiencia, pero no mucho dinero (a menos que sea director o gerente de ventas exitoso). Y, sin embargo, si le gustan las redes y está apenas al comienzo de su viaje, una carrera en apoyo de algún operador no muy grande será, incluso ahora, un punto de partida ideal (en las federales todo está muy escrito, y hay hay poco espacio para la creatividad). Bueno, las historias sobre cómo puedes pasar de ser un ingeniero de servicio en unos pocos años a un gerente de nivel C también son bastante reales, aunque raras, por razones obvias. Siempre hay necesidad de personal, porque se produce rotación. Esto es bueno y malo al mismo tiempo; por otro lado, siempre hay vacantes; a menudo, los más activos/inteligentes se van rápidamente para un ascenso o para otros lugares más "cálidos".
2. “Empresa” condicional. No importa si su actividad principal está relacionada con TI o no. Lo principal es que cuenta con su propio departamento de TI, que vela por el funcionamiento de los sistemas internos de la empresa, incluida la red en oficinas, canales de comunicación con sucursales, etc. Las funciones de un ingeniero de redes en dichas empresas pueden ser realizadas "a tiempo parcial" por un administrador del sistema (si la infraestructura de la red es pequeña o está a cargo de un contratista externo), y un especialista en redes, si lo hay, puede al mismo tiempo Al mismo tiempo cuida la telefonía y SAN (no sirve). Pagan de forma diferente: depende en gran medida de la rentabilidad del negocio, del tamaño de la empresa y de la estructura. Trabajé con empresas donde los sistemas Cisco se "cargaban en barriles" regularmente, y con empresas donde la red se construía a partir de heces, palos y cinta azul, y los servidores nunca se actualizaban (no hace falta decir que tampoco se proporcionaban reservas). Hay mucha menos experiencia aquí, y es casi seguro que será en el área del estricto bloqueo de proveedores, o "cómo hacer algo a partir de la nada". Personalmente, lo encontré tremendamente aburrido, aunque a mucha gente le gusta: todo es bastante mesurado y predecible (si hablamos de grandes empresas), "dorakha-bahato", etc. Al menos una vez al año, algunos proveedores importantes dicen que han creado otro sistema mega-súper-duper que ahora automatizará todo y todos los administradores de sistemas y usuarios de redes pueden dispersarse, dejando que un par presione botones en una hermosa interfaz. La realidad es que, incluso si ignoramos el costo de la solución, los usuarios de redes no avanzarán más allá de ese punto. Sí, tal vez en lugar de la consola vuelva a haber una interfaz web (pero no una pieza de hardware específica, sino un sistema grande que administra decenas y cientos de esas piezas de hardware), pero el conocimiento de "cómo funciona todo por dentro" aún será necesario. ser necesario.
3. Empresas de productos, cuyo beneficio proviene del desarrollo (y, a menudo, de la operación) de algún software o plataforma, ese mismo producto. Suelen ser pequeñas y ágiles, todavía están lejos de la escala de las empresas y de su burocratización. Es aquí donde se encuentran en masa esos mismos devops, cubers, dockers y otras palabras terribles, lo que sin duda convertirá a los ingenieros de redes y de redes en un rudimento innecesario.
¿En qué se diferencia un networker de un administrador de sistemas?
En opinión de personas que no son de TI, nada. Ambos miran la pantalla negra y escriben algunos hechizos, a veces maldiciendo en voz baja.
Según lo entienden los programadores, quizás por área temática. Los administradores de sistemas administran servidores, los usuarios de redes administran conmutadores y enrutadores. A veces la administración es mala y todo se desmorona para todos. Bueno, en caso de algo extraño, los networkers también tienen la culpa. Sólo porque, vete a la mierda, es por eso.
De hecho, la principal diferencia es el enfoque del trabajo. Quizás sea entre los networkers donde hay más partidarios del enfoque “¡Si funciona, no lo toques!”. Por regla general, algo se puede hacer (dentro de un mismo proveedor) de una sola manera: toda la configuración de la caja está ahí, en la palma de la mano. El costo de un error es alto y, a veces, muy alto (por ejemplo, tendrá que viajar varios cientos de kilómetros para reiniciar el enrutador y, en ese momento, varios miles de personas se quedarán sin comunicación, una situación bastante común para un operador de telecomunicaciones) .
En mi opinión, esta es la razón por la que los ingenieros de redes, por un lado, están extremadamente motivados por la estabilidad de la red (y el cambio es el principal enemigo de la estabilidad) y, por otro, su conocimiento es más profundo que amplio (no es necesario). necesita poder configurar docenas de demonios diferentes, necesita conocer las tecnologías y su implementación de un fabricante de equipo específico). Es por eso que un administrador de sistemas que buscó en Google cómo registrar una VLAN en un sistema Cisco aún no es un experto en redes. Y es poco probable que pueda brindar soporte efectivo (y solucionar problemas) de una red más o menos compleja.
Pero, ¿por qué necesitas un networker si tienes un hosting?
Por dinero adicional (y si es un cliente muy grande y querido, tal vez incluso gratis, "como amigo"), los ingenieros del centro de datos configurarán sus conmutadores para satisfacer sus necesidades y tal vez incluso lo ayuden a establecer una interfaz BGP con los proveedores. (si tiene su propia subred de direcciones IP para el anuncio).
El principal problema es que el centro de datos no es su departamento de TI, es una empresa independiente cuyo objetivo es obtener beneficios. Incluso a expensas de usted como cliente. El centro de datos proporciona racks, les proporciona electricidad y frío, y también proporciona cierta conectividad "predeterminada" a Internet. Sobre la base de esta infraestructura, el centro de datos puede alojar su equipo (colocación), alquilarle un servidor (servidor dedicado) o proporcionarle un servicio administrado (por ejemplo, OpenStack o K8). Pero el negocio de un centro de datos (normalmente) no es la administración de la infraestructura del cliente, porque este proceso requiere bastante mano de obra, está poco automatizado (y en un centro de datos normal todo lo que es posible está automatizado), unificado y peor aún (cada cliente es individual) y generalmente está plagado de quejas (“me dices que el servidor estaba configurado, pero ahora ha fallado, ¡¡¡es todo culpa tuya!!!111”). Por lo tanto, si el proveedor de alojamiento te ayuda en algo, intentará hacerlo lo más sencillo y cómodo posible. Porque hacerlo difícil no es rentable, al menos desde el punto de vista de los costes laborales de los ingenieros de este mismo hosting (pero las situaciones son diferentes, ver aviso legal). Esto no significa que el proveedor de alojamiento necesariamente hará todo mal. Pero no es en absoluto un hecho que hará exactamente lo que usted realmente necesita.
Parecería que la cosa es bastante obvia, pero varias veces en mi práctica me he encontrado con el hecho de que las empresas comenzaron a confiar en su proveedor de hosting un poco más de lo debido, y esto no condujo a nada bueno. Tuve que explicar larga y detalladamente que ni un solo SLA cubriría las pérdidas por tiempo de inactividad (hay excepciones, pero normalmente es muy, MUY caro para el cliente) y que el proveedor de alojamiento no está en absoluto al tanto de lo que está sucediendo en la infraestructura de los clientes (salvo indicadores muy generales). Y el proveedor de alojamiento tampoco hace copias de seguridad por usted. La situación es aún peor si tienes más de un proveedor de alojamiento. En caso de cualquier problema entre ellos, seguramente no descubrirán qué salió mal.
En realidad, los motivos aquí son exactamente los mismos que cuando se elige "equipo de administración interno versus subcontratación". Si se calculan los riesgos, la calidad es satisfactoria y a la empresa no le importa, ¿por qué no intentarlo? Por otro lado, la red es una de las capas más básicas de infraestructura, y no vale la pena dejarla en manos de gente externa si usted mismo ya soporta todo lo demás.
¿En qué casos se necesita un networker?
A continuación hablaremos específicamente de las empresas alimentarias modernas. Con los operadores y las empresas, todo está claro, más o menos: poco ha cambiado allí en los últimos años, antes se necesitaban operadores de red y se necesitan ahora. Pero con esos mismos “jóvenes y atrevidos” las cosas no están tan claras. A menudo colocan toda su infraestructura en las nubes, por lo que ni siquiera necesitan administradores, excepto los administradores de esas mismas nubes, por supuesto. La infraestructura, por un lado, es bastante simple en su diseño, por otro lado, está bien automatizada (ansible/puppet, terraform, ci/cd... bueno, ya sabes). Pero también en este caso hay situaciones en las que no se puede prescindir de un ingeniero de redes.
Ejemplo 1, clásico
Supongamos que una empresa comienza con un servidor con una dirección IP pública, que está ubicado en un centro de datos. Luego hay dos servidores. Luego más... Tarde o temprano, será necesaria una red privada entre servidores. Porque el tráfico "externo" está limitado tanto por el ancho de banda (no más de 100 Mbit/s, por ejemplo) como por el volumen de descargas/subidas por mes (diferentes proveedores de hosting tienen tarifas diferentes, pero el ancho de banda hacia el mundo exterior suele ser mucho más caro que un red privada).
El proveedor de alojamiento agrega tarjetas de red adicionales a los servidores y las incluye en sus conmutadores en una VLAN separada. Aparece un área local "plana" entre los servidores. ¡Cómodo!
La cantidad de servidores está creciendo y el tráfico en la red privada también está creciendo: copias de seguridad, replicaciones, etc. El proveedor de alojamiento ofrece trasladarlo a conmutadores separados para que usted no interfiera con otros clientes y ellos no interfieran con usted. El proveedor de alojamiento instala algunos conmutadores y de alguna manera los configura, lo más probable es que deje una red plana entre todos sus servidores. Todo funciona bien, pero en un momento determinado comienzan los problemas: los retrasos entre hosts aumentan periódicamente, los registros se quejan de demasiados paquetes arp por segundo y durante una auditoría el pentester arruinó toda su red local, rompiendo solo un servidor.
Qué tengo que hacer?
Divida la red en segmentos: VLAN. Configure su propio direccionamiento en cada VLAN, seleccione una puerta de enlace que transfiera el tráfico entre redes. Configure acl en la puerta de enlace para limitar el acceso entre segmentos, o incluso instale un firewall separado cerca.
Ejemplo 1, continuación
Los servidores están conectados a la LAN con un solo cable. Los interruptores de los bastidores están conectados de alguna manera entre sí, pero si hay un accidente en un bastidor, tres más adyacentes se caen. Existen esquemas, pero existen dudas sobre su relevancia. Cada servidor tiene su propia dirección pública, que es emitida por el proveedor de alojamiento y está vinculada al bastidor. Aquellos. Al mover un servidor, se debe cambiar la dirección.
Qué tengo que hacer?
Conecte los servidores mediante LAG (Link Aggregation Group) con dos cables a los conmutadores del rack (también deben ser redundantes). Reserva las conexiones entre racks y conviértelas en “estrella” (o el ahora de moda CLOS) para que la pérdida de un rack no afecte a los demás. Seleccione los racks "centrales" en los que se ubicará el núcleo de la red y donde se conectarán otros racks. Al mismo tiempo, ordene el direccionamiento público, tome del proveedor de alojamiento (o de RIR, si es posible) una subred que usted mismo (o a través del proveedor de alojamiento) anuncia al mundo.
¿Puede todo esto hacerlo un administrador de sistemas “ordinario” que no tenga un conocimiento profundo de las redes? No estoy seguro. ¿El proveedor de alojamiento hará esto? Tal vez sea así, pero necesitarás una especificación técnica bastante detallada, que alguien también deberá redactar. y luego comprobar que todo se hace correctamente.
Ejemplo 2: nube
Digamos que tiene una VPC en alguna nube pública. Para obtener acceso desde la oficina o parte local de la infraestructura a la red local dentro de la VPC, debe configurar una conexión a través de IPSec o un canal dedicado. Por un lado, IPSec es más barato porque no es necesario comprar hardware adicional; puede configurar un túnel entre su servidor con una dirección pública y la nube. Pero hay retrasos, rendimiento limitado (ya que el canal debe estar cifrado) y conectividad no garantizada (ya que el acceso se realiza a través de Internet normal).
Qué tengo que hacer?
Establezca una conexión a través de un canal dedicado (por ejemplo, AWS lo llama Direct Connect). Para ello, busca un operador asociado que te conecte, decide el punto de conexión más cercano a ti (tanto tú con el operador como el operador con la nube) y, finalmente, configura todo. ¿Es posible hacer todo esto sin un ingeniero de redes? Seguramente sí. Pero ya no está tan claro cómo solucionar problemas sin él en caso de problemas.
También puede haber problemas de disponibilidad entre nubes (si tienes una multinube) o problemas de retrasos entre distintas regiones, etc. Por supuesto, ahora han aparecido muchas herramientas que aumentan la transparencia de lo que sucede en la nube (los mismos Mil Ojos), pero todas estas son las herramientas de un ingeniero de redes, y no lo reemplazan.
Podría esbozar una docena más de ejemplos de mi práctica, pero creo que está claro que el equipo, a partir de un cierto nivel de desarrollo de infraestructura, debe tener una persona (preferiblemente más de una) que sepa cómo funciona la red y pueda configurarla. equipos de red y solucionar problemas si surgen. Créeme, él tendrá algo que hacer.
¿Qué debe saber un networker?
No es en absoluto necesario (e incluso, a veces, perjudicial) que un ingeniero de redes se ocupe únicamente de la red y nada más. Incluso si no consideramos la opción con una infraestructura que reside casi por completo en la nube pública (y, digan lo que digan, se está volviendo cada vez más popular), y tomamos, por ejemplo, nubes locales o privadas, donde sobre “Solo conocimiento a nivel CCNP” "No te irás.
Además, de hecho, de las redes, aunque el campo de estudio es simplemente infinito, incluso si nos concentramos solo en un área (redes de proveedores, empresas, centros de datos, Wi-Fi...)
Por supuesto, muchos de ustedes ahora recordarán Python y otras “automatizaciones de red”, pero esto es sólo una condición necesaria, pero no suficiente. Para que un ingeniero de redes “se una al equipo con éxito”, debe poder hablar el mismo idioma tanto con los desarrolladores como con sus compañeros administradores/desarrolladores. ¿Qué significa?
- Ser capaz no solo de trabajar en Linux como usuario, sino también de administrarlo, al menos en el nivel sysadmin-jun: instalar el software necesario, reiniciar un servicio fallido, escribir una unidad systemd simple.
- Comprender (al menos en términos generales) cómo funciona la pila de red en Linux, cómo funciona la red en hipervisores y contenedores (lxc/docker/kubernetes).
- Por supuesto, poder trabajar con ansible/chef/puppet u otro sistema SCM.
- Se debe escribir una línea separada sobre SDN y redes para nubes privadas (por ejemplo, TungstenFabric u OpenvSwitch). Esta es otra enorme capa de conocimiento.
En resumen, describí a un típico especialista en forma de T (como está de moda decirlo ahora). No parece nada nuevo, pero según la experiencia en entrevistas, no todos los ingenieros de redes pueden presumir de conocer al menos dos temas de la lista anterior. En la práctica, la falta de conocimiento "en campos relacionados" hace que sea muy difícil no sólo comunicarse con colegas, sino también comprender los requisitos que las empresas imponen a la red, como infraestructura de nivel más bajo del proyecto. Y sin esta comprensión, resulta más difícil defender su punto de vista y “venderlo” a las empresas.
Por otro lado, el mismo hábito de "comprender cómo funciona el sistema" da a los usuarios de redes una muy buena ventaja sobre varios "generalistas" que conocen las tecnologías por artículos en Habré/medium y chats en Telegram, pero no tienen la menor idea de cómo hacerlo. ¿Cuáles son los principios en los que funciona este o aquel software? Y el conocimiento de ciertos patrones, como se sabe, reemplaza con éxito el conocimiento de muchos hechos.
Conclusiones, o simplemente TL;DR
- Un administrador de red (como un DBA o un ingeniero de VoIP) es un especialista con un perfil bastante limitado (a diferencia de los administradores de sistemas/desarrolladores/SRE), cuya necesidad no surge de inmediato (y puede que no surja durante mucho tiempo, de hecho). . Pero si surge, es poco probable que sea reemplazado por expertos externos (administradores subcontratados o administradores ordinarios de propósito general, “que también se ocupan de la red”). Lo que es un poco más triste es que la necesidad de tales especialistas es pequeña y, condicionalmente, en una empresa con 800 programadores y 30 devops/administradores, puede que solo haya dos networkers que hagan un excelente trabajo con sus responsabilidades. Aquellos. el mercado era y es muy, muy pequeño, y con un buen salario, incluso menos.
- Por otro lado, un buen networker en el mundo moderno debe conocer no sólo las redes en sí (y cómo automatizar su configuración), sino también cómo interactúan con ellas los sistemas operativos y el software que se ejecutan sobre estas redes. Sin esto, será extremadamente difícil entender lo que sus colegas le piden y transmitirles (razonablemente) sus deseos/requisitos.
- No hay ninguna nube, es sólo la computadora de otra persona. Debe comprender que el uso de nubes públicas/privadas o los servicios de un proveedor de alojamiento "que hace todo por usted llave en mano" no cambia el hecho de que su aplicación todavía usa la red, y los problemas con ella afectarán el funcionamiento de su aplicación. Tu elección es dónde se ubicará el centro de competencia, que será responsable de la red de tu proyecto.
Fuente: habr.com