టాప్ ఫకపోవ్ సియాన్

అంతా మంచిదే! 

నా పేరు నికితా, నేను సియాన్ ఇంజినీరింగ్ టీమ్ టీమ్ లీడర్‌ని. ఉత్పత్తిలో మౌలిక సదుపాయాలకు సంబంధించిన సంఘటనల సంఖ్యను సున్నాకి తగ్గించడం కంపెనీలో నా బాధ్యతలలో ఒకటి.
దిగువ చర్చించబడేది మాకు చాలా బాధను కలిగించింది మరియు ఇతర వ్యక్తులు మన తప్పులను పునరావృతం చేయకుండా లేదా కనీసం వారి ప్రభావాన్ని తగ్గించకుండా నిరోధించడం ఈ వ్యాసం యొక్క ఉద్దేశ్యం. 

ప్రవేశిక

చాలా కాలం క్రితం, Cian మోనోలిత్‌లను కలిగి ఉన్నప్పుడు మరియు ఇంకా మైక్రోసర్వీస్‌ల సూచనలు లేనప్పుడు, మేము 3-5 పేజీలను తనిఖీ చేయడం ద్వారా వనరు యొక్క లభ్యతను కొలిచాము. 

వారు సమాధానం ఇస్తారు - అంతా బాగానే ఉంది, వారు ఎక్కువసేపు సమాధానం ఇవ్వకపోతే - అప్రమత్తం. ఇది ఒక సంఘటనగా పరిగణించబడటానికి వారు ఎంతకాలం పనికి దూరంగా ఉండాలో సమావేశాలలో ప్రజలు నిర్ణయించారు. ఈ ఘటనపై విచారణలో ఇంజనీర్ల బృందం ఎప్పుడూ పాల్గొంటుంది. దర్యాప్తు పూర్తయినప్పుడు, వారు పోస్ట్‌మార్టం రాశారు - ఫార్మాట్‌లో ఇమెయిల్ ద్వారా ఒక రకమైన నివేదిక: ఏమి జరిగింది, ఎంతకాలం కొనసాగింది, మేము క్షణంలో ఏమి చేసాము, భవిష్యత్తులో మనం ఏమి చేస్తాము. 

సైట్ యొక్క ప్రధాన పేజీలు లేదా మేము దిగువకు చేరుకున్నామని ఎలా అర్థం చేసుకున్నాము

 
లోపం యొక్క ప్రాధాన్యతను ఏదో విధంగా అర్థం చేసుకోవడానికి, మేము వ్యాపార కార్యాచరణ కోసం అత్యంత క్లిష్టమైన సైట్ పేజీలను గుర్తించాము. వాటిని ఉపయోగించి, మేము విజయవంతమైన/విజయవంతం కాని అభ్యర్థనలు మరియు గడువు ముగిసిన వాటి సంఖ్యను లెక్కిస్తాము. ఈ విధంగా మేము సమయ సమయాన్ని కొలుస్తాము. 

ప్రధాన సేవకు బాధ్యత వహించే సైట్‌లో చాలా ముఖ్యమైన విభాగాలు ఉన్నాయని మేము కనుగొన్నాము - ప్రకటనలను శోధించడం మరియు సమర్పించడం. విఫలమయ్యే అభ్యర్థనల సంఖ్య 1% మించి ఉంటే, ఇది క్లిష్టమైన సంఘటన. ప్రధాన సమయంలో 15 నిమిషాలలోపు ఎర్రర్ రేటు 0,1% మించి ఉంటే, ఇది కూడా క్లిష్టమైన సంఘటనగా పరిగణించబడుతుంది. ఈ ప్రమాణాలు చాలా సంఘటనలను కవర్ చేస్తాయి; మిగిలినవి ఈ కథనం యొక్క పరిధికి మించినవి.

అగ్ర ఉత్తమ సంఘటనలు సియాన్

కాబట్టి, ఒక సంఘటన జరిగిన వాస్తవాన్ని గుర్తించడానికి మేము ఖచ్చితంగా నేర్చుకున్నాము. 

