Confiabilidade

Nesta seção do framework de arquitetura, descrevemos como aplicar requisitos técnicos e processuais para arquitetar e operar serviços confiáveis no Google Cloud.

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

A confiabilidade é o recurso mais importante de qualquer aplicativo, porque se o aplicativo não for confiável, os usuários o abandonarão e os outros recursos não serão importantes.

  • Um aplicativo precisa ter metas de confiabilidade mensuráveis, e os desvios precisam ser corrigidos imediatamente.
  • O aplicativo precisa ser arquitetado para escalonabilidade, alta disponibilidade e gerenciamento automatizado de mudanças.
  • O aplicativo precisa se corrigir automaticamente sempre que possível e ser instrumentado para observabilidade.
  • Os procedimentos operacionais usados para executar o aplicativo precisam impor o mínimo de trabalho manual e carga cognitiva nos operadores, garantindo a mitigação rápida de falhas.

Estratégias

Use estas estratégias para ter confiabilidade.

A confiabilidade é definida pelo usuário. Para cargas de trabalho voltadas ao usuário, avalie a experiência dele, por exemplo, a proporção de sucesso por consultas, em vez de apenas métricas do servidor, como o uso da CPU. Para cargas de trabalho em lote e streaming, talvez seja necessário medir KPIs (indicadores principais de desempenho), como linhas verificadas por janela de tempo, para garantir que um relatório trimestral esteja no caminho certo para terminar no prazo, em vez de apenas métricas do servidor, como o uso do disco.

É necessário ter confiabilidade suficiente. Seus sistemas devem ser confiáveis o suficiente para que os usuários fiquem satisfeitos, mas não excessivamente confiáveis de modo que o investimento não seja justificável. Defina os objetivos de nível de serviço (SLOs) que definem o limite de confiabilidade e use erros de orçamento para gerenciar a taxa de alteração. Aplique os outros princípios listados abaixo somente se o SLO justificar o custo.

Criar redundância. Sistemas com necessidades de alta confiabilidade não precisam ter pontos únicos de falha, e os recursos precisam ser replicados em vários domínios com falha. Um domínio de falha é um pool de recursos que podem falhar de forma independente, como uma VM, zona ou região.

Incluir escalonabilidade horizontal. Adicione mais recursos para garantir que cada componente do sistema possa acomodar o crescimento do tráfego ou dos dados.

Garantir a tolerância de sobrecarga. Projete serviços para que eles possam degradar suavemente dependendo da carga.

Incluir o recurso de reversão. Qualquer alteração feita por um operador em um serviço precisa ter um método bem definido para desfazê-la, ou seja, reverter a alteração.

Evitar picos de tráfego. Não sincronize solicitações entre clientes. Se muitos clientes enviarem tráfego ao mesmo tempo, haverá picos de tráfego que podem, no pior dos casos, causar falhas em cascata.

Testar a recuperação de falhas. Se você não testou recentemente seus procedimentos operacionais para se recuperar de falhas, os procedimentos provavelmente não funcionarão quando você precisar deles. Os itens a serem testados periodicamente incluem failover regional, reversão de um lançamento e restauração de dados de backups.

Detectar falhas. Há diferenças entre alertar muito cedo e esgotar a equipe de operações ou enviar alertas muito tarde e ter interrupções estendidas de serviço. O atraso antes de notificar operadores sobre interrupções (também conhecido como "tempo de detecção", ou TTD, na sigla em inglês) precisa ser ajustado.

Fazer alterações incrementais. Alterações globais instantâneas em binários de serviço ou configurações são arriscadas. Recomendamos que você implemente as alterações gradualmente, com o "teste canário", para detectar bugs nos estágios iniciais de um lançamento, em que o impacto sobre os usuários é mínimo.

Ter uma resposta de emergência coordenada. Projetar práticas operacionais para minimizar a duração das interrupções (também conhecidas como "tempo para mitigar", ou TTM, na sigla em inglês) considerando a experiência do cliente e o bem-estar dos operadores. Essa abordagem exige a formalização antecipada dos procedimentos de resposta com papéis e canais de comunicação bem definidos.

