En este documento, se describen la recuperación ante desastres (DR) y la planificación de la continuidad empresarial en el contexto de la integración continua y la entrega continua (CI/CD). También proporciona orientación sobre cómo identificar y mitigar las dependencias cuando desarrollas un plan de continuidad empresarial (BCP) integral. El documento incluye prácticas recomendadas que puedes aplicar a tu BCP, independientemente de las herramientas y los procesos que utilices. En el documento, se supone que conoces los conceptos básicos del ciclo de operaciones y entrega de software, CI/CD y DR.
Las canalizaciones de CI/CD son responsables de compilar e implementar tus aplicaciones fundamentales para la empresa. Por lo tanto, al igual que la infraestructura de tu aplicación, tu proceso de CI/CD requiere planificación para la DR y la continuidad empresarial. Cuando piensas en la DR y la continuidad del negocio para la CI/CD, es importante comprender cada fase del ciclo de operaciones y entrega de software, y comprender cómo funcionan en conjunto como un proceso integral.
El siguiente diagrama es una vista simplificada del ciclo de operaciones y desarrollo de software, que incluye las siguientes tres fases:
- Bucle interno de desarrollo: código, prueba y confirmación
- Integración continua: compilación, pruebas y seguridad
- Entrega continua: promoción, lanzamiento, reversión y métricas
Este diagrama también muestra que Google Kubernetes Engine (GKE), Cloud Run y Google Distributed Cloud son posibles destinos de implementación del ciclo de operaciones y desarrollo de software.
A lo largo del ciclo de operaciones y desarrollo de software, debes considerar el impacto de un desastre en la capacidad de los equipos para operar y mantener aplicaciones esenciales para la empresa. Esto te ayudará a determinar el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO) para 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 diferentes aplicaciones y conjuntos de infraestructura, y cada canalización tiene requisitos únicos para la planificación de DR y la continuidad empresarial. La estrategia de recuperación que elijas para una canalización variará según el RTO y el RPO de tus herramientas. Por ejemplo, algunas canalizaciones son más importantes que otras y tendrán requisitos de RTO y RPO más bajos. Es importante identificar las canalizaciones críticas para el negocio en tu BCP, y también deben recibir más atención cuando implementes las prácticas recomendadas para probar y ejecutar procedimientos de recuperación.
Debido a que cada proceso de CI/CD y su cadena de herramientas son diferentes, los objetivos de esta guía son ayudarte a identificar los puntos únicos de fallo en tu proceso de CI/CD y desarrollar un BCP integral. En las siguientes secciones, encontrarás información que te ayudará a hacer lo siguiente:
- Comprende lo que se necesita para recuperarse de un evento de DR que afecta tu proceso de CI/CD.
- Determina el RTO y el RPO de las herramientas de tu proceso de CI/CD.
- Comprende los modos de falla y las dependencias de tu proceso de CI/CD.
- Elige una estrategia de recuperación adecuada para las herramientas de tu cadena de herramientas.
- Comprende las prácticas recomendadas generales para implementar un plan de recuperación DR para tu proceso de CI/CD.
Comprende el proceso de continuidad del negocio
Crear un BCP es fundamental para garantizar que tu organización pueda continuar con sus operaciones en caso de interrupciones y emergencias. Ayuda a tu organización a volver rápidamente a un estado de operaciones normales para su proceso de CI/CD.
En las siguientes secciones, se describen las etapas de alto nivel que incluyen los pasos que se deben seguir para crear un BCP eficaz. Aunque muchos de estos pasos se aplican de manera general a la administración de programas y a la DR, algunos son más relevantes para planificar la continuidad empresarial de tu proceso de CI/CD. En las siguientes secciones, se destacan los pasos que son específicamente relevantes para planificar la continuidad empresarial de CI/CD, y también forman la base para la orientación en el resto de este documento.
Iniciación y planificación
En esta etapa inicial, los equipos técnicos y empresariales trabajan juntos para establecer las bases del proceso de planificación de la continuidad empresarial y su mantenimiento continuo. Estos son los pasos clave de esta etapa:
- Consecución de la aceptación de los líderes: Asegúrate de que la administración sénior apoye y defienda el desarrollo del BCP. Asigna un equipo dedicado o una persona que sea responsable de supervisar el plan.
- Asignación de recursos: Asignar el presupuesto, el personal y los recursos necesarios para desarrollar e implementar el BCP
- Alcance y objetivos: Define el alcance de tu BCP y sus objetivos. Determina qué procesos empresariales son fundamentales y deben abordarse en el plan.
- Evaluación de riesgos: Identifica los posibles riesgos y amenazas que podrían interrumpir tu empresa, como desastres naturales, violaciones de la seguridad cibernética o interrupciones de la cadena de suministro.
- Análisis del impacto: Evalúa las posibles consecuencias de estos hallazgos 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 del impacto comercial
En esta etapa, los equipos comerciales y técnicos analizan el impacto comercial de las interrupciones en tus clientes y tu organización, y priorizan la recuperación de las funciones comerciales críticas. Estas funciones empresariales las realizan diferentes herramientas durante las diferentes fases de un proceso de compilación e implementación.
El análisis de impacto comercial es una etapa importante en el proceso de planificación de la continuidad de la actividad para CI/CD, en especial los pasos para identificar las funciones comerciales y las dependencias de herramientas críticas. Además, comprender tu cadena de herramientas de CI/CD, incluidas sus dependencias y cómo funciona dentro del ciclo de vida de DevOps, es un elemento básico para desarrollar un BCP para tu proceso de CI/CD.
Los pasos clave en la etapa de análisis del impacto comercial incluyen los siguientes:
- Funciones críticas: Determina las funciones y los procesos comerciales clave que se deben priorizar para la recuperación. Por ejemplo, si determinas que implementar aplicaciones es más importante que ejecutar pruebas de unidades, priorizarías la recuperación para los procesos y las herramientas de implementación de aplicaciones.
- Dependencias: Identifica las dependencias internas y externas que podrían afectar la recuperación de tus funciones críticas. Las dependencias son especialmente relevantes para garantizar el funcionamiento continuo de tu proceso de CI/CD a través de su cadena de herramientas.
- RTO y RPO: Definen los límites aceptables de inactividad y pérdida de datos para cada función crítica. Estos objetivos de RTO y RPO están vinculados a la importancia de una función empresarial para que las operaciones continúen y abarcan herramientas específicas que se necesitan para que la función empresarial funcione sin problemas.
Desarrollo de estrategias
En esta etapa, el equipo técnico desarrolla estrategias de recuperación para funciones comerciales críticas, como restablecer operaciones y datos, y comunicarse con proveedores y partes interesadas. El desarrollo de estrategias también es una parte clave de la planificación de la continuidad empresarial para tu proceso de CI/CD, en especial el paso de seleccionar estrategias de recuperación de alto nivel para funciones críticas.
Los pasos clave en la etapa de desarrollo de la estrategia incluyen los siguientes:
- Estrategias de recuperación: Desarrolla estrategias para restablecer funciones críticas. Estas estrategias pueden incluir ubicaciones alternativas, trabajo remoto o sistemas de copia de seguridad. 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 mantener la cadena de suministro en funcionamiento durante las interrupciones.
- Recuperación de datos y TI: Crea planes para la copia de seguridad de datos, la recuperación de sistemas de TI y las medidas de seguridad cibernética.
- 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 etapa, el paso principal es documentar el BCP. 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 escribir instrucciones paso a paso para que los empleados las sigan durante una interrupción. Durante la implementación y el mantenimiento continuo, es posible que se deban realizar cambios en el plan, y este debe tratarse como un documento dinámico.
Implementación
En esta etapa, implementas el plan de tu organización con el BCP que creó el equipo técnico. La implementación incluye la capacitación de los empleados y las pruebas iniciales del BCP. La implementación también incluye el uso del plan si se produce una interrupción para recuperar las operaciones normales. Entre los pasos clave de la implementación, se incluyen los siguientes:
- Pruebas y capacitación iniciales: Después de documentar el BPC, pruébalo a través de simulaciones y ejercicios para identificar las brechas y mejorar la eficacia. Capacita a los empleados sobre sus roles y responsabilidades durante una interrupción.
- Activación: Cuando se produce una interrupción, inicia el BCP según los activadores y procedimientos predefinidos.
- Comunicación: Mantén informadas a las partes interesadas sobre la situación y las iniciativas de recuperación.
Mantenimiento y revisión
Esta etapa no es un proceso definido que ocurre solo una vez, sino que representa un esfuerzo continuo y continuo que debe convertirse en una parte normal de tus operaciones de CI/CD. Es importante revisar, probar y actualizar el BCP de forma periódica en tu organización para que siga siendo relevante y práctico si se produce una interrupción. Entre los pasos clave del mantenimiento y la revisión, se incluyen los siguientes:
- Actualizaciones periódicas: Revisa y actualiza el BCP periódicamente para que permanezca vigente y eficaz. Actualízala cada vez que haya cambios en el personal, la tecnología o los procesos empresariales.
- Lecciones aprendidas: Después de cada interrupción o prueba, realiza un informe para identificar las lecciones aprendidas y las áreas de mejora.
- Cumplimiento normativo: Alinea tu BCP con las reglamentaciones y los estándares de la industria.
- Concienciación de los empleados: Educa a los empleados de forma continua sobre el BCP y sus roles en su ejecución.
Crea un proceso de continuidad empresarial para CI/CD
En esta sección, se proporcionan lineamientos específicos para crear un BCP que se enfoque específicamente en restablecer tus operaciones de CI/CD. El proceso de planificación de la continuidad empresarial para CI/CD comienza con una comprensión profunda de tu cadena de herramientas de CI/CD y cómo se vincula con el ciclo de vida de las operaciones y la entrega de software. Con esta comprensión como base, puedes planificar cómo tu organización recuperará sus operaciones de CI/CD después de una interrupción.
Para crear un proceso sólido de continuidad del negocio para tu proceso de CI/CD, debes seguir los siguientes pasos principales:
- Información sobre la cadena de herramientas
- Identifica los datos y las dependencias
- Determina los objetivos de RTO y RPO
- Elige una estrategia de alto nivel para la continuidad del negocio
- Documenta tu BCP y, luego, implementa las prácticas recomendadas
- Prueba situaciones de falla y mantén el plan
En las siguientes secciones, se proporcionan más detalles sobre cada uno de estos pasos.
Comprende 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, comprender tu cadena de herramientas de CI/CD y sus dependencias es clave para la planificación de la continuidad empresarial de CI/CD. La misión principal de tu proceso de CI/CD es entregar código a los sistemas de producción para el consumo del usuario final. A lo largo de ese proceso, se usan muchos sistemas y fuentes de datos diferentes. Conocer esas fuentes de datos y dependencias es fundamental para desarrollar un BCP. Para comenzar a crear tu estrategia de DR, primero debes comprender las diferentes herramientas involucradas en tu proceso de CI/CD.
Para ayudarte a comprender cómo evaluar tu propia cadena de herramientas y desarrollar tu BCP, en este documento, se usa el ejemplo de una aplicación empresarial de Java que se ejecuta en GKE. En el siguiente diagrama, se muestra la primera capa de datos y sistemas en la cadena de herramientas. Esta primera capa estaría bajo tu control directo y, además, incluye lo siguiente:
- La fuente de tus aplicaciones
- 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:
- Los eventos de desarrollo de código en el bucle interno del desarrollador activan Cloud Build.
- Cloud Build extrae el código fuente de la aplicación del repositorio de control de código fuente.
- 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. Luego, 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 prueba de unidades.
- Si la compilación tiene éxito, Cloud Build crea la imagen del contenedor y la envía al repositorio de contenedores en Artifact Registry.
- Se activa una canalización de Cloud Deploy, que extrae la imagen de contenedor del repositorio y la implementa en un entorno de GKE.
Para comprender las herramientas que se usan en tu proceso de CI/CD, te sugerimos que crees un diagrama que muestre tu proceso de CI/CD y las herramientas que se usan en él, similar al ejemplo de este documento. Luego, puedes usar tu diagrama para crear una tabla que capture 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 que se ven afectados por una falla de la herramienta. Esta tabla proporciona una asignación de las herramientas de tu cadena de herramientas y las identifica con fases específicas del proceso de CI/CD. Por lo tanto, la tabla puede ayudarte a obtener una vista general de tu cadena de herramientas y cómo funciona.
En las siguientes tablas, se asigna el ejemplo de una aplicación empresarial que se mencionó anteriormente a cada herramienta del diagrama. Para proporcionar un ejemplo más completo de cómo podría verse 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 asigna herramientas que se usan en la fase de CI del proceso de CI/CD:
| Integración continua | Fuente | Herramientas utilizadas | Usuarios principales | Uso |
|---|---|---|---|---|
| Fase: Control de código fuente |
|
|
|
|
| Fase: compilación |
|
Desarrolladores |
|
|
| Fase: Prueba |
|
Desarrolladores |
Ejecuta pruebas de integración y unidad en una plataforma coherente y on demand. |
|
| Fase: Seguridad |
|
|
Escanea el código para detectar problemas de seguridad. |
La segunda tabla se enfoca en las herramientas que se usan en la fase de CD del proceso de CI/CD:
| Implementación continua | Fuente | Herramientas utilizadas | Usuarios principales | Uso |
|---|---|---|---|---|
| Fase: Deployment | Archivos de configuración de Deployment |
|
Automatiza las implementaciones para promocionar, aprobar y administrar el tráfico en una plataforma segura y coherente. |
|
| Fase: Prueba |
|
|
Desarrolladores |
Prueba la integración y el rendimiento para verificar la calidad y la usabilidad. |
| Fase: Registro |
|
|
Conserva los registros para la observabilidad y la solución de problemas. |
|
| Fase: Supervisión | Supervisión de archivos de configuración, incluidos los siguientes:
|
|
|
A medida que sigas trabajando en tu BCP y tu comprensión de la cadena de herramientas de integración y compilación continuas (CI/CD) crezca, puedes actualizar el diagrama y la tabla de asignación.
Identifica los datos y las dependencias
Después de completar el inventario base y el mapa de tu cadena de herramientas de CI/CD, el siguiente paso es capturar cualquier dependencia en metadatos o configuraciones. Cuando implementes tu BCP, es fundamental que tengas una comprensión clara de las dependencias dentro de tu cadena de herramientas de CI/CD. Por lo general, las dependencias se dividen en una de 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. Estos sistemas incluyen tu herramienta de CI, el almacén de administración de claves y el sistema de control de código fuente. Puedes considerar que estos sistemas se encuentran en la siguiente capa debajo de la cadena de herramientas.
Por ejemplo, en el siguiente diagrama, se muestra un ejemplo de cómo las dependencias internas se ajustan a una cadena de herramientas. El diagrama expande el diagrama de cadena de herramientas de primera capa anterior para la aplicación de Java de ejemplo y también incluye las dependencias internas de la cadena de herramientas: credenciales de la aplicación, el archivo deploy.yaml y el archivo cloudbuild.yaml.
El diagrama muestra que, para funcionar correctamente en la aplicación de Java de ejemplo, herramientas como Cloud Build, Cloud Deploy y GKE necesitan acceso a dependencias que no son 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.
Considera las dependencias internas documentadas para la aplicación de ejemplo de Java.
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 una dependencia de GKE. También es importante incluir los archivos deploy.yaml y cloudbuild.yaml como dependencias, aunque se almacenen en el control de código fuente con el código de la aplicación, ya que definen la canalización de CI/CD para esa aplicación.
El BCP de la aplicación de Java de ejemplo debe tener en cuenta estas dependencias en los archivos deploy.yaml y cloudbuild.yaml, ya que vuelven a crear la canalización de CI/CD después de que se implementan las herramientas durante el proceso de recuperación.
Además, si se vulneran estas dependencias, la función general de la canalización se vería afectada, incluso si las herramientas aún están en funcionamiento.
Dependencias externas
Las dependencias externas son sistemas externos en los que se basa tu cadena de herramientas para operar y no están bajo tu control directo. Las dependencias externas provienen de las herramientas y los frameworks de programación que seleccionaste. Puedes pensar en las dependencias externas como una capa debajo de las dependencias internas. Algunos ejemplos de dependencias externas incluyen los repositorios de npm o Maven, y los servicios de supervisión.
Aunque las dependencias externas están fuera de tu control, puedes incorporarlas a tu BCP. En el siguiente diagrama, se actualiza la aplicación de Java de ejemplo, ya que se incluyen dependencias externas además de las internas: bibliotecas de 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.
El diagrama muestra que las dependencias externas pueden ser importantes para tu proceso de CI/CD: Cloud Build y GKE dependen de dos servicios externos (Maven y Docker) para funcionar correctamente. Cuando evalúes tu propia cadena de herramientas, documenta las dependencias externas a las que deben acceder tus herramientas y los procedimientos para controlar las interrupciones de las dependencias.
En la aplicación de Java de ejemplo, las bibliotecas de Java y las imágenes de Docker no se pueden controlar directamente, pero puedes incluirlas y sus procedimientos de recuperación en el BCP. Por ejemplo, considera 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 Artifact Registry. De esta manera, tu proceso de recuperación no necesita depender de la disponibilidad de la fuente externa.
Además, es importante comprender que las dependencias externas pueden tener más de una capa. Por ejemplo, puedes considerar los sistemas que usan tus dependencias internas como dependencias de segundo orden. Estas dependencias de segundo orden pueden tener sus propias dependencias, que puedes considerar como dependencias de tercer orden. Ten en cuenta que es posible que debas documentar y tener en cuenta las dependencias externas de segundo y tercer orden en tu BCP para recuperar las operaciones durante una interrupción.
Determina los objetivos de RTO y RPO
Después de comprender tu cadena de herramientas y las dependencias, debes definir los objetivos de RTO y RPO para tus herramientas. Cada una de las herramientas del proceso de CI/CD realiza una acción diferente que puede tener un impacto diferente en la empresa. Por lo tanto, es importante que la prioridad de los objetivos de RTO y RPO de la función comercial coincida con su impacto en la empresa. Por ejemplo, compilar versiones nuevas de aplicaciones a través de la etapa de CI podría tener menos impacto que implementar aplicaciones a través de la etapa de CD. 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 podrías determinar tus objetivos de RTO y RPO para cada componente de la cadena de herramientas de CI/CD. La cadena de herramientas que se asigna en este gráfico incluye herramientas como un canalizado de IaC y fuentes de datos de prueba. Las herramientas no se mencionaron en los diagramas anteriores de la aplicación de Java, pero se incluyen aquí para proporcionar un ejemplo más completo.
En el gráfico, se muestran cuadrantes que se basan en el nivel de impacto en los desarrolladores y las operaciones. En el gráfico, los componentes se ubican de la siguiente manera:
- Impacto moderado para los desarrolladores y bajo para las operaciones: prueba las fuentes de datos
- Impacto moderado para los desarrolladores y las operaciones: Cloud Key Management Service, Cloud KMS
- Impacto moderado en los desarrolladores, alto impacto en las operaciones: canalización de implementación
- Alto impacto para los desarrolladores, bajo impacto para las operaciones: bucle interno de desarrollo
- Alto impacto para los desarrolladores, impacto moderado para las operaciones: canalización de CI, canalización de infraestructura como código (IaC)
- Alto impacto en los desarrolladores y en las operaciones: administración de control de código fuente (SCM) y Artifact Registry
Los componentes como la administración de control de código fuente y Artifact Registry, que tienen un alto impacto en los desarrolladores y las operaciones, tienen el mayor impacto 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 para los componentes de tu cadena de herramientas deben establecerse según la cantidad de datos o pérdida de configuración que se pueda tolerar en comparación con la cantidad de tiempo que debería tardar en restablecerse el servicio para ese componente.
Por ejemplo, considera las diferentes ubicaciones de Artifact Registry y la canalización de IaC en el grafo. Una comparación de estas dos herramientas muestra que una interrupción de Artifact Registry tiene un mayor impacto en las operaciones comerciales que una interrupción en la canalización de IaC. Debido a que una interrupción de Artifact Registry afecta de manera significativa tu capacidad para implementar o escalar automáticamente tu aplicación, tendría objetivos de RTO y RPO más bajos en comparación con otras herramientas. En cambio, el gráfico muestra que una interrupción de la canalización de IaC tiene un impacto menor en las operaciones comerciales que otras herramientas. En ese caso, 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.
Elige una estrategia de alto nivel para la continuidad del negocio
Los procesos de continuidad empresarial para las aplicaciones de producción suelen depender de una de las tres estrategias de DR comunes. Sin embargo, para la CI/CD, puedes elegir entre dos estrategias de alto nivel para la continuidad del negocio: activa/pasiva o copia de seguridad/restauración. La estrategia que elijas dependerá de tus requisitos y tu presupuesto. Cada estrategia tiene compensaciones con la complejidad y el costo, y tienes diferentes consideraciones para tu proceso de CI/CD. En las siguientes secciones, se proporcionan más detalles sobre cada estrategia y sus compensaciones.
Además, cuando ocurren eventos que interrumpen el servicio, es posible que afecten más que tu implementación de CI/CD. También debes considerar toda la infraestructura que necesitas, incluida la red, el procesamiento y el almacenamiento. Debes tener un plan de DR para esos componentes fundamentales y probarlo periódicamente para asegurarte de que sea eficaz.
Activa/pasiva
Con la estrategia activa/pasiva (o de modo de espera activo), tus aplicaciones y la canalización de CI/CD pasiva son espejos. Sin embargo, la canalización pasiva no controla 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 más adecuada para las aplicaciones fundamentales para la empresa en las que se puede tolerar una pequeña cantidad de tiempo de inactividad.
En el siguiente diagrama, se muestra una configuración activa/pasiva para la aplicación de ejemplo de Java que se usa en este documento. La canalización pasiva duplica por completo la cadena de herramientas de la aplicación en una región diferente.
En este ejemplo, region1 aloja la canalización de CI/CD activa y region2 tiene la contraparte pasiva. El código se aloja en un proveedor de servicios de Git externo, como GitHub o GitLab. Un evento de repositorio (como una combinación de una solicitud de extracción) puede activar la canalización de CI/CD en la región 1 para compilar, probar e implementar en el entorno de producción multirregional.
Si se produce un problema crítico para la canalización de region1, como una interrupción regional de un producto, el resultado podría ser que las implementaciones o compilaciones no se realicen correctamente. Para recuperarte rápidamente del problema, puedes actualizar el activador del repositorio de Git y cambiar a la canalización de region2, que se convierte en la activa. Una vez que se resuelva el problema en la región1, puedes mantener la canalización en la región1 como pasiva.
Entre las ventajas de la estrategia activa/pasiva, se incluyen las siguientes:
- Tiempo de inactividad bajo: Como se implementó la canalización pasiva, pero se reduce su escala, la cantidad de tiempo de inactividad se limita al tiempo necesario para escalar la canalización.
- Tolerancia configurable para la pérdida de datos: Con esta estrategia, la configuración y el artefacto deben sincronizarse periódicamente. Sin embargo, el importe se puede configurar según tus requisitos, lo que puede reducir la complejidad.
Entre las desventajas de esta estrategia, se incluyen las siguientes:
- Costo: Con la infraestructura duplicada, esta estrategia aumenta el costo general de tu infraestructura de CI/CD.
Copia de seguridad/restablecimiento
Con la estrategia de copia de seguridad y restablecimiento, creas tu canalización de conmutación por error solo cuando es necesario durante la recuperación de incidentes. Esta estrategia es más adecuada para los casos de uso de menor prioridad. En el siguiente diagrama, se muestra una configuración de copia de seguridad y restablecimiento para la aplicación de Java de ejemplo. La configuración de la copia de seguridad duplica solo parte de la canalización de CI/CD de la aplicación en una región diferente.
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 region2, esta solo tiene copias de seguridad de los datos regionales necesarios, como los paquetes de Maven y las imágenes de contenedores. Si alojas tus repositorios de origen en la región 1, también debes sincronizar los datos con tus ubicaciones de DR.
Del mismo modo, si se produce un problema grave en la canalización de region1, como una interrupción del producto regional, puedes restablecer tu implementación de CI/CD en region2. Si el código de infraestructura se almacena en el repositorio de código de infraestructura, puedes ejecutar la secuencia de comandos de automatización desde el repositorio y volver a compilar la canalización de CI/CD en la región2.
Si la interrupción es un evento a gran escala, es posible que debas competir con otros clientes por los recursos de la nube. Una forma de mitigar esta situación es tener varias opciones para la ubicación de DR. Por ejemplo, si tu canalización de region1 está en us-east1,
tu región de conmutación por error puede ser us-east4, us-central1 o us-west1.
Entre las ventajas de la estrategia de copia de seguridad y restablecimiento, se incluyen las siguientes:
- Costo: Esta estrategia tiene el costo más bajo porque implementas la canalización de copia de seguridad solo durante situaciones de DR.
Entre las desventajas de esta estrategia, se incluyen las siguientes:
- Tiempo de inactividad: Esta estrategia lleva más tiempo de implementar porque 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 artefactos y el tiempo para recuperar dependencias externas también podrían ser significativamente más largos.
Documenta tu BCP y, luego, implementa las prácticas recomendadas
Después de asignar tu cadena de herramientas de CI/CD, identificar sus dependencias y determinar los objetivos de RTO y RPO para las funciones críticas, el siguiente paso es documentar toda la información relevante en un BCP escrito. Cuando crees tu BCP, documenta las estrategias, los procesos y los procedimientos para restablecer cada función crítica. Este proceso de documentación incluye la redacción de procedimientos paso a paso para que los empleados con roles específicos los sigan durante una interrupción.
Después de definir tu BCP, implementa o actualiza tu cadena de herramientas de CI/CD con las prácticas recomendadas para alcanzar tus objetivos de RTO y RPO. Si bien las cadenas de herramientas de CI/CD pueden ser muy diferentes, dos patrones clave para las prácticas recomendadas son comunes independientemente de la cadena de herramientas: una comprensión integral de las dependencias y la implementación de la automatización.
En lo que respecta a las dependencias, la mayoría de los BCP se dirigen a los sistemas directamente dentro de tu control. Sin embargo, recuerda que las dependencias externas de segundo o tercer orden pueden ser igual de impactantes, por lo que es importante implementar prácticas recomendadas y medidas de redundancia para esas dependencias críticas. Las bibliotecas externas de Java en la aplicación de ejemplo son un ejemplo de dependencias de tercer orden. Si no tienes un repositorio local o una copia de seguridad para esas bibliotecas, es posible que no puedas compilar tu aplicación si la fuente externa desde la que extraes las bibliotecas está desconectada.
En términos de automatización, la implementación de las prácticas recomendadas debe incorporarse a tu estrategia general 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 altamente eficaces porque se incorporan al funcionamiento diario de tus canalizaciones de CI/CD. Además, la IaC promueve el almacenamiento de tus 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 según tu BCP y las prácticas recomendadas para dependencias y 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 resulte de la revisión del BCP y la implementación de las prácticas recomendadas.
Prueba situaciones de fallas y mantén el plan
Es fundamental revisar, probar y actualizar el BCP de forma periódica. Las pruebas del BCP y los procedimientos de recuperación verifican que el plan siga siendo válido y que los objetivos de RPO y RTO documentados sean aceptables. Sin embargo, lo más importante es que las pruebas, las actualizaciones y el mantenimiento regulares hacen que la ejecución del BCP sea parte de las operaciones normales. Con Google Cloud, puedes probar situaciones de recuperación a un costo mínimo. Te recomendamos que hagas lo siguiente para ayudarte con las pruebas:
- Automatiza el aprovisionamiento de infraestructura con una herramienta de IaC: Puedes usar herramientas como Terraform para automatizar el aprovisionamiento de la infraestructura de CI/CD.
- Supervisa y depura tus pruebas con Cloud Logging y Cloud Monitoring: La Observabilidad de Google Cloud proporciona herramientas de registro y supervisión a las que puedes acceder a través de llamadas a la API, lo que significa que puedes automatizar la implementación de situaciones de recuperación reaccionando a las métricas. Cuando diseñes pruebas, asegúrate de que la supervisión y las alertas estén en funcionamiento y puedan activar las acciones de recuperación adecuadas.
- Realiza las pruebas en tu BCP: por ejemplo, puedes probar si los permisos y el acceso del usuario funcionan en el entorno de DR como lo hacen en el entorno de producción. Puedes realizar pruebas de integración y funcionales en tu entorno de DR. También puedes realizar una prueba en la que tu ruta de acceso habitual a Google Cloud no funcione.
En Google, probamos nuestro BCP con regularidad a través de un proceso llamado DiRT (pruebas de recuperación ante desastres). Estas pruebas ayudan a Google a verificar los impactos, la automatización y exponer los riesgos no contabilizados. Los cambios en la automatización y el BCP que se deben implementar son un resultado importante de DiRT.
Prácticas recomendadas
En esta sección, aprenderás sobre algunas prácticas recomendadas que puedes implementar para lograr tus objetivos de RTO y RPO. Estas prácticas recomendadas se aplican de forma general a la DR para CI/CD, y no a herramientas específicas. Independientemente de tu implementación, debes probar el BCP con regularidad para asegurarte de que la alta disponibilidad, el RTO y el RPO cumplan con tus requisitos. Si ocurre un incidente o desastre, también debes hacer una retrospectiva y analizar tu proceso para poder mejorarlo.
Alta disponibilidad
Para cada herramienta, debes trabajar para implementar las prácticas recomendadas de alta disponibilidad. Si sigues las prácticas recomendadas para la alta disponibilidad, tu proceso de CI/CD estará en una posición más proactiva, ya que estas prácticas hacen que el proceso de CI/CD sea más resistente a las fallas. Estas estrategias proactivas deben usarse con controles y procedimientos más reactivos para la recuperación y la copia de seguridad.
A continuación, se incluyen algunas prácticas recomendadas para lograr la alta disponibilidad. Sin embargo, consulta la documentación detallada de cada herramienta de tu CI/CD para obtener prácticas recomendadas más detalladas:
- Servicios administrados: El uso de servicios administrados transfiere la responsabilidad operativa a Google Cloud.
- Ajuste de escala automático: Cuando sea posible, usa el ajuste de escala automático. Un aspecto clave del ajuste de escala automático es que las instancias de trabajador se crean de forma dinámica, por lo que la recuperación de los nodos con errores es automática.
- Implementaciones globales y multirregionales: Siempre que sea posible, usa implementaciones globales y multirregionales en lugar de implementaciones regionales. Por ejemplo, puedes configurar Artifact Registry para el almacenamiento multirregional.
- Dependencias: Comprende todas las dependencias de tus herramientas y asegúrate de que tengan alta disponibilidad. Por ejemplo, puedes almacenar en caché todas las bibliotecas de terceros en tu registro de artefactos.
Procedimientos de copia de seguridad
Cuando implementas la DR para CI/CD, algunas herramientas y procesos son más adecuados para las estrategias de copia de seguridad y restablecimiento. Una estrategia de copia de seguridad integral es el primer paso para tener controles reactivos eficaces. Las copias de seguridad te permiten recuperar tu canalización de CI/CD con una interrupción mínima en el caso de actores malintencionados o situaciones de desastre.
Como punto de partida, debes implementar las siguientes tres prácticas recomendadas. Sin embargo, para obtener prácticas recomendadas más detalladas sobre las copias de seguridad, consulta la documentación de cada herramienta en tu proceso de CI/CD.
- Control de código fuente: Almacena los archivos de configuración y todo lo que codifiques, como las secuencias de comandos y las políticas de automatización, en el control de código fuente. Algunos ejemplos son los archivos YAML de
cloudbuild.yamly Kubernetes. - Redundancia: Asegúrate de que no haya un solo punto de fallo en el acceso a secretos, como contraseñas, certificados y claves de API. Algunos ejemplos de prácticas que se deben evitar son que una sola persona conozca la contraseña o que se almacene la clave de API en un solo servidor en una región en particular.
- Copias de seguridad: Verifica con frecuencia la integridad y la precisión de tus copias de seguridad. Los servicios administrados, como Copia de seguridad para GKE, te ayudarán a simplificar el proceso de verificación.
Procedimientos de recuperación
La DR también requiere procedimientos de recuperación para complementar los procesos de copia de seguridad. Tus procedimientos de recuperación, combinados con copias de seguridad completas, determinarán cuán rápido puedes responder ante situaciones de desastre.
Administración de dependencias
Tu canalización de CI/CD puede tener muchas dependencias, que también pueden ser fuentes de fallas. Se debe identificar una lista completa de las dependencias, como se describe antes en este documento en Cómo identificar datos y dependencias. Sin embargo, las dos fuentes de dependencias más comunes son las siguientes:
- Artefactos de la aplicación: por ejemplo, paquetes, bibliotecas e imágenes
- Sistemas externos: por ejemplo, sistemas de tickets y notificaciones
Una forma de mitigar los riesgos de las dependencias es adoptar la práctica de proveedores. La venta de paquetes o imágenes de aplicaciones es el proceso de crear y almacenar copias de ellos en un repositorio privado. La venta de proveedores quita la dependencia de fuentes externas para estos paquetes o imágenes y también puede ayudar a evitar que se inserte software malicioso en la cadena de suministro de software.
Estos son algunos de los beneficios de vender paquetes o imágenes de aplicaciones:
- Seguridad: La vinculación con proveedores quita la dependencia de fuentes externas para los paquetes o las imágenes de la aplicación, lo que puede ayudar a evitar ataques de inserción de software malicioso.
- Control: Cuando las organizaciones venden sus propios paquetes o imágenes, pueden tener más control sobre la fuente de estos paquetes o imágenes.
- Cumplimiento: La adquisición de proveedores puede ayudar a las organizaciones a cumplir con las reglamentaciones de la industria, como la certificación del Modelo de madurez de la seguridad cibernética.
Si tu equipo decide comprar paquetes o imágenes de aplicaciones, sigue estos pasos principales:
- Identifica los paquetes o las imágenes de la aplicación que se deben proporcionar a los proveedores.
- Crea un repositorio privado para almacenar los paquetes o las imágenes del proveedor.
- 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 del proveedor según sea necesario.
Las canalizaciones de CI/CD suelen llamar a sistemas de terceros para realizar acciones como ejecutar análisis, registrar tickets o enviar notificaciones. En la mayoría de los casos, estos sistemas de terceros tienen sus propias estrategias de DR que se deben implementar. Sin embargo, en algunos casos, es posible que no tengan un plan de DR adecuado, y esas instancias deben documentarse claramente en el BCP. Luego, debes decidir si se pueden omitir esas etapas de la canalización por motivos de disponibilidad o si es aceptable generar un tiempo de inactividad para la canalización de CI/CD.
Supervisión y notificaciones
Tu CI/CD es igual que los sistemas de producción de tu aplicación, por lo que también debes implementar técnicas de supervisión y notificación para tus herramientas de CI/CD. Como práctica recomendada, te sugerimos que implementes paneles y notificaciones de alertas. El repositorio de muestras de GitHub para Cloud Monitoring tiene muchos ejemplos de paneles y políticas de alertas.
También puedes implementar niveles adicionales de supervisión, como los indicadores de nivel de servicio (SLI) y los objetivos de nivel de servicio (SLO). Estos niveles de supervisión ayudan a hacer un seguimiento del estado y el rendimiento general de tus canalizaciones de CI/CD. Por ejemplo, se pueden implementar los SLO para hacer un seguimiento de la latencia de las etapas de compilación y implementación. Estos SLO ayudan a los equipos a compilar y lanzar aplicaciones a la velocidad y frecuencia que desees.
Procedimientos de acceso de emergencia
Durante un desastre, es posible que los equipos de operaciones deban tomar medidas fuera de los procedimientos estándar y obtener acceso de emergencia a los sistemas y las herramientas. Estas acciones de emergencia a veces se denominan procedimientos para romper el vidrio. Como punto de partida, debes implementar 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 fundamental, como la configuración y los secretos.
- Desarrolla métodos de auditoría automatizados para que puedas hacer un seguimiento de cuándo se usaron los procedimientos de acceso de emergencia y quién los usó.
¿Qué sigue?
- Obtén más información sobre los productos de Google Cloud que se usan en este documento:
- Consulta la Guía de planificación para la recuperación ante desastres.
- Completa nuestros instructivos para probar otras funciones de Google Cloud .
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.
Colaboradores
Autores:
- Ben Good | Arquitecto de soluciones
- Xiang Shen | Arquitecto de soluciones
Otros colaboradores:
- Marco Ferrari | Arquitecto de soluciones de nube
- Anuradha Bajpai | Arquitecto de soluciones
- Rodd Zurcher | Arquitecto de soluciones