¿Qué se necesita para el éxito de una empresa de TI en 2019? Los ponentes en conferencias y encuentros hablan muchas palabras impactantes y no siempre comprensibles para la gente común. La lucha por el tiempo de despliegue, microservicios, el abandono del monolito, la transformación DevOps y mucho más. Si dejamos de lado la palabrería y hablamos claro, todo se reduce a una simple tesis: hagan un producto de calidad, y háganlo de manera cómoda para el equipo.
Esto se ha vuelto críticamente importante. Finalmente, el negocio ha llegado a la conclusión de que un proceso de desarrollo cómodo aumenta la productividad, y si todo está ajustado y funciona a la perfección, también proporciona cierto espacio de maniobra en situaciones críticas. En su momento, para ese espacio de maniobra, un pensador inteligente inventó las copias de seguridad, pero la industria está evolucionando y hemos llegado a los ingenieros DevOps: personas que transforman el proceso de interacción entre el desarrollo y la infraestructura externa en algo adecuado y desvinculado del chamanismo.
Toda esta historia de "por módulos" es hermosa, pero... Resulta que parte de los administradores fueron repentinamente llamados DevOps, y de los propios ingenieros DevOps comenzaron a exigir, al menos, habilidades de telepatía y clarividencia.
Antes de hablar sobre los problemas modernos en la provisión de infraestructura, aclaremos qué entendemos por este término. En la actualidad, la situación ha llegado a tal punto que hemos llegado a una dualidad en este concepto: la infraestructura puede ser condicionalmente externa y condicionalmente interna.
Por infraestructura externa se debe entender todo lo que asegura el funcionamiento del servicio o producto en el que está trabajando el equipo. Esto incluye los servidores de aplicación o del sitio, hosting y otros servicios que garantizan el funcionamiento del producto.
La infraestructura interna incluye los servicios y el equipo que utiliza el propio equipo de desarrollo y otros empleados, que suelen ser numerosos. Esto comprende los servidores internos de los sistemas de almacenamiento de código, un gestor de tareas desplegado localmente y todo lo que existe dentro del intranet corporativo.
¿Qué hace un administrador de sistemas en la empresa? Además de administrar la intranet corporativa, a menudo tiene la carga de asegurarse de que el equipo de oficina esté funcionando. El administrador es la persona que rápidamente podría traer un nuevo sistema o un portátil de repuesto listo para usar, proporcionar un teclado nuevo y arrastrarse por las oficinas tendiendo un cable Ethernet. El administrador es el propietario local y el maestro no solo de los recursos internos y externos servidores, sino también de los asuntos. Sí, algunos administradores pueden trabajar solo en la parte del sistema, sin el hardware. Se les puede considerar parte de una subclase denominada "administradores de sistemas de infraestructura". Y hay quienes se especializan únicamente en el mantenimiento del equipo de oficina; en efecto, si la empresa cuenta con más de cien personas, el trabajo nunca se termina. Pero ni unos ni otros son DevOps.
¿Y quiénes son los DevOps? Los DevOps son las personas que se ocupan de la interacción entre el desarrollo de software y la infraestructura externa. Más precisamente, los DevOps modernos están involucrados en los procesos de desarrollo y despliegue de manera mucho más profunda de lo que alguna vez lo estuvieron los administradores, que solo subían actualizaciones por ftp. Una de las tareas clave de un ingeniero DevOps hoy en día es garantizar un proceso cómodo y eficaz de interacción entre los equipos de desarrollo y la infraestructura del producto. Estas son las personas responsables de implementar sistemas de retroceso y despliegue, y son las que aligeran parte de la carga de los desarrolladores, concentrándose al máximo en su tarea esencial. Sin embargo, un DevOps nunca se encargará de tendrer un nuevo cable o proporcionar un portátil de repuesto (c) KO
¿Cuál es el truco?
La respuesta a la pregunta "¿Y quién es un DevOps?" es que la mitad de los trabajadores del sector empiezan a responder algo como "Bueno, es un administrador que..." y continúan con su explicación. Sí, hace tiempo, cuando la profesión de ingeniero DevOps apenas comenzaba a surgir de los administradores más talentosos en el mantenimiento de servicios, las diferencias entre ellos no eran del todo obvias. Pero ahora, cuando las funciones de un DevOps y un administrador en un equipo se han diferenciado radicalmente, confundirlos o incluso poner entre ellos un signo de igualdad es inaceptable.
Pero, ¿en qué se traduce esto para el negocio?
La contratación, todo se centra en ello.
Abres una vacante de "Administrador de sistemas", y ahí se enumeran requisitos como "interactuar con desarrollo y clientes", "sistema de entrega CI/CD", "mantenimiento de servidores y equipos de la empresa", "administración de sistemas internos" y así sucesivamente; entiendes que el empleador está diciendo alguna tontería. La trampa está en que, en lugar de "Administrador de sistemas" en el título de la vacante debería estar "Ingeniero DevOps", y si cambias ese título, todo toma sentido.
Sin embargo, ¿qué impresión se crea al leer tal vacante? ¿Que la empresa busca a un multitarea que despliegue tanto el sistema de control de versiones como el de monitoreo, e incluso que monte una presentación con los dientes?
Y es que, para no elevar el nivel de locura en el mercado laboral, basta con nombrar las vacantes correctamente y tener clara la diferencia entre un ingeniero DevOps y un administrador de sistemas; son dos entidades distintas. Lo que sucede es que el deseo incesante de algunos empleadores de exigir a los candidatos la mayor cantidad posible de requisitos lleva a que los "administradores de sistemas clásicos" dejen de entender lo que sucede a su alrededor. ¿Acaso la profesión está mutando y se han quedado atrás?
No, no y otra vez no. Los administradores de infraestructura, que manejarán los servidores internos de la empresa, o que ocuparán posiciones de soporte L2/L3 y ayudarán a otros empleados, no han desaparecido y no tienen intención de irse.
¿Pueden estos especialistas convertirse en ingenieros DevOps? Por supuesto que sí. De hecho, es un entorno afín que requiere habilidades de administración de sistemas, pero además, implica trabajar con monitoreo, sistemas de entrega y, en general, una estrecha colaboración con el equipo de desarrollo y pruebas.
Otro problema de DevOps
En realidad, no se limita solo a la contratación y la confusión constante entre administradores y devops. En algún momento, el negocio se enfrentó al problema de la entrega de actualizaciones y a la interacción entre el equipo de desarrollo y la infraestructura final.
Quizás fue entonces cuando un tipo en el escenario de alguna conferencia subió con ojos brillantes y dijo: “Y nosotros hacemos esto y lo llamamos DevOps. Estos chicos solucionarán todos sus problemas” — y comenzó a relatar lo bien que se vive en la empresa tras la implementación de prácticas DevOps.
Sin embargo, no basta con contratar a un ingeniero DevOps para que todo funcione "como debe ser." La empresa debe pasar por una transformación DevOps integral, es decir, el papel y las capacidades de nuestro devops deben ser claramente entendidos también por el equipo de desarrollo y pruebas del producto. Sobre este tema tenemos una "hermosa" historia que ilustra completamente toda la locura que a veces sucede.
Situación. Se le pide a un DevOps que implemente un sistema de retroceso de versiones sin profundizar en cómo funcionará. Supongamos que dentro del sistema de Usuarios hay campos separados para nombre, apellido y contraseña. Sale una nueva versión del producto, pero para los desarrolladores, el "retroceso" es simplemente una varita mágica que lo arregla todo, y ni siquiera tienen idea de cómo funciona. Así que, por ejemplo, los desarrolladores en un nuevo parche unieron los campos de nombre y apellido, lo lanzaron en producción y la versión tiene problemas de rendimiento por alguna razón. ¿Qué sucede? La dirección se acerca al DevOps y le dice "¡Acciona el interruptor!", es decir, le piden que retroceda a la versión anterior. ¿Qué hace el DevOps? Retrocede a la versión anterior, pero como los desarrolladores no se tomaron la molestia de entender cómo se hace este retroceso, nadie le dijo al DevOps que también hay que retroceder la base de datos. Al final, todo se cae, y los usuarios en lugar de un sitio lento ven el error "500", porque la versión antigua no funciona con los campos de la nueva base. El DevOps no está al tanto de esto. Los desarrolladores permanecen en silencio. La dirección comienza a perder los nervios y el dinero, y recuerda las copias de seguridad, sugiriendo retroceder con ellas para que "algo funcione". Como resultado, los usuarios pierden todos sus datos de un período de tiempo.
Por supuesto, el DevOps que "no implementó el sistema de retroceso correcto" recibe toda la culpa, mientras que a los desarrolladores, que son los verdaderos responsables en esta historia, no les importa a nadie.
La conclusión es sencilla: sin un enfoque adecuado hacia DevOps como tal, no se obtiene mucho beneficio.
Lo principal que hay que recordar: un ingeniero de DevOps no es un mago, y sin comunicaciones de calidad y una interacción bidireccional con el desarrollo, no podrá cumplir con sus tareas. No se puede dejar a los DevOps solos con sus "problemas" o decirles "no te involucres con los desarrolladores, es su trabajo codificar", y luego esperar que todo funcione correctamente en un momento crítico. Así no funciona.
En esencia, DevOps son competencias que se sitúan en la frontera entre la gestión y la tecnología. Además, no es nada obvio que en este cóctel de tecnologías deba haber más que gestión. Si realmente quieres construir procesos de desarrollo más rápidos y eficientes, debes confiar en tu DevOps. Él sabe qué herramientas son necesarias, ha implementado proyectos similares y sabe cómo hacerlo. Ayúdale, escucha sus consejos, no intentes aislarlo en una unidad autónoma. Si los administradores pueden trabajar por su cuenta, en ese caso los DevOps son inútiles; no podrán ayudarte a mejorar si tú mismo no deseas aceptar esa ayuda.
Y por último: basta de hacer sentir mal a los administradores de infraestructura. Ellos tienen su propio y extremadamente importante frente de trabajo. Sí, un administrador puede convertirse en ingeniero DevOps, pero esto debe ocurrir por voluntad propia, no por obligación. Y no hay nada de malo en que un administrador de sistemas quiera seguir siendo administrador de sistemas; esa es su profesión y su derecho. Sin embargo, si hay un deseo de pasar por una transformación profesional, nunca hay que olvidar que se deberá desarrollar no solo habilidades técnicas, sino también habilidades de gestión. Lo más probable es que seas tú como líder quien tendrá que reunir a todas estas personas y enseñarles a comunicarse en un mismo idioma.
Fuente: habr.com
