Capítulo 13 – Resposta de Emergência

Resposta de emergência

Escrito por Corey Adam Baye
Editado por Diane Bates

 

 

Coisas quebram; assim é a vida.

Independentemente dos interesses envolvidos ou do tamanho de uma organização, uma característica que é vital para sua saúde a longo prazo e que, consequentemente, a diferencia das outras, é como as pessoas envolvidas respondem a uma emergência. Poucos de nós respondem naturalmente bem durante uma emergência. Uma resposta adequada requer preparação e treinamento prático periódico pertinente. Estabelecer e manter processos minuciosos de treinamento e teste exige o apoio da diretoria e da gestão, além da atenção cuidadosa da equipe. Todos esses elementos são essenciais para promover um ambiente no qual as equipes podem gastar dinheiro, energia e possivelmente até mesmo tempo de atividade para garantir que os sistemas, processos e pessoas respondam com eficiência durante uma emergência.

Observe que o Capítulo 15, sobre cultura postmortem, discute os detalhes de como escrever postmortems para garantir que os incidentes que exigem resposta de emergência também se tornem uma oportunidade de aprendizado. Este capítulo fornece exemplos mais concretos de tais incidentes.

O que fazer quando os sistemas quebram

Em primeiro lugar, não entre em pânico! Você não está sozinho e o céu não está caindo. Você é um profissional treinado para lidar com esse tipo de situação. Normalmente, ninguém está em perigo físico – apenas pobres elétrons estão em perigo. Na pior das hipóteses, metade da Internet está fora do ar. Portanto, respire fundo e… continue.

Se você se sentir sobrecarregado, chame mais pessoas para ajudar. Às vezes, pode até ser necessário enviar um pager para toda a empresa. Se a sua empresa possui um processo de resposta a incidentes (veja Capítulo 14), certifique-se de que esteja familiarizado com ele e siga esse processo.

Emergência induzida por teste

O Google adotou uma abordagem proativa para testes de desastres e emergências (consulte aqui). Os SREs quebram nossos sistemas, observam como eles falham e fazem alterações para melhorar a confiabilidade e evitar que as falhas se repitam. Na maioria das vezes, essas falhas controladas acontecem conforme o planejado, e o sistema de destino e os sistemas dependentes se comportam aproximadamente da maneira como esperamos. Identificamos alguns pontos fracos ou dependências ocultas e documentamos ações de acompanhamento para corrigir as falhas que descobrimos. No entanto, às vezes nossas suposições e os resultados reais estão em mundos separados.

Aqui está um exemplo de um teste que revelou uma série de dependências inesperadas.

Detalhes

Queríamos liberar dependências ocultas em um banco de dados de teste em um de nossos maiores bancos de dados MySQL distribuídos. O plano era bloquear todo o acesso a apenas um banco de dados em cem. Ninguém previu os resultados que viriam.

Resposta

Poucos minutos após o início do teste, vários serviços dependentes reportaram que os usuários externos e internos não conseguiram acessar os sistemas principais. Alguns sistemas estavam intermitentemente ou apenas parcialmente acessíveis.

Assumindo que o teste era o responsável, o SRE abortou imediatamente o exercício. Tentamos reverter a alteração das permissões, mas não tivemos sucesso. Em vez de entrar em pânico, imediatamente pensamos em como restaurar o acesso adequado. Usando uma abordagem já testada, restauramos as permissões para as replicas e failovers. Em um esforço paralelo, procuramos os principais desenvolvedores para corrigir a falha na biblioteca da camada de aplicativo do banco de dados.

Uma hora após a decisão original, todo o acesso foi totalmente restaurado e todos os serviços puderam se conectar novamente. O amplo impacto desse teste motivou uma correção rápida e completa para as bibliotecas e um plano de reteste periódico para evitar que uma falha grave se repita.

Descobertas

O que correu bem

Os serviços dependentes afetados pelo incidente escalaram imediatamente os problemas dentro da empresa. Presumimos, corretamente, que nosso experimento controlado saiu do controle e abortou imediatamente o teste.

Conseguimos restaurar totalmente as permissões uma hora após o primeiro relatório, momento em que os sistemas começaram a se comportar corretamente. Algumas equipes adotaram uma abordagem diferente e reconfiguraram seus sistemas para evitar o banco de dados de teste. Esses esforços paralelos ajudaram a restaurar o serviço o mais rápido possível.

Os itens de ação de acompanhamento foram resolvidos de forma rápida e completa para evitar uma interrupção semelhante, e instituímos testes periódicos para garantir que falhas semelhantes não ocorram novamente.

O que aprendemos

Embora esse teste tenha sido completamente revisado e considerado bem definido, a realidade revelou que tínhamos uma compreensão insuficiente dessa interação particular entre os sistemas dependentes.

Falhamos em seguir o processo de resposta a incidentes, que havia sido implementado apenas algumas semanas antes e não havia sido completamente disseminado. Esse processo teria garantido que todos os serviços e clientes estivessem cientes da interrupção. Para evitar cenários semelhantes no futuro, o SRE refina e testa continuamente nossas ferramentas e processos de resposta a incidentes, além de garantir que as atualizações em nossos procedimentos de gestão de incidentes sejam comunicados claramente a todas as partes relevantes.

Como não testamos nossos procedimentos de rollback em um ambiente de teste, esses procedimentos apresentaram falhas, o que prolongou a interrupção. Agora exigimos testes completos de procedimentos de rollback antes de iniciar tais testes em grande escala.

Emergência induzida por mudança

