Excelência operacional

Nesta seção do framework de arquitetura, veremos como a excelência operacional resulta da eficiência dos sistemas de execução, gerenciamento e monitoramento que agregam valor comercial.

O framework é composto pela seguinte série de artigos:

• Visão geral
• Considerações sobre o design do sistema do Google Cloud
• Excelência operacional (este artigo)
• Segurança, privacidade e conformidade
• Confiabilidade
• Otimização de desempenho e custo

A qualidade operacional cria uma base para outro princípio importante, a confiabilidade. Consulte a seção Confiança para ver os requisitos técnicos e processuais relacionados à arquitetura e à operação de serviços confiáveis no Google Cloud.

Estratégias

Use estas estratégias para alcançar a eficiência operacional.

Automatizar a criação, os testes e a implantação. Use pipelines de integração e implantação contínuas (CI/CD) para criar testes automatizados nos lançamentos. Realize testes e implantação de integração automatizados.

Monitorar as métricas de objetivos de negócios. Defina, avalie e alerte sobre métricas comerciais relevantes.

Realizar testes de recuperação de desastres. Não espere por um desastre. Em vez disso, verifique periodicamente se os procedimentos de recuperação de desastres funcionam e teste-os regularmente.

Práticas recomendadas

Siga estas práticas para alcançar a excelência operacional.

• Aumentar a velocidade do desenvolvimento e lançamento de software.
• Monitorar a integridade do sistema e do negócio.
• Planejar e projetar para falhas.

Nas seções a seguir, abordamos as práticas recomendadas com detalhes.

Aumentar a velocidade de desenvolvimento e lançamento

Use uma abordagem de CI/CD para aumentar a velocidade. Primeiro, você torna sua equipe de desenvolvimento de software mais produtiva e automatiza os testes de integração no processo de criação. Você automatiza a implantação depois que o build atende aos critérios de teste específicos. Seus desenvolvedores podem fazer alterações menores e mais frequentes. As alterações são testadas exaustivamente, e o tempo para implantá-las é reduzido.

Nesta seção, descrevemos os elementos de uma abordagem de CI/CD: engenharia de versões, automação, repositórios de código central, pipelines de compilação, testes e implantação.

Engenharia de versões

A engenharia de versões é uma função de trabalho que supervisiona como o software é criado e entregue. A engenharia de versões é guiada por quatro práticas:

• Modo de autoatendimento. Estabeleça diretrizes para ajudar os engenheiros de software a evitar erros comuns. Aplicado por processos automatizados.
• Lançamentos frequentes. A alta velocidade soluciona problemas e facilita a correção de problemas. Os lançamentos frequentes dependem de testes de unidade automatizados.
• Builds herméticos. Use ferramentas de compilação para garantir a consistência. Controle as versões de compiladores de build para criar versões atuais e compará-las com as de um mês atrás.
• Aplicação da política. Todas as alterações precisam de revisão de código. O ideal é que incluam um conjunto de diretrizes e políticas para reforçar a segurança. Isso melhora a revisão de código, a solução de problemas e o teste de lançamentos.

Automação

Automatize o pipeline de compilação e lançamento para verificar problemas conhecidos e realizar testes rápidos. Também é possível usar a automação para eliminar tarefas repetitivas.

Repositórios de código central

Armazene seu código em um repositório central, com controle de versão e rotulado (por exemplo, test, dev, prod) conforme necessário. Essas etapas garantem que o pipeline de compilação produza resultados consistentes. No Google Cloud, é possível armazenar o código na versão do Cloud Source Repositories e integrá-lo a vários produtos.

Criar pipelines

Controle a versão da configuração de compilação para garantir que todos os builds sejam consistentes e para que você possa reverter para a última configuração mais conhecida, se necessário. No Google Cloud, o Cloud Build define dependências e versões para criar um pacote de aplicativos. Use o Cloud Functions para acionar um processo de compilação periodicamente ou acionar builds em eventos específicos quando o novo código for verificado. Também é possível usar o Cloud Functions para acionar testes e automatizar todo o pipeline.

Testes

Os testes são essenciais em um lançamento bem-sucedido. Exemplos de teste incluem:

• Testes de unidade. Eles são rápidos e realizam implantações com eficiência.
• Testes de integração. Esses testes podem ficar complexos quando você testa a integração com serviços interconectados.
• Testes do sistema. Eles são demorados e complexos, mas identificam casos extremos e corrigir problemas antes da implantação.

