Goed vir almal!
My naam is Nikita, ek is die spanleier van die Cian-ingenieurspan. Een van my verantwoordelikhede by die maatskappy is om die aantal voorvalle wat verband hou met infrastruktuur in produksie tot nul te verminder.
Wat hieronder bespreek sal word, het vir ons baie pyn gebring, en die doel van hierdie artikel is om te verhoed dat ander mense ons foute herhaal of ten minste hul impak tot die minimum beperk.
aanhef
Lank gelede, toe Cian uit monoliete bestaan het, en daar nog geen sweempies van mikrodienste was nie, het ons die beskikbaarheid van 'n hulpbron gemeet deur 3-5 bladsye na te gaan.
Hulle antwoord - alles is in orde, as hulle vir 'n lang tyd nie antwoord nie - waaksaam. Hoe lank hulle van die werk af moes wees om dit as 'n voorval te beskou, is deur mense in vergaderings besluit. ’n Span ingenieurs was altyd by die ondersoek na die voorval betrokke. Toe die ondersoek afgehandel is, het hulle ’n nadoodse ondersoek geskryf – ’n soort verslag per e-pos in die formaat: wat het gebeur, hoe lank dit aangehou het, wat ons in die oomblik gedoen het, wat ons in die toekoms gaan doen.
Die hoofbladsye van die webwerf of hoe ons verstaan dat ons die onderkant getref het
Om op een of ander manier die prioriteit van die fout te verstaan, het ons die mees kritieke werfbladsye vir besigheidsfunksionaliteit geïdentifiseer. Deur dit te gebruik, tel ons die aantal suksesvolle/onsuksesvolle versoeke en uitteltyd. Dit is hoe ons uptyd meet.
Kom ons sê ons het uitgevind dat daar 'n aantal super-belangrike afdelings van die webwerf is wat verantwoordelik is vir die hoofdiens - soek en indiening van advertensies. As die aantal versoeke wat misluk 1% oorskry, is dit 'n kritieke voorval. As die foutkoers binne 15 minute gedurende spitstyd 0,1% oorskry, word dit ook as 'n kritieke voorval beskou. Hierdie kriteria dek die meeste van die voorvalle; die res is buite die bestek van hierdie artikel.
Top beste voorvalle Cyan
So, ons het beslis geleer om die feit te bepaal dat 'n voorval gebeur het.
Nou word elke voorval in detail beskryf en in die Jira-epos weerspieël. Terloops: hiervoor het ons 'n aparte projek begin, dit FAIL genoem - slegs eposse kan daarin geskep word.
As jy al die mislukkings oor die afgelope paar jaar versamel, is die leiers:
- mssql-verwante voorvalle;
- voorvalle veroorsaak deur eksterne faktore;
- admin foute.
Kom ons kyk in meer besonderhede na die foute van administrateurs, sowel as 'n paar ander interessante mislukkings.
Vyfde plek - "Om dinge in orde te stel in die DNS"
Dit was 'n stormagtige Dinsdag. Ons het besluit om orde in die DNS-groepering te herstel.
Ek wou interne DNS-bedieners van bind na powerdns oordra, en heeltemal aparte bedieners hiervoor toewys, waar daar niks behalwe DNS is nie.
Ons het een DNS-bediener op elke plek van ons DC's geplaas, en die oomblik het aangebreek om sones van bind na powerdns te skuif en die infrastruktuur na nuwe bedieners oor te skakel.
Te midde van die skuif, van al die bedieners wat gespesifiseer is in plaaslike caching bind op alle bedieners, het net een oorgebly, wat in die datasentrum in St. Petersburg was. Hierdie DC is aanvanklik vir ons as nie-krities verklaar, maar het skielik 'n enkele punt van mislukking geword.
Dit was gedurende hierdie tydperk van hervestiging dat die kanaal tussen Moskou en St. Petersburg geval het. Ons was eintlik vir vyf minute sonder DNS gelaat en het weer opgestaan toe die gasheer die probleem opgelos het.
Gevolgtrekkings:
As ons vroeër eksterne faktore afgeskeep het tydens voorbereiding vir werk, is hulle nou ook ingesluit in die lys waarvoor ons voorberei. En nou streef ons daarna om te verseker dat alle komponente gereserveer is n-2, en tydens die werk kan ons hierdie vlak verlaag na n-1.
- Wanneer jy ’n aksieplan opstel, merk die punte waar die diens kan misluk, en dink vooraf deur ’n scenario waar alles “van sleg tot erger” gegaan het.
- Versprei interne DNS-bedieners oor verskillende geoliggings/datasentrums/rakke/skakelaars/insette.
- Installeer 'n plaaslike kas-DNS-bediener op elke bediener, wat versoeke na die hoof-DNS-bedieners herlei, en as dit nie beskikbaar is nie, sal dit vanaf die kas reageer.
Vierde plek - "Om dinge in orde te stel in Nginx"
Op 'n mooi dag het ons span besluit dat "ons het genoeg hiervan gehad," en die proses van herfaktorering van nginx-konfigurasies het begin. Die hoofdoel is om die konfigurasies na 'n intuïtiewe struktuur te bring. Voorheen was alles “histories vasgestel” en het geen logika gedra nie. Nou is elke bedienernaam na 'n lêer met dieselfde naam geskuif en alle konfigurasies is in dopgehou versprei. Terloops, die konfigurasie bevat 253949 reëls of 7836520 karakters en neem byna 7 megagrepe op. Topvlak van struktuur:
Nginx struktuur
├── 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.confDit het baie beter geword, maar in die proses om konfigurasies te hernoem en te versprei, het sommige van hulle die verkeerde uitbreiding gehad en is nie ingesluit in die include *.conf-direktief nie. Gevolglik het sommige gashere onbeskikbaar geraak en 301 na die hoofblad teruggekeer. Weens die feit dat die reaksiekode nie 5xx/4xx was nie, is dit nie dadelik opgemerk nie, maar eers in die oggend. Daarna het ons begin toetse skryf om infrastruktuurkomponente na te gaan.
Gevolgtrekkings:
- Struktureer jou konfigurasies korrek (nie net nginx nie) en dink deur die struktuur in 'n vroeë stadium van die projek. Op hierdie manier sal jy hulle meer verstaanbaar maak vir die span, wat op sy beurt TTM sal verminder.
- Skryf toetse vir sommige infrastruktuurkomponente. Byvoorbeeld: kontroleer dat alle sleutelbedienername die korrekte status + antwoordliggaam gee. Dit sal genoeg wees om net 'n paar skrifte byderhand te hê wat die basiese funksies van die komponent nagaan, om nie woes om 3:XNUMX te onthou wat nog gekontroleer moet word nie.
Derde plek - "Skielik het spasie in Cassandra opgeraak"
Die data het geleidelik gegroei, en alles was in orde tot die oomblik toe die herstel van groot kasruimtes in die Cassandra-groep begin misluk het, omdat verdigting nie daarop kon werk nie.
Een stormagtige dag het die tros amper in 'n pampoen verander, naamlik:
- daar was ongeveer 20% van die totale spasie in die tros oor;
- Dit is onmoontlik om nodusse volledig by te voeg, want opruiming gaan nie deur nadat 'n nodus bygevoeg is nie weens 'n gebrek aan spasie op die partisies;
- produktiwiteit daal geleidelik namate verdigting nie werk nie;
- Die groep is in noodmodus.
Verlaat - ons het nog 5 nodusse bygevoeg sonder opruiming, waarna ons hulle stelselmatig uit die groep begin verwyder het en hulle weer binnegaan, soos leë nodusse wat nie meer spasie gehad het nie. Baie meer tyd is spandeer as wat ons sou wou hê. Daar was 'n risiko van gedeeltelike of volledige onbeskikbaarheid van die groepering.
Gevolgtrekkings:
- Op alle Cassandra-bedieners moet nie meer as 60% van die spasie op elke partisie beset word nie.
- Hulle moet nie meer as 50% cpu gelaai word nie.
- Jy moet nie van kapasiteitsbeplanning vergeet nie en moet dit deurdink vir elke komponent, gebaseer op sy besonderhede.
- Hoe meer nodusse in die groepie, hoe beter. Bedieners wat 'n klein hoeveelheid data bevat, word vinniger oorlaai, en so 'n groep is makliker om te laat herleef.
Tweede plek - "Data het uit konsul-sleutelwaardeberging verdwyn"
Vir diensontdekking gebruik ons, soos baie, konsul. Maar ons gebruik ook die sleutelwaarde daarvan vir blougroen uitleg van die monoliet. Dit stoor inligting oor aktiewe en onaktiewe stroomop, wat van plek verander tydens ontplooiing. Vir hierdie doel is 'n ontplooiingsdiens geskryf wat in wisselwerking met KV was. Op 'n stadium het die data van KV verdwyn. Uit die geheue herstel, maar met 'n aantal foute. As gevolg hiervan, tydens die oplaai, is die las op die stroomopwaarts oneweredig versprei, en ons het baie 502-foute ontvang as gevolg van die agterkant wat op die SVE oorlaai is. Gevolglik het ons van konsul KV na postgres geskuif, vanwaar dit nie meer so maklik is om hulle te verwyder nie.
Gevolgtrekkings:
- Dienste sonder enige magtiging moet nie data bevat wat krities is vir die werking van die webwerf nie. As jy byvoorbeeld nie magtiging in ES het nie, sal dit beter wees om toegang op netwerkvlak van oral waar dit nie nodig is nie te weier, net die nodige te laat, en ook action.destructive_requires_name: true in te stel.
- Oefen jou rugsteun- en herstelmeganisme vooraf. Maak byvoorbeeld vooraf 'n skrif (byvoorbeeld in python) wat kan rugsteun en herstel.
Eerste plek - “Captain Unobvious”
Op 'n stadium het ons 'n ongelyke verspreiding van las op nginx-stroomop opgemerk in gevalle waar daar 10+ bedieners in die agterkant was. As gevolg van die feit dat round-robin versoeke van 1ste tot die laaste stroomop in volgorde gestuur het, en elke nginx herlaai begin oor het, het die eerste stroomops altyd meer versoeke as die res ontvang.Gevolglik het hulle stadiger gewerk en die hele werf het daaronder gely. Dit het al hoe meer opvallend geword namate die hoeveelheid verkeer toegeneem het. Om net nginx op te dateer om ewekansig te aktiveer, het nie gewerk nie - ons moet 'n klomp lua-kode oordoen wat nie op weergawe 1.15 (op daardie oomblik) opgestyg het nie. Ons moes ons nginx 1.14.2 pleister, deur ewekansige ondersteuning daarin in te voer. Dit het die probleem opgelos. Hierdie gogga wen die kategorie "Kaptein Non-Obviousness".
Gevolgtrekkings:
Dit was baie interessant en opwindend om hierdie gogga te verken).
- Organiseer jou monitering sodat dit jou help om sulke skommelinge vinnig te vind. Byvoorbeeld, jy kan ELK gebruik om rps op elke agterkant van elke stroomop te monitor, hul reaksietyd te monitor vanuit die oogpunt van nginx. In hierdie geval het dit ons gehelp om die probleem te identifiseer.
Gevolglik kon die meeste van die mislukkings vermy gewees het met 'n meer noukeurige benadering tot wat jy doen. Ons moet altyd Murphy se wet onthou: Enigiets wat verkeerd kan gaan, sal verkeerd gaan, en bou komponente op grond daarvan.
Bron: will.com