Get best of the week

Top Fakapov Cyan



Bom para todos! 

Meu nome é Nikita, sou líder de equipe de engenheiros cianos. Uma das minhas responsabilidades na empresa é reduzir o número de incidentes relacionados à infraestrutura no produto para zero.
O que será discutido mais adiante nos trouxe muita dor, e o objetivo deste artigo é impedir que outras pessoas repitam nossos erros ou, pelo menos, minimizar seu impacto. 

Preâmbulo


Era uma vez, quando o Cyan consistia em monólitos e ainda não havia dicas de microsserviços, medimos a disponibilidade do recurso verificando 3-5 páginas. 

Resposta - está tudo bem, não responda por muito tempo - alerta. Quanto tempo eles não devem trabalhar para que isso seja considerado um incidente, decidiram as pessoas nas reuniões. Uma equipe de engenheiros sempre esteve envolvida na investigação do incidente. Quando a investigação foi concluída, eles escreveram um post-mortem - um tipo de relatório para os correios no formato: o que foi, quanto tempo, o que foi feito no momento, o que será feito no futuro. 

As páginas principais do site, ou como entendemos, quebraram o fundo

 
Para entender de alguma forma a prioridade do erro, destacamos as páginas mais críticas do site para a funcionalidade da empresa. De acordo com eles, consideramos o número de solicitações e tempos limite bem-sucedidos / malsucedidos. Então, medimos o tempo de atividade. 

Suponha que descobrimos que existem várias seções super importantes do site responsáveis ​​pelo serviço principal - pesquisa e envio de anúncios. Se o número de solicitações que falharam for maior que 1%, esse é um incidente crítico. Se em 15 minutos no horário nobre a porcentagem de erros exceder 0,1%, também será considerado um incidente crítico. Esses critérios abrangem a maioria dos incidentes, o restante está além do escopo deste artigo.



Os melhores incidentes de ciano


Então, aprendemos precisamente a determinar o fato de que o incidente aconteceu. 

Agora, cada incidente em nosso país é descrito em detalhes e refletido no épico de Jira. A propósito: para isso, iniciamos um projeto separado, chamado FAIL - somente épicos podem ser criados nele. 

Se você coletar todas as falhas nos últimos anos, os líderes serão: 

  • incidentes relacionados ao mssql;
  • incidentes causados ​​por fatores externos;
  • erros de administrador.

Vamos nos aprofundar nos detalhes dos erros dos administradores, bem como em algumas outras falhas interessantes.

Quinto lugar - "Colocando ordem no DNS"


Era uma terça-feira chuvosa. Decidimos limpar o cluster DNS. 

Eu queria transferir os servidores DNS internos de bind para powerdns, destacando servidores completamente separados para ele, onde não há nada além de DNS. 

Colocamos um servidor DNS em cada local dos nossos DCs, e chegou o momento de mover as zonas de ligação para powerdns e mudar a infraestrutura para novos servidores. 

No auge da movimentação, de todos os servidores que foram indicados no cache local de ligação em todos os servidores, havia apenas um que estava no datacenter em São Petersburgo. Esse CD foi inicialmente declarado como não crítico para nós, mas de repente se tornou um único ponto de falha.
Apenas durante esse período de realocação, o canal entre Moscou e São Petersburgo caiu. Na verdade, ficamos sem DNS por cinco minutos e levantamos quando o hoster resolveu os problemas. 

Conclusões:

se anteriormente negligenciamos fatores externos durante a preparação para o trabalho, agora eles também são incluídos na lista do que estamos preparando. E agora nos esforçamos para garantir que todos os componentes sejam reservados n-2 e, durante a duração do trabalho, podemos reduzir esse nível para n-1.

  • Ao elaborar um plano de ação, marque os pontos em que o serviço pode cair e pense sobre o cenário em que tudo correu "pior do que nada", com antecedência.
  • Distribua servidores DNS internos por diferentes geolocalizações / data centers / racks / switches / entradas.
  • Em cada servidor, coloque um servidor DNS em cache local, que redirecione as solicitações para os principais servidores DNS e, se não estiver disponível, responderá a partir do cache. 

Quarto lugar - "Limpando o Nginx"


Um belo dia, nossa equipe decidiu que "o suficiente para suportar isso", e o processo de refatoração das configurações do nginx foi iniciado. O objetivo principal é trazer as configurações para uma estrutura intuitiva. Anteriormente, tudo era "estabelecido historicamente" e não havia lógica em si. Agora, cada server_name foi retirado para o arquivo com o mesmo nome e distribuído todas as configurações em pastas. A propósito, a configuração contém 253949 linhas ou 7836520 caracteres e ocupa quase 7 megabytes. Estrutura de nível superior: 