É possível realizar outros testes, incluindo testes estáticos, de carga, de segurança e assim por diante, antes de implantar o aplicativo na produção. Depois de automatizar os testes, atualize e adicione novos testes para melhorar e manter a integridade operacional da implantação.

Implantação

Escolha como seu aplicativo será lançado. Recomendamos fazer testes canário e observar se há erros no sistema, o que será mais fácil se você tiver um sistema robusto de monitoramento e alerta. No Google Cloud, é possível usar grupos de instâncias gerenciadas (MIGs, na sigla em inglês) para realizar testes A/B ou canário, bem como realizar um lançamento lento ou uma reversão, se necessário.

Perguntas sobre design

• Como sua equipe de desenvolvimento gerencia o build e o lançamento?
• Quais testes de integração e segurança sua equipe de desenvolvimento utiliza?
• Como fazer a reversão?

Recomendações

• Torne o pipeline de CI/CD a única maneira de implantar na produção.
• Isole e proteja seu ambiente de CI/CD.
• Crie apenas uma vez e promova o resultado por meio do pipeline.
• Mantenha seus pipelines de CI/CD rápidos.
• Minimize a ramificação do sistema de controle de versões.

Principais serviços

O Cloud Source Repositories é um serviço de repositório particular do Git com todos os recursos hospedado no Google Cloud. É possível usar o Cloud Source Repositories para o desenvolvimento colaborativo de qualquer aplicativo ou serviço.

O Container Registry é uma central com controle de acesso avançado para sua equipe gerenciar imagens do Docker, realizar análises de vulnerabilidade e definir as permissões de acesso. Com as integrações de CI/CD, é possível configurar pipelines do Docker totalmente automatizados para ter feedback rápido.

O Cloud Build é um serviço que executa seus builds na infraestrutura do Google Cloud. O Cloud Build pode importar o código-fonte do GitHub, do Bitbucket, do Cloud Storage ou do Cloud Source Repositories, executar um build de acordo com suas especificações e produzir artefatos como contêineres do Docker ou arquivos Java.

Monitorar a integridade do sistema e da empresa

O projeto de recursos e avaliação do DevOps (DORA, na sigla em inglês) define o monitoramento da seguinte maneira:

Monitoramento é o processo de coleta, análise e uso de informações para acompanhar aplicativos e infraestrutura, permitindo orientar as decisões de negócios. O monitoramento é um recurso importante, porque fornece informações sobre seus sistemas e trabalho.

O monitoramento pode ser usado para tomar decisões sobre o impacto das alterações no serviço, aplicar o método científico à resposta a incidentes e avaliar o alinhamento do serviço com as metas da sua empresa. Com o monitoramento, é possível:

• analisar tendências de longo prazo;
• comparar experiências ao longo do tempo;
• definir alertas sobre métricas importantes;
• criar painéis relevantes em tempo real;
• realizar análises retroativas;

monitorar métricas de negócios e de integridade do sistema. As métricas de negócios ajudam a entender o suporte que os sistemas oferecem ao seu negócio. Por exemplo, é possível monitorar o custo para atender um usuário em um aplicativo, a mudança no volume de tráfego para seu site após uma reformulação ou quanto tempo um cliente leva para comprar um produto no site. As métricas de integridade do sistema ajudam a entender se os sistemas estão funcionando corretamente e dentro de níveis de desempenho aceitáveis.

Use os quatro sinais de ouro a seguir para monitorar seu sistema:

• Latência. O tempo necessário para atender uma solicitação.
• Tráfego. Quanto está sendo demandado do seu sistema.
• Erros. A taxa de solicitações que falham. As solicitações podem falhar explicitamente (por exemplo, HTTP 500s), implicitamente (por exemplo, uma resposta HTTP 200 bem-sucedida, mas com conteúdo errado) ou por política (por exemplo, se você se comprometeu com tempos de resposta de um segundo, qualquer solicitação que leva mais de um segundo é um erro).
• Saturação. Quanto seu serviço está cheio. Uma medida dos recursos mais restritos. Ou seja, em um sistema com restrição de memória, mostra a memória, mas em um sistema com E/S restrita, mostra a E/S.

Logging

