Top fakapov Cyan

Todo ben! 

Chámome Nikita, son o xefe de equipo do equipo de enxeñería de Cian. Unha das miñas responsabilidades na empresa é reducir a cero o número de incidencias relacionadas coa infraestrutura en produción.
O que se comentará a continuación provocounos moita dor, e o propósito deste artigo é evitar que outras persoas repitan os nosos erros ou polo menos minimicen o seu impacto. 

Preámbulo

Hai moito tempo, cando Cian consistía en monolitos e aínda non había indicios de microservizos, medimos a dispoñibilidade dun recurso comprobando 3-5 páxinas. 

Eles responden: todo está ben, se non responden durante moito tempo, alerta. Canto tempo tiñan que estar fóra do traballo para que se considerase un incidente decidiuno a xente nas reunións. Un equipo de enxeñeiros estivo sempre implicado na investigación do suceso. Cando rematou a investigación, redactaron unha autopsia, unha especie de informe por correo electrónico no formato: que pasou, canto tempo durou, que fixemos no momento, que faremos no futuro. 

As páxinas principais do sitio ou como entendemos que chegamos ao fondo

 
Para comprender dalgunha maneira a prioridade do erro, identificamos as páxinas do sitio máis críticas para a funcionalidade empresarial. Utilizándoas, contamos o número de solicitudes e tempo de espera exitosos/non exitosos. Así é como medimos o tempo de actividade. 

Digamos que descubrimos que hai unha serie de seccións súper importantes do sitio que son responsables do servizo principal: buscar e enviar anuncios. Se o número de solicitudes que fallan supera o 1%, trátase dun incidente crítico. Se dentro de 15 minutos durante o horario de máxima audiencia a taxa de erro supera o 0,1%, entón tamén se considera un incidente crítico. Estes criterios cobren a maioría dos incidentes, o resto quedan fóra do ámbito deste artigo.

Top mellores incidentes Cyan

Entón, definitivamente aprendemos a determinar o feito de que ocorreu un incidente. 

Agora cada incidente descríbese en detalle e reflíctese na épica Jira. Por certo: para iso iniciamos un proxecto separado, chamado FAIL - só se poden crear épicos nel. 

Se recolles todos os fallos dos últimos anos, os líderes son: 

• incidentes relacionados con mssql;
• incidentes causados ​​por factores externos;
• erros de administración.

Vexamos con máis detalle os erros dos administradores, así como algúns outros fallos interesantes.

Quinto lugar - "Poner as cousas en orde no DNS"

Foi un martes de tormenta. Decidimos restaurar a orde no clúster DNS. 

Quería transferir servidores DNS internos de bind a powerdns, asignando servidores completamente separados para iso, onde non hai nada excepto DNS. 

Colocamos un servidor DNS en cada localización dos nosos DC, e chegou o momento de mover as zonas de enlace a powerdns e cambiar a infraestrutura a novos servidores. 

No medio do traslado, de todos os servidores que se especificaron en enlaces de caché local en todos os servidores, só quedaba un, que estaba no centro de datos de San Petersburgo. Este DC foi inicialmente declarado como non crítico para nós, pero de súpeto converteuse nun único punto de falla.
Foi durante este período de traslado cando a canle entre Moscova e San Petersburgo caeu. En realidade, estivemos sen DNS durante cinco minutos e volvemos a levantarnos cando o servidor solucionou o problema. 

Conclusións:

Se antes descoidabamos os factores externos durante a preparación para o traballo, agora tamén están incluídos na lista do que nos estamos preparando. E agora esforzámonos por garantir que todos os compoñentes estean reservados n-2, e durante o traballo podemos baixar este nivel a n-1.

• Ao elaborar un plan de acción, marca os puntos nos que o servizo podería fallar e pensa nun escenario no que todo fose "de mal en peor" con antelación.
• Distribuír servidores DNS internos en diferentes xeolocalizacións/centros de datos/racks/conmutadores/entradas.
• En cada servidor, instala un servidor DNS de caché local, que redirixe as solicitudes aos servidores DNS principais e, se non está dispoñible, responderá desde a caché. 

Cuarto lugar: "Poñer orde en Nginx"

Un bo día, o noso equipo decidiu que "xa tivemos farto disto" e comezou o proceso de refactorización das configuracións de nginx. O obxectivo principal é levar as configuracións a unha estrutura intuitiva. Antes, todo estaba "históricamente establecido" e non levaba ningunha lóxica. Agora cada server_name moveuse a un ficheiro co mesmo nome e todas as configuracións distribuíronse en cartafoles. Por certo, a configuración contén 253949 liñas ou 7836520 caracteres e ocupa case 7 megabytes. Nivel superior de estrutura: 

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

Foi moito mellor, pero no proceso de renomear e distribuír as configuracións, algunhas delas tiñan a extensión incorrecta e non estaban incluídas na directiva include *.conf. Como resultado, algúns anfitrións non estaban dispoñibles e volveron 301 á páxina principal. Debido ao feito de que o código de resposta non era 5xx/4xx, isto non se detectou inmediatamente, senón só pola mañá. Despois diso, comezamos a escribir probas para comprobar os compoñentes da infraestrutura.

