{"id":33725,"date":"2019-10-31T21:54:21","date_gmt":"2019-10-31T18:54:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/chto-takoe-devops\/"},"modified":"2019-10-31T21:54:21","modified_gmt":"2019-10-31T18:54:21","slug":"chto-takoe-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/chto-takoe-devops","title":{"rendered":"\u00bfQu\u00e9 es DevOps?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La definici\u00f3n de DevOps es muy compleja, por lo que cada vez es necesario iniciar la discusi\u00f3n sobre el tema desde cero. Solo en Habr hay mil publicaciones al respecto. Pero si est\u00e1s leyendo esto, seguramente sabes qu\u00e9 es DevOps. Porque yo no lo s\u00e9. Hola, me llamo Alexander Titov (@osminog<\/a><\/noindex><\/b>), y simplemente hablaremos sobre DevOps y compartir\u00e9 mi experiencia.<\/p>\n

\"\u00bfQu\u00e9
\n
\nHe estado pensando mucho en c\u00f3mo hacer que mi relato sea \u00fatil, por lo que aqu\u00ed habr\u00e1 muchas preguntas: aquellas que yo mismo me hago y las que pregunto a los clientes de nuestra empresa. Al responder estas preguntas, la comprensi\u00f3n mejora. Te contar\u00e9 por qu\u00e9 DevOps es necesario desde mi perspectiva, qu\u00e9 es, nuevamente desde mi posici\u00f3n, y c\u00f3mo entender que te est\u00e1s moviendo hacia DevOps, de nuevo desde mi punto de vista. El \u00faltimo punto ser\u00e1 a trav\u00e9s de preguntas. Al responderlas a ti mismo, podr\u00e1s entender si tu empresa se est\u00e1 moviendo hacia DevOps o si hay problemas.
\n<\/a><\/noindex>
\n

\r\n \"Reproducir\r\n
<\/div>\r\n <\/div><\/center>
\nDurante un tiempo, navegu\u00e9 en las aguas de fusiones y adquisiciones. Primero trabaj\u00e9 en una peque\u00f1a startup llamada Qik, luego fue comprada por una empresa un poco m\u00e1s grande, Skype, que a su vez fue adquirida por una empresa a\u00fan m\u00e1s grande, Microsoft. En ese momento, me di cuenta de c\u00f3mo se transforma la percepci\u00f3n de DevOps en diferentes empresas seg\u00fan su tama\u00f1o. Despu\u00e9s de eso, me interes\u00f3 observar DevOps desde la perspectiva del mercado, y con mis colegas organizamos la empresa Expres 42. Ya llevamos 6 a\u00f1os navegando en este mercado.<\/p>\n

Adem\u00e1s de todo, soy uno de los organizadores de la comunidad DevOps Moscow y organizador de DevOps-Days 2017, pero no organic\u00e9 el 2018. Expres 42 trabaja con muchas empresas. Estamos promoviendo DevOps all\u00ed, observando c\u00f3mo ocurre, sacando conclusiones, analizando, compartiendo nuestros hallazgos con todos, y formando a las personas en pr\u00e1cticas de DevOps. En resumen, cultivamos la experiencia y la experticia en este sentido.<\/p>\n

\u00bfPor qu\u00e9 DevOps?<\/h2>\n

\nLa primera pregunta que persigue a todos y siempre es: \u00bfpor qu\u00e9? Muchos piensan que DevOps es solo automatizaci\u00f3n o algo similar que ya estaba en cada empresa.<\/p>\n

\u2014 Ten\u00edamos Integraci\u00f3n Continua \u2014 eso significa que ya ten\u00edamos DevOps, \u00bfy para qu\u00e9 necesitamos todo este asunto? All\u00ed afuera se divierten, \u00a1y aqu\u00ed nos impiden trabajar!<\/i><\/p>\n

Despu\u00e9s de 9 a\u00f1os de desarrollo de la comunidad y la metodolog\u00eda, ya est\u00e1 claro que no son solo destellos de marketing, pero a\u00fan no est\u00e1 del todo claro por qu\u00e9 es necesario. Como cualquier herramienta y proceso, DevOps tiene objetivos concretos que finalmente resuelve.<\/p>\n

Todo esto est\u00e1 relacionado con el hecho de que el mundo est\u00e1 cambiando. Se aleja del enfoque empresarial, donde las compa\u00f1\u00edas avanzan directamente hacia su sue\u00f1o, como cantaba nuestro cl\u00e1sico de San Petersburgo, del punto A al punto B siguiendo una estrategia definida, con una estructura espec\u00edfica construida para eso. <\/p>\n

\"\u00bfQu\u00e9
\n<\/p>\n

En principio, todo en TI deber\u00eda construirse bajo este enfoque. Aqu\u00ed, la TI se utiliza exclusivamente para la automatizaci\u00f3n de procesos.<\/p><\/blockquote>\n

\nLa automatizaci\u00f3n no cambia a menudo porque cuando una empresa sigue un camino ya trazado, \u00bfqu\u00e9 hay que cambiar? Si funciona, \u00a1no lo toques! Actualmente, en el mundo los enfoques est\u00e1n cambiando, y el que se llama Agile dice que el punto final B no se ve de inmediato.<\/p>\n

\"\u00bfQu\u00e9
\n
\nCuando una empresa navega en el mercado, trabaja con el cliente, constantemente investiga el mercado y cambia su punto final B. Adem\u00e1s, cuanto m\u00e1s a menudo una empresa cambia su direcci\u00f3n, m\u00e1s \u00e9xito tiene al elegir m\u00e1s nichos de mercado.<\/p>\n

Una estrategia es demostrada por una empresa interesante de la que me enter\u00e9 recientemente. One Box Shave es un servicio de entrega de maquinillas de afeitar y productos de afeitado por suscripci\u00f3n en una caja. Pueden personalizar su 'cajita' para diferentes clientes. Esto se maneja mediante un software espec\u00edfico que luego env\u00eda el pedido a una f\u00e1brica en Corea que produce el producto.<\/p>\n

Este producto fue adquirido por la empresa Unilever por 1 mil millones de d\u00f3lares. Ahora compite con Gillette y ha robado una parte significativa de su base de consumidores en el mercado estadounidense. One Box Shave dice:<\/p>\n

\u2014 \u00bf4 hojas? \u00bfEn serio? \u00bfPara qu\u00e9 las necesitas? Esto no mejora en nada la calidad del afeitado. Una crema bien seleccionada, una fragancia y una maquinilla de afeitar de calidad con dos hojas resuelven muchos m\u00e1s problemas que esas tontas 4 hojas de Gillette. \u00bfPronto llegar\u00e1n a 10?<\/i><\/p>\n

As\u00ed es como el mundo cambia. Unilever afirma que tienen un excelente sistema de TI que permite hacer esto. Al final, esto se presenta como un concepto Time-to-market<\/b>, del que ya no ha hablado nadie.<\/p>\n

\"\u00bfQu\u00e9
\n
\nEl sentido de Time-to-market no reside en cu\u00e1n a menudo hacemos despliegues. Se puede desplegar con frecuencia, pero los ciclos de lanzamiento pueden ser largos. Si se superponen ciclos de lanzamiento de tres meses, desplaz\u00e1ndolos una semana, parece que la empresa se despliega una vez a la semana. Sin embargo, desde la idea hasta la implementaci\u00f3n final pasan 3 meses.<\/p>\n

Time-to-market se trata de minimizar el tiempo desde la idea hasta la implementaci\u00f3n final.<\/p><\/blockquote>\n

\nEn este caso, el software interact\u00faa con el mercado. As\u00ed, en One Box Shave, el sitio web interact\u00faa con el cliente. No tienen vendedores, solo un sitio donde el visitante hace clic y deja sus deseos. Por lo tanto, es necesario actualizar constantemente el sitio, a\u00f1adiendo novedades de acuerdo a estos deseos. Por ejemplo, en Corea del Sur se afeitan de manera diferente que en Rusia, y prefieren centros de fragancia con aromas como el de zanahoria y vainilla, no con olor a pino.<\/p>\n

Dado que necesitamos cambiar r\u00e1pidamente el contenido del sitio, el desarrollo de software est\u00e1 cambiando dr\u00e1sticamente. A trav\u00e9s del software, debemos saber lo que quiere el cliente. Antes, esto lo descubr\u00edamos por m\u00e9todos indirectos, como a trav\u00e9s de la gesti\u00f3n empresarial. Luego, dise\u00f1\u00e1bamos, incorpor\u00e1bamos los requisitos en el sistema inform\u00e1tico y todo funcionaba perfectamente. Ahora es diferente: el software es dise\u00f1ado por todos los involucrados en el proceso, incluidos los ingenieros, porque ellos aprenden a trav\u00e9s de las especificaciones t\u00e9cnicas c\u00f3mo funciona el mercado y tambi\u00e9n comparten sus conocimientos con el negocio.<\/p>\n

Por ejemplo, en la empresa Qik, de repente descubrimos que a la gente le gusta mucho subir listas de contactos al servidor, y nos desarrollaron una aplicaci\u00f3n para ello. Inicialmente, no hab\u00edamos pensado en esto. En una empresa cl\u00e1sica, todos habr\u00edan decidido que era un error, ya que en la especificaci\u00f3n no se dec\u00eda que deb\u00eda funcionar bien y, de hecho, se hab\u00eda implementado de manera improvisada; habr\u00edan desactivado la funci\u00f3n y dir\u00edan: \u00abNo es necesario, lo m\u00e1s importante es que la funcionalidad b\u00e1sica funcione\u00bb. Pero una empresa tecnol\u00f3gica ve una oportunidad en esto y comienza a cambiar el software en consecuencia.<\/p>\n

\"\u00bfQu\u00e9
\n
\nEn 1968, un perspicaz joven llamado Melvin Conway formul\u00f3 la siguiente idea.<\/p>\n

Una organizaci\u00f3n que crea un sistema est\u00e1 limitada por el dise\u00f1o que copia la estructura de comunicaci\u00f3n dentro de esa organizaci\u00f3n.<\/p><\/blockquote>\n

\nPara producir sistemas de otro tipo, es necesario tener adem\u00e1s una estructura de comunicaci\u00f3n diferente dentro de la empresa. Si su estructura de comunicaci\u00f3n es jer\u00e1rquica, no podr\u00e1 crear sistemas que proporcionen un alto \u00edndice de Time-to-market.<\/p>\n

Leer sobre la ley de Conway<\/a><\/noindex> en a trav\u00e9s de los enlaces<\/a><\/noindex>. Es importante para entender la cultura o filosof\u00eda de DevOps, ya que lo \u00fanico que cambia fundamentalmente en DevOps es precisamente la estructura de comunicaci\u00f3n entre equipos.<\/b>.<\/p>\n

Desde el punto de vista del proceso, antes de DevOps, todas las etapas: an\u00e1lisis, desarrollo, pruebas, explotaci\u00f3n, eran lineales.\"\u00bfQu\u00e9
\nEn el caso de DevOps, todos estos procesos se desarrollan simult\u00e1neamente.<\/p>\n

\"\u00bfQu\u00e9
\n
\nEl Time-to-market solo se puede cumplir de esta manera. Para las personas que trabajaron en el antiguo proceso, esto parece un poco extra\u00f1o y en general no es muy bien visto.<\/p>\n

Entonces, \u00bfpor qu\u00e9 se necesita DevOps?<\/h3>\n

\nPara el desarrollo de productos digitales<\/b>. Si su empresa no tiene un producto digital, no necesita DevOps, esto es muy importante.<\/p>\n

DevOps supera las limitaciones de velocidad del modelo de producci\u00f3n secuencial<\/b>. En \u00e9l, todos los procesos ocurren al mismo tiempo.<\/p>\n

Aumenta la complejidad.<\/b> Cuando los evangelistas de DevOps dicen que con \u00e9l ser\u00e1 m\u00e1s f\u00e1cil lanzar software, es una tonter\u00eda.<\/p>\n

Con DevOps, las cosas solo ser\u00e1n m\u00e1s complejas.<\/p><\/blockquote>\n

\nEn la conferencia, en el stand de Avito, se pod\u00eda ver lo que significa desplegar un contenedor Docker: una tarea incre\u00edblemente dif\u00edcil. La complejidad se vuelve abrumadora, hay que hacer malabares con muchas cosas al mismo tiempo.<\/p>\n

DevOps cambia completamente el proceso y la organizaci\u00f3n de la empresa<\/b>\u00a0\u2014 m\u00e1s bien, no lo cambia DevOps, sino el producto digital. Para llegar al DevOps, este proceso debe cambiarse por completo.<\/p>\n

Preguntas para el especialista<\/h3>\n

\n\u00bfY usted? Preguntas que puede hacerse mientras trabaja en la empresa y se desarrolla como especialista.<\/p>\n

\u00bfTiene una estrategia para crear un producto digital?<\/b> Si la tiene, ya es un buen signo. Esto significa que su empresa avanza hacia DevOps.<\/p>\n

\u00bfSu empresa ya est\u00e1 creando un producto digital?<\/b> Esto significa que puede avanzar un paso m\u00e1s, dedicarse a asuntos m\u00e1s interesantes, desde el punto de vista de DevOps nuevamente. Hablo solo desde este punto de vista.<\/p>\n

\u00bfSu empresa es uno de los l\u00edderes del mercado en el nicho de productos digitales?<\/b> Spotify, Yandex, Uber: empresas que est\u00e1n a la vanguardia del progreso tecnol\u00f3gico en este momento.<\/p>\n

Preg\u00fantate estas cuestiones, y si todas las respuestas son negativas, tal vez no deber\u00edas involucrarte en DevOps en esta empresa. Sin embargo, si realmente te interesa el tema de DevOps, \u00bfquiz\u00e1s deber\u00edas considerar cambiar de empresa? Si tu empresa quiere incorporar DevOps, pero has respondido \"No\" a todas las preguntas, entonces se parece a ese hermoso rinoceronte que nunca cambiar\u00e1.<\/p>\n

\"\u00bfQu\u00e9
\n<\/p>\n

Organizaci\u00f3n<\/h2>\n

\nComo ya he mencionado, seg\u00fan la ley de Conway, la organizaci\u00f3n en la empresa cambia. Comenzar\u00e9 por lo que impide que DevOps se infiltre en la empresa desde la perspectiva organizacional.<\/p>\n

El problema de los \"silos\"<\/h3>\n

\nLa palabra inglesa \"Silo\" se traduce aqu\u00ed al espa\u00f1ol como \"silo\". El sentido de este problema es que no hay intercambio de informaci\u00f3n entre los equipos.<\/b>Cada equipo profundiza en su propia experiencia sin construir un mapa com\u00fan en el que se pueda orientar.<\/p>\n

Esto se asemeja a una persona que acaba de llegar a Mosc\u00fa y a\u00fan no sabe orientarse en el mapa del metro. Los moscovitas suelen conocer su \u00e1rea perfectamente, mientras que en toda Mosc\u00fa se orientan con el mapa del metro. Cuando llegas a Mosc\u00fa por primera vez, no tienes esta habilidad y simplemente te sientes desorientado.<\/p>\n

DevOps propone atravesar este momento de desorientaci\u00f3n y construir juntos un mapa com\u00fan de interacci\u00f3n entre todos los departamentos.<\/p><\/blockquote>\n

\nDos factores lo dificultan.<\/p>\n

La consecuencia del sistema corporativo de gesti\u00f3n.<\/b> Est\u00e1 construido sobre \"silos\" jer\u00e1rquicos separados. Por ejemplo, hay ciertos KPI en las empresas que apoyan este sistema. Por otro lado, tambi\u00e9n intervienen las limitaciones cognitivas de la persona, que a menudo tiene dificultades para salir de los l\u00edmites de su propia experiencia y orientarse en todo el sistema. Simplemente no es c\u00f3modo. Imagina que est\u00e1s en el aeropuerto de Bangkok: no es f\u00e1cil orientarse r\u00e1pidamente. Tambi\u00e9n es complicado orientarse en DevOps, por lo que la gente suele decir que hay que encontrar un gu\u00eda para poder entrar.<\/p>\n

Pero lo m\u00e1s importante es que el problema de los \"silos\" para un ingeniero que ha adoptado el esp\u00edritu de DevOps, que ha le\u00eddo a Fowler y montones de otros libros, se expresa en el hecho de que \"los silos\" no permiten hacer cosas \"obvias\"<\/b>. A menudo nos reunimos despu\u00e9s de DevOps Moscow, conversamos entre nosotros y la gente se queja:<\/p>\n

\u2014 Solo quer\u00edamos iniciar CI, pero result\u00f3 que la gerencia no lo necesita.<\/i><\/p>\n

Esto ocurre precisamente porque\u00a0CI <\/b>y\u00a0proceso de entrega continua<\/b> se encuentran en la frontera de muchas experiencias. Simplemente, al no superar el problema de los \"pozos\" a nivel organizacional, no se podr\u00e1 avanzar m\u00e1s, por mucho que se haga y por triste que sea.<\/p>\n

\"\u00bfQu\u00e9
\n
\nCada participante del proceso en la empresa: desarrolladores de backend y frontend, pruebas, DBA, operaciones, redes, trabaja en su propia direcci\u00f3n, y nadie tiene un mapa general, excepto el gerente, que de alguna manera los observa y gestiona con el m\u00e9todo de \"divide y vencer\u00e1s\".<\/p>\n

Las personas luchan por algunas estrellitas o banderitas, cada uno profundiza en su propia experiencia.<\/p><\/blockquote>\n

\nAl final, cuando surge la tarea de juntar todo esto y construir un pipeline com\u00fan, y ya no es necesario luchar por estrellitas y banderitas, surge la pregunta: \u00bfqu\u00e9 se debe hacer? Hay que llegar a un acuerdo de alguna manera, pero \u00bfc\u00f3mo se hace eso? En la escuela no nos ense\u00f1aron. Desde el colegio nos ense\u00f1aron: \u00a1octavo grado \u2014 wow! \u2014 en comparaci\u00f3n con s\u00e9ptimo grado. Aqu\u00ed es lo mismo.<\/p>\n

\u00bfEs igual en su empresa?<\/h3>\n

\nPara comprobarlo, se pueden hacer las siguientes preguntas.<\/p>\n

\u00bfUtilizan los equipos herramientas comunes, aportan cambios a estas herramientas comunes?<\/p>\n

\u00bfCon qu\u00e9 frecuencia se reconfiguran los equipos, es decir, algunos especialistas de un equipo pasan a otro?<\/b> Esto se est\u00e1 volviendo normal en el entorno de DevOps, porque a veces una persona simplemente no puede entender en qu\u00e9 consiste otra \u00e1rea de especializaci\u00f3n. Se traslada a otro departamento, trabaja all\u00ed durante un par de semanas para crear su mapa de orientaci\u00f3n e interacci\u00f3n con ese departamento.<\/p>\n

\u00bfSe puede crear un comit\u00e9 de cambio y hacer algo al respecto? <\/b>\u00bfO se necesita la mano firme de la alta direcci\u00f3n y una orden? Recientemente escrib\u00ed en Facebook c\u00f3mo un banco poco conocido implementa herramientas a trav\u00e9s de \u00f3rdenes: escribieron una orden, llevan un a\u00f1o implement\u00e1ndola y observan qu\u00e9 sucede. Eso, por supuesto, es largo y triste.<\/p>\n

\u00bfCu\u00e1n importante es para los gerentes lograr logros personales sin tener en cuenta los logros de la empresa? <\/b><\/p>\n

Si respondes a estas preguntas, te ser\u00e1 m\u00e1s claro si tienes este problema en la empresa.<\/p>\n

Infraestructura como c\u00f3digo<\/h2>\n

\nUna vez que se ha resuelto este problema, la primera pr\u00e1ctica importante, sin la cual es dif\u00edcil avanzar en DevOps, es infraestructura como c\u00f3digo<\/b>. <\/p>\n

La infraestructura como c\u00f3digo se percibe m\u00e1s com\u00fanmente de la siguiente manera:<\/p>\n

\u2014 \u00a1Automatizamos todo con bash, llen\u00e9monos de scripts para que los administradores tengan menos trabajo manual!<\/i><\/p>\n

Pero no es as\u00ed.<\/p>\n

La infraestructura como c\u00f3digo implica que describes el sistema IT con el que trabajas en forma de c\u00f3digo, para comprender siempre su estado.<\/p><\/blockquote>\n

\nJunto con otros equipos, creas un mapa en forma de c\u00f3digo que es claro para todos, sobre el cual se puede orientar y navegar. No importa en qu\u00e9 se haya hecho: Chef, Ansible, Salt, o si se utilizan archivos YAML en Kubernetes, no hay diferencia.<\/p>\n

En la conferencia, un colega de 2GIS habl\u00f3 sobre c\u00f3mo crearon su herramienta interna para Kubernetes, que describe la configuraci\u00f3n de sistemas individuales. Para describir 500 sistemas, necesitaron una herramienta separada que genera esta descripci\u00f3n. Cuando existe esta descripci\u00f3n, cualquiera puede consultarla, monitorear cambios, c\u00f3mo modificarla y mejorarla, y qu\u00e9 falta. <\/p>\n

Estar\u00e1s de acuerdo en que los scripts bash separados normalmente no proporcionan esa comprensi\u00f3n. En una de las empresas donde trabaj\u00e9, incluso hab\u00eda un nombre para ellos: script 'write only' \u2014 una vez escrito, ya no se puede leer. Creo que a ti tambi\u00e9n te resulta familiar.<\/p>\n

La infraestructura como c\u00f3digo es c\u00f3digo que describe el estado actual de la infraestructura<\/b>. Este c\u00f3digo es trabajado en conjunto por muchos equipos de producto, infraestructura y servicios, y lo m\u00e1s importante, todos ellos deben entender c\u00f3mo funciona este c\u00f3digo.<\/p>\n

El c\u00f3digo se mantiene de acuerdo con las mejores pr\u00e1cticas de desarrollo de software:<\/b>desarrollo colaborativo, revisi\u00f3n de c\u00f3digo, programaci\u00f3n XP, pruebas, pull requests, CI para la infraestructura como c\u00f3digo \u2014 todo esto es valioso y se puede utilizar.<\/p>\n

El c\u00f3digo se convierte en un lenguaje com\u00fan para todos los ingenieros.<\/p><\/blockquote>\n

\nModificar la infraestructura en c\u00f3digo no lleva mucho tiempo<\/b>. S\u00ed, en el c\u00f3digo de infraestructura tambi\u00e9n puede haber deuda t\u00e9cnica. Generalmente, los equipos se enfrentan a ella un a\u00f1o y medio despu\u00e9s de haber comenzado a implementar 'infraestructura como c\u00f3digo' en forma de un mont\u00f3n de scripts o incluso Ansible, que escriben como si fuera c\u00f3digo espagueti, y adem\u00e1s le a\u00f1aden unos scripts bash al fuego. <\/p>\n

Importante<\/b>: si a\u00fan no has probado este truco, recuerda que Ansible no es bash<\/b>! Lee la documentaci\u00f3n con atenci\u00f3n, investiga lo que se dice sobre esto.<\/p>\n

La infraestructura como c\u00f3digo es la separaci\u00f3n del c\u00f3digo de infraestructura en capas distintas.<\/p><\/blockquote>\n

\nEn nuestra empresa, destacamos 3 capas b\u00e1sicas que son muy claras y simples, pero pueden haber m\u00e1s. Puedes revisar tu c\u00f3digo de infraestructura y decir si tienes esta condici\u00f3n o no. Si no se destacan capas, es necesario dedicar tiempo para refactorizar un poco.
\n\"\u00bfQu\u00e9
\n
\nCapa b\u00e1sica<\/b>\u00a0es como se configura el sistema operativo, las copias de seguridad y otras cosas a bajo nivel, por ejemplo, c\u00f3mo se despliega Kubernetes en un nivel b\u00e1sico.<\/p>\n

Nivel de servicios<\/b>\u00a0son los servicios que ofreces al desarrollador: logging como servicio, monitoreo como servicio, base de datos como servicio, balanceador como servicio, cola como servicio, Continuous Delivery como servicio: un mont\u00f3n de servicios que equipos separados pueden proporcionar al desarrollo. Todo esto debe describirse en m\u00f3dulos separados en tu sistema de gesti\u00f3n de configuraci\u00f3n.<\/p>\n

Capa donde se desarrollan las aplicaciones<\/b> y se describe c\u00f3mo se desplegar\u00e1n sobre las dos capas anteriores.<\/p>\n

Preguntas clave<\/h3>\n

\n\u00bfTienes en tu empresa un repositorio de infraestructura com\u00fan? \u00bfControlas la deuda t\u00e9cnica en la infraestructura? \u00bfUsas pr\u00e1cticas de desarrollo en el repositorio de infraestructura? \u00bfEst\u00e1 tu infraestructura dividida en capas? Puedes consultar con el esquema Base-service-APP. \u00bfQu\u00e9 tan dif\u00edcil es hacer un cambio? <\/p>\n

Si te has encontrado con que hacer cambios toma un d\u00eda y medio, eso significa que tienes deuda t\u00e9cnica y debes trabajar en ello. Te has topado con el problema de la deuda t\u00e9cnica en el c\u00f3digo de infraestructura. Recuerdo muchas historias en las que para cambiar alg\u00fan CCTL, necesitas reescribir la mitad del c\u00f3digo de infraestructura porque la creatividad y el deseo de automatizar todo llevaron a que todo est\u00e9 enredado, se quitaron todas las manijas, y es necesario refactorizar.<\/p>\n

Entrega continua<\/h2>\n

\nHagamos un balance entre el d\u00e9bito y el cr\u00e9dito. Primero, aparece una descripci\u00f3n de la infraestructura, que puede ser bastante b\u00e1sica. No es necesario describir todo en detalle, pero se requiere alguna descripci\u00f3n b\u00e1sica para que puedas trabajar con ello. De lo contrario, no est\u00e1 claro sobre qu\u00e9 hacer a continuaci\u00f3n para realizar una entrega continua. Todas estas pr\u00e1cticas se despliegan al mismo tiempo cuando llegas a DevOps, pero debes comenzar con el entendimiento de lo que tienes y c\u00f3mo gestionarlo. Esa es precisamente la pr\u00e1ctica de infraestructura como c\u00f3digo.<\/p>\n

Despu\u00e9s de entender lo que tienes y c\u00f3mo gestionarlo, comienzas a idear c\u00f3mo enviar el c\u00f3digo del desarrollador al producci\u00f3n lo m\u00e1s r\u00e1pido posible. Me refiero a hacerlo junto con el desarrollador, recordando el problema de los \u201cpozos\u201d, es decir, no son solo personas individuales las que lo idean, sino el equipo.<\/p>\n

Cuando estuvimos con\u00a0Vanya Evtukhovich<\/b> y vimos el primer libro de Jez Humble<\/b> y un grupo de autores \u00abContinuous Delivery\u00bb<\/b>, que sali\u00f3 en 2009, pensamos mucho sobre c\u00f3mo traducir su t\u00edtulo al espa\u00f1ol. Quer\u00edamos traducirlo como \u00abEntrega continua\u00bb, pero, lamentablemente, se tradujo como \u00abEntrega continua\u00bb. Me parece que en nuestro t\u00edtulo hay algo muy espa\u00f1ol, con \u00edmpetu.<\/p>\n

Entregar continuamente significa<\/h3>\n

\nEl c\u00f3digo que est\u00e1 en el repositorio de productos siempre puede ser desplegado en producci\u00f3n.<\/b>Puede que no se despliegue, pero siempre est\u00e1 listo para ello. En consecuencia, siempre escribes c\u00f3digo con una sensaci\u00f3n dif\u00edcil de explicar de cierta inquietud en la parte baja de la espalda. Esta sensaci\u00f3n de inquietud deber\u00eda estar presente; provoca procesos mentales que permiten escribir el c\u00f3digo de manera un poco diferente. Esto debe estar registrado en las reglas dentro del desarrollo.<\/p>\n

Para entregar continuamente, se necesita un formato de artefacto que pase por la plataforma de infraestructura. <\/b>Si lanzas en la plataforma de infraestructura desechos de diferentes formatos, se vuelve no unificada, es dif\u00edcil de mantener, y surge el problema de la deuda t\u00e9cnica. El formato del artefacto debe alinearse, y esa tambi\u00e9n es una tarea colectiva: todos deben reunirse, poner sus mentes en marcha y pensar en este formato.<\/p>\n

El artefacto mejora continuamente y cambia en funci\u00f3n del entorno de producci\u00f3n durante su paso por el pipeline de entrega. <\/b>Cuando el artefacto se mueve a trav\u00e9s del pipeline, siempre se enfrenta a ciertas dificultades similares a las que encuentra el artefacto que se despliega en producci\u00f3n. Si en el desarrollo cl\u00e1sico esto es manejado por el administrador de sistemas que realiza el despliegue, en el proceso de DevOps esto ocurre constantemente: aqu\u00ed lo han probado con algunas pruebas, all\u00ed lo han lanzado al cl\u00faster de Kubernetes, que es m\u00e1s o menos similar a producci\u00f3n, y de repente han iniciado pruebas de carga.<\/p>\n

Esto se asemeja a un juego de Pac-Man: el artefacto sigue una historia. Es fundamental controlar si el c\u00f3digo realmente sigue esta historia y si est\u00e1 relacionado con tu producci\u00f3n. Las historias de producci\u00f3n pueden incorporarse al proceso de Continuous Delivery: hab\u00eda un caso en el que algo fall\u00f3, as\u00ed que vamos a programar este escenario dentro del sistema. Cada vez que el c\u00f3digo pase por este escenario, no te encontrar\u00e1s con el mismo problema la pr\u00f3xima vez. Te enterar\u00e1s de \u00e9l mucho antes de que llegue a tu cliente.<\/p>\n

Diferentes estrategias de despliegue. <\/b>Por ejemplo, utilizas pruebas A\/B o despliegues canarios para \"tocar\" el c\u00f3digo de diferentes formas en diferentes clientes, obteniendo informaci\u00f3n sobre c\u00f3mo funciona el c\u00f3digo, mucho antes de que se despliegue a 100 millones de usuarios.<\/p>\n

La \"entrega continua\" se ve as\u00ed.<\/p>\n

\"\u00bfQu\u00e9
\n<\/p>\n

El proceso de entrega Dev, CI, Test, PreProd, Prod no es un entorno separado, son etapas o estaciones con sumas inextinguibles, por las que pasa tu artefacto.<\/p><\/blockquote>\n

\nSi tienes c\u00f3digo de infraestructura que est\u00e1 descrito como Base Service APP, entonces ayuda a no olvidar todos los escenarios<\/b>, y tambi\u00e9n registrar estos escenarios como c\u00f3digo para este artefacto, promover el artefacto<\/b> y modificarlo a medida que avanza.<\/p>\n

Preguntas para autoevaluaci\u00f3n<\/h3>\n

\n\u00bfEl tiempo desde la descripci\u00f3n de la caracter\u00edstica hasta el despliegue en producci\u00f3n es, en el 95 % de los casos, menor de una semana? \u00bfAumenta la calidad del artefacto en cada etapa del pipeline? \u00bfHay una historia por la que pasa? \u00bfUtilizas diversas estrategias de despliegue?<\/p>\n

Si todas las respuestas son s\u00ed, \u00a1entonces eres incre\u00edble! Deja tus respuestas en los comentarios, estar\u00e9 encantado de leerlas).<\/p>\n

