{"id":97373,"date":"2020-10-17T14:42:32","date_gmt":"2020-10-17T12:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/seteviki-ne-nuzhny"},"modified":"2020-10-17T14:42:32","modified_gmt":"2020-10-17T12:42:32","slug":"seteviki-ne-nuzhny","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/seteviki-ne-nuzhny","title":{"rendered":"Los ingenieros de red (no) son necesarios","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

En el momento en que se escribi\u00f3 este art\u00edculo, la b\u00fasqueda en un conocido sitio de trabajo con la frase 'Ingeniero de redes' arrojaba alrededor de trescientas ofertas en toda Rusia. Para comparar, la b\u00fasqueda con la frase 'Administrador de sistemas' devuelve casi 2.5 mil vacantes, mientras que 'Ingeniero DevOps' casi 800.<\/p>\n

\u00bfSignifica esto que los ingenieros de redes ya no son necesarios en la \u00e9poca de las nubes dominantes, Docker, Kubernetes y el ubicuo Wi-Fi p\u00fablico?
\nVamos a averiguarlo (c)<\/p>\n

\"Los
\n<\/a><\/noindex>
\nVamos a conocernos. Me llamo Alexey y soy ingeniero de redes. <\/p>\n

He estado trabajando con redes durante m\u00e1s de 10 a\u00f1os y m\u00e1s de 15 a\u00f1os 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 \u00faltimos a\u00f1os he estado en una fintech 'joven y audaz', donde las nubes, DevOps, Kubernetes y otras palabras aterradoras, que inevitablemente har\u00e1n que yo y mis colegas seamos innecesarios. Alg\u00fan d\u00eda. Quiz\u00e1s.<\/p>\n

disclaimer: 'En nuestra vida no todo es as\u00ed, siempre y en todas partes, y algo, a veces y en lugares' (c) Maxim Dorofeyev.<\/p>\n

Todo lo que se escribe a continuaci\u00f3n puede y debe considerarse como la opini\u00f3n personal del autor, sin pretender ser la \u00faltima palabra en la verdad, y ni siquiera una investigaci\u00f3n completa. Todos los personajes son ficticios, todas las coincidencias son casuales.<\/p><\/blockquote>\n

Bienvenido a mi mundo.<\/p>\n

\u00bfD\u00f3nde se pueden encontrar ingenieros de redes?<\/h3>\n

\n1. Operadores de telecomunicaciones, empresas de servicios y otros integradores<\/b>. Aqu\u00ed todo es simple: la red para ellos es un negocio. Venden conectividad directamente (operadores) o brindan servicios para la creaci\u00f3n\/mantenimiento de redes de sus clientes. <\/p>\n

Aqu\u00ed 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\u00e1s al inicio de tu camino, una carrera en el soporte de alg\u00fan operador no muy grande es, incluso ahora, un punto de partida ideal (en las empresas federales todo est\u00e1 muy guionizado y hay poco espacio para la creatividad). Adem\u00e1s, las historias sobre c\u00f3mo es posible ascender de ingeniero de guardia a gerente de nivel C en unos pocos a\u00f1os tambi\u00e9n son bastante reales, aunque raras, por razones obvias. Siempre hay una necesidad de personal, ya que la rotaci\u00f3n es una realidad. Esto tiene sus pros y sus contras: siempre hay vacantes, pero por otro lado, a menudo, los m\u00e1s activos\/inteligentes se van r\u00e1pidamente, ya sea por ascenso o a otros lugares m\u00e1s<\/p>\n

2. Condicional \u00abempresa\u00bb<\/b>. No importa si su actividad principal est\u00e1 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\u00f3n en las sucursales, etc. Las funciones del ingeniero de redes en tales empresas pueden ser desempe\u00f1adas \u2018a tiempo parcial\u2019 por un administrador de sistemas (si la infraestructura de red es peque\u00f1a, o si un contratista externo se encarga de ella), y el especialista en redes, si es que existe, puede supervisar tambi\u00e9n la telefon\u00eda y el SAN (no es un detalle menor). Los salarios var\u00edan \u2014 dependen en gran medida de la rentabilidad del negocio, el tama\u00f1o de la empresa y la estructura. He trabajado tanto con empresas donde los Cisco se \u2018cargaban a barreales\u2019, como con empresas donde la red se constru\u00eda con excremento, palos y cinta aislante azul, y los servidores no se actualizaban, pr\u00e1cticamente, nunca (no hace falta decir que no se preve\u00edan reservas). Aqu\u00ed hay mucho menos experiencia, y casi con seguridad estar\u00e1 en el \u00e1mbito del duro vendor-lock, o \u2018c\u00f3mo hacer algo de la nada\u2019. Personalmente, all\u00ed me pareci\u00f3 extremadamente aburrido, aunque a muchos les gusta \u2014 todo es bastante pausado y predecible (si hablamos de grandes empresas), \u2018dora-ha-bajato\u2019, etc. No menos de una vez al a\u00f1o, alg\u00fan gran proveedor dice que ha ideado otro sistema mega-s\u00faper-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\u00f3n, los especialistas en redes no desaparecer\u00e1n de all\u00ed. S\u00ed, es posible que en lugar de la consola vuelva a haber una interfaz web (pero ya no de un equipo espec\u00edfico, sino de un gran sistema que gestiona decenas y cientos de esos equipos), pero el conocimiento de \u2018c\u00f3mo est\u00e1 todo organizado por dentro\u2019 seguir\u00e1 siendo necesario.<\/p>\n

3. Empresas de productos<\/b>, cuyo beneficio proviene del desarrollo (y, a menudo, explotaci\u00f3n) de alg\u00fan software o plataforma \u2014 ese mismo producto. Por lo general, son peque\u00f1as y \u00e1giles, a\u00fan est\u00e1n lejos de la escala de las empresas grandes y su burocratizaci\u00f3n. Es aqu\u00ed donde abundan esos devops, kuberos, Docker y otras palabras aterradoras, que sin duda convertir\u00e1n la red y a los ingenieros de redes en un rel\u00edcto innecesario. <\/p>\n

\u00bfQu\u00e9 diferencia a un especialista en redes de un administrador de sistemas?<\/h3>\n

\nEn la comprensi\u00f3n 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. <\/p>\n

En la comprensi\u00f3n de los programadores, es m\u00e1s bien un \u00e1mbito de trabajo. Los administradores de sistemas administran servidores, los expertos en redes administran switches y routers. A veces lo hacen mal, y todo cae. Bueno, en caso de algo extra\u00f1o, los responsables tambi\u00e9n son los de redes. Simplemente porque, j\u00f3dete, eso es todo.<\/p>\n

En realidad, la principal diferencia radica en el enfoque del trabajo. Tal vez, entre los administradores de red es donde m\u00e1s se escucha el enfoque de \u00ab\u00a1Funciona, no lo toques!\u00bb. Generalmente, se puede hacer algo (dentro de un \u00fanico proveedor) de una sola manera, toda la configuraci\u00f3n del dispositivo est\u00e1 a la vista. El costo de un error es alto, a veces demasiado alto (por ejemplo, tendr\u00e1s que recorrer cientos de kil\u00f3metros para reiniciar un router, mientras miles de personas se quedar\u00e1n sin conexi\u00f3n, una situaci\u00f3n bastante habitual para un proveedor de servicios).<\/p>\n

A mi juicio, precisamente por eso, los ingenieros de red est\u00e1n extremadamente motivados a mantener la estabilidad de la red (y los cambios son el principal enemigo de la estabilidad); adem\u00e1s, su conocimiento se adentra m\u00e1s en la profundidad que en la amplitud (no necesitas saber configurar decenas de demonios diferentes, necesitas conocer las tecnolog\u00edas y su implementaci\u00f3n en un fabricante espec\u00edfico de hardware). Por eso, un administrador de sistemas que encontr\u00f3 en Google c\u00f3mo configurar VLAN en un dispositivo Cisco, no es a\u00fan un ingeniero de red. Y es poco probable que pueda mantener de manera efectiva (as\u00ed como solucionar problemas) una red medianamente compleja. <\/p>\n

Pero, \u00bfpor qu\u00e9 necesitas un ingeniero de red si tienes ofrezca una gran cantidad de espacio en disco.<\/a>?<\/b><\/p>\n

Por un costo adicional (y si eres un cliente muy grande y querido, incluso puede ser gratis, \u00abpor amistad\u00bb), los ingenieros del centro de datos configurar\u00e1n tus conmutadores seg\u00fan tus necesidades, y quiz\u00e1s incluso ayudar\u00e1n a establecer la conexi\u00f3n BGP con los proveedores (si tienes tu propia subred direcciones ip<\/a> para anunciar).<\/p>\n

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\u00f3n, y tambi\u00e9n ofrece cierta conectividad \"predeterminada\" a Internet. Con base en esta infraestructura, el centro de datos puede alojar su hardware (colocaci\u00f3n), alquilarle un servidor (servidor dedicado) o proporcionar servicio gestionado (por ejemplo, OpenStack o K8s). Sin embargo, la administraci\u00f3n de la infraestructura de los clientes no suele ser la actividad principal del centro de datos, porque este proceso implica mucho trabajo, es dif\u00edcil de automatizar (y en un centro de datos normal se automatiza todo lo que es posible), y es a\u00fan m\u00e1s dif\u00edcil de estandarizar (cada cliente es \u00fanico) y, en general, puede dar lugar a reclamaciones (\u201cme configuraron el servidor y ahora se cay\u00f3, \u00a1ustedes son los culpables!\u201d). As\u00ed que, si el proveedor de hosting le ayuda en algo, tratar\u00e1 de hacerlo de la manera m\u00e1s sencilla y b\u00e1sica 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\u00f3n har\u00e1 todo mal. Pero no es seguro que \u00e9l haga precisamente lo que usted realmente necesitaba.<\/p>\n

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\u00e1s de lo que deb\u00edan, y esto no termin\u00f3 bien. Tuve que explicar detalladamente que ning\u00fan SLA cubrir\u00e1 las p\u00e9rdidas por inactividad (hay excepciones, pero normalmente son muy, MUY caras para el cliente) y que el proveedor de hosting no est\u00e1 informado sobre lo que sucede en la infraestructura de los clientes (m\u00e1s all\u00e1 de indicadores muy generales). Y adem\u00e1s, el proveedor tampoco hace copias de seguridad en su nombre. La situaci\u00f3n es a\u00fan m\u00e1s complicada si tiene m\u00e1s de un proveedor de hosting. En caso de alg\u00fan problema entre ellos, seguramente no aclarar\u00e1n por usted lo que realmente sali\u00f3 mal.<\/p>\n

Los motivos aqu\u00ed son exactamente los mismos que al elegir entre 'equipo propio de administradores vs. outsourcing'. Si los riesgos est\u00e1n calculados, la calidad satisface y el negocio est\u00e1 de acuerdo, \u00bfpor qu\u00e9 no intentarlo? Por otro lado, la red es una de las capas m\u00e1s b\u00e1sicas de la infraestructura, y dif\u00edcilmente vale la pena dejarla en manos de externos si ya mantienes todo lo dem\u00e1s t\u00fa mismo.<\/p>\n

\u00bfCu\u00e1ndo se necesita un ingeniero de redes?<\/b><\/p>\n

A continuaci\u00f3n, hablaremos espec\u00edficamente sobre las empresas de productos modernas. Con los operadores y las empresas grandes est\u00e1 m\u00e1s o menos claro: no ha habido muchos cambios en los \u00faltimos a\u00f1os y siempre han necesitado ingenieros de redes. Sin embargo, en el caso de las 'j\u00f3venes y audaces', la situaci\u00f3n no es tan sencilla. A menudo, colocan su infraestructura completamente en la nube, as\u00ed que ni siquiera necesitan administradores, excepto los de esas mismas nubes, por supuesto. La infraestructura, por un lado, es bastante simple en su dise\u00f1o, pero, por otro lado, est\u00e1 bien automatizada (ansible\/puppet, terraform, ci\/cd... bueno, ya sabes). Pero incluso aqu\u00ed hay situaciones en las que no se puede prescindir de un ingeniero de redes.<\/p>\n

Ejemplo 1, cl\u00e1sico<\/b><\/p>\n

Supongamos que la empresa comienza con un servidor con una direcci\u00f3n IP p\u00fablica, que se encuentra en un centro de datos. Luego el n\u00famero de servidores aumenta a dos. Despu\u00e9s m\u00e1s... Tarde o temprano, surge la necesidad de una red privada entre los servidores. Porque el tr\u00e1fico 'externo' est\u00e1 limitado tanto en ancho de banda (no m\u00e1s 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\u00e1s caro que una red privada).<\/p>\n

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'. \u00a1Conveniente!<\/p>\n

El n\u00famero de servidores est\u00e1 aumentando, el tr\u00e1fico en la red privada tambi\u00e9n \u2014 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 \u2014 probablemente dejando entre todos tus servidores una red plana. Todo funciona bien, pero en un momento dado comienzan los problemas: peri\u00f3dicamente aumentan las latencias entre los hosts, en los registros hay quejas sobre un n\u00famero excesivo de paquetes ARP por segundo, y un pentester al auditar ha dominado toda tu red local, rompiendo solo un servidor.<\/p>\n

\u00bfQu\u00e9 se debe hacer?<\/i><\/p>\n

Dividir la red en segmentos: VLANs. Configurar en cada VLAN su propia direcci\u00f3n, asignar una puerta de enlace que redirija el tr\u00e1fico entre las redes. En la puerta de enlace, configurar ACL para restringir el acceso entre segmentos, o incluso colocar un cortafuegos separado al lado.<\/p>\n

Ejemplo 1, continuaci\u00f3n<\/b><\/p>\n

Los servidores est\u00e1n conectados a la red local con un cable. Los conmutadores en los racks est\u00e1n conectados entre s\u00ed 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\u00f3n p\u00fablica, que es proporcionada por el proveedor de servicios y est\u00e1 vinculada al rack. Es decir, al mover el servidor, es necesario cambiar la direcci\u00f3n.<\/p>\n

\u00bfQu\u00e9 se debe hacer?<\/i><\/p>\n

Conectar los servidores mediante LAG (Link Aggregation Group) con dos cables a los conmutadores en el rack (tambi\u00e9n hay que reservarlos). Reservar las conexiones entre racks, transformarlas en \"estrella\" (o el ahora popular CLOS), para que la ca\u00edda de un rack no afecte a los dem\u00e1s. Destacar racks \u201ccentrales\u201d, donde se ubicar\u00e1 el n\u00facleo de red y donde se conectar\u00e1n otros racks. Adem\u00e1s, organizar la asignaci\u00f3n de direcciones p\u00fablicas, obtener de tu proveedor (o de RIR, si es posible) un bloque de direcciones que anunciar\u00e1s al mundo por tu cuenta (o a trav\u00e9s del proveedor).<\/p>\n

\u00bfPuede hacer todo esto un \"administrador de sistemas\" com\u00fan, que no tenga conocimientos profundos en redes? No estoy seguro. \u00bfLo har\u00e1 el proveedor de servicios? Puede que lo haga, pero necesitar\u00e1s un pliego de condiciones bastante detallado, que tambi\u00e9n deber\u00e1 ser redactado por alguien. Luego tendr\u00e1s que asegurar que todo se haga correctamente.<\/p>\n

Ejemplo 2. Nube<\/b><\/p>\n

Supongamos que tienes una VPC en alguna nube p\u00fablica. 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\u00f3n a trav\u00e9s de IPSec o un canal dedicado. Por un lado, IPSec es m\u00e1s barato, ya que no necesitas comprar hardware adicional; puedes configurar un t\u00fanel entre tu servidor con direcci\u00f3n p\u00fablica y la nube. Pero, hay retrasos, un rendimiento limitado (ya que el canal necesita ser cifrado), adem\u00e1s de conectividad no garantizada (porque el acceso se realiza a trav\u00e9s de internet convencional). <\/p>\n

\u00bfQu\u00e9 se debe hacer?<\/i><\/p>\n

Establecer la conexi\u00f3n a trav\u00e9s 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\u00e1s cercano a ti (tanto para el operador como para la nube) y, finalmente, configurar todo. \u00bfSe puede hacer esto sin un ingeniero de redes? Seguramente, s\u00ed. Pero c\u00f3mo solucionar problemas sin \u00e9l en caso de fallos ya no es tan claro. <\/p>\n

Tambi\u00e9n 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.<\/p>\n

Podr\u00eda 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\u00fan, m\u00e1s de una) que sepa c\u00f3mo funciona la red, pueda configurar el equipo de red y resolver problemas si surgen. Cr\u00e9eme, tendr\u00e1 mucho en qu\u00e9 ocuparse. <\/p>\n

