Recientemente, este tipo de anuncios han inundado Internet. A pesar del agradable salario, uno no puede evitar avergonzarse de que en su interior esté escrita una herejía salvaje. Al principio se supone que "DevOps" e "ingeniero" de alguna manera se pueden unir en una sola palabra, y luego aparece una lista aleatoria de requisitos, algunos de los cuales están claramente copiados de la vacante de administrador de sistemas.
En este post me gustaría hablar un poco de cómo llegamos a este punto de la vida, qué es realmente DevOps y qué hacer con él ahora.
Estas vacantes se pueden condenar de todas las formas posibles, pero el hecho es que hay muchas y así es como funciona el mercado en este momento. Celebramos una conferencia devops y declaramos abiertamente: " - no para ingenieros de DevOps." A muchos les parecerá extraño y descabellado: por qué la gente que organiza un evento completamente comercial va en contra del mercado. Ahora te lo explicamos todo.
Sobre cultura y procesos
Comencemos con el hecho de que DevOps no es una disciplina de ingeniería. Todo empezó con el hecho de que la división de roles históricamente establecida no favorece la calidad de los productos. Cuando los programadores sólo programan, pero no quieren oír nada sobre pruebas, el software está plagado de errores. Cuando a los administradores no les importa cómo o por qué está escrito el software, el soporte se convierte en un infierno.
Por ejemplo, describir la diferencia entre un administrador de sistemas y un enfoque SRE para la gestión de servicios. . Se han llevado a cabo interesantes estudios en — está claro que los mejores desarrolladores de alguna manera logran implementar nuevos cambios en producción más rápido que una vez por hora. Proban con las manos no más del 10% (esto se puede ver en ). ¿Cómo lo hacen? “Sobresalga o muera”, dice uno de los títulos del informe. Para una discusión detallada de estas estadísticas en el contexto de las pruebas, puede consultar la conferencia magistral de Baruch Sadogursky. en nuestra otra conferencia, Heisenbug.
“Cuando no hay acuerdo entre camaradas,
Bueno, su negocio no servirá,
Y no funcionará fuera de él, solo la harina.
Érase una vez un cisne, un cangrejo y un lucio..."
¿Qué parte de los programadores web crees que realmente entiende las condiciones bajo las cuales se utilizan sus aplicaciones en producción? ¿Cuántos de ellos acudirán a los administradores e intentarán averiguar qué pasará si la base de datos falla? ¿Y cuál de ellos acudirá a los evaluadores y les pedirá que les enseñen cómo redactar pruebas correctamente? Y también hay guardias de seguridad, gerentes de producto y muchas otras personas.
La idea general de DevOps es crear colaboración entre roles y departamentos. En primer lugar, esto no se logra mediante un software inteligentemente configurado, sino mediante la práctica de la comunicación. DevOps tiene que ver con cultura, prácticas, metodología y procesos. No existe ninguna especialidad de ingeniería que pueda responder a estas preguntas.
Círculo vicioso
¿De dónde vino entonces la disciplina de la “ingeniería devops”? ¡Tenemos una versión! Las ideas de DevOps eran buenas, tan buenas que se convirtieron en víctimas de su propio éxito. Algunos reclutadores y traficantes de personas turbios, que tienen su propia atmósfera, comenzaron a dar vueltas en torno a todo este tema.
Imagínese: ayer estaba haciendo shawarma en Khimki y hoy ya es un gran hombre, un reclutador senior. Hay todo un proceso de búsqueda y selección de candidatos, no todo es fácil, hay que entenderlo. Digamos que el jefe de un departamento dice: busque un especialista en X. Le asignamos la palabra “ingeniero” a X y listo. ¿Necesitas Linux? Bueno, este es definitivamente un ingeniero de Linux, si quieres DevOps, entonces un ingeniero de DevOps. La vacante consta no solo de un título, sino que también se debe ingresar algún texto en su interior. La forma más sencilla es introducir un conjunto de palabras clave de Google, según su imaginación. DevOps consta de dos palabras: "Dev" y "Ops", lo que significa que debemos unir palabras clave relacionadas con desarrolladores y administradores, todas en una sola pila. Así aparecen vacantes sobre dominio de 42 lenguajes de programación y 20 años de uso simultáneo de Kubernetes y Swarm. Diagrama de trabajo.
Así es como se ha arraigado en la mente de las personas la imagen sin sentido y despiadada de cierto superhéroe "devops", que configurará a todos para que se desplieguen en Jenkins, y la felicidad llegará. Oh, si todo fuera tan simple. "Y así también se puede cazar a los administradores de sistemas", piensa RR.HH., "es una palabra de moda, las palabras clave son las mismas, deberían morder el anzuelo".
La demanda crea oferta, y todas estas vacantes de basura se han llenado con una cantidad increíble de administradores de sistemas que se dieron cuenta: puedes hacer todo igual que antes, pero obtener varias veces más llamándote "devops". Así como configuraste servidores a través de SSH manualmente uno a la vez, continuarás configurándolos, pero ahora esto es supuestamente una práctica de Devops. Se trata de una especie de fenómeno complejo, en parte relacionado con la subestimación de los administradores clásicos y el revuelo en torno a DevOps, pero en general lo que pasó, pasó.
Entonces tenemos oferta y demanda. Un círculo vicioso que se retroalimenta. Esto es contra lo que estamos luchando (incluso mediante la creación de la conferencia DevOops).
Por supuesto, además de los administradores de sistemas que se han rebautizado como "devops", hay otros participantes, por ejemplo, SRE profesionales o desarrolladores de infraestructura como código.
Lo que hace la gente en DevOps (de verdad)
Entonces desea avanzar en el aprendizaje y la aplicación de prácticas de DevOps. Pero ¿cómo hacerlo, en qué dirección mirar? Obviamente, no debes confiar ciegamente en palabras clave populares.
Si hay trabajo, alguien debería hacerlo. Ya hemos descubierto que estos no son “ingenieros devops”, entonces ¿quiénes lo son? Parece más correcto formular esto no en términos de puestos, sino en términos de áreas de trabajo específicas.
En primer lugar, puede abordar el corazón de DevOps: los procesos y la cultura. La cultura es un negocio lento y difícil, y aunque tradicionalmente es responsabilidad de los directivos, todos están involucrados de una forma u otra, desde los programadores hasta los administradores. Hace un par de meses Tim Lister :
“La cultura está determinada por los valores fundamentales de la organización. Normalmente la gente no se da cuenta de esto, pero después de haber trabajado en consultoría durante muchos años, estamos acostumbrados a notarlo. Entras en una empresa y literalmente a los pocos minutos empiezas a sentir lo que está pasando. A esto lo llamamos "sabor". A veces este aroma es realmente bueno. A veces provoca náuseas. (...) No se puede cambiar una cultura hasta que se comprendan los valores y creencias detrás de acciones específicas. El comportamiento es fácil de observar, pero buscar creencias es difícil. DevOps es simplemente un gran ejemplo de cómo las cosas se vuelven cada vez más complejas”.
Por supuesto, también hay una parte técnica de la cuestión. Si su nuevo código se prueba en un mes, pero se publica sólo un año después y es físicamente imposible acelerarlo todo, es posible que no esté a la altura de las buenas prácticas. Las buenas prácticas están respaldadas por buenas herramientas. Por ejemplo, con la idea de infraestructura como código en mente, puede utilizar cualquier cosa, desde AWS CloudFormation y Terraform hasta Chef-Ansible-Puppet. Es necesario saber y poder hacer todo esto, y esto ya es toda una disciplina de ingeniería. Es importante no confundir causa con efecto: primero se trabaja según los principios de SRE y sólo después se implementan estos principios en forma de algunas soluciones técnicas específicas. Al mismo tiempo, SRE es una metodología muy completa que no le dice cómo configurar Jenkins, sino cinco principios básicos:
- Comunicación mejorada entre roles y departamentos.
- Aceptar los errores como parte integral del trabajo.
- Hacer cambios gradualmente
- Uso de herramientas y otros tipos de automatización
- Medir todo lo que se puede medir
No se trata sólo de un conjunto de declaraciones, sino de una . Por ejemplo, en el camino hacia la aceptación de errores, deberá comprender los riesgos, medir la disponibilidad e indisponibilidad de los servicios utilizando algo como SLI () y SLO (), aprende a escribir autopsias y haz que escribirlas no dé miedo.
En la disciplina SRE, el uso de herramientas es sólo una parte del éxito, aunque importante. Necesitamos desarrollarnos técnicamente constantemente, observar lo que sucede en el mundo y cómo se puede aplicar en nuestro trabajo.
A su vez, las soluciones Cloud Native se han vuelto muy populares. Según lo define hoy la Cloud Native Computing Foundation, las tecnologías Cloud Native permiten a las organizaciones desarrollar y ejecutar aplicaciones escalables en los entornos dinámicos actuales, como las nubes públicas, privadas e híbridas. Los ejemplos incluyen contenedores, mallas de servicios, microservicios, infraestructura inmutable y API declarativas. Todas estas técnicas permiten que los sistemas débilmente acoplados sigan siendo elásticos, manejables y altamente observables. Una buena automatización permite a los ingenieros realizar grandes cambios con frecuencia y con resultados predecibles sin que sea una tarea ardua. Todo esto está respaldado por una pila de herramientas conocidas como Docker y Kubernetes.
Esta definición bastante complicada y amplia se debe al hecho de que el área también es bastante compleja. Por un lado, se argumenta que es muy sencillo introducir nuevos cambios en este sistema. Por otro lado, para descubrir cómo crear una especie de entorno en contenedores en el que los servicios débilmente acoplados vivan en una infraestructura definida por software y se entreguen allí mediante CI/CD continuo, y desarrollar prácticas de DevOps en torno a todo esto, todo esto requiere más Más de uno se come al perro.
Que hacer con todo esto
Cada uno resuelve estos problemas a su manera: por ejemplo, puedes publicar vacantes normales para romper el círculo vicioso. Puede descubrir qué significan palabras como DevOps y Cloud Native y utilizarlas correctamente y al grano. Puede desarrollar en DevOps y demostrar los enfoques correctos con su ejemplo.
Estamos haciendo una conferencia , lo que brinda la oportunidad de profundizar en las cosas de las que acabamos de hablar. Para ello existen varios grupos de informes:
- Procesos y cultura;
- Ingeniería de Confiabilidad del Sitio;
- Nativo de la nube;
¿Cómo elegir dónde ir? Hay un punto sutil aquí. Por un lado, DevOps se trata de interacción y realmente queremos que asista a presentaciones de diferentes bloques. Por otro lado, si usted es un gerente de desarrollo que vino a la conferencia para concentrarse en una tarea específica, entonces nadie lo limitará; obviamente, esto será un bloqueo sobre procesos y cultura. No olvide que tendrá grabaciones después de la conferencia (después de completar el formulario de comentarios), para que siempre pueda ver presentaciones menos importantes más adelante.
Evidentemente, en la propia conferencia no se pueden ir a tres temas a la vez, por eso organizamos el programa de tal manera que en cada franja horaria haya temas para todos los gustos.
¡Todo lo que queda es entender qué hacer si eres un ingeniero de DevOps! Primero, intenta determinar qué haces realmente. Normalmente les gusta llamar a esta palabra:
- Desarrolladores que trabajan en infraestructura. Los grupos de informes sobre SRE y Cloud Native son los más adecuados para ti.
- Administradores de sistemas. Es más complicado aquí. DevOops no se trata de administración de sistemas. Afortunadamente, existen muchas conferencias, libros, artículos, vídeos, etc. excelentes en Internet sobre el tema de la administración de sistemas. Por otro lado, si estás interesado en desarrollarte en términos de comprensión de la cultura y los procesos, aprender sobre las tecnologías de la nube y los detalles de la vida con Cloud Native, ¡nos encantaría verte! Piensa en esto: estás haciendo administración, ¿y luego qué harás? Para evitar encontrarse repentinamente en una situación desagradable, debe aprender ahora.
Hay otra opción: persistes y continúas afirmando que eres específicamente un ingeniero de DevOps y nada más, sea lo que sea que eso signifique. Entonces tenemos que decepcionarte, ¡DevOops no es una conferencia para ingenieros de DevOps!
Deslizar desde en Munich
DevOops 2020 Moscú se celebrará del 29 al 30 de abril en Moscú, las entradas ya están disponibles .
Además, puedes hasta el 8 de febrero. Tenga en cuenta que al completar el formulario, debe seleccionar el público objetivo que más se beneficiará de su informe (Hay una sorpresa enterrada dentro de la lista.).
Fuente: habr.com