Instrumentar os sistemas para observabilidade. Os sistemas precisam ser suficientemente instrumentados para poder realizar triagens, resolver problemas e oferecer diagnósticos de problemas rapidamente para minimizar os TTMs.

Documentar e automatizar respostas de emergência. Em uma emergência, as pessoas costumam ter dificuldade para definir o que precisa ser feito e realizar tarefas complexas. Portanto, planeje ações de emergência previamente, documente-as e, de preferência, automatize-as.

Gerenciar capacidade. Preveja o tráfego e provisione recursos antecipadamente para atender eventos de pico de tráfego.

Reduzir o esforço. O esforço é um trabalho manual e repetitivo, sem valor duradouro, que aumenta conforme o serviço cresce. Tente reduzir ou eliminar o esforço sempre que puder. Caso contrário, o trabalho operacional acabará sobrecarregando os operadores, deixando pouco espaço para crescimento.

Práticas recomendadas

Siga estas práticas recomendadas para alcançar a confiabilidade.

  • Definir metas de confiabilidade usando objetivos de nível de serviço (SLOs) e erros de orçamento.
  • Incorporar a observação na infraestrutura e em aplicativos.
  • Projetar para escala e alta disponibilidade.
  • Criar recursos de implantação flexíveis e automatizados.
  • Criar alertas eficientes.
  • Criar um processo colaborativo para o gerenciamento de incidentes.

Definir metas de confiabilidade

Recomendamos que você avalie sua experiência atual do cliente, sua tolerância a erros e problemas para estabelecer metas de confiabilidade com base nesses eventos. Por exemplo, não é possível alcançar uma meta geral de tempo de atividade do sistema de 100% por um período infinito, e essa meta não será significativa se os dados que o cliente quiser não estiverem lá.

Definir SLOs com base na experiência do usuário. Avalie as métricas de confiabilidade da forma mais próxima possível do usuário. Se possível, instrumentalize o cliente móvel ou da Web. Se isso não for possível, instrumentalize o balanceador de carga. A medição da confiabilidade no servidor deve ser o último recurso. Defina um SLO alto o suficiente para que o usuário não fique insatisfeito, mas nada além disso.

Devido à conectividade de rede ou a outros problemas temporários do lado do cliente, seus clientes podem não perceber alguns problemas de confiabilidade causados pelo aplicativo por breves períodos.

Para o tempo de atividade e outras métricas vitais, recomendamos que você estabeleça uma meta inferior a 100%, mas próxima disso. Essa meta permite que qualquer pessoa forneça software de forma mais rápida e com alta qualidade. Também é verdade que, em muitos casos, com um sistema projetado adequadamente, é possível alcançar maior disponibilidade reduzindo o ritmo e o volume de alterações.

Em outras palavras, metas de confiabilidade alcançáveis ajustadas à experiência do cliente tendem a definir o ritmo e o escopo máximos das alterações (ou seja, a velocidade do recurso) que os clientes podem tolerar.

Se não for possível avaliar a experiência do cliente atual e definir metas relacionadas a ela, recomendamos realizar uma análise de comparativo de mercado. Na ausência de concorrência comparável, avalie a experiência do cliente, mesmo que ainda não seja possível definir metas. Por exemplo, a disponibilidade do sistema ou a taxa de transações significativas e bem-sucedidas para o cliente. É possível correlacionar isso com métricas de negócios ou KPIs, como volume de pedidos (varejo), volume de chamadas de suporte ao cliente, tíquetes e a gravidade deles etc. Depois de um tempo, será possível usar esses exercícios de correlação para chegar a um limite razoável de satisfação do cliente, ou seja, um SLO.

SLIs, SLOs e SLAs

Um indicador de nível de serviço (SLI) é uma medida quantitativa de algum aspecto do nível de serviço que está sendo prestado. Ele é uma métrica, não uma meta.

Os objetivos de nível de serviço (SLOs) especificam uma meta de confiabilidade do serviço. Como os SLOs são fundamentais para tomar decisões baseadas em dados de confiabilidade, eles são a base das práticas de SRE. O SLO é um valor para um SLI e, quando ele é igual ou superior a esse valor, o serviço é considerado "confiável o suficiente".