Retroalimentaci\u00f3n<\/h3>\n

\nEsta es la pr\u00e1ctica m\u00e1s complicada de todas. En la conferencia DevOpsConf, un colega de Infobip, al hablar sobre ella, se confund\u00eda un poco porque realmente es una pr\u00e1ctica muy complicada sobre lo que hay que monitorear: \u00a1todo!<\/p>\n

\"\u00bfQu\u00e9
\n
\nPor ejemplo, hace tiempo, cuando trabajaba en Qik, nos dimos cuenta de que hab\u00eda que monitorear todo. Lo hicimos, y en Zabbix aparecieron 150,000 items que se monitorean constantemente. Era aterrador, el director t\u00e9cnico se volvi\u00f3 loco:<\/p>\n

\u2014 Chicos, \u00bfpor qu\u00e9 est\u00e1n torturando el servidor con cosas incomprensibles?<\/i><\/p>\n

Pero luego sucedi\u00f3 algo que demostr\u00f3 que esta es realmente una estrategia muy buena.<\/p>\n

Uno de los servicios comenz\u00f3 a fallar constantemente. Inicialmente no fallaba, lo curioso es que no se estaba agregando c\u00f3digo, porque era un broker b\u00e1sico, que pr\u00e1cticamente no ten\u00eda funcionalidad empresarial, simplemente enviaba mensajes entre servicios distintos. El servicio no cambi\u00f3 durante 4 meses, y de repente comenz\u00f3 a fallar con el error \u00abSegmentation fault\u00bb.<\/p>\n

