{"id":38747,"date":"2019-10-31T22:25:42","date_gmt":"2019-10-31T19:25:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp\/"},"modified":"2019-10-31T22:25:42","modified_gmt":"2019-10-31T19:25:42","slug":"infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp","title":{"rendered":"Infraestructura como C\u00f3digo: c\u00f3mo resolver problemas con XP","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>\u00a1Hola, Habr! Antes me quejaba de la vida en la paradigma de Infrastructure as Code y no ofrec\u00eda nada para solucionar la situaci\u00f3n. Hoy he vuelto para contar qu\u00e9 enfoques y pr\u00e1cticas pueden ayudar a salir del abismo de la desesperaci\u00f3n y encaminar la situaci\u00f3n de manera correcta. <\/p>\n<p><img decoding=\"async\" alt=\"Infraestructura como C\u00f3digo: c\u00f3mo resolver problemas con XP\" src=\"\/wp-content\/uploads\/2019\/10\/e23fbf20980e731ae1cdb4719c97eb00.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nEn el art\u00edculo anterior <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzaio\/blog\/465137\/\">\u00abInfrastructure as Code: primer acercamiento\u00bb<\/a><\/noindex> Compart\u00eda mis impresiones sobre este \u00e1mbito, intentaba reflexionar sobre la situaci\u00f3n actual en este campo e incluso suger\u00eda que las pr\u00e1cticas est\u00e1ndar, conocidas por todos los desarrolladores, pueden ayudar. Podr\u00eda haber parecido que hab\u00eda muchas quejas sobre la vida, pero no hab\u00eda propuestas para salir de esta situaci\u00f3n. <\/p>\n<h2>Qui\u00e9nes somos, d\u00f3nde estamos y cu\u00e1les son nuestros problemas<\/h2>\n<p>\nActualmente estamos en el SRE Onboarding Team, que consiste en seis programadores y tres ingenieros de infraestructura. Todos estamos tratando de escribir Infrastructure as Code (IaC). Lo hacemos porque, en principio, sabemos escribir c\u00f3digo y en el pasado hemos sido desarrolladores de nivel \u00absuperior al promedio\u00bb. <\/p>\n<ul>\n<li>Tenemos un conjunto de ventajas: un cierto trasfondo, conocimientos de pr\u00e1cticas, habilidades para escribir c\u00f3digo y deseos de aprender cosas nuevas. <\/li>\n<li>Y hay una parte d\u00e9bil, que es un inconveniente: la falta de conocimientos en la materia de infraestructura. <\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">El stack de tecnolog\u00edas que utilizamos en nuestro IaC.<\/b><\/p>\n<ul>\n<li>Terraform para crear recursos.<\/li>\n<li>Packer para construir im\u00e1genes. Estas son im\u00e1genes de Windows y CentOS 7.<\/li>\n<li>Jsonnet, para hacer poderosas construcciones en drone.io, as\u00ed como para generar json de packer y nuestros m\u00f3dulos de Terraform.<\/li>\n<li>Azure.<\/li>\n<li>Ansible al preparar las im\u00e1genes.<\/li>\n<li>Python para servicios auxiliares, as\u00ed como scripts de aprovisionamiento.<\/li>\n<li>Y todo esto en VSCode con plugins compartidos entre los miembros del equipo.<\/li>\n<\/ul>\n<p>La conclusi\u00f3n de mi <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzaio\/blog\/465137\/\">del art\u00edculo anterior<\/a><\/noindex> fue la siguiente: intentaba inculcar (primordialmente a m\u00ed mismo) optimismo, quer\u00eda decir que probar\u00edamos los enfoques y pr\u00e1cticas que conocemos para enfrentar las dificultades y retos que existen en este campo. <\/p>\n<p>Actualmente estamos enfrentando los siguientes problemas de IaC:<\/p>\n<ul>\n<li>Imperfecciones de las herramientas y medios para desarrollar c\u00f3digo.<\/li>\n<li>Despliegue lento. La infraestructura es parte del mundo real, y este puede no ser r\u00e1pido.<\/li>\n<li>Falta de enfoques y pr\u00e1cticas.<\/li>\n<li>Somos nuevos y no sabemos mucho.<\/li>\n<\/ul>\n<p><\/p>\n<h2>La programaci\u00f3n extrema (XP) viene al rescate.<\/h2>\n<p>\nA todos los desarrolladores les resulta bien conocido el desarrollo extremo (XP) y las pr\u00e1cticas que lo respaldan. Muchos de nosotros hemos trabajado con este enfoque, y ha sido exitoso. Entonces, \u00bfpor qu\u00e9 no aprovechar los principios y pr\u00e1cticas establecidos all\u00ed para superar las dificultades de la infraestructura? Decidimos aplicar este enfoque y ver qu\u00e9 resulta de ello.<\/p>\n<p><b class=\"spoiler_title\">Evaluaci\u00f3n de la aplicabilidad del enfoque XP a su \u00e1mbito<\/b>A continuaci\u00f3n, presento una descripci\u00f3n del entorno para el cual XP es adecuado y c\u00f3mo se relaciona con nosotros: <\/p>\n<p>1. Requisitos de software que cambian din\u00e1micamente. Ten\u00edamos claro cu\u00e1l era el objetivo final. Pero se pueden variar los detalles. Nosotros mismos decidimos hacia d\u00f3nde debemos dirigirnos, por lo que los requisitos cambian peri\u00f3dicamente (principalmente por nuestra parte). Si consideramos a un equipo de SRE que realiza la automatizaci\u00f3n y tambi\u00e9n limita los requisitos y el alcance del trabajo, este punto encaja bien. <\/p>\n<p>2. Riesgos causados por proyectos de tiempo fijo que utilizan tecnolog\u00eda nueva. Pueden surgir riesgos al utilizar cosas que no conocemos. Y ese es nuestro caso al 100%. Todo nuestro proyecto implica el uso de tecnolog\u00edas con las que no est\u00e1bamos completamente familiarizados. En general, este es un problema constante, ya que en el campo de la infraestructura emergen continuamente muchas tecnolog\u00edas nuevas. <\/p>\n<p>3,4. Peque\u00f1o equipo de desarrollo extendido y coubicado. La tecnolog\u00eda que est\u00e1s utilizando permite pruebas autom\u00e1ticas unitarias y funcionales. Estos dos puntos no nos aplican del todo. En primer lugar, no somos un equipo coubicado; en segundo lugar, somos nueve personas, lo que puede considerarse un equipo grande. Sin embargo, seg\u00fan algunas definiciones, un 'gran' equipo se compone de 14 o m\u00e1s personas. <\/p>\n<p>Consideremos algunas pr\u00e1cticas de XP y c\u00f3mo influyen en la velocidad y calidad de la retroalimentaci\u00f3n.<\/p>\n<h4>El principio del ciclo de retroalimentaci\u00f3n en XP<\/h4>\n<p>\nEn mi entendimiento, la retroalimentaci\u00f3n es la respuesta a la pregunta de si estoy haciendo lo correcto, si vamos en la direcci\u00f3n adecuada. En XP existe un esquema maravilloso al respecto: el ciclo de retroalimentaci\u00f3n en el tiempo. La curiosidad radica en que, cuanto m\u00e1s bajo estamos, m\u00e1s r\u00e1pido podemos obtener el feedback necesario para responder a las preguntas relevantes. <\/p>\n<p><img decoding=\"async\" alt=\"Infraestructura como C\u00f3digo: c\u00f3mo resolver problemas con XP\" src=\"\/wp-content\/uploads\/2019\/10\/e381fb2d7937cbd1978fd6740e63e790.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEste es un tema bastante interesante para discutir, ya que en nuestra industria de TI es posible obtener r\u00e1pidamente retroalimentaci\u00f3n. Imag\u00ednese lo dif\u00edcil que es trabajar en un proyecto durante seis meses y solo luego enterarse de que se cometi\u00f3 un error al principio. Esto puede suceder tanto en el dise\u00f1o como en la construcci\u00f3n de sistemas complejos. <\/p>\n<p>En nuestro caso, IaC nos ayuda a obtener retroalimentaci\u00f3n. Hago un peque\u00f1o ajuste en el esquema anterior: el plan de lanzamiento no tiene un ciclo mensual, sino que ocurre varias veces al d\u00eda. A este ciclo est\u00e1n vinculadas ciertas pr\u00e1cticas que examinaremos en detalle.<\/p>\n<blockquote><p>Importante: la retroalimentaci\u00f3n puede ser la soluci\u00f3n para todos los problemas mencionados anteriormente. Junto con las pr\u00e1cticas de XP, puede sacarte del abismo de la desesperaci\u00f3n.<\/p><\/blockquote>\n<p><\/p>\n<h2>C\u00f3mo salir del abismo de la desesperaci\u00f3n: tres pr\u00e1cticas<\/h2>\n<p><\/p>\n<h4>Pruebas <\/h4>\n<p>\nLas pruebas se mencionan dos veces en el ciclo de retroalimentaci\u00f3n de XP. No es casualidad. Son extremadamente importantes para toda la t\u00e9cnica de programaci\u00f3n extrema. <\/p>\n<p>Se supone que tienes pruebas de unidad y pruebas de aceptaci\u00f3n. Algunas te dan retroalimentaci\u00f3n en unos minutos, otras en unos d\u00edas, por lo que se escriben m\u00e1s lentamente y se ejecutan con menos frecuencia. <\/p>\n<p>Hay una pir\u00e1mide de pruebas cl\u00e1sica que muestra que debe haber m\u00e1s de algunos tipos de pruebas. <\/p>\n<p><img decoding=\"async\" alt=\"Infraestructura como C\u00f3digo: c\u00f3mo resolver problemas con XP\" src=\"\/wp-content\/uploads\/2019\/10\/29f3217f11b67378c9c0c3f14fab9d61.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00bfC\u00f3mo se aplica este esquema a nuestro proyecto IaC? En realidad... no se aplica. <\/p>\n<ul>\n<li>No puede haber demasiadas pruebas unitarias, a pesar de que deber\u00edan ser muchas. O bien prueban algo de manera muy indirecta. De hecho, se puede decir que casi no las escribimos. Pero aqu\u00ed hay algunas aplicaciones para esas pruebas que s\u00ed hemos logrado hacer:\n<ol>\n<li>Pruebas de c\u00f3digo en jsonnet. Por ejemplo, nuestro pipeline de compilaci\u00f3n en drone, que es bastante complejo. El c\u00f3digo en jsonnet est\u00e1 bien cubierto por pruebas. <br \/>\n Usamos este <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/yugui\/jsonnetunit\">Unit testing framework for Jsonnet<\/a><\/noindex>. <\/li>\n<li> Pruebas en scripts que se ejecutan al iniciar el recurso. Los scripts est\u00e1n en Python, por lo que tambi\u00e9n se pueden escribir pruebas para ellos.<\/li>\n<\/ol>\n<\/li>\n<li>Potencialmente, es posible verificar la configuraci\u00f3n en las pruebas, pero no lo hacemos. Tambi\u00e9n hay una posibilidad de configurar la verificaci\u00f3n de las reglas de configuraci\u00f3n de recursos a trav\u00e9s de <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/wata727\/tflint\">tflint<\/a><\/noindex>. Sin embargo, simplemente para Terraform, las verificaciones son bastante b\u00e1sicas, aunque se han escrito muchos escenarios de verificaci\u00f3n para AWS. Y nosotros estamos en Azure, as\u00ed que eso nuevamente no se aplica.<\/li>\n<li>Pruebas de integraci\u00f3n de componentes: aqu\u00ed depende de c\u00f3mo las clasificas y d\u00f3nde las distribuyes. Pero, en principio, funcionan.\n<p>As\u00ed es como se ven las pruebas de integraci\u00f3n. <\/p>\n<p><img decoding=\"async\" alt=\"Infraestructura como C\u00f3digo: c\u00f3mo resolver problemas con XP\" src=\"\/wp-content\/uploads\/2019\/10\/b4771e9e5d329ffb2ba565ead7fdddfd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEste es un ejemplo durante la construcci\u00f3n de im\u00e1genes en Drone CI. Para llegar a ellas, debes esperar 30 minutos mientras se construye la imagen de Packer, luego otros 15 minutos para que pasen. \u00a1Pero existen! <\/p>\n<p><b class=\"spoiler_title\">Algoritmo de verificaci\u00f3n de im\u00e1genes<\/b> <\/p>\n<ol>\n<li>Primero, Packer debe preparar completamente la imagen.<\/li>\n<li>Junto a la prueba hay un terraform con estado local, que usamos para desplegar esta imagen. <\/li>\n<li>Al desplegar, se utiliza un peque\u00f1o m\u00f3dulo cercano para facilitar el trabajo con la imagen. <\/li>\n<li>Una vez que la VM se ha desplegado desde la imagen, se pueden iniciar las verificaciones. Principalmente, las pruebas se realizan en la m\u00e1quina. Se verifica c\u00f3mo funcionaron los scripts al iniciar y c\u00f3mo trabajan los demonios. Para ello, accedemos a la m\u00e1quina reci\u00e9n levantada a trav\u00e9s de ssh o winrm y comprobamos el estado de la configuraci\u00f3n o si los servicios se han levantado.<\/li>\n<\/ol>\n<p>\n <\/li>\n<li>La situaci\u00f3n es similar con las pruebas de integraci\u00f3n y en los m\u00f3dulos para terraform. Aqu\u00ed hay una tabla breve que explica las caracter\u00edsticas de tales pruebas.\n<p><img decoding=\"async\" alt=\"Infraestructura como C\u00f3digo: c\u00f3mo resolver problemas con XP\" src=\"\/wp-content\/uploads\/2019\/10\/e2624fb97831701e374a7e8e7fe39a16.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl feedback en el pipeline es de aproximadamente 40 minutos. Todo ocurre muy lentamente. Se puede utilizar para regresi\u00f3n, pero para nuevo desarrollo es completamente imposible. Si te preparas muy bien, preparas running, scripts, puedes reducirlo a 10 minutos. Pero aun as\u00ed, no son pruebas Unitarias que se pueden ejecutar 100 en 5 segundos. <\/li>\n<\/ul>\n<p>\nLa falta de pruebas Unitarias al construir im\u00e1genes o m\u00f3dulos de terraform obliga a delegar el trabajo en servicios separados, que simplemente se pueden invocar a trav\u00e9s de REST, o en scripts de Python.<\/p>\n<p>Por ejemplo, necesit\u00e1bamos hacer que al iniciar la m\u00e1quina virtual, se registrara en el servicio <noindex><a rel=\"nofollow\" href=\"https:\/\/www.scaleft.com\/\">ScaleFT<\/a><\/noindex>, y al destruir la VM, se eliminara a s\u00ed misma.<\/p>\n<p>Dado que ScaleFT es un servicio, nos vemos obligados a trabajar con \u00e9l a trav\u00e9s de la API. Se escribi\u00f3 un wrapper que se puede invocar y decir: \"Ve y elimina esto, esto y aquello\". Almacena todas las configuraciones y accesos necesarios. <\/p>\n<p>Sobre esto ya podemos escribir pruebas normales, ya que no se diferencia de un software com\u00fan: se moca una API, la llamas y observas qu\u00e9 ocurre. <\/p>\n<p><img decoding=\"async\" alt=\"Infraestructura como C\u00f3digo: c\u00f3mo resolver problemas con XP\" src=\"\/wp-content\/uploads\/2019\/10\/dc17aaa64038acb080669d31fe8ecfe0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<blockquote><p>Resultados de las pruebas: Las pruebas unitarias que deber\u00edan dar el SO en un minuto no lo hacen. Y tipos de pruebas m\u00e1s altas en la pir\u00e1mide dan efecto, pero solo cubren una parte de los problemas. <\/p><\/blockquote>\n<h4>Programaci\u00f3n en pareja<\/h4>\n<p>\nLas pruebas son, por supuesto, importantes. Se pueden escribir muchas y pueden ser de varios tipos. Funcionar\u00e1n en sus niveles y nos proporcionar\u00e1n retroalimentaci\u00f3n. Pero el problema con las malas pruebas unitarias, que proporcionan el sistema operativo m\u00e1s r\u00e1pido, persiste. A\u00fan as\u00ed, se desea un sistema operativo r\u00e1pido, con el que sea f\u00e1cil y agradable trabajar. Sin mencionar la calidad de la soluci\u00f3n obtenida. Afortunadamente, existen t\u00e9cnicas que permiten dar una retroalimentaci\u00f3n incluso m\u00e1s r\u00e1pida que las pruebas modulares. Eso es la programaci\u00f3n en pareja.<\/p>\n<p>Al escribir c\u00f3digo, se desea obtener retroalimentaci\u00f3n sobre su calidad lo m\u00e1s r\u00e1pido posible. S\u00ed, se puede escribir todo en una rama de caracter\u00edsticas (para no romper nada a nadie), hacer una solicitud de extracci\u00f3n en GitHub, asignar a alguien cuyo criterio tenga peso y esperar la respuesta. <\/p>\n<p>Pero la espera puede ser larga. Todos est\u00e1n ocupados, y la respuesta, incluso si llega, puede no ser de la m\u00e1s alta calidad. Supongamos que la respuesta lleg\u00f3 de inmediato, que el revisor entendi\u00f3 de inmediato toda la intenci\u00f3n, pero a\u00fan as\u00ed llega con retraso, a posteriori. Y se desea antes. Eso es precisamente lo que busca la programaci\u00f3n en pareja: obtener respuestas inmediatamente, en el momento de escribir.<\/p>\n<p>A continuaci\u00f3n, presento los estilos de programaci\u00f3n en pareja y su aplicabilidad en el trabajo sobre IaC: <\/p>\n<p><b>1. Cl\u00e1sico, experimentado + experimentado, cambio por temporizador.<\/b> Dos roles: conductor y navegador. Dos personas. Trabajan sobre el mismo c\u00f3digo y cambian de roles en un intervalo de tiempo previamente determinado. <\/p>\n<p>Consideremos la compatibilidad de nuestros problemas con el estilo: <\/p>\n<ul>\n<li>Problema: imperfecci\u00f3n de las herramientas y medios para el desarrollo de c\u00f3digo. <br \/>\nInfluencia negativa: desarrollo m\u00e1s lento, nos ralentizamos, se rompe el ritmo del trabajo.<br \/>\n C\u00f3mo lo enfrentamos: aplicamos diferentes herramientas, IDE compartido y tambi\u00e9n aprendemos atajos.<\/li>\n<li> Problema: despliegue lento. <br \/>\nInfluencia negativa: aumenta el tiempo necesario para crear una parte funcional del c\u00f3digo. Nos aburrimos mientras esperamos, nuestras manos se ven atra\u00eddas a hacer algo m\u00e1s mientras esperamos. <br \/>\nC\u00f3mo lo enfrentamos: no lo hemos resuelto.<\/li>\n<li> Problema: falta de enfoques y pr\u00e1cticas. <br \/>\nInfluencia negativa: no hay conocimiento sobre lo que se hace bien y lo que se hace mal. Alarga la obtenci\u00f3n de retroalimentaci\u00f3n. <br \/>\nC\u00f3mo lo enfrentamos: el intercambio de opiniones y pr\u00e1cticas en el trabajo en pareja casi resuelve el problema.<\/li>\n<\/ul>\n<p>\nEl principal problema al aplicar este estilo en IaC es el ritmo irregular de trabajo. En el desarrollo de software tradicional, el avance es mucho m\u00e1s uniforme. Puedes gastar cinco minutos y escribir N, diez minutos y escribir 2N, quince minutos - 3N. Aqu\u00ed, en cambio, puedes gastar cinco minutos y escribir N, y luego dedicar otros 30 minutos y escribir una d\u00e9cima parte de N. Aqu\u00ed no sabes nada, te atascas, no avanzas. El desentramado lleva tiempo y distrae de la programaci\u00f3n en s\u00ed. <\/p>\n<blockquote><p>Conclusi\u00f3n: en su forma pura no nos es adecuado.<\/p><\/blockquote>\n<p><b>2. Ping-pong. Este enfoque supone que un participante escribe una prueba y el otro realiza la implementaci\u00f3n.<\/b> Teniendo en cuenta que con las pruebas unitarias todo es complicado y es necesario escribir una prueba de integraci\u00f3n que consume mucho tiempo, toda la ligereza del ping-pong desaparece. <\/p>\n<p>Puedo decir que hemos probado la divisi\u00f3n de responsabilidades en el dise\u00f1o del escenario de prueba y la implementaci\u00f3n del c\u00f3digo para ello. Un participante ideaba el escenario, en esta parte del trabajo era responsable y ten\u00eda la \u00faltima palabra. El otro se encargaba de la implementaci\u00f3n. Esto result\u00f3 ser efectivo. La calidad del escenario mejora con este enfoque. <\/p>\n<blockquote><p>Conclusi\u00f3n: lamentablemente, el ritmo de trabajo no permite utilizar el ping-pong como pr\u00e1ctica de programaci\u00f3n en pareja en IaC.<\/p><\/blockquote>\n<p>\n <b>3. Strong Style.<\/b> <noindex><a rel=\"nofollow\" href=\"http:\/\/llewellynfalco.blogspot.com\/2014\/06\/llewellyns-strong-style-pairing.html\">Pr\u00e1ctica compleja.<\/a><\/noindex>La idea es que un participante se convierte en el navegador directivo, mientras que el segundo asume el rol de conductor ejecutor. En este caso, el derecho a tomar decisiones corresponde exclusivamente al navegador. El conductor solo escribe y puede influir en lo que sucede con sus palabras. Los roles no cambian durante un largo tiempo. <\/p>\n<p>Es muy adecuado para la ense\u00f1anza, pero requiere habilidades blandas fuertes. Aqu\u00ed es donde nos encontramos con dificultades. La t\u00e9cnica result\u00f3 ser complicada. Y no se trata solo de la infraestructura. <\/p>\n<blockquote><p>Conclusi\u00f3n: potencialmente puede aplicarse, no nos rendimos en el intento.<\/p><\/blockquote>\n<p>\n<b>4. Mobbing, swarming y todos los estilos conocidos, pero no mencionados aqu\u00ed.<\/b> no se consideran, ya que no los hemos probado y no podemos hablar de ellos en el contexto de nuestro trabajo.<\/p>\n<blockquote><p>Resumen general sobre el uso de la programaci\u00f3n en pareja:<\/p>\n<ul>\n<li>Tenemos un ritmo de trabajo desigual que interfiere.<\/li>\n<li>Hemos topado con habilidades blandas insuficientemente buenas. Y el \u00e1rea tem\u00e1tica no facilita la superaci\u00f3n de estas deficiencias.<\/li>\n<li>Pruebas largas y problemas con las herramientas hacen que el desarrollo en pareja sea engorroso.<\/li>\n<\/ul>\n<\/blockquote>\n<p><b>5. A pesar de esto, tambi\u00e9n hubo \u00e9xitos. Inventamos nuestro propio m\u00e9todo 'Convergencia - Divergencia'.<\/b> Describir\u00e9 brevemente c\u00f3mo funciona. <\/p>\n<p>Tenemos socios constantes por algunos d\u00edas (menos de una semana). Realizamos una tarea en conjunto. Pasamos un tiempo juntos: uno escribe, el otro observa, como en un equipo de soporte. Luego nos separamos por un tiempo, cada uno realiza algunas tareas independientes, despu\u00e9s volvemos a reunirnos, sincronizamos r\u00e1pidamente, hacemos algo juntos y de nuevo nos separamos. <\/p>\n<h4>Planificaci\u00f3n y comunicaci\u00f3n<\/h4>\n<p>\nEl \u00faltimo bloque de pr\u00e1cticas, a trav\u00e9s del cual se resuelven los problemas del sistema operativo, es la organizaci\u00f3n del trabajo con las propias tareas. Esto incluye el intercambio de experiencias que est\u00e1 fuera del trabajo en pareja. Consideremos tres pr\u00e1cticas:<\/p>\n<p><b>1. Tareas a trav\u00e9s del \u00e1rbol de objetivos.<\/b> La gesti\u00f3n general del proyecto la organizamos a trav\u00e9s de un \u00e1rbol que se adentra infinitamente en el futuro. T\u00e9cnicamente se lleva a cabo en Miro. Hay una tarea, que es un objetivo intermedio. De ella surgen objetivos m\u00e1s peque\u00f1os o grupos de tareas. Desde ellos, se generan las propias tareas. Todas las tareas se crean y gestionan en esta pizarra. <\/p>\n<p><img decoding=\"async\" alt=\"Infraestructura como C\u00f3digo: c\u00f3mo resolver problemas con XP\" src=\"\/wp-content\/uploads\/2019\/10\/fe601e959f0055de4f7f4c39ae713c31.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEste esquema tambi\u00e9n proporciona retroalimentaci\u00f3n, que ocurre una vez al d\u00eda, cuando nos sincronizamos en las reuniones. Tener un plan com\u00fan ante todos, estructurado y completamente abierto, permite que cada uno est\u00e9 al tanto de lo que est\u00e1 sucediendo y de cu\u00e1nto hemos avanzado en el progreso. <\/p>\n<p>Ventajas de la visi\u00f3n visual de las tareas:<\/p>\n<ul>\n<li>Causalidad. Cada tarea lleva a alg\u00fan objetivo global. Las tareas se agrupan por objetivos m\u00e1s peque\u00f1os. El dominio de la infraestructura en s\u00ed es bastante t\u00e9cnico. No siempre es evidente cu\u00e1l es la influencia espec\u00edfica que, por ejemplo, tiene la redacci\u00f3n de un manual de migraci\u00f3n a otro nginx sobre el negocio. Tener una tarjeta de objetivo junto a ello lo hace m\u00e1s comprensible.<br \/>\n <img decoding=\"async\" alt=\"Infraestructura como C\u00f3digo: c\u00f3mo resolver problemas con XP\" src=\"\/wp-content\/uploads\/2019\/10\/fc4da9d277f7dc186a5710cf2be4419c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n La causalidad es una propiedad importante de las tareas. Responde directamente a la pregunta: '\u00bfEstoy haciendo lo correcto?' <\/li>\n<li>Paralelismo. Somos nueve personas y es f\u00edsicamente imposible abordar una tarea todos a la vez. Las tareas de un mismo \u00e1mbito tampoco siempre son suficientes. Nos vemos obligados a paralelizar el trabajo entre peque\u00f1os grupos de trabajo. En este contexto, los grupos se dedican un tiempo a su tarea y pueden ser reforzados por alguien m\u00e1s. A veces, algunas personas de este grupo se retiran. Alguien puede irse de vacaciones, otro puede estar preparando una presentaci\u00f3n para la conferencia DevOps conf, o alguien m\u00e1s puede estar escribiendo un art\u00edculo para Habr. Es muy importante saber qu\u00e9 objetivos y tareas se pueden realizar en paralelo. <\/li>\n<\/ul>\n<p>\n<b>2. L\u00edderes alternos de las reuniones matutinas.<\/b> En los stand-ups ha surgido un problema: muchas tareas se realizan en paralelo. A veces, las tareas est\u00e1n d\u00e9bilmente conectadas y no hay entendimiento sobre qui\u00e9n est\u00e1 haciendo qu\u00e9. La opini\u00f3n de otro miembro del equipo es muy importante. Es informaci\u00f3n adicional que puede cambiar el rumbo de la soluci\u00f3n de la tarea. Claro que, normalmente, hay alguien contigo en pareja, pero la consulta y los consejos siempre son bienvenidos. <\/p>\n<p>Para mejorar esta situaci\u00f3n, aplicamos la t\u00e9cnica de \"Cambio de l\u00edder del stand-up\". Ahora rotan seg\u00fan una lista determinada, y esto tiene su efecto. Cuando te llega el turno, te ves obligado a sumergirte y entender qu\u00e9 est\u00e1 pasando, para llevar bien la reuni\u00f3n scrum. <\/p>\n<p><img decoding=\"async\" alt=\"Infraestructura como C\u00f3digo: c\u00f3mo resolver problemas con XP\" src=\"\/wp-content\/uploads\/2019\/10\/622973a654ecd3e27a7a366596814ffc.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>3. Demos internas.<\/b> La ayuda en la resoluci\u00f3n de tareas a trav\u00e9s de programaci\u00f3n en pareja, la visualizaci\u00f3n en el \u00e1rbol de tareas y la asistencia en las reuniones scrum por la ma\u00f1ana es buena, pero no es perfecta. En pareja, est\u00e1s limitado solo por tus conocimientos. El \u00e1rbol de tareas ayuda a entender globalmente qui\u00e9n hace qu\u00e9. Y el l\u00edder y los colegas en la reuni\u00f3n matutina no profundizar\u00e1n en tus problemas. Seguramente podr\u00e1n pasar por alto algo. <\/p>\n<p>La soluci\u00f3n fue encontrar una forma de mostrar el trabajo realizado entre nosotros y discutirlo posteriormente. Nos reunimos una vez a la semana durante una hora y mostramos los detalles de las soluciones a las tareas que hicimos en la \u00faltima semana. <\/p>\n<p>Durante la demostraci\u00f3n, hay que dar detalles de la tarea y mostrar su funcionamiento. <\/p>\n<p><b class=\"spoiler_title\">El informe se puede realizar seg\u00fan una lista de verificaci\u00f3n.<\/b>1. Establece el contexto. \u00bfDe d\u00f3nde surgi\u00f3 la tarea, por qu\u00e9 era necesaria?<\/p>\n<p>2. \u00bfC\u00f3mo se resolvi\u00f3 la tarea anteriormente? Por ejemplo, \u00bfse requer\u00edan m\u00faltiples clics con un mouse, o era imposible hacer algo en absoluto?<\/p>\n<p>3. \u00bfC\u00f3mo mejoramos esto? Por ejemplo: \"Miren, ahora hay un peque\u00f1o script, aqu\u00ed est\u00e1 el readme\".<\/p>\n<p>4. Muestre c\u00f3mo funciona. Preferiblemente realice alg\u00fan escenario de usuario. Quiero X, hago Y, veo Y (o Z). Por ejemplo, despliego NGINX, consulto la URL, obtengo 200 OK. Si la acci\u00f3n es larga, prep\u00e1rela con antelaci\u00f3n para luego mostrarla. Preferiblemente, aproximadamente una hora antes de la demo, no rompa nada importante, si es fr\u00e1gil.<\/p>\n<p>5. Explique qu\u00e9 tan exitosamente se ha abordado el problema, qu\u00e9 dificultades persisten, qu\u00e9 no se ha completado, qu\u00e9 mejoras son posibles en el futuro. Por ejemplo, ahora hay CLI, despu\u00e9s habr\u00e1 una automatizaci\u00f3n completa en CI.<\/p>\n<p>Es deseable que cada orador se limite a 5-10 minutos. Si su intervenci\u00f3n es claramente importante y tomar\u00e1 m\u00e1s tiempo, coordine esto con anticipaci\u00f3n en el canal sre-takeover.<\/p>\n<p>Despu\u00e9s de la parte presencial, es obligatorio un debate en el hilo. Aqu\u00ed es donde aparece la retroalimentaci\u00f3n necesaria sobre las tareas. <\/p>\n<p><img decoding=\"async\" alt=\"Infraestructura como C\u00f3digo: c\u00f3mo resolver problemas con XP\" src=\"\/wp-content\/uploads\/2019\/10\/77da888d24b52c7eea7e65d2400e152c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nAl final, se realiza una encuesta para evaluar la utilidad de lo sucedido. Esta es ya una retroalimentaci\u00f3n sobre el contenido de la presentaci\u00f3n y la importancia de la tarea.<\/p>\n<p><img decoding=\"async\" alt=\"Infraestructura como C\u00f3digo: c\u00f3mo resolver problemas con XP\" src=\"\/wp-content\/uploads\/2019\/10\/7642cd87050171cc4a6bf278329dd283.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Conclusiones largas y qu\u00e9 sigue<\/h2>\n<p>\nPuede parecer que el tono del art\u00edculo es algo pesimista. No es as\u00ed. Dos niveles b\u00e1sicos de obtenci\u00f3n de retroalimentaci\u00f3n, a saber, pruebas y programaci\u00f3n en pareja, funcionan. No de manera tan perfecta como en el desarrollo tradicional, pero hay un efecto positivo. <\/p>\n<p>Las pruebas, en su forma actual, proporcionan solo una cobertura parcial del c\u00f3digo. Muchas funciones de configuraci\u00f3n quedan sin probar. Su impacto en el trabajo inmediato al escribir c\u00f3digo es bajo. Sin embargo, hay efecto de las pruebas de integraci\u00f3n, y son precisamente ellas las que permiten realizar refactorizaciones sin miedo. Este es un gran logro. Adem\u00e1s, con el cambio de enfoque hacia el desarrollo en lenguajes de alto nivel (tenemos python, go) el problema desaparece. Y para el 'pegamento' se requieren muchas verificaciones y no es necesario, solo es suficiente una integraci\u00f3n general.<\/p>\n<p>El trabajo en pareja depende m\u00e1s de las personas concretas. Est\u00e1 el factor de la tarea y nuestras habilidades blandas. Con algunos resulta muy bien, con otros peor. Definitivamente hay beneficios. Es claro que incluso con un cumplimiento deficiente de las reglas del trabajo en pareja, el simple hecho de realizar tareas conjuntamente influencia positivamente la calidad del resultado. Personalmente, me resulta m\u00e1s f\u00e1cil y agradable trabajar en pareja.<\/p>\n<p>M\u00e9todos m\u00e1s de alto nivel para influir en el sistema operativo: la planificaci\u00f3n y el trabajo con tareas ciertamente producen efectos: un intercambio de conocimientos de calidad y una mejora en la calidad del desarrollo. <\/p>\n<h4>Conclusiones breves en una l\u00ednea <\/h4>\n<p><\/p>\n<ul>\n<li>Las pr\u00e1cticas de XP funcionan en IaC, pero con menor eficiencia.<\/li>\n<li>Potencia lo que funciona.<\/li>\n<li>Inventa tus propios mecanismos y pr\u00e1cticas compensatorias.<\/li>\n<\/ul>\n<p>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzaio\/blog\/470620\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0436\u0430\u043b\u043e\u0432\u0430\u043b\u0441\u044f \u043d\u0430 \u0436\u0438\u0437\u043d\u044c \u0432 \u043f\u0430\u0440\u0430\u0434\u0438\u0433\u043c\u0435 Infrastructure as code \u0438 \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u043b \u0434\u043b\u044f \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0441\u043b\u043e\u0436\u0438\u0432\u0448\u0435\u0439\u0441\u044f \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u0438. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0432\u0435\u0440\u043d\u0443\u043b\u0441\u044f, \u0447\u0442\u043e\u0431\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c, \u043a\u0430\u043a\u0438\u0435 \u043f\u043e\u0434\u0445\u043e\u0434\u044b \u0438 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 \u043f\u043e\u043c\u043e\u0433\u0443\u0442 \u0432\u044b\u0440\u0432\u0430\u0442\u044c\u0441\u044f \u0438\u0437 \u0431\u0435\u0437\u0434\u043d\u044b \u043e\u0442\u0447\u0430\u044f\u043d\u0438\u044f \u0438 \u0432\u044b\u0440\u0443\u043b\u0438\u0442\u044c \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u044e \u0432 \u043f\u0440\u0430\u0432\u0438\u043b\u044c\u043d\u043e\u0435 \u0440\u0443\u0441\u043b\u043e. \u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u00abInfrastructure as code: \u043f\u0435\u0440\u0432\u043e\u0435 \u0437\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e\u00bb \u044f \u0434\u0435\u043b\u0438\u043b\u0441\u044f \u0441\u0432\u043e\u0438\u043c \u0432\u043f\u0435\u0447\u0430\u0442\u043b\u0435\u043d\u0438\u0435\u043c \u043e\u0442 \u044d\u0442\u043e\u0439 \u0441\u0444\u0435\u0440\u044b, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29066,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38747","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0436\u0430\u043b\u043e\u0432\u0430\u043b\u0441\u044f \u043d\u0430 \u0436\u0438\u0437\u043d\u044c \u0432 \u043f\u0430\u0440\u0430\u0434\u0438\u0433\u043c\u0435 Infrastructure as code \u0438 \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u043b \u0434\u043b\u044f \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0441\u043b\u043e\u0436\u0438\u0432\u0448\u0435\u0439\u0441\u044f \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u0438.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Infrastructure as Code: \u043a\u0430\u043a \u043f\u043e\u0431\u043e\u0440\u043e\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e XP | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0436\u0430\u043b\u043e\u0432\u0430\u043b\u0441\u044f \u043d\u0430 \u0436\u0438\u0437\u043d\u044c \u0432 \u043f\u0430\u0440\u0430\u0434\u0438\u0433\u043c\u0435 Infrastructure as code \u0438 \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u043b \u0434\u043b\u044f \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0441\u043b\u043e\u0436\u0438\u0432\u0448\u0435\u0439\u0441\u044f \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u0438.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:25:42+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:25:42+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Infrastructure as Code: c\u00f3mo superar problemas con XP | ProHoster","description":"\u00a1Hola, Habr! Antes me quejaba de la vida en la paradigma de Infrastructure as Code y no ofrec\u00eda soluciones para la situaci\u00f3n.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Infrastructure as Code: \u043a\u0430\u043a \u043f\u043e\u0431\u043e\u0440\u043e\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e XP | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0436\u0430\u043b\u043e\u0432\u0430\u043b\u0441\u044f \u043d\u0430 \u0436\u0438\u0437\u043d\u044c \u0432 \u043f\u0430\u0440\u0430\u0434\u0438\u0433\u043c\u0435 Infrastructure as code \u0438 \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u043b \u0434\u043b\u044f \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0441\u043b\u043e\u0436\u0438\u0432\u0448\u0435\u0439\u0441\u044f \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u0438.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:25:42+00:00","article:modified_time":"2019-10-31T19:25:42+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38747","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 23:16:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:04:30","updated":"2026-01-23 23:16:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/38747","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=38747"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/38747\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/29066"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=38747"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=38747"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=38747"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}