Alles goed!
Myn namme is Nikita, ik bin de teamlieder fan it Cian engineering team. Ien fan myn ferantwurdlikheden by it bedriuw is om it oantal ynsidinten yn ferbân mei ynfrastruktuer yn produksje te ferminderjen nei nul.
Wat hjirûnder besprutsen wurde brocht ús in protte pine, en it doel fan dit artikel is om te foarkommen dat oare minsken ús flaters werhelje of op syn minst har ynfloed minimalisearje.
Foaropgong
In lange tiid lyn, doe't Cian bestie út monoliten, en d'r wiene noch gjin hints fan mikrotsjinsten, mjitten wy de beskikberens fan in boarne troch 3-5 siden te kontrolearjen.
Se antwurdzje - alles is goed, as se in lange tiid net antwurdzje - alert. Hoe lang se út it wurk moasten om it as in ynsidint beskôge te wurden, waard yn gearkomsten troch minsken besletten. In team fan yngenieurs wie altyd belutsen by it ûndersyk fan it ynsidint. Doe't it ûndersyk foltôge wie, skreaunen se in postmortem - in soarte fan ferslach per e-post yn it formaat: wat barde, hoe lang duorre it, wat hawwe wy op it stuit dien, wat sille wy yn 'e takomst dwaan.
De wichtichste siden fan de side of hoe't wy begripe dat wy hawwe rekke de boaiem
Om op ien of oare manier de prioriteit fan 'e flater te begripen, hawwe wy de meast krityske sidesiden foar saaklike funksjonaliteit identifisearre. Troch se te brûken, telle wy it oantal suksesfolle / net-suksesfolle oanfragen en timeouts. Dit is hoe't wy uptime mjitte.
Litte wy sizze dat wy fûnen dat d'r in oantal super-wichtige seksjes fan 'e side binne dy't ferantwurdlik binne foar de haadtsjinst - sykjen en yntsjinje fan advertinsjes. As it oantal oanfragen dat mislearret mear as 1% is, is dit in kritysk ynsidint. As binnen 15 minuten yn 'e prime time de flaterrate 0,1% grutter is, dan wurdt dit ek beskôge as in kritysk ynsidint. Dizze kritearia dekke de measte ynsidinten; de rest lizze bûten it berik fan dit artikel.
Top bêste ynsidinten Cyan
Dat, wy hawwe perfoarst leard om it feit te bepalen dat in ynsidint barde.
No wurdt elk ynsidint yn detail beskreaun en reflektearre yn it Jira-epos. Trouwens: hjirfoar binne wy in apart projekt begûn, neamd it FAIL - allinich epos kinne wurde makke yn it.
As jo alle mislearrings yn 'e ôfrûne jierren sammelje, binne de lieders:
- mssql-relatearre ynsidinten;
- ynsidinten feroarsake troch eksterne faktoaren;
- admin flaters.
Litte wy yn mear detail sjen nei de flaters fan behearders, lykas ek guon oare nijsgjirrige mislearrings.
Fyfde plak - "Dingen yn oarder sette yn 'e DNS"
It wie in stoarmige tiisdei. Wy besletten om de oarder te herstellen yn it DNS-kluster.
Ik woe ynterne DNS-tsjinners oerdrage fan binde nei powerdns, dêrfoar folslein aparte tsjinners allocearje, wêr't neat is útsein DNS.
Wy pleatsten ien DNS-tsjinner op elke lokaasje fan ús DC's, en it momint kaam om sônes te ferpleatsen fan binde nei powerdns en de ynfrastruktuer te wikseljen nei nije servers.
Yn 'e midden fan' e ferhuzing, fan alle servers dy't waarden oantsjutte yn lokale caching bynt op alle servers, mar ien bleau, dat wie yn it datasintrum yn St. Dizze DC waard ynearsten ferklearre as net-kritysk foar ús, mar waard ynienen ien punt fan mislearring.
It wie yn dizze perioade fan ferhuzing dat it kanaal tusken Moskou en Sint-Petersburch foel. Wy wiene eins fiif minuten sûnder DNS litten en kamen werom doe't de hoster it probleem reparearre.
Konklúzjes:
As wy earder eksterne faktoaren ferwaarleazge yn 'e tarieding op wurk, no binne se ek opnommen yn' e list fan wêr't wy ús foar tariede. En no stribje wy om te soargjen dat alle komponinten reservearre binne n-2, en tidens it wurk kinne wy dit nivo nei n-1 ferleegje.
- By it opstellen fan in aksjeplan, markearje de punten wêr't de tsjinst mislearre kin, en tink troch in senario wêr't alles "fan min nei slimmer" gie.
- Fersprieden ynterne DNS-tsjinners oer ferskate geolokaasjes/datasintra/racks/switches/ynputs.
- Ynstallearje op elke tsjinner in lokale caching DNS-tsjinner, dy't fersiken omliedt nei de wichtichste DNS-tsjinners, en as it net beskikber is, sil it reagearje fanút it cache.
Fjirde plak - "De dingen yn oarder sette yn Nginx"
Op in moaie dei besleat ús team dat "wy hawwe genôch fan dit," en it proses fan refactoring nginx configs begûn. It haaddoel is om de konfiguraasjes nei in yntuïtive struktuer te bringen. Earder wie alles "histoarysk fêststeld" en hie gjin logika. No is elke server_name ferpleatst nei in bestân mei deselde namme en alle konfiguraasjes binne ferdield yn mappen. Trouwens, de konfiguraasje befettet 253949 rigels of 7836520 tekens en nimt hast 7 megabytes op. Top nivo fan struktuer:
Nginx struktuer
├── 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.confIt waard folle better, mar yn it proses fan it omneamen en fersprieden fan konfiguraasjes hienen guon fan harren de ferkearde útwreiding en waarden net opnommen yn 'e include *.conf-rjochtline. As gefolch, guon hosts waarden net beskikber en werom 301 nei de haadside. Trochdat de antwurdkoade net 5xx/4xx wie, waard dat net daliks opmurken, mar allinnich moarns. Dêrnei begûnen wy tests te skriuwen om ynfrastruktuerkomponinten te kontrolearjen.
Konklúzjes:
- Strukturearje jo konfiguraasjes korrekt (net allinich nginx) en tink troch de struktuer yn in ier stadium fan it projekt. Op dizze manier sille jo se mear begryplik meitsje foar it team, wat op syn beurt TTM sil ferminderje.
- Skriuw tests foar guon ynfrastruktuerkomponinten. Bygelyks: kontrolearje dat alle kaai server_names de juste status + antwurd lichem jouwe. It sil genôch wêze om gewoan in pear skripts oan 'e hân te hawwen dy't de basisfunksjes fan' e komponint kontrolearje, om net om 3 oere frentysk te ûnthâlden wat oars moat wurde kontrolearre.
Tredde plak - "Ynienen rûn út romte yn Cassandra"
De gegevens groeiden stadichoan, en alles wie goed oant it momint doe't de reparaasje fan grutte kofferromten begon te mislearjen yn 'e Cassandra-kluster, om't kompaktjen der net op koe wurkje.
Op in stoarmige dei feroare de kluster hast yn in pompoen, nammentlik:
- der wie oer 20% fan de totale romte oerbleaun yn it kluster;
- It is ûnmooglik om knooppunten folslein ta te foegjen, om't skjinmeitsjen net trochgiet nei it tafoegjen fan in knooppunt troch gebrek oan romte op 'e partysjes;
- produktiviteit sakket stadichoan as kompaktjen net wurket;
- It kluster is yn needmodus.
Utgong - wy hawwe 5 mear knopen tafoege sûnder skjinmeitsjen, wêrnei't wy se systematysk begûnen te ferwiderjen fan it kluster en opnij ynfiere, lykas lege knopen dy't gjin romte hiene. Der waard folle mear tiid bestege as wy wolle. Der wie in risiko fan in part of folsleine net-beskikberens fan it kluster.
Konklúzjes:
- Op alle cassandra-tsjinners moat net mear as 60% fan 'e romte op elke partysje beset wurde.
- Se moatte wurde laden op net mear as 50% cpu.
- Jo moatte net ferjitte oer kapasiteitsplanning en moatte it trochtinke foar elke komponint, basearre op har spesifikaasjes.
- Hoe mear knopen yn it kluster, hoe better. Servers dy't in lytse hoemannichte gegevens befetsje, wurde rapper oerladen, en sa'n kluster is makliker te wekken.
Twadde plak - "Gegevens ferdwûn út konsul kaai-wearde opslach"
Foar ûntdekking fan tsjinsten brûke wy, lykas in protte, konsul. Mar wy brûke ek syn kaai-wearde foar blau-griene yndieling fan 'e monolith. It bewarret ynformaasje oer aktive en ynaktive streamopstreamen, dy't plak feroarje by ynset. Dêrfoar is in ynsettsjinst skreaun dy't omgie mei KV. Op in stuit ferdwûnen de gegevens fan KV. Restaurearre út it ûnthâld, mar mei in oantal flaters. As gefolch, tidens de upload, waard de lading op 'e upstreams unjildich ferdield, en wy krigen in protte 502-flaters fanwegen de efterkanten dy't oerladen waarden op' e CPU. Dêrtroch ferhuze wy fan konsul KV nei postgres, dêr't it net mear sa maklik is om se fuort te heljen.
Konklúzjes:
- Tsjinsten sûnder autorisaasje moatte gjin gegevens befetsje dy't kritysk binne foar de wurking fan 'e side. Bygelyks, as jo gjin autorisaasje yn ES, it soe wêze better te wegerje tagong op it netwurk nivo fan oeral dêr't it is net nedich, lit allinne de nedige, en ek set action.destructive_requires_name: wier.
- Oefenje jo reservekopy- en herstelmeganisme foarôf. Meitsje bygelyks foarôf in skript (bygelyks yn python) dat kin reservekopy en weromsette.
Earste plak - "Captain Unobvious"
Op in stuit hawwe wy in unjildige ferdieling fan load op nginx-upstreams opmurken yn gefallen wêr't d'r 10+ servers yn 'e efterkant wiene. Troch it feit dat round-robin fersiken stjoerde fan 1e nei de lêste streamop yn oarder, en elke nginx reload begon oer, krigen de earste upstreams altyd mear oanfragen as de rest. As gefolch, se wurken stadiger en de hiele side lijen. Dat waard hieltyd merkber neidat de hoemannichte ferkear tanaam. It gewoan bywurkjen fan nginx om willekeurich yn te skeakeljen wurke net - wy moatte in boskje lua-koade opnij meitsje dy't net op 'e ferzje 1.15 (op dat stuit) kaam. Wy moasten ús nginx 1.14.2 patchje, en dêryn willekeurige stipe yntrodusearje. Dit loste it probleem op. Dizze brek wint de kategory "Kaptein Non-Obviousness".
Konklúzjes:
It wie heul ynteressant en spannend om dizze brek te ferkennen).
- Organisearje jo tafersjoch sadat it jo helpt om sokke fluktuaasjes fluch te finen. Jo kinne bygelyks ELK brûke om rps op elke efterkant fan elke streamop te kontrolearjen, har reaksjetiid te kontrolearjen út it eachpunt fan nginx. Yn dit gefal holp dit ús it probleem te identifisearjen.
As gefolch, de measte fan 'e mislearrings koenen wurde mijd mei in mear scrupulous oanpak fan wat jo diene. Wy moatte altyd de wet fan Murphy ûnthâlde: Alles wat ferkeard gean kin, sil ferkeard gean, en bouwe komponinten basearre op it.
Boarne: www.habr.com