Esta página aplica-se ao Apigee e ao Apigee Hybrid.
Veja a documentação do
Apigee Edge.
O Apigee é uma plataforma baseada na nuvem, de autosserviço e com vários inquilinos, que é executada numa configuração totalmente redundante (em direto/em direto) em vários centros de dados em várias regiões do mundo. O Apigee usa o Google Cloud para a respetiva plataforma baseada na nuvem. Como parte dos serviços que criamos no Google Cloud, usamos vários centros de dados em cada região e fornecemos tráfego em direto aos nossos clientes nestes vários centros de dados. Não temos um centro de dados "em direto" e um centro de dados "em espera" (ou "secundário" ou "de alternativa"). Temos dois (ou mais) centros de dados que prestam serviços de tráfego de clientes de forma constante e simultânea em cada região a nível global.
Plano de BCP/DR
O planeamento de continuidade do negócio e a recuperação de desastres (BCP/DR) do Apigee são um plano ao nível da plataforma e não contêm tarefas detalhadas para clientes individuais. Em vez disso, a plataforma está configurada para processar pedidos de dados de clientes, independentemente de interrupções e indisponibilidades. Os dados continuam a fluir mesmo que um centro de dados inteiro esteja offline. Se uma região inteira ficar offline, um cliente de região única pode sofrer uma interrupção dos serviços de processamento de APIs. Para os clientes que procuram serviços redundantes "na região", o Apigee está disponível a um nível globalmente redundante de centros de dados redundantes, onde o tráfego pode ser processado em várias regiões ou países. Deste modo, se uma região inteira ficar offline, os dados continuam a fluir.
Os serviços de apoio ao cliente de região única não são transferidos automaticamente para outra região devido a possíveis restrições geográficas no tratamento e acesso aos dados. Os serviços Apigee são alojados para clientes na região identificada pelo cliente. Uma vez que podem existir regulamentos específicos ou compromissos dos clientes com os respetivos utilizadores relativamente às localizações geográficas dos dados, os serviços não são movidos automaticamente para uma região alternativa, uma vez que tal poderia comprometer os compromissos da Google com os respetivos clientes ou os compromissos dos clientes da Google com os respetivos clientes.
A Google não partilha o plano de NCP/DR completo com nenhum cliente individual, uma vez que contém informações confidenciais internas e referências aos nossos clientes. A nossa política de privacidade impede a partilha do plano de continuidade de negócios/recuperação de desastres da plataforma com clientes individuais que possam expor potencialmente os nomes de outros clientes. Oferecemos o mesmo nível de privacidade a cada cliente.
Gestão de BCP/DR
Uma equipa de segurança de informações da Google é responsável pela supervisão do programa de resiliência empresarial, enquanto um comandante de incidentes rotativo é responsável pela gestão e resolução de todos os incidentes. O comandante de incidentes tem pessoal operacional e de engenharia disponível em qualquer altura, juntamente com manuais de procedimentos para todas as ações que possam ter de ser tomadas.
Testes de BCP/DR
A Google realiza processos operacionais que suportam os testes de BCP/DR da plataforma com uma cadência mais frequente do que os nossos testes de BCP/DR anuais completos. Todos os meses, fazemos variações de carga a partir do nosso ambiente em direto/em direto enquanto fazemos atualizações aos sistemas que executam o serviço. Este processo envolve a desativação de sistemas equivalentes a um centro de dados inteiro, enquanto a carga é processada pelo centro de dados par. Durante este processo, após a realização de atualizações, o primeiro centro de dados é reposto e os serviços são executados em direto/novamente em direto para verificar se foram introduzidos problemas. Em seguida, o centro de dados de pares é desativado para as mesmas atualizações e, depois, volta a ficar online. A Google usa ferramentas e técnicas para reduzir o tráfego e enviar uma pequena percentagem do tráfego para serviços atualizados recentemente para verificar se existem problemas ou erros antes de voltar ao processamento de carga total.
Este processo operacional consistente excede os "testes" de resiliência semestrais padrão da indústria do nosso serviço, tornando-o numa tarefa operacional que ocorre com mais frequência.
Além dos processos operacionais descritos acima, a Google também realiza exercícios de PCO/RDA, pelo menos, uma vez por ano, nos quais os membros das equipas de engenharia e operações testam um cenário de desastre real. Isto oferece formação e experiência adicionais ao nosso pessoal nos nossos planos de BCP/DR mais amplos para a empresa como um todo, além do próprio serviço.
Os testes de BCP/DR realizados pela Google não usam "exercícios de comutação por falha" nem "localizações secundárias" porque tudo isso está integrado no sistema em execução.
A Google mantém manuais de procedimentos para utilização por todas as equipas operacionais e de engenharia. Estes guias interativos são revistos e atualizados, pelo menos, anualmente, e usados em todos os nossos testes de BCP/DR e exercícios de formação.
Os relatórios anuais de testes de BCP/DR estão disponíveis para os clientes. Também partilhamos os resultados das nossas tarefas operacionais e relatórios de testes de exercícios de DR anuais com os nossos auditores externos, e estes formam a base para a revisão do auditor da nossa conformidade com a PCI, a HIPAA, a ISO, os requisitos contratuais e outros.
Testes de BCP/DR de clientes
Recomendamos que os clientes incorporem os serviços Apigee nos seus próprios planos de recuperação de desastres. Os clientes podem e devem considerar como o Apigee pode redirecionar o tráfego conforme necessário para que os clientes mantenham os serviços de utilizador final, mesmo durante uma indisponibilidade do centro de dados do cliente ou outro evento de desastre. No entanto, este nível de testes está fora do âmbito do plano de DR do Apigee. Incentivamos os clientes a realizar testes de BCP/DR nas suas próprias aplicações e a incluir o Apigee no teste.
RTO/RPO
O Apigee não oferece objetivos de ponto de recuperação e tempo de recuperação (RPO/RTO) para clientes nem em contratos relacionados com atividades de BCP/DR. Os SLAs são o equivalente na nuvem dos pontos de dados RTO/RPO. Uma vez que o Apigee é um serviço baseado na nuvem redundante com serviços de gestão e de tempo de execução arquitetados com serviços ativos redundantes, o RTO e o RPO podem ser vistos como "em tempo real". Os clientes de uma única região recebem um mínimo de serviços redundantes em diferentes centros de dados na mesma região. Os clientes que pretendam níveis mais elevados de redundância podem optar por serviços multirregionais.
Plano de pandemia
A Google inclui um plano de pandemia como parte do plano e dos processos gerais de BCP/DR. Para operações empresariais, como o apoio técnico, a Google opera uma equipa de apoio técnico global 24 horas por dia, 7 dias por semana em vários escritórios e localizações remotas. Se uma pandemia numa área do globo afetar um dos nossos locais de apoio técnico, o pessoal de outros escritórios é alertado e cobre os turnos normalmente processados pelo escritório afetado. Para outros serviços empresariais, como as vendas, a força de trabalho está distribuída a nível global. Todas as equipas da Google estão equipadas para trabalhar remotamente, se necessário. As ferramentas usadas são baseadas na nuvem e adequam-se naturalmente a um plano de resposta a uma pandemia.
Atualizações
A Google revê e atualiza o respetivo plano de CNE/REC, pelo menos, anualmente. As informações recolhidas a partir de incidentes, alterações de produtos, normas da indústria, atividades de análise de riscos e testes de BCP/DB são usadas para atualizar o plano.
Análise do impacto empresarial e avaliações de risco
A Google realiza uma análise de impacto empresarial e uma avaliação de riscos anualmente. Os resultados da BIA e da RA são prioritários e documentados no sistema de acompanhamento de problemas.