Este documento descreve a recuperação de desastres (DR) e o planeamento de continuidade do negócio no contexto da integração contínua e entrega contínua (CI/CD). Também fornece orientações sobre como identificar e mitigar dependências quando desenvolve um plano de continuidade do negócio (BCP) abrangente. O documento inclui práticas recomendadas que pode aplicar ao seu PCN, independentemente das ferramentas e dos processos que usa. O documento pressupõe que conhece os princípios básicos do ciclo de operações e entrega de software, CI/CD e DR.
Os pipelines de CI/CD são responsáveis pela criação e implementação das suas aplicações críticas para a empresa. Assim, tal como a sua infraestrutura de aplicações, o processo de CI/CD requer planeamento para DR e continuidade do negócio. Quando pensa na recuperação de desastres e na continuidade do negócio para CI/CD, é importante compreender cada fase do ciclo de operações e entrega de software, e perceber como funcionam em conjunto como um processo holístico.
O diagrama seguinte é uma vista simplificada do ciclo de desenvolvimento e operações de software, que inclui as três fases seguintes:
- Ciclo interno de desenvolvimento: codificar, experimentar e confirmar
- Integração contínua: criação, testes e segurança
- Entrega contínua: promova, implemente, reverta e consulte 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 implementação do ciclo de desenvolvimento e operações de software.
Ao longo do ciclo de desenvolvimento e operações de software, tem de considerar o impacto de um desastre na capacidade das equipas de operar e manter as aplicações essenciais para a empresa. Ao fazê-lo, ajuda a determinar o objetivo de tempo de recuperação (OTR) e o objetivo de ponto de recuperação (OPR) 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 diferentes aplicações e conjuntos de infraestrutura, e cada pipeline tem requisitos únicos para DR e planeamento de continuidade do negócio. A estratégia de recuperação que escolher para um pipeline varia consoante 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 a empresa no seu PCN. Estes também devem receber mais atenção quando implementar práticas recomendadas para testar e executar procedimentos de recuperação.
Uma vez que cada processo de CI/CD e a respetiva cadeia de ferramentas são diferentes, os objetivos deste guia são ajudar a identificar pontos únicos de falha no seu processo de CI/CD e desenvolver um BCP abrangente. As secções seguintes ajudam a fazer o seguinte:
- Compreenda o que é necessário para recuperar de um evento de recuperação de desastres que afeta o seu processo de CI/CD.
- Determine o RTO e o RPO para as ferramentas no seu processo de CI/CD.
- Compreenda 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.
- Compreenda as práticas recomendadas gerais para implementar um plano de recuperação de DR para o seu processo de CI/CD.
Compreenda o processo de continuidade do negócio
A criação de um PCN é fundamental para ajudar a garantir que a sua organização pode continuar as suas operações em caso de interrupções e emergências. Ajuda a sua organização a regressar rapidamente a um estado de funcionamento normal para o respetivo processo de CI/CD.
As secções seguintes descrevem as fases de alto nível que incluem os passos envolvidos na criação de um PCN eficaz. Embora muitos destes passos se apliquem de forma geral à gestão de programas e à recuperação de desastres, determinados passos são mais relevantes para o planeamento da continuidade da empresa para o seu processo de CI/CD. Os passos especificamente relevantes para o planeamento da continuidade da empresa para CI/CD são realçados nas secções seguintes e também formam a base para as orientações no resto deste documento.
Iniciação e planeamento
Nesta fase inicial, as equipas técnicas e comerciais trabalham em conjunto para estabelecer as bases do processo de planeamento da continuidade do negócio e a sua manutenção contínua. Os principais passos desta fase incluem o seguinte:
- Aprovação da liderança: certifique-se de que a gestão sénior apoia e defende o desenvolvimento do PCP. Atribua uma equipa dedicada ou um indivíduo responsável pela supervisão do plano.
- Atribuição de recursos: atribua o orçamento, o pessoal e os recursos necessários para desenvolver e implementar o PCP.
- Âmbito e objetivos: defina o âmbito do seu PCP e os respetivos objetivos. Determinar que processos empresariais são críticos e têm de ser abordados no plano.
- Avaliação de riscos: identifique potenciais riscos e ameaças que possam perturbar a sua empresa, como desastres naturais, violações de cibersegurança ou interrupções na cadeia de abastecimento.
- Análise de impacto: avalie as potenciais consequências destas conclusões da avaliação de riscos nas operações comerciais, finanças, reputação e satisfação do cliente da sua empresa.
Análise de impacto para a empresa
Nesta fase, as equipas empresariais e técnicas analisam o impacto empresarial das interrupções nos seus clientes e organização, e dão prioridade à recuperação das funções empresariais críticas. Estas funções empresariais são realizadas por diferentes ferramentas durante as diferentes fases de um processo de criação e implementação.
A análise do impacto empresarial é uma fase importante no processo de planeamento da continuidade empresarial para CI/CD, especialmente os passos para identificar funções empresariais críticas e dependências de ferramentas. Além disso, compreender a sua cadeia de ferramentas de CI/CD, incluindo as respetivas dependências e como funciona no seu ciclo de vida de DevOps, é um elemento essencial para desenvolver um PCN para o seu processo de CI/CD.
Os passos principais na fase de análise do impacto empresarial incluem o seguinte:
- Funções críticas: determinam as funções e os processos empresariais essenciais que têm de ser priorizados para recuperação. Por exemplo, se determinar que a implementação de aplicações é mais crítica do que a execução de testes unitários, deve dar prioridade à recuperação dos processos e das ferramentas de implementação de aplicações.
- 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 o funcionamento contínuo do seu processo de CI/CD através da respetiva cadeia de ferramentas.
- RTO e RPO: defina limites aceitáveis para limites de inatividade e perda de dados para cada função crítica. Estes objetivos de RTO e RPO estão associados à importância de uma função empresarial para a continuidade das operações e envolvem ferramentas específicas necessárias para que a função empresarial opere sem problemas.
Desenvolvimento de estratégias
Nesta fase, a equipa técnica desenvolve estratégias de recuperação para funções empresariais críticas, como o restauro de operações e dados, e a comunicação com fornecedores e partes interessadas. O desenvolvimento de estratégias também é uma parte fundamental do planeamento da continuidade do negócio para o seu processo de CI/CD, especialmente o passo de selecionar estratégias de recuperação de alto nível para funções críticas.
Os principais passos na fase de desenvolvimento da estratégia incluem o seguinte:
- Estratégias de recuperação: desenvolva estratégias para restaurar funções críticas. Estas estratégias podem envolver localizações alternativas, trabalho remoto ou sistemas de cópia de segurança. Estas estratégias estão associadas aos alvos de RTO e RPO para cada função crítica.
- Relações com fornecedores: estabeleça planos de comunicação e coordenação com os principais fornecedores para manter a cadeia de abastecimento em funcionamento durante as interrupções.
- Recuperação de dados e TI: crie planos para cópias de segurança de dados, recuperação de sistemas de TI e medidas de cibersegurança.
- 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 de planos
Nesta fase, o passo principal é documentar o PCN. A equipa técnica documenta as ferramentas, os processos, as estratégias de recuperação, a fundamentação e os procedimentos para cada função crítica. O planeamento do desenvolvimento também inclui a escrita de instruções passo a passo para os funcionários seguirem durante uma interrupção. Durante a implementação e a manutenção contínua, podem ter de ser introduzidas alterações no plano, e o plano deve ser tratado como um documento dinâmico.
Implementação
Nesta fase, implementa o plano para a sua organização através do PCN que a equipa técnica criou. A implementação inclui a formação dos funcionários e os testes iniciais do PCN. A implementação também inclui a utilização do plano se ocorrer uma interrupção para recuperar as operações normais. Os principais passos de implementação incluem o seguinte:
- Testes e formação iniciais: depois de documentar o BPC, teste-o através de simulações e exercícios para identificar lacunas e melhorar a eficácia. Dê formação aos funcionários sobre as respetivas funções e responsabilidades durante uma interrupção.
- Ativação: quando ocorre uma interrupção, inicie o PCN de acordo com os acionadores e os 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
Esta fase não é um processo definido que ocorre apenas uma vez. Em vez disso, representa um esforço contínuo e permanente que deve tornar-se uma parte normal das suas operações de CI/CD. É importante rever, testar e atualizar regularmente o PCN na sua organização para que permaneça relevante e acionável se ocorrer uma interrupção. Os passos principais de manutenção e revisão incluem o seguinte:
- Atualizações regulares: reveja e atualize o PCN periodicamente para que se mantenha atual e eficaz. Atualize-o sempre que houver alterações ao pessoal, à tecnologia ou aos processos empresariais.
- Lições aprendidas: após cada interrupção ou teste, faça um balanço para identificar lições aprendidas e áreas de melhoria.
- Conformidade regulamentar: alinhe o seu PCN com os regulamentos e as normas da indústria.
- Consciencialização dos funcionários: informe continuamente os funcionários sobre o PCN e as respetivas funções na sua execução.
Crie um processo de continuidade do negócio para CI/CD
Esta secção fornece diretrizes específicas para criar um PCP focado especificamente na restauração das suas operações de CI/CD. O processo de planeamento da continuidade da empresa para CI/CD começa com uma compreensão detalhada da sua cadeia de ferramentas de CI/CD e como se relaciona com o ciclo de vida da entrega e das operações de software. Com esta compreensão como base, pode planear como a sua organização vai recuperar as operações de CI/CD de uma interrupção.
Para criar um processo de continuidade de negócios robusto para o seu processo de CI/CD, tem de seguir os seguintes passos principais:
- Compreenda a cadeia de ferramentas
- Identifique dados e dependências
- Determine os alvos de RTO e RPO
- Escolha uma estratégia de alto nível para a continuidade do negócio
- Documente o seu PCP e implemente práticas recomendadas
- Teste cenários de falha e mantenha o plano
As secções seguintes fornecem mais detalhes sobre cada um destes passos.
Compreenda a cadeia de ferramentas
As cadeias de ferramentas de CI/CD são compostas por muitas ferramentas individuais diferentes e as possíveis combinações de ferramentas podem parecer infinitas. No entanto, compreender a sua cadeia de ferramentas de CI/CD e as respetivas dependências é fundamental para o planeamento de continuidade do negócio para CI/CD. A missão principal do seu processo de CI/CD é fornecer código aos sistemas de produção para consumo do utilizador final. Ao longo desse processo, são usados muitos sistemas e origens de dados diferentes. Conhecer essas origens de dados e dependências é fundamental para desenvolver um PCN. Para começar a criar a sua estratégia de recuperação de desastres, primeiro, tem de compreender as diferentes ferramentas envolvidas no seu processo de CI/CD.
Para ajudar a compreender como avaliar a sua própria cadeia de ferramentas e desenvolver o seu PCN, este documento usa o exemplo de uma aplicação Java empresarial que é executada no GKE. O diagrama seguinte mostra a primeira camada de dados e sistemas na cadeia de ferramentas. Esta primeira camada está sob o seu controlo direto e inclui o seguinte:
- A origem das suas aplicações
- Ferramentas na sua plataforma de CI/CD, como o Cloud Build ou o Cloud Deploy
- Interligações básicas das diferentes ferramentas
Conforme mostrado no diagrama, o fluxo principal da aplicação de exemplo é o seguinte:
- Eventos de desenvolvimento de código no acionador do ciclo interno de desenvolvimento do Cloud Build.
- O Cloud Build extrai o código-fonte da aplicação do repositório de controlo de origem.
- O Cloud Build identifica todas as dependências necessárias especificadas nos ficheiros de configuração de compilação, como ficheiros JAR de terceiros do repositório Java no Artifact Registry. Em seguida, o Cloud Build extrai estas dependências das respetivas localizações de origem.
- O Cloud Build executa a compilação e faz a validação necessária, como a análise estática e os testes de unidade.
- Se a compilação for bem-sucedida, o Cloud Build cria a imagem do contentor e envia-a para o repositório de contentores no Artifact Registry.
- É acionado um pipeline do Cloud Deploy, e o pipeline extrai a imagem do contentor do repositório e implementa-a num ambiente do GKE.
Para compreender as ferramentas usadas no seu processo de CI/CD, sugerimos que crie um diagrama que mostre o seu processo de CI/CD e as ferramentas usadas no mesmo, semelhante ao exemplo neste documento. Em seguida, pode usar o diagrama para criar uma tabela que capture informações importantes sobre a cadeia de ferramentas de CI/CD, como a fase do processo, a finalidade da ferramenta, a própria ferramenta e as equipas afetadas por uma falha da ferramenta. Esta tabela fornece um mapeamento das ferramentas na sua cadeia de ferramentas e identifica as ferramentas com fases específicas do processo de CI/CD. Assim, a tabela pode ajudar a ter uma vista geral da sua cadeia de ferramentas e do respetivo funcionamento.
As tabelas seguintes mapeiam o exemplo mencionado anteriormente de uma aplicação empresarial para cada ferramenta no diagrama. Para oferecer um exemplo mais completo de como pode ser um mapeamento da cadeia de ferramentas, estas tabelas também incluem outras ferramentas que não são mencionadas no diagrama, como ferramentas de segurança ou ferramentas de teste.
A primeira tabela é mapeada para ferramentas usadas na fase de CI do processo de CI/CD:
| Integração contínua | Origem | Ferramentas usadas | Utilizadores principais | Utilização |
|---|---|---|---|---|
| Fase: controlo de origem |
|
|
|
|
| Fase: criação |
|
Programadores |
|
|
| Fase: teste |
|
Programadores |
Execute testes de unidades e de integração numa plataforma consistente e a pedido. |
|
| Fase: segurança |
|
|
Analise o código quanto a problemas de segurança. |
A segunda tabela foca-se nas ferramentas usadas na fase de CD do processo de CI/CD:
| Implementação contínua | Origem | Ferramentas usadas | Utilizadores principais | Utilização |
|---|---|---|---|---|
| Fase: implementação | Ficheiros de configuração de implementação |
|
Automatize as implementações para promover, aprovar e gerir o tráfego numa plataforma segura e consistente. |
|
| Fase: teste |
|
|
Programadores |
Teste a integração e o desempenho para garantir a qualidade e a usabilidade. |
| Fase: registo |
|
|
Manter registos para observabilidade e resolução de problemas. |
|
| Fase: monitorização | Monitorização de ficheiros de configuração, incluindo o seguinte:
|
|
|
À medida que continua a trabalhar no seu PCN e a sua compreensão da cadeia de ferramentas de CI/CD aumenta, pode atualizar o diagrama e a tabela de mapeamento.
Identifique dados e dependências
Depois de concluir o inventário base e o mapeamento da sua cadeia de ferramentas de CI/CD, o passo seguinte é capturar todas as dependências de metadados ou configurações. Quando implementar o seu PCP, é fundamental que compreenda claramente as dependências na sua cadeia de ferramentas de CI/CD. Normalmente, as dependências pertencem a uma de duas categorias: dependências internas (de primeira ordem) e dependências externas (de segunda ou terceira ordem).
Dependências internas
As dependências internas são sistemas que a sua cadeia de ferramentas usa e que estão diretamente sob o seu controlo. As dependências internas também são selecionadas pelas suas equipas. Estes sistemas incluem a sua ferramenta de IC, o repositório de gestão de chaves e o sistema de controlo de origem. Pode considerar que estes sistemas estão na camada abaixo da própria cadeia de ferramentas.
Por exemplo, o diagrama seguinte fornece um exemplo de como as dependências internas se encaixam numa cadeia de ferramentas. O diagrama expande o diagrama da cadeia de ferramentas de primeira camada anterior para a aplicação Java de exemplo, de modo a incluir também as dependências internas da cadeia de ferramentas: credenciais da aplicação, o ficheiro deploy.yaml e o ficheiro cloudbuild.yaml.
O diagrama mostra que, para funcionar com êxito na aplicação Java de exemplo, as ferramentas como o Cloud Build, o Cloud Deploy e o GKE precisam de acesso a dependências que não fazem parte da cadeia de ferramentas,como cloudbuild.yaml, deploy.yaml e credenciais da aplicação. Quando analisa a sua própria cadeia de ferramentas de CI/CD, avalia se uma ferramenta pode ser executada sozinha ou se precisa de chamar outro recurso.
Considere as dependências internas documentadas para a aplicação Java de exemplo.
As credenciais são armazenadas no Secret Manager, que não faz parte da cadeia de ferramentas, mas as credenciais são necessárias para a aplicação ser iniciada na implementação. Assim, as credenciais da aplicação são incluídas como uma dependência para o GKE. Também é importante incluir os ficheiros deploy.yaml e cloudbuild.yaml como dependências, mesmo que estejam armazenados no controlo de origem com o código da aplicação, porque definem o pipeline de CI/CD para essa aplicação.
O BCP para a aplicação Java de exemplo deve ter em conta estas dependências nos ficheiros deploy.yaml e cloudbuild.yaml, porque recriam o pipeline de CI/CD depois de as ferramentas estarem implementadas durante o processo de recuperação.
Além disso, se estas dependências forem comprometidas, a função geral do pipeline é afetada, mesmo que as próprias ferramentas ainda estejam operacionais.
Dependências externas
As dependências externas são sistemas externos dos quais a sua cadeia de ferramentas depende para funcionar e não estão sob o seu controlo direto. As dependências externas resultam das ferramentas e das estruturas de programação que selecionou. Pode considerar as dependências externas como estando mais abaixo do que as dependências internas. Alguns exemplos de dependências externas incluem repositórios npm ou Maven e serviços de monitorização.
Embora as dependências externas estejam fora do seu controlo, pode incorporá-las no seu PCN. O diagrama seguinte atualiza o exemplo de aplicação Java incluindo dependências externas, além das internas: bibliotecas Java no Maven Central e imagens Docker no Docker Hub. As bibliotecas Java são usadas pelo Artifact Registry e as imagens Docker são usadas pelo Cloud Build.
O diagrama mostra que as dependências externas podem ser importantes para o seu processo de CI/CD: o Cloud Build e o GKE dependem de dois serviços externos (Maven e Docker) para funcionar com êxito. Quando avaliar a sua própria cadeia de ferramentas, documente as dependências externas que as suas ferramentas precisam de aceder e os procedimentos para lidar com interrupções de dependências.
No exemplo da aplicação Java, não é possível controlar diretamente as bibliotecas Java e as imagens do Docker, mas ainda pode incluí-las e os respetivos procedimentos de recuperação no PCP. Por exemplo, considere as bibliotecas Java no Maven. Embora as bibliotecas sejam armazenadas numa origem externa, pode estabelecer um processo para transferir e atualizar periodicamente as bibliotecas Java para um repositório Maven local ou um registo de artefactos. Ao fazê-lo, o processo de recuperação não tem de depender da disponibilidade da origem de terceiros.
Além disso, é importante compreender que as dependências externas podem ter mais do que uma camada. Por exemplo, pode considerar os sistemas usados pelas suas dependências internas como dependências de segunda ordem. Estas dependências de segunda ordem podem ter as suas próprias dependências, que pode considerar como dependências de terceira ordem. Tenha em atenção que pode ter de documentar e contabilizar as dependências externas de segunda e terceira ordem no seu PCN para recuperar as operações durante uma interrupção.
Determine os alvos de RTO e RPO
Depois de desenvolver uma compreensão da sua cadeia de ferramentas e dependências, define os alvos de RTO e RPO para as suas ferramentas. As ferramentas no processo de CI/CD executam cada uma uma ação diferente que pode ter um impacto diferente na empresa. Por conseguinte, é importante fazer corresponder a prioridade dos objetivos de RTO e RPO da função empresarial ao respetivo impacto na empresa. Por exemplo, a criação de novas versões de aplicações através da fase de CI pode ter um impacto menor do que a implementação de aplicações através da fase de CD. Assim, as ferramentas de implementação podem ter objetivos de RTO e RPO mais longos do que outras funções.
O gráfico de quatro quadrantes seguinte é um exemplo geral de como pode determinar os seus objetivos 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 origens de dados de teste. As ferramentas não foram mencionadas nos diagramas anteriores para a aplicação Java, mas estão incluídas aqui para fornecer um exemplo mais completo.
O gráfico mostra quadrantes baseados no nível de impacto nos programadores e nas operações. No gráfico, os componentes estão posicionados da seguinte forma:
- Impacto moderado para programadores e baixo impacto nas operações: teste origens de dados
- Impacto moderado no programador e nas operações: Cloud Key Management Service, Cloud KMS
- Impacto moderado no programador, impacto elevado nas operações: pipeline de implementação
- Impacto elevado no programador, impacto baixo nas operações: ciclo interno de desenvolvimento
- Impacto elevado no programador, impacto moderado nas operações: pipeline de CI, pipeline de infraestrutura como código (IaC)
- Impacto elevado no programador, impacto elevado nas operações: gestão de controlo de fontes (SCM), Artifact Registry
Os componentes como a gestão do controlo de origem e o Artifact Registry que têm um elevado impacto no programador e nas operações têm o maior impacto na empresa. Estes componentes devem ter os objetivos de RTO e RPO mais baixos. Os componentes nos outros quadrantes têm uma prioridade inferior, o que significa que os objetivos de RTO e RPO serão mais elevados. Em geral, os objetivos de RTO e RPO para os componentes da cadeia de ferramentas devem ser definidos de acordo com a quantidade de dados ou a perda de configuração que pode ser tolerada em comparação com o tempo necessário para restaurar o serviço para esse componente.
Por exemplo, considere as diferentes localizações do Artifact Registry e do pipeline de IaC no gráfico. Uma comparação destas duas ferramentas mostra que uma indisponibilidade do Artifact Registry tem um impacto maior nas operações empresariais do que uma indisponibilidade no pipeline de IaC. Uma vez que uma indisponibilidade do Artifact Registry afeta significativamente a sua capacidade de implementar ou ajustar automaticamente a escala da sua aplicação, teria alvos de RTO e RPO inferiores em comparação com outras ferramentas. Por outro lado, o gráfico mostra que uma indisponibilidade do pipeline de IaC tem um impacto menor nas operações empresariais do que outras ferramentas. Em seguida, o pipeline de IaC teria objetivos de RTO e RPO mais elevados porque pode usar outros métodos para implementar ou atualizar a infraestrutura durante uma indisponibilidade.
Escolha uma estratégia de alto nível para a continuidade do negócio
Os processos de continuidade do negócio para aplicações de produção baseiam-se frequentemente numa das três estratégias de recuperação de desastres comuns. No entanto, para CI/CD, pode escolher entre duas estratégias de alto nível para a continuidade da empresa: ativa/passiva ou cópia de segurança/restauro. A estratégia que escolher depende dos seus requisitos e orçamento. Cada estratégia tem compromissos com a complexidade e o custo, e tem diferentes considerações para o seu processo de CI/CD. As secções seguintes fornecem mais detalhes sobre cada estratégia e as respetivas vantagens e desvantagens.
Além disso, quando ocorrem eventos que interrompem o serviço, podem afetar mais do que a implementação de CI/CD. Também deve considerar toda a infraestrutura de que precisa, incluindo a rede, o processamento e o armazenamento. Deve ter um plano de recuperação de desastres para esses elementos básicos e testá-lo regularmente para garantir que é eficaz.
Ativo/passivo
Com a estratégia ativa/passiva (ou standby a quente), as suas aplicações e o pipeline de CI/CD passivo são espelhos. No entanto, o pipeline passivo não está a processar a carga de trabalho do cliente nem qualquer compilação ou implementação, pelo que se encontra num estado reduzido. Esta estratégia é mais adequada para aplicações críticas para a empresa em que uma pequena quantidade de tempo de inatividade é tolerável.
O diagrama seguinte mostra uma configuração ativa/passiva para a aplicação Java de exemplo usada neste documento. O pipeline passivo duplica totalmente a cadeia de ferramentas de aplicações numa região diferente.
Neste exemplo, a região1 aloja o pipeline de CI/CD ativo e a região2 tem a contrapartida passiva. O código está alojado num fornecedor de serviços Git externo, como o GitHub ou o GitLab. Um evento de repositório (como uma união de um pedido de envio) pode acionar o pipeline de CI/CD na região 1 para criar, testar e implementar no ambiente de produção multirregional.
Se ocorrer um problema crítico para o pipeline da região 1, como uma indisponibilidade regional de um produto, o resultado pode ser implementações falhadas ou compilações sem êxito. Para recuperar rapidamente do problema, pode atualizar o acionador do repositório Git e mudar para o pipeline da região 2, que passa a ser o pipeline ativo. Depois de o problema ser resolvido na região 1, pode manter o pipeline na região 1 como passivo.
Seguem-se algumas vantagens da estratégia ativa/passiva:
- Tempo de inatividade reduzido: uma vez que o pipeline passivo foi implementado, mas está reduzido, o tempo de inatividade está limitado ao tempo necessário para aumentar a escala do pipeline.
- Tolerância configurável para perda de dados: com esta estratégia, a configuração e o artefacto têm de ser sincronizados periodicamente. No entanto, o valor é configurável com base nos seus requisitos, o que pode reduzir a complexidade.
As desvantagens desta estratégia incluem o seguinte:
- Custo: com a infraestrutura duplicada, esta estratégia aumenta o custo geral da sua infraestrutura de CI/CD.
Cópia de segurança/restauro
Com a estratégia de cópia de segurança/restauro, cria o pipeline de comutação por falha apenas quando necessário durante a recuperação de incidentes. Esta estratégia é mais adequada para exemplos de utilização de prioridade inferior. O diagrama seguinte mostra uma configuração de cópia de segurança/restauro para a aplicação Java de exemplo. A configuração da cópia de segurança duplica apenas parte do pipeline de CI/CD da aplicação numa região diferente.
Tal como no exemplo anterior, a região1 aloja o pipeline de CI/CD ativo. Em vez de ter um pipeline passivo na região 2, a região 2 só tem cópias de segurança dos dados regionais necessários, como os pacotes Maven e as imagens de contentores. Se alojar os repositórios de origem na região 1, também deve sincronizar os dados com as localizações de recuperação de desastres.
Da mesma forma, se ocorrer um problema crítico no pipeline da região 1, como uma indisponibilidade regional do produto, pode 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, pode executar o script de automatização a partir do repositório e reconstruir o pipeline de CI/CD na região 2.
Se a indisponibilidade for um evento de grande escala, pode competir com outros clientes por recursos na nuvem. Uma forma de mitigar esta situação é ter várias opções para a localização de recuperação de desastres. Por exemplo, se o pipeline region1 estiver em us-east1, a região de alternativa pode ser us-east4, us-central1 ou us-west1.
Seguem-se algumas vantagens da estratégia de cópia de segurança/restauro:
- Custo: esta estratégia incorre no custo mais baixo porque está a implementar o pipeline de cópia de segurança apenas durante cenários de recuperação de desastres.
As desvantagens desta estratégia incluem o seguinte:
- Tempo de inatividade: esta estratégia demora mais tempo a implementar porque cria o pipeline de comutação por falha quando precisa. Em vez de ter um pipeline pré-criado, os serviços têm de ser criados e configurados durante a recuperação de incidentes. O tempo de compilação dos artefactos e o tempo de obtenção de dependências externas também podem ser significativamente mais longos.
Documente o seu PCN e implemente práticas recomendadas
Depois de mapear a cadeia de ferramentas de CI/CD, identificar as respetivas dependências e determinar os objetivos de RTO e RPO para as funções críticas, o passo seguinte é documentar todas as informações relevantes num BCP escrito. Quando criar o seu PCN, documente as estratégias, os processos e os procedimentos para restaurar cada função crítica. Este processo de documentação inclui a escrita de procedimentos passo a passo para os funcionários em funções específicas seguirem durante uma interrupção.
Depois de definir o seu PCP, implemente ou atualize a cadeia de ferramentas de CI/CD através de práticas recomendadas para alcançar os seus alvos de RTO e RPO. Embora as cadeias de ferramentas de CI/CD possam ser muito diferentes, existem dois padrões principais de práticas recomendadas comuns, independentemente da cadeia de ferramentas: uma compreensão abrangente das dependências e a implementação da automatização.
No que diz respeito às dependências, a maioria dos PCNs aborda os sistemas diretamente no seu controlo. No entanto, lembre-se de que as dependências externas de segunda ou terceira ordem podem ter o mesmo impacto, pelo que é importante implementar práticas recomendadas e medidas de redundância também para essas dependências críticas. As bibliotecas Java externas na aplicação de exemplo são um exemplo de dependências de terceira ordem. Se não tiver um repositório local ou uma cópia de segurança dessas bibliotecas, pode não conseguir criar a sua aplicação se a fonte externa de onde extrai as bibliotecas estiver desligada.
Em termos de automatização, a implementação de práticas recomendadas deve ser incorporada na sua estratégia de IaC na nuvem geral. A sua solução de IaC deve usar ferramentas como o Terraform para aprovisionar automaticamente os recursos necessários da sua implementação de CI/CD e para configurar os processos. As práticas de IaC são procedimentos de recuperação altamente eficazes porque estão incorporadas no funcionamento diário dos seus pipelines de CI/CD. Além disso, a IaC promove o armazenamento dos seus ficheiros de configuração no controlo de origem, o que, por sua vez, promove a adoção das práticas recomendadas para cópias de segurança.
Depois de implementar a sua cadeia de ferramentas de acordo com o seu PCN e as práticas recomendadas para dependências e automatização, o seu processo de CI/CD e as estratégias de recuperação podem mudar. Certifique-se de que documenta todas as alterações às estratégias, aos processos e aos procedimentos de recuperação resultantes da revisão do PCN e da implementação das práticas recomendadas.
Teste cenários de falha e mantenha o plano
É fundamental rever, testar e atualizar regularmente o seu PCN de forma contínua. Testar os procedimentos de recuperação e de BCP verifica se o plano ainda é válido e se os alvos de RPO e RTO documentados são aceitáveis. No entanto, o mais importante é que os testes, as atualizações e a manutenção regulares fazem com que a BCP seja executada como parte das operações normais. Com o Google Cloud, pode testar cenários de recuperação a um custo mínimo. Recomendamos que faça o seguinte para ajudar nos testes:
- Automatize o aprovisionamento da infraestrutura com uma ferramenta de IaC: pode usar ferramentas como o Terraform para automatizar o aprovisionamento da infraestrutura de CI/CD.
- Monitorize e depure os seus testes com o Cloud Logging e o Cloud Monitoring: o Google Cloud Observability fornece ferramentas de registo e monitorização às quais pode aceder através de chamadas de API, o que significa que pode automatizar a implementação de cenários de recuperação reagindo às métricas. Quando conceber testes, certifique-se de que tem uma monitorização e alertas adequados que podem acionar ações de recuperação adequadas.
- Realize os testes no seu PCP: por exemplo, pode testar se as autorizações e o acesso do utilizador funcionam no ambiente de recuperação de desastres (RD) como no ambiente de produção. Pode realizar testes de integração e funcionais no seu ambiente de recuperação de desastres. Também pode fazer um teste em que o seu caminho de acesso habitual para Google Cloud não funciona.
Na Google, testamos regularmente o nosso PCO através de um processo denominado DiRT (testes de recuperação de desastres). Este teste ajuda a Google a verificar os impactos, a automatização e a expor riscos não contabilizados. As alterações à automatização e ao BCP que têm de ser implementadas são um resultado importante do DiRT.
Práticas recomendadas
Nesta secção, vai conhecer algumas práticas recomendadas que pode implementar para alcançar os seus objetivos de RTO e RPO. Estas práticas recomendadas aplicam-se de forma geral à DR para CI/CD e não a ferramentas específicas. Independentemente da sua implementação, deve testar o seu PCP regularmente para garantir que a elevada disponibilidade, o RTO e o RPO cumprem os seus requisitos. Se ocorrer um incidente ou um desastre, também deve fazer uma análise retrospetiva e analisar o seu processo para o poder melhorar.
Alta disponibilidade
Para cada ferramenta, deve trabalhar para implementar práticas recomendadas para a alta disponibilidade. Seguir as práticas recomendadas para a elevada disponibilidade coloca o seu processo de CI/CD numa posição mais proativa, porque estas práticas tornam o processo de CI/CD mais resiliente a falhas. Estas estratégias proativas devem ser usadas com controlos e procedimentos mais reativos para a recuperação e a cópia de segurança.
Seguem-se algumas práticas recomendadas para alcançar uma elevada disponibilidade. No entanto, consulte a documentação detalhada de cada ferramenta na sua CI/CD para ver práticas recomendadas mais detalhadas:
- Serviços geridos: a utilização de serviços geridos transfere a responsabilidade operacional para a Google Cloud.
- Escala automática: sempre que possível, use a escala automática. Um aspeto fundamental do ajuste de escala automático é que as instâncias de trabalho são criadas dinamicamente, pelo que a recuperação de nós com falhas é automática.
- Implementações globais e multirregionais: sempre que possível, use implementações globais e multirregionais em vez de implementações regionais. Por exemplo, pode configurar o Artifact Registry para armazenamento multirregional.
- Dependências: compreenda todas as dependências das suas ferramentas e certifique-se de que essas dependências estão altamente disponíveis. Por exemplo, pode colocar em cache todas as bibliotecas de terceiros no seu registo de artefactos.
Procedimentos de cópia de segurança
Quando implementa a RD para CI/CD, algumas ferramentas e processos são mais adequados para estratégias de cópia de segurança/restauro. Uma estratégia de cópia de segurança abrangente é o primeiro passo para controlos reativos eficazes. As cópias de segurança permitem-lhe recuperar o pipeline de CI/CD com uma interrupção mínima em caso de intervenientes prejudiciais ou cenários de desastre.
Como ponto de partida, deve implementar as três práticas recomendadas seguintes. No entanto, para ver práticas recomendadas de cópia de segurança mais detalhadas, consulte a documentação de cada ferramenta no seu processo de CI/CD.
- Controlo de origem: armazene ficheiros de configuração e tudo o que codificar, como scripts de automatização e políticas, no controlo de origem. Os exemplos incluem ficheiros YAML do Kubernetes e
cloudbuild.yaml. - Redundância: certifique-se de que não existe um único ponto de falha relativamente ao acesso a segredos, como palavras-passe, certificados e chaves de API. Alguns exemplos de práticas a evitar incluem apenas uma pessoa saber a palavra-passe ou armazenar a chave da API apenas num único servidor numa região específica.
- Cópias de segurança: verifique frequentemente a integridade e a precisão das suas cópias de segurança. Os serviços geridos, como a cópia de segurança do GKE, ajudam a simplificar o processo de validação.
Procedimentos de recuperação
A DR também requer procedimentos de recuperação para complementar os processos de cópia de segurança. Os seus procedimentos de recuperação, combinados com cópias de segurança completas, determinam a rapidez com que consegue responder a cenários de desastre.
Gestão de dependências
O pipeline de CI/CD pode ter muitas dependências, que também podem ser origens de falhas. Deve identificar uma lista completa das dependências, conforme descrito anteriormente neste documento, em Identifique dados e dependências. No entanto, as duas origens de dependências mais comuns são as seguintes:
- Artefactos da aplicação: por exemplo, pacotes, bibliotecas e imagens
- Sistemas externos: por exemplo, sistemas de notificações e emissão de bilhetes
Uma forma de mitigar os riscos das dependências é adotar a prática de fornecimento. A venda de pacotes de aplicações ou imagens é o processo de criação e armazenamento de cópias dos mesmos num repositório privado. A externalização remove a dependência de fontes externas para estes pacotes ou imagens e também pode ajudar a evitar a inserção de software malicioso na cadeia de abastecimento de software.
Algumas das vantagens de fornecer pacotes de aplicações ou imagens incluem o seguinte:
- Segurança: a terceirização remove a dependência de fontes externas para pacotes de aplicações ou imagens, o que pode ajudar a evitar ataques de inserção de software malicioso.
- Controlo: ao fornecer os seus próprios pacotes ou imagens, as organizações podem ter mais controlo sobre a origem destes pacotes e imagens.
- Conformidade: a gestão de fornecedores pode ajudar as organizações a agir em conformidade com os regulamentos da indústria, como a certificação do modelo de maturidade em cibersegurança.
Se a sua equipa decidir fornecer pacotes de aplicações ou imagens, siga estes passos principais:
- Identifique os pacotes de aplicações ou as imagens que têm de ser fornecidos.
- Crie um repositório privado para armazenar os pacotes ou as imagens de fornecedores.
- Transfira os pacotes ou as imagens da origem original e armazene-os no repositório privado.
- Verifique a integridade dos pacotes ou das imagens.
- Atualize os pacotes ou as imagens de fornecedores conforme necessário.
As pipelines de CI/CD chamam frequentemente sistemas externos para realizar ações como executar análises, registar pedidos ou enviar notificações. Na maioria dos casos, estes sistemas de terceiros têm as suas próprias estratégias de recuperação de desastres que devem ser implementadas. No entanto, em alguns casos, podem não ter um plano de recuperação de desastres adequado e essas instâncias devem ser claramente documentadas no PCP. Em seguida, tem de decidir se essas fases no pipeline podem ser ignoradas por motivos de disponibilidade ou se é aceitável causar tempo de inatividade para o pipeline de CI/CD.
Monitorização e notificações
O CI/CD é igual aos sistemas de produção da sua aplicação, pelo que também tem de implementar técnicas de monitorização e notificação para as suas ferramentas de CI/CD. Como prática recomendada, sugerimos que implemente painéis de controlo e notificações de alerta. O repositório de exemplo do GitHub para o Cloud Monitoring tem muitos exemplos de painéis de controlo e políticas de alerta.
Também pode implementar níveis adicionais de monitorização, como indicadores do nível de serviço (INSs) e objetivos ao nível do serviço (SLOs). Estes níveis de monitorização ajudam a acompanhar o estado geral e o desempenho das suas pipelines de CI/CD. Por exemplo, os SLOs podem ser implementados para acompanhar a latência das fases de compilação e implementação. Estes SLOs ajudam as equipas a criar e lançar aplicações à taxa e frequência desejadas.
Procedimentos de acesso de emergência
Durante um desastre, pode ser necessário que as equipas de operações tomem medidas fora dos procedimentos padrão e obtenham acesso de emergência a sistemas e ferramentas. Por vezes, estas ações de emergência são denominadas procedimentos de emergência. Como ponto de partida, deve implementar estas três práticas recomendadas:
- Ter um plano e um procedimento de encaminhamento claros. Um plano claro ajuda a equipa de operações a saber quando tem de usar os procedimentos de acesso de emergência.
- Certifique-se de que várias pessoas têm acesso a informações críticas, como a configuração e os segredos.
- Desenvolva métodos de auditoria automatizados para poder acompanhar quando foram usados os procedimentos de acesso de emergência e quem os usou.
O que se segue?
- Saiba mais sobre os Google Cloud produtos usados neste documento:
- Consulte o Guia de planeamento de recuperação de desastres.
- Experimente outras Google Cloud funcionalidades concluindo os nossos tutoriais.
- Para ver mais arquiteturas de referência, diagramas e práticas recomendadas, explore o Centro de arquitetura na nuvem.
Colaboradores
Autores:
- Ben Good | Solutions Architect
- Xiang Shen | Solutions Architect
Outros colaboradores:
- Marco Ferrari | Arquiteto de soluções na nuvem
- Anuradha Bajpai | Solutions Architect
- Rodd Zurcher | Solutions Architect