Os erros de orçamento são calculados como (100% - SLO) durante um período. Eles informam se o sistema é mais ou menos confiável do que o necessário em um determinado período. Geralmente, recomendamos usar uma janela contínua de 30 dias.

Os contratos de nível de serviço (SLAs) são um contrato explícito ou implícito com os usuários que incluem consequências do cumprimento (ou não) dos SLOs que eles contêm.

Recomenda-se ter SLOs internos mais rigorosos do que SLAs externos. A lógica dessa abordagem é que as violações do SLA tendem a exigir a emissão de um crédito ou reembolso financeiro do cliente, e é melhor resolver os problemas bem antes que eles tenham impacto financeiro. Recomendamos anexar SLOs internos mais rigorosos a um processo retrospectivo sem atribuição de culpa e com análises de incidentes.

Se o aplicativo tiver uma arquitetura multilocatária, típica de aplicativos SaaS usados por vários clientes independentes, capture SLIs no nível do locatário. Se você medir os SLIs somente no nível global agregado, o monitoramento não poderá sinalizar problemas críticos que afetam clientes individuais ou uma minoria de clientes. Projete o aplicativo para incluir um identificador de locatário em cada solicitação do usuário e propagar esse identificador em cada camada da pilha. A propagação desse identificador permite que o sistema de monitoramento agregue estatísticas no nível por locatário em cada camada ou microsserviço ao longo do caminho da solicitação.

Erros de orçamento

Use erros de orçamento para gerenciar a velocidade de desenvolvimento. Quando o erro de orçamento ainda não for consumido, continue lançando novos recursos rapidamente. Quando o erro de orçamento estiver próximo de zero, congele ou diminua a velocidade do serviço e invista os recursos de engenharia em aspectos de confiabilidade.

O Google Cloud minimiza o esforço de configurar SLOs e erros de orçamento com o monitoramento de serviços. Esse produto oferece uma IU para configurar SLOs manualmente, uma API de configuração programática de SLOs e painéis integrados para rastrear a taxa de gravação de erros de orçamento.

Exemplos de SLIs

Os SLIs a seguir são típicos para sistemas de veiculação:

  • A disponibilidade informa a fração do tempo em que um serviço pode ser usado. Ela geralmente é definida em termos da fração de solicitações bem formadas que são bem-sucedidas, por exemplo, 99%.
  • A latência informa a velocidade com que uma determinada porcentagem de solicitações pode ser atendida. Ela geralmente é definida em termos de uma percentil diferente do 50º, por exemplo, o 99º percentil a 300 ms.
  • A qualidade informa a qualidade de uma determinada resposta. A definição de qualidade geralmente é específica para o serviço, indicando o nível de diferença entre o conteúdo da resposta a uma solicitação e o conteúdo da resposta ideal. Ela pode ser binária (boa ou ruim) ou expressa em uma escala de 0% a 100%.

Os SLIs a seguir são típicos para sistemas de processamento de dados:

  • A cobertura informa a fração de dados processados, por exemplo, 99,9%.
  • A correção informa a fração de respostas consideradas corretas, por exemplo, 99,99%.
  • A atualização informa até que ponto os dados de origem ou as respostas agregadas estão atualizados. Quanto maior a frequência, melhor. Por exemplo, 20 minutos.
  • A capacidade informa a quantidade de dados que está sendo processada, por exemplo, 500 MiB/s ou até 1.000 RPS.

Os SLIs a seguir são comuns para sistemas de armazenamento:

  • A durabilidade informa a probabilidade de os dados gravados no sistema serem recuperados no futuro, por exemplo, 99,9999%. Qualquer incidente permanente de perda de dados reduz a métrica de durabilidade.
  • A capacidade e a latência (conforme descrito anteriormente).

Perguntas sobre design

  • Você está avaliando a experiência do usuário com base na confiabilidade do aplicativo?
  • Os aplicativos clientes são projetados para capturar e relatar métricas de confiabilidade?
  • A arquitetura do sistema foi projetada com base em metas específicas de confiabilidade e escalonabilidade?
  • Para sistemas multilocatários, as solicitações de usuários incluem um identificador de locatário, e esse identificador é propagado por cada camada da pilha de software?