Como você pode imaginar, o Google tem muitas configurações – configurações complexas – e fazemos alterações constantes nesta configuração. Para evitar a quebra total de nossos sistemas, realizamos vários testes nas alterações de configuração para garantir que não resultem em comportamento inesperado e indesejado. No entanto, a escala e a complexidade da infraestrutura do Google tornam impossível prever cada dependência ou interação; às vezes, as mudanças na configuração não acontecem totalmente de acordo com o planejado.

O seguinte caso é um exemplo.

Detalhes

Uma mudança na configuração da infraestrutura que ajuda a proteger nossos serviços contra abusos foi promovida globalmente em uma sexta-feira. Essa infraestrutura interage essencialmente com todos os nossos sistemas externos, e a mudança desencadeou um bug de crash-loop nesses sistemas, que fez com que toda a infraestrutura começasse a fazer um crash-loop quase simultaneamente. Como a infraestrutura interna do Google também depende de nossos próprios serviços, muitos aplicativos internos repentinamente também ficaram indisponíveis.

Resposta

Em segundos, os alertas de monitoramento começaram a disparar, indicando que alguns sites estavam fora do ar. Alguns engenheiros de plantão experimentaram simultaneamente o que acreditavam ser uma falha da rede corporativa e foram realocados para salas seguras dedicadas (salas de pânico) com acesso de backup ao ambiente de produção. Eles se juntaram a outros engenheiros que estavam enfrentando problemas com seus acessos corporativos.

Cinco minutos após o primeiro envio de configuração, o engenheiro responsável pelo envio, tendo ficado ciente da indisponibilidade corporativa, mas ainda sem saber da indisponibilidade mais ampla, pressionou outra mudança de configuração para reverter a primeira mudança. Nesse ponto, os serviços começaram a se recuperar.

Dentro de 10 minutos da primeira configuração push, os engenheiros de plantão declararam um incidente e passaram a seguir os procedimentos internos para resposta a incidentes. Eles começaram a notificar o resto da empresa sobre a situação. O engenheiro de push informou aos engenheiros de plantão que a interrupção provavelmente se devia à alteração que havia sido feita e posteriormente revertida. No entanto, alguns serviços apresentaram bugs não relacionados ou configurações incorretas acionadas pelo evento original e não se recuperaram totalmente por até uma hora.

Descobertas

O que correu bem

Vários fatores impediram que esse incidente resultasse em uma interrupção de longo prazo de muitos dos sistemas internos do Google.

Para começar, o monitoramento quase que imediatamente detectou e nos alertou sobre o problema. No entanto, é importante destacar que, neste caso, o nosso monitoramento ficou aquém do ideal: alertas disparados de forma repetida e constante, sobrecarregando as chamadas e enviando spam para canais de comunicação regulares e de emergência.

Assim que o problema foi detectado, o gerenciamento de incidentes em geral correu bem e as atualizações foram comunicadas com frequência e clareza. Nossos sistemas de comunicação fora de banda mantiveram todos conectados, mesmo quando algumas das pilhas de software mais complicadas estavam inutilizáveis. Essa experiência nos lembrou por que o SRE mantém sistemas de backup altamente confiáveis e de baixa sobrecarga, que usamos regularmente.

Além desses sistemas de comunicação fora de banda, o Google possui ferramentas de linha de comando e métodos alternativos de acesso que nos permitem realizar atualizações e reverter alterações, mesmo quando outras interfaces estão inacessíveis. Essas ferramentas e métodos de acesso funcionaram bem durante a interrupção, com a ressalva de que os engenheiros precisavam estar mais familiarizados com as ferramentas e testá-las mais rotineiramente.

A infraestrutura do Google fornecia mais uma camada de proteção, pois o sistema afetado limitava a taxa de rapidez com que fornecia atualizações completas para novos clientes. Esse comportamento pode ter limitado o loop de travamento e evitado uma interrupção completa, permitindo que os jobs permanecessem ativos por tempo suficiente para atender a algumas solicitações entre os travamentos.

Finalmente, não devemos ignorar o elemento de sorte na resolução rápida deste incidente: o engenheiro de push estava seguindo os canais de comunicação em tempo real – um nível adicional de diligência que não é uma parte normal do processo de liberação. O engenheiro de push percebeu um grande número de reclamações sobre o acesso corporativo logo após o push e reverteu a alteração quase que imediatamente. Se essa rápida reversão não tivesse ocorrido, a interrupção poderia ter durado consideravelmente mais, tornando-se imensamente mais difícil de solucionar.

O que aprendemos

Um push anterior do novo recurso envolveu um canary completo, mas não acionou o mesmo bug, pois não havia executado uma palavra-chave de configuração muito rara e específica em combinação com o novo recurso. A mudança específica que desencadeou este bug não foi considerada arriscada e, portanto, seguiu um processo canary menos rigoroso. Quando a mudança foi enviada globalmente, ela usou a combinação de palavra-chave/recurso não testada que desencadeou a falha.

Ironicamente, melhorias no canary e na automação estavam programadas para se tornarem mais prioritárias no trimestre seguinte. Este incidente imediatamente aumentou sua prioridade e reforçou a necessidade de canary completo, independentemente do risco percebido.

Como era de se esperar, o alerta foi vocal durante esse incidente porque cada local estava essencialmente offline por alguns minutos. Isso interrompeu o trabalho real que estava sendo executado pelos engenheiros de plantão e tornou a comunicação entre os envolvidos no incidente mais difícil.

O Google depende de nossas próprias ferramentas. Grande parte da pilha de software que usamos para solucionar problemas e nos comunicar está por trás de trabalhos que estavam em loop de falha. Se essa interrupção tivesse durado mais, o debug teria sido severamente prejudicado.

