Recientemente, tales anuncios han inundado Internet. A pesar del salario agradable, uno no puede dejar de avergonzarse de que una herejía salvaje esté escrita en su interior. Al principio, se supone que "DevOps" e "ingeniero" se pueden unir de alguna manera en una palabra, y luego viene una lista aleatoria de requisitos, algunos de los cuales se copian claramente de la vacante del administrador del sistema.
En esta publicación, quiero hablar un poco sobre cómo llegamos al punto de lo que realmente es 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. Hicimos una conferencia de devo y declaramos abiertamente: " DevOops , no para ingenieros de DevOps". Aquí, parecerá extraño y salvaje para muchos: por qué las personas que realizan un evento completamente comercial van en contra del mercado. Explicaremos todo ahora.
Sobre cultura y procesos
Para empezar, DevOps no es una disciplina de ingeniería. Todo comenzó con el hecho de que la división de roles establecida históricamente no funciona en la calidad de los productos. Cuando los programadores solo programan pero no quieren escuchar nada sobre las pruebas, el software está lleno de errores. Cuando a los administradores no les importa cómo y por qué se escribe el software, el soporte se convierte en un infierno.
Por ejemplo, el famoso Libro SRE de Google comienza con una descripción de la diferencia entre el enfoque sysadmin y SRE-shny para la gestión de servicios. Se realizaron estudios interesantes como parte de la encuesta DORA : se puede ver que los mejores desarrolladores de alguna manera logran implementar nuevos cambios en la producción más rápido que una vez por hora. Prueban con sus manos no más del 10% (esto se puede ver en el DORA del año pasado ). Como lo hacen "Excel or die" dice uno de los encabezados del informe. Para una discusión detallada de estas estadísticas en términos de pruebas, puede recurrir a la nota clave de Baruch Sadogursky "Tenemos DevOps. Vamos a despedir a todos los probadores " en nuestra otra conferencia, Heisenbug.
"Cuando no hay acuerdo en los camaradas,
No va a funcionar bien,
Y no saldrá de eso, solo harina.
Una vez cisne, cáncer y lucio ... "
¿Qué piensas, qué parte de los programadores web realmente entiende las condiciones bajo las cuales sus aplicaciones funcionan en productos? ¿Cuántos de ellos irán a los administradores e intentarán descubrir qué sucederá cuando la base caiga? ¿Y quién de ellos irá a los evaluadores y les pedirá que enseñen cómo escribir las pruebas correctamente? Y todavía hay guardias de seguridad, gerentes de producto y un montón de personas.
La idea general de DevOps es establecer la interacción entre roles y departamentos. En primer lugar, esto no se logra mediante un software astutamente ajustado, sino mediante la práctica de la comunicación. DevOps se trata de cultura, práctica, metodología y procesos. No existe una especialidad de ingeniería que responda estas preguntas.
Círculo vicioso
¿De dónde, entonces, vino la disciplina de la "ingeniería devops"? ¡Tenemos una versión! Las ideas de DevOps resultaron ser buenas, tan buenas que se convirtieron en víctimas de su éxito. En torno a este tema, algunos reclutadores y traficantes fangosos con una atmósfera muy especial comenzaron a arremolinarse.
Imagínese: ayer hizo shawarma en Khimki, y hoy ya es un gran hombre, reclutador senior. Hay un proceso completo de búsqueda y selección de candidatos, no todo es fácil, debe comprenderlo. Supongamos que el jefe del departamento dice: busque un especialista en X. Asignamos la palabra "ingeniero" a X, y el punto está en el sombrero. ¿Necesitas Linux? Bueno, definitivamente es un ingeniero de Linux, quieres DevOps: ingeniero de DevOps. Un trabajo no solo consiste en un encabezado, sino que se debe ingresar algo de texto dentro. La forma más fácil es ingresar un conjunto de palabras clave de Google, para quienes hay suficiente imaginación. DevOps consta de dos palabras: "Dev" y "Ops", lo que significa que debe pegar las palabras clave relacionadas con desarrolladores y administradores, todo en una pila. Por lo tanto, hay vacantes sobre poseer 42 lenguajes de programación y 20 años de usar Kubernetes y Swarm al mismo tiempo. Esquema de trabajo.
Entonces, la imagen despiadada y despiadada de cierto superhéroe - "devopus" echó raíces en la mente de las personas, lo que hará que todos se desplieguen en Jenkins, y la felicidad llegará. Ah, si tan solo fuera así de simple. "Y también puedes hackear a los administradores del sistema de esta manera", piensa Eichar, "la palabra está de moda, las palabras clave son las mismas, deben picotear".
La demanda crea suministro, y un número increíble de administradores de sistemas se han encontrado con todas estas vacantes de basura, que se han dado cuenta de que puedes hacer lo mismo que antes, pero obtienes varias veces más, llamándote "devops". A medida que configura el servidor a través de SSH con sus manos una a la vez, continuará configurándolo, pero ahora se supone que esto es una práctica de DevOps. Este es un tipo de fenómeno complejo, parcialmente relacionado tanto con la subestimación de los administradores clásicos como con la exageración en torno a DevOps, pero en general, lo que sucedió resultó.
Entonces, tenemos oferta y demanda. Un círculo vicioso que se alimenta a sí mismo. Esto es con lo que estamos luchando (incluso creando la conferencia DevOops).
Por supuesto, además de los administradores del sistema, rebautizados como "devops", hay otros participantes, por ejemplo, SRE profesionales o desarrolladores de Infraestructura como Código.
¿Qué hacen las personas en DevOps (en realidad)
Por lo tanto, desea avanzar en el aprendizaje y la aplicación de prácticas DevOps. Pero, ¿cómo hacerlo, qué forma de mirar? Obviamente, guiarse ciegamente por palabras clave populares no vale la pena.
Si hay trabajo, alguien debería hacerlo. Ya hemos descubierto que estos no son "ingenieros de DevOps", ¿entonces quién? Parece más correcto formular esto no en términos de publicaciones, sino en términos de áreas específicas de trabajo.
Primero, puede hacer el corazón de DevOps: procesos y cultura. La cultura no es una cuestión rápida y fácil, y aunque tradicionalmente es responsabilidad de los gerentes, de una forma u otra, todos participan en esto, desde los programadores hasta los administradores. Hace un par de meses, Tim Lister dijo en una entrevista :
“La cultura está establecida por los valores centrales de la organización. Por lo general, las personas no se dan cuenta de esto, pero nosotros, trabajando en consultoría durante muchos años, estamos acostumbrados a notarlo. Entras en la empresa y literalmente en unos minutos comienzas a sentir lo que está sucediendo. Lo llamamos "aroma". A veces este sabor es realmente bueno. A veces causa náuseas. (...) No se puede cambiar una cultura antes de que se hayan realizado los valores y creencias detrás de acciones concretas. El comportamiento es fácil de observar y buscar persuasión es difícil. DevOps es solo un gran ejemplo de cómo las cosas se ponen cada vez más difíciles ".
También hay una parte técnica a la pregunta, por supuesto. Si obtiene un nuevo código para probar en un mes, y en el lanzamiento aparece solo en un año, y es físicamente imposible acelerar todo esto, no puede cumplir con 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 usar cualquier cosa, desde AWS CloudFormation y Terraform hasta Chef-Ansible-Puppet. Necesita saber y poder hacer todo esto, y esta es una disciplina de ingeniería completa. Es importante no confundir la causa con las consecuencias: primero trabaja en los principios de SRE y solo luego implementa estos principios en forma de algunas soluciones técnicas específicas. Al mismo tiempo, SRE es una metodología muy completa que no habla sobre cómo configurar Jenkins, sino sobre cinco principios básicos:
- Mejorando la interacción entre roles y departamentos
- Aceptar errores como parte integral del trabajo
- Cambio progresivo
- Usando tuning y otra automatización
- Medir todo lo que se puede medir
Esto no es solo un conjunto de declaraciones, sino una guía específica para la acción . Por ejemplo, en el camino de cometer errores, deberá lidiar con los riesgos, medir la disponibilidad y la inaccesibilidad de los servicios utilizando algo como SLI ( indicadores de nivel de servicio ) y SLO ( objetivos de nivel de servicio ), aprender a escribir post mortem y facilitar su escritura. .
En la disciplina SRE, el uso de herramientas es solo una parte del éxito, sin embargo, es importante. Necesitamos desarrollar constantemente técnicamente, observar lo que está sucediendo en el mundo y cómo se puede aplicar en nuestro trabajo.
A su vez, las soluciones de Cloud Native se han vuelto muy populares ahora. De acuerdo con la comprensión actual de 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 servicio, microservicios, infraestructura inmutable y API declarativas. Todas estas técnicas permiten que los sistemas acoplados libremente permanezcan flexibles, manejables y bien observables. Una buena automatización permite a los ingenieros realizar grandes cambios a menudo y con resultados predecibles, sin convertirlo en un trabajo infernal. Todo esto está respaldado por una pila de herramientas conocidas como Docker y Kubernetes.
Esta definición bastante complicada y pesada está relacionada con el hecho de que la región es bastante complicada. Por un lado, se argumenta que los nuevos cambios a este sistema deberían agregarse de manera bastante simple. Por otro lado, para descubrir cómo crear algún tipo de entorno en contenedores en el que los servicios acoplados libremente vivan en una infraestructura definida por software y se entreguen allí utilizando un CI / CD continuo, y construyan alrededor de toda esta práctica de DevOps: necesita más de uno comer un perro
¿Qué hacer con todo esto?
Cada uno resuelve estos problemas a su manera: por ejemplo, puede publicar trabajos 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 propio ejemplo.
Estamos haciendo la conferencia DevOops 2020 Moscú , que brinda la oportunidad de comprender mejor las cosas de las que acabamos de hablar. Hay varios grupos de informes para esto:
- Procesos y cultura;
- Ingeniería de confiabilidad del sitio;
- Nube nativa
¿Cómo elegir a dónde ir? Hay un punto sutil. Por un lado, DevOps trata sobre la interacción, y realmente queremos que vayas a los informes de diferentes bloques. Por otro lado, si usted es un gerente de desarrollo que asistió a la conferencia para concentrarse en una tarea específica, entonces nadie lo limita; obviamente, esto será un bloqueo sobre los procesos y la cultura. No olvide que después de la conferencia tendrá notas (después de completar el formulario de comentarios), por lo que siempre podrá ver informes menos importantes más adelante.
Obviamente, en la conferencia en sí no puede ir de inmediato a tres pistas al mismo tiempo, por lo que estamos creando el programa de tal manera que haya temas para todos los gustos en cada intervalo de tiempo.
¡Solo queda entender qué hacer si eres un ingeniero de DevOps! Primero, trate de determinar lo que realmente está haciendo. Por lo general, les gusta llamar a esta palabra:
- Desarrolladores que se ocupan de infraestructura. Los grupos de conversación SRE y Cloud Native son los más adecuados para usted.
- Administradores del sistema. Es mas complicado. DevOops no se trata de la administración del sistema. Afortunadamente, hay muchas conferencias excelentes, libros, artículos, videos en Internet, etc. sobre el tema de la administración del sistema. Por otro lado, si está interesado en desarrollarse en términos de comprender la cultura y los procesos, explorar las tecnologías de la nube y los detalles de la vida con Cloud Native, ¡nos alegrará verlo! Piensa en esto: aquí estás en la administración, ¿y luego qué harás? Para no estar repentinamente en una situación desagradable, vale la pena estudiar ahora.
Hay otra opción: persiste y continúa afirmando que es un ingeniero de DevOps y nada más, lo que sea que eso signifique. Luego obligado a llorar, ¡DevOops no es una conferencia para ingenieros de DevOps!
Diapositiva del informe Konstantin Diener en Munich
DevOops 2020 Moscú se llevará a cabo del 29 al 30 de abril en Moscú, las entradas ya se pueden comprar en el sitio web oficial .
Además, puede enviar su informe antes del 8 de febrero. Tenga en cuenta que al completar el formulario, debe elegir el público objetivo para el cual su informe será más bueno ( una sorpresa está oculta dentro de la lista ).