Os serviços de geração de registros são essenciais para monitorar sistemas. Embora as métricas sejam a base de itens específicos para monitorar, os registros contêm informações valiosas necessárias para depuração, análise relacionada à segurança e requisitos de conformidade. O Google Cloud inclui o Cloud Logging, um serviço de geração de registros integrado que pode ser usado para armazenar, pesquisar, analisar, monitorar e alertar sobre dados de registro e eventos do Google Cloud. O Cloud Logging coleta registros dos serviços do Google Cloud automaticamente. Esses registros podem ser usados para criar métricas para monitoramento e exportações de registros para serviços externos, como Cloud Storage, BigQuery e Pub/Sub.

Métrica

Defina as métricas para avaliar o comportamento da implantação. Certifique-se de que suas definições de métrica sempre representem necessidades de negócios e considere promover ou combinar algumas métricas para formar indicadores de nível de serviço (SLIs). Para detalhes, consulte Confiabilidade.

Todos os níveis do serviço geram métricas, desde a infraestrutura e a rede até a lógica de negócios. Os exemplos incluem:

• solicitações por segundo, conforme medido pelo balanceador de carga;
• total de blocos de disco lidos por disco;
• pacotes enviados por uma determinada interface de rede;
• tamanho do heap de memória para um determinado processo;
• distribuição de latências de resposta;
• número de consultas inválidas rejeitadas por uma instância de banco de dados.

Monitoring

Monitorar um aplicativo complexo é um esforço de engenharia significativo por si só. O Google Cloud oferece o Cloud Monitoring, um serviço gerenciado que faz parte do pacote de operações do Google Cloud. É possível usar o Cloud Monitoring para monitorar os serviços e as métricas personalizadas do Google Cloud. Ele também fornece uma API para integração com ferramentas de monitoramento de terceiros.

O Cloud Monitoring agrega métricas, registros e eventos da infraestrutura, oferecendo aos desenvolvedores e operadores um conjunto avançado de sinais observáveis para acelerar a análise da causa raiz e reduzir o tempo médio de resolução (MTTR, na sigla em inglês). É possível definir alertas e métricas personalizadas que atendam aos objetivos de negócios e ajudem a agregar, visualizar e monitorar a integridade do sistema.

O Cloud Monitoring conta com painéis padrão para serviços de aplicativos de nuvem e de código aberto. Usando o modelo de métricas, é possível definir painéis personalizados com ferramentas avançadas de visualização e configurar gráficos no Metrics Explorer.

Painéis

Depois de fazer o monitoramento, crie painéis relevantes para você realizar ações. Seus painéis devem ser simples e fáceis de ler. Realize e visualize análises de curto prazo ou em tempo real e análises de longo prazo. Para detalhes, consulte Confiabilidade.

Alertas

Verifique se o sistema de alertas está mapeado diretamente para os quatro sinais de ouro do monitoramento do sistema, para que você possa comparar o desempenho ao longo do tempo para determinar a velocidade do recurso ou reverter as alterações.

Torne os alertas práticos. Ao enviar alertas, inclua uma descrição e forneça todas as informações necessárias para a pessoa que estiver a postos agir imediatamente. Não devem ser necessários mais do que alguns cliques e um pouco de navegação para entender como agir de acordo com os alertas.

Sempre tente reduzir o esforço, por exemplo, eliminando ou automatizando correções para erros que você vê com frequência. Permita que a pessoa que está a postos se concentre em tornar os componentes operacionais confiáveis. Para detalhes, consulte Confiabilidade.

Caminho de escalonamento

Um caminho de escalonamento bem definido é essencial para reduzir o esforço envolvido no suporte aos produtos do Google Cloud. Esse caminho inclui aprender a trabalhar com a equipe de suporte do Google, encontrar documentos de arquitetura otimizados para engenheiros de suporte, definir como se comunicar durante uma interrupção e configurar o monitoramento e a geração de registros para diagnosticar problemas.

Para começar a definir um caminho de escalonamento, verifique se os administradores de segurança, rede e sistema estão configurados corretamente para receber e-mails e alertas importantes do Google Cloud. Isso ajuda os administradores a tomar decisões coerentes e a possivelmente corrigir problemas com antecedência. Da mesma forma, verifique se os proprietários do projeto têm nomes de usuário roteáveis por e-mail para receber e-mails importantes.

Recomendações