Estrutura Nginx
├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    ├── cian-mcs.conf
    ├── ...
    └── wafserver.conf


Tornou-se muito melhor, mas no processo de renomear e distribuir as configurações, algumas delas tinham a extensão errada e não se enquadravam na diretiva include * .conf. Como resultado, parte dos hosts ficou indisponível e retornou 301 para o principal. Devido ao fato de o código de resposta não ser 5xx / 4xx, isso não foi percebido imediatamente, mas apenas pela manhã. Depois disso, começamos a escrever testes para testar componentes de infraestrutura.

Constatações: 

  • Estruture corretamente as configurações (não apenas o nginx) e pense sobre a estrutura no estágio inicial do projeto. Assim, você os tornará mais compreensíveis para a equipe, o que, por sua vez, reduzirá o TTM.
  • Para alguns componentes de infraestrutura, escreva testes. Por exemplo: verificando se todos os nomes-chave do servidor retornam o status correto, + corpo da resposta. Será suficiente ter em mãos apenas alguns scripts que verificam as funções básicas do componente para que você não se lembre freneticamente às três da manhã o que mais precisa ser verificado. 

Terceiro lugar - “De repente terminou em Cassandra”


Os dados estavam crescendo constantemente e tudo estava bem até o momento em que o reparo de casos grandes começou a cair no cluster Cassandra, porque a compactação não podia funcionar neles. 

Em um dia chuvoso, o aglomerado quase se transformou em abóbora, a saber:

  • os lugares permaneceram em cerca de 20% do cluster total;
  • é impossível adicionar nós completamente, porque a limpeza não funciona após a adição de um nó devido à falta de espaço nas partições;
  • o desempenho cai um pouco, porque a compactação não funciona; 
  • o cluster está no modo de emergência.



Saída - adicionados outros 5 nós sem limpeza, após o que começaram a remover sistematicamente do cluster e os reinserir como nós vazios nos quais o local terminou. O tempo passou muito mais do que gostaríamos. Havia um risco de inacessibilidade parcial ou completa do cluster. 

Constatações:

  • Todos os servidores cassandra não devem ocupar mais de 60% do espaço em cada partição. 
  • Eles não devem ser carregados com mais de 50% da CPU.
  • Não obstrua o planejamento de capacidade e pense nele para cada componente, com base em suas especificidades.
  • Quanto mais nós no cluster, melhor. Os servidores que contêm uma pequena quantidade de dados são migrados mais rapidamente e esse cluster é mais fácil de reanimar. 

Segundo lugar - "Os dados do armazenamento de valores-chave do consul desapareceram"


Para a descoberta de serviços, como muitos, usamos o consul. Mas aqui, seu valor-chave também é usado para cálculos de monólito azul-verde. Ele armazena informações sobre upstream ativo e inativo, que mudam de lugar durante a implantação. Para isso, foi criado um serviço de implantação que interagia com o KV. Em algum momento, os dados do KV desapareceram. Recuperado da memória, mas com vários erros. Como resultado, durante o cálculo, a carga no upstream foi distribuída de maneira desigual e tivemos muitos 502 erros devido à sobrecarga dos back-ends na CPU. Como resultado, passamos do cônsul KV para o postgres, de onde não é tão fácil removê-los.  

Constatações:

  • - . , ES — , , , action.destructive_requires_name: true.
  • . , ( ,  python), .

— « » 


Em algum momento, notamos uma distribuição desigual de carga no nginx upstream nos casos em que havia mais de 10 servidores no back-end. Como o round-robin enviou solicitações de 1 para o último upstream em ordem, e cada recarregamento do nginx começou desde o início, o primeiro upstream sempre teve mais solicitações do que o resto, resultando em um trabalho mais lento e em todo o site. Isso se tornou mais perceptível à medida que a quantidade de tráfego aumentou. Apenas atualizar o nginx para ativar o aleatório não funcionou - você precisa refazer um monte de código lua que não decolou na versão 1.15 (naquele momento). Eu tive que corrigir nosso nginx 1.14.2, introduzindo suporte aleatório nele. Isso resolveu o problema. Esse bug ganha a nomeação de "capitão não óbvio".

Conclusões:

Foi muito interessante e emocionante investigar esse bug). 

  • Configure o monitoramento para ajudar a encontrar essas flutuações rapidamente. Por exemplo, você pode usar o ELK para monitorar os rps em cada back-end de cada montante e monitorar o tempo de resposta do ponto de vista do nginx. Nesse caso, nos ajudou a identificar o problema. 

Como resultado, a maioria das falhas poderia ter sido evitada com uma abordagem mais escrupulosa do que você está fazendo. Você deve sempre se lembrar da Lei de Murphy:  tudo o que pode dar errado dará errado e criará componentes com base nela. 

More articles:


All Articles