Top fakapov Cyan

Molt bé a tots! 

Em dic Nikita, sóc la líder de l'equip d'enginyeria de Cian. Una de les meves responsabilitats a l'empresa és reduir a zero el nombre d'incidències relacionades amb la infraestructura en producció.
El que es comentarà a continuació ens va causar molt de dolor, i l'objectiu d'aquest article és evitar que altres persones repeteixin els nostres errors o, almenys, minimitzin el seu impacte. 

Preàmbul

Fa molt de temps, quan Cian constava de monòlits i encara no hi havia indicis de microserveis, vam mesurar la disponibilitat d'un recurs comprovant entre 3 i 5 pàgines. 

Responen: tot està bé, si no responen durant molt de temps, alerta. Quant de temps havien d'estar fora de la feina perquè es considerés un incident, la gent decidia a les reunions. Un equip d'enginyers sempre va participar en la investigació de l'incident. Quan es va acabar la investigació, van escriure una autopsia: una mena d'informe per correu electrònic en el format: què va passar, quant de temps va durar, què vam fer en aquest moment, què farem en el futur. 

Les pàgines principals del lloc o com entenem que hem tocat el fons

 
Per tal d'entendre d'alguna manera la prioritat de l'error, hem identificat les pàgines del lloc més crítiques per a la funcionalitat empresarial. Utilitzant-los, comptem el nombre de sol·licituds i temps d'espera reeixits/no reeixits. Així és com mesurem el temps de funcionament. 

Suposem que hem descobert que hi ha una sèrie de seccions molt importants del lloc que són responsables del servei principal: cercar i enviar anuncis. Si el nombre de sol·licituds fallides supera l'1%, es tracta d'un incident crític. Si en 15 minuts durant el prime time la taxa d'error supera el 0,1%, també es considera un incident crític. Aquests criteris cobreixen la majoria de les incidències, la resta queden fora de l'abast d'aquest article.

Top millors incidents Cyan

Per tant, definitivament hem après a determinar el fet que va passar un incident. 

Ara cada incident es descriu amb detall i es reflecteix a l'èpica Jira. Per cert: per això vam iniciar un projecte separat, anomenat FAIL: només es poden crear èpiques en ell. 

Si reculls tots els errors dels últims anys, els líders són: 

• incidents relacionats amb mssql;
• incidents causats per factors externs;
• errors d'administració.

Vegem amb més detall els errors dels administradors, així com alguns altres errors interessants.

Cinquè lloc - "Posar les coses en ordre al DNS"

Va ser un dimarts de tempesta. Vam decidir restaurar l'ordre al clúster DNS. 

Volia transferir servidors DNS interns de bind a powerdns, assignant servidors completament separats per a això, on no hi ha res excepte DNS. 

Vam col·locar un servidor DNS a cada ubicació dels nostres DC, i va arribar el moment de traslladar les zones de bind a powerdns i canviar la infraestructura a nous servidors. 

Enmig de la mudança, de tots els servidors que s'especificaven en els enllaços de memòria cau local a tots els servidors, només en quedava un, que era al centre de dades de Sant Petersburg. Aquest DC es va declarar inicialment no crític per a nosaltres, però de sobte es va convertir en un únic punt de fracàs.
Va ser durant aquest període de trasllat que el canal entre Moscou i Sant Petersburg va caure. En realitat, ens vam quedar sense DNS durant cinc minuts i vam tornar a aixecar-nos quan l'amfitrió va solucionar el problema. 

Conclusions:

Si abans descuidàvem els factors externs durant la preparació per al treball, ara també s'inclouen a la llista del que estem preparant. I ara ens esforcem per garantir que tots els components estiguin reservats n-2, i durant el treball podem baixar aquest nivell a n-1.

• A l'hora d'elaborar un pla d'acció, marqueu els punts en què el servei podria fallar i penseu amb antelació en un escenari en què tot va anar "de mal en pitjor".
• Distribuïu servidors DNS interns a diferents geolocalitzacions/centres de dades/racks/interruptors/entrades.
• A cada servidor, instal·leu un servidor DNS de memòria cau local, que redirigeix ​​les sol·licituds als servidors DNS principals i, si no està disponible, respondrà des de la memòria cau. 

Quart lloc: "Posar ordre a Nginx"

Un bon dia, el nostre equip va decidir que "ja n'hem tingut prou" i va començar el procés de refactorització de les configuracions de nginx. L'objectiu principal és portar les configuracions a una estructura intuïtiva. Abans, tot estava “històricament establert” i no portava cap lògica. Ara, cada nom_server s'ha mogut a un fitxer del mateix nom i totes les configuracions s'han distribuït en carpetes. Per cert, la configuració conté 253949 línies o 7836520 caràcters i ocupa gairebé 7 megabytes. Nivell superior d'estructura: 

Estructura 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

Va ser molt millor, però en el procés de canviar el nom i distribuir les configuracions, algunes d'elles tenien l'extensió incorrecta i no estaven incloses a la directiva include *.conf. Com a resultat, alguns amfitrions no van estar disponibles i van tornar 301 a la pàgina principal. A causa del fet que el codi de resposta no era 5xx/4xx, això no es va notar immediatament, sinó només al matí. Després d'això, vam començar a escriure proves per comprovar els components de la infraestructura.