ఇప్పుడు ప్రతి సంఘటన వివరంగా వివరించబడింది మరియు జిరా ఇతిహాసంలో ప్రతిబింబిస్తుంది. మార్గం ద్వారా: దీని కోసం మేము ఒక ప్రత్యేక ప్రాజెక్ట్‌ను ప్రారంభించాము, దీనిని FAIL అని పిలుస్తారు - అందులో ఇతిహాసాలు మాత్రమే సృష్టించబడతాయి. 

మీరు గత కొన్ని సంవత్సరాలుగా అన్ని వైఫల్యాలను సేకరిస్తే, నాయకులు: 

• mssql సంబంధిత సంఘటనలు;
• బాహ్య కారకాల వల్ల సంభవించే సంఘటనలు;
• నిర్వాహక లోపాలు.

నిర్వాహకుల తప్పులు, అలాగే కొన్ని ఇతర ఆసక్తికరమైన వైఫల్యాల గురించి మరింత వివరంగా చూద్దాం.

ఐదవ స్థానం - “DNSలో వస్తువులను క్రమంలో ఉంచడం”

ఇది తుఫాను మంగళవారం. మేము DNS క్లస్టర్‌లో క్రమాన్ని పునరుద్ధరించాలని నిర్ణయించుకున్నాము. 

నేను అంతర్గత DNS సర్వర్‌లను బైండ్ నుండి పవర్‌డిఎన్‌లకు బదిలీ చేయాలనుకుంటున్నాను, దీని కోసం పూర్తిగా ప్రత్యేక సర్వర్‌లను కేటాయిస్తున్నాను, ఇక్కడ DNS తప్ప మరేమీ లేదు. 

మేము మా DCల యొక్క ప్రతి ప్రదేశంలో ఒక DNS సర్వర్‌ని ఉంచాము మరియు జోన్‌లను బైండ్ నుండి పవర్‌డిఎన్‌లకు తరలించడానికి మరియు మౌలిక సదుపాయాలను కొత్త సర్వర్‌లకు మార్చడానికి క్షణం వచ్చింది. 

తరలింపు మధ్యలో, అన్ని సర్వర్‌లలో స్థానిక కాషింగ్ బైండ్‌లలో పేర్కొన్న అన్ని సర్వర్‌లలో, సెయింట్ పీటర్స్‌బర్గ్‌లోని డేటా సెంటర్‌లో ఉన్న ఒక్కటి మాత్రమే మిగిలి ఉంది. ఈ DC ప్రారంభంలో మాకు నాన్-క్రిటికల్‌గా ప్రకటించబడింది, కానీ అకస్మాత్తుగా ఒకే పాయింట్ వైఫల్యంగా మారింది.
ఈ పునరావాస కాలంలోనే మాస్కో మరియు సెయింట్ పీటర్స్‌బర్గ్ మధ్య కాలువ పడిపోయింది. మేము నిజానికి ఐదు నిమిషాల పాటు DNS లేకుండా ఉండిపోయాము మరియు హోస్టర్ సమస్యను పరిష్కరించినప్పుడు మేము తిరిగి లేచాము. 

ముగింపులు:

ఇంతకుముందు మేము పని కోసం సన్నాహక సమయంలో బాహ్య కారకాలను విస్మరించినట్లయితే, ఇప్పుడు అవి కూడా మనం సిద్ధం చేస్తున్న జాబితాలో చేర్చబడ్డాయి. మరియు ఇప్పుడు మేము అన్ని భాగాలు n-2 రిజర్వు చేయబడినట్లు నిర్ధారించడానికి ప్రయత్నిస్తాము మరియు పని సమయంలో మేము ఈ స్థాయిని n-1కి తగ్గించవచ్చు.

• కార్యాచరణ ప్రణాళికను రూపొందించేటప్పుడు, సేవ విఫలమయ్యే పాయింట్లను గుర్తించండి మరియు ప్రతిదీ ముందుగానే "చెడు నుండి అధ్వాన్నంగా" వెళ్ళిన దృష్టాంతంలో ఆలోచించండి.
• విభిన్న జియోలొకేషన్‌లు/డేటా సెంటర్‌లు/రాక్‌లు/స్విచ్‌లు/ఇన్‌పుట్‌లలో అంతర్గత DNS సర్వర్‌లను పంపిణీ చేయండి.
• ప్రతి సర్వర్‌లో, స్థానిక కాషింగ్ DNS సర్వర్‌ను ఇన్‌స్టాల్ చేయండి, ఇది అభ్యర్థనలను ప్రధాన DNS సర్వర్‌లకు దారి మళ్లిస్తుంది మరియు అది అందుబాటులో లేకుంటే, అది కాష్ నుండి ప్రతిస్పందిస్తుంది. 

