Recentemente, tales anuncios inundaron Internet. A pesar do agradable salario, un non pode evitar sentirse avergoñado de que a salvaxe herexía está escrita dentro. Ao principio, asúmese que "DevOps" e "enxeñeiro" poden pegarse dalgún xeito nunha soa palabra, e despois hai unha lista aleatoria de requisitos, algúns dos cales están claramente copiados da vacante de administrador do sistema.
Neste post gustaríame falar un pouco de como chegamos a este punto da vida, o que é realmente DevOps e que facer con el agora.
Este tipo de prazas pódense condenar de todas as formas posibles, pero o certo é: son moitas, e así funciona o mercado nestes momentos. Fixemos unha conferencia devops e declaramos abertamente: " - non para enxeñeiros de DevOps". Isto parecerá estraño e salvaxe para moitos: por que a xente que está a facer un evento completamente comercial vai en contra do mercado. Agora imos explicar todo.
Sobre a cultura e os procesos
Comecemos co feito de que DevOps non é unha disciplina de enxeñería. Todo comezou co feito de que a división de roles históricamente establecida non funciona para a calidade dos produtos. Cando os programadores só programan, pero non queren escoitar nada sobre probas, o software está cheo de erros. Cando aos administradores non lles importa como ou por que se escribe o software, o soporte convértese nun inferno.
Por exemplo, describindo a diferenza entre un administrador do sistema e un enfoque SRE para a xestión do servizo . Realizáronse interesantes estudos dentro — Está claro que os mellores desenvolvedores conseguen, dalgún xeito, implementar novos cambios na produción máis rápido que unha vez por hora. Proban coas mans non máis do 10% (isto pódese ver desde ). Como fan isto? "Excel ou morrer", di un dos títulos do informe. Para unha discusión detallada destas estatísticas no contexto das probas, podes consultar a nota principal de Baruch Sadogursky na nosa outra conferencia, Heisenbug.
"Cando non hai acordo entre compañeiros,
As cousas non lles irán ben,
E non sairá nada, só tormento.
Érase unha vez un cisne, un lagostino e un lucio..."
Que parte dos programadores web cres que entende realmente as condicións nas que se utilizan as súas aplicacións na produción? Cantos deles acudirán aos administradores e tentarán descubrir que pasará se a base de datos falla? E cal deles acudirá aos probadores e lles pedirá que lles ensinen a escribir correctamente as probas? E tamén hai gardas de seguridade, xestores de produtos e unha morea de persoas.
A idea xeral de DevOps é crear colaboración entre roles e departamentos. En primeiro lugar, isto conséguese non mediante algún software intelixentemente configurado, senón pola práctica da comunicación. DevOps trata sobre cultura, prácticas, metodoloxía e procesos. Non hai ningunha especialidade de enxeñaría que poida responder a estas preguntas.
Círculo vicioso
De onde veu entón a disciplina da "enxeñería devops"? Temos unha versión! As ideas de DevOps eran boas, tan boas que se converteron en vítimas do seu propio éxito. Algúns recrutadores sombríos e traficantes de seres humanos, que teñen a súa propia atmosfera, comezaron a xirar en torno a todo este tema.
Imaxina: onte estabas facendo shawarma en Khimki, e hoxe xa es un home grande, un reclutador senior. Hai todo un proceso de busca e selección de candidatos, non todo é doado, hai que entender. Digamos que o xefe dun departamento di: busca un especialista en X. Asignamos a palabra "enxeñeiro" a X e xa está. Necesitas Linux? Ben, este é definitivamente un enxeñeiro de Linux, se queres DevOps, entón un enxeñeiro de DevOps. A vacante consiste non só nun título, senón que tamén hai que introducir algún texto no seu interior. O xeito máis sinxelo é introducir un conxunto de palabras clave de Google, dependendo da túa imaxinación. DevOps consta de dúas palabras: "Dev" e "Ops", o que significa que necesitamos pegar palabras clave relacionadas con desenvolvedores e administradores, todo nunha pila. Así aparecen as vacantes sobre a competencia en 42 linguaxes de programación e 20 anos de uso simultaneo de Kubernetes e Swarm. Diagrama de traballo.
Así foi como a imaxe sen sentido e despiadada dun certo superheroe "devops" arraigou na mente da xente, que configurará a todos para que se despreguen en Jenkins, e chegará a felicidade. Ah, se todo fose tan sinxelo. "E tamén é así como podes cazar aos administradores do sistema", pensa RH, "é unha palabra de moda, as palabras clave son as mesmas, deberían ter o anzuelo".
A demanda crea oferta, e todas estas vacantes de lixo cubríronse cun número insensato de administradores de sistemas que se deron conta: podes facer todo o mesmo que antes, pero conseguir varias veces máis chamándote "devops". Do mesmo xeito que configuraches os servidores a través de SSH manualmente un a un, seguirás configurándoos, pero agora supostamente é unha práctica devops. Este é algún tipo de fenómeno complexo, en parte relacionado coa subestimación dos administradores clásicos e o bombo en torno a DevOps, pero en xeral, ocorreu o que pasou.
Entón temos oferta e demanda. Un círculo vicioso que se alimenta. Isto é contra o que loitamos (incluíndo a creación da conferencia DevOops).
Por suposto, ademais dos administradores do sistema que cambiaron o nome de "devops", hai outros participantes, por exemplo, SRE profesionais ou desenvolvedores de Infraestructura como Código.
Que fai a xente en DevOps (de verdade)
Polo tanto, quere saír adiante na aprendizaxe e na aplicación das prácticas de DevOps. Pero como facelo, en que dirección mirar? Obviamente, non debes confiar cegamente en palabras clave populares.
Se hai traballo, alguén debería facelo. Xa descubrimos que estes non son "enxeñeiros devops", entón quen o son? Parece máis correcto formular isto non en función de postos, senón de áreas específicas de traballo.
En primeiro lugar, pode abordar o corazón de DevOps: procesos e cultura. A cultura é un negocio lento e difícil, e aínda que tradicionalmente é responsabilidade dos xestores, todos participan dun xeito ou doutro, desde programadores ata administradores. Hai un par de meses Tim Lister :
“A cultura está determinada polos valores fundamentais da organización. Normalmente a xente non se decata diso, pero levando moitos anos traballando na consultoría, estamos acostumados a notalo. Entras nunha empresa e literalmente en poucos minutos comezas a sentir o que está a pasar. Chamámoslle "sabor". Ás veces, este aroma é moi bo. Ás veces provoca náuseas. (...) Non se pode cambiar unha cultura ata que se comprendan os valores e as crenzas detrás de accións específicas. O comportamento é fácil de observar, pero buscar crenzas é difícil. DevOps é só un gran exemplo de como as cousas son cada vez máis complexas".
Tamén hai unha parte técnica do problema, por suposto. Se o teu novo código se proba nun mes, pero só se publica un ano despois e é fisicamente imposible aceleralo todo, é posible que non cumpras as boas prácticas. As boas prácticas están apoiadas por boas ferramentas. Por exemplo, tendo en conta a idea de Infrastructure-as-Code, podes usar calquera cousa, desde AWS CloudFormation e Terraform ata Chef-Ansible-Puppet. Cómpre saber e poder facer todo isto, e esta xa é toda unha disciplina de enxeñería. É importante non confundir causa co efecto: primeiro traballas segundo os principios de SRE e só despois implementas estes principios en forma dalgunhas solucións técnicas específicas. Ao mesmo tempo, SRE é unha metodoloxía moi completa que non che indica como configurar Jenkins, senón sobre cinco principios básicos:
- Mellora a comunicación entre roles e departamentos
- Aceptar os erros como parte integrante do traballo
- Facendo cambios gradualmente
- Uso de ferramentas e outras automatizacións
- Medindo todo o que se pode medir
Este non é só un conxunto de afirmacións, senón un específico . Por exemplo, no camiño para aceptar erros, terás que comprender os riscos, medir a dispoñibilidade e non dispoñibilidade dos servizos usando algo como SLI () e SLO (), aprende a escribir autopsias e fai que escribilas non teña medo.
Na disciplina SRE, o uso de ferramentas é só unha parte do éxito, aínda que é importante. Necesitamos desenvolvernos tecnicamente constantemente, mirar o que está a pasar no mundo e como se pode aplicar no noso traballo.
Pola súa banda, as solucións Cloud Native volvéronse moi populares. Tal e como define a Cloud Native Computing Foundation hoxe, as tecnoloxías Cloud Native permiten ás organizacións desenvolver e executar aplicacións escalables nos entornos dinámicos actuais, como nubes públicas, privadas e híbridas. Os exemplos inclúen contedores, mallas de servizos, microservizos, infraestrutura inmutable e API declarativas. Todas estas técnicas permiten que os sistemas pouco acoplados permanezan elásticos, manexables e altamente observables. A boa automatización permite aos enxeñeiros facer grandes cambios con frecuencia e con resultados previsibles sen que sexa unha tarefa. Todo isto está apoiado por unha pila de ferramentas coñecidas como Docker e Kubernetes.
Esta definición bastante complicada e ampla débese a que a zona tamén é bastante complexa. Por unha banda, argumentase que se deben engadir novos cambios a este sistema de forma sinxela. Por outra banda, descubrir como crear unha especie de ambiente en contenedores no que os servizos pouco acoplados vivan nunha infraestrutura definida por software e se entreguen alí mediante CI/CD continuos e construír prácticas DevOps arredor de todo isto, todo isto require máis que un come o can.
Que facer con todo
Cada un resolve estes problemas á súa maneira: por exemplo, podes publicar vacantes normais para romper o círculo vicioso. Podes descubrir o que significan palabras como DevOps e Cloud Native e usalas correctamente e ata o punto. Podes desenvolver en DevOps e demostrar os enfoques correctos co teu exemplo.
Estamos facendo unha conferencia , que ofrece a oportunidade de afondar nas cousas das que acabamos de falar. Existen varios grupos de informes para iso:
- Procesos e cultura;
- Enxeñaría de fiabilidade do sitio;
- Cloud Native;
Como elixir onde ir? Aquí hai un punto sutil. Por unha banda, DevOps trata da interacción, e queremos que asistades a presentacións de diferentes bloques. Por outra banda, se es un xestor de desenvolvemento que acudiu á conferencia para concentrarse nunha tarefa específica, ninguén o limita; obviamente, este será un bloque sobre procesos e cultura. Non esquezas que terás gravacións despois da conferencia (despois de cubrir o formulario de comentarios), para que sempre poidas ver presentacións menos importantes máis tarde.
Evidentemente, no propio congreso non se pode ir por tres vías á vez, polo que organizamos o programa de xeito que cada franxa horaria teña temas para todos os gustos.
Todo o que queda é entender que facer se es enxeñeiro de DevOps. Primeiro, tenta determinar o que realmente fas. Normalmente gústalles chamar a esta palabra:
- Desenvolvedores que traballan en infraestruturas. Os grupos de informes sobre SRE e Cloud Native son os máis axeitados para ti.
- Administradores de sistemas. Aquí é máis complicado. DevOops non é sobre a administración do sistema. Afortunadamente, hai un montón de excelentes conferencias, libros, artigos, vídeos en Internet, etc. sobre o tema da administración do sistema. Por outra banda, se estás interesado en desenvolverte en termos de comprender a cultura e os procesos, aprender sobre tecnoloxías na nube e os detalles da vida con Cloud Native, encantaríanos verte. Pensa nisto: estás facendo administración, e logo que vai facer? Para evitar atoparse de súpeto nunha situación desagradable, debes aprender agora.
Hai outra opción: persiste e segues afirmando que o es específicamente un enxeñeiro de DevOps e nada máis, sexa o que iso signifique. Entón temos que decepcionarte, DevOops non é unha conferencia para enxeñeiros de DevOps.
Desliza desde en Múnic
DevOops 2020 Moscova celebrarase do 29 ao 30 de abril en Moscova, as entradas xa están dispoñibles .
Alternativamente, podes ata o 8 de febreiro. Teña en conta que ao cubrir o formulario, debe seleccionar o público obxectivo que se beneficiará máis do seu informe (hai unha sorpresa enterrada dentro da lista).
Fonte: www.habr.com