Recomendações

  • Defina e avalie SLIs voltados ao cliente.
  • Defina um erro de orçamento centrado no cliente que seja mais rigoroso do que o SLA externo com consequências por violações, como o congelamento da produção.
  • Configure SLIs de latência para capturar valores atípicos, ou seja, o 90º ou o 99º percentil, para detectar as respostas mais lentas.
  • Analise os SLOs pelo menos uma vez por ano.

Recursos

Incorporar a observabilidade na infraestrutura e em aplicativos

A observabilidade inclui serviços de monitoramento, geração de registros, rastreamento, criação de perfil, depuração e semelhantes.

Instrumentalize seu código para maximizar a capacidade de observação. Grave entradas de registro e entradas de rastreamento e exporte métricas de monitoramento tendo em mente a depuração e a solução de problemas, priorizando os modos de falha mais prováveis ou frequentes do sistema. Audite e elimine periodicamente seu monitoramento, excluindo painéis, alertas, traces e registros não utilizados ou desnecessários para reduzir a confusão.

O monitoramento está na base da hierarquia de confiabilidade do serviço. Sem o monitoramento adequado, não é possível saber se um aplicativo está funcionando.

Um sistema bem projetado tem como objetivo ter a quantidade certa de observabilidade, começando pela fase de desenvolvimento. Não espere até que um aplicativo esteja em produção para começar a observá-lo.

O pacote de operações do Google Cloud oferece monitoramento em tempo real, geração de registros (Google Cloud e AWS), além de rastreamento, criação de perfil e depuração. Ele também é capaz de monitorar uma malha de serviços usando o Istio e serviços do App Engine (Cloud Monitoring).

Alguns antipadrões comuns são a engenharia de monitoramento e alertas em excesso. Para evitar esses antipadrões, exclua proativamente séries temporais, painéis e alertas que não são consultados ou são raramente acionados durante os estágios iniciais de lançamento externo. Isso também é válido para entradas de registro verificadas raramente.

Considere enviar todos ou uma amostra de eventos de aplicativos para um armazenamento de dados na nuvem, como o BigQuery. Isso é útil porque permite executar consultas arbitrárias a um custo menor em vez de projetar seu monitoramento imediatamente. Assim, você também separa os relatórios do monitoramento. Os relatórios podem ser gerados por qualquer pessoa que use o Google Data Studio ou o Looker.

Perguntas sobre design

  • O processo de análise do design tem padrões de observabilidade que orientam as análises de design e de código?
  • As métricas são exportadas pelo aplicativo adequado para solucionar falhas na solução de problemas?
  • As entradas de registro do aplicativo são detalhadas e relevantes o suficiente para serem úteis na depuração?

Recomendações

  • Implemente o monitoramento antes de iniciar uma migração ou ao criar um novo aplicativo, antes da primeira implantação de produção.
  • Elimine a ambiguidade entre problemas de aplicativos e problemas de nuvem. Por exemplo, use o SLI transparente e o painel de status do Google Cloud.
  • Defina uma estratégia de observabilidade que vá além da criação de perfil e que inclua rastreamento, criação de perfil e depuração.
  • Limpe regularmente os artefatos de observabilidade que não estão sendo usados ou que não são úteis, incluindo alertas não acionáveis.
  • Envie eventos de aplicativos (ou seja, métricas de alta cardinalidade) para um sistema de armazenamento de dados, como o BigQuery.

Projetar para escala e alta disponibilidade

Projetar uma arquitetura multirregional com failover

Se o serviço precisa estar ativo mesmo quando uma região inteira está inativa, projete-o para usar pools de recursos de computação espalhados por diferentes regiões, com failover automático quando uma região ficar inativa. Elimine pontos únicos de falha, como um banco de dados mestre de região única que possa causar uma interrupção global quando estiver inacessível.

Eliminar gargalos de escalonabilidade

