Lições aprendidas em 20 anos de Site Reliability Engineering (SRE) no Google

20 anos de lições aprendidas em Site Reliability Engineering (SRE)

Lições de engenharia de confiabilidade aprendidas com o YouTube

• Escolha de medidas de mitigação de risco

  • Em caso de erro grave, é preciso escolher medidas de mitigação proporcionais à severidade do erro.
  • Medidas excessivas de mitigação podem causar efeitos colaterais e só devem ser usadas quando houver um motivo legítimo para contornar procedimentos padrão.

• Testar mecanismos de recuperação para situações de emergência

  • Mecanismos de recuperação e medidas de mitigação devem ser suficientemente praticados e testados com antecedência, para que seja possível reagir de forma eficaz mesmo em situações críticas.
  • Os testes reduzem riscos futuros e melhoram a capacidade de resposta.

• Introdução gradual de mudanças (aplicando testes canário)

  • Antes de implantar mudanças em larga escala, elas devem ser introduzidas gradualmente para evitar impacto em todo o sistema caso surjam problemas.
  • Com o caso de mudança na configuração de cache do YouTube, ficou claro que até pequenas mudanças exigem uma introdução sistemática.

Lições aprendidas com o Google Calendar

• Importância de uma função de interrupção de emergência

  • Para mudanças com riscos potenciais, é necessário ter uma função como um "grande botão vermelho" para reagir rapidamente.
  • É preciso preparar uma função de interrupção de emergência considerando as dependências do serviço.

• Necessidade de testes de integração

  • Testes unitários são úteis em um escopo limitado, mas é preciso validar a adequação do sistema em conjunto com o ambiente real por meio de testes de integração.
  • A partir de um caso de erro no Google Calendar, reconheceu-se a importância de testes que sigam o caminho real de uso.

Lições do Google em 2017

• Importância de canais de comunicação para emergências

  • É necessário se preparar para canais de comunicação e canais de backup.
  • Em caso de indisponibilidade do serviço, é preciso contar com vários meios de comunicação independentes entre si e testar sua eficácia.

• Manter o mínimo de funcionalidade em caso de degradação de desempenho

  • O sistema deve ser projetado para oferecer funcionalidades básicas mesmo em estado degradado, evitando que o serviço pare completamente.

Testes de resiliência a desastres

• Testes de resiliência e recuperação em desastres
  • É preciso testar a resiliência de serviços e sistemas para garantir sua continuidade mesmo em situações de desastre.
  • Por meio de testes de recuperação, deve-se verificar se o sistema consegue voltar ao estado normal após uma interrupção.

Importância de medidas de mitigação automatizadas

• Automatização de medidas de mitigação
  • Em vez de lidar manualmente com falhas em múltiplas redes, é preciso reduzir o tempo de resolução com medidas de mitigação automatizadas.

Redução do intervalo entre implantações

• Realizar rollouts frequentes

  • Longos intervalos entre rollouts afetam a avaliação da segurança do sistema.

• Uma única versão global de hardware é um ponto único de falha

  • Depender apenas de um modelo específico pode simplificar a operação, mas se esse modelo apresentar problemas, a execução de funções críticas pode ser interrompida.
  • A existência de vários backbones de rede ajuda a evitar interrupções gerais e permite rotear tráfego prioritário para alternativas que ainda estejam funcionando.