{"id":53925,"date":"2019-12-13T00:00:00","date_gmt":"2019-12-12T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat"},"modified":"2020-02-18T14:01:52","modified_gmt":"2020-02-18T11:01:52","slug":"devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat","title":{"rendered":"No existen ingenieros DevOps. \u00bfQui\u00e9nes son entonces y qu\u00e9 hacer al respecto?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"No<\/p>\n

<\/p>\n

\u00daltimamente, 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\u00e9s viene una lista aleatoria de requisitos, muchos de los cuales claramente est\u00e1n copiados de una oferta de trabajo para un administrador de sistemas.<\/p>\n

<\/p>\n

En este post, quiero hablar un poco sobre c\u00f3mo hemos llegado a esta situaci\u00f3n, qu\u00e9 es realmente DevOps y qu\u00e9 debemos hacer con ello.<\/p>\n

<\/p>\n

Se puede criticar de muchas maneras estas ofertas de trabajo, pero el hecho es que hay muchas, y as\u00ed est\u00e1 estructurado el mercado en este momento. Organizamos una conferencia de DevOps y declaramos abiertamente: \u00abDevOops<\/a><\/noindex> \u2014 no es para ingenieros de DevOps\u00bb. Esto puede parecer extra\u00f1o y absurdo para muchos: \u00bfpor qu\u00e9 personas que organizan un evento puramente comercial van en contra del mercado? Ahora lo explicaremos.<\/p>\n

<\/a><\/noindex><\/p>\n

Sobre la cultura y procesos<\/h2>\n

<\/p>\n

Empecemos por el hecho de que DevOps no es una disciplina de ingenier\u00eda. Todo comenz\u00f3 con que la divisi\u00f3n de roles hist\u00f3ricamente 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\u00e1 lleno de errores. Cuando a los administradores no les importa c\u00f3mo y por qu\u00e9 se escribi\u00f3 el software, el soporte se convierte en un infierno. <\/p>\n

<\/p>\n

Por ejemplo, la descripci\u00f3n de la diferencia entre el enfoque de administrador de sistemas y el enfoque de SRE hacia la gesti\u00f3n de servicios se encuentra al inicio del famoso libro de SRE de Google.<\/a><\/noindex>Se han realizado interesantes investigaciones en el marco del informe DORA<\/a><\/noindex> \u2014 es evidente que los mejores desarrolladores logran desplegar nuevas modificaciones en producci\u00f3n m\u00e1s r\u00e1pido que una vez por hora. Ellos tampoco prueban m\u00e1s del 10% a mano (se puede ver en el DORA del a\u00f1o pasado<\/a><\/noindex>). \u00bfC\u00f3mo lo logran? 'Excel o muere' \u2013 dice uno de los encabezados del informe. Para un an\u00e1lisis detallado de esta estad\u00edstica en t\u00e9rminos de pruebas, se puede consultar la keynote de Baruch Sadogursky \u00abTenemos DevOps. Despidamos a todos los testers\u00bb<\/a><\/noindex> en otra de nuestras conferencias, Heisenbug.<\/p>\n

<\/p>\n

\u00abCuando en los compa\u00f1eros no hay acuerdo,
\nSu asunto no prosperar\u00e1,
\nY de ello no saldr\u00e1 nada, solo sufrimiento.
\nUna vez, un Cisne, un Cangrejo y una Sombra\u2026\u00bb<\/p><\/blockquote>\n

\u00bfQu\u00e9 opinas, cu\u00e1ntos desarrolladores web realmente comprenden en qu\u00e9 condiciones funcionan sus aplicaciones en producci\u00f3n? \u00bfCu\u00e1ntos de ellos se acercar\u00e1n a los administradores y tratar\u00e1n de entender qu\u00e9 suceder\u00e1 si la base de datos falla? \u00bfY qui\u00e9n de ellos ir\u00e1 a los testers y pedir\u00e1 aprender a escribir pruebas correctamente? Adem\u00e1s, hay tambi\u00e9n expertos en seguridad, gerentes de productos y un mont\u00f3n de otras personas.<\/p>\n

<\/p>\n

La idea general de DevOps es establecer la comunicaci\u00f3n entre roles y departamentos. Esto se logra principalmente no a trav\u00e9s de alg\u00fan software ingeniosamente configurado, sino a trav\u00e9s de una pr\u00e1ctica de comunicaci\u00f3n. DevOps se trata de cultura, pr\u00e1ctica, metodolog\u00eda y procesos. No existe ninguna especialidad de ingenier\u00eda que responda a estas preguntas.<\/p>\n

<\/p>\n

C\u00edrculo vicioso<\/h2>\n

<\/p>\n

\u00bfDe d\u00f3nde proviene entonces la disciplina de \u00abingenier\u00eda DevOps\u00bb? \u00a1Tenemos una versi\u00f3n! Las ideas de DevOps resultaron ser tan buenas que se convirtieron en v\u00edctimas de su propio \u00e9xito. Alrededor de este tema comenzaron a aparecer reclutadores dudosos y comerciantes de personas, que tienen su propia atm\u00f3sfera.<\/p>\n

<\/p>\n

Imagina: ayer estabas en Khimki haciendo shawarma, y hoy ya eres una persona importante, un reclutador senior. Hay todo un proceso de b\u00fasqueda y selecci\u00f3n de candidatos, no es f\u00e1cil, hay que entenderlo. Supongamos que el jefe del departamento dice: encuentra un especialista en X. A\u00f1adimos la palabra \u00abingeniero\u00bb a X, y ya est\u00e1. \u00bfNecesitas 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\u00edtulo, tambi\u00e9n hay que incluir alg\u00fan texto. Lo m\u00e1s f\u00e1cil es incluir una lista de palabras clave de Google, seg\u00fan la imaginaci\u00f3n de cada uno. DevOps consta de dos palabras: \u00abDev\u00bb y \u00abOps\u00bb, significa que hay que juntar palabras clave relacionadas con desarrolladores y administradores, todo en un mismo lugar. As\u00ed es como aparecen ofertas de trabajo que piden dominar 42 lenguajes de programaci\u00f3n y 20 a\u00f1os de experiencia usando Kubernetes y Swarm al mismo tiempo. Ese es el esquema de trabajo.<\/p>\n

<\/p>\n

As\u00ed en la mente de las personas se ha arraigado la imagen absurda e implacable de un superh\u00e9roe \u00abDevOps\u00bb, que configurar\u00e1 el despliegue para todos en Jenkins, y la felicidad llegar\u00e1. Oh, si tan solo fuera tan simple. \u00abY tambi\u00e9n podemos cazar administradores de sistemas\u00bb, piensa el reclutador, \u00abes una palabra de moda, las mismas palabras clave, deben picar\u00bb.<\/p>\n

<\/p>\n

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\u00e1s, llam\u00e1ndose \"devops\". As\u00ed como configurabas servidores por SSH uno a uno, seguir\u00e1s configurando, pero ahora esto supuestamente es una pr\u00e1ctica devops. Es un fen\u00f3meno complejo, parcialmente relacionado con la subestimaci\u00f3n de los administradores cl\u00e1sicos y con el hype alrededor de DevOps, pero en general \u2014 lo que pas\u00f3, pas\u00f3.<\/p>\n

<\/p>\n

As\u00ed que tenemos demanda y oferta. Un c\u00edrculo vicioso que se retroalimenta. Con esto es con lo que luchamos (incluyendo la creaci\u00f3n de la conferencia DevOops).<\/p>\n

<\/p>\n

Sin duda, adem\u00e1s de los administradores de sistemas que se han renombrado como \"devops\", hay otros participantes \u2014 por ejemplo, profesionales de SRE o desarrolladores de Infrastructure-as-Code.<\/p>\n

<\/p>\n

\u00bfQu\u00e9 hacen las personas en DevOps (realmente)?<\/h2>\n

<\/p>\n

As\u00ed que, deseas avanzar en el estudio y aplicaci\u00f3n de las pr\u00e1cticas de DevOps. Pero, \u00bfc\u00f3mo hacerlo, hacia qu\u00e9 direcci\u00f3n mirar? Obviamente, no deber\u00edas guiarte ciegamente por las palabras clave populares.<\/p>\n

<\/p>\n

Si hay trabajo, alguien debe hacerlo. Ya hemos aclarado que no son \"ingenieros devops\", entonces, \u00bfqui\u00e9n? Parece que ser\u00eda m\u00e1s correcto formularlo no en t\u00e9rminos de puestos, sino en t\u00e9rminos de direcciones de trabajo espec\u00edficas.<\/p>\n

<\/p>\n

En primer lugar, puedes ocuparte del coraz\u00f3n de DevOps \u2014 los procesos y la cultura. La cultura es un asunto que no se logra r\u00e1pidamente y no es f\u00e1cil, y aunque tradicionalmente es responsabilidad de los l\u00edderes, de una forma u otra todos participan, desde programadores hasta administradores. Hace un par de meses, Tim Lister dijo en una entrevista<\/a><\/noindex>:<\/p>\n

<\/p>\n

\"La cultura se establece a partir de los valores fundamentales de la organizaci\u00f3n. Normalmente, la gente no se da cuenta, pero nosotros, trabajando en consultor\u00eda durante muchos a\u00f1os, hemos aprendido a notarlo. Entras en una empresa y literalmente a los pocos minutos comienzas a sentir lo que est\u00e1 sucediendo. Lo llamamos 'aroma'. A veces ese aroma es realmente bueno. Otras veces causa n\u00e1useas. (\u2026) No puedes cambiar la cultura antes de que se reconozcan los valores y creencias que est\u00e1n detr\u00e1s de acciones concretas. El comportamiento es f\u00e1cil de observar, pero encontrar creencias es dif\u00edcil. DevOps es un excelente ejemplo de c\u00f3mo todo se vuelve m\u00e1s complicado y complejo.\"<\/p><\/blockquote>\n

Tambi\u00e9n hay una parte t\u00e9cnica en la cuesti\u00f3n, por supuesto. Si tu nuevo c\u00f3digo llega para prueba en un mes, pero solo se libera un a\u00f1o despu\u00e9s, y no es f\u00edsicamente posible acelerar todo esto, es probable que no llegues a las buenas pr\u00e1cticas. Las buenas pr\u00e1cticas 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\u00e9s concretas estos principios en soluciones t\u00e9cnicas espec\u00edficas. Adem\u00e1s, SRE es una metodolog\u00eda muy compleja que no habla solo de c\u00f3mo configurar Jenkins, sino de cinco principios fundamentales:<\/p>\n

<\/p>\n