Identifique os componentes do sistema que não podem crescer além dos limites de recursos de uma única VM ou zona. Alguns aplicativos são projetados para escalonamento vertical, em que mais núcleos de CPU, memória ou largura de banda de rede são necessários em uma única VM para lidar com o aumento da carga. Esses aplicativos têm limites absolutos de escalonabilidade e geralmente exigem reconfiguração manual para lidar com o crescimento. Reformule esses componentes para serem escalonáveis horizontalmente usando fragmentação (particionamento entre VMs ou zonas), de modo que o crescimento no tráfego ou no uso possa ser tratado facilmente adicionando mais fragmentos e os fragmentos usem tipos de VM padrão que podem ser adicionados automaticamente para lidar com aumentos na carga por fragmento. Em vez de projetar novamente, considere substituir esses componentes por serviços gerenciados projetados para escalonamento horizontal sem ação do usuário.

Degradação suave de serviços

Projete seus serviços para detectar sobrecarga e retornar respostas de baixa qualidade para o usuário ou eliminar parcialmente o tráfego em vez de falhar completamente nesse contexto. Por exemplo, um serviço pode responder a solicitações de usuários com páginas da Web estáticas enquanto desativa temporariamente um comportamento dinâmico mais caro ou pode permitir operações somente leitura enquanto desativa temporariamente as atualizações de dados.

Implementar espera exponencial com instabilidade

Quando os clientes de dispositivos móveis encontram uma resposta de erro no serviço, eles precisam tentar novamente após um atraso aleatório. Se eles recebem erros repetidos, devem esperar por um tempo exponencialmente maior antes de tentar novamente, além de adicionar compensações de tempo aleatórias (instabilidade) a cada operação de repetição. Isso impede que grupos grandes de clientes gerem picos de tráfego instantâneos após falhas na rede celular, porque esses picos podem travar os servidores.

Prever eventos de pico de tráfego e planejá-los

Se o sistema passar por períodos de pico conhecidos, como a Black Friday para varejistas, invista tempo na preparação desses eventos para evitar perda significativa de tráfego e receita. Preveja o tamanho do pico de tráfego, adicione um buffer e confirme se o sistema tem capacidade de computação suficiente para lidar com o pico. Teste a carga do sistema com a combinação esperada de solicitações de usuários para garantir que a capacidade estimada de processamento de carga corresponda à real. Realize exercícios em que sua equipe de operações conduza simulações de interrupções. Ensine os procedimentos de resposta e de gerenciamento de incidentes entre equipes discutidos abaixo.

Realizar testes de recuperação de desastres

Não espere por um desastre. Teste e verifique periodicamente seus procedimentos e processos de recuperação de desastres. Talvez você esteja planejando uma arquitetura para alta disponibilidade (HA, na sigla em inglês). Ela não se sobrepõe totalmente à recuperação de desastres, mas geralmente é necessário considerar a alta disponibilidade quando você está pensando nos valores do objetivo de tempo de recuperação (RTO, na sigla em inglês) e do objetivo de ponto de recuperação (RPO, na sigla em inglês). A alta disponibilidade garante um nível acordado de desempenho operacional, geralmente com base no tempo de atividade, por um período maior que o normal. Ao executar cargas de trabalho de produção no Google Cloud, é possível usar um sistema distribuído globalmente para que, caso algo dê errado em uma região, o aplicativo continue a fornecer serviços, mesmo que não esteja tão disponível. Basicamente, esse aplicativo invoca o próprio plano de recuperação de desastres.

Perguntas sobre design

  • O aplicativo pode ser escalonado adicionando mais VMs, sem mudanças na arquitetura?
  • Cada componente da arquitetura é escalonável horizontalmente, por meio de fragmentação ou de outra forma?
  • Os aplicativos clientes foram projetados para evitar a sincronização de solicitações entre clientes?
  • O aplicativo pode processar falhas de uma região inteira da nuvem sem causar uma interrupção global?
  • As solicitações de usuários são distribuídas uniformemente entre fragmentos e regiões?
  • O aplicativo pode detectar quando está sobrecarregado e mudar o comportamento para evitar uma interrupção?