Emergência induzida por processo

Dedicamos uma quantidade considerável de tempo e energia à automação que gerencia nossa infraestrutura de máquinas. É incrível a quantidade de trabalhos que se pode iniciar, parar ou reequipar em toda a estrutura com muito pouco esforço. Às vezes, a eficiência de nossa automação pode ser um pouco assustadora quando as coisas não saem exatamente de acordo com o planejado.

Este é um exemplo onde mover-se rapidamente não foi exatamente uma coisa tão boa.

Detalhes

Como parte dos testes de automação de rotina, duas solicitações de desativação consecutivas para uma mesma instalação de servidor prestes a ser desativada foram submetidas. No caso da segunda solicitação de desativação, um bug sutil na automação adicionou todas as máquinas em todas essas instalações globalmente para a fila Diskerase, onde seus discos rígidos foram destinados a serem apagados; consulte, no Capítulo 7, o tópico “Automação: Habilitando a falha em escala” para mais detalhes.

Resposta

Logo depois que a segunda solicitação de desativação foi emitida, os engenheiros de plantão receberam uma página quando a primeira instalação de servidor pequeno foi colocada offline para ser desativada. A investigação determinou que as máquinas foram transferidas para a fila Diskerase, portanto, seguindo o procedimento normal, os engenheiros de plantão drenaram o tráfego do local. Como as máquinas naquele local foram apagadas, eles não puderam responder às solicitações. Para evitar a falha imediata dessas solicitações, os engenheiros de plantão drenaram o tráfego daquele local. O tráfego foi redirecionado para locais que poderiam responder adequadamente às solicitações.

Em pouco tempo, pagers em todos os lugares estavam disparando para todas as instalações de servidores ao redor do mundo. Em resposta, os engenheiros de plantão desativaram toda a automação da equipe para evitar mais danos. Eles pararam ou congelaram a automação adicional e a manutenção da produção logo em seguida.

Em uma hora, todo o tráfego foi desviado para outros locais. Embora os usuários possam ter experimentado latências elevadas, suas solicitações foram atendidas. A interrupção foi oficialmente encerrada.

E então começou a parte mais difícil: a recuperação. Alguns links de rede relataram um forte congestionamento, então os engenheiros de rede implementaram atenuações à medida que os pontos de estrangulamento surgiam. A instalação de um servidor em um desses locais foi escolhida para ser a primeira de muitas a renascer das cinzas. Três horas após a interrupção inicial, e graças à tenacidade de vários engenheiros, a instalação foi reconstruída e colocada novamente online, aceitando com satisfação as solicitações dos usuários mais uma vez.

As equipes dos EUA repassaram o ocorrido às suas contrapartes na Europa e o SRE traçou um plano para priorizar as reinstalações usando um processo simplificado, mas manual. A equipe foi dividida em três partes, sendo cada parte responsável por uma etapa do processo de reinstalação manual. Em três dias, grande parte da capacidade estava online novamente, enquanto as mais retardatárias seriam recuperadas nos próximos um ou dois meses.

Descobertas

O que correu bem

Proxies reversos em instalações de servidores grandes são gerenciados de maneira muito diferente dos proxies reversos em instalações pequenas, logo, as instalações grandes não foram afetadas. Os engenheiros de plantão conseguiram mover rapidamente o tráfego de instalações menores para as instalações maiores. Por design, essas instalações maiores podem lidar com uma carga completa sem dificuldade. No entanto, alguns links de rede ficaram congestionados e, portanto, exigiram que os engenheiros de rede desenvolvessem soluções alternativas. Para reduzir o impacto sobre os usuários finais, os engenheiros de plantão priorizaram as redes congestionadas.

O processo de desativação para pequenas instalações funcionou bem e com eficiência. Do início ao fim, demorou menos de uma hora para desligar com sucesso e limpar com segurança um grande número dessas instalações.

Embora a automação de desativação tenha rapidamente interrompido o monitoramento das instalações menores, os engenheiros de plantão foram capazes de reverter prontamente essas alterações de monitoramento. Isso os ajudou a avaliar a extensão dos danos.

Os engenheiros seguiram rapidamente os protocolos de resposta a incidentes, que amadureceram consideravelmente ao longo do ano desde a primeira interrupção descrita neste capítulo. A comunicação e a colaboração em toda a empresa e entre as equipes foram excelentes – um verdadeiro testemunho do programa e treinamento de gerenciamento de incidentes. Todas as mãos dentro das respectivas equipes contribuíram, trazendo sua vasta experiência para suportar as ações tomadas.

O que aprendemos

A causa raiz era que o servidor de automação de desativação não tinha as verificações de integridade apropriadas nos comandos enviados. Quando o servidor foi executado novamente em resposta à falha inicial de desativação, ele recebeu uma resposta vazia para o rack da máquina. Em vez de filtrar a resposta, ele passou o filtro vazio para o banco de dados da máquina, que por sua vez informou ao Diskerase que todas as máquinas estavam envolvidas. Sim, às vezes zero significa tudo. O banco de dados da máquina estava em conformidade, então o fluxo de trabalho de desativação começou a circular pelas máquinas o mais rapidamente possível.