Est\u00e1bamos en shock, abrimos nuestros gr\u00e1ficos en Zabbix, y descubrimos que hace una semana y media el comportamiento de las solicitudes en el servicio API hab\u00eda cambiado dr\u00e1sticamente. Luego observamos que cambi\u00f3 la frecuencia de env\u00edo de un cierto tipo de mensajes. Despu\u00e9s supimos que eran los clientes de Android. Les preguntamos:<\/p>\n

\u2014 Chicos, \u00bfqu\u00e9 sucedi\u00f3 hace una semana y media?<\/i><\/p>\n

En respuesta escuchamos una historia interesante sobre c\u00f3mo hab\u00edan remodelado la interfaz. Dif\u00edcilmente alguien dir\u00eda de inmediato que cambiaron la biblioteca HTTP. Para los clientes de Android es como cambiar el jab\u00f3n en el ba\u00f1o: simplemente no lo recuerdan. Al final, despu\u00e9s de 40 minutos de conversaci\u00f3n, descubrimos que efectivamente hab\u00edan cambiado la biblioteca HTTP, y esta hab\u00eda cambiado los tiempos predeterminados. Esto provoc\u00f3 un cambio en el comportamiento del tr\u00e1fico en el servidor API, lo que llev\u00f3 a una situaci\u00f3n que caus\u00f3 una carrera dentro del broker, y comenz\u00f3 a fallar.<\/p>\n