Conclusions: 

• Estructureu les vostres configuracions correctament (no només nginx) i penseu en l'estructura en una fase inicial del projecte. D'aquesta manera, els faràs més entenedors per a l'equip, que al seu torn reduirà el TTM.
• Escriu proves per a alguns components de la infraestructura. Per exemple: comprovar que tots els noms_server clau donen l'estat correcte + el cos de la resposta. N'hi haurà prou amb tenir uns quants scripts a mà que comproven les funcions bàsiques del component, per no recordar frenèticament a les 3 a.m. què més cal comprovar. 

Tercer lloc: "De sobte es va quedar sense espai a Cassandra"

Les dades van créixer constantment i tot va anar bé fins al moment en què la reparació de grans espais va començar a fallar al clúster Cassandra, perquè la compactació no podia funcionar en ells. 

Un dia de tempesta, el cúmul gairebé es va convertir en una carbassa, és a dir:

• quedava al voltant del 20% de l'espai total al clúster;
• És impossible afegir nodes completament, perquè la neteja no es realitza després d'afegir un node a causa de la manca d'espai a les particions;
• la productivitat disminueix gradualment a mesura que la compactació no funciona; 
• El clúster està en mode d'emergència.

Sortida: vam afegir 5 nodes més sense netejar, després de la qual cosa vam començar a eliminar-los sistemàticament del clúster i tornar-hi a entrar, com nodes buits que s'havien quedat sense espai. Vam passar molt més temps del que voldríem. Hi havia un risc de no disponibilitat parcial o total del clúster. 

Conclusions:

• En tots els servidors Cassandra, no s'ha d'ocupar més del 60% de l'espai de cada partició. 
• S'han de carregar a no més del 50% de CPU.
• No us heu d'oblidar de la planificació de la capacitat i heu de pensar-ho bé per a cada component, en funció de les seves especificitats.
• Com més nodes al clúster, millor. Els servidors que contenen una petita quantitat de dades es sobrecarreguen més ràpidament i aquest clúster és més fàcil de reviure. 

Segon lloc: "Les dades van desaparèixer de l'emmagatzematge del valor-clau del cònsol"

Per a la descoberta de serveis, nosaltres, com molts, utilitzem cònsol. Però també fem servir el seu valor-clau per al disseny blau-verd del monòlit. Emmagatzema informació sobre aigües amunt actives i inactives, que canvien de lloc durant el desplegament. Amb aquesta finalitat, es va escriure un servei de desplegament que interactua amb KV. En algun moment, les dades de KV van desaparèixer. Restaurat des de la memòria, però amb una sèrie d'errors. Com a resultat, durant la càrrega, la càrrega a les aigües amunt es va distribuir de manera desigual i vam rebre molts errors 502 a causa de la sobrecàrrega dels backends a la CPU. Com a resultat, vam passar de cònsol KV a postgres, d'on ja no és tan fàcil eliminar-los.  

Conclusions:

• Els serveis sense cap autorització no haurien de contenir dades crítiques per al funcionament del lloc. Per exemple, si no teniu autorització a ES, seria millor negar l'accés a nivell de xarxa des de qualsevol lloc on no sigui necessari, deixar només les necessàries i també establir action.destructive_requires_name: true.
• Practiqueu el vostre mecanisme de còpia de seguretat i recuperació amb antelació. Per exemple, feu un script per endavant (per exemple, en Python) que pugui fer una còpia de seguretat i restaurar-lo.

Primer lloc - "Capità Unobvious" 

En algun moment, vam notar una distribució desigual de la càrrega a nginx aigües amunt en els casos en què hi havia més de 10 servidors al backend. A causa del fet que el round-robin enviava sol·licituds de l'1 a l'últim en ordre, i cada recàrrega de nginx començava de nou, els primers upstreams sempre van rebre més sol·licituds que la resta. Com a resultat, van funcionar més lentament i tot el lloc va patir. Això es va fer cada cop més notable a mesura que augmentava la quantitat de trànsit. Simplement actualitzar nginx per habilitar l'atzar no va funcionar: hem de tornar a fer un munt de codi lua que no va sortir a la versió 1.15 (en aquell moment). Vam haver de pegar el nostre nginx 1.14.2, introduint-hi suport aleatori. Això va resoldre el problema. Aquest error guanya la categoria "Capità no obvietat".

Conclusions:

Va ser molt interessant i emocionant explorar aquest error). 

• Organitzeu el vostre seguiment perquè us ajudi a trobar aquestes fluctuacions ràpidament. Per exemple, podeu utilitzar ELK per controlar els rps a cada backend de cada aigües amunt, controlar el seu temps de resposta des del punt de vista de nginx. En aquest cas, això ens va ajudar a identificar el problema. 

Com a resultat, la majoria dels fracassos es podrien haver evitat amb un enfocament més escrupolós del que estàveu fent. Sempre hem de recordar la llei de Murphy: Qualsevol cosa que pugui sortir malament anirà malament, i construir components basats en això. 

Font: www.habr.com