Últimamente, estos anuncios han inundado Internet. A pesar de un buen salario, no se puede evitar sentir inquietud ante la locura que se escribe en su interior. Primero se supone que se puede combinar 'DevOps' e 'ingeniero' en una sola palabra, y después viene una lista aleatoria de requisitos, muchos de los cuales claramente están copiados de una oferta de trabajo para un administrador de sistemas.
En este post, quiero hablar un poco sobre cómo hemos llegado a esta situación, qué es realmente DevOps y qué debemos hacer con ello.
Se puede criticar de muchas maneras estas ofertas de trabajo, pero el hecho es que hay muchas, y así está estructurado el mercado en este momento. Organizamos una conferencia de DevOps y declaramos abiertamente: « — no es para ingenieros de DevOps». Esto puede parecer extraño y absurdo para muchos: ¿por qué personas que organizan un evento puramente comercial van en contra del mercado? Ahora lo explicaremos.
Sobre la cultura y procesos
Empecemos por el hecho de que DevOps no es una disciplina de ingeniería. Todo comenzó con que la división de roles históricamente existente no funciona para la calidad de los productos. Cuando los programadores solo programan, pero no quieren saber nada sobre las pruebas, el software está lleno de errores. Cuando a los administradores no les importa cómo y por qué se escribió el software, el soporte se convierte en un infierno.
Por ejemplo, la descripción de la diferencia entre el enfoque de administrador de sistemas y el enfoque de SRE hacia la gestión de servicios Se han realizado interesantes investigaciones en el marco del — es evidente que los mejores desarrolladores logran desplegar nuevas modificaciones en producción más rápido que una vez por hora. Ellos tampoco prueban más del 10% a mano (se puede ver en ). ¿Cómo lo logran? 'Excel o muere' – dice uno de los encabezados del informe. Para un análisis detallado de esta estadística en términos de pruebas, se puede consultar la keynote de Baruch Sadogursky en otra de nuestras conferencias, Heisenbug.
«Cuando en los compañeros no hay acuerdo,
Su asunto no prosperará,
Y de ello no saldrá nada, solo sufrimiento.
Una vez, un Cisne, un Cangrejo y una Sombra…»
¿Qué opinas, cuántos desarrolladores web realmente comprenden en qué condiciones funcionan sus aplicaciones en producción? ¿Cuántos de ellos se acercarán a los administradores y tratarán de entender qué sucederá si la base de datos falla? ¿Y quién de ellos irá a los testers y pedirá aprender a escribir pruebas correctamente? Además, hay también expertos en seguridad, gerentes de productos y un montón de otras personas.
La idea general de DevOps es establecer la comunicación entre roles y departamentos. Esto se logra principalmente no a través de algún software ingeniosamente configurado, sino a través de una práctica de comunicación. DevOps se trata de cultura, práctica, metodología y procesos. No existe ninguna especialidad de ingeniería que responda a estas preguntas.
Círculo vicioso
¿De dónde proviene entonces la disciplina de «ingeniería DevOps»? ¡Tenemos una versión! Las ideas de DevOps resultaron ser tan buenas que se convirtieron en víctimas de su propio éxito. Alrededor de este tema comenzaron a aparecer reclutadores dudosos y comerciantes de personas, que tienen su propia atmósfera.
Imagina: ayer estabas en Khimki haciendo shawarma, y hoy ya eres una persona importante, un reclutador senior. Hay todo un proceso de búsqueda y selección de candidatos, no es fácil, hay que entenderlo. Supongamos que el jefe del departamento dice: encuentra un especialista en X. Añadimos la palabra «ingeniero» a X, y ya está. ¿Necesitas Linux? Entonces definitivamente es un ingeniero de Linux; si deseas DevOps, es un ingeniero DevOps. La oferta de trabajo no consiste solo en el título, también hay que incluir algún texto. Lo más fácil es incluir una lista de palabras clave de Google, según la imaginación de cada uno. DevOps consta de dos palabras: «Dev» y «Ops», significa que hay que juntar palabras clave relacionadas con desarrolladores y administradores, todo en un mismo lugar. Así es como aparecen ofertas de trabajo que piden dominar 42 lenguajes de programación y 20 años de experiencia usando Kubernetes y Swarm al mismo tiempo. Ese es el esquema de trabajo.
Así en la mente de las personas se ha arraigado la imagen absurda e implacable de un superhéroe «DevOps», que configurará el despliegue para todos en Jenkins, y la felicidad llegará. Oh, si tan solo fuera tan simple. «Y también podemos cazar administradores de sistemas», piensa el reclutador, «es una palabra de moda, las mismas palabras clave, deben picar».
La demanda crea la oferta, y a todas estas ofertas locas han acudido una cantidad absurda de administradores de sistemas que se dieron cuenta: pueden hacer lo mismo que antes, pero ganando mucho más, llamándose "devops". Así como configurabas servidores por SSH uno a uno, seguirás configurando, pero ahora esto supuestamente es una práctica devops. Es un fenómeno complejo, parcialmente relacionado con la subestimación de los administradores clásicos y con el hype alrededor de DevOps, pero en general — lo que pasó, pasó.
Así que tenemos demanda y oferta. Un círculo vicioso que se retroalimenta. Con esto es con lo que luchamos (incluyendo la creación de la conferencia DevOops).
Sin duda, además de los administradores de sistemas que se han renombrado como "devops", hay otros participantes — por ejemplo, profesionales de SRE o desarrolladores de Infrastructure-as-Code.
¿Qué hacen las personas en DevOps (realmente)?
Así que, deseas avanzar en el estudio y aplicación de las prácticas de DevOps. Pero, ¿cómo hacerlo, hacia qué dirección mirar? Obviamente, no deberías guiarte ciegamente por las palabras clave populares.
Si hay trabajo, alguien debe hacerlo. Ya hemos aclarado que no son "ingenieros devops", entonces, ¿quién? Parece que sería más correcto formularlo no en términos de puestos, sino en términos de direcciones de trabajo específicas.
En primer lugar, puedes ocuparte del corazón de DevOps — los procesos y la cultura. La cultura es un asunto que no se logra rápidamente y no es fácil, y aunque tradicionalmente es responsabilidad de los líderes, de una forma u otra todos participan, desde programadores hasta administradores. Hace un par de meses, Tim Lister :
"La cultura se establece a partir de los valores fundamentales de la organización. Normalmente, la gente no se da cuenta, pero nosotros, trabajando en consultoría durante muchos años, hemos aprendido a notarlo. Entras en una empresa y literalmente a los pocos minutos comienzas a sentir lo que está sucediendo. Lo llamamos 'aroma'. A veces ese aroma es realmente bueno. Otras veces causa náuseas. (…) No puedes cambiar la cultura antes de que se reconozcan los valores y creencias que están detrás de acciones concretas. El comportamiento es fácil de observar, pero encontrar creencias es difícil. DevOps es un excelente ejemplo de cómo todo se vuelve más complicado y complejo."
También hay una parte técnica en la cuestión, por supuesto. Si tu nuevo código llega para prueba en un mes, pero solo se libera un año después, y no es físicamente posible acelerar todo esto, es probable que no llegues a las buenas prácticas. Las buenas prácticas se mantienen con buenas herramientas. Por ejemplo, al tener presente la idea de Infrastructure-as-Code, se puede utilizar cualquier cosa, desde AWS CloudFormation y Terraform hasta Chef-Ansible-Puppet. Todo esto debe ser conocido y dominado, y ya es una disciplina ingenieril. Es importante no confundir causa y efecto: primero trabajas bajo los principios de SRE y solo después concretas estos principios en soluciones técnicas específicas. Además, SRE es una metodología muy compleja que no habla solo de cómo configurar Jenkins, sino de cinco principios fundamentales:
- Mejorar la interacción entre roles y departamentos
- Aceptar los errores como parte inherente del trabajo
- Implementar cambios gradualmente
- Usar herramientas y otras formas de automatización
- Medir todo lo que se pueda medir
No se trata solo de un conjunto de afirmaciones, sino de una . Por ejemplo, en el camino hacia la aceptación de errores será necesario abordar los riesgos, medir la disponibilidad e indisponibilidad de los servicios con algo como SLI () y SLO (), aprender a redactar post-mortems y hacer que escribirlos no sea aterrador.
En la disciplina SRE, el uso de herramientas es solo una parte del éxito, aunque no menos importante. Necesitamos seguir desarrollándonos técnicamente, observar lo que sucede en el mundo y cómo se puede aplicar a nuestro trabajo.
A su vez, las soluciones Cloud Native se han vuelto muy populares ahora. Según la comprensión moderna de la Cloud Native Computing Foundation, las tecnologías Cloud Native permiten a las organizaciones desarrollar y ejecutar aplicaciones escalables en entornos dinámicos modernos, como nubes públicas, privadas e híbridas. Ejemplos de esto son los contenedores, los service meshes, los microservicios, la infraestructura inmutable y las APIs declarativas. Todas estas técnicas permiten que los sistemas débilmente acoplados permanezcan elásticos, manejables y bien monitoreados. Una buena automatización permite a los ingenieros realizar grandes cambios con frecuencia y con resultados predecibles, sin que se convierta en una tarea abrumadora. Todo esto es respaldado por un stack de herramientas bien conocidas, como Docker y Kubernetes.
Esta es una definición bastante compleja y amplia, relacionada con el hecho de que el área es también bastante complicada. Por un lado, se afirma que los nuevos cambios en este sistema deben añadirse de manera relativamente sencilla. Por otro lado, entender cómo crear un entorno containerizado en el que servicios débilmente acoplados operen en una infraestructura definida por software y se entreguen allí a través de CI/CD continuo, y construir prácticas de DevOps alrededor de todo esto, requiere una considerable experiencia.
¿Qué hacer con todo esto?
Cada uno resuelve estos problemas a su manera: por ejemplo, se pueden publicar ofertas de trabajo adecuadas para romper el ciclo vicioso. Se podría entender qué significan términos como DevOps y Cloud Native y usarlos correctamente y en contexto. Se puede avanzar en DevOps y mostrar con el ejemplo los enfoques correctos.
Estamos organizando una conferencia , que ofrece la oportunidad de profundizar en los temas de los que acabamos de hablar. Para ello hay varios grupos de presentaciones:
- Procesos y cultura;
- Ingeniería de Confiabilidad del Sitio;
- Cloud Native;
¿Cómo elegir a dónde ir? Aquí hay un detalle sutil. Por un lado, DevOps se trata de interacción, y queremos que asistas a presentaciones de diferentes bloques. Por otro lado, si eres un líder de desarrollo que ha venido a la conferencia para concentrarse en una tarea específica, entonces nadie te limita; evidentemente, será el bloque sobre procesos y cultura. Recuerda que después de la conferencia tendrás grabaciones (tras completar el formulario de retroalimentación), así que siempre podrás ver las presentaciones menos importantes más tarde.
Es evidente que en la conferencia no puedes asistir a tres tracks a la vez, por lo que organizamos el programa para que en cada intervalo de tiempo haya temas para todos los gustos.
Solo falta entender qué hacer si eres ingeniero de DevOps. Primero, intenta definir en qué estás trabajando realmente. A menudo, esta palabra se usa para describir:
- Desarrolladores que se ocupan de la infraestructura. Para ti, los grupos de presentaciones sobre SRE y Cloud Native son los más adecuados.
- Administradores de sistemas. Aquí es más complicado. DevOops no se trata de administración de sistemas. Afortunadamente, hay muchas conferencias, libros, artículos, videos en Internet, etc., sobre administración de sistemas. Por otro lado, si te interesa desarrollarte en cuanto a entender la cultura y los procesos, explorar tecnologías en la nube y los detalles de la vida con Cloud Native, ¡nos encantaría verte! Piensa en esto: si estás en administración, ¿qué harás después? Para no encontrarte de repente en una situación incómoda, es bueno aprender desde ahora.
Hay otra opción: persistes y sigues afirmando que eres justo un ingeniero de DevOps y nada más, sea lo que sea que signifique eso. Entonces tengo que decepcionarte, ¡DevOops no es una conferencia para ingenieros de DevOps!
Diapositiva de en Múnich
DevOops 2020 Moscú se llevará a cabo del 29 al 30 de abril en Moscú, ya se pueden .
Además, puedes hasta el 8 de febrero. Ten en cuenta que al completar el formulario, debes elegir la audiencia objetivo a la que tu ponencia sea más útil (hay una sorpresa escondida en la lista).
Fuente: habr.com