Sin un monitoreo profundo, esto ser\u00eda imposible de detectar.<\/b>. Si en la organizaci\u00f3n hay otro problema de \"pozos\", donde cada uno se pasa la responsabilidad al otro, esto puede persistir durante a\u00f1os. Simplemente reinicias el servidor porque no se puede resolver el problema. Cuando monitoreas, sigues y registras todos los eventos que tienes, y usas el monitoreo como prueba \u2014 escribes el c\u00f3digo y de inmediato indicas c\u00f3mo monitorearlo, tambi\u00e9n en forma de c\u00f3digo (ya tenemos infraestructura como c\u00f3digo), todo se vuelve claro como el agua. Incluso los problemas m\u00e1s complejos son f\u00e1ciles de rastrear.<\/p>\n

\"\u00bfQu\u00e9
\n<\/p>\n

Re\u00fane toda la informaci\u00f3n sobre lo que ocurre con el artefacto en cada etapa del proceso de entrega \u2014 no en producci\u00f3n.<\/p><\/blockquote>\n

\nCarga el monitoreo en CI, y ah\u00ed ya se ver\u00e1n algunas cosas b\u00e1sicas. Luego las ver\u00e1s tanto en Test como en PredProd y en pruebas de carga. Recoge informaci\u00f3n en todas las etapas, no solo m\u00e9tricas y estad\u00edsticas, sino tambi\u00e9n registros: c\u00f3mo se despleg\u00f3 la aplicaci\u00f3n, anomal\u00edas \u2014 recopila todo. <\/p>\n