నాల్గవ స్థానం - “Nginxలో వస్తువులను క్రమంలో ఉంచడం”

ఒక మంచి రోజు, మా బృందం "మేము దీన్ని తగినంతగా కలిగి ఉన్నాము" అని నిర్ణయించుకుంది మరియు nginx కాన్ఫిగర్‌లను రీఫ్యాక్టరింగ్ చేసే ప్రక్రియ ప్రారంభమైంది. కాన్ఫిగరేషన్‌లను సహజమైన ఆకృతికి తీసుకురావడం ప్రధాన లక్ష్యం. గతంలో, ప్రతిదీ "చారిత్రాత్మకంగా స్థాపించబడింది" మరియు ఏ తర్కాన్ని కలిగి ఉండదు. ఇప్పుడు ప్రతి సర్వర్_పేరు అదే పేరుతో ఉన్న ఫైల్‌కి తరలించబడింది మరియు అన్ని కాన్ఫిగర్‌లు ఫోల్డర్‌లలోకి పంపిణీ చేయబడ్డాయి. మార్గం ద్వారా, కాన్ఫిగర్ 253949 పంక్తులు లేదా 7836520 అక్షరాలను కలిగి ఉంది మరియు దాదాపు 7 మెగాబైట్‌లను తీసుకుంటుంది. నిర్మాణం యొక్క ఉన్నత స్థాయి: 

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

ఇది చాలా మెరుగ్గా మారింది, కానీ కాన్ఫిగర్‌ల పేరు మార్చడం మరియు పంపిణీ చేసే ప్రక్రియలో, వాటిలో కొన్ని తప్పు పొడిగింపును కలిగి ఉన్నాయి మరియు చేర్చబడిన *.conf డైరెక్టివ్‌లో చేర్చబడలేదు. ఫలితంగా, కొన్ని హోస్ట్‌లు అందుబాటులో లేవు మరియు 301ని ప్రధాన పేజీకి తిరిగి ఇచ్చారు. ప్రతిస్పందన కోడ్ 5xx/4xx కానందున, ఇది వెంటనే గుర్తించబడలేదు, కానీ ఉదయం మాత్రమే. ఆ తర్వాత, మేము మౌలిక సదుపాయాల భాగాలను తనిఖీ చేయడానికి పరీక్షలు రాయడం ప్రారంభించాము.

ముగింపులు: 

• మీ కాన్ఫిగర్‌లను సరిగ్గా రూపొందించండి (కేవలం nginx మాత్రమే కాదు) మరియు ప్రాజెక్ట్ యొక్క ప్రారంభ దశలో నిర్మాణం గురించి ఆలోచించండి. ఈ విధంగా మీరు వారిని బృందానికి మరింత అర్థమయ్యేలా చేస్తారు, ఇది TTMని తగ్గిస్తుంది.
• కొన్ని ఇన్‌ఫ్రాస్ట్రక్చర్ భాగాల కోసం పరీక్షలు రాయండి. ఉదాహరణకు: అన్ని కీ సర్వర్_పేర్లు సరైన స్థితి + ప్రతిస్పందన అంశాన్ని ఇస్తాయో లేదో తనిఖీ చేయడం. కాంపోనెంట్ యొక్క ప్రాథమిక విధులను తనిఖీ చేసే కొన్ని స్క్రిప్ట్‌లను చేతిలో ఉంచుకుంటే సరిపోతుంది, తద్వారా తెల్లవారుజామున 3 గంటలకు ఇంకా ఏమి తనిఖీ చేయాలి అని పిచ్చిగా గుర్తుంచుకోకూడదు. 

మూడవ స్థానం - “కాసాండ్రాలో అకస్మాత్తుగా స్థలం అయిపోయింది”