Recomendações

  • Implemente a espera exponencial com ordem aleatória na lógica de repetição de erro dos aplicativos clientes.
  • Implemente uma arquitetura multirregional com failover automático para alta disponibilidade.
  • Use o balanceamento de carga para distribuir solicitações de usuários entre fragmentos e regiões.
  • Projete o aplicativo para degradar suavemente em caso de sobrecarga, veiculando respostas parciais ou fornecendo funcionalidade limitada em vez de falhar completamente.
  • Para planejar capacidade, estabeleça um processo recorrente baseado em dados, usando testes de carga e previsões de tráfego para impulsionar o provisionamento de recursos.
  • Estabeleça procedimentos de recuperação de desastres e teste-os periodicamente.

Criar recursos de implantação flexíveis e automatizados

Garantir que todas as alterações possam ser revertidas

Se não houver uma maneira bem definida de desfazer certos tipos de alterações, mude o design do serviço para oferecer compatibilidade com reversões e teste esse processo periodicamente. Isso pode ser caro para aplicativos de dispositivos móveis, e sugerimos que os desenvolvedores apliquem a Configuração remota do Firebase para facilitar a reversão de recursos.

Distribuir o tráfego para promoções e lançamentos programados

Para eventos promocionais, como vendas que começam em um horário exato (por exemplo, à meia-noite) e incentivam muitos usuários a se conectarem ao serviço simultaneamente, projete um código de cliente para distribuir o tráfego por alguns segundos adicionando atrasos aleatórios antes de iniciar solicitações. Isso evita picos de tráfego instantâneos que possam travar os servidores no horário de início programado.

Implementar lançamentos progressivos com testes canário

Lance novas versões de executáveis e alterações de configuração gradualmente, começando com um escopo pequeno, como algumas VMs em uma zona. O objetivo é detectar bugs quando apenas uma pequena parte do tráfego de usuários é afetada, antes de lançar a alteração globalmente. Configure um sistema de "teste canário" que perceba essas alterações e faça uma comparação A/B das métricas dos servidores alterados com os servidores restantes, sinalizando um comportamento anômalo. O sistema canário deve alertar os operadores sobre os problemas e até mesmo interromper os lançamentos automaticamente. Depois que a alteração passar no teste canário, propague-a gradualmente para escopos maiores, como para uma zona completa e depois para uma segunda zona, permitindo que o sistema alterado processe volumes progressivamente maiores de tráfego do usuário para expor bugs latentes.

Automatizar a criação, o teste e a implantação

Use pipelines de CI/CD para criar testes automatizados nas versões e eliminar o esforço de lançamento. Realize testes e implantação de integração automatizados.

A automação é útil, mas não milagrosa. Ela tem custos consideráveis de manutenção e riscos de confiabilidade que vão além dos custos iniciais de desenvolvimento e configuração.

Recomendamos que você realize um inventário a avalie o custo do esforço nas equipes que gerenciam os sistemas. Torne esse processo contínuo e inicie-o antes de investir na automação personalizada para expandir o que os serviços e parceiros do Google Cloud já oferecem. Muitas vezes, é possível ajustar a automação do Google Cloud, por exemplo, o algoritmo de escalonamento automático do Compute Engine.

"Esforço" é o trabalho manual, repetitivo, automático e reativo que tende a não ter valor duradouro e aumenta pelo menos tão rápido quanto a origem dele. Para mais detalhes, consulte o capítulo Como eliminar o esforço do livro "SRE".

Veja a seguir algumas das principais áreas em que, graças à eliminação do esforço com o Google, foi possível fornecer uma automação configurável ou personalizada que ajudou nossos clientes:

  • Gerenciamento de identidade, por exemplo, Cloud Identity e Google IAM.
  • Soluções hospedadas pelo Google Cloud, em vez de "implantações próprias", como gerenciamento de cluster (Google Kubernetes Engine), banco de dados relacional (Cloud SQL), armazenamento de dados (BigQuery) e gerenciamento de API (Apigee)
  • Serviços do Google Cloud e provisionamento de locatários, por exemplo, Cloud Deployment Manager, Terraform, Cloud Foundation Toolkit
  • Provisionamento de capacidade extra, como vários produtos do Google Cloud que oferecem escalonamento automático configurável
  • Pipelines de CI/CD com implantação automatizada, por exemplo, Cloud Build
  • Análise canário para validar implantações, por exemplo, Kayenta
  • Treinamento de modelo automatizado (para machine learning), por exemplo, AutoML