\u00bfQu\u00e9 debe saber un ingeniero de redes?<\/b><\/p>\n

No es necesario (y a veces, incluso perjudicial) que un ingeniero de redes se dedique solo a la red y a nada m\u00e1s. Aunque no tomemos en cuenta la opci\u00f3n de infraestructura que vive casi completamente en la nube p\u00fablica (que, de hecho, se est\u00e1 volviendo cada vez m\u00e1s popular), y hablemos, por ejemplo, de nubes on-premises o privadas, donde solo con \"conocimientos al nivel de CCNP\" no se avanza. <\/p>\n

Adem\u00e1s de las propias redes, aunque aqu\u00ed hay un amplio campo para estudiar, incluso si solo te concentras en una direcci\u00f3n (redes de proveedores, empresarial, centros de datos, Wifi\u2026)<\/p>\n

Por supuesto, muchos de ustedes recordar\u00e1n Python y otra \u00abautomatizaci\u00f3n de redes\u00bb, pero esto es solo una condici\u00f3n necesaria, no suficiente. Para que un ingeniero de redes \u00abse integre exitosamente en el equipo\u00bb, debe ser capaz de comunicarse en el mismo idioma tanto con desarrolladores como con colegas administradores\/devops. \u00bfQu\u00e9 significa esto?<\/p>\n