డేటా స్థిరంగా పెరిగింది మరియు కాసాండ్రా క్లస్టర్‌లో పెద్ద కేస్‌పేస్‌ల మరమ్మత్తు విఫలమవడం ప్రారంభించిన క్షణం వరకు ప్రతిదీ బాగానే ఉంది, ఎందుకంటే వాటిపై సంపీడనం పనిచేయదు. 

ఒక తుఫాను రోజు క్లస్టర్ దాదాపు గుమ్మడికాయగా మారింది, అవి:

• క్లస్టర్‌లో మొత్తం స్థలంలో దాదాపు 20% మిగిలి ఉంది;
• నోడ్‌లను పూర్తిగా జోడించడం అసాధ్యం, ఎందుకంటే విభజనలపై ఖాళీ లేకపోవడం వల్ల నోడ్‌ను జోడించిన తర్వాత శుభ్రపరచడం జరగదు;
• సంపీడనం పని చేయనందున ఉత్పాదకత క్రమంగా పడిపోతుంది; 
• క్లస్టర్ ఎమర్జెన్సీ మోడ్‌లో ఉంది.

నిష్క్రమించు - మేము క్లీనప్ లేకుండా మరో 5 నోడ్‌లను జోడించాము, దాని తర్వాత మేము వాటిని క్లస్టర్ నుండి క్రమపద్ధతిలో తీసివేసి, ఖాళీ నోడ్‌ల వలె వాటిని మళ్లీ నమోదు చేయడం ప్రారంభించాము. మేము కోరుకున్న దానికంటే ఎక్కువ సమయం గడిపారు. క్లస్టర్ పాక్షికంగా లేదా పూర్తిగా అందుబాటులో లేకుండా పోయే ప్రమాదం ఉంది. 

ముగింపులు:

• అన్ని కాసాండ్రా సర్వర్‌లలో, ప్రతి విభజనలో 60% కంటే ఎక్కువ స్థలాన్ని ఆక్రమించకూడదు. 
• అవి 50% కంటే ఎక్కువ cpu వద్ద లోడ్ చేయబడాలి.
• మీరు సామర్థ్య ప్రణాళిక గురించి మరచిపోకూడదు మరియు ప్రతి భాగం దాని ప్రత్యేకతల ఆధారంగా దాని గురించి ఆలోచించాలి.
• క్లస్టర్‌లో ఎక్కువ నోడ్‌లు ఉంటే మంచిది. తక్కువ మొత్తంలో డేటాను కలిగి ఉన్న సర్వర్‌లు వేగంగా ఓవర్‌లోడ్ చేయబడతాయి మరియు అటువంటి క్లస్టర్‌ను పునరుద్ధరించడం సులభం. 

రెండవ స్థానం - “కాన్సుల్ కీ-విలువ నిల్వ నుండి డేటా అదృశ్యమైంది”

సేవా ఆవిష్కరణ కోసం, మేము చాలా మందిలాగే కాన్సుల్‌ని ఉపయోగిస్తాము. కానీ మేము ఏకశిలా యొక్క నీలం-ఆకుపచ్చ లేఅవుట్ కోసం దాని కీ-విలువను కూడా ఉపయోగిస్తాము. ఇది యాక్టివ్ మరియు ఇన్‌యాక్టివ్ అప్‌స్ట్రీమ్‌ల గురించి సమాచారాన్ని నిల్వ చేస్తుంది, ఇది విస్తరణ సమయంలో స్థలాలను మారుస్తుంది. ఈ ప్రయోజనం కోసం, KVతో పరస్పర చర్య చేసే విస్తరణ సేవ వ్రాయబడింది. ఏదో ఒక సమయంలో, KV నుండి డేటా అదృశ్యమైంది. మెమరీ నుండి పునరుద్ధరించబడింది, కానీ అనేక లోపాలతో. ఫలితంగా, అప్‌లోడ్ సమయంలో, అప్‌స్ట్రీమ్‌లపై లోడ్ అసమానంగా పంపిణీ చేయబడింది మరియు CPUలో బ్యాకెండ్‌లు ఓవర్‌లోడ్ కావడం వల్ల మేము చాలా 502 ఎర్రర్‌లను అందుకున్నాము. ఫలితంగా, మేము కాన్సుల్ KV నుండి పోస్ట్‌గ్రెస్‌కి మారాము, అక్కడ నుండి వాటిని తీసివేయడం అంత సులభం కాదు.  

