Escrito por Ben Treynor Sloss
Editado por Betsy Beyer
Falhar Sensatamente
Limpe e valide inputs de configuração, e responda a inputs implausíveis, tanto continuando a funcionar no estado anterior como alertando para o recebimento de inputs incorretos. Os inputs incorretos inserem-se frequentemente em uma destas categorias:
Dados incorretos
Valide tanto a sintaxe como, se possível, a semântica. Observe dados vazios e dados parciais ou truncados (por exemplo, alerte se a configuração for N% menor que a versão anterior).
Dados atrasados
Isto pode invalidar os dados atuais devido a timeouts. Alerte bem antes que os dados expirem.
Falhe de uma forma que preserve o funcionamento, possivelmente à custa de ser excessivamente permissivo ou excessivamente simplista. Descobrimos que é geralmente mais seguro os sistemas continuarem a funcionar com a sua configuração anterior e aguardarem a aprovação de um humano antes de usar os novos dados, talvez inválidos.
Exemplos
Em 2005, o sistema global de balanceamento de carga e latência do DNS do Google recebeu um arquivo de entrada de DNS vazio como resultado das permissões de arquivo. Aceitou este arquivo vazio e serviu o NXDOMAIN durante seis minutos para todas as propriedades do Google. Em resposta, o sistema executa agora uma série de verificações de sanidade em novas configurações, incluindo a confirmação da presença de IPs virtuais para google.com, e continuará a servir as entradas DNS anteriores até receber um novo arquivo que passe nas verificações de input.
Em 2009, dados incorretos (mas válidos) levaram a Google a marcar toda a Web como contendo malware. Um arquivo de configuração contendo a lista de URLs suspeitos foi substituído por um único caractere de barra (/), que correspondia a todos os URLs. Verificações de mudanças drásticas no tamanho do arquivo e verificações se a configuração está correspondendo a sites que se acredita serem improváveis de conter malware teriam impedido que este chegasse à produção.
Lançamentos progressivos
Os lançamentos não urgentes devem prosseguir por fases. Tanto as alterações de configuração como as binárias introduzem o risco, e este risco é mitigado pela aplicação da alteração a pequenas frações de tráfego e capacidade de uma só vez. O tamanho do seu serviço ou lançamento, assim como o seu perfil de risco, informarão os percentuais de capacidade de produção para os quais o lançamento é direcionado e o intervalo de tempo adequado entre as fases. É também uma boa ideia realizar diferentes fases em diferentes geografias, a fim de detectar problemas relacionados a ciclos de tráfego diurno e diferenças de mistura de tráfego geográfico.
Os lançamentos devem ser supervisionados. Para garantir que nada inesperado ocorra durante o lançamento, ele deve ser monitorado pelo engenheiro que executa o estágio de lançamento ou, de preferência, por um sistema de monitoramento comprovadamente confiável. Se for detectado um comportamento inesperado, reverta primeiro e diagnostique depois para minimizar o tempo médio de recuperação.
Defina SLOs como um usuário
Meça a disponibilidade e o desempenho em termos que interessam a um usuário final. Ver Capítulo 4 para mais discussões.
Exemplo
Medir as taxas de erro e a latência no cliente do Gmail, e não no servidor, resultou em uma redução substancial em nossa avaliação da disponibilidade do Gmail e levou a alterações no código do cliente e do servidor do Gmail. O resultado foi que o Gmail passou de cerca de 99,0% disponível para mais de 99,9% disponível em poucos anos.
Error Budgets
Equilibre a confiabilidade e o ritmo da inovação com error budgets (orçamento de erro) (ver Motivação para error budgets), que definem o nível aceitável de falhas para um serviço, durante algum período; utilizamos frequentemente um mês. Um orçamento é simplesmente 1 menos o SLO de um serviço; por exemplo, um serviço com um objetivo de 99,99% de disponibilidade tem um “orçamento” de 0,01% para indisponibilidade. Desde que o serviço não tenha gasto seu error budget do mês por meio da taxa de erros em segundo plano mais qualquer tempo de inatividade, a equipe de desenvolvimento está livre (dentro do razoável) para lançar novas funcionalidades, atualizações, e assim por diante.
Se o error budget for gasto, o serviço congela alterações (exceto segurança urgente e correções de bugs que abordem qualquer causa do aumento de erros) até que o serviço recupere espaço no orçamento ou o mês seja redefinido. Para serviços maduros com um SLO superior a 99,99%, um reset do orçamento trimestral em vez de mensal é apropriado, pois o tempo de inatividade permitido é pequeno.
Os error budgets eliminam a tensão estrutural que poderia se desenvolver entre o SRE e as equipes de desenvolvimento de produtos, dando-lhes um mecanismo comum, orientado por dados, para avaliar o risco de lançamento. Eles também dão às equipes de desenvolvimento de produtos e SRE um objetivo comum de desenvolver práticas e tecnologia que permitem inovação mais rápida e mais lançamentos sem “explodir o orçamento”.
Monitoramento
O monitoramento pode ter apenas três tipos de saída:
Alertas
Um humano deve fazer algo agora
Tickets
Um humano deve fazer algo em poucos dias
Logging
Ninguém precisa olhar imediatamente para esta saída, mas está disponível para análise posterior, se necessário
Se for suficientemente importante para incomodar um humano, deve ou exigir uma ação imediata (ou seja, um alerta) ou ser tratado como um bug e introduzido no seu sistema de rastreamento de bugs. Colocar alertas em e-mail e esperar que alguém leia todos eles e perceba os importantes é o equivalente moral de enviá-los para /dev/null: eles eventualmente serão ignorados. A história demonstra que esta estratégia é um incômodo atrativo porque pode funcionar durante algum tempo, mas depende da eterna vigilância humana, e a interrupção inevitável é, portanto, mais grave quando ocorre.
Correspondência
Os postmortems (ver Capítulo 15) devem ser irrepreensíveis e concentrar-se no processo e na tecnologia, e não nas pessoas. Assuma que as pessoas envolvidas em um incidente sejam inteligentes, bem intencionadas e estejam fazendo as melhores escolhas possíveis, de acordo com as informações disponíveis no momento. Segue-se que não podemos “consertar” as pessoas, mas sim consertar seu ambiente: por exemplo, melhorar o design do sistema para evitar classes inteiras de problemas, tornar as informações apropriadas facilmente disponíveis e validar automaticamente as decisões operacionais para dificultar a colocação sistemas em estados perigosos.
Planejamento de capacidade
Provisão para lidar com uma interrupção simultânea planejada e não planejada, sem tornar a experiência do usuário inaceitável; isto resulta numa configuração “N + 2”, onde o tráfego de pico pode ser tratado por N instâncias (possivelmente em modo degradado) enquanto as 2 instâncias maiores não estão disponíveis:
- Valide as previsões de demanda anteriores contra a realidade até que correspondam consistentemente à realidade. A divergência implica previsões instáveis, provisionamento ineficiente e o risco de um déficit de capacidade.
- Utilize testes de carga em vez da tradição para estabelecer a relação recursos/capacidade: um cluster de X máquinas poderia lidar com consultas Y por segundo há três meses, mas será que ainda o pode fazer tendo em conta as alterações no sistema?
- Não confunda a carga do primeiro dia com a carga de estado estacionário. Os lançamentos atraem frequentemente mais tráfego, enquanto também são o momento em que você deseja dar o melhor de si no produto. Ver Capítulo 27 e Apêndice E.
Sobrecargas e falhas
Os serviços devem produzir resultados razoáveis, mas abaixo do ideal, se sobrecarregados. Por exemplo, a Pesquisa Google pesquisará uma fração menor do índice, e interromperá a veiculação de funcionalidades como o Instant para continuar a fornecer resultados de pesquisa na Web de boa qualidade quando sobrecarregados. A pesquisa SRE testa clusters de pesquisa na web para além da sua capacidade nominal, para garantir um desempenho aceitável quando sobrecarregados com tráfego.
Para momentos em que a carga é alta o suficiente, que mesmo as respostas degradadas são demasiado caras para todas as consultas, pratique graciosamente redução de carga, utilizando enfileiramento bem comportados e tempos de espera dinâmicos; ver Capítulo 21. Outras técnicas incluem responder a solicitações após um atraso significativo (“tarpitting”) e escolher um subconjunto consistente de clientes para receber erros, preservando uma boa experiência do usuário para os restantes.
As novas tentativas podem amplificar baixas taxas de erro em níveis mais elevados de tráfego, levando a falhas em cascata (ver Capítulo 22 ). Responda a falhas em cascata, eliminando uma fração do tráfego (incluindo novas tentativas!) upstream do sistema quando a carga total exceder a capacidade total.
Cada cliente que faz um RPC deve implementar um backoff exponencial (com jitter) para novas tentativas, para amortecer a amplificação de erros. Os clientes móveis são especialmente problemáticos porque pode haver milhões deles e a atualização do seu código para corrigir o comportamento leva uma quantidade significativa de tempo – possivelmente semanas – e exige que os usuários instalem atualizações.
Equipes SRE
As equipes SRE não devem gastar mais de 50% do seu tempo em trabalho operacional (ver Capítulo 5 ); o sobrefluxo operacional deve ser dirigido à equipe de desenvolvimento do produto. Muitos serviços incluem também os desenvolvedores de produtos na rotação de plantão e no tratamento de tickets, mesmo que não haja atualmente um sobrefluxo. Isso fornece incentivos para projetar sistemas que minimizem ou eliminem a labuta operacional, além de garantir que os desenvolvedores de produtos estejam em contato com o lado operacional do serviço. Uma reunião regular de produção entre os SREs e a equipe de desenvolvimento (ver Capitulo 31) também é útil.
Descobrimos que pelo menos oito pessoas precisam fazer parte da equipe de plantão, a fim de evitar a fadiga e permitir um pessoal sustentável e uma baixa rotatividade. De preferência, as pessoas de plantão devem estar em duas localizações geográficas bem separadas (por exemplo, Califórnia e Irlanda) para proporcionar uma melhor qualidade de vida, evitando páginas noturnas; neste caso, seis pessoas em cada local é o tamanho mínimo da equipe.
Não espere lidar com mais de dois eventos por turno de plantão (por exemplo, por 12 horas): é preciso tempo para responder e corrigir as interrupções, iniciar postmortem, e arquivar os bugs resultantes. Eventos mais frequentes podem degradar a qualidade da resposta, e sugerir que algo está errado (pelo menos um dos) com o design do sistema, monitoramento da sensibilidade, e resposta a bugs postmortem.
Ironicamente, se implementar estas melhores práticas, a equipe de SRE pode acabar perdendo a prática de responder a incidentes devido à sua infrequência, fazendo uma longa interrupção de uma curta. Pratique o tratamento de interrupções hipotéticas (ver Desempenho do Papel do Desastre Capítulo 28 ) de forma rotineira e melhore a sua documentação de tratamento de incidentes no processo.
Fonte: Google SRE Book