As reinstalações de máquinas eram lentas e pouco confiáveis. Esse comportamento era devido em grande parte ao uso do Trivial File Transfer Protocol (TFTP) na Qualidade de Serviço (QoS) da rede mais lenta de locais distantes. O Bios – software embutido em um computador para enviar instruções simples ao hardware, permitindo entrada e saída antes que o sistema operacional seja carregado – de cada máquina do sistema lidou mal com as falhas. Dependendo das placas de rede envolvidas, o Bios parava ou entrava em um ciclo de reinicialização constante. Eles não conseguiam transferir os arquivos de inicialização em cada ciclo e sobrecarregavam ainda mais os instaladores. Os engenheiros de plantão conseguiram corrigir esses problemas de reinstalação reclassificando o tráfego de instalação com uma prioridade um pouco mais alta e usando a automação para reiniciar todas as máquinas que estavam travadas.

A infraestrutura de reinstalação de máquinas não foi capaz de lidar com a configuração simultânea de milhares de máquinas. Essa incapacidade foi parcialmente devido a uma regressão que impediu a infraestrutura de executar mais de duas tarefas de configuração por máquina de trabalho. A regressão também usou configurações de QoS inadequadas para transferir arquivos e teve tempos de intervalo mal ajustados. E forçou também a reinstalação do kernel, mesmo em máquinas que ainda tinham o kernel adequado e nas quais o Diskerase ainda não tinha ocorrido. Para remediar essa situação, os engenheiros de plantão escalaram as partes responsáveis por essa infraestrutura, que puderam reajustá-la rapidamente para suportar essa carga incomum.

Todos os problemas têm soluções

O tempo e a experiência têm mostrado que os sistemas não apenas quebrarão, mas quebrarão de maneiras que ninguém poderia imaginar anteriormente. Uma das maiores lições que o Google aprendeu é que existe uma solução, mesmo que não seja óbvia, especialmente para a pessoa cujo pager está apitando. Se você não consegue pensar em uma solução, lance sua rede mais longe. Envolva mais seus companheiros de equipe, peça ajuda, faça o que for preciso, mas faça rápido. A maior prioridade é resolver o problema em questão rapidamente. Muitas vezes, a pessoa com mais condição é aquela cujas ações de alguma forma acionaram o evento. Utilize essa pessoa.

Muito importante, uma vez que a emergência tenha sido mitigada, não se esqueça de reservar um tempo para limpar, escrever o incidente e…

Aprenda com o passado. Não o repita.

Mantenha um histórico de interrupções

Não há melhor maneira de aprender do que documentar o que quebrou no passado. História, é aprender com os erros de todos. Seja minucioso, seja honesto, mas acima de tudo, faça perguntas difíceis. Procure ações específicas que possam evitar que tal interrupção se repita, não apenas taticamente, mas também estrategicamente. Certifique-se de que todos na empresa possam aprender o que você aprendeu publicando e organizando postmortems.

Responsabilize-se e aos outros pelo acompanhamento das ações específicas detalhadas nesses postmortems. Isso evitará uma interrupção futura que é quase idêntica à causada por quase os mesmos acionadores de uma interrupção que já foi documentada. Depois de ter um histórico sólido de aprendizado com interrupções passadas, veja o que você pode fazer para evitar interrupções futuras.

Faça perguntas abrangentes, até mesmo improváveis: e se…?

Não há teste maior do que a realidade. Faça a si mesmo algumas perguntas abrangentes e abertas. E se a energia do prédio falhar…? E se os racks de equipamentos de rede estiverem a meio metro d’água…? E se o datacenter principal escurecer de repente…? E se alguém comprometer o seu servidor web…? O que você faz? Para quem você liga? Quem vai preencher o cheque? Você tem um plano? Você sabe como reagir? Você sabe como seus sistemas irão reagir? Você poderia minimizar o impacto se acontecesse agora? A pessoa sentada ao seu lado poderia fazer o mesmo?

Incentive o teste proativo

Quando se trata de falhas, teoria e realidade são dois domínios muito diferentes. Até que seu sistema tenha realmente falhado, você não sabe realmente como esse sistema, seus sistemas dependentes ou seus usuários irão reagir. Não confie em suposições ou no que você não pode testar ou não testou. Você prefere que uma falha aconteça às 2h da manhã de sábado, quando a maior parte da empresa ainda está ausente em um local externo de construção de equipes na Alemanha – ou quando você tem o seu melhor e mais brilhante colega por perto, monitorando o teste que analisaram meticulosamente nas semanas anteriores?

Conclusão

Revisamos três casos diferentes em que partes de nossos sistemas quebraram. Embora todas as três emergências tenham sido disparadas de forma diferente – uma por um teste proativo, outra por uma mudança de configuração e outra ainda por automação de desativação – as respostas compartilhavam muitas características. Os respondentes não entraram em pânico. Eles atraíram outros quando acharam necessário. Os respondentes estudaram e aprenderam com as interrupções anteriores. Posteriormente, eles construíram seus sistemas para responder melhor a esses tipos de interrupções. Cada vez que novos modos de falha se apresentavam, os respondentes documentavam esses modos de falha. Esse acompanhamento ajudou outras equipes a aprender como solucionar melhor os problemas e a fortalecer seus sistemas contra interrupções semelhantes. Os respondentes testaram seus sistemas de maneira proativa. Esses testes garantiram que as alterações corrigissem os problemas subjacentes e identificassem outras fraquezas antes que se tornassem interrupções.

E à medida que nossos sistemas evoluem, o ciclo continua, com cada interrupção ou teste resultando em melhorias incrementais para os processos e sistemas. Embora os estudos de caso neste capítulo sejam específicos do Google, essa abordagem de resposta a emergências pode ser aplicada com o tempo a qualquer organização de qualquer tamanho.

Fonte: Google SRE Book