Recomendamos priorizar a eliminação do esforço antes da automação, aproveitando ao máximo a automação configurável fornecida pelo Google para reduzir o esforço restante em um segundo momento. A terceira etapa, que pode ser feita em paralelo com a primeira e a segunda, envolve avaliar a criação ou a compra de outras soluções caso o custo do esforço continue alto, por exemplo, mais do que 50% do tempo para qualquer equipe que gerencia seus sistemas de produção. Ao criar ou comprar soluções, considere os custos de integração, segurança, privacidade e conformidade.

Se você encontrar um produto ou serviço do Google Cloud que atenda apenas parcialmente às suas necessidades técnicas de automatização ou eliminação de fluxos de trabalho manuais, envie uma solicitação de recurso por meio do representante da conta do Google Cloud. Isso pode ser mais uma prioridade para os clientes ou já fazer parte do roteiro. Nesse caso, saber a prioridade e o cronograma do recurso avalia melhor as vantagens de criar sua própria solução em vez de esperar para usá-la como um recurso do Google Cloud.

Perguntas sobre design

  • O processo de alteração de executáveis e configurações é automatizado?
  • A automação de mudanças foi projetada para permitir a reversão rápida para cada alteração possível?
  • Para alterações que não podem ser revertidas, como alterações de esquema, há um processo de análise de design para garantir a compatibilidade com versões anteriores ou futuras entre esquemas de dados e versões binárias atuais ou antigas?
  • Os arquivos de configuração do sistema são fragmentados, de modo que as alterações de configuração possam ser implementadas de forma incremental em vez de global?

Recomendações

  • Defina os testes canário de novos lançamentos e configurações.
  • Defina o esforço para suas equipes e avalie o custo regularmente.
  • Elimine esforços/fluxos de trabalho desnecessários antes de desenvolver uma automação personalizada.
  • Use a automação que já está disponível nos serviços do Google Cloud, ajustando a configuração padrão ou criando uma nova, caso não seja fornecida uma padrão.
  • Avalie criar (ou comprar) uma automação personalizada se o custo de manutenção e os riscos da confiabilidade e segurança do serviço valem a pena. Também recomendamos avaliar um software de código aberto com boa manutenção.

Criar alertas eficientes

Otimizar atraso de alertas

Ajuste o atraso configurado antes que o sistema de monitoramento notifique os humanos sobre um problema para minimizar o TTD enquanto maximiza o sinal em vez do ruído. Use a taxa de consumo de erro de orçamento para derivar a configuração de alerta ideal.

Alertar sobre sintomas, não causas

Acione alertas com base no impacto direto na experiência do usuário, ou seja, não conformidade com SLOs globais ou por cliente. Não alerte sobre todas as possíveis causas de uma falha, especialmente quando o impacto for limitado a uma réplica. Um sistema distribuído bem projetado se recupera perfeitamente de falhas de réplica única.

Criar um processo colaborativo de gerenciamento de incidentes

É impossível que seu sistema bem projetado acabe falhando nos SLOs. Lembre-se de que, na ausência de um SLO, seus clientes ainda definirão de forma imprecisa o nível de serviço aceitável com base na experiência anterior e o encaminharão para o suporte técnico ou grupo semelhante, seja lá o que estiver no SLA.

Para atender adequadamente seus clientes, recomendamos estabelecer e implementar regularmente um plano de gerenciamento de incidentes. O plano pode ser uma lista de verificação de uma página com cerca de 10 itens. Esse processo ajudará a equipe a reduzir o tempo médio de detecção (MTTD) e o tempo médio de mitigação (MTTM, ambos nas siglas em inglês). Usamos a sigla MTTM em vez de MTTR porque a segunda é ambígua. O R geralmente é usado como "reparo" ou "recuperação" para significar "correção completa" em vez de "mitigação". MTTM significa explicitamente a mitigação, não uma correção completa.

Um sistema bem projetado com operações excelentes aumentará o tempo médio entre falhas (MTBF, na sigla em inglês). Consulte as seções "Design de sistemas" e "Excelência operacional" para saber mais.

Também é importante estabelecer uma cultura retrospectiva sem atribuição de culpados e um processo de análise de incidentes. "Sem atribuição de culpados" significa que a equipe precisa avaliar e documentar o que deu errado de forma objetiva, sem "apontar o dedo". Erros são tratados como oportunidades de aprendizado, não como motivo para críticas. Sempre tente tornar o sistema mais resiliente para que ele possa se recuperar rapidamente de erros humanos ou, melhor ainda, detectar e evitar erros humanos.

Reduzir o MTTD

Um pré-requisito para reduzir o MTTD é implementar as recomendações descritas na seção "Observabilidade" e "Definir metas de monitoramento", por exemplo, eliminar a ambiguidade entre os problemas de aplicativos e os de nuvem.

Um conjunto bem ajustado de SLIs alerta a equipe no momento certo sem causar sobrecarga de alertas. Para orientação, consulte Ajuste suas métricas de SLI: lições de vida útil do CRE.

Reduzir o MTTM

Para reduzir o MTTM, tenha um plano de gerenciamento de incidentes adequadamente documentado e bem treinado. Além disso, tenha dados disponíveis sobre o que mudou.

Exemplo de plano de gerenciamento de incidentes

  • Foram detectados problemas de produção (alerta, página) ou encaminhados para mim.
  • Devo delegar em primeiro lugar? Sim, se você e sua equipe não conseguirem resolver isso.
  • Isso é uma violação de privacidade ou segurança? Se sim, delegue à equipe de privacidade/segurança.
  • É uma emergência ou os SLOs estão em risco? Em caso de dúvida, trate como uma emergência.
  • Devo envolver mais pessoas? Sim, se estiver afetando mais de X% dos clientes ou demorando mais de Y minutos para resolver. Se estiver em dúvida, sempre envolva mais pessoas, especialmente durante o horário comercial.
    • Defina um canal principal de comunicação, por exemplo, IRC, Hangouts Chat ou Slack.
    • Delegue papéis definidos anteriormente, por exemplo:
      • Comandante do incidente: responsável pela coordenação geral
      • Líder de comunicações: responsável por lidar com comunicações internas e externas
      • Líder de operações: responsável por mitigar o problema
    • Defina quando o incidente termina. Isso pode exigir a confirmação de um representante do suporte.
  • Colabore no processo póstumo.
  • Participe de uma reunião de análise retrospectiva dos incidentes para discutir as ações necessárias da equipe.

Gráficos

Veja uma lista de gráficos a serem considerados. As pessoas que responderem a incidentes devem ser capazes de visualizá-los em um único lugar.

  • Indicadores de nível de serviço: por exemplo, solicitações bem-sucedidas divididas pelo total
  • Configuração e/ou lançamentos binários
  • Solicitações por segundo para o sistema
  • Erros por segundo retornados pelo sistema
  • Solicitações por segundo do sistema para as dependências
  • Erros por segundo do sistema para as dependências

Geralmente, vemos o tamanho da solicitação e da resposta, o custo da consulta, os pools de linhas de execução (para procurar uma regressão induzida pelo esgotamento do pool) e as métricas do JVM sendo representadas graficamente (quando aplicável).

Teste alguns posicionamentos para esses gráficos. Também é possível usar machine learning para encontrar o subconjunto certo desses gráficos (ou seja, técnicas de detecção de anomalias).

Por fim, conforme discutido anteriormente, outra abordagem comum para a mitigação rápida é projetar sistemas e alterações facilmente reversíveis.

Recomendações

  • Estabeleça e treine suas equipes com um plano de gerenciamento de incidentes.
  • Implemente as recomendações da seção "Observabilidade" para reduzir o MTTD.
  • Crie um painel "o que mudou" que você consiga visualizar durante os incidentes.
  • Documente snippets de consulta ou crie um painel do Data Studio.
  • Avalie a Configuração remota do Firebase para mitigar problemas de lançamento relacionados a aplicativos para dispositivos móveis.
  • Implemente as recomendações de "Recuperação de desastres" para diminuir o MTTM de um subconjunto de incidentes.
  • Projete e teste configurações e reversões binárias.
  • Implemente as recomendações das seções "Design de sistemas" e "Recuperação de desastres" (teste) para aumentar o MTBF.

Recursos