Conclusións: 

• Estrutura as túas configuracións correctamente (non só nginx) e pensa na estrutura nunha fase inicial do proxecto. Deste xeito farás máis comprensibles para o equipo, o que á súa vez reducirá o TTM.
• Escribe probas para algúns compoñentes da infraestrutura. Por exemplo: comprobando que todos os nomes de servidor clave dan o estado correcto + o corpo da resposta. Bastará con ter a man uns cantos scripts que comproben as funcións básicas do compoñente, para non lembrar frenéticamente ás 3 da mañá que máis hai que comprobar. 

Terceiro lugar: "De súpeto quedou sen espazo en Cassandra"

Os datos creceron constantemente e todo estivo ben ata o momento en que a reparación de grandes espazos de casos comezou a fallar no clúster Cassandra, porque a compactación non podía funcionar neles. 

Un día de tormenta o racimo case se converteu nunha cabaza, a saber:

• quedaba arredor do 20% do espazo total no clúster;
• É imposible engadir nodos por completo, porque a limpeza non se realiza despois de engadir un nodo debido á falta de espazo nas particións;
• a produtividade cae gradualmente a medida que a compactación non funciona; 
• O clúster está en modo de emerxencia.

Saír: engadimos 5 nodos máis sen limpeza, despois de que comezamos a eliminalos do clúster de forma sistemática e a ingresalos de novo, como nodos baleiros que quedaran sen espazo. Pasouse moito máis tempo do que nos gustaría. Houbo o risco de indisponibilidade parcial ou total do clúster. 

Conclusións:

• En todos os servidores Cassandra, non se debe ocupar máis do 60% do espazo en cada partición. 
• Deben cargarse a non máis do 50% de CPU.
• Non debes esquecer a planificación da capacidade e hai que pensalo ben para cada compoñente, en función das súas particularidades.
• Cantos máis nodos no clúster, mellor. Os servidores que conteñen unha pequena cantidade de datos sobrecárganse máis rápido e un clúster deste tipo é máis fácil de revivir. 

Segundo lugar: "Os datos desapareceron do almacenamento de clave-valor do cónsul"

Para o descubrimento do servizo, nós, como moitos, usamos cónsul. Pero tamén usamos o seu valor clave para o deseño azul-verde do monólito. Almacena información sobre subidas activas e inactivas, que cambian de lugar durante a implantación. Para iso, escribiuse un servizo de despregamento que interactuaba con KV. Nalgún momento, os datos de KV desapareceron. Restaurado desde a memoria, pero con varios erros. Como resultado, durante a carga, a carga dos upstreams distribuíuse de forma desigual e recibimos moitos erros 502 debido a que os backends estaban sobrecargados na CPU. Como resultado, pasamos de consul KV a postgres, de onde xa non é tan fácil eliminalos.  

Conclusións:

• Os servizos sen ningunha autorización non deben conter datos críticos para o funcionamento do sitio. Por exemplo, se non tes autorización en ES, sería mellor denegar o acceso a nivel de rede desde todos os lugares onde non sexa necesario, deixar só os necesarios e establecer tamén action.destructive_requires_name: true.
• Practica o teu mecanismo de copia de seguridade e recuperación con antelación. Por exemplo, faga un script con antelación (por exemplo, en Python) que poida facer copias de seguridade e restaurar.

Primeiro lugar - "Captain Unobvious" 

Nalgún momento, observamos unha distribución desigual da carga en nginx upstream nos casos nos que había máis de 10 servidores no backend. Debido ao feito de que o round-robin enviou solicitudes do 1 ao último upstream en orde, e cada recarga de nginx comezaba de novo, os primeiros upstreams sempre recibiron máis solicitudes que o resto. Como resultado, traballaron máis lento e todo o sitio sufriu. Isto fíxose cada vez máis perceptible a medida que aumentaba a cantidade de tráfico. Simplemente actualizar nginx para activar o azar non funcionou; necesitamos refacer un montón de código lua que non despegou na versión 1.15 (nese momento). Tivemos que parchear o noso nginx 1.14.2, introducindo soporte aleatorio nel. Isto resolveu o problema. Este erro gaña a categoría "Captain Non-Obviousness".

Conclusións:

Foi moi interesante e emocionante explorar este erro). 

• Organice a súa vixilancia para que che axude a atopar esas flutuacións rapidamente. Por exemplo, pode usar ELK para supervisar os rps en cada backend de cada upstream, supervisar o seu tempo de resposta desde o punto de vista de nginx. Neste caso, isto axudounos a identificar o problema. 

Como resultado, a maioría dos fallos poderían evitarse cun enfoque máis escrupuloso do que estabas facendo. Sempre debemos lembrar a lei de Murphy: Calquera cousa que poida saír mal sairá mal, e construír compoñentes baseados nel. 

Fonte: www.habr.com