• Escolha métricas relevantes que correspondam às necessidades do seu negócio.
• Use o Cloud Monitoring e implante agentes de monitoramento para métricas personalizadas, se necessário.
• Verifique se o Cloud Logging está configurado para todas as entradas de registro.
• Crie alertas bem definidos, como porcentagem de sucesso ou falha.
• Envie alertas com informações para tomar medidas.
• Considere comprar um pacote de suporte empresarial ou baseado em papéis.
• Ao trabalhar com o suporte do Cloud, defina um caminho de escalonamento e forneça indicadores úteis, como horário, produto e local.

Principais serviços

O Cloud Monitoring fornece coleta, agregação e painéis de métricas, além de um framework de alertas e verificações de endpoints para aplicativos da Web e outros serviços acessíveis pela Internet.

O Cloud Logging permite filtrar, pesquisar, visualizar e exportar da nuvem e dos serviços de aplicativos de código aberto para registros do BigQuery, do Cloud Storage ou do Pub/Sub. É possível definir métricas com base no conteúdo do registro incorporado em painéis e alertas.

O Cloud Debugger conecta os dados de produção do aplicativo ao código-fonte inspecionando o estado do aplicativo em qualquer local do código na produção sem interromper ou atrasar as solicitações do aplicativo.

O Error Reporting analisa e agrega os erros nos aplicativos de nuvem e notifica quando novos erros são detectados.

O Cloud Trace conta com amostragem de latência e geração de relatórios para o App Engine, inclusive estatísticas por URL e distribuições de latência.

O Cloud Profiler fornece a criação contínua de perfis do consumo de recursos nos aplicativos de produção para identificar e eliminar problemas de desempenho.

Recursos

Padrões de projeto para exportação de registros

Projetar para recuperação de desastres

Projetar seu sistema para prever e lidar com cenários de falha garante que, se houver uma catástrofe, o impacto nos sistemas será minimizado. Para antecipar falhas, verifique se você tem um plano de recuperação de desastres (DR) bem definido e testado regularmente para fazer backup e restaurar serviços e dados.

Casos de interrupção de serviço podem acontecer a qualquer momento. Sua rede pode ter uma interrupção, o envio mais recente do aplicativo pode apresentar um bug crítico ou pode ser necessário enfrentar um desastre natural. Quando as coisas dão errado, é importante ter um plano de recuperação de desastres robusto, direcionado e bem testado.

Planejamento

A DR é um subconjunto do planejamento de continuidade de negócios. O planejamento de recuperação de desastres começa com uma análise de impacto nos negócios, em que são definidas duas métricas principais:

• Um objetivo do tempo de recuperação (RTO, na sigla em inglês), que é o período máximo aceitável em que o aplicativo pode ficar off-line. Esse valor é normalmente definido como parte de um contrato maior de nível de serviço (SLA).

• Um objetivo do ponto de recuperação (RPO, na sigla em inglês), que é o período máximo aceitável em que os dados podem ser perdidos pelo aplicativo devido a um incidente grave. Essa métrica varia de acordo com a forma como os dados são usados. Por exemplo, os dados do usuário que são frequentemente modificados podem ter um RPO de apenas alguns minutos. Dados menos importantes e modificados com pouca frequência podem ter um RPO de várias horas. Nessa métrica, é descrito apenas o tempo. Não são abordadas perdas de quantidade ou qualidade dos dados.

Normalmente, quanto menores forem os valores de RTO e RPO (ou seja, quanto mais rápido o aplicativo precisar se recuperar de uma interrupção), mais custos serão necessários para a execução. O gráfico a seguir mostra a proporção de custo para RTO/RPO:

Como valores de RTO e RPO menores geralmente significam maior complexidade, a sobrecarga administrativa segue uma curva semelhante. Por exemplo, um aplicativo de alta disponibilidade (HA, na sigla em inglês) pode exigir que você gerencie a distribuição entre dois data centers fisicamente separados, a replicação e muito mais.

Os valores de RTO e RPO normalmente se acumulam em outra métrica: o objetivo de nível de serviço (SLO), que é um elemento importante e mensurável de um SLA.

• Um SLA é o acordo completo que especifica qual serviço deve ser provisionado, como é o suporte, os horários, os locais, os custos, o desempenho, as penalidades e as responsabilidades das partes envolvidas.
• Os SLOs são características específicas e mensuráveis do SLA, como disponibilidade, capacidade, frequência, tempo de resposta ou qualidade.