Capítulo 13 – Resposta de Emergência

Resposta de emergência

Escrito por Corey Adam Baye
Editado por Diane Bates

 

 

Coisas quebram; assim é a vida.

Independentemente dos interesses envolvidos ou do tamanho de uma organização, uma característica que é vital para sua saúde a longo prazo e que, consequentemente, a diferencia das outras, é como as pessoas envolvidas respondem a uma emergência. Poucos de nós respondem naturalmente bem durante uma emergência. Uma resposta adequada requer preparação e treinamento prático periódico pertinente. Estabelecer e manter processos minuciosos de treinamento e teste exige o apoio da diretoria e da gestão, além da atenção cuidadosa da equipe. Todos esses elementos são essenciais para promover um ambiente no qual as equipes podem gastar dinheiro, energia e possivelmente até mesmo tempo de atividade para garantir que os sistemas, processos e pessoas respondam com eficiência durante uma emergência.

Observe que o Capítulo 15, sobre cultura postmortem, discute os detalhes de como escrever postmortems para garantir que os incidentes que exigem resposta de emergência também se tornem uma oportunidade de aprendizado. Este capítulo fornece exemplos mais concretos de tais incidentes.

O que fazer quando os sistemas quebram

Em primeiro lugar, não entre em pânico! Você não está sozinho e o céu não está caindo. Você é um profissional treinado para lidar com esse tipo de situação. Normalmente, ninguém está em perigo físico – apenas pobres elétrons estão em perigo. Na pior das hipóteses, metade da Internet está fora do ar. Portanto, respire fundo e… continue.

Se você se sentir sobrecarregado, chame mais pessoas para ajudar. Às vezes, pode até ser necessário enviar um pager para toda a empresa. Se a sua empresa possui um processo de resposta a incidentes (veja Capítulo 14), certifique-se de que esteja familiarizado com ele e siga esse processo.

Emergência induzida por teste

O Google adotou uma abordagem proativa para testes de desastres e emergências (consulte aqui). Os SREs quebram nossos sistemas, observam como eles falham e fazem alterações para melhorar a confiabilidade e evitar que as falhas se repitam. Na maioria das vezes, essas falhas controladas acontecem conforme o planejado, e o sistema de destino e os sistemas dependentes se comportam aproximadamente da maneira como esperamos. Identificamos alguns pontos fracos ou dependências ocultas e documentamos ações de acompanhamento para corrigir as falhas que descobrimos. No entanto, às vezes nossas suposições e os resultados reais estão em mundos separados.

Aqui está um exemplo de um teste que revelou uma série de dependências inesperadas.

Detalhes

Queríamos liberar dependências ocultas em um banco de dados de teste em um de nossos maiores bancos de dados MySQL distribuídos. O plano era bloquear todo o acesso a apenas um banco de dados em cem. Ninguém previu os resultados que viriam.

Resposta

Poucos minutos após o início do teste, vários serviços dependentes reportaram que os usuários externos e internos não conseguiram acessar os sistemas principais. Alguns sistemas estavam intermitentemente ou apenas parcialmente acessíveis.

Assumindo que o teste era o responsável, o SRE abortou imediatamente o exercício. Tentamos reverter a alteração das permissões, mas não tivemos sucesso. Em vez de entrar em pânico, imediatamente pensamos em como restaurar o acesso adequado. Usando uma abordagem já testada, restauramos as permissões para as replicas e failovers. Em um esforço paralelo, procuramos os principais desenvolvedores para corrigir a falha na biblioteca da camada de aplicativo do banco de dados.

Uma hora após a decisão original, todo o acesso foi totalmente restaurado e todos os serviços puderam se conectar novamente. O amplo impacto desse teste motivou uma correção rápida e completa para as bibliotecas e um plano de reteste periódico para evitar que uma falha grave se repita.

Descobertas

O que correu bem

Os serviços dependentes afetados pelo incidente escalaram imediatamente os problemas dentro da empresa. Presumimos, corretamente, que nosso experimento controlado saiu do controle e abortou imediatamente o teste.

Conseguimos restaurar totalmente as permissões uma hora após o primeiro relatório, momento em que os sistemas começaram a se comportar corretamente. Algumas equipes adotaram uma abordagem diferente e reconfiguraram seus sistemas para evitar o banco de dados de teste. Esses esforços paralelos ajudaram a restaurar o serviço o mais rápido possível.

Os itens de ação de acompanhamento foram resolvidos de forma rápida e completa para evitar uma interrupção semelhante, e instituímos testes periódicos para garantir que falhas semelhantes não ocorram novamente.

O que aprendemos

Embora esse teste tenha sido completamente revisado e considerado bem definido, a realidade revelou que tínhamos uma compreensão insuficiente dessa interação particular entre os sistemas dependentes.

Falhamos em seguir o processo de resposta a incidentes, que havia sido implementado apenas algumas semanas antes e não havia sido completamente disseminado. Esse processo teria garantido que todos os serviços e clientes estivessem cientes da interrupção. Para evitar cenários semelhantes no futuro, o SRE refina e testa continuamente nossas ferramentas e processos de resposta a incidentes, além de garantir que as atualizações em nossos procedimentos de gestão de incidentes sejam comunicados claramente a todas as partes relevantes.

Como não testamos nossos procedimentos de rollback em um ambiente de teste, esses procedimentos apresentaram falhas, o que prolongou a interrupção. Agora exigimos testes completos de procedimentos de rollback antes de iniciar tais testes em grande escala.

Emergência induzida por mudança