ముగింపులు:

• ఎటువంటి అధికారం లేని సేవలు సైట్ యొక్క ఆపరేషన్‌కు కీలకమైన డేటాను కలిగి ఉండకూడదు. ఉదాహరణకు, మీకు ESలో అధికారం లేకపోతే, అవసరం లేని ప్రతిచోటా నెట్‌వర్క్ స్థాయిలో యాక్సెస్‌ను తిరస్కరించడం మంచిది, అవసరమైన వాటిని మాత్రమే వదిలివేయండి మరియు action.destructive_requires_name: true.
• మీ బ్యాకప్ మరియు రికవరీ మెకానిజంను ముందుగానే ప్రాక్టీస్ చేయండి. ఉదాహరణకు, బ్యాకప్ మరియు పునరుద్ధరించగల స్క్రిప్ట్‌ను ముందుగానే (ఉదాహరణకు, పైథాన్‌లో) తయారు చేయండి.

మొదటి స్థానం - “కెప్టెన్ అస్పష్టంగా” 

ఏదో ఒక సమయంలో, బ్యాకెండ్‌లో 10+ సర్వర్లు ఉన్న సందర్భాల్లో nginx అప్‌స్ట్రీమ్‌లలో లోడ్ అసమాన పంపిణీని మేము గమనించాము. రౌండ్-రాబిన్ క్రమంలో 1వ నుండి చివరి అప్‌స్ట్రీమ్‌కు అభ్యర్థనలను పంపడం మరియు ప్రతి nginx రీలోడ్ మళ్లీ ప్రారంభించడం వలన, మొదటి అప్‌స్ట్రీమ్‌లు ఎల్లప్పుడూ మిగిలిన వాటి కంటే ఎక్కువ అభ్యర్థనలను స్వీకరించాయి. ఫలితంగా, అవి నెమ్మదిగా పని చేశాయి మరియు మొత్తం సైట్ నష్టపోయింది. రద్దీ పెరగడంతో ఇది మరింతగా గుర్తించదగినదిగా మారింది. యాదృచ్ఛికంగా ఎనేబుల్ చేయడానికి nginxని అప్‌డేట్ చేయడం పని చేయలేదు - మేము వెర్షన్ 1.15 (ఆ సమయంలో) టేకాఫ్ చేయని లువా కోడ్‌ని మళ్లీ చేయాలి. మేము మా nginx 1.14.2ని ప్యాచ్ చేయాల్సి వచ్చింది, దానిలో యాదృచ్ఛిక మద్దతును పరిచయం చేస్తున్నాము. దీంతో సమస్య పరిష్కారమైంది. ఈ బగ్ "కెప్టెన్ నాన్-అస్పష్టత" కేటగిరీని గెలుచుకుంది.

ముగింపులు:

ఈ బగ్‌ని అన్వేషించడం చాలా ఆసక్తికరంగా మరియు ఉత్సాహంగా ఉంది). 

• మీ పర్యవేక్షణను నిర్వహించండి, తద్వారా అటువంటి హెచ్చుతగ్గులను త్వరగా కనుగొనడంలో ఇది మీకు సహాయపడుతుంది. ఉదాహరణకు, మీరు ప్రతి అప్‌స్ట్రీమ్‌లోని ప్రతి బ్యాకెండ్‌లో rpsని పర్యవేక్షించడానికి ELKని ఉపయోగించవచ్చు, nginx కోణం నుండి వారి ప్రతిస్పందన సమయాన్ని పర్యవేక్షించవచ్చు. ఈ సందర్భంలో, ఇది సమస్యను గుర్తించడంలో మాకు సహాయపడింది. 

తత్ఫలితంగా, మీరు చేస్తున్నదానికి మరింత నిశితమైన విధానంతో చాలా వైఫల్యాలను నివారించవచ్చు. మనం ఎల్లప్పుడూ మర్ఫీ నియమాన్ని గుర్తుంచుకోవాలి: తప్పు జరిగే ఏదైనా తప్పు జరుగుతుంది, మరియు దాని ఆధారంగా భాగాలను నిర్మించండి. 

మూలం: www.habr.com