Este documento descreve a recuperação de desastres (DR) e o planejamento de continuidade de negócios no contexto da integração e entrega contínuas (CI/CD). Ele também fornece orientações sobre como identificar e mitigar dependências ao desenvolver um plano abrangente de continuidade de negócios (BCP). O documento inclui práticas recomendadas que podem ser aplicadas ao seu BCP, independentemente das ferramentas e dos processos que você usa. O documento pressupõe que você conheça os conceitos básicos do ciclo de entrega e operações de software, CI/CD e DR.
Os pipelines de CI/CD são responsáveis por criar e implantar seus aplicativos essenciais para os negócios. Assim, assim como a infraestrutura do aplicativo, o processo de CI/CD exige planejamento para DR e continuidade de negócios. Ao pensar em DR e continuidade dos negócios para CI/CD, é importante entender cada fase do ciclo de entrega e operações de software e como elas funcionam juntas como um processo holístico.
O diagrama a seguir é uma visualização simplificada do ciclo de desenvolvimento e operações de software, que inclui as três fases a seguir:
- Loop interno de desenvolvimento: codificar, tentar e confirmar
- Integração contínua: criação, teste e segurança
- Entrega contínua: promoção, lançamento, reversão e métricas
O diagrama também mostra que o Google Kubernetes Engine (GKE), o Cloud Run e o Google Distributed Cloud são possíveis destinos de implantação do ciclo de desenvolvimento e operações de software.
Durante o ciclo de desenvolvimento e operações de software, é necessário considerar o impacto de um desastre na capacidade das equipes de operar e manter aplicativos essenciais para os negócios. Isso vai ajudar a determinar o objetivo do tempo de recuperação (RTO) e o objetivo do ponto de recuperação (RPO) para as ferramentas na cadeia de ferramentas de CI/CD.
Além disso, a maioria das organizações tem muitos pipelines de CI/CD diferentes para aplicativos e conjuntos de infraestrutura diferentes, e cada pipeline tem requisitos exclusivos para DR e planejamento de continuidade de negócios. A estratégia de recuperação escolhida para um pipeline varia de acordo com o RTO e o RPO das ferramentas. Por exemplo, alguns pipelines são mais críticos do que outros e têm requisitos de RTO e RPO menores. É importante identificar os pipelines críticos para o negócio no seu BCP, e eles também precisam receber mais atenção ao implementar as práticas recomendadas para testar e executar procedimentos de recuperação.
Como cada processo de CI/CD e a cadeia de ferramentas são diferentes, os objetivos deste guia são ajudar você a identificar pontos únicos de falha no processo de CI/CD e desenvolver um BCP abrangente. As seções a seguir ajudam você a fazer o seguinte:
- Entenda o que é necessário para se recuperar de um evento de DR que afeta seu processo de CI/CD.
- Determine o RTO e o RPO das ferramentas no seu processo de CI/CD.
- Entenda os modos de falha e as dependências do seu processo de CI/CD.
- Escolha uma estratégia de recuperação adequada para as ferramentas da sua cadeia de ferramentas.
- Entenda as práticas recomendadas gerais para implementar um plano de recuperação de DR para seu processo de CI/CD.
Entender o processo de continuidade de negócios
Criar um BCP é crucial para garantir que sua organização possa continuar as operações em caso de interrupções e emergências. Ele ajuda a organização a retornar rapidamente a um estado de operações normais para o processo de CI/CD.
As seções a seguir descrevem as etapas gerais que incluem as etapas envolvidas na criação de um BCP eficaz. Embora muitas dessas etapas se apliquem amplamente ao gerenciamento de programas e à DR, algumas etapas são mais relevantes para planejar a continuidade de negócios para seu processo de CI/CD. As etapas que são especificamente relevantes para o planejamento da continuidade de negócios para CI/CD são destacadas nas seções a seguir e também servem de base para a orientação no resto deste documento.
Iniciação e planejamento
Nessa fase inicial, as equipes técnicas e de negócios trabalham juntas para estabelecer a base do processo de planejamento de continuidade de negócios e a manutenção contínua dele. As principais etapas desta fase incluem:
- Comprometimento da liderança: garanta que a alta administração apoie e defenda o desenvolvimento do BCP. Atribua uma equipe dedicada ou um indivíduo responsável por supervisionar o plano.
- Alocação de recursos: aloque o orçamento, o pessoal e os recursos necessários para desenvolver e implementar o BCP.
- Escopo e objetivos: defina o escopo do seu BCP e os objetivos dele. Determine quais processos de negócios são críticos e precisam ser abordados no plano.
- Avaliação de risco: identifique possíveis riscos e ameaças que possam interromper sua empresa, como desastres naturais, violações de segurança cibernética ou interrupções da cadeia de suprimentos.
- Análise de impacto: avalie as possíveis consequências dessas descobertas da avaliação de risco nas operações, finanças, reputação e satisfação do cliente.
Análise de impacto nos negócios
Nessa fase, as equipes de negócios e técnicas analisam o impacto comercial das interrupções para seus clientes e organização e priorizam a recuperação de funções de negócios essenciais. Essas funções de negócios são realizadas por diferentes ferramentas durante as diferentes fases de um processo de build e implantação.
A análise de impacto nos negócios é uma etapa importante no processo de planejamento de continuidade de negócios para CI/CD, especialmente as etapas para identificar funções de negócios críticas e dependências de ferramentas. Além disso, entender a cadeia de ferramentas de CI/CD, incluindo as dependências e como ela funciona no ciclo de vida do DevOps, é um elemento básico para desenvolver um BCP para o processo de CI/CD.
As principais etapas da análise de impacto nos negócios incluem:
- Funções críticas: determine as principais funções e processos de negócios que precisam ser priorizados para recuperação. Por exemplo, se você determinar que a implantação de aplicativos é mais importante do que a execução de testes de unidade, priorize a recuperação para processos e ferramentas de implantação de aplicativos.
- Dependências: identifique dependências internas e externas que podem afetar a recuperação das funções críticas. As dependências são especialmente relevantes para garantir a operação contínua do processo de CI/CD pela cadeia de ferramentas.
- RTO e RPO: defina limites aceitáveis para inatividade e perda de dados para cada função crítica. Esses objetivos de RTO e RPO estão vinculados à importância de uma função de negócios para operações contínuas e envolvem ferramentas específicas necessárias para que a função de negócios funcione corretamente.
Desenvolvimento da estratégia
Nessa fase, a equipe técnica desenvolve estratégias de recuperação para funções essenciais de negócios, como restaurar operações e dados e se comunicar com fornecedores e partes interessadas. O desenvolvimento de estratégia também é uma parte importante do planejamento da continuidade de negócios para seu processo de CI/CD, especialmente a etapa de seleção de estratégias de recuperação de alto nível para funções críticas.
As principais etapas do estágio de desenvolvimento da estratégia incluem:
- Estratégias de recuperação: desenvolva estratégias para restaurar funções críticas. Essas estratégias podem envolver locais alternativos, trabalho remoto ou sistemas de backup. Essas estratégias estão vinculadas às metas de RTO e RPO de cada função crítica.
- Relacionamentos com fornecedores: estabeleça planos de comunicação e coordenação com os principais fornecedores para manter a cadeia de suprimentos em funcionamento durante as interrupções.
- Recuperação de dados e de TI: crie planos de backup de dados, recuperação de sistemas de TI e medidas de segurança cibernética.
- Plano de comunicação: desenvolva um plano de comunicação claro para partes interessadas internas e externas durante e após uma interrupção.
Planejar o desenvolvimento
Nesta fase, a principal etapa é documentar o BCP. A equipe técnica documenta as ferramentas, os processos, as estratégias de recuperação, a justificativa e os procedimentos para cada função crítica. O desenvolvimento do plano também inclui instruções detalhadas para que os funcionários sigam durante uma interrupção. Durante a implementação e a manutenção contínua, pode ser necessário introduzir mudanças no plano, e ele precisa ser tratado como um documento vivo.
Implementação
Nesta fase, você implementa o plano para sua organização usando o BCP criado pela equipe técnica. A implementação inclui treinamento de funcionários e testes iniciais do BCP. A implementação também inclui o uso do plano se uma interrupção ocorrer para recuperar as operações normais. As principais etapas de implementação incluem:
- Testes e treinamentos iniciais: depois que o BPC for documentado, teste-o por meio de simulações e exercícios para identificar lacunas e melhorar a eficácia. Treine os funcionários sobre as funções e responsabilidades deles durante uma interrupção.
- Ativação: quando ocorre uma interrupção, inicie o BCP de acordo com os gatilhos e procedimentos predefinidos.
- Comunicação: mantenha as partes interessadas informadas sobre a situação e os esforços de recuperação.
Manutenção e revisão
Essa etapa não é um processo definido que ocorre apenas uma vez. Em vez disso, ela representa um esforço contínuo e contínuo que precisa se tornar uma parte normal das operações de CI/CD. É importante revisar, testar e atualizar regularmente o BCP na sua organização para que ele continue relevante e acionável em caso de interrupção. As principais etapas de manutenção e revisão incluem:
- Atualizações regulares: revise e atualize o BCP periodicamente para que ele continue atualizado e eficaz. Atualize-o sempre que houver mudanças no pessoal, na tecnologia ou nos processos de negócios.
- Lições aprendidas: após cada interrupção ou teste, faça uma debriefing para identificar as lições aprendidas e as áreas que precisam de melhorias.
- Compliance regulatório: alinhe seu BCP com as regulamentações e padrões do setor.
- Conscientização dos funcionários: conscientize os funcionários continuamente sobre o BCP e as funções deles na execução.
Criar um processo de continuidade de negócios para CI/CD
Esta seção fornece diretrizes específicas para criar um BCP com foco específico na restauração das operações de CI/CD. O processo de planejamento da continuidade de negócios para CI/CD começa com uma compreensão completa da cadeia de ferramentas de CI/CD e como ela se conecta ao ciclo de vida de entrega e operações de software. Com esse entendimento como base, você pode planejar como sua organização vai recuperar as operações de CI/CD de uma interrupção.
Para criar um processo robusto de continuidade de negócios para seu processo de CI/CD, você precisa seguir estas etapas principais:
- Noções básicas sobre o conjunto de ferramentas
- Identificar dados e dependências
- Determinar as metas de RTO e RPO
- Escolher uma estratégia de alto nível para a continuidade dos negócios
- Documentar o BCP e implementar as práticas recomendadas
- Testar cenários de falha e manter o plano
As seções a seguir fornecem mais detalhes sobre cada uma dessas etapas.
Entender o conjunto de ferramentas
As cadeias de ferramentas de CI/CD são compostas por muitas ferramentas individuais diferentes, e as combinações possíveis de ferramentas podem parecer infinitas. No entanto, entender sua ferramenta de linha de ferramentas de CI/CD e as dependências dela é fundamental para o planejamento de continuidade de negócios para CI/CD. A missão principal do seu processo de CI/CD é entregar código para sistemas de produção para consumo do usuário final. Durante esse processo, muitos sistemas e fontes de dados diferentes são usados. Conhecer essas fontes de dados e dependências é fundamental para desenvolver um BCP. Para começar a criar sua estratégia de DR, primeiro você precisa entender as diferentes ferramentas envolvidas no processo de CI/CD.
Para ajudar você a entender como avaliar sua própria cadeia de ferramentas e desenvolver seu BCP, este documento usa o exemplo de um aplicativo Java empresarial executado no GKE. O diagrama a seguir mostra a primeira camada de dados e sistemas na cadeia de ferramentas. Essa primeira camada estaria sob seu controle direto e inclui o seguinte:
- A origem das suas inscrições
- Ferramentas na sua plataforma de CI/CD, como o Cloud Build ou o Cloud Deploy
- Interconexões básicas das diferentes ferramentas
Conforme mostrado no diagrama, o fluxo principal do exemplo de aplicativo é o seguinte:
- Eventos de desenvolvimento de código no gatilho de loop interno do desenvolvedor do Cloud Build.
- O Cloud Build extrai o código-fonte do aplicativo do repositório de controle de origem.
- O Cloud Build identifica todas as dependências necessárias especificadas em arquivos de configuração de build, como arquivos JAR de terceiros do repositório Java no Artifact Registry. O Cloud Build extrai essas dependências dos locais de origem.
- O Cloud Build executa o build e faz a validação necessária, como análise estática e testes de unidade.
- Se a build for bem-sucedida, o Cloud Build vai criar a imagem do contêiner e fazer o push dela para o repositório de contêineres no Artifact Registry.
- Um pipeline do Cloud Deploy é acionado e extrai a imagem do contêiner do repositório e a implanta em um ambiente do GKE.
Para entender as ferramentas usadas no processo de CI/CD, sugerimos criar um diagrama que mostre seu processo de CI/CD e as ferramentas usadas nele, semelhante ao exemplo neste documento. Em seguida, use o diagrama para criar uma tabela que capture informações importantes sobre o conjunto de ferramentas de CI/CD, como a fase do processo, a finalidade da ferramenta, a própria ferramenta e as equipes que são afetadas por uma falha da ferramenta. Esta tabela fornece um mapeamento das ferramentas no conjunto de ferramentas e identifica as ferramentas com fases específicas do processo de CI/CD. Assim, a tabela pode ajudar você a ter uma visão geral da toolchain e como ela funciona.
As tabelas a seguir mapeiam o exemplo mencionado anteriormente de um aplicativo empresarial para cada ferramenta no diagrama. Para fornecer um exemplo mais completo de como um mapeamento de conjunto de ferramentas pode ser, essas tabelas também incluem outras ferramentas que não são mencionadas no diagrama, como ferramentas de segurança ou de teste.
A primeira tabela mapeia as ferramentas usadas na fase de CI do processo de CI/CD:
Integração contínua | Origem | Ferramentas usadas | Usuários principais | Uso |
---|---|---|---|---|
Fase: controle de origem |
|
|
|
|
Fase: criação |
|
Desenvolvedores |
|
|
Fase: teste |
|
Desenvolvedores |
Execute testes de unidade e integração em uma plataforma consistente e sob demanda. |
|
Fase: segurança |
|
|
Verifique se há problemas de segurança no código. |
A segunda tabela se concentra nas ferramentas usadas na fase de CD do processo de CI/CD:
Implantação contínua | Origem | Ferramentas usadas | Usuários principais | Uso |
---|---|---|---|---|
Fase: implantação | Arquivos de configuração de implantação |
|
Automatize implantações para promover, aprovar e gerenciar o tráfego em uma plataforma segura e consistente. |
|
Fase: teste |
|
|
Desenvolvedores |
Teste a integração e o desempenho para qualidade e usabilidade. |
Fase: registro |
|
|
Mantenha registros para observabilidade e solução de problemas. |
|
Fase: monitoramento | Monitoramento de arquivos de configuração, incluindo:
|
|
|
À medida que você continua trabalhando no BCP e seu entendimento da ferramenta de integração contínua/desenvolvimento contínuo aumenta, é possível atualizar o diagrama e a tabela de mapeamento.
Identificar dados e dependências
Depois de concluir o inventário básico e o mapa da cadeia de ferramentas de CI/CD, a próxima etapa é capturar todas as dependências de metadados ou configurações. Ao implementar o BCP, é fundamental que você entenda claramente as dependências da cadeia de ferramentas de CI/CD. As dependências geralmente se enquadram em uma destas duas categorias: dependências internas (de primeira ordem) e externas (de segunda ou terceira ordem).
Dependências internas
Dependências internas são sistemas que o conjunto de ferramentas usa e que você controla diretamente. As dependências internas também são selecionadas pelas equipes. Esses sistemas incluem a ferramenta de CI, a loja de gerenciamento de chaves e o sistema de controle de origem. Esses sistemas estão na próxima camada abaixo da toolchain.
Por exemplo, o diagrama a seguir mostra como as dependências
internas se encaixam em uma cadeia de ferramentas. O diagrama expande o diagrama anterior
de ferramenta de camada 1 para o exemplo de aplicativo Java e também inclui as
dependências internas da ferramenta: credenciais do aplicativo, o arquivo deploy.yaml
e
o arquivo cloudbuild.yaml
.
O diagrama mostra que, para funcionar no exemplo de aplicativo Java, ferramentas como
o Cloud Build, o Cloud Deploy e o GKE precisam ter acesso a dependências que não são do toolchain,como cloudbuild.yaml
, deploy.yaml
e credenciais do aplicativo. Ao analisar sua própria cadeia de ferramentas de CI/CD, você avalia se uma ferramenta pode ser executada sozinha ou se ela precisa chamar outro recurso.
Considere as dependências internas documentadas para o exemplo de aplicativo Java.
As credenciais são armazenadas no Secret Manager, que não faz parte da
ferramenta, mas são necessárias para que o aplicativo seja iniciado na
implantação. Portanto, as credenciais do aplicativo são incluídas como uma dependência do
GKE. Também é importante incluir os arquivos deploy.yaml
e
cloudbuild.yaml
como dependências, mesmo que eles sejam armazenados no controle
de origem com o código do aplicativo, porque eles definem o pipeline de CI/CD para
esse aplicativo.
O BCP para o exemplo de aplicativo Java precisa considerar essas dependências
nos arquivos deploy.yaml
e cloudbuild.yaml
, porque eles recriam o
pipeline de CI/CD depois que as ferramentas são implementadas durante o processo de recuperação.
Além disso, se essas dependências forem comprometidas, a função geral do
pipeline será afetada, mesmo que as ferramentas ainda estejam operacionais.
Dependências externas
Dependências externas são sistemas externos em que a cadeia de ferramentas depende para operar e que não estão sob seu controle direto. As dependências externas resultam das ferramentas e frameworks de programação selecionadas. Pense nas dependências externas como uma camada abaixo das dependências internas. Exemplos de dependências externas incluem repositórios npm ou Maven e serviços de monitoramento.
Embora as dependências externas estejam fora do seu controle, é possível incorporá-las ao seu BCP. O diagrama a seguir atualiza o exemplo de aplicativo Java incluindo dependências externas além das internas: bibliotecas Java no Maven Central e imagens do Docker no Docker Hub. As bibliotecas Java são usadas pelo Artifact Registry, e as imagens do Docker são usadas pelo Cloud Build.
O diagrama mostra que as dependências externas podem ser importantes para seu processo de CI/CD: o Cloud Build e o GKE dependem de dois serviços externos (Maven e Docker) para funcionar. Ao avaliar sua própria cadeia de ferramentas, documente as dependências externas que as ferramentas precisam acessar e os procedimentos para lidar com interrupções de dependência.
No exemplo de aplicativo Java, as bibliotecas Java e as imagens do Docker não podem ser controladas diretamente, mas ainda é possível incluí-las e os procedimentos de recuperação no BCP. Por exemplo, considere as bibliotecas Java no Maven. Embora as bibliotecas sejam armazenadas em uma fonte externa, é possível estabelecer um processo para fazer o download e atualizar periodicamente as bibliotecas Java em um repositório Maven local ou no Artifact Registry. Assim, seu processo de recuperação não precisa depender da disponibilidade da fonte de terceiros.
Além disso, é importante entender que as dependências externas podem ter mais de uma camada. Por exemplo, pense nos sistemas usados pelas dependências internas como dependências de segunda ordem. Essas dependências de segundo grau podem ter dependências próprias, que podem ser consideradas dependências de terceiro grau. Talvez seja necessário documentar e considerar dependências externas de segunda e terceira ordem no seu BCP para recuperar as operações durante uma interrupção.
Determinar as metas de RTO e RPO
Depois de entender a cadeia de ferramentas e as dependências, defina as metas de RTO e RPO para as ferramentas. As ferramentas no processo de CI/CD executam ações diferentes que podem ter um impacto diferente no negócio. Portanto, é importante combinar a prioridade das metas de RTO e RPO da função com o impacto dela no negócio. Por exemplo, criar novas versões de aplicativos na fase de CI pode ter menos impacto do que implantar aplicativos na fase de CD. Portanto, as ferramentas de implantação podem ter metas de RTO e RPO mais longas do que outras funções.
O gráfico de quatro quadrantes a seguir é um exemplo geral de como determinar as metas de RTO e RPO para cada componente da cadeia de ferramentas de CI/CD. A cadeia de ferramentas mapeada neste gráfico inclui ferramentas como um pipeline de IaC e fontes de dados de teste. As ferramentas não foram mencionadas nos diagramas anteriores para o aplicativo Java, mas foram incluídas aqui para fornecer um exemplo mais completo.
O gráfico mostra quadrantes com base no nível de impacto para desenvolvedores e operações. No gráfico, os componentes são posicionados da seguinte maneira:
- Impacto moderado para desenvolvedores, baixo impacto para operações: teste de fontes de dados
- Impacto moderado para desenvolvedores, impacto moderado para operações: Cloud Key Management Service, Cloud KMS
- Impacto moderado para desenvolvedores, alto impacto para operações: pipeline de implantação
- Alto impacto para desenvolvedores, baixo impacto para operações: loop interno de desenvolvimento
- Alto impacto para desenvolvedores, impacto moderado para operações: pipeline de CI, pipeline de infraestrutura como código (IaC)
- Alto impacto para desenvolvedores e operações: gerenciamento de controle de origem (SCM, na sigla em inglês) e Artifact Registry
Componentes como o gerenciamento de controle de origem e o Artifact Registry, que têm um alto impacto sobre o desenvolvedor e as operações, têm o maior impacto sobre a empresa. Esses componentes precisam ter os objetivos de RTO e RPO mais baixos. Os componentes nos outros quadrantes têm prioridade menor, o que significa que os objetivos de RTO e RPO serão maiores. Em geral, os objetivos de RTO e RPO dos componentes da cadeia de ferramentas precisam ser definidos de acordo com a quantidade de dados ou configuração que pode ser tolerada em comparação com o tempo necessário para restaurar o serviço desse componente.
Por exemplo, considere os diferentes locais do Artifact Registry e do pipeline do IaC no gráfico. Uma comparação entre essas duas ferramentas mostra que uma interrupção do Artifact Registry tem um impacto maior nas operações comerciais do que uma interrupção no pipeline de IaC. Como uma falha do Artifact Registry afeta significativamente a capacidade de implantar ou dimensionar automaticamente o aplicativo, ele teria metas de RTO e RPO menores em comparação com outras ferramentas. Por outro lado, o gráfico mostra que uma interrupção do pipeline de IaC tem um impacto menor nas operações de negócios do que outras ferramentas. O pipeline de IaC teria objetivos de RTO e RPO mais altos, porque é possível usar outros métodos para implantar ou atualizar a infraestrutura durante uma interrupção.
Escolha uma estratégia geral para a continuidade dos negócios
Os processos de continuidade de negócios para aplicativos de produção geralmente dependem de uma das três estratégias comuns de DR. No entanto, para CI/CD, você pode escolher entre duas estratégias de alto nível para continuidade de negócios: ativa/passiva ou backup/restauração. A estratégia escolhida depende dos seus requisitos e do seu orçamento. Cada estratégia tem compensações com complexidade e custo, e você tem considerações diferentes para seu processo de CI/CD. As seções a seguir fornecem mais detalhes sobre cada estratégia e as compensações.
Além disso, quando ocorrem eventos de interrupção de serviço, eles podem afetar mais do que a implementação de CI/CD. Você também precisa considerar toda a infraestrutura necessária, incluindo rede, computação e armazenamento. Você precisa ter um plano de DR para esses elementos de criação e testá-lo regularmente para garantir que ele seja eficaz.
Ativo/passivo
Com a estratégia ativa/passiva (ou de espera morna), seus aplicativos e o pipeline passivo de CI/CD são espelhados. No entanto, o pipeline passivo não processa a carga de trabalho do cliente nem qualquer build ou implantação. Portanto, ele está em um estado reduzido. Essa estratégia é mais adequada para aplicativos essenciais para os negócios, em que um pequeno período de inatividade é tolerável.
O diagrama a seguir mostra uma configuração ativa/passiva para o exemplo de aplicativo Java usado neste documento. O pipeline passivo duplica totalmente a cadeia de ferramentas do aplicativo em uma região diferente.
Neste exemplo, a região1 hospeda o pipeline ativo de CI/CD, e a região2 tem a contraparte passiva. O código é hospedado em um provedor de serviço Git externo, como o GitHub ou o GitLab. Um evento do repositório (como uma mesclagem de uma solicitação de envio) pode acionar o pipeline de CI/CD na região1 para criar, testar e implantar no ambiente de produção multirregional.
Se um problema crítico ocorrer no pipeline da região1, como uma falha regional de um produto, o resultado poderá ser implantações ou builds com falha. Para se recuperar rapidamente do problema, atualize o gatilho do repositório do Git e mude para o pipeline region2, que se torna o ativo. Depois que o problema for resolvido na região1, você poderá manter o pipeline na região1 como passivo.
As vantagens da estratégia ativa/passiva incluem:
- Tempo de inatividade baixo: como o pipeline passivo foi implantado, mas foi reduzido, o tempo de inatividade é limitado ao tempo necessário para aumentar o pipeline.
- Tolerância configurável para perda de dados: com essa estratégia, a configuração e o artefato precisam ser sincronizados periodicamente. No entanto, o valor é configurável com base nos seus requisitos, o que pode reduzir a complexidade.
As desvantagens dessa estratégia incluem:
- Custo: com a infraestrutura duplicada, essa estratégia aumenta o custo geral da sua infraestrutura de CI/CD.
Backup/restauração
Com a estratégia de backup/restauração, você cria o pipeline de failover somente quando precisar durante a recuperação de incidentes. Essa estratégia é mais adequada para casos de uso de prioridade mais baixa. O diagrama a seguir mostra uma configuração de backup/restauração para o exemplo de aplicativo Java. A configuração de backup duplica apenas parte do pipeline de CI/CD do aplicativo em uma região diferente.
Semelhante ao exemplo anterior, a região1 hospeda o pipeline de CI/CD ativo. Em vez de ter um pipeline passivo na região2, ela só tem backups dos dados regionais necessários, como os pacotes do Maven e as imagens de contêiner. Se você hospedar seus repositórios de origem na região1, também vai precisar sincronizar os dados com os locais de DR.
Da mesma forma, se um problema crítico ocorrer no pipeline da região 1, como uma falha temporária regional do produto, é possível restaurar a implementação de CI/CD na região 2. Se o código de infraestrutura estiver armazenado no repositório de código de infraestrutura, será possível executar o script de automação no repositório e recriar o pipeline de CI/CD na região2.
Se a interrupção for um evento em grande escala, você poderá competir com outros clientes por recursos de nuvem. Uma maneira de mitigar essa situação é ter várias opções
para o local de DR. Por exemplo, se o pipeline da região 1 estiver em us-east1
,
a região de failover poderá ser us-east4
, us-central1
ou us-west1
.
As vantagens da estratégia de backup/restauração incluem:
- Custo: essa estratégia tem o menor custo, porque você está implantando o pipeline de backup somente durante cenários de DR.
As desvantagens dessa estratégia incluem:
- Tempo de inatividade: essa estratégia leva mais tempo para ser implementada porque você cria o pipeline de failover quando precisar dele. Em vez de ter um pipeline pré-criado, os serviços precisam ser criados e configurados durante a recuperação de incidentes. O tempo de build de artefatos e o tempo para recuperar dependências externas também podem ser consideravelmente maiores.
Documentar seu BCP e implementar práticas recomendadas
Depois de mapear sua ferramenta de cadeia de ferramentas de CI/CD, identificar as dependências dela e determinar as metas de RTO e RPO para funções críticas, a próxima etapa é documentar todas as informações relevantes em um BCP escrito. Ao criar seu BCP, documente as estratégias, os processos e os procedimentos para restaurar cada função crítica. Esse processo de documentação inclui a escrita de procedimentos detalhados para que funcionários em papéis específicos sigam durante uma interrupção.
Depois de definir o BCP, implante ou atualize a cadeia de ferramentas de CI/CD usando práticas recomendadas para alcançar as metas de RTO e RPO. Embora as cadeias de ferramentas de CI/CD possam ser muito diferentes, dois padrões importantes para as práticas recomendadas são comuns, independente da cadeia de ferramentas: um entendimento abrangente das dependências e da implementação da automação.
Em relação às dependências, a maioria dos BCPs aborda os sistemas diretamente no seu controle. No entanto, lembre-se de que dependências externas de segunda ou terceira ordem podem ser igualmente impactantes. Por isso, é importante implementar práticas recomendadas e medidas de redundância para essas dependências críticas. As bibliotecas Java externas no aplicativo de exemplo são um exemplo de dependências de terceira ordem. Se você não tiver um repositório local ou um backup dessas bibliotecas, talvez não seja possível criar o aplicativo se a fonte externa em que você extrai as bibliotecas estiver desconectada.
Em termos de automação, a implementação das práticas recomendadas precisa ser incorporada à sua estratégia geral de IaC na nuvem. Sua solução de IaC precisa usar ferramentas como o Terraform para provisionar automaticamente os recursos necessários da implementação de CI/CD e configurar os processos. As práticas de IaC são procedimentos de recuperação altamente eficazes porque são incorporadas ao funcionamento diário dos pipelines de CI/CD. Além disso, a IaC promove o armazenamento dos arquivos de configuração no controle de origem, o que promove a adoção das práticas recomendadas para backups.
Depois de implementar o conjunto de ferramentas de acordo com o BCP e as práticas recomendadas para dependências e automação, o processo de CI/CD e as estratégias de recuperação podem mudar. Documente todas as mudanças nas estratégias, nos processos e nos procedimentos de recuperação que resultem da análise do BCP e da implementação de práticas recomendadas.
Testar cenários de falha e manter o plano
É fundamental revisar, testar e atualizar o BCP regularmente. O teste do BCP e dos procedimentos de recuperação verifica se o plano ainda é válido e se as metas documentadas de RPO e RTO são aceitáveis. No entanto, o mais importante é que testes, atualizações e manutenção regulares tornam a execução do BCP parte das operações normais. Com o Google Cloud, é possível testar cenários de recuperação a um custo mínimo. Recomendamos que você faça o seguinte para ajudar nos testes:
- Automatizar o provisionamento de infraestrutura com uma ferramenta de IaC: é possível usar ferramentas como o Terraform para automatizar o provisionamento da infraestrutura de CI/CD.
- Monitore e depure seus testes com o Cloud Logging e o Cloud Monitoring: a Observabilidade do Google Cloud oferece ferramentas de registro e monitoramento que podem ser acessadas por chamadas de API. Isso significa que você pode automatizar a implantação de cenários de recuperação reagindo às métricas. Ao criar testes, verifique se você tem monitoramento e alertas adequados que possam acionar ações de recuperação apropriadas.
- Realizar os testes no seu BCP: por exemplo, você pode testar se as permissões e o acesso do usuário funcionam no ambiente de DR como no ambiente de produção. É possível realizar testes funcionais e de integração no ambiente de DR. Também é possível realizar um teste em que o caminho de acesso habitual ao Google Cloud não funcione.
No Google, testamos regularmente nosso BCP por meio de um processo chamado DiRT (teste de recuperação de desastres). Esse teste ajuda o Google a verificar impactos, automação e expor riscos não contabilizados. As mudanças na automação e no BCP que precisam ser implementadas são um resultado importante do DiRT.
Práticas recomendadas
Nesta seção, você vai aprender sobre algumas práticas recomendadas que podem ser implementadas para atingir seus objetivos de RTO e RPO. Essas práticas recomendadas se aplicam amplamente ao DR para CI/CD, e não a ferramentas específicas. Independentemente da implementação, teste seu BCP regularmente para garantir que a alta disponibilidade, o RTO e o RPO atendam aos seus requisitos. Se ocorrer um incidente ou desastre, faça uma retrospectiva e analise seu processo para melhorá-lo.
Alta disponibilidade
Para cada ferramenta, você precisa implementar as práticas recomendadas para alta disponibilidade. Seguir as práticas recomendadas para alta disponibilidade coloca seu processo de CI/CD em uma postura mais proativa, porque essas práticas tornam o processo de CI/CD mais resistente a falhas. Essas estratégias proativas devem ser usadas com controles e procedimentos mais reativos para recuperação e backup.
Confira a seguir algumas práticas recomendadas para alcançar alta disponibilidade. No entanto, consulte a documentação detalhada de cada ferramenta na sua CI/CD para conferir práticas recomendadas mais detalhadas:
- Serviços gerenciados: o uso de serviços gerenciados transfere a responsabilidade operacional para Google Cloud.
- Escalonamento automático: use o escalonamento automático sempre que possível. Um aspecto importante do escalonamento automático é que as instâncias de worker são criadas de forma dinâmica, para que a recuperação de nós com falhas seja automática.
- Implantações globais e multirregionais: sempre que possível, use implantações globais e multirregionais em vez de regionais. Por exemplo, é possível configurar o Artifact Registry para armazenamento multirregional.
- Dependências: entenda todas as dependências das ferramentas e garanta que elas tenham alta disponibilidade. Por exemplo, é possível armazenar em cache todas as bibliotecas de terceiros no registro de artefatos.
Procedimentos de backup
Ao implementar a DR para CI/CD, algumas ferramentas e processos são mais adequados para estratégias de backup/restauração. Uma estratégia abrangente de backup é a primeira etapa para controles reativos eficazes. Os backups permitem que você recupere seu pipeline de CI/CD com a mínima interrupção no caso de agentes mal-intencionados ou cenários de desastre.
Como ponto de partida, implemente as três práticas recomendadas a seguir. No entanto, para conferir práticas recomendadas de backup mais detalhadas, consulte a documentação de cada ferramenta no seu processo de CI/CD.
- Controle de origem: armazene arquivos de configuração e tudo o que você codificar, como
scripts e políticas de automação, no controle de origem. Exemplos incluem
cloudbuild.yaml
e arquivos YAML do Kubernetes. - Redundância: garanta que não haja um ponto único de falha em relação ao acesso a segredos, como senhas, certificados e chaves de API. Exemplos de práticas a serem evitadas incluem apenas uma pessoa que sabe a senha ou armazena a chave de API em apenas um servidor em uma região específica.
- Backups: verifique com frequência a integridade e a precisão dos seus backups. Os serviços gerenciados, como o Backup para GKE, ajudam a simplificar o processo de verificação.
Procedimentos de recuperação
A DR também exige procedimentos de recuperação para complementar os processos de backup. Seus procedimentos de recuperação, combinados com backups completos, vão determinar a rapidez com que você poderá responder a cenários de desastre.
Gerenciamento de dependências
Seu pipeline de CI/CD pode ter muitas dependências, que também podem ser fontes de falhas. Uma lista completa das dependências precisa ser identificada, conforme descrito anteriormente neste documento em Identificar dados e dependências. No entanto, as duas fontes mais comuns de dependências são as seguintes:
- Artefatos do aplicativo: por exemplo, pacotes, bibliotecas e imagens
- Sistemas externos: por exemplo, sistemas de criação de tíquetes e de notificação
Uma maneira de reduzir os riscos de dependências é adotar a prática de vender. A venda de pacotes ou imagens de aplicativos é o processo de criação e armazenamento de cópias em um repositório particular. O fornecimento de serviços de terceiros remove a dependência de fontes externas para esses pacotes ou imagens e também pode ajudar a evitar que malware seja inserido na cadeia de suprimentos de software.
Alguns dos benefícios de fornecer pacotes ou imagens de aplicativos incluem:
- Segurança: o fornecimento de serviços de terceiros remove a dependência de fontes externas para pacotes de aplicativos ou imagens, o que pode ajudar a evitar ataques de inserção de malware.
- Controle: ao vender pacotes ou imagens próprios, as organizações podem ter mais controle sobre a origem desses pacotes e imagens.
- Compliance: a terceirização pode ajudar as organizações a obedecer às regulamentações do setor, como a Certificação do modelo de maturidade em segurança cibernética.
Se a equipe decidir vender pacotes de aplicativos ou imagens, siga estas etapas principais:
- Identifique os pacotes de aplicativos ou imagens que precisam ser fornecidos.
- Crie um repositório privado para armazenar os pacotes ou imagens fornecidos pelo fornecedor.
- Faça o download dos pacotes ou imagens da fonte original e armazene-os no repositório privado.
- Verifique a integridade dos pacotes ou imagens.
- Atualize os pacotes ou imagens fornecidos pelo fornecedor conforme necessário.
Os pipelines de CI/CD geralmente chamam sistemas de terceiros para realizar ações como executar verificações, registrar tíquetes ou enviar notificações. Na maioria dos casos, esses sistemas de terceiros têm as próprias estratégias de DR que precisam ser implementadas. No entanto, em alguns casos, elas podem não ter um plano de DR adequado, e essas instâncias precisam ser documentadas claramente no BCP. Em seguida, você precisa decidir se essas etapas no pipeline podem ser puladas por motivos de disponibilidade ou se é aceitável causar inatividade no pipeline de CI/CD.
Monitoramento e notificações
A CI/CD é como os sistemas de produção de aplicativos. Portanto, você também precisa implementar técnicas de monitoramento e notificação para suas ferramentas de CI/CD. Como prática recomendada, recomendamos implementar painéis e notificações de alerta. O repositório de exemplo do GitHub para o Cloud Monitoring tem muitos exemplos de painéis e políticas de alerta.
Também é possível implementar outros níveis de monitoramento, como indicadores de nível de serviço (SLIs, na sigla em inglês) e objetivos de nível de serviço (SLO). Esses níveis de monitoramento ajudam a acompanhar a integridade e o desempenho geral dos pipelines de CI/CD. Por exemplo, os SLOs podem ser implementados para acompanhar a latência dos estágios de criação e implantação. Essas SLOs ajudam as equipes a criar e lançar aplicativos na taxa e frequência que você quiser.
Procedimentos de acesso de emergência
Durante um desastre, pode ser necessário que as equipes de operações tomem medidas fora dos procedimentos padrão e tenham acesso de emergência a sistemas e ferramentas. Essas ações de emergência às vezes são chamadas de procedimentos de quebra de vidro. Como ponto de partida, implemente estas três práticas recomendadas:
- Tenha um plano e um procedimento de encaminhamento claros. Um plano claro ajuda a equipe de operações a saber quando ela precisa usar os procedimentos de acesso de emergência.
- Garanta que várias pessoas tenham acesso a informações importantes, como configurações e segredos.
- Desenvolva métodos de auditoria automatizados para acompanhar quando os procedimentos de acesso de emergência foram usados e por quem.
A seguir
- Saiba mais sobre os produtos Google Cloud usados neste documento:
- Consulte o guia de planejamento de recuperação de desastres.
- Teste outros recursos Google Cloud concluindo nossos tutoriais.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.
Colaboradores
Autores:
- Ben Good | Arquiteto de soluções
- Xiang Shen | Arquiteto de soluções
Outros colaboradores:
- Marco Ferrari | Arquiteto de soluções do Cloud
- Anuradha Bajpai | Arquiteto de soluções
- Rodd Zurcher | Arquiteto de soluções