Una manera sencilla de definir la entrega continua es como la habilidad de una organizaci\u00f3n o equipo para mantener el software siempre en un estado entregable, a trav\u00e9s de cambios peque\u00f1os y frecuentes y un conjunto suficiente de validaciones autom\u00e1ticas que garantiza la calidad del software tras cada cambio, por peque\u00f1o que sea (se ponga o no ese cambio en producci\u00f3n).
La ingenier\u00eda de la fiabilidad de sitios se puede definir como la habilidad de una organizaci\u00f3n o equipo para mantener sistemas de software escalables y resistentes a los errores, adoptando pr\u00e1cticas propias de la ingenier\u00eda del software a las actividades de operaci\u00f3n de las soluciones y gesti\u00f3n de las infraestructuras.<\/p>\n\n\n\n
Es posible que hay\u00e1is le\u00eddo o escuchado que la entrega continua es DevOps desde el “lado Dev” y que la ingenier\u00eda de fiabilidad de sitios es DevOps desde el “lado Ops”, pero no solo es inapropiado hablar de lados en DevOps (recordad: sin silos) sino que esa visi\u00f3n tan simplista es muy inexacta.<\/p>\n\n\n\n
Eso es as\u00ed porque ambos conjuntos de pr\u00e1cticas son complementarios y est\u00e1n interrelacionados.<\/p>\n\n\n\n
\u00bfPor qu\u00e9 son complementarias la entrega continua y la fiabilidad de sitios?<\/h3>\n\n\n\n
No se puede ser una organizaci\u00f3n que cumple las expectativas de los principios DevOps si no se implementan armoniosamente las pr\u00e1cticas que promueven tanto la entrega continua como la ingenier\u00eda de fiabilidad de sitios. No tiene sentido ser una organizaci\u00f3n s\u00faper \u00e1gil en la manera en la que llevamos cambios de aplicaciones a producci\u00f3n si luego no podemos mantener un m\u00ednimo de estabilidad y operaci\u00f3n de esas aplicaciones.<\/p>\n\n\n\n
La entrega continua se centra en la cadencia del cambio y el tiempo a mercado. Se pone foco en tener una estrategia de puesta en producci\u00f3n clara con flujos de trabajo definidos, reducir las dependencias entre equipos, mantener la trazabilidad de todos los cambios, automatizar todas las tareas posibles mediante pipelines de integraci\u00f3n y despliegue continuos, y adelantar tanto como sea posible (shift-left) todas las validaciones de calidad y seguridad de las aplicaciones, datos, plataformas e infraestructuras.<\/p>\n\n\n\n
La ingenier\u00eda de fiabilidad de los sitios se centra en la disponibilidad de los sistemas. Se pone foco en el tiempo que el sistema est\u00e1 disponible, el rendimiento, la tolerancia a los fallos, la capacidad para degradarse gr\u00e1cilmente, la planificaci\u00f3n de capacidad frente a eventos, o los planes de respuesta a emergencias.<\/p>\n\n\n\n Ambos conjuntos de pr\u00e1cticas tienen muchos puntos en com\u00fan, como no pod\u00eda ser menos, puesto que abogamos por la colaboraci\u00f3n constante entre desarrollo y operaciones, con objetivos y preocupaciones compartidas (sin silos; s\u00ed, ya s\u00e9 que soy “muy pesado” con eso).<\/p>\n\n\n\n Un ejemplo de esas preocupaciones compartidas entre ambos conjuntos de pr\u00e1cticas es la capacidad para hacer pruebas en producci\u00f3n gracias a t\u00e9cnicas como las pruebas A\/B, la activaci\u00f3n de capacidades a demanda del negocio mediante “feature flags”, o los despliegues de tipo “canary”. Otro ejemplo habitual es la colaboraci\u00f3n en la detecci\u00f3n y resoluci\u00f3n de incidentes gracias a la telemetr\u00eda que se captura de los sistemas activos, la detecci\u00f3n temprana de problemas, y a las capacidades de auto-escalado y de auto-curaci\u00f3n de las aplicaciones, plataformas e infraestructura. Tambi\u00e9n es un ejemplo de preocupaci\u00f3n compartida el tener la habilidad para hacer despliegues de cambios sin ca\u00edda del servicio y con una estrategia de vuelta atr\u00e1s definida.<\/p>\n\n\n\n En la pr\u00f3xima secci\u00f3n entrar\u00e9 en detalle en las pr\u00e1cticas de automatizaci\u00f3n, desarrollando brevemente en qu\u00e9 consisten, y c\u00f3mo est\u00e1n conectadas con la entrega continua y la ingenier\u00eda de fiabilidad de sitios.<\/p>\n\n\n\n Hay muchas formas de clasificar las pr\u00e1cticas de automatizaci\u00f3n de DevOps pero a m\u00ed me ayuda mucho estructurarlas en 6 grupos de pr\u00e1cticas de la siguiente forma:<\/p>\n\n\n\n En su mayor\u00eda, como pod\u00e9is ver, se pone \u00e9nfasis en “continuo” como sin\u00f3nimo de que son pr\u00e1cticas que se aplican, de forma consistente, para cada cambio en el sistema (idealmente cuanto m\u00e1s peque\u00f1o mejor), sin intervenci\u00f3n humana (o \u00e9sta es m\u00ednima) y sin disrupci\u00f3n en la prestaci\u00f3n de los servicios.<\/p>\n\n\n\n Veamos ahora cada grupo con algo m\u00e1s de detalle.<\/p>\n\n\n\n La gesti\u00f3n del ciclo de vida se refiere a la habilidad de tener completa trazabilidad de las actividades relacionadas con el ciclo de vida de los desarrollos, desde requerimientos a entregas, as\u00ed como a las actividades de la operaci\u00f3n, desde tareas peri\u00f3dicas de mantenimiento a la resoluci\u00f3n de incidentes.<\/p>\n\n\n\n Se fundamenta en una gesti\u00f3n de la configuraci\u00f3n exquisita, con estrategias de versionado y ramas consistentes, y que es inclusiva de todos los elementos del sistema, tanto aplicaciones como datos o piezas de la infraestructura (m\u00e1s sobre este \u00faltimo aspecto en el apartado sobre infraestructura continua).<\/p>\n\n\n\n Tendremos una identificaci\u00f3n precisa sobre qui\u00e9n hizo qu\u00e9, cu\u00e1ndo y por qu\u00e9, independientemente de la capa o componente donde impactara el cambio. La gesti\u00f3n de dependencias ser\u00e1 clara y evitaremos sorpresas como las que suceden, a modo de ejemplo, cuando no se han identificados ciertos artefactos software y solo se descubre su falta en el momento de una entrega o cuando los cambios ya est\u00e1n desplegado en producci\u00f3n y suceden errores imprevistos.<\/p>\n\n\n\n Por tanto, una gesti\u00f3n del ciclo de vida de las aplicaciones adecuada es imprescindible tanto para conseguir los objetivos de velocidad y \u00e9xito en las entregas como la fiabilidad, resiliencia y operabilidad de los sistemas.<\/p>\n\n\n\n Ejemplos de herramientas de ciclo de vida son: GitHub, GitLab, Jira, BitBucket, Azure DevOps, Nexus Repository, o Artifactory.<\/p>\n\n\n\n La integraci\u00f3n continua fue definida en septiembre del a\u00f1o 2000 por Martin Fowler en un famoso blog considerado todo un cl\u00e1sico3<\/a><\/sup>. Desde entonces, aunque ha mantenido esa pieza en constante revisi\u00f3n (la \u00faltima de enero de 2024) y se ha expandido tanto en el libro hom\u00f3nimo como en m\u00faltiples otros lugares, se ha mantenido intacto el significado de lo que es y lo que no es integraci\u00f3n continua.<\/p>\n\n\n\n En breve: la integraci\u00f3n continua es el proceso por el cual de forma frecuente (al menos una vez al d\u00eda) los miembros de un equipo integran los cambios de sus compa\u00f1eros sobre sus propios cambios, validan que el funcionamiento tras la integraci\u00f3n de esos cambios sigue siendo el esperado (“green tests”) y se comparte el c\u00f3digo al repositorio com\u00fan (“git push”) para que un entorno centralizado (el motor de integraci\u00f3n continua) realice un proceso de construcci\u00f3n autom\u00e1tico (lo que normalmente llamamos una “build”) y ejecutar\u00e1 de nuevo todas las pruebas concluyendo en un producto candidato para ser entregado (“shippable product”) o en un aviso a los desarrolladores de que algo no funciona como se espera.<\/p>\n\n\n\n Practicar integraci\u00f3n continua implica, entre otras cosas, que los miembros de los equipos validan sus cambios e integran los cambios de sus compa\u00f1eros de forma frecuente para evitar que se acumulen los cambios pendientes de integrar. De forma impl\u00edcita promueve una estrategia de ramas sencilla con m\u00faltiples ramas de tipo “feature” de vida corta adem\u00e1s del tronco o “main” donde est\u00e1 la versi\u00f3n m\u00e1s actual del c\u00f3digo. Finalmente, practicar integraci\u00f3n continua implica que si una “build” falla, el equipo para todo el trabajo en curso para resolverlo, antes de retomar el trabajo planificado. De ese modo, el estado del tronco o “main” ser\u00e1 siempre estable (aunque no necesariamente entregable; m\u00e1s sobre esto cuando se trate la validaci\u00f3n continua).<\/p>\n\n\n\n Mediante la integraci\u00f3n continua conseguimos detectar de forma temprana problemas derivados de la integraci\u00f3n de cambios que se han realizado de forma independiente por distintos miembros del equipo (o del mismo desarrollador para dos peticiones diferentes) sobre cualquier componente software del sistema. Se gana en calidad de los entregables y en productividad del equipo ya que resolver esas situaciones en peque\u00f1os lotes es mucho m\u00e1s \u00f3ptimo que integrar cientos de cambios a la vez.<\/p>\n\n\n\n Si adem\u00e1s complementamos la integraci\u00f3n continua con otro tipo de validaciones como la inspecci\u00f3n de c\u00f3digo y configuraci\u00f3n, el an\u00e1lisis de dependencias o la identificaci\u00f3n de vulnerabilidades de seguridad, se consigue aumentar aun m\u00e1s la calidad del software mediante la detecci\u00f3n temprana de ese tipo de defectos.<\/p>\n\n\n\n La integraci\u00f3n continua tiene adem\u00e1s otro beneficio adicional: el proceso que transforma c\u00f3digo y configuraci\u00f3n en software que funciona es un proceso bien conocido, repetible, autom\u00e1tico, mucho m\u00e1s fiable que los procesos manuales que suelen tener una alta tasa de fallo, que no est\u00e1n documentados o que directamente requieren del conocimiento “tribal” de algunos (pocos) miembros del equipo. A la secuencia que transforma el c\u00f3digo en un producto candidato es a lo que normalmente llamamos el “pipeline” de integraci\u00f3n continua.<\/p>\n\n\n\n Por tanto, la integraci\u00f3n continua ayuda fundamentalmente a cumplir con los objetivos de la entrega continua.<\/p>\n\n\n\n Ejemplos de herramientas de integraci\u00f3n continua son: Jenkins, GitHub Actions, GitLab CI\/CD, Azure Pipelines, o CircleCI.<\/p>\n\n\n\n Tambi\u00e9n son muy relevantes para los “pipelines” de CI las herramientas que interact\u00faan con los distintos lenguajes y plataformas, ya sea para gestionar dependencias, compilar, transformar, empaquetar, validar la calidad del c\u00f3digo, ejecutar pruebas unitarias, o identificar vulnerabilidades. Por ejemplo: Maven, Gradle, Grunt, npm, webpack, pip, SonarQube, Checkstyle, SpotBugs, ESLint, OWASP Dependency Track, y un largo etc.<\/p>\n\n\n\n Consiste en la capacidad para desplegar cambios de forma autom\u00e1tica a todos los entornos incluido el productivo, de forma orquestada incluyendo dependencias (con otras aplicaciones, sistemas externos, datos), as\u00ed como cualquier tipo de umbral (“gate”) como son, por ejemplo: verificaci\u00f3n de momento del despliegue frente a las ventanas definidas, la validaci\u00f3n del \u00e9xito de pruebas de aceptaci\u00f3n y regresi\u00f3n en un entorno previo, o un paso de aprobaci\u00f3n manual por parte de un responsable de negocio.<\/p>\n\n\n\n Una pr\u00e1ctica de despliegue continuo saludable adem\u00e1s cuenta con procesos de marcha atr\u00e1s (“rollback”) bien definidos y que se ejecutan ya sea autom\u00e1ticamente o de forma manual. Un ejemplo de “rollback” autom\u00e1tico ser\u00eda el que se hace sin intervenci\u00f3n cuando fallan las pruebas realizadas en producci\u00f3n post-despliegue, como pruebas operacionales o pruebas de humo.<\/p>\n\n\n\n Desplegar continuamente es m\u00e1s que tener un automatismo. Un “shell script” que sube un fichero por scp y ejecuta un comando de reinicio por ssh es f\u00e1cil de hacer. La dificultad, en algunos casos m\u00e1xima, reside en orquestar procesos complejos, aplicaciones con muchos componentes, dependencias con librer\u00edas de terceros o con otras aplicaciones, ser consistentes en el despliegue de cambios de la aplicaci\u00f3n junto con cambios en datos (y que se pueda hacer un “rollback” seguro de la aplicaci\u00f3n considerando que seguramente no se podr\u00e1 hacer marcha atr\u00e1s de los cambios en los datos), o ser capaces de implantar un proceso de despliegue que no suponga interrupciones al servicio (como pueden ser despliegues “canary”, “azul\/verde” o “rolling”).<\/p>\n\n\n\n La pr\u00e1ctica de despliegue continuo es terreno colaborativo tanto de Dev como de Ops, una preocupaci\u00f3n de la entrega continua y de la fiabilidad de los sitios, y es por tanto de esperar que sea una de las pr\u00e1cticas donde mayor colaboraci\u00f3n e interacci\u00f3n exista entre ambos grupos.<\/p>\n\n\n\n Disponer de un proceso autom\u00e1tico y desatendido facilita en gran medida la trazabilidad de los cambios desplegados a trav\u00e9s de todos los entornos, as\u00ed como disponer de artefactos firmados digitalmente con los que podamos prevenir cambios no deseados por ataques en la “cadena de suministro” del software (“secure software supply chain”).<\/p>\n\n\n\n Ejemplos de herramientas de despliegue continuo (y de orquestaci\u00f3n de aplicaciones) son: Jenkins, CloudBees CD\/RO, AutoRABIT, Flyway, Liquibase, Helm, Terraform, o Ansible. Y muchas, muchas, l\u00edneas de “shell script”.<\/p>\n\n\n\n O como algunas veces me gusta llamarla: “esa gran desconocida”.<\/p>\n\n\n\n Iron\u00edas aparte, en mi experiencia es una pr\u00e1ctica muchas veces denostada, arrinconada o adoptada de forma muy incompleta en los proyectos del mundo real. \u00bfQu\u00e9 pasa cuando un proyecto va mal en fecha? \u00bfQu\u00e9 suele verse sacrificado lo primero? \u00bfRecortamos alcance? No; con mucha frecuencia, se reduce la carga de trabajo en tareas de aseguramiento de la calidad. Es aun muy com\u00fan ver proyectos, incluso tecnol\u00f3gicamente punteros, con m\u00ednimas o ninguna pruebas unitarias autom\u00e1ticas, pruebas que “van de visita” sin validar ning\u00fan resultado, pruebas de aceptaci\u00f3n testimoniales, o pruebas de regresi\u00f3n limitadas al “voy a darle una vuelta” de forma manual.<\/p>\n\n\n\n Sin validaci\u00f3n continua no puede haber entrega continua. No importa cu\u00e1nto y bueno sean la integraci\u00f3n continua y el despliegue continuo, que sin un conjunto suficiente de pruebas de validaci\u00f3n del software no podemos considerar si \u00e9ste est\u00e1 o no en estado entregable. Y garantizar el estado entregable del software es la pieza angular de la entrega continua: ser capaces de llevar cambios a producci\u00f3n con bajo riesgo, r\u00e1pida y consistentemente.<\/p>\n\n\n\n La validaci\u00f3n continua implica la ejecuci\u00f3n de pruebas autom\u00e1ticas de forma temprana y frecuente en entornos equivalentes al de producci\u00f3n. Debido al \u00e9nfasis en que la validaci\u00f3n es continua, de forma frecuente significa que las ejecutaremos tras cada cambio, o como m\u00ednimo una vez al d\u00eda alineados a la pr\u00e1ctica de integraci\u00f3n continua. Que se hagan de forma temprana implica que desde la primera l\u00ednea de c\u00f3digo existen las pruebas necesarias para la validaci\u00f3n. Se puede practicar TDD, BDD o no, pero todo cambio lleva emparejado el cambio en scripts y datos de prueba. Entornos equivalente al de producci\u00f3n significa que podemos aprovisionar un entorno ef\u00edmero a partir de la misma definici\u00f3n del productivo, con las mismas piezas de infraestructura y versiones, cargarlo con datos significativos, y una vez ya no es necesario, eliminarlo para ahorrar en recursos.<\/p>\n\n\n\n Ejemplos de herramientas de validaci\u00f3n continua son: JUnit, JaCoCo, Pitest, Karma, Mocha, Jasmine, Cypress, Selenium, SoapUI, JMeter, Gatling, y otro largo etc\u00e9tera. Muchas de estas herramientas ya se habr\u00e1n utilizado como parte de los “pipelines” de integraci\u00f3n continua para la ejecuci\u00f3n y validaci\u00f3n de las pruebas unitarias, por lo que su uso es transversal y encajar\u00e1 m\u00e1s all\u00e1 o ac\u00e1 seg\u00fan el tipo de pruebas que se automatizan y su lugar dentro de la pir\u00e1mide del “testing”.<\/p>\n\n\n\n La infraestructura continua se basa en tres pilares: la infraestructura como c\u00f3digo (o infraestructura definida por software); la integraci\u00f3n de las capacidades de resiliencia, disponibilidad, o escalabilidad, en la propia definici\u00f3n de la infraestructura y no como una consideraci\u00f3n posterior; y la capacidad de validar continuamente cambios en la infraestructura de modo an\u00e1logo a como la integraci\u00f3n continua lo hace para los componentes software (para que sea realmente continua).<\/p>\n\n\n\n La infraestructura como c\u00f3digo nos permite generar entornos completamente funcionales a partir de la nada. Mediante herramientas especializadas y scripts somos capaces de validar pre-requisitos y generar todas las capas de la infraestructura como son: redes, discos, computaci\u00f3n, bases de datos, servicios “serverless”, y un largo etc\u00e9tera. La definici\u00f3n asume pocas o ninguna dependencias externas, idealmente agrupando consideraciones comunes en capas de abstracci\u00f3n como puede ser una “landing zone” de la que heredan propiedades el resto de entornos, o una estructura modular alineada con las capas conceptuales de la arquitectura.<\/p>\n\n\n\n La infraestructura como c\u00f3digo permite adoptar estrategias de entornos ef\u00edmeros, que existen solo cuando son necesarios lo que permite ahorrar en costes si lo comparamos con tener entornos 24×7 operativos se est\u00e9n usando o no. Es clave para tener entornos equivalentes al de producci\u00f3n lo que facilita la detecci\u00f3n temprana de problemas y la repetibilidad de incidentes en la producci\u00f3n cuando se repiten en entornos previos o creados espec\u00edficamente para investigar el suceso.<\/p>\n\n\n\n Emparejada con el control de versiones, la infraestructura como c\u00f3digo facilita las necesidades de trazabilidad y gobierno, incluyendo el mantenimiento de inventarios completos (SBOM o “software bill of materials”) y la certificaci\u00f3n de soluciones (clave en entornos regulados como son las infraestructuras cr\u00edticas de un pa\u00eds).<\/p>\n\n\n\n Otro beneficio es que habilita la pr\u00e1ctica de GitOps: la validaci\u00f3n y despliegue de nuevas versiones de las infraestructuras y plataformas a partir de cambios en los repositorios, validar y propagar los cambios a trav\u00e9s de tantos entornos como sea necesario. Es la fusi\u00f3n perfecta entre la integraci\u00f3n continua y la validaci\u00f3n continua pero para los componentes de infraestructura y plataforma.<\/p>\n\n\n\n Una pr\u00e1ctica de infraestructura continua aporta una capa adicional de tranquilidad respecto a la estabilidad de los negocios. Poder generar un entorno productivo al completo desde cero, con todos los componentes necesarios en las versiones correctas (porque todo est\u00e1 bajo control de versiones y trazado) y con la \u00faltima versi\u00f3n de los datos, y poder hacerlo en pocas horas, significa minimizar disrupciones incluso en casos severos de p\u00e9rdidas de disponibilidad de servicios. Sobrevivir incluso a la p\u00e9rdida completa de un centro de datos moviendo la producci\u00f3n a una regi\u00f3n alternativa. Es decir: la “red de seguridad” definitiva.<\/p>\n\n\n\n Esta pr\u00e1ctica es fundamental para los objetivos de SRE pero es tambi\u00e9n importante para la entrega continua al facilitar las actividades de validaci\u00f3n de los cambios en entornos equivalentes al de producci\u00f3n y garantizar el estado entregable de una soluci\u00f3n.<\/p>\n\n\n\n Ejemplos de herramientas de infraestructura continua son: VirtualBox, Vagrant, Docker, Kubernetes, Rancher, Terraform, Ansible, etc. Y, por supuesto, los proveedores de servicios de infraestructura y plataformas como: VMware, Amazon Web Services, Google Cloud, Microsoft Azure, OVHcloud, etc.<\/p>\n\n\n\n Las operaciones continuas se basan en tres pilares: la observabilidad, o capacidad de recolectar informaci\u00f3n a trav\u00e9s de todos los entornos y funciones de un sistema y tomar una posici\u00f3n proactiva en la detecci\u00f3n y resoluci\u00f3n de incidentes; la ingenier\u00eda del caos, que nos permite abordar la detecci\u00f3n temprana de problemas de infraestructura de forma estructurada (y cient\u00edfica) en base a la ideaci\u00f3n de experimentos y validaci\u00f3n de las hip\u00f3tesis sobre el comportamiento esperado del sistema; y los planos de control de la infraestructura que permiten a los sistemas auto-monitorizarse y actuar sin intervenci\u00f3n humana para resolver situaciones de disponibilidad, escalado, degradaci\u00f3n de servicios, contenci\u00f3n de fallos, etc.<\/p>\n\n\n\n Mediante la introducci\u00f3n de una estrategia de observabilidad y herramientas de monitorizaci\u00f3n modernas podemos realizar una recopilaci\u00f3n exhaustiva de telemetr\u00eda de todos los componentes de un sistema y dejar de ser reactivos a incidentes. Estableciendo objetivos de nivel de servicio (“service-level objectives”, SLOs) e indicadores de nivel de servicio (“service-level indicators”, SLIs), podemos tener el control continuo sobre el rendimiento y disponibilidad del sistema, entender qu\u00e9 margen de actuaci\u00f3n tenemos (la diferencia entre el SLO y el SLI, tambi\u00e9n conocido como el “error budget”) y actuar proactivamente ante cualquier riesgo de que no pueda cumplirse el SLO.<\/p>\n\n\n\n Una estrategia adecuada de observabilidad tambi\u00e9n nos permite obtener m\u00e9tricas relevantes para el an\u00e1lisis del rendimiento del negocio como son: comportamiento de usuarios, uso de caracter\u00edsticas espec\u00edficas (muy potente si se alinea con pruebas A\/B o la activaci\u00f3n de caracter\u00edsticas o “feature flags”), informaci\u00f3n en tiempo real de KPIs de negocio, etc.<\/p>\n\n\n\n Es posible optimizar los costes de las infraestructuras monitorizando el uso y adaptando en tiempo real los recursos a las necesidades reales, escalando en ambos sentidos seg\u00fan el momento, as\u00ed como identificar caracter\u00edsticas poco o nunca utilizadas y considerar su eliminaci\u00f3n del sistema.<\/p>\n\n\n\n Los experimentos de ingenier\u00eda del caos nos facilitan validar el dise\u00f1o de la resiliencia de nuestros sistemas comenzando por lo que sabemos o creemos saber (“known knowns”), aumentando progresivamente la dificultad y alcance de los experimentos hasta cubrir todo lo que no sabemos o no hemos medido antes (“known unknowns”, “unknown unknowns”).<\/p>\n\n\n\n Un ejemplo de experimento sobre una base conocida es: si una r\u00e9plica del servicio de autentificaci\u00f3n falla no habr\u00e1 p\u00e9rdida de servicio porque el resto de r\u00e9plicas podr\u00e1n absorber la carga hasta 1.000 usuarios por minuto. O tambi\u00e9n: si un nodo de nuestro cl\u00faster Kubernetes falla otro nodo estar\u00e1 disponible y los servicios de vuelta en funcionamiento en menos de 2 minutos.<\/p>\n\n\n\n Un ejemplo de experimento sobre una base desconocidos puede ser: el tiempo de recuperaci\u00f3n de servicios en caso de que sufri\u00e9ramos la p\u00e9rdida completa del centro de datos de Europa Sur deber\u00eda ser inferior a las 4 horas para cumplir el objetivo (RTO o “recovery time objective”), pero no estamos seguros de ello ya que nunca se ha ejecutado ese escenario. No solo deber\u00edamos validar los tiempos de recuperaci\u00f3n sino si la monitorizaci\u00f3n es capaz de hacer detecci\u00f3n temprana de un suceso de esa envergadura o si la automatizaci\u00f3n disponible actualmente puede recrear el entorno al completo sin intervenci\u00f3n manual.<\/p>\n\n\n\n Contar con unas operaciones de este nivel es preocupaci\u00f3n fundamental de SRE pero con enorme colaboraci\u00f3n de los equipos de desarrollo en consideraciones de dise\u00f1o de la resiliencia, exportar y disponibilizar los datos de telemetr\u00eda, contar con registros operacionales como los logs de las aplicaciones, o la resoluci\u00f3n r\u00e1pida de incidentes.<\/p>\n\n\n\n Ejemplos de plataformas y herramientas ampliamente utilizadas en estas pr\u00e1cticas son: Elastic, Dynatrace, Grafana, Prometheus, New Relic, influxdata, DataDog, AppDynamics, Viewtinet, Nagios, Litmus Chaos, Gremlin, etc.<\/p>\n\n\n\n Cerrando el c\u00edrculo, el siguiente diagrama trata de recoger de un vistazo la relaci\u00f3n entre las pr\u00e1cticas de automatizaci\u00f3n de DevOps y su impacto en conseguir los objetivos tanto de la entrega continua como de la ingenier\u00eda de fiabilidad de sitios.<\/p>\n\n\n\n En el pr\u00f3ximo art\u00edculo de la serie continuar\u00e9 profundizando en aspectos relacionados con DevOps hablando de la experiencia del desarrollador, o “Developer Experience”.<\/p>\n\n\n\n \u00a1Hasta pronto!<\/p>\n\n\n\n Jorge Hidalgo es director de ingenier\u00eda de software en Accenture, responsable de DevOps en Accenture Iberia y de la unidad de Arquitectura y Plataformas Cloud y DevOps en Accenture EMEA South Advanced Technology Center. Es tambi\u00e9n responsable en Accenture globalmente de la comunidad de pr\u00e1ctica Java y Java Champion desde 2023.<\/p>\n\n\n\n Jorge cuenta con m\u00e1s de 25 a\u00f1os de experiencia en la industria, principalmente con tecnolog\u00edas Java, web, cloud, DevOps, agilidad y ciberseguridad. Adem\u00e1s de desarrollar su actividad profesional con clientes, es una figura activa en las comunidades tecnol\u00f3gicas, tanto como ponente en numerosos eventos locales e internacionales, como liderando la actividad de comunidades como M\u00e1laga JUG, M\u00e1laga Scala Developers y Boquer\u00f3nSec, as\u00ed como colaborando en la organizaci\u00f3n de eventos como OpenSouthCode o Codemotion.<\/p>\n\n\n\n https:\/\/deors.wordpress.com<\/a><\/p>\n\n\n\n https:\/\/x.com\/deors314<\/a><\/p>\n\n\n\n https:\/\/www.linkedin.com\/in\/deors<\/a><\/p>\n\n\n En esta segunda parte sobre DevOps, hablar\u00e9 de la entrega continua o “Continuous Delivery” y de la ingenier\u00eda de fiabilidad de sitios o “Site Reliability Engineering”. Si DevOps nos gu\u00eda en la promesa de construir software que est\u00e1 siempre en estado entregable y que una vez que se entrega se mantiene estable y f\u00e1cil de… Read more<\/a><\/p>\n","protected":false},"author":248,"featured_media":27140,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_editorskit_title_hidden":false,"_editorskit_reading_time":0,"_editorskit_is_block_options_detached":false,"_editorskit_block_options_position":"{}","_uag_custom_page_level_css":"","_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":"[{\"id\":\"d8f16f2e-bd7b-4aa5-955e-1e62b26f4363\",\"content\":\"Libro \\\"Continuous Delivery\\\", por Jez Humble y David Farley<\\\/a>\"},{\"id\":\"ae127050-2811-4992-85dd-03c60be41a78\",\"content\":\"Libro \\\"Site Reliability Engineering\\\", de Google<\\\/a>\"},{\"id\":\"d72e2ea7-d543-46b2-9fe3-474598155c12\",\"content\":\"Art\\u00edculo que introdujo la integraci\\u00f3n continua, por Martin Fowler<\\\/a>\"}]"},"categories":[10626],"tags":[10747],"collections":[],"class_list":{"0":"post-29696","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-devops-es","8":"tag-desarrollo-web","9":"entry"},"yoast_head":"\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/10\/arti2-img1.png\")
<\/figure>\n\n\n\nDiagrama sobre la relaci\u00f3n entre la entrega continua y la fiabilidad de sitios.<\/pre>\n\n\n\n
\u00bfC\u00f3mo se interrelacionan la entrega continua y la fiabilidad de sitios?<\/h3>\n\n\n\n
Pr\u00e1cticas de Automatizaci\u00f3n de DevOps vs. CD vs. SRE<\/h3>\n\n\n\n
\n
Gesti\u00f3n del ciclo de vida de las aplicaciones<\/h3>\n\n\n\n
Integraci\u00f3n continua<\/h3>\n\n\n\n
Despliegue continuo<\/h3>\n\n\n\n
Validaci\u00f3n continua<\/h3>\n\n\n\n
Infraestructura continua<\/h3>\n\n\n\n
Operaciones continuas<\/h3>\n\n\n\n
Conclusiones<\/h3>\n\n\n\n
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2024\/10\/arti2-img2-1024x385.png\")
<\/figure>\n\n\n\nDiagrama con la relaci\u00f3n entre los grupos de pr\u00e1cticas de DevOps,
la entrega continua y la fiabilidad de sitios.<\/pre>\n\n\n\nSobre el autor<\/h3>\n\n\n\n