Uma análise interna da confiabilidade dos serviços do Facebook

Engenheiros de Produção

2009. SRE

2010. SRO e AppOps

2012. Engenheiros de Produção

2014. SRO de fechamento

• Estamos sempre integrados em equipes. Não temos a pesquisa SRE em geral, como no Google, é para cada serviço de pesquisa separadamente.
• Não estamos nos produtos , apenas na infraestrutura em que o produto se administra.
• Estamos oncall junto com os desenvolvedores.
• Como temos um pouco mais de experiência em sistemas e redes, nos concentramos em monitorar e extinguir serviços quando eles queimam intensamente. Corrigimos erros com antecedência que poderiam levar a falhas e influenciar a arquitetura de novos serviços desde o início, para que eles funcionassem sem problemas na produção.

Monitoramento

ATOP

ATOP é bonito, usamos constantemente.

Malloc HTTP

Thrift message
HTTP/1.1 400
"HTTP" == 0x48545450

malloc("HTTP")
pid = fork(); // errno = ENOMEM

malloc("HTTP")
pid = fork(); // errno = ENOMEM

// 0: heuristic overcommit
vm.overcommit_memory = 0

FB303

Service FacebookService {
    map<string, i64> getCounters()
}

incrementCounter(string& key);

setCounter(string& key, int64_t value);

Observabilidade

Mergulho

• Uma tabela que mostra as versões de arquivos binários, pacotes e quanta memória é consumida em todos os milhões de máquinas. Em cada host, um PS é feito uma vez por hora e enviado ao Scuba.
• Todos os dmesg, todos os despejos de memória são enviados para outras tabelas. Executamos o Perf a cada 10 minutos em cada máquina, para saber quais rastreamentos de pilha temos no kernel e o que a CPU global pode carregar.

Depuração do PHP

Dashboards

Como funciona

Quando o Facebook estava

Portal do Gerenciador de Incidentes

Prevenção

• Sob carga normal, a solicitação chega, é processada e retornada ao cliente.
• Com uma carga alta, as solicitações estão aguardando em uma fila porque todos os encadeamentos para processamento de solicitações estão ocupados. O atraso está aumentando, mas até agora está tudo bem.
• A linha está crescendo, a carga está aumentando. Em algum momento, tudo o que o servidor executa no cliente termina com um tempo limite de resposta e o cliente cai com um erro. Nesse ponto, o resultado do servidor pode ser simplesmente descartado.

Ferramentas

• Cubismo integrado no sistema.
• O FBAR é um "cavalo de batalha" que vem e conserta, para que ninguém se preocupe com um carro quebrado. Essa é a principal tarefa do FBAR, mas agora ele tem ainda mais tarefas.
• Coredumper , que escrevemos com dois colegas . Ele monitora coredumps em todas as máquinas e os coloca em um só lugar, juntamente com rastreamentos de pilha com todas as informações do host: onde está, como encontrar o tamanho. Mas o mais importante é que os rastreamentos de pilha são gratuitos, sem iniciar o GDB usando os programas BPF.

Pesquisas

"A principal responsabilidade do software do sistema deve ser continuar executando. A prestação de serviços deve ser vista como um efeito colateral benéfico da operação continuada »

• "O que acontece se o seu sistema receber 10% da carga?" Quando as pessoas pensam: "Mas sério, o que?" - insights aparecem e muitos até governam seus sistemas. Anteriormente, eles não pensavam sobre isso, mas após a pergunta há uma razão.
• "Quem é o primeiro a perceber problemas no seu serviço - você ou seus usuários?" Os desenvolvedores começam a se lembrar de quando isso aconteceu e: "... Talvez você precise adicionar alertas".
• "Qual é a sua maior dor oncall?" Isso é incomum para desenvolvedores, especialmente para novos. Eles imediatamente dizem: “Temos muitos alertas! Vamos limpá-los e remover aqueles que não são o caso ".
• "Qual a frequência de seus lançamentos?" Primeiro, eles lembram que o estão liberando com as mãos e, em seguida, eles têm sua própria implantação personalizada.

6-7 Saint HighLoad++, . (, , ).
telegram- . !