Um SLA pode conter muitos SLOs. RTOs e RPOs são mensuráveis e devem ser considerados como SLOs.

Requisitos de infraestrutura

Na recuperação de desastres, é uma prática recomendada considerar vários requisitos, incluindo:

• capacidade: aquisição de recursos suficientes para fazer o dimensionamento conforme necessário;
• segurança: segurança física para proteger os recursos;
• infraestrutura de rede: componentes de software, como firewalls e balanceadores de carga;
• suporte: disponibilização de técnicos capacitados para realizar manutenções e solucionar problemas;
• largura de banda: largura de banda adequada para carga de pico;
• instalações: infraestrutura física, incluindo equipamentos e energia.

Recuperação de desastres no Google Cloud

Em comparação com o atendimento local dos requisitos, o Google Cloud pode reduzir o custo de atender a RTOs e RPOs. O Google Cloud ignora a maioria ou todos os fatores complicadores relacionados a hardware físico, eliminando muitos custos de negócios. Além disso, o foco do Google Cloud na simplicidade administrativa foi planejado para reduzir os custos de gerenciamento de um aplicativo complexo.

O Google Cloud oferece vários recursos relevantes para o planejamento de recuperação de desastres:

Rede global. O Google tem uma das maiores e mais avançadas redes de computadores do mundo. A rede de backbone do Google utiliza uma rede avançada, definida por software, e conta com serviços de armazenamento em cache próximo dos usuários finais para oferecer desempenho rápido, consistente e escalonável.

Redundância. Vários pontos de presença (PoPs, na sigla em inglês) em todo o mundo garantem uma redundância forte. Seus dados são espelhados automaticamente em dispositivos de armazenamento em vários locais.

Escalonabilidade. O Google Cloud foi projetado para escalonar como outros produtos do Google, como a Pesquisa e o Gmail, mesmo diante de um grande pico de tráfego. Os serviços gerenciados, como o App Engine, os escalonadores automáticos do Compute Engine e o Datastore oferecem escalonamento automático que permite que o aplicativo possa aumentar e diminuir conforme necessário.

Segurança. O modelo de segurança do Google se baseia em mais de 15 anos de experiência, ajudando a manter os clientes seguros em aplicativos do Google, como o Gmail e o Google Workspace. Além disso, as equipes de engenharia de confiabilidade do site do Google garantem alta disponibilidade e impedem o abuso de recursos da plataforma.

Conformidade. O Google passa regularmente por auditorias independentes realizadas por terceiros para verificar se o Google Cloud está alinhado às normas e práticas recomendadas de segurança, privacidade e conformidade. O Google Cloud é compatível com a conformidade com certificações como ISO 27001, SOC 2/3 e PCI DSS 3.2.1.

Recomendações

• Defina seus objetivos de RTO e RPO.
• Projete seu plano de DR com base nas soluções de dados e aplicativos.
• Teste seu plano de recuperação de desastres manualmente pelo menos uma vez por ano.
• Considere implementar a injeção de falha controlada para detectar regressões antecipadamente.
• Aproveite a engenharia de caos para encontrar áreas de risco.

Principais serviços

O snapshot do disco permanente oferece backups incrementais ou snapshots de máquinas virtuais (VMs) do Compute Engine que podem ser copiadas entre regiões e usadas para recriar discos permanentes em caso de desastre.

A migração em tempo real mantém as instâncias de VM em execução mesmo quando ocorre um evento do sistema host, como uma atualização de software ou hardware.

O Cloud Storage é um armazenamento de objetos que fornece classes de armazenamento, como Nearline e Coldline, adequadas para casos de uso específicos, como backup.

O Cloud DNS oferece uma maneira programática de gerenciar entradas de DNS como parte de um processo de recuperação automatizado. A rede global de servidores de nomes Anycast do Google é usada pelo Cloud DNS para atender a zonas de DNS de locais redundantes do mundo todo, oferecendo alta disponibilidade e baixa latência aos usuários.

Recursos

• Guia de planejamento de recuperação de desastres | Arquiteturas
• Elementos fundamentais da recuperação de desastres | Arquiteturas
• Cenários de recuperação de desastres para dados | Arquiteturas
• Cenários de recuperação de desastres para aplicativos | Arquiteturas
• Projeto de infraestrutura para disponibilidade e resiliência (PDF)