En este documento se describen la recuperación tras fallos y la planificación de la continuidad de la actividad en el contexto de la integración continua y la entrega continua (CI/CD). También ofrece directrices sobre cómo identificar y mitigar las dependencias al desarrollar un plan de continuidad de la actividad (BCP) completo. El documento incluye prácticas recomendadas que puedes aplicar a tu plan de continuidad de negocio, independientemente de las herramientas y los procesos que utilices. En este documento se da por supuesto que conoces los aspectos básicos del ciclo de entrega y operaciones de software, la integración continua y la entrega continua (CI/CD) y la recuperación ante desastres (DR).
Los flujos de procesamiento de CI/CD se encargan de compilar y desplegar tus aplicaciones esenciales. Por lo tanto, al igual que tu infraestructura de aplicaciones, tu proceso de CI/CD requiere una planificación de recuperación ante desastres y continuidad de la actividad. Cuando piensas en la recuperación ante desastres y la continuidad del negocio para la integración continua y la entrega continua, es importante que conozcas cada fase del ciclo de entrega y operaciones de software, así como la forma en que funcionan juntas como un proceso integral.
El siguiente diagrama es una vista simplificada del ciclo de desarrollo y operaciones de software, que incluye las tres fases siguientes:
- Bucle interno de desarrollo: codificar, probar y confirmar
- Integración continua: compilación, pruebas y seguridad
- Entrega continua: promociones, lanzamientos, restauraciones y métricas
En este diagrama también se muestra que Google Kubernetes Engine (GKE), Cloud Run y Google Distributed Cloud son posibles destinos de despliegue del ciclo de desarrollo y operaciones de software.
A lo largo del ciclo de desarrollo y operaciones de software, debes tener en cuenta el impacto de un desastre en la capacidad de los equipos para operar y mantener aplicaciones esenciales para la empresa. De esta forma, podrás determinar el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO) de las herramientas de tu cadena de herramientas de CI/CD.
Además, la mayoría de las organizaciones tienen muchas canalizaciones de CI/CD diferentes para distintas aplicaciones y conjuntos de infraestructura, y cada canalización tiene requisitos únicos para la planificación de la recuperación ante desastres y la continuidad de la actividad. La estrategia de recuperación que elijas para una canalización variará en función del tiempo de recuperación (RTO) y del punto de recuperación (RPO) de tus herramientas. Por ejemplo, algunas pipelines son más críticas que otras y tendrán requisitos de RTO y RPO más bajos. Es importante identificar las canalizaciones críticas para la empresa en tu plan de continuidad de la actividad. También debes prestarles más atención al implementar las prácticas recomendadas para probar y ejecutar los procedimientos de recuperación.
Como cada proceso de CI/CD y su cadena de herramientas son diferentes, el objetivo de esta guía es ayudarte a identificar los puntos únicos de fallo en tu proceso de CI/CD y a desarrollar un plan de continuidad de negocio completo. En las siguientes secciones se explica cómo hacer lo siguiente:
- Descubre qué necesitas para recuperarte de un evento de recuperación ante desastres que afecte a tu proceso de integración continua y entrega continua.
- Determina el tiempo de recuperación y el punto de recuperación de los datos de las herramientas de tu proceso de CI/CD.
- Conocer los modos de fallo y las dependencias de tu proceso de CI/CD.
- Elige una estrategia de recuperación adecuada para las herramientas de tu cadena de herramientas.
- Conocer las prácticas recomendadas generales para implementar un plan de recuperación ante desastres para tu proceso de CI/CD.
Información sobre el proceso de continuidad empresarial
El desarrollo de un plan de continuidad de negocio es fundamental para asegurar que tu organización pueda seguir operando en caso de interrupciones y emergencias. Ayuda a tu organización a volver rápidamente a un estado de operaciones normal en su proceso de integración continua y entrega continua.
En las siguientes secciones se describen las fases generales que incluyen los pasos necesarios para crear un plan de continuidad de negocio eficaz. Aunque muchos de estos pasos se aplican de forma general a la gestión de programas y a la recuperación ante desastres, algunos son más relevantes para planificar la continuidad de la actividad empresarial en tu proceso de CI/CD. Los pasos que son específicamente relevantes para planificar la continuidad del negocio de la CI/CD se destacan en las siguientes secciones y también constituyen la base de las directrices del resto de este documento.
Iniciación y planificación
En esta fase inicial, los equipos técnicos y de gestión trabajan conjuntamente para sentar las bases del proceso de planificación de la continuidad de la actividad y su mantenimiento continuo. Estos son los pasos clave de esta fase:
- Implicación de los líderes: asegúrate de que la alta dirección apoya y promueve el desarrollo del plan de continuidad de negocio. Asigna un equipo o una persona que se encargue de supervisar el plan.
- Asignación de recursos: asigna el presupuesto, el personal y los recursos necesarios para desarrollar e implementar el plan de continuidad de negocio.
- Ámbito y objetivos: define el ámbito de tu plan de continuidad de negocio y sus objetivos. Determina qué procesos empresariales son críticos y deben abordarse en el plan.
- Evaluación de riesgos: identifica los riesgos y las amenazas potenciales que podrían interrumpir tu negocio, como desastres naturales, brechas de ciberseguridad o interrupciones en la cadena de suministro.
- Análisis de impacto: evalúa las posibles consecuencias de los resultados de la evaluación de riesgos en las operaciones, las finanzas, la reputación y la satisfacción de los clientes de tu empresa.
Análisis de impacto empresarial
En esta fase, los equipos empresariales y técnicos analizan el impacto de las interrupciones en tus clientes y en tu organización, y priorizan la recuperación de las funciones empresariales críticas. Estas funciones empresariales se llevan a cabo con diferentes herramientas durante las distintas fases de un proceso de compilación e implementación.
El análisis de impacto empresarial es una fase importante del proceso de planificación de la continuidad del negocio para la integración y la entrega continuas, especialmente los pasos para identificar las funciones empresariales críticas y las dependencias de herramientas. Además, comprender tu cadena de herramientas de CI/CD, incluidas sus dependencias y cómo funciona en tu ciclo de vida de DevOps, es un elemento fundamental para desarrollar un plan de continuidad de negocio para tu proceso de CI/CD.
Los pasos clave de la fase de análisis del impacto empresarial son los siguientes:
- Funciones críticas: determina las funciones y los procesos empresariales clave que deben priorizarse para la recuperación. Por ejemplo, si determinas que implementar aplicaciones es más importante que ejecutar pruebas unitarias, priorizarías la recuperación de los procesos y las herramientas de implementación de aplicaciones.
- Dependencias: identifica las dependencias internas y externas que podrían afectar a la recuperación de tus funciones críticas. Las dependencias son especialmente importantes para asegurar el funcionamiento continuo de tu proceso de CI/CD a través de su cadena de herramientas.
- Tiempo de recuperación (RTO) y punto de recuperación (RPO): define los límites aceptables de tiempo de inactividad y pérdida de datos de cada función crítica. Estos objetivos de tiempo de recuperación y de punto de recuperación están vinculados a la importancia de una función empresarial para que las operaciones continúen y requieren herramientas específicas para que la función empresarial opere sin problemas.
Desarrollo de la estrategia
En esta fase, el equipo técnico desarrolla estrategias de recuperación para las funciones empresariales críticas, como la restauración de operaciones y datos, y la comunicación con proveedores y partes interesadas. El desarrollo de una estrategia también es una parte fundamental de la planificación de la continuidad del negocio para tu proceso de CI/CD, especialmente en el paso de seleccionar estrategias de recuperación de alto nivel para las funciones críticas.
Entre los pasos clave de la fase de desarrollo de la estrategia se incluyen los siguientes:
- Estrategias de recuperación: desarrolla estrategias para restaurar las funciones críticas. Estas estrategias pueden incluir ubicaciones alternativas, trabajo remoto o sistemas de respaldo. Estas estrategias están vinculadas a los objetivos de RTO y RPO de cada función crítica.
- Relaciones con proveedores: establece planes de comunicación y coordinación con proveedores clave para que la cadena de suministro siga funcionando durante las interrupciones.
- Recuperación de datos y de TI: crea planes de copias de seguridad de datos, recuperación de sistemas de TI y medidas de ciberseguridad.
- Plan de comunicación: desarrolla un plan de comunicación claro para las partes interesadas internas y externas durante y después de una interrupción.
Desarrollo del plan
En esta fase, el paso principal es documentar el plan de continuidad de negocio. El equipo técnico documenta las herramientas, los procesos, las estrategias de recuperación, los fundamentos y los procedimientos de cada función crítica. El desarrollo del plan también incluye la redacción de instrucciones paso a paso que los empleados deben seguir durante una interrupción. Durante la implementación y el mantenimiento continuo, es posible que sea necesario introducir cambios en el plan, por lo que este debe considerarse un documento dinámico.
Implementación
En esta fase, se implementa el plan de tu organización mediante el plan de continuidad de negocio que ha creado el equipo técnico. La implementación incluye la formación de los empleados y las pruebas iniciales del plan de continuidad de negocio. La implementación también incluye el uso del plan si se produce una interrupción para recuperar las operaciones habituales. Estos son los pasos de implementación clave:
- Pruebas y formación iniciales: una vez que se haya documentado el BPC, pruébalo mediante simulaciones y ejercicios para identificar las carencias y mejorar su eficacia. Forma a los empleados sobre sus funciones y responsabilidades durante una interrupción.
- Activación: cuando se produce una interrupción, inicia el plan de continuidad de negocio de acuerdo con los activadores y procedimientos predefinidos.
- Comunicación: mantén informadas a las partes interesadas sobre la situación y las medidas de recuperación.
Mantenimiento y revisión
Esta fase no es un proceso definido que se produce una sola vez, sino que representa un esfuerzo continuo que debe convertirse en una parte normal de tus operaciones de integración continua y entrega continua. Es importante que revises, pruebes y actualices periódicamente el plan de continuidad de negocio de tu organización para que siga siendo relevante y útil en caso de que se produzca una interrupción. Estos son los pasos clave del mantenimiento y la revisión:
- Actualizaciones periódicas: revisa y actualiza el plan de continuidad de negocio periódicamente para que siga siendo actual y eficaz. Actualízala siempre que haya cambios en el personal, la tecnología o los procesos empresariales.
- Lecciones aprendidas: después de cada interrupción o prueba, haz una sesión informativa para identificar las lecciones aprendidas y las áreas de mejora.
- Cumplimiento de las normativas: adapta tu plan de continuidad de negocio a las normativas y los estándares del sector.
- Concienciación de los empleados: informa continuamente a los empleados sobre el plan de continuidad de negocio y sus funciones en su ejecución.
Crear un proceso de continuidad empresarial para CI/CD
En esta sección se ofrecen directrices específicas para crear un plan de continuidad de negocio centrado en restaurar tus operaciones de CI/CD. El proceso de planificación de la continuidad de negocio para CI/CD empieza con un conocimiento exhaustivo de tu cadena de herramientas de CI/CD y de cómo se relaciona con el ciclo de vida de la entrega y las operaciones de software. Con esta información como base, puedes planificar cómo recuperará tu organización las operaciones de CI/CD tras una interrupción.
Para crear un proceso de continuidad empresarial sólido para tu proceso de CI/CD, debes seguir estos pasos principales:
- Información sobre la cadena de herramientas
- Identificar datos y dependencias
- Determinar los objetivos de RTO y RPO
- Elegir una estrategia de alto nivel para la continuidad de la actividad empresarial
- Documenta tu plan de continuidad de negocio e implementa las prácticas recomendadas
- Escenarios de fallos en las pruebas y mantenimiento del plan
En las siguientes secciones se ofrece más información sobre cada uno de estos pasos.
Conocer la cadena de herramientas
Las cadenas de herramientas de CI/CD se componen de muchas herramientas individuales diferentes y las posibles combinaciones de herramientas pueden parecer infinitas. Sin embargo, es fundamental conocer tu cadena de herramientas de CI/CD y sus dependencias para planificar la continuidad de la actividad de CI/CD. El objetivo principal de tu proceso de CI/CD es entregar código a los sistemas de producción para que lo utilicen los usuarios finales. Durante ese proceso, se utilizan muchos sistemas y fuentes de datos diferentes. Conocer esas fuentes de datos y dependencias es fundamental para desarrollar un plan de continuidad de negocio. Para empezar a crear tu estrategia de recuperación ante desastres, primero debes conocer las diferentes herramientas que intervienen en tu proceso de CI/CD.
Para ayudarte a evaluar tu propia cadena de herramientas y desarrollar tu plan de continuidad de negocio, en este documento se utiliza el ejemplo de una aplicación Java empresarial que se ejecuta en GKE. En el siguiente diagrama se muestra la primera capa de datos y sistemas de la cadena de herramientas. Esta primera capa estaría bajo tu control directo e incluiría lo siguiente:
- La fuente de tus solicitudes
- Herramientas de tu plataforma de CI/CD, como Cloud Build o Cloud Deploy
- Interconexiones básicas de las diferentes herramientas
Como se muestra en el diagrama, el flujo principal de la aplicación de ejemplo es el siguiente:
- Eventos de desarrollo de código en el bucle interno de desarrollo que activan Cloud Build.
- Cloud Build extrae el código fuente de la aplicación del repositorio de control de versiones.
- Cloud Build identifica las dependencias necesarias que se especifican en los archivos de configuración de compilación, como los archivos JAR de terceros del repositorio de Java en Artifact Registry. A continuación, Cloud Build extrae estas dependencias de sus ubicaciones de origen.
- Cloud Build ejecuta la compilación y realiza la validación necesaria, como el análisis estático y las pruebas unitarias.
- Si la compilación se realiza correctamente, Cloud Build crea la imagen del contenedor y la envía al repositorio de contenedores de Artifact Registry.
- Se activa una canalización de Cloud Deploy, que extrae la imagen de contenedor del repositorio y la despliega en un entorno de GKE.
Para entender las herramientas que se usan en tu proceso de CI/CD, te recomendamos que crees un diagrama que muestre tu proceso de CI/CD y las herramientas que se usan en él, como el ejemplo de este documento. Después, puedes usar el diagrama para crear una tabla que recoja información clave sobre tu cadena de herramientas de CI/CD, como la fase del proceso, el propósito de la herramienta, la herramienta en sí y los equipos a los que afectaría un fallo de la herramienta. Esta tabla proporciona una asignación de las herramientas de tu cadena de herramientas e identifica las herramientas con fases específicas del proceso de integración continua y entrega continua. Por lo tanto, la tabla puede ayudarte a obtener una vista general de tu cadena de herramientas y de cómo funciona.
En las siguientes tablas se asigna el ejemplo mencionado anteriormente de una aplicación empresarial a cada herramienta del diagrama. Para ofrecer un ejemplo más completo de cómo podría ser una asignación de cadena de herramientas, estas tablas también incluyen otras herramientas que no se mencionan en el diagrama, como herramientas de seguridad o de prueba.
La primera tabla se corresponde con las herramientas que se usan en la fase de integración continua del proceso de CI/CD:
| Integración continua | Fuente | Herramientas utilizadas | Usuarios principales | Uso |
|---|---|---|---|---|
| Fase: control de código fuente |
|
|
|
|
| Fase: Creación |
|
Desarrolladores |
|
|
| Fase: prueba |
|
Desarrolladores |
Ejecuta pruebas unitarias y de integración en una plataforma coherente y bajo demanda. |
|
| Fase: seguridad |
|
|
Analiza el código para detectar problemas de seguridad. |
La segunda tabla se centra en las herramientas que se usan en la fase de CD del proceso de CI/CD:
| Despliegue continuo | Fuente | Herramientas utilizadas | Usuarios principales | Uso |
|---|---|---|---|---|
| Fase: implementación | Archivos de configuración de la implementación |
|
Automatiza los despliegues para promocionar, aprobar y gestionar el tráfico en una plataforma segura y coherente. |
|
| Fase: prueba |
|
|
Desarrolladores |
Prueba la integración y el rendimiento para comprobar la calidad y la usabilidad. |
| Fase: registro |
|
|
Mantener registros para la observabilidad y la solución de problemas. |
|
| Fase: monitorización | Monitorización de archivos de configuración, incluidos los siguientes:
|
|
|
A medida que sigas trabajando en tu plan de continuidad de negocio y aumente tu conocimiento de la cadena de herramientas de integración continua y entrega continua, podrás actualizar el diagrama y la tabla de asignación.
Identificar datos y dependencias
Una vez que hayas completado el inventario base y el mapa de tu cadena de herramientas de CI/CD, el siguiente paso es registrar las dependencias de metadatos o configuraciones. Cuando implementes tu plan de continuidad de negocio, es fundamental que conozcas bien las dependencias de tu cadena de herramientas de integración continua y entrega continua. Las dependencias suelen clasificarse en dos categorías: dependencias internas (de primer orden) y dependencias externas (de segundo o tercer orden).
Dependencias internas
Las dependencias internas son sistemas que usa tu cadena de herramientas y que controlas directamente. Tus equipos también seleccionan las dependencias internas. Entre estos sistemas se incluyen tu herramienta de integración continua, tu almacén de gestión de claves y tu sistema de control de versiones. Estos sistemas se encuentran en la capa inferior a la de la propia cadena de herramientas.
Por ejemplo, en el siguiente diagrama se muestra cómo encajan las dependencias internas en una cadena de herramientas. El diagrama amplía el diagrama de la cadena de herramientas de la primera capa anterior de la aplicación Java de ejemplo para incluir también las dependencias internas de la cadena de herramientas: las credenciales de la aplicación, el archivo deploy.yaml y el archivo cloudbuild.yaml.
El diagrama muestra que, para que la aplicación Java de ejemplo funcione correctamente, herramientas como Cloud Build, Cloud Deploy y GKE necesitan acceder a dependencias que no forman parte de la cadena de herramientas,como cloudbuild.yaml, deploy.yaml y las credenciales de la aplicación. Cuando analizas tu propia cadena de herramientas de CI/CD, evalúas si una herramienta puede ejecutarse por sí sola o si necesita llamar a otro recurso.
Ten en cuenta las dependencias internas documentadas de la aplicación Java de ejemplo.
Las credenciales se almacenan en Secret Manager, que no forma parte de la cadena de herramientas, pero son necesarias para que la aplicación se inicie en la implementación. Por lo tanto, las credenciales de la aplicación se incluyen como dependencia de GKE. También es importante incluir los archivos deploy.yaml y cloudbuild.yaml como dependencias, aunque estén almacenados en el control de versiones con el código de la aplicación, ya que definen la canalización de CI/CD de esa aplicación.
El plan de continuidad de negocio de la aplicación Java de ejemplo debe tener en cuenta estas dependencias de los archivos deploy.yaml y cloudbuild.yaml, ya que recrean la canalización de integración continua y entrega continua después de que las herramientas se hayan implementado durante el proceso de recuperación.
Además, si estas dependencias se ven comprometidas, la función general de la canalización se verá afectada aunque las herramientas sigan operativas.
Dependencias externas
Las dependencias externas son sistemas externos de los que depende tu cadena de herramientas para funcionar y no están bajo tu control directo. Las dependencias externas son el resultado de las herramientas y los frameworks de programación que has seleccionado. Puedes considerar las dependencias externas como otra capa por debajo de las dependencias internas. Algunos ejemplos de dependencias externas son los repositorios npm o Maven, y los servicios de monitorización.
Aunque las dependencias externas no están bajo tu control, puedes incorporarlas a tu PCO. En el siguiente diagrama se actualiza la aplicación Java de ejemplo para incluir dependencias externas, además de las internas: bibliotecas Java en Maven Central e imágenes de Docker en Docker Hub. Artifact Registry usa las bibliotecas de Java y Cloud Build usa las imágenes de Docker.
En el diagrama se muestra que las dependencias externas pueden ser importantes para tu proceso de CI/CD: tanto Cloud Build como GKE dependen de dos servicios externos (Maven y Docker) para funcionar correctamente. Cuando evalúes tu cadena de herramientas, documenta tanto las dependencias externas a las que deben acceder tus herramientas como los procedimientos para gestionar las interrupciones de las dependencias.
En la aplicación Java de ejemplo, las bibliotecas Java y las imágenes de Docker no se pueden controlar directamente, pero sí se pueden incluir junto con sus procedimientos de recuperación en el PCO. Por ejemplo, considere las bibliotecas de Java en Maven. Aunque las bibliotecas se almacenan en una fuente externa, puedes establecer un proceso para descargar y actualizar periódicamente las bibliotecas de Java en un repositorio local de Maven o en Artifact Registry. De esta forma, el proceso de recuperación no dependerá de la disponibilidad de la fuente de terceros.
Además, es importante tener en cuenta que las dependencias externas pueden tener más de una capa. Por ejemplo, puedes considerar que los sistemas que usan tus dependencias internas son dependencias de segundo orden. Estas dependencias de segundo orden pueden tener sus propias dependencias, que se pueden considerar dependencias de tercer orden. Ten en cuenta que es posible que tengas que documentar y contabilizar las dependencias externas de segundo y tercer orden en tu plan de continuidad de negocio para poder recuperar las operaciones durante una interrupción.
Determinar los objetivos de RTO y RPO
Una vez que conozcas tu cadena de herramientas y tus dependencias, define los objetivos de RTO y RPO de tus herramientas. Las herramientas del proceso de CI/CD realizan acciones diferentes que pueden tener un impacto distinto en la empresa. Por lo tanto, es importante que los objetivos de RTO y RPO de la función empresarial coincidan con su impacto en la empresa. Por ejemplo, crear nuevas versiones de aplicaciones en la fase de integración continua podría tener menos impacto que desplegar aplicaciones en la fase de entrega continua. Por lo tanto, las herramientas de implementación podrían tener objetivos de RTO y RPO más largos que otras funciones.
El siguiente gráfico de cuatro cuadrantes es un ejemplo general de cómo puedes determinar tus objetivos de RTO y RPO para cada componente de la cadena de herramientas de CI/CD. La cadena de herramientas asignada en este gráfico incluye herramientas como una canalización de IaC y fuentes de datos de prueba. Las herramientas no se mencionaron en los diagramas anteriores de la aplicación Java, pero se incluyen aquí para ofrecer un ejemplo más completo.
El gráfico muestra cuadrantes basados en el nivel de impacto en los desarrolladores y las operaciones. En el gráfico, los componentes se colocan de la siguiente manera:
- Impacto moderado en los desarrolladores e impacto bajo en las operaciones: fuentes de datos de prueba
- Impacto moderado en los desarrolladores e impacto moderado en las operaciones: Cloud Key Management Service y Cloud KMS
- Impacto moderado en los desarrolladores e impacto alto en las operaciones: canalización de implementación
- Alto impacto en los desarrolladores y bajo impacto en las operaciones: bucle interno de desarrollo
- Alto impacto en los desarrolladores e impacto moderado en las operaciones: flujo de procesamiento de CI y flujo de procesamiento de infraestructura como código (IaC)
- Alto impacto en los desarrolladores y en las operaciones: gestión del control de versiones (SCM) y Artifact Registry
Los componentes que tienen un gran impacto en los desarrolladores y en las operaciones, como la gestión del control de versiones y Artifact Registry, son los que más influyen en la empresa. Estos componentes deben tener los objetivos de RTO y RPO más bajos. Los componentes de los otros cuadrantes tienen una prioridad más baja, lo que significa que los objetivos de RTO y RPO serán más altos. En general, los objetivos de RTO y RPO de los componentes de tu cadena de herramientas deben definirse en función de la cantidad de datos o de configuración que se pueda tolerar en comparación con el tiempo que se debe tardar en restaurar el servicio de ese componente.
Por ejemplo, considera las diferentes ubicaciones de Artifact Registry y la canalización de IaC en el gráfico. Una comparación de estas dos herramientas muestra que una interrupción de Artifact Registry tiene un mayor impacto en las operaciones empresariales que una interrupción en la canalización de IaC. Como una interrupción de Artifact Registry afecta significativamente a tu capacidad para desplegar o escalar automáticamente tu aplicación, tendría objetivos de RTO y RPO inferiores en comparación con otras herramientas. Por el contrario, el gráfico muestra que una interrupción de la canalización de IaC tiene un impacto menor en las operaciones empresariales que otras herramientas. La canalización de IaC tendría objetivos de RTO y RPO más altos, ya que puedes usar otros métodos para implementar o actualizar la infraestructura durante una interrupción.
Elegir una estrategia de alto nivel para la continuidad del negocio
Los procesos de continuidad de la actividad de las aplicaciones de producción suelen basarse en una de las tres estrategias de recuperación ante desastres habituales. Sin embargo, en el caso de la integración y la entrega continuas, puedes elegir entre dos estrategias de alto nivel para la continuidad de la actividad empresarial: activa/pasiva o copia de seguridad/restauración. La estrategia que elijas dependerá de tus requisitos y tu presupuesto. Cada estrategia tiene ventajas e inconvenientes en cuanto a complejidad y coste, y debes tener en cuenta diferentes aspectos para tu proceso de integración continua y entrega continua. En las siguientes secciones se ofrecen más detalles sobre cada estrategia y sus ventajas e inconvenientes.
Además, cuando se producen eventos que interrumpen el servicio, pueden afectar a más elementos que a tu implementación de CI/CD. También debes tener en cuenta toda la infraestructura que necesitas, como la red, la computación y el almacenamiento. Debes tener un plan de recuperación ante desastres para esos componentes básicos y probarlo periódicamente para asegurarte de que es eficaz.
Activo/pasivo
Con la estrategia activa/pasiva (o de espera activa), tus aplicaciones y la canalización de CI/CD pasiva son idénticas. Sin embargo, el flujo de procesamiento pasivo no gestiona la carga de trabajo del cliente ni ninguna compilación o implementación, por lo que se encuentra en un estado reducido. Esta estrategia es la más adecuada para las aplicaciones críticas para la empresa en las que se puede tolerar un pequeño periodo de inactividad.
En el siguiente diagrama se muestra una configuración activo-pasivo para la aplicación Java de ejemplo que se usa en este documento. La canalización pasiva duplica por completo la cadena de herramientas de la aplicación en otra región.
En este ejemplo, region1 aloja la canalización de CI/CD activa y region2 tiene la contraparte pasiva. El código está alojado en un proveedor de servicios Git externo, como GitHub o GitLab. Un evento de repositorio (como una combinación de una solicitud de extracción) puede activar el flujo de procesamiento de CI/CD en la región 1 para compilar, probar y desplegar en el entorno de producción multirregional.
Si se produce un problema crítico en la canalización de la región 1, como una interrupción regional de un producto, el resultado podría ser que las implementaciones o las compilaciones fallen. Para recuperarte rápidamente del problema, puedes actualizar el activador del repositorio de Git y cambiar a la canalización region2, que se convertirá en la activa. Una vez que se haya resuelto el problema en region1, puedes mantener la canalización en region1 como pasiva.
Entre las ventajas de la estrategia activa/pasiva se incluyen las siguientes:
- Tiempo de inactividad bajo: como la canalización pasiva se ha implementado, pero se ha reducido, el tiempo de inactividad se limita al tiempo necesario para aumentar la escala de la canalización.
- Tolerancia configurable a la pérdida de datos: con esta estrategia, la configuración y el artefacto deben sincronizarse periódicamente. Sin embargo, la cantidad se puede configurar en función de tus requisitos, lo que puede reducir la complejidad.
Entre las desventajas de esta estrategia se incluyen las siguientes:
- Coste: con una infraestructura duplicada, esta estrategia aumenta el coste total de la infraestructura de CI/CD.
Copia de seguridad o restauración
Con la estrategia de copia de seguridad y restauración, solo creas tu canalización de conmutación por error cuando sea necesario durante la recuperación tras un incidente. Esta estrategia es la más adecuada para casos prácticos de menor prioridad. En el siguiente diagrama se muestra una configuración de copia de seguridad y restauración para la aplicación Java de ejemplo. La configuración de copia de seguridad solo duplica una parte del flujo de procesamiento de CI/CD de la aplicación en otra región.
Al igual que en el ejemplo anterior, region1 aloja la canalización de CI/CD activa. En lugar de tener una canalización pasiva en la región 2, esta solo tiene copias de seguridad de los datos regionales necesarios, como los paquetes Maven y las imágenes de contenedor. Si aloja sus repositorios de origen en la región 1, también debe sincronizar los datos con sus ubicaciones de recuperación ante desastres.
Del mismo modo, si se produce un problema crítico en la canalización de la región 1, como una interrupción del servicio de un producto regional, puedes restaurar tu implementación de CI/CD en la región 2. Si el código de infraestructura se almacena en el repositorio de código de infraestructura, puede ejecutar la secuencia de comandos de automatización desde el repositorio y volver a compilar el flujo de procesamiento de CI/CD en la región 2.
Si la interrupción es un evento a gran escala, es posible que compitas con otros clientes por los recursos en la nube. Una forma de mitigar esta situación es tener varias opciones para la ubicación de recuperación ante desastres. Por ejemplo, si tu canal de la región 1 está en us-east1, tu región de conmutación por error puede ser us-east4, us-central1 o us-west1.
Estas son algunas de las ventajas de la estrategia de copia de seguridad y restauración:
- Coste: esta estrategia incurre en el coste más bajo porque solo implementas la canalización de copia de seguridad durante las situaciones de recuperación ante desastres.
Entre las desventajas de esta estrategia se incluyen las siguientes:
- Tiempo de inactividad: esta estrategia requiere más tiempo para implementarse, ya que creas la canalización de conmutación por error cuando la necesitas. En lugar de tener una canalización precompilada, los servicios deben crearse y configurarse durante la recuperación de incidentes. El tiempo de compilación de los artefactos y el tiempo necesario para obtener las dependencias externas también podrían ser significativamente más largos.
Documenta tu plan de continuidad de negocio e implementa las prácticas recomendadas
Una vez que hayas asignado tu cadena de herramientas de CI/CD, identificado sus dependencias y determinado los objetivos de RTO y RPO de las funciones críticas, el siguiente paso es documentar toda la información pertinente en un plan de continuidad de negocio por escrito. Cuando crees tu plan de continuidad de negocio, documenta las estrategias, los procesos y los procedimientos para restaurar cada función crítica. Este proceso de documentación incluye la redacción de procedimientos paso a paso para que los empleados con funciones específicas los sigan durante una interrupción.
Una vez que hayas definido tu plan de continuidad de negocio, implementa o actualiza tu cadena de herramientas de CI/CD siguiendo las prácticas recomendadas para alcanzar tus objetivos de RTO y RPO. Aunque las cadenas de herramientas de CI/CD pueden ser muy diferentes, hay dos patrones clave de prácticas recomendadas que son comunes independientemente de la cadena de herramientas: comprender las dependencias en profundidad e implementar la automatización.
En cuanto a las dependencias, la mayoría de los PCCCs se dirigen a los sistemas que están directamente bajo tu control. Sin embargo, recuerda que las dependencias externas de segundo o tercer orden pueden tener el mismo impacto, por lo que es importante implementar prácticas recomendadas y medidas de redundancia para esas dependencias críticas también. Las bibliotecas Java externas de la aplicación de ejemplo son un ejemplo de dependencias de tercer orden. Si no tienes un repositorio local o una copia de seguridad de esas bibliotecas, es posible que no puedas compilar tu aplicación si la fuente externa de la que obtienes las bibliotecas está desconectada.
En cuanto a la automatización, la implementación de las prácticas recomendadas debe incorporarse a tu estrategia de IaC en la nube. Tu solución de IaC debe usar herramientas como Terraform para aprovisionar automáticamente los recursos necesarios de tu implementación de CI/CD y configurar los procesos. Las prácticas de IaC son procedimientos de recuperación muy eficaces porque se incorporan al funcionamiento diario de tus canalizaciones de CI/CD. Además, IaC fomenta el almacenamiento de los archivos de configuración en el control de código fuente, lo que a su vez promueve la adopción de las prácticas recomendadas para las copias de seguridad.
Después de implementar tu cadena de herramientas de acuerdo con tu plan de continuidad de negocio y las prácticas recomendadas para las dependencias y la automatización, es posible que cambien tu proceso de CI/CD y tus estrategias de recuperación. Asegúrate de documentar cualquier cambio en las estrategias, los procesos y los procedimientos de recuperación que se produzcan como resultado de la revisión del plan de continuidad de negocio y de la implementación de las prácticas recomendadas.
Prueba los escenarios de fallos y mantén el plan
Es fundamental que revises, pruebes y actualices tu plan de continuidad de negocio periódicamente. Al probar los procedimientos de continuidad de la actividad y de recuperación, se verifica que el plan sigue siendo válido y que los objetivos de RPO y RTO documentados son aceptables. Sin embargo, lo más importante es que las pruebas, las actualizaciones y el mantenimiento periódicos hacen que la ejecución del plan de continuidad de negocio forme parte de las operaciones normales. Con Google Cloud, puede probar escenarios de recuperación con un coste mínimo. Para ayudarte con las pruebas, te recomendamos que hagas lo siguiente:
- Automatiza el aprovisionamiento de la infraestructura con una herramienta de IaC: puedes usar herramientas como Terraform para automatizar el aprovisionamiento de la infraestructura de CI/CD.
- Monitoriza y depura tus pruebas con Cloud Logging y Cloud Monitoring: Google Cloud Observability proporciona herramientas de registro y monitorización a las que puedes acceder mediante llamadas a la API, lo que significa que puedes automatizar la implementación de escenarios de recuperación reaccionando a las métricas. Cuando diseñes pruebas, asegúrate de que tienes configurados sistemas de monitorización y alertas adecuados que puedan activar las acciones de recuperación pertinentes.
- Realiza las pruebas en tu plan de continuidad de negocio: por ejemplo, puedes comprobar si los permisos y el acceso de los usuarios funcionan en el entorno de recuperación ante desastres como lo hacen en el entorno de producción. Puedes realizar pruebas de integración y funcionales en tu entorno de recuperación ante desastres. También puedes hacer una prueba en la que tu ruta de acceso habitual a Google Cloud no funcione.
En Google, probamos periódicamente nuestro Plan de Continuidad de la Actividad Empresarial mediante un proceso llamado DiRT (Disaster Recovery Testing). Estas pruebas ayudan a Google a verificar los impactos y la automatización, así como a exponer los riesgos no contabilizados. Los cambios en la automatización y el plan de continuidad de negocio que deben implementarse son un resultado importante de DiRT.
Prácticas recomendadas
En esta sección, aprenderá algunas prácticas recomendadas que puede implementar para alcanzar sus objetivos de RTO y RPO. Estas prácticas recomendadas se aplican de forma general a la recuperación ante desastres para CI/CD y no a herramientas específicas. Independientemente de la implementación, debe probar su plan de continuidad de negocio periódicamente para asegurarse de que la alta disponibilidad, el tiempo de recuperación y el punto de recuperación cumplan sus requisitos. Si se produce un incidente o un desastre, también debes hacer una retrospectiva y analizar el proceso para poder mejorarlo.
Alta disponibilidad
En cada herramienta, debes implementar las prácticas recomendadas para conseguir una alta disponibilidad. Si sigues las prácticas recomendadas de alta disponibilidad, tu proceso de CI/CD será más proactivo, ya que estas prácticas hacen que el proceso de CI/CD sea más resistente a los fallos. Estas estrategias proactivas deben usarse junto con controles y procedimientos más reactivos para la recuperación y la copia de seguridad.
A continuación, se indican algunas prácticas recomendadas para conseguir una alta disponibilidad. Sin embargo, consulta la documentación detallada de cada herramienta de tu CI/CD para obtener más información sobre las prácticas recomendadas:
- Servicios gestionados: al usar servicios gestionados, la responsabilidad operativa pasa a Google Cloud.
- Autoescalado: cuando sea posible, usa el autoescalado. Un aspecto clave del autoescalado es que las instancias de trabajador se crean de forma dinámica, por lo que la recuperación de los nodos fallidos es automática.
- Despliegues globales y multirregionales: cuando sea posible, utiliza despliegues globales y multirregionales en lugar de despliegues regionales. Por ejemplo, puedes configurar Artifact Registry para el almacenamiento multirregional.
- Dependencias: conoce todas las dependencias de tus herramientas y asegúrate de que tengan una alta disponibilidad. Por ejemplo, puede almacenar en caché todas las bibliotecas de terceros en su registro de artefactos.
Procedimientos de copia de seguridad
Cuando implementas la recuperación ante desastres para CI/CD, algunas herramientas y procesos son más adecuados para las estrategias de copia de seguridad y restauración. Una estrategia de copia de seguridad completa es el primer paso para implementar controles reactivos eficaces. Las copias de seguridad te permiten recuperar tu flujo de procesamiento de CI/CD con una interrupción mínima en caso de que haya agentes perniciosos o desastres.
Para empezar, debes implementar las tres prácticas recomendadas que se indican a continuación. Sin embargo, para obtener información más detallada sobre las prácticas recomendadas de copias de seguridad, consulta la documentación de cada herramienta de tu proceso de CI/CD.
- Control de versiones: almacena los archivos de configuración y todo lo que codifiques, como las secuencias de comandos de automatización y las políticas, en el control de versiones. Por ejemplo, los archivos
cloudbuild.yamly YAML de Kubernetes. - Redundancia: asegúrate de que no haya un único punto de fallo en lo que respecta al acceso a secretos, como contraseñas, certificados y claves de API. Por ejemplo, no debe permitir que solo una persona conozca la contraseña ni almacenar la clave de API en un único servidor de una región concreta.
- Copias de seguridad: verifica con frecuencia que tus copias de seguridad estén completas y sean precisas. Los servicios gestionados, como Backup for GKE, te ayudarán a simplificar el proceso de verificación.
Procedimientos de recuperación
La recuperación tras desastres también requiere procedimientos de recuperación que complementen los procesos de copia de seguridad. Tus procedimientos de recuperación, combinados con copias de seguridad completas, determinarán la rapidez con la que puedas responder a situaciones de desastre.
Gestión de dependencias
Tu flujo de procesamiento de CI/CD puede tener muchas dependencias, que también pueden ser fuentes de errores. En este documento, en la sección Identificar datos y dependencias, se indica cómo identificar una lista completa de las dependencias. Sin embargo, las dos fuentes de dependencias más habituales son las siguientes:
- Artefactos de aplicación: por ejemplo, paquetes, bibliotecas e imágenes
- Sistemas externos: por ejemplo, sistemas de incidencias y de notificaciones
Una forma de mitigar los riesgos de las dependencias es adoptar la práctica de incluir dependencias. El vendor de paquetes o imágenes de aplicaciones es el proceso de crear y almacenar copias de ellos en un repositorio privado. El proveedor elimina la dependencia de fuentes externas para estos paquetes o imágenes, y también puede ayudar a evitar que se inserte malware en la cadena de suministro de software.
Estas son algunas de las ventajas de incluir paquetes o imágenes de aplicaciones de terceros:
- Seguridad: el vendoring elimina la dependencia de fuentes externas para los paquetes o las imágenes de aplicaciones, lo que puede ayudar a evitar ataques de inserción de malware.
- Control: al incluir sus propios paquetes o imágenes, las organizaciones pueden tener más control sobre el origen de estos paquetes e imágenes.
- Cumplimiento: la contratación de proveedores puede ayudar a las organizaciones a cumplir las normativas del sector, como la certificación del modelo de madurez en ciberseguridad (CMMC).
Si tu equipo decide usar paquetes o imágenes de aplicaciones de proveedores, sigue estos pasos principales:
- Identifica los paquetes de aplicaciones o las imágenes que se deben incluir.
- Crea un repositorio privado para almacenar los paquetes o las imágenes de terceros.
- Descarga los paquetes o las imágenes de la fuente original y almacénalos en el repositorio privado.
- Verifica la integridad de los paquetes o las imágenes.
- Actualiza los paquetes o las imágenes de proveedores según sea necesario.
Las pipelines de CI/CD suelen llamar a sistemas de terceros para realizar acciones como ejecutar análisis, registrar incidencias o enviar notificaciones. En la mayoría de los casos, estos sistemas de terceros tienen sus propias estrategias de recuperación ante desastres, que deben implementarse. Sin embargo, en algunos casos puede que no tengan un plan de recuperación ante desastres adecuado, y esas instancias deben documentarse claramente en el plan de continuidad de negocio. Después, debes decidir si se pueden omitir esas fases del flujo de procesamiento por motivos de disponibilidad o si es aceptable que el flujo de procesamiento de CI/CD tenga un tiempo de inactividad.
Monitorización y notificaciones
Tu CI/CD es como los sistemas de producción de tu aplicación, por lo que también debes implementar técnicas de monitorización y notificación para tus herramientas de CI/CD. Como práctica recomendada, te aconsejamos que implementes paneles de control y notificaciones de alertas. El repositorio de ejemplo de GitHub de Cloud Monitoring contiene muchos ejemplos de paneles de control y políticas de alertas.
También puedes implementar niveles de monitorización adicionales, como los indicadores de nivel de servicio y los objetivos de nivel de servicio. Estos niveles de monitorización te ayudan a hacer un seguimiento del estado y el rendimiento generales de tus pipelines de CI/CD. Por ejemplo, se pueden implementar SLOs para monitorizar la latencia de las fases de compilación y despliegue. Estos SLOs ayudan a los equipos a crear y lanzar aplicaciones con la frecuencia que quieras.
Procedimientos de acceso de emergencia
Durante una catástrofe, es posible que los equipos de operaciones tengan que tomar medidas que no se ajusten a los procedimientos estándar y obtener acceso de emergencia a sistemas y herramientas. Estas acciones de emergencia se denominan en ocasiones procedimientos de acceso de emergencia. Para empezar, le recomendamos que implemente estas tres prácticas recomendadas:
- Tener un plan y un procedimiento de derivación claros. Un plan claro ayuda al equipo de operaciones a saber cuándo debe usar los procedimientos de acceso de emergencia.
- Asegúrate de que varias personas tengan acceso a información crítica, como la configuración y los secretos.
- Desarrolla métodos de auditoría automatizados para poder hacer un seguimiento de cuándo y quién ha usado los procedimientos de acceso de emergencia.
Siguientes pasos
- Consulta más información sobre los productos de Google Cloud que se mencionan en este documento:
- Consulta la guía de planificación para la recuperación tras fallos.
- Prueba otras Google Cloud funciones completando nuestros tutoriales.
- Para ver más arquitecturas de referencia, diagramas y prácticas recomendadas, consulta el centro de arquitectura de Cloud.
Colaboradores
Autores:
- Ben Good | Arquitecto de soluciones
- Xiang Shen | Arquitecto de soluciones
Otros colaboradores:
- Marco Ferrari | Arquitecto de soluciones en la nube
- Anuradha Bajpai | Arquitecta de soluciones
- Rodd Zurcher | Arquitecto de soluciones