¿Qué se necesita para que una empresa de TI tenga éxito en 2019? Los conferenciantes en conferencias y reuniones dicen muchas palabras en voz alta que no siempre son comprensibles para la gente normal. La lucha por el tiempo de implementación, los microservicios, el abandono del monolito, la transformación de DevOps y mucho, mucho más. Si descartamos la belleza verbal y hablamos directamente y en ruso, entonces todo se reduce a una tesis simple: hacer un producto de alta calidad y hacerlo con comodidad para el equipo.
Esto último ha adquirido una importancia crítica. Las empresas finalmente han llegado a la conclusión de que un proceso de desarrollo cómodo aumenta la productividad y, si todo está depurado y funciona como un reloj, también deja cierto margen de maniobra en situaciones críticas. Érase una vez, para esta maniobra, a cierta persona inteligente se le ocurrieron copias de seguridad, pero la industria se está desarrollando y acudimos a los ingenieros de DevOps, personas que convierten el proceso de interacción entre el desarrollo y la infraestructura externa en algo adecuado y No relacionado con el chamanismo.
Toda esta historia "modular" es maravillosa, pero... Dio la casualidad de que algunos de los administradores fueron apodados abruptamente DevOps, y a los propios ingenieros de DevOps se les empezó a exigir que tuvieran al menos habilidades de telepatía y clarividencia.
Antes de hablar de los problemas modernos de proporcionar infraestructura, definamos qué entendemos por este término. En la actualidad, la situación ha evolucionado de tal manera que hemos llegado a la dualidad de este concepto: la infraestructura puede ser condicionalmente externa y condicionalmente interna.
Por infraestructura externa entendemos todo aquello que asegura la funcionalidad del servicio o producto que el equipo está desarrollando. Se trata de servidores de aplicaciones o sitios web, alojamiento y otros servicios que garantizan la funcionalidad del producto.
La infraestructura interna incluye servicios y equipos que utilizan el propio equipo de desarrollo y otros empleados, que suelen ser muchos. Estos son servidores internos de sistemas de almacenamiento de códigos, un administrador de tareas implementado localmente y todo, todo, todo lo que existe dentro de la intranet corporativa.
¿Qué hace un administrador de sistemas en una empresa? Además del trabajo de administrar esta intranet tan corporativa, a menudo soporta la carga de las preocupaciones económicas para garantizar el funcionamiento de los equipos de oficina. El administrador es el mismo tipo que rápidamente arrastrará desde la trastienda una nueva unidad de sistema o una computadora portátil de repuesto lista para usar, entregará un teclado nuevo y se arrastrará a cuatro patas por las oficinas, estirando el cable Ethernet. Un administrador es un propietario y gobernante local no sólo de servidores internos y externos, sino también un ejecutivo de negocios. Sí, algunos administradores sólo pueden trabajar en el plano del sistema, sin hardware. Deberían separarse en una subclase separada de "administradores de sistemas de infraestructura". Y algunos se especializan exclusivamente en el mantenimiento de equipos de oficina; afortunadamente, si la empresa tiene más de cien personas, el trabajo nunca termina. Pero ninguno de ellos es devops.
¿Quiénes son los DevOps? Los Devops son personas que hablan de la interacción del desarrollo de software con la infraestructura externa. Más precisamente, los desarrolladores modernos están involucrados en los procesos de desarrollo e implementación de manera mucho más profunda que los administradores que simplemente cargaban actualizaciones a ftp. Una de las tareas clave de un ingeniero de DevOps ahora es garantizar un proceso de interacción cómodo y estructurado de manera efectiva entre los equipos de desarrollo y la infraestructura del producto. Son estas personas las responsables de implementar los sistemas de implementación y reversión; son estas personas las que quitan parte de la carga a los desarrolladores y se concentran tanto como sea posible en su tarea extremadamente importante. Al mismo tiempo, los devops nunca instalarán un cable nuevo ni emitirán una computadora portátil nueva desde la trastienda (c) KO
¿Cuál es la trampa?
A la pregunta "¿Quién es DevOps?" la mitad de los trabajadores en el campo comienzan a responder algo como “Bueno, en fin, este es el administrador que…” y más adelante en el texto. Sí, había una vez, cuando la profesión de ingeniero DevOps apenas emergía entre los administradores más talentosos en términos de mantenimiento de servicios, las diferencias entre ellos no eran obvias para todos. Pero ahora, cuando las funciones de devops y administrador en el equipo se han vuelto radicalmente diferentes, es inaceptable confundirlos o incluso equipararlos.
Pero ¿qué significa esto para las empresas?
Contratar, se trata de eso.
Abres una vacante para "Administrador del sistema" y los requisitos enumerados allí son "interacción con el desarrollo y los clientes", "sistema de entrega de CI/CD", "mantenimiento de los servidores y equipos de la empresa", "administración de sistemas internos", etc. en; entiendes que el empleador está diciendo tonterías. El problema es que en lugar de "Administrador del sistema", el título de la vacante debería ser "Ingeniero de DevOps", y si se cambia este título, entonces todo encajará.
Sin embargo, ¿qué impresión se tiene al leer semejante vacante? Que la empresa está buscando un operador de múltiples máquinas que implementará un sistema de control y monitoreo de versiones y apretará el tornado con los dientes...
Pero para no aumentar el grado de drogadicción en el mercado laboral, basta con llamar a las vacantes por sus nombres propios y comprender claramente que un ingeniero de DevOps y un administrador de sistemas son dos entidades diferentes. Pero el deseo incontenible de algunos empleadores de presentar la lista de requisitos más amplia posible a un candidato lleva al hecho de que los administradores de sistemas "clásicos" dejan de comprender lo que sucede a su alrededor. ¿Qué, la profesión está mutando y están atrasados?
No no y una vez más no. Los administradores de infraestructura que administrarán los servidores internos de la empresa, u ocuparán puestos de soporte L2/L3 y ayudarán a otros empleados, no se han ido ni van a irse.
¿Pueden estos especialistas convertirse en ingenieros de DevOps? Por supuesto que pueden. De hecho, este es un entorno relacionado que requiere habilidades de administración de sistemas, pero a esto se suma el trabajo con monitoreo, sistemas de entrega y, en general, una estrecha interacción con el equipo de desarrollo y pruebas.
Otro problema de DevOps
De hecho, no todo se limita solo a la contratación y la confusión constante entre administradores y desarrolladores. En algún momento, la empresa se enfrentó al problema de entregar actualizaciones y la interacción del equipo de desarrollo con la infraestructura final.
Quizás fue cuando un tío con ojos brillantes se subió al escenario de alguna conferencia y dijo: “Hacemos esto y lo llamamos DevOps. Estos muchachos resolverán todos sus problemas”, y comenzó a contar lo buena que es la vida en la empresa después de implementar las prácticas de DevOps.
Sin embargo, no basta con contratar a un ingeniero de DevOps para que todo funcione como debería. La empresa debe someterse a una transformación completa de DevOps, es decir, el papel y las capacidades de nuestro DevOps también deben comprenderse claramente por parte del equipo de desarrollo y pruebas de productos. Tenemos una historia “maravillosa” sobre este tema que ilustra plenamente toda la brutalidad que está ocurriendo en algunos lugares.
Situación. Se requiere DevOps para implementar un sistema de reversión de versiones sin profundizar realmente en cómo funcionará. Supongamos que dentro del sistema Usuarios hay campos separados para nombre, apellido y contraseña. Sale una nueva versión del producto, pero para los desarrolladores una "reversión" es solo una varita mágica que arreglará todo y ni siquiera saben cómo funciona. Entonces, por ejemplo, en el siguiente parche los desarrolladores combinaron los campos de nombre y apellido, lo implementaron en producción, pero la versión es lenta por alguna razón. ¿Lo que está sucediendo? La gerencia llega a Devops y le dice "¡Apriete el interruptor!", Es decir, le pide que vuelva a la versión anterior. ¿Qué hace DevOps? Se revierte a la versión anterior, pero como los desarrolladores no querían descubrir cómo se hacía esta reversión, nadie le dijo al equipo de desarrollo que la base de datos también debía revertirse. Como resultado, todo falla para nosotros y, en lugar de un sitio web lento, los usuarios ven un error "500", porque la versión anterior no funciona con los campos de la nueva base de datos. Devops no sabe sobre esto. Los desarrolladores guardan silencio. La gerencia comienza a perder los nervios y el dinero y recuerda las copias de seguridad, ofreciéndose a revertirlas para que "al menos algo funcione". Como resultado, los usuarios pierden todos sus datos durante un período de tiempo.
Los locos, por supuesto, van a parar a los devops, que “no crearon un sistema de reversión adecuado”, y a nadie le importa que los alces en esta historia sean desarrolladores.
La conclusión es simple: sin un enfoque normal de DevOps como tal, sirve de poco.
Lo principal que hay que recordar: un ingeniero de DevOps no es un mago y, sin una comunicación de calidad y una interacción bidireccional con el desarrollo, no podrá hacer frente a sus tareas. Los desarrolladores no pueden quedarse solos con sus “problemas” ni recibir la orden de “no te metas con los desarrolladores, su trabajo es codificar” y luego esperar que en un momento crítico todo funcione como debería. Así no es cómo funciona.
Básicamente, DevOps es una competencia en la frontera entre gestión y tecnología. Además, no es nada obvio que deba haber más tecnología que gestión en este cóctel. Si realmente desea crear procesos de desarrollo más rápidos y eficientes, debe confiar en su equipo de Devops. Conoce las herramientas adecuadas, ha implementado proyectos similares y sabe cómo hacerlo. Ayúdalo, escucha sus consejos, no intentes aislarlo en algún tipo de unidad autónoma. Si los administradores pueden trabajar solos, entonces los devops en este caso son inútiles; no podrán ayudarlo a mejorar si usted mismo no quiere aceptar esta ayuda.
Y una última cosa: dejar de ofender a los administradores de infraestructuras. Tienen su propio frente de trabajo extremadamente importante. Sí, un administrador puede convertirse en ingeniero de DevOps, pero esto debe suceder a petición de la propia persona y no bajo presión. Y no hay nada de malo en el hecho de que un administrador de sistemas quiera seguir siendo administrador de sistemas; esta es su profesión independiente y su derecho. Si quieres emprender una transformación profesional, nunca debes olvidar que tendrás que desarrollar no sólo habilidades tecnológicas, sino también de gestión. Lo más probable es que dependa de usted, como líder, reunir a todas estas personas y enseñarles a comunicarse en el mismo idioma.
Fuente: habr.com