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 este 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 tu infraestructura de aplicaciones, 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 CI/CD, es importante comprender cada fase del ciclo de entrega y operaciones de software, y cómo funcionan en conjunto como un proceso integral.
El siguiente diagrama es una vista simplificada del ciclo de desarrollo y operaciones de software, que incluye las siguientes tres fases:
- Bucle interno de desarrollo: Codifica, prueba y confirma
- Integración continua: Compilación, pruebas y seguridad
- Entrega continua: Promoción, lanzamiento, reversión 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 implementación 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 las aplicaciones críticas 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 distintas aplicaciones y conjuntos de infraestructura, y cada canalización tiene requisitos únicos para la planificación de la 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 críticas 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 deberían recibir más atención cuando implementes las prácticas recomendadas para probar y ejecutar los procedimientos de recuperación.
Dado que 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 falla en tu proceso de CI/CD y desarrollar un BCP integral. En las siguientes secciones, se te ayudará a hacer lo siguiente:
- Comprende qué se necesita para recuperarse de un evento de DR que afecte tu proceso de CI/CD.
- Determina el RTO y el RPO para 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 empresarial
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 generales que incluyen los pasos necesarios para crear un BCP eficaz. Si bien muchos de estos pasos se aplican de forma general a la administración de programas y 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 de la orientación en el resto de este documento.
Iniciación y planificación
En esta etapa inicial, los equipos técnicos y comerciales trabajan juntos para establecer la base del proceso de planificación de la continuidad empresarial y su mantenimiento continuo. Estos son los pasos clave de esta etapa:
- Aprobación de la dirección: Asegúrate de que la administración superior respalde y promueva el desarrollo del PCO. Asigna un equipo dedicado o una persona responsable de supervisar el plan.
- Asignación de recursos: Asigna el presupuesto, el personal y los recursos necesarios para desarrollar e implementar el PCO.
- Alcance y objetivos: Define el alcance de tu PCO y sus objetivos. Determina qué procesos comerciales son fundamentales y deben abordarse en el plan.
- Evaluación de riesgos: Identifica posibles riesgos y amenazas que podrían interrumpir tu negocio, como desastres naturales, incumplimientos de ciberseguridad o interrupciones en la cadena de suministro.
- Análisis de impacto: Evalúa las posibles consecuencias de los resultados de esta evaluación de riesgos en las operaciones, las finanzas, la reputación y la satisfacción del cliente de tu empresa.
Análisis del impacto comercial
En esta etapa, los equipos técnicos y de negocios analizan el impacto de las interrupciones en los clientes y la organización, y priorizan la recuperación de las funciones comerciales críticas. Estas funciones comerciales se realizan con diferentes herramientas durante las distintas 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 empresarial para CI/CD, en especial los pasos para identificar las funciones comerciales críticas y las dependencias de herramientas. Además, comprender tu cadena de herramientas de CI/CD, incluidas sus dependencias y cómo funciona dentro de tu ciclo de vida de DevOps, es un componente básico fundamental para desarrollar un BCP para tu proceso de CI/CD.
Los pasos clave en la etapa de análisis del impacto comercial incluyen lo siguiente:
- Funciones críticas: Determina las funciones y los procesos comerciales clave que deben priorizarse 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 de 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: Define límites aceptables para el tiempo de inactividad y la pérdida de datos en cada función crítica. Estos objetivos de RTO y RPO están vinculados a la importancia de una función empresarial para la continuidad de las operaciones, y requieren herramientas específicas para que la función empresarial opere sin problemas.
Desarrollo de estrategias
En esta etapa, el equipo técnico desarrolla estrategias de recuperación para las funciones comerciales críticas, como la restauración de operaciones y datos, y la comunicación con proveedores y partes interesadas. El desarrollo de la estrategia 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 las funciones críticas.
Los pasos clave en la etapa de desarrollo de la estrategia incluyen lo siguiente:
- Estrategias de recuperación: Desarrolla estrategias para restablecer 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 los 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 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 etapa, el paso principal es documentar el BCP. El equipo técnico documenta las herramientas, los procesos, las estrategias de recuperación, la justificación y los procedimientos para cada función crítica. El desarrollo del plan también incluye la redacción de 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 deban introducirse cambios en el plan, y este debe considerarse un documento dinámico.
Implementación
En esta etapa, implementarás el plan para 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. Los pasos clave de la implementación incluyen lo siguiente:
- Pruebas y capacitación iniciales: Después de documentar la BPC, pruébala a través de simulaciones y ejercicios para identificar 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, se inicia el BCP según los activadores y procedimientos predefinidos.
- Comunicación: Mantén informados a los interesados sobre la situación y los esfuerzos 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 constante que debería convertirse en una parte normal de tus operaciones de CI/CD. Es importante revisar, probar y actualizar periódicamente el BCP dentro de tu organización para que siga siendo pertinente y práctico si se produce una interrupción. Estos son los pasos clave del mantenimiento y la revisión:
- Actualizaciones periódicas: Revisa y actualiza el BCP periódicamente para que siga siendo actual y eficaz. Actualízala cada vez que haya cambios en el personal, la tecnología o los procesos comerciales.
- Lecciones aprendidas: Después de cada interrupción o prueba, realiza una sesión informativa para identificar las lecciones aprendidas y las áreas de mejora.
- Cumplimiento de las reglamentaciones: Alinea tu PCO con las reglamentaciones y los estándares de la industria.
- Concientización de los empleados: Educar continuamente a los empleados 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 centre 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 exhaustiva de tu cadena de herramientas de CI/CD y cómo se relaciona 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 empresarial para tu proceso de CI/CD, debes seguir estos 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 de la empresa
- Documenta tu BCP y aplica 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 combinaciones posibles 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 utilizan 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 que participan en tu proceso de CI/CD.
Para ayudarte a comprender cómo evaluar tu propia cadena de herramientas y desarrollar tu BCP, este documento 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 comprendería lo siguiente:
- La fuente de tus aplicaciones
- Herramientas en 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 de desarrollo 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 se realiza correctamente, 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 el 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. En esta tabla, se proporciona una asignación de las herramientas de tu cadena de herramientas y se identifican las herramientas 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 mencionado anteriormente de una aplicación empresarial 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 se asigna a las 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 a pedido. |
|
| Fase: Seguridad |
|
|
Analiza el código en busca de problemas de seguridad. |
La segunda tabla se enfoca en las herramientas que se usan en la fase de EC del proceso de CI/CD:
| Implementación continua | Fuente | Herramientas utilizadas | Usuarios principales | Uso |
|---|---|---|---|---|
| Fase: Deployment | Archivos de configuración de la Deployment |
|
Automatiza las implementaciones para promover, aprobar y administrar el tráfico en una plataforma segura y coherente. |
|
| Fase: Prueba |
|
|
Desarrolladores |
Prueba la integración y el rendimiento para garantizar la calidad y la usabilidad. |
| Fase: Registro |
|
|
Mantener 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 aumente tu comprensión de la cadena de herramientas de CI/CD, podrás actualizar tu diagrama y tu 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 las dependencias de los metadatos o las configuraciones. Cuando implementes tu BCP, es fundamental que comprendas claramente las dependencias dentro de tu cadena de herramientas de CI/CD. Por lo general, las dependencias se dividen en dos categorías: internas (de primer orden) y externas (de segundo o tercer orden).
Dependencias internas
Las dependencias internas son los 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 por debajo de la cadena de herramientas.
Por ejemplo, el siguiente diagrama muestra cómo las dependencias internas se ajustan dentro de una cadena de herramientas. El diagrama amplía el diagrama anterior de la cadena de herramientas de primera capa 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.
En el diagrama, se muestra que, para que la aplicación de Java de ejemplo funcione correctamente, 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 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 en 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 para 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 recrean la canalización de CI/CD después de que las herramientas están en su lugar 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, incluso si las herramientas en sí siguen 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 seleccionaste. Puedes considerar las dependencias externas como otro nivel por debajo de las dependencias internas. Algunos ejemplos de dependencias externas incluyen los repositorios de npm o Maven, y los servicios de supervisión.
Si bien las dependencias externas están fuera de tu control, puedes incorporarlas a tu PCO. En el siguiente diagrama, se actualiza la aplicación de Java de ejemplo para incluir dependencias externas además de las internas: bibliotecas de Java en Maven Central y las 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 propia cadena de herramientas, documenta las dependencias externas a las que tus herramientas necesitan acceder 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 aún 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 tus dependencias, define los objetivos de RTO y RPO para tus herramientas. Las herramientas del proceso de CI/CD realizan diferentes acciones 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 comercial coincidan con su impacto en la empresa. Por ejemplo, compilar versiones nuevas de aplicaciones durante la etapa de CI podría tener menos impacto que implementar aplicaciones durante 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 una canalización de IaC y fuentes de datos de prueba. Las herramientas no se mencionaron en los diagramas anteriores para la aplicación de Java, pero se incluyen aquí para proporcionar 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 posicionan de la siguiente manera:
- Impacto moderado en el desarrollo y bajo en las operaciones: fuentes de datos de prueba
- Impacto moderado en los desarrolladores y las operaciones: Cloud Key Management Service, Cloud KMS
- Impacto moderado en los desarrolladores y 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 y moderado en las operaciones: canalización de CI y 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), Artifact Registry
Los componentes como la administración del control de código fuente y Artifact Registry, que tienen un gran impacto en los desarrolladores y las operaciones, 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 para los componentes de tu cadena de herramientas deben establecerse según la cantidad de pérdida de datos o configuración que se puede tolerar en comparación con el tiempo que debería tomar restablecer el servicio para 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 comerciales que una interrupción en la canalización de IaC. Dado que una interrupción de Artifact Registry afecta significativamente tu capacidad de 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. Luego, 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 comercial
Los procesos de continuidad empresarial para las aplicaciones de producción suelen basarse en 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 presupuesto. Cada estrategia tiene sus ventajas y desventajas en cuanto a complejidad y costo, y debes tener en cuenta diferentes aspectos para tu proceso de CI/CD. En las siguientes secciones, se proporcionan más detalles sobre cada estrategia y sus ventajas y desventajas.
Además, cuando ocurren eventos que interrumpen el servicio, pueden afectar más que tu implementación de CI/CD. También debes tener en cuenta toda la infraestructura que necesitas, incluidas la red, la computación y el almacenamiento. Deberías 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 espera templada), tus aplicaciones y la canalización de CI/CD pasiva son reflejos. 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 tolera 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 en Java 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, la región1 aloja la canalización de CI/CD activa y la región2 tiene la contraparte pasiva. El código se aloja en un proveedor de servicios de Git externo, como GitHub o GitLab. Un evento del repositorio (como una combinación de una solicitud de extracción) puede activar la canalización de CI/CD en la región1 para compilar, probar e implementar en el entorno de producción multirregional.
Si ocurre un problema crítico en la canalización de region1, como una interrupción regional de un producto, el resultado podría ser implementaciones fallidas o compilaciones sin éxito. Para recuperarte rápidamente del problema, puedes actualizar el activador del repositorio de Git y cambiar a la canalización de region2, que luego se convertirá en la activa. Después de que se resuelva el problema en la región 1, puedes mantener la canalización en la región 1 como pasiva.
Las ventajas de la estrategia activa/pasiva incluyen las siguientes:
- Poco tiempo de inactividad: Dado que se implementó la canalización pasiva, pero se redujo su escala, el tiempo de inactividad se limita al tiempo necesario para aumentar la escala de 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, la cantidad se puede configurar según tus requisitos, lo que puede reducir la complejidad.
Las desventajas de esta estrategia incluyen lo siguiente:
- Costo: Con la infraestructura duplicada, esta estrategia aumenta el costo general de tu infraestructura de CI/CD.
Copia de seguridad y 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 copia de seguridad duplica solo una parte de la canalización de CI/CD de la aplicación en otra región.
Al igual que en el ejemplo anterior, la región 1 aloja la canalización de CI/CD activa. En lugar de tener una canalización pasiva en la región2, 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 region1, también debes sincronizar los datos con tus ubicaciones de DR.
Del mismo modo, si se produce un problema crítico en la canalización de la región 1, como una interrupción regional del producto, puedes restablecer 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, puedes ejecutar tu secuencia de comandos de automatización desde el repositorio y volver a compilar la canalización de CI/CD en region2.
Si la interrupción es un evento a gran escala, es posible que compitas 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 región1 está en us-east1, tu región de conmutación por error puede ser us-east4, us-central1 o us-west1.
Las ventajas de la estrategia de copia de seguridad y restablecimiento incluyen lo siguiente:
- Costo: Esta estrategia genera el costo más bajo porque solo implementas la canalización de copia de seguridad durante las situaciones de DR.
Las desventajas de esta estrategia incluyen lo siguiente:
- Tiempo de inactividad: Esta estrategia lleva más tiempo implementarla porque creas la canalización de conmutación por error cuando la necesitas. En lugar de tener una canalización prediseñada, los servicios deben crearse y configurarse durante la recuperación del incidente. El tiempo de compilación del artefacto y el tiempo para recuperar dependencias externas también podrían ser mucho más largos.
Documenta tu PCO y aplica las prácticas recomendadas
Después de mapear 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 pertinente 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 en 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 cuanto a las dependencias, la mayoría de los BCP abordan los sistemas directamente dentro de tu control. Sin embargo, recuerda que las dependencias externas de segundo o tercer orden pueden ser igual de importantes, por lo que es fundamental implementar prácticas recomendadas y medidas de redundancia también 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 se desconecta la fuente externa de la que extraes las bibliotecas.
En términos de automatización, la implementación de 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 muy 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, fomenta 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 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 resulten de la revisión del PCO y la implementación de las prácticas recomendadas.
Probar situaciones de falla y mantener el plan
Es fundamental que revises, pruebes y actualices tu BCP de forma continua. Probar el BCP y los procedimientos de recuperación verifica 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 periódicos hacen que la ejecución del BCP forme 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 infraestructura de CI/CD.
- Supervisa y depura tus pruebas con Cloud Logging y Cloud Monitoring: Google Cloud Observability 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 funcionales y de integración 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 y la automatización, y a exponer los riesgos no contabilizados. Los cambios en la automatización y el BCP que deben implementarse son un resultado importante del DiRT.
Prácticas recomendadas
En esta sección, aprenderás sobre algunas prácticas recomendadas que puedes implementar para alcanzar 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 tu 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 en la implementación de las prácticas recomendadas para la alta disponibilidad. Seguir las prácticas recomendadas para la alta disponibilidad coloca tu proceso de CI/CD 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 se deben usar 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 una alta disponibilidad. Sin embargo, consulta la documentación detallada de cada herramienta en tu CI/CD para conocer las 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 trabajadores se crean de forma dinámica, por lo que la recuperación de los nodos con errores es automática.
- Implementaciones globales y multirregionales: Cuando 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 estén altamente disponibles. 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 copias de seguridad integral es el primer paso para implementar controles reactivos eficaces. Las copias de seguridad te permiten recuperar tu canalización de CI/CD con una interrupción mínima en caso de situaciones de desastre o actores maliciosos.
Como punto de partida, debes implementar las siguientes tres prácticas recomendadas. Sin embargo, para conocer las prácticas recomendadas de copias de seguridad más detalladas, consulta la documentación de cada herramienta en tu proceso de CI/CD.
- Control de fuente: Almacena los archivos de configuración y todo lo que codifiques, como las políticas y los lenguajes de secuencias de comandos de automatización, en el control de fuente. Algunos ejemplos son los archivos YAML de
cloudbuild.yamly Kubernetes. - Redundancia: Asegúrate de que no haya un solo punto de falla en relación con el acceso a Secrets, como contraseñas, certificados y claves de API. Entre los ejemplos de prácticas que se deben evitar, se incluyen que solo una persona conozca la contraseña o que la clave de API se almacene solo en un servidor de 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 qué tan rápido podrás 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 describió anteriormente en este documento en Identifica los datos y las 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 vendoring. El proceso de vender paquetes o imágenes de aplicaciones consiste en crear y almacenar copias de ellos en un repositorio privado. El vendoring 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.
Estos son algunos de los beneficios de incluir paquetes o imágenes de aplicaciones en el proveedor:
- Seguridad: El vendoring 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: Al vender sus propios paquetes o imágenes, las organizaciones pueden tener más control sobre la fuente de estos elementos.
- Cumplimiento: La contratació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 vender paquetes de aplicaciones o imágenes, sigue estos pasos principales:
- Identifica los paquetes o las imágenes de la aplicación que se deben vender.
- Crea un repositorio privado para almacenar los paquetes o las imágenes incluidos en el 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 incluidos según sea necesario.
Las canalizaciones de CI/CD suelen llamar a sistemas externos 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 estar claramente documentadas en el BCP. Luego, debes decidir si esas etapas de la canalización se pueden omitir por motivos de disponibilidad o si es aceptable causar tiempo de inactividad en la canalización de CI/CD.
Supervisión y notificaciones
Tu CI/CD es igual que tus sistemas de producción de aplicaciones, 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 alerta. El repositorio de muestras de GitHub para Cloud Monitoring contiene 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 rendimiento y el estado general de tus canalizaciones de CI/CD. Por ejemplo, se pueden implementar SLO para hacer un seguimiento de la latencia de las etapas de compilación e implementación. Estos SLO ayudan a los equipos a compilar y lanzar aplicaciones con la frecuencia y la velocidad 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. A veces, estas acciones de emergencia se denominan procedimientos de emergencia. 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 la información crítica, 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 Google Cloud funciones.
- 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 | Arquitecta de soluciones
- Rodd Zurcher | Arquitecto de soluciones