Bon à tutti!
Mi chjamu Nikita, sò u capu di a squadra di a squadra di l'ingegneria Cian. Una di e mo rispunsabilità in a cumpagnia hè di riduce u numeru di incidenti ligati à l'infrastruttura in a pruduzzione à zero.
Ciò chì serà discutitu quì sottu ci hà purtatu assai dulore, è u scopu di questu articulu hè di impedisce à l'altri persone di ripetiri i nostri sbagli o almenu minimizzà u so impattu.
Preamble
Un bellu tempu fà, quandu Cian era custituitu di monoliti, è ùn ci era ancu micca suggerimenti di microservices, avemu misuratu a dispunibilità di una risorsa cuntrollandu 3-5 pagine.
Rispundenu - tuttu hè bè, s'ellu ùn risponde micca per un bellu pezzu - alerta. Quantu tempu avianu da esse fora di u travagliu per esse cunsideratu un incidente hè statu decisu da e persone in riunioni. Una squadra di ingegneri era sempre implicata in l'investigazione di l'incidentu. Quandu l'inchiesta hè stata finita, anu scrittu un postmortem - un tipu di rapportu per email in u formatu: ciò chì hè accadutu, quantu durò, ciò chì avemu fattu in u mumentu, ciò chì faremu in u futuru.
E pagine principali di u situ o cumu avemu capitu chì avemu toccu u fondu
In modu di capiscenu a priorità di l'errore, avemu identificatu e pagine di u situ più critichi per a funziunalità cummerciale. Aduprà elli, cuntemu u numeru di dumande successu / senza successu è timeout. Questu hè cumu si misurà u uptime.
Dicemu chì avemu scupertu chì ci sò una quantità di rùbbriche super-impurtanti di u situ chì sò rispunsevuli di u serviziu principale - ricerca è sottumessu publicità. Se u numeru di richieste chì fallenu supera u 1%, questu hè un incidente criticu. Se in 15 minuti durante u prime time a rata di errore supera u 0,1%, allora questu hè ancu cunsideratu un incidente criticu. Questi criteri coprenu a maiò parte di l'incidenti; u restu hè fora di u scopu di stu articulu.
Top best incidenti Cian
Dunque, avemu certamente amparatu à determinà u fattu chì un incidente hè accadutu.
Avà ogni incidente hè descrittu in dettagliu è riflessu in l'epica Jira. In modu: per questu avemu principiatu un prughjettu separatu, chjamatu FAIL - solu l'epica pò esse creatu in questu.
Se cullate tutti i fallimenti in l'ultimi anni, i capi sò:
- incidenti legati à mssql;
- incidenti causati da fattori esterni;
- errori di amministratore.
Fighjemu in più in detail i sbagli di l'amministratori, è ancu qualchì altru fallimentu interessante.
Quintu postu - "Mettà e cose in ordine in u DNS"
Era un marti di tempesta. Avemu decisu di restaurà l'ordine in u cluster DNS.
Vuliu trasfiriri i servitori DNS interni da bind à powerdns, assignendu servitori completamente separati per questu, induve ùn ci hè nunda, salvu DNS.
Avemu piazzatu un servitore DNS in ogni locu di i nostri DC, è u mumentu hè ghjuntu per spustà e zone da u ligame à i powerdns è cambià l'infrastruttura à novi servitori.
In u mezu di u muvimentu, di tutti i servitori chì anu specificatu in caching locale ligami nantu à tutti i servitori, solu unu restava, chì era in u centru di dati in San Petruburgu. Stu DC hè statu inizialmente dichjaratu cum'è micca criticu per noi, ma di colpu hè diventatu un unicu puntu di fallimentu.
Hè durante stu periodu di traslocazione chì u canali trà Mosca è San Petruburgu cascò. In realtà, ci sò stati lasciati senza DNS per cinque minuti è si sò tornati quandu l'hoster hà risoltu u prublema.
Conclusioni:
Se prima avemu trascuratatu fatturi esterni durante a preparazione per u travagliu, avà sò ancu inclusi in a lista di ciò chì avemu preparatu. È avà strivemu per assicurà chì tutti i cumpunenti sò riservati n-2, è durante u travagliu pudemu calà stu livellu à n-1.
- Quandu si stabilisce un pianu d'azzione, marcate i punti induve u serviziu pò fallu, è pensate à un scenariu induve tuttu hè andatu "da u male à u peghju" in anticipu.
- Distribuite i servitori DNS interni in diverse geolocazioni / centri di dati / rack / switch / inputs.
- In ogni servitore, installate un servitore DNS di caching locale, chì redirige e dumande à i servitori DNS principali, è s'ellu ùn hè micca dispunibule, risponderà da u cache.
Quartu postu - "Mettà e cose in ordine in Nginx"
Un bellu ghjornu, a nostra squadra hà decisu chì "avemu avutu abbastanza di questu", è u prucessu di refactoring nginx configs hà iniziatu. U scopu principale hè di portà i cunfigurazioni in una struttura intuitiva. Nanzu, tuttu era "storicu stabilitu" è ùn portava nisuna logica. Avà ogni server_name hè statu spustatu in un schedariu di u stessu nome è tutte e cunfigurazioni sò state distribuite in cartulare. A strada, a cunfigurazione cuntene 253949 linee o 7836520 caratteri è occupa quasi 7 megabytes. U livellu più altu di a struttura:
Struttura 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.confHè diventatu assai megliu, ma in u prucessu di rinominazione è distribuzione di cunfigurazioni, alcuni di elli avianu l'estensione sbagliata è ùn eranu micca inclusi in a direttiva include *.conf. In u risultatu, certi òspiti ùn sò micca dispunibili è tornanu 301 à a pagina principale. A causa di u fattu chì u codice di risposta ùn era micca 5xx / 4xx, questu ùn hè micca nutatu immediatamente, ma solu in a matina. Dopu quì, avemu cuminciatu à scrive testi per verificà i cumpunenti di l'infrastruttura.
Conclusioni:
- Strutturate e vostre cunfigurazioni currettamente (micca solu nginx) è pensate à a struttura in una prima fase di u prugettu. In questu modu, li farà più comprensibili à a squadra, chì à u turnu riducerà TTM.
- Scrivite testi per certi cumpunenti di l'infrastruttura. Per esempiu: cuntrollà chì tutte e chjave server_names dà u statu currettu + corpu di risposta. Sarà abbastanza à avè uni pochi di script in manu chì verificate e funzioni basi di u cumpunente, per ùn ricurdà freneticamente à 3 a.m. chì altru deve esse verificatu.
Terzu postu - "Subbitumente hà scappatu u spaziu in Cassandra"
I dati crescenu in modu fermu, è tuttu era bè finu à u mumentu chì a riparazione di grande casespaces hà cuminciatu à fallu in u cluster Cassandra, perchè a compactazione ùn pudia micca travaglià nantu à elli.
Un ghjornu di tempesta, u cluster hè quasi diventatu una zucca, à dì:
- ci era circa 20% di u spaziu tutale lasciatu in u cluster;
- Hè impussibile di aghjunghje node cumplettamente, perchè a pulizia ùn passa micca dopu à aghjunghje un node per mancanza di spaziu nantu à e partizioni;
- a produtividade diminuisce gradualmente cum'è a compactazione ùn viaghja micca;
- U cluster hè in modu di emergenza.
Esci - avemu aghjustatu 5 nodi più senza pulizia, dopu avemu cuminciatu à caccià sistematicamente da u cluster è rientra in elli, cum'è nodi vacanti chì anu scappatu di u spaziu. Ci hè statu passatu assai più tempu di ciò chì vuleriamu. Ci era un risicu di indisponibilità parziale o cumpleta di u cluster.
Conclusioni:
- In tutti i servitori Cassandra, ùn deve esse occupatu più di 60% di u spaziu nantu à ogni partizione.
- Anu deve esse caricate à micca più di 50% cpu.
- Ùn deve micca scurdate di a pianificazione di capacità è bisognu di pensà à ogni cumpunente, basatu annantu à i so specifichi.
- U più nodi in u cluster, u megliu. I servitori chì cuntenenu una piccula quantità di dati sò sopracargati più veloce, è un tali cluster hè più faciule per rinviviscia.
Secondu postu - "Dati spariti da l'almacenamiento di chjave-valore di consul"
Per a scuperta di serviziu, noi, cum'è parechji, usemu cunsul. Ma avemu ancu aduprà u so valore chjave per u layout blu-verde di u monolitu. Immagazzina l'infurmazioni nantu à i upstreams attivi è inattivi, chì cambianu i posti durante a implementazione. Per questu scopu, hè statu scrittu un serviziu di implementazione chì interagisce cù KV. À un certu puntu, i dati da KV sò spariti. Resturatu da a memoria, ma cù una quantità di errori. In u risultatu, durante l'upload, a carica nantu à l'upstreams hè stata distribuita in modu irregulare, è avemu ricevutu parechji errori 502 per via di i backends chì sò sopracargati in u CPU. In u risultatu, avemu passatu da u consul KV à u postgres, da induve ùn hè più cusì faciule per sguassà.
Conclusioni:
- I servizii senza alcuna autorizazione ùn deve micca cuntene dati critichi per u funziunamentu di u situ. Per esempiu, sè ùn avete micca l'autorizazione in ES, saria megliu nigà l'accessu à u livellu di a reta da ogni locu induve ùn hè micca necessariu, lasciate solu i necessarii, è ancu stabilisce action.destructive_requires_name: true.
- Praticate u vostru mecanismu di salvezza è ricuperazione in anticipu. Per esempiu, fate un script in anticipu (per esempiu, in python) chì pò salvà è restaurà.
Primu postu - "Captain Unobvious"
À un certu puntu, avemu nutatu una distribuzione irregulare di carica in nginx upstreams in i casi induve ci era 10+ servitori in u backend. A causa di u fattu chì u round-robin hà mandatu dumande da u 1u à l'ultimu upstream in ordine, è ogni nginx reload hà cuminciatu, i primi upstreams sempre ricivutu più richieste di u restu, in u risultatu, travagliavanu più lentamente è tuttu u situ hà patitu. Questu hè diventatu sempre più notu cum'è a quantità di trafficu aumentava. Simply l'aghjurnamentu di nginx per attivà l'aleatoriu ùn hà micca travagliatu - avemu bisognu di ripiglià una mansa di codice lua chì ùn hà micca sbulicatu in a versione 1.15 (in quellu mumentu). Avemu avutu à patch u nostru nginx 1.14.2, intruducendu un supportu aleatoriu in questu. Questu hà risoltu u prublema. Stu bug vince a categuria "Captain Non-Obviousness".
Conclusioni:
Era assai interessante è eccitante per spiegà stu bug).
- Organizzate u vostru monitoraghju in modu chì vi aiuta à truvà tali fluttuazioni rapidamente. Per esempiu, pudete aduprà ELK per monitorà rps in ogni backend di ogni upstream, monitorizà u so tempu di risposta da u puntu di vista di nginx. In questu casu, questu ci hà aiutatu à identificà u prublema.
In u risultatu, a maiò parte di i fallimenti puderia esse evitata cù un accostu più scrupulous à ciò chì facia. Avemu da ricurdà sempre a lege di Murphy: Qualchese chì pò sbaglià andarà male, è custruisce cumpunenti basatu annantu à questu.
Source: www.habr.com