Como você pode imaginar, o Google tem muitas configurações – configurações complexas – e fazemos alterações constantes nesta configuração. Para evitar a quebra total de nossos sistemas, realizamos vários testes nas alterações de configuração para garantir que não resultem em comportamento inesperado e indesejado. No entanto, a escala e a complexidade da infraestrutura do Google tornam impossível prever cada dependência ou interação; às vezes, as mudanças na configuração não acontecem totalmente de acordo com o planejado.

O seguinte caso é um exemplo.

Detalhes

Uma mudança na configuração da infraestrutura que ajuda a proteger nossos serviços contra abusos foi promovida globalmente em uma sexta-feira. Essa infraestrutura interage essencialmente com todos os nossos sistemas externos, e a mudança desencadeou um bug de crash-loop nesses sistemas, que fez com que toda a infraestrutura começasse a fazer um crash-loop quase simultaneamente. Como a infraestrutura interna do Google também depende de nossos próprios serviços, muitos aplicativos internos repentinamente também ficaram indisponíveis.

Resposta

Em segundos, os alertas de monitoramento começaram a disparar, indicando que alguns sites estavam fora do ar. Alguns engenheiros de plantão experimentaram simultaneamente o que acreditavam ser uma falha da rede corporativa e foram realocados para salas seguras dedicadas (salas de pânico) com acesso de backup ao ambiente de produção. Eles se juntaram a outros engenheiros que estavam enfrentando problemas com seus acessos corporativos.

Cinco minutos após o primeiro envio de configuração, o engenheiro responsável pelo envio, tendo ficado ciente da indisponibilidade corporativa, mas ainda sem saber da indisponibilidade mais ampla, pressionou outra mudança de configuração para reverter a primeira mudança. Nesse ponto, os serviços começaram a se recuperar.

Dentro de 10 minutos da primeira configuração push, os engenheiros de plantão declararam um incidente e passaram a seguir os procedimentos internos para resposta a incidentes. Eles começaram a notificar o resto da empresa sobre a situação. O engenheiro de push informou aos engenheiros de plantão que a interrupção provavelmente se devia à alteração que havia sido feita e posteriormente revertida. No entanto, alguns serviços apresentaram bugs não relacionados ou configurações incorretas acionadas pelo evento original e não se recuperaram totalmente por até uma hora.

Descobertas

O que correu bem

Vários fatores impediram que esse incidente resultasse em uma interrupção de longo prazo de muitos dos sistemas internos do Google.

Para começar, o monitoramento quase que imediatamente detectou e nos alertou sobre o problema. No entanto, é importante destacar que, neste caso, o nosso monitoramento ficou aquém do ideal: alertas disparados de forma repetida e constante, sobrecarregando as chamadas e enviando spam para canais de comunicação regulares e de emergência.

Assim que o problema foi detectado, o gerenciamento de incidentes em geral correu bem e as atualizações foram comunicadas com frequência e clareza. Nossos sistemas de comunicação fora de banda mantiveram todos conectados, mesmo quando algumas das pilhas de software mais complicadas estavam inutilizáveis. Essa experiência nos lembrou por que o SRE mantém sistemas de backup altamente confiáveis e de baixa sobrecarga, que usamos regularmente.

Além desses sistemas de comunicação fora de banda, o Google possui ferramentas de linha de comando e métodos alternativos de acesso que nos permitem realizar atualizações e reverter alterações, mesmo quando outras interfaces estão inacessíveis. Essas ferramentas e métodos de acesso funcionaram bem durante a interrupção, com a ressalva de que os engenheiros precisavam estar mais familiarizados com as ferramentas e testá-las mais rotineiramente.

A infraestrutura do Google fornecia mais uma camada de proteção, pois o sistema afetado limitava a taxa de rapidez com que fornecia atualizações completas para novos clientes. Esse comportamento pode ter limitado o loop de travamento e evitado uma interrupção completa, permitindo que os jobs permanecessem ativos por tempo suficiente para atender a algumas solicitações entre os travamentos.

Finalmente, não devemos ignorar o elemento de sorte na resolução rápida deste incidente: o engenheiro de push estava seguindo os canais de comunicação em tempo real – um nível adicional de diligência que não é uma parte normal do processo de liberação. O engenheiro de push percebeu um grande número de reclamações sobre o acesso corporativo logo após o push e reverteu a alteração quase que imediatamente. Se essa rápida reversão não tivesse ocorrido, a interrupção poderia ter durado consideravelmente mais, tornando-se imensamente mais difícil de solucionar.

O que aprendemos

Um push anterior do novo recurso envolveu um canary completo, mas não acionou o mesmo bug, pois não havia executado uma palavra-chave de configuração muito rara e específica em combinação com o novo recurso. A mudança específica que desencadeou este bug não foi considerada arriscada e, portanto, seguiu um processo canary menos rigoroso. Quando a mudança foi enviada globalmente, ela usou a combinação de palavra-chave/recurso não testada que desencadeou a falha.

Ironicamente, melhorias no canary e na automação estavam programadas para se tornarem mais prioritárias no trimestre seguinte. Este incidente imediatamente aumentou sua prioridade e reforçou a necessidade de canary completo, independentemente do risco percebido.

Como era de se esperar, o alerta foi vocal durante esse incidente porque cada local estava essencialmente offline por alguns minutos. Isso interrompeu o trabalho real que estava sendo executado pelos engenheiros de plantão e tornou a comunicação entre os envolvidos no incidente mais difícil.

O Google depende de nossas próprias ferramentas. Grande parte da pilha de software que usamos para solucionar problemas e nos comunicar está por trás de trabalhos que estavam em loop de falha. Se essa interrupção tivesse durado mais, o debug teria sido severamente prejudicado.