De lo contrario, ser\u00e1 dif\u00edcil entender. Ya he mencionado que DevOps implica una mayor complejidad. Para lidiar con esta complejidad, necesitas tener una anal\u00edtica adecuada.<\/b>.<\/p>\n

Preguntas para la autoevaluaci\u00f3n.<\/h3>\n

\n\u00bfEs tu monitoreo y registro una herramienta de desarrollo para ti?<\/b> \u00bfTus desarrolladores, incluido t\u00fa mismo, piensan en c\u00f3mo monitorear el c\u00f3digo que escriben?<\/p>\n

\u00bfTe enteras de los problemas por parte de los clientes? \u00bfComprendes mejor al cliente a trav\u00e9s del monitoreo y el registro?<\/b> \u00bfComprendes mejor el sistema a trav\u00e9s del monitoreo y el registro?<\/b> \u00bfCambias el sistema simplemente porque ves que la tendencia en el sistema est\u00e1 creciendo y entiendes que en tres semanas todo se caer\u00e1? <\/p>\n

Cuando tienes estos tres componentes, puedes pensar en qu\u00e9 tipo de plataforma de infraestructura tienes en tu empresa.<\/p>\n

Plataforma de infraestructura. <\/h2>\n

\nEl sentido no est\u00e1 en que sea un conjunto de herramientas dispares que existen en cada empresa.<\/p>\n

