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ínua (CI/CD). Ele também oferece orientações sobre como identificar e reduzir dependências ao desenvolver um plano de continuidade de negócios (BCP) abrangente. O documento inclui práticas recomendadas que podem ser aplicadas ao seu plano de continuidade de negócios, independentemente das ferramentas e processos usados. Presumimos que você conheça os conceitos básicos do ciclo de operações e entrega 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 de aplicativos, 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 operações e entrega de software e como elas funcionam juntas como um processo holístico.
O diagrama a seguir é uma visão simplificada do ciclo de desenvolvimento e operações de software, que inclui as três fases a seguir:
- Loop interno de desenvolvimento: codificar, testar e confirmar
- Integração contínua: criação, teste e segurança
- Entrega contínua: promoção, lançamento, reversão e métricas
Este 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.
Ao longo do ciclo de desenvolvimento e operações de software, é preciso considerar o impacto de um desastre na capacidade das equipes de operar e manter aplicativos essenciais para os negócios. Isso vai ajudar você a determinar o objetivo do tempo de recuperação (RTO) e o objetivo do ponto de recuperação (RPO) para as ferramentas na sua cadeia de ferramentas de CI/CD.
Além disso, a maioria das organizações tem vários 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 suas ferramentas. Por exemplo, alguns pipelines são mais críticos do que outros e têm requisitos de RTO e RPO mais baixos. É importante identificar os pipelines essenciais para os negócios no seu BCP, que também precisam receber mais atenção ao implementar práticas recomendadas para testes e execução de procedimentos de recuperação.
Como cada processo de CI/CD e sua cadeia de ferramentas são diferentes, o objetivo deste guia é 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 para as 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 na sua cadeia de ferramentas.
- Entenda as práticas recomendadas gerais para implementar um plano de recuperação de DR no 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. Isso ajuda sua organização a voltar 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 ações envolvidas na criação de um PCA eficaz. Embora muitas dessas etapas se apliquem de maneira geral ao gerenciamento de programas e à DR, algumas são mais relevantes para o planejamento da continuidade de negócios no seu processo de CI/CD. As etapas especificamente relevantes para o planejamento da continuidade de negócios para CI/CD são destacadas nas seções a seguir e também formam a base para a orientação no restante deste documento.
Início e planejamento
Nessa etapa 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 sua manutenção contínua. As principais etapas dessa fase incluem:
- Aprovação da liderança: garanta que a gestão sênior apoie e defenda o desenvolvimento do BCP. Atribua uma equipe dedicada ou uma pessoa 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 e os objetivos do seu BCP. Determine quais processos de negócios são críticos e precisam ser abordados no plano.
- Avaliação de riscos: 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 na cadeia de suprimentos.
- Análise de impacto: avalie as possíveis consequências dessas descobertas de avaliação de risco nas operações, finanças, reputação e satisfação do cliente da sua empresa.
Análise de impacto nos negócios
Nesta etapa, as equipes de negócios e técnicas analisam o impacto das interrupções nos clientes e na organização e priorizam a recuperação das funções comerciais críticas. Essas funções comerciais 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 da continuidade de negócios para CI/CD, principalmente as etapas de identificação de funções comerciais críticas e dependências de ferramentas. Além disso, entender sua cadeia de ferramentas de CI/CD, incluindo as dependências e como ela funciona no ciclo de vida do DevOps, é um elemento fundamental para desenvolver um BCP para seu 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 possam afetar a recuperação das suas funções críticas. As dependências são especialmente relevantes para garantir a operação contínua do processo de CI/CD na cadeia de ferramentas.
- RTO e RPO: defina limites aceitáveis para inatividade e perda de dados para cada função crítica. Essas metas de RTO e RPO estão vinculadas à importância de uma função de negócios para a continuidade das operações e envolvem ferramentas específicas necessárias para que a função opere sem problemas.
Desenvolvimento de estratégia
Nesta etapa, a equipe técnica desenvolve estratégias de recuperação para funções comerciais críticas, como restauração de operações e dados e comunicação com fornecedores e partes interessadas. O desenvolvimento de estratégias também é uma parte fundamental 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 da fase 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 funcionando durante interrupções.
- Recuperação de dados e de TI: crie planos para 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 as partes interessadas internas e externas durante e após uma interrupção.
Desenvolvimento do plano
Nesta etapa, a principal ação é documentar o BCP. A equipe técnica documenta as ferramentas, os processos, as estratégias de recuperação, a lógica e os procedimentos de cada função crítica. O desenvolvimento do plano também inclui a criação de instruções detalhadas para os funcionários seguirem durante uma interrupção. Durante a implementação e a manutenção contínua, talvez seja necessário fazer mudanças no plano, que deve ser tratado como um documento dinâmico.
Implementação
Nesta etapa, 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 teste inicial do BCP. A implementação também inclui o uso do plano se ocorrer uma interrupção para recuperar as operações regulares. As principais etapas de implementação incluem o seguinte:
- Teste e treinamento iniciais: depois que o BPC é documentado, teste-o com 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 uma interrupção ocorre, 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 que deve se tornar uma parte normal das suas operações de CI/CD. É importante revisar, testar e atualizar regularmente o BCP na sua organização para que ele permaneça 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 permaneça atual e eficaz. Atualize sempre que houver mudanças em pessoal, tecnologia ou processos comerciais.
- Lições aprendidas: após cada interrupção ou teste, faça um debriefing para identificar lições aprendidas e áreas de melhoria.
- Conformidade regulatória: alinhe seu PCO com as regulamentações e os padrões do setor.
- Conscientização dos funcionários: eduque continuamente os funcionários sobre o PCO 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 focado na restauração das operações de CI/CD. O processo de planejamento da continuidade de negócios para CI/CD começa com um entendimento completo da sua cadeia de ferramentas de CI/CD e como ela se relaciona com o ciclo de vida de operações e entrega 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, siga estas etapas principais:
- Entender o conjunto de ferramentas
- Identificar dados e dependências
- Determinar metas de RTO e RPO
- Escolha uma estratégia de alto nível para a continuidade dos negócios
- Documente seu BCP e implemente 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 toolchains de CI/CD são compostas por muitas ferramentas individuais diferentes, e as possíveis combinações parecem infinitas. No entanto, entender sua cadeia de ferramentas de CI/CD e as dependências dela é fundamental para o planejamento de continuidade de negócios para CI/CD. A principal missão do seu processo de CI/CD é entregar código aos sistemas de produção para consumo do usuário final. Ao longo desse processo, muitos sistemas e fontes de dados diferentes são usados. Conhecer essas fontes 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 está sob seu controle direto e inclui o seguinte:
- A origem das suas inscrições
- Ferramentas na sua plataforma de CI/CD, como Cloud Build ou Cloud Deploy
- Interconexões básicas das diferentes ferramentas
Conforme mostrado no diagrama, o fluxo principal do aplicativo de exemplo é o seguinte:
- Eventos de desenvolvimento de código no loop interno de desenvolvimento acionam o 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. Em seguida, 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 teste de unidade.
- Se a build for bem-sucedida, o Cloud Build vai criar a imagem do contêiner e enviá-la para o repositório de contêineres no Artifact Registry.
- Um pipeline do Cloud Deploy é acionado, extrai a imagem do contêiner do repositório e a implanta em um ambiente do GKE.
Para entender as ferramentas usadas no seu processo de CI/CD, sugerimos criar um diagrama que mostre o processo 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 seu conjunto de ferramentas de CI/CD, como a fase do processo, a finalidade da ferramenta, a ferramenta em si e as equipes afetadas por uma falha dela. Esta tabela fornece um mapeamento das ferramentas no seu conjunto de ferramentas e identifica as ferramentas com fases específicas do processo de CI/CD. Assim, a tabela ajuda você a ter uma visão geral da sua cadeia de ferramentas e de como ela opera.
As tabelas a seguir mapeiam o exemplo mencionado anteriormente de um aplicativo corporativo para cada ferramenta no diagrama. Para dar 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 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 |
|
|
Analise o código em busca de problemas de segurança. |
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 garantir a qualidade e a usabilidade. |
| Fase: geração de registros |
|
|
Mantenha registros para observabilidade e solução de problemas. |
|
| Fase: monitoramento | Monitoramento de arquivos de configuração, incluindo:
|
|
|
À medida que você trabalha no seu BCP e entende melhor a cadeia de ferramentas de CI/CD, é possível atualizar o diagrama e a tabela de mapeamento.
Identificar dados e dependências
Depois de concluir o inventário de base e o mapa da sua cadeia de ferramentas de CI/CD, a próxima etapa é capturar dependências de metadados ou configurações. Ao implementar seu BCP, é fundamental ter uma compreensão clara das dependências na sua cadeia de ferramentas de CI/CD. As dependências geralmente se enquadram em uma de duas categorias: internas (de primeira ordem) e externas (de segunda ou terceira ordem).
Dependências internas
As dependências internas são sistemas usados pelo conjunto de ferramentas e que você controla diretamente. As dependências internas também são selecionadas pelas suas equipes. Esses sistemas incluem sua ferramenta de CI, o repositório de gerenciamento de chaves e o sistema de controle de origem. Você pode pensar nesses sistemas como estando na próxima camada abaixo da própria cadeia de ferramentas.
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 da cadeia de ferramentas de primeira camada para o aplicativo Java de exemplo e inclui também as dependências internas da cadeia de ferramentas: credenciais do aplicativo, arquivo deploy.yaml e arquivo cloudbuild.yaml.
O diagrama mostra que, para trabalhar com sucesso no exemplo de aplicativo Java, ferramentas como o Cloud Build, o Cloud Deploy e o GKE precisam de acesso a dependências que não são da cadeia de ferramentas,como cloudbuild.yaml, deploy.yaml e credenciais de aplicativos. Ao analisar sua própria cadeia de ferramentas de CI/CD, você avalia se uma ferramenta pode ser executada sozinha ou se 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
cadeia de ferramentas, mas são necessárias para que o aplicativo seja iniciado na
implantação. Assim, 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 definem o pipeline de CI/CD para
esse aplicativo.
O BCP para o aplicativo Java de exemplo 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 instaladas 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 em si ainda estejam operacionais.
Dependências externas
Dependências externas são sistemas externos que sua cadeia de ferramentas usa para operar e que não estão sob seu controle direto. As dependências externas resultam das ferramentas e frameworks de programação selecionados. Pense nas dependências externas como outra camada abaixo das 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 PCO. 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 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 corretamente. Ao avaliar sua própria cadeia de ferramentas, documente as dependências externas que suas 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 baixar 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 suas dependências internas como dependências de segunda ordem. Essas dependências de segunda ordem podem ter as próprias dependências, que podem ser consideradas dependências de terceira ordem. É importante documentar e contabilizar as dependências externas de segunda e terceira ordem no seu BCP para recuperar as operações durante uma interrupção.
Determine as metas de RTO e RPO
Depois de entender a cadeia de ferramentas e as dependências, você define as metas de RTO e RPO para suas ferramentas. As ferramentas no processo de CI/CD realizam ações diferentes que podem ter um impacto diferente nos negócios. Portanto, é importante corresponder a prioridade das metas de RTO e RPO da função comercial ao impacto dela nos negócios. Por exemplo, criar novas versões de aplicativos na etapa de CI pode ser menos impactante do que implantar aplicativos na etapa de CD. Assim, 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 do aplicativo Java, mas estão 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 estão posicionados da seguinte maneira:
- Impacto moderado para desenvolvedores, baixo impacto nas operações: fontes de dados de teste
- Impacto moderado no desenvolvedor e nas 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 no desenvolvedor, impacto moderado nas 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), Artifact Registry
Componentes como gerenciamento de controle de origem e Artifact Registry, que têm alto impacto no desenvolvedor e nas operações, são os que mais afetam os negócios. Esses componentes precisam ter os menores objetivos de RTO e RPO. Os componentes nos outros quadrantes têm uma prioridade menor, o que significa que os objetivos de RTO e RPO serão maiores. Em geral, os objetivos de RTO e RPO para os componentes da sua cadeia de ferramentas devem ser definidos de acordo com a quantidade de dados ou perda de 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 de IaC no gráfico. Uma comparação dessas 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 interrupção do Artifact Registry afeta significativamente sua capacidade de implantar ou escalonar automaticamente o aplicativo, ele teria metas de RTO e RPO menores em comparação com outras ferramentas. Em contraste, o gráfico mostra que uma interrupção de pipeline de IaC tem um impacto menor nas operações comerciais do que outras ferramentas. O pipeline de IaC teria objetivos de RTO e RPO mais altos porque você pode usar outros métodos para implantar ou atualizar a infraestrutura durante uma interrupção.
Escolha uma estratégia de alto nível 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 dos negócios: ativa/passiva ou backup/restauração. A estratégia escolhida depende dos seus requisitos e orçamento. Cada estratégia tem compensações de 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 suas compensações.
Além disso, quando ocorrem eventos de interrupção de serviço, eles podem afetar mais do que sua implementação de CI/CD. Também é preciso considerar toda a infraestrutura necessária, incluindo rede, computação e armazenamento. Você precisa ter um plano de DR para esses elementos básicos e testá-lo regularmente para garantir que ele seja eficaz.
Ativo/passivo
Com a estratégia ativa/passiva (ou espera ativa), seus aplicativos e o pipeline de CI/CD passivo são espelhos. No entanto, o pipeline passivo não está processando a carga de trabalho do cliente nem qualquer build ou implantação. Por isso, ele está em um estado reduzido. Essa estratégia é mais adequada para aplicativos essenciais em que uma pequena quantidade de inatividade é tolerável.
O diagrama a seguir mostra uma configuração ativa/passiva para o aplicativo Java de exemplo usado neste documento. O pipeline passivo duplica totalmente a cadeia de ferramentas do aplicativo em uma região diferente.
Neste exemplo, a região 1 hospeda o pipeline de CI/CD ativo, e a região 2 tem a contraparte passiva. O código é hospedado em um provedor de serviços Git externo, como GitHub ou GitLab. Um evento do repositório (como uma mesclagem de uma solicitação de envio) pode acionar o pipeline de CI/CD na região 1 para criar, testar e implantar no ambiente de produção multirregional.
Se ocorrer um problema crítico no pipeline da região 1, como uma interrupção regional de um produto, o resultado poderá ser implantações com falha ou builds sem sucesso. Para se recuperar rapidamente do problema, atualize o gatilho do repositório Git e mude para o pipeline da região 2, que se tornará o ativo. Depois que o problema for resolvido na região 1, você poderá manter o pipeline na região 1 como passivo.
As vantagens da estratégia ativa/passiva incluem:
- Tempo de inatividade baixo: como o pipeline passivo foi implantado, mas está reduzido, o tempo de inatividade é limitado ao tempo necessário para aumentar a escala do 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 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 necessário durante a recuperação de incidentes. Essa estratégia é mais adequada para casos de uso de baixa prioridade. 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ão 1 hospeda o pipeline de CI/CD ativo. Em vez de ter um pipeline passivo na região 2, 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ão 1, também precisará sincronizar os dados com seus locais de DR.
Da mesma forma, se ocorrer um problema crítico no pipeline da região 1, como uma interrupção regional do produto, você poderá 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, você poderá executar o script de automação no repositório e recriar o pipeline de CI/CD na região 2.
Se a interrupção for um evento de 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 incorre no menor custo porque você implanta o pipeline de backup apenas 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 precisa 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 do artefato e o tempo para recuperar dependências externas também podem ser significativamente maiores.
Documente seu BCP e implemente práticas recomendadas
Depois de mapear a cadeia de ferramentas de CI/CD, identificar as dependências 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 o BCP, documente as estratégias, os processos e os procedimentos para restaurar cada função crítica. Esse processo de documentação inclui a criação de procedimentos detalhados para que os funcionários em funções específicas 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 toolchains de CI/CD possam ser muito diferentes, dois padrões principais de práticas recomendadas são comuns, independente da toolchain: um entendimento abrangente das dependências e a 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 tão impactantes quanto as de primeira ordem. Por isso, é importante implementar práticas recomendadas e medidas de redundância também 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 ou backup local dessas bibliotecas, talvez não seja possível criar o aplicativo se a fonte externa de onde você extrai as bibliotecas estiver desconectada.
Em termos de automação, a implementação de 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 sua 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, por sua vez, promove a adoção das práticas recomendadas para backups.
Depois de implementar a toolchain de acordo com seu BCP e as práticas recomendadas para dependências e automação, seu processo de CI/CD e as estratégias de recuperação podem mudar. Documente todas as mudanças nas estratégias, processos e procedimentos de recuperação resultantes da revisão do BCP e da implementação das práticas recomendadas.
Testar cenários de falha e manter o plano
É fundamental revisar, testar e atualizar regularmente o BCP. Testar o BCP e os 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. Usando 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:
- Automatize 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: o Google Cloud Observability oferece ferramentas de geração de registros e monitoramento que podem ser acessadas por chamadas de API. Isso significa que é possível 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.
- Realize o teste 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 de integração e funcionais no ambiente de DR. Você também pode realizar um teste em que o caminho de acesso habitual ao Google Cloud não funcione.
No Google, testamos regularmente nosso BCP com 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 algumas práticas recomendadas que podem ser implementadas para atingir seus objetivos de RTO e RPO. Essas práticas recomendadas se aplicam de maneira geral à DR para CI/CD, e não a ferramentas específicas. Independente da sua implementação, teste o 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, implemente as práticas recomendadas de alta disponibilidade. Seguir as práticas recomendadas de alta disponibilidade coloca seu processo de CI/CD em uma posição mais proativa, porque essas práticas tornam o processo de CI/CD mais resiliente a falhas. Essas estratégias proativas devem ser usadas com controles e procedimentos mais reativos para recuperação e backup.
Confira 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 trabalho são criadas dinamicamente, então a recuperação de nós com falha é 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 suas ferramentas e garanta que elas estejam altamente disponíveis. Por exemplo, é possível armazenar em cache todas as bibliotecas de terceiros no registro de artefatos.
Procedimentos de backup
Ao implementar a recuperação de desastres para CI/CD, algumas ferramentas e processos são mais adequados para estratégias de backup/restauração. Uma estratégia de backup abrangente é a primeira etapa para controles reativos eficazes. Com os backups, é possível recuperar seu pipeline de CI/CD com interrupção mínima em caso de agentes maliciosos ou desastres.
Para começar, implemente as três práticas recomendadas a seguir. No entanto, para 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.yamle arquivos YAML do Kubernetes. - Redundância: garanta que não haja um único ponto de falha ao acessar secrets, como senhas, certificados e chaves de API. Exemplos de práticas a serem evitadas incluem apenas uma pessoa saber a senha ou armazenar a chave de API em um único servidor em uma região específica.
- Backups: verifique com frequência a integridade e a precisão dos seus backups. 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:
- Artefatos do aplicativo: por exemplo, pacotes, bibliotecas e imagens
- Sistemas externos: por exemplo, sistemas de emissão de tíquetes e de notificação
Uma maneira de reduzir os riscos das dependências é adotar a prática de vendoring. O fornecimento de pacotes ou imagens de aplicativos é o processo de criação e armazenamento de cópias deles em um repositório particular. O vendoring 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.
Confira alguns dos benefícios de usar pacotes ou imagens de aplicativos de fornecedores:
- Segurança: o vendoring remove a dependência de fontes externas para pacotes ou imagens de aplicativos, o que pode ajudar a evitar ataques de inserção de malware.
- Controle: ao vender os próprios pacotes ou imagens, as organizações podem ter mais controle sobre a origem deles.
- Compliance: a venda de produtos e serviços 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 sua equipe decidir vender pacotes de aplicativos ou imagens, siga estas etapas principais:
- Identifique os pacotes ou imagens de aplicativos que precisam ser fornecidos.
- Crie um repositório particular para armazenar os pacotes ou imagens vendidas.
- 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 vendidas 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 externos têm estratégias próprias de DR que precisam ser implementadas. No entanto, em alguns casos, eles podem não ter um plano de DR adequado, e essas instâncias precisam ser claramente documentadas no BCP. Em seguida, decida se essas etapas no pipeline podem ser ignoradas por motivos de disponibilidade ou se é aceitável causar inatividade no pipeline de CI/CD.
Monitoramento e notificações
Seu 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, implemente painéis e notificações de alerta. O repositório de amostra do GitHub para o Cloud Monitoring tem muitos exemplos de painéis e políticas de alertas.
Também é possível implementar outros níveis de monitoramento, como indicadores de nível de serviço (SLIs) e objetivos de nível de serviço (SLOs). Esses níveis de monitoramento ajudam a acompanhar a integridade e o desempenho gerais dos seus pipelines de CI/CD. Por exemplo, os SLOs podem ser implementados para rastrear a latência das etapas de build e implantação. Esses SLOs ajudam as equipes a criar e lançar aplicativos na taxa e frequência desejadas.
Procedimentos de acesso de emergência
Durante um desastre, talvez seja 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 emergência. Para começar, 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 usar os procedimentos de acesso de emergência.
- Garanta que várias pessoas tenham acesso a informações críticas, como configuração e secrets.
- Desenvolva métodos de auditoria automatizados para acompanhar quando e por quem os procedimentos de acesso de emergência foram usados.
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 do 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 | Arquiteta de soluções
- Rodd Zurcher | Arquiteto de soluções