Emergência induzida por processo

Dedicamos uma quantidade considerável de tempo e energia à automação que gerencia nossa infraestrutura de máquinas. É incrível a quantidade de trabalhos que se pode iniciar, parar ou reequipar em toda a estrutura com muito pouco esforço. Às vezes, a eficiência de nossa automação pode ser um pouco assustadora quando as coisas não saem exatamente de acordo com o planejado.

Este é um exemplo onde mover-se rapidamente não foi exatamente uma coisa tão boa.

Detalhes

Como parte dos testes de automação de rotina, duas solicitações de desativação consecutivas para uma mesma instalação de servidor prestes a ser desativada foram submetidas. No caso da segunda solicitação de desativação, um bug sutil na automação adicionou todas as máquinas em todas essas instalações globalmente para a fila Diskerase, onde seus discos rígidos foram destinados a serem apagados; consulte, no Capítulo 7, o tópico “Automação: Habilitando a falha em escala” para mais detalhes.

Resposta

Logo depois que a segunda solicitação de desativação foi emitida, os engenheiros de plantão receberam uma página quando a primeira instalação de servidor pequeno foi colocada offline para ser desativada. A investigação determinou que as máquinas foram transferidas para a fila Diskerase, portanto, seguindo o procedimento normal, os engenheiros de plantão drenaram o tráfego do local. Como as máquinas naquele local foram apagadas, eles não puderam responder às solicitações. Para evitar a falha imediata dessas solicitações, os engenheiros de plantão drenaram o tráfego daquele local. O tráfego foi redirecionado para locais que poderiam responder adequadamente às solicitações.

Em pouco tempo, pagers em todos os lugares estavam disparando para todas as instalações de servidores ao redor do mundo. Em resposta, os engenheiros de plantão desativaram toda a automação da equipe para evitar mais danos. Eles pararam ou congelaram a automação adicional e a manutenção da produção logo em seguida.

Em uma hora, todo o tráfego foi desviado para outros locais. Embora os usuários possam ter experimentado latências elevadas, suas solicitações foram atendidas. A interrupção foi oficialmente encerrada.

E então começou a parte mais difícil: a recuperação. Alguns links de rede relataram um forte congestionamento, então os engenheiros de rede implementaram atenuações à medida que os pontos de estrangulamento surgiam. A instalação de um servidor em um desses locais foi escolhida para ser a primeira de muitas a renascer das cinzas. Três horas após a interrupção inicial, e graças à tenacidade de vários engenheiros, a instalação foi reconstruída e colocada novamente online, aceitando com satisfação as solicitações dos usuários mais uma vez.

As equipes dos EUA repassaram o ocorrido às suas contrapartes na Europa e o SRE traçou um plano para priorizar as reinstalações usando um processo simplificado, mas manual. A equipe foi dividida em três partes, sendo cada parte responsável por uma etapa do processo de reinstalação manual. Em três dias, grande parte da capacidade estava online novamente, enquanto as mais retardatárias seriam recuperadas nos próximos um ou dois meses.

Descobertas

O que correu bem

Proxies reversos em instalações de servidores grandes são gerenciados de maneira muito diferente dos proxies reversos em instalações pequenas, logo, as instalações grandes não foram afetadas. Os engenheiros de plantão conseguiram mover rapidamente o tráfego de instalações menores para as instalações maiores. Por design, essas instalações maiores podem lidar com uma carga completa sem dificuldade. No entanto, alguns links de rede ficaram congestionados e, portanto, exigiram que os engenheiros de rede desenvolvessem soluções alternativas. Para reduzir o impacto sobre os usuários finais, os engenheiros de plantão priorizaram as redes congestionadas.

O processo de desativação para pequenas instalações funcionou bem e com eficiência. Do início ao fim, demorou menos de uma hora para desligar com sucesso e limpar com segurança um grande número dessas instalações.

Embora a automação de desativação tenha rapidamente interrompido o monitoramento das instalações menores, os engenheiros de plantão foram capazes de reverter prontamente essas alterações de monitoramento. Isso os ajudou a avaliar a extensão dos danos.

Os engenheiros seguiram rapidamente os protocolos de resposta a incidentes, que amadureceram consideravelmente ao longo do ano desde a primeira interrupção descrita neste capítulo. A comunicação e a colaboração em toda a empresa e entre as equipes foram excelentes – um verdadeiro testemunho do programa e treinamento de gerenciamento de incidentes. Todas as mãos dentro das respectivas equipes contribuíram, trazendo sua vasta experiência para suportar as ações tomadas.

O que aprendemos

A causa raiz era que o servidor de automação de desativação não tinha as verificações de integridade apropriadas nos comandos enviados. Quando o servidor foi executado novamente em resposta à falha inicial de desativação, ele recebeu uma resposta vazia para o rack da máquina. Em vez de filtrar a resposta, ele passou o filtro vazio para o banco de dados da máquina, que por sua vez informou ao Diskerase que todas as máquinas estavam envolvidas. Sim, às vezes zero significa tudo. O banco de dados da máquina estava em conformidade, então o fluxo de trabalho de desativação começou a circular pelas máquinas o mais rapidamente possível.

As reinstalações de máquinas eram lentas e pouco confiáveis. Esse comportamento era devido em grande parte ao uso do Trivial File Transfer Protocol (TFTP) na Qualidade de Serviço (QoS) da rede mais lenta de locais distantes. O Bios – software embutido em um computador para enviar instruções simples ao hardware, permitindo entrada e saída antes que o sistema operacional seja carregado – de cada máquina do sistema lidou mal com as falhas. Dependendo das placas de rede envolvidas, o Bios parava ou entrava em um ciclo de reinicialização constante. Eles não conseguiam transferir os arquivos de inicialização em cada ciclo e sobrecarregavam ainda mais os instaladores. Os engenheiros de plantão conseguiram corrigir esses problemas de reinstalação reclassificando o tráfego de instalação com uma prioridade um pouco mais alta e usando a automação para reiniciar todas as máquinas que estavam travadas.

A infraestrutura de reinstalação de máquinas não foi capaz de lidar com a configuração simultânea de milhares de máquinas. Essa incapacidade foi parcialmente devido a uma regressão que impediu a infraestrutura de executar mais de duas tarefas de configuração por máquina de trabalho. A regressão também usou configurações de QoS inadequadas para transferir arquivos e teve tempos de intervalo mal ajustados. E forçou também a reinstalação do kernel, mesmo em máquinas que ainda tinham o kernel adequado e nas quais o Diskerase ainda não tinha ocorrido. Para remediar essa situação, os engenheiros de plantão escalaram as partes responsáveis por essa infraestrutura, que puderam reajustá-la rapidamente para suportar essa carga incomum.

Todos os problemas têm soluções

O tempo e a experiência têm mostrado que os sistemas não apenas quebrarão, mas quebrarão de maneiras que ninguém poderia imaginar anteriormente. Uma das maiores lições que o Google aprendeu é que existe uma solução, mesmo que não seja óbvia, especialmente para a pessoa cujo pager está apitando. Se você não consegue pensar em uma solução, lance sua rede mais longe. Envolva mais seus companheiros de equipe, peça ajuda, faça o que for preciso, mas faça rápido. A maior prioridade é resolver o problema em questão rapidamente. Muitas vezes, a pessoa com mais condição é aquela cujas ações de alguma forma acionaram o evento. Utilize essa pessoa.

Muito importante, uma vez que a emergência tenha sido mitigada, não se esqueça de reservar um tempo para limpar, escrever o incidente e…

Aprenda com o passado. Não o repita.

Mantenha um histórico de interrupções

Não há melhor maneira de aprender do que documentar o que quebrou no passado. História, é aprender com os erros de todos. Seja minucioso, seja honesto, mas acima de tudo, faça perguntas difíceis. Procure ações específicas que possam evitar que tal interrupção se repita, não apenas taticamente, mas também estrategicamente. Certifique-se de que todos na empresa possam aprender o que você aprendeu publicando e organizando postmortems.

Responsabilize-se e aos outros pelo acompanhamento das ações específicas detalhadas nesses postmortems. Isso evitará uma interrupção futura que é quase idêntica à causada por quase os mesmos acionadores de uma interrupção que já foi documentada. Depois de ter um histórico sólido de aprendizado com interrupções passadas, veja o que você pode fazer para evitar interrupções futuras.

Faça perguntas abrangentes, até mesmo improváveis: e se…?

Não há teste maior do que a realidade. Faça a si mesmo algumas perguntas abrangentes e abertas. E se a energia do prédio falhar…? E se os racks de equipamentos de rede estiverem a meio metro d’água…? E se o datacenter principal escurecer de repente…? E se alguém comprometer o seu servidor web…? O que você faz? Para quem você liga? Quem vai preencher o cheque? Você tem um plano? Você sabe como reagir? Você sabe como seus sistemas irão reagir? Você poderia minimizar o impacto se acontecesse agora? A pessoa sentada ao seu lado poderia fazer o mesmo?

Incentive o teste proativo

Quando se trata de falhas, teoria e realidade são dois domínios muito diferentes. Até que seu sistema tenha realmente falhado, você não sabe realmente como esse sistema, seus sistemas dependentes ou seus usuários irão reagir. Não confie em suposições ou no que você não pode testar ou não testou. Você prefere que uma falha aconteça às 2h da manhã de sábado, quando a maior parte da empresa ainda está ausente em um local externo de construção de equipes na Alemanha – ou quando você tem o seu melhor e mais brilhante colega por perto, monitorando o teste que analisaram meticulosamente nas semanas anteriores?

Conclusão

Revisamos três casos diferentes em que partes de nossos sistemas quebraram. Embora todas as três emergências tenham sido disparadas de forma diferente – uma por um teste proativo, outra por uma mudança de configuração e outra ainda por automação de desativação – as respostas compartilhavam muitas características. Os respondentes não entraram em pânico. Eles atraíram outros quando acharam necessário. Os respondentes estudaram e aprenderam com as interrupções anteriores. Posteriormente, eles construíram seus sistemas para responder melhor a esses tipos de interrupções. Cada vez que novos modos de falha se apresentavam, os respondentes documentavam esses modos de falha. Esse acompanhamento ajudou outras equipes a aprender como solucionar melhor os problemas e a fortalecer seus sistemas contra interrupções semelhantes. Os respondentes testaram seus sistemas de maneira proativa. Esses testes garantiram que as alterações corrigissem os problemas subjacentes e identificassem outras fraquezas antes que se tornassem interrupções.

E à medida que nossos sistemas evoluem, o ciclo continua, com cada interrupção ou teste resultando em melhorias incrementais para os processos e sistemas. Embora os estudos de caso neste capítulo sejam específicos do Google, essa abordagem de resposta a emergências pode ser aplicada com o tempo a qualquer organização de qualquer tamanho.

Fonte: Google SRE Book

Experimente agora, grátis!