Esta página se aplica à Apigee e à Apigee híbrida.
Confira a documentação da Apigee Edge.
A Apigee é uma plataforma multilocatária, de autoatendimento e baseada em nuvem que é executada em uma configuração totalmente redundante (ativa/ao vivo) em vários data centers em várias regiões do mundo. A Apigee usa o Google Cloud como plataforma baseada em nuvem. Como parte dos serviços que criamos no Google Cloud, usamos vários data centers em cada região e atendemos o tráfego em tempo real para nossos clientes nesses vários data centers. Não temos um data center "ativo" e um data center "em espera" (ou "secundário" ou "failover"). Temos dois (ou mais) data centers que atendem constantemente e simultaneamente ao tráfego de clientes em cada região.
Plano BCP/DR
O planejamento de continuidade de negócios e recuperação de desastres (BCP/DR, na sigla em inglês) da Apigee é um plano de toda a plataforma e não contém tarefas detalhadas para clientes individuais. Em vez disso, a plataforma é configurada para processar solicitações de dados de clientes, independentemente de interrupções e interrupções. Os dados continuarão a fluir mesmo se um data center inteiro estiver off-line. Se uma região inteira ficar off-line, um cliente de região única poderá enfrentar uma interrupção dos serviços de processamento de API. Para clientes que procuram mais do que serviços redundantes "na região", a Apigee está disponível em um nível globalmente redundante de data centers redundantes em que o tráfego pode ser atendido em várias regiões ou países para que se uma região inteira precisar ficar off-line, os dados ainda seriam transmitidos.
Os serviços ao cliente de uma única região não são transferidos automaticamente para outra região devido a possíveis restrições geográficas no processamento e no acesso a dados. Os serviços da Apigee são hospedados para clientes na região identificada pelo cliente. Como pode haver regulamentos ou compromissos específicos do cliente em relação à localização geográfica dos dados, os serviços não serão migrados automaticamente para uma região alternativa, porque isso pode comprometer os compromissos do Google com isso. aos clientes.
O Google não compartilha o plano BCP/DR completo com nenhum cliente individual, porque ele contém informações confidenciais internas e referências aos nossos clientes. Nossa política de privacidade impede o compartilhamento do plano de BCP/DR da plataforma com clientes individuais que podem expor outros nomes de clientes. Oferecemos esse mesmo nível de privacidade a todos os clientes.
Gerenciamento de BCP/DR
Uma equipe de segurança de informações do Google é responsável pela supervisão do programa de resiliência de negócios, enquanto um comandante de incidentes rotativo é responsável pelo gerenciamento e resolução de todos os incidentes. O Commander Incident tem funcionários operacionais e de engenharia sempre à disposição, além de manuais para todas as ações que precisam ser realizadas.
Teste BCP/DR
O Google realiza processos operacionais compatíveis com testes de BCP/DR da plataforma em uma cadência mais frequente do que os testes anuais completos de BCP/DR. Todos os meses fazemos mudanças de carga no ambiente ativo/ao vivo enquanto realizamos atualizações nos sistemas que executam o serviço. Esse processo envolve a remoção de um sistema de data centers inteiro enquanto a carga é gerenciada pelo data center de peering. Durante esse processo, após a realização de qualquer atualização, o primeiro data center é recuperado e os serviços são executados ao vivo/novamente para verificar se não houve problemas. Depois, o data center de mesmo nível é reduzido para as mesmas atualizações e, em seguida, fica on-line novamente. O Google usa ferramentas e técnicas para drenar o tráfego e enviar uma pequena porcentagem dele aos serviços atualizados recentemente para verificar se há problemas ou erros antes de retornar ao processamento completo.
Esse processo operacional consistente excede o "teste" de resiliência semestral padrão do nosso serviço, tornando-o uma tarefa operacional que ocorre com mais frequência.
Além dos processos operacionais descritos acima, o Google também realiza exercícios de BCP/DR pelo menos uma vez por ano em que os membros das equipes de engenharia e operações testam um cenário de desastres real. Isso proporciona treinamento e experiência adicionais para nossa equipe nos nossos planos maiores de BCP/DR para a empresa como um todo, além do próprio serviço.
O teste BCP/DR feito pelo Google não usa "exercícios de failover" ou "locais secundários" porque tudo isso é incorporado ao sistema em execução.
O Google mantém os Playbooks para uso por todas as equipes operacionais e de engenharia. Esses manuais são revisados e atualizados pelo menos anualmente e usados em todos os nossos exercícios de treinamento e teste de BCP/DR.
Os relatórios anuais de teste BCP/DR estão disponíveis para os clientes. Também compartilhamos os resultados das nossas tarefas operacionais e dos relatórios anuais de testes de DR com nossos auditores terceirizados. Eles são a base para a análise do auditor sobre nossa conformidade requisitos do PCI, da HIPAA, de ISO, contratuais e outros.
Testes de BCP/DR do cliente
Os clientes são incentivados a ter os próprios planos de DR incorporando os serviços da Apigee. Os clientes podem e precisam considerar como a Apigee pode redirecionar o tráfego conforme necessário para que os clientes mantenham os serviços do usuário final, mesmo durante uma interrupção do data center do cliente ou outro evento de desastre. No entanto, esse nível de teste está fora do escopo do plano de DR da Apigee. Incentivamos os clientes a realizar testes BCP/DR nos próprios aplicativos e incluir a Apigee no teste.
RTO/RPO
A Apigee não oferece objetivos de ponto de recuperação e tempo de recuperação (RPO/RTO, na sigla em inglês) para clientes ou contratos relacionados a atividades de BCP/DR. Os SLAs são o equivalente na nuvem dos pontos de dados de RTO/RPO. Como a Apigee é um serviço redundante baseado em nuvem, os serviços de gerenciamento e de tempo de execução são projetados com serviços ativos redundantes, o RTO e o RPO podem ser vistos como "em tempo real". Clientes de região única recebem no mínimo serviços redundantes em data centers diferentes na mesma região. Os clientes que desejam níveis de redundância mais altos podem optar por serviços de várias regiões.
Plano de pandemia
O Google inclui um plano de pandemia como parte do plano e dos processos gerais de BCP/DR. Para operações comerciais, como suporte, o Google opera uma equipe de suporte global 24 horas por dia, 7 dias por semana, em vários escritórios e locais remotos. Se uma pandemia em uma área do mundo afetar um dos nossos locais de suporte, os funcionários de outros escritórios serão alertados e cobrirão as mudanças normalmente controladas pelo escritório afetado. Para outros serviços comerciais, como vendas, a força de trabalho é distribuída globalmente. Todas as equipes do Google podem trabalhar remotamente se necessário. As ferramentas usadas são baseadas na nuvem e se adaptam naturalmente a um plano de resposta à pandemia.
Atualizações
O Google revisa e atualiza nosso plano de BCP/DR pelo menos anualmente. Para atualizar o plano, usamos informações coletadas de incidentes, alterações de produtos, padrões do setor, atividades de análise de risco e testes BCP/DB.
Análise de impacto no negócio e avaliações de risco
O Google realiza uma análise de impacto nos negócios e uma avaliação de risco anualmente. Os resultados da BIA e da RA são priorizados e documentados no sistema de rastreamento de problemas.