El objetivo de la plataforma de infraestructura es que todos los equipos utilicen estas herramientas y las desarrollen conjuntamente.<\/p><\/blockquote>\n

\nEs evidente que hay equipos separados que son responsables de desarrollar diferentes partes de la plataforma de infraestructura. Pero, al mismo tiempo, cada ingeniero es responsable del desarrollo, la operatividad y la promoci\u00f3n de la plataforma de infraestructura. A nivel interno, se convierte en una herramienta com\u00fan.<\/b>. <\/p>\n

Todos los equipos desarrollan la plataforma de infraestructura y la cuidan como si fuera su propia IDE.<\/b>. En su IDE, coloca diferentes complementos para que todo sea hermoso y r\u00e1pido, y configura atajos de teclado. Cuando abre Sublime, Atom o Visual Studio Code, aparecen errores de c\u00f3digo y se da cuenta de que es completamente imposible trabajar, se siente triste de inmediato y corre a arreglar su IDE.<\/p>\n

Trate su plataforma de infraestructura de la misma manera. Si se da cuenta de que algo no va bien, deje una solicitud si no puede solucionarlo usted mismo. Si es algo simple, corr\u00edjalo usted mismo, env\u00ede una solicitud de extracci\u00f3n \u2014 el equipo la revisar\u00e1 y a\u00f1adir\u00e1. Este es un enfoque diferente hacia las herramientas de ingenier\u00eda en la mente del desarrollador.<\/p>\n

La plataforma de infraestructura garantiza la transferencia del artefacto desde el desarrollo al cliente con una mejora continua de la calidad.<\/b>. En la PI, se programa un conjunto de historias que ocurren con el c\u00f3digo en producci\u00f3n. A lo largo de los a\u00f1os de desarrollo, se acumulan muchas historias, algunas de las cuales son \u00fanicas y solo le conciernen a usted \u2014 no se pueden buscar en Google. <\/p>\n

En este momento, la plataforma de infraestructura se convierte en su ventaja competitiva.<\/b>, porque incluye lo que no est\u00e1 en la herramienta de la competencia. Cuanto m\u00e1s profunda sea su PI, mayor ser\u00e1 su ventaja competitiva en t\u00e9rminos de Time-to-market. Aqu\u00ed surge el problema del vendor lock<\/b>: puede adoptar una plataforma ajena, pero al usar la experiencia de otros, no entender\u00e1 cu\u00e1n relevante es para usted. S\u00ed, no toda empresa puede construir una plataforma como la de Amazon. Es una l\u00ednea complicada, donde la experiencia de la empresa es relevante a su posici\u00f3n en el mercado, y no se puede permitir el vendor lock all\u00ed. Tambi\u00e9n es importante reflexionar sobre esto.<\/p>\n

Esquema<\/h3>\n

\nEste es el esquema b\u00e1sico de la plataforma de infraestructura que le ayudar\u00e1 a establecer todas las pr\u00e1cticas y procesos en una empresa DevOps.<\/p>\n

\"\u00bfQu\u00e9
\n
\nConsideremos de qu\u00e9 se compone.<\/p>\n

Sistema de orquestaci\u00f3n de recursos<\/b>, que proporciona CPU, memoria y almacenamiento a las aplicaciones y otros servicios. Encima de esto \u2014 servicios de bajo nivel<\/b>: monitoreo, registro, motor CI\/CD, almacenamiento de artefactos, infraestructura como c\u00f3digo.<\/p>\n

Servicios de mayor nivel.<\/b>: base de datos como servicio, colas como servicio, Balanceo de Carga como servicio, redimensionamiento de im\u00e1genes como servicio, Big Data como servicio. Por encima de esto \u2014 un pipeline que entrega c\u00f3digo constantemente modificado a su cliente<\/b>.<\/p>\n

Obtiene informaci\u00f3n sobre c\u00f3mo su software opera en el cliente, modifica, vuelve a entregar este c\u00f3digo, obtiene informaci\u00f3n \u2014 y as\u00ed desarrolla constantemente tanto la plataforma de infraestructura como su software.<\/p>\n

En el esquema, el delivery pipeline consta de m\u00faltiples etapas. Pero esta es una representaci\u00f3n b\u00e1sica, proporcionada como ejemplo \u2014 no es necesario replicarla al pie de la letra. Las etapas interact\u00faan con los servicios como si fueran servicios \u2014 cada ladrillo de la plataforma tiene su propia historia: c\u00f3mo se asignan los recursos, c\u00f3mo se inicia la aplicaci\u00f3n, c\u00f3mo trabaja con los recursos, c\u00f3mo se monitorea y se modifica.<\/p>\n

Es importante entender que cada parte de la plataforma tiene su historia, y preguntarse \u2014 \u00bfcu\u00e1l es la historia que cuenta este ladrillo? Tal vez valga la pena desecharlo y reemplazarlo con un servicio de terceros. Por ejemplo, \u00bfse puede sustituir un ladrillo por Okmeter? Tal vez ellos ya tengan m\u00e1s experiencia en esto que nosotros. Pero tal vez no \u2014 puede que tengamos una experiencia \u00fanica, debemos implementar Prometheus y desarrollarlo m\u00e1s.<\/p>\n

Creaci\u00f3n de la plataforma<\/h3>\n

\nEs un proceso comunicativo complejo. Cuando tiene pr\u00e1cticas b\u00e1sicas, inicia la comunicaci\u00f3n entre diferentes ingenieros y especialistas que desarrollan requisitos y est\u00e1ndares, y los cambian constantemente para diferentes herramientas y enfoques. Aqu\u00ed la cultura es importante, la que existe en DevOps.<\/p>\n

\"\u00bfQu\u00e9
\nCon la cultura, todo es muy simple \u2014 es colaboraci\u00f3n y comunicaci\u00f3n<\/b>, es decir, el deseo de trabajar conjuntamente en el mismo terreno, el deseo de dominar una herramienta juntos. No hay nada complicado \u2014 todo es muy simple, banal. Por ejemplo, todos vivimos en un edificio y mantenemos su limpieza \u2014 ese es el nivel de cultura.<\/p>\n

\u00bfY ustedes?<\/h3>\n

\nNuevamente, preguntas que pueden hacerse.<\/p>\n

\u00bfEst\u00e1 la plataforma de infraestructura claramente definida? \u00bfQui\u00e9n es responsable de su desarrollo? \u00bfComprenden las ventajas competitivas de su plataforma de infraestructura?<\/p>\n

Estas son preguntas que debemos hacernos constantemente. Si algo se puede externalizar a servicios de terceros, se debe hacer; si un servicio externo comienza a bloquear tu progreso, entonces hay que construir un sistema interno.<\/p>\n

As\u00ed que, DevOps...<\/h2>\n

\n\u2026 es un sistema complejo que debe incluir:<\/p>\n