HighLoad++, Evgeniy Kuzovlev (EcommPay IT): ఒక నిమిషం పనికిరాని సమయం $100000 అయినప్పుడు ఏమి చేయాలి

ప్రతి ఒక్కరూ అభివృద్ధి మరియు పరీక్ష ప్రక్రియల గురించి మాట్లాడతారు, సిబ్బందికి శిక్షణ ఇవ్వడం, ప్రేరణను పెంచడం, కానీ ఈ ప్రక్రియలు సరిపోవు, ఒక నిమిషం సేవా సమయానికి అపారమైన డబ్బు ఖర్చవుతుంది. మీరు కఠినమైన SLA కింద ఆర్థిక లావాదేవీలను నిర్వహించినప్పుడు ఏమి చేయాలి? సమీకరణం నుండి అభివృద్ధి మరియు పరీక్షలను తీసుకొని, మీ సిస్టమ్‌ల విశ్వసనీయత మరియు తప్పు సహనాన్ని ఎలా పెంచాలి?

తదుపరి HighLoad++ సమావేశం 6 ఏప్రిల్ 7 మరియు 2020 తేదీలలో సెయింట్ పీటర్స్‌బర్గ్‌లో జరుగుతుంది. వివరాలు మరియు టిక్కెట్లు వద్ద లింక్. నవంబర్ 9, 18:00. హైలోడ్++ మాస్కో 2018, ఢిల్లీ + కోల్‌కతా హాల్. థీసెస్ మరియు ప్రదర్శన.

Evgeniy Kuzovlev (ఇకపై – EC): - మిత్రులారా, హలో! నా పేరు కుజోవ్లెవ్ ఎవ్జెనీ. నేను EcommPay కంపెనీ నుండి వచ్చాను, ఒక నిర్దిష్ట విభాగం EcommPay IT, కంపెనీల సమూహం యొక్క IT విభాగం. మరియు ఈ రోజు మనం డౌన్‌టైమ్‌ల గురించి మాట్లాడుతాము - వాటిని ఎలా నివారించాలి అనే దాని గురించి, దానిని నివారించలేకపోతే వాటి పరిణామాలను ఎలా తగ్గించాలి అనే దాని గురించి. అంశం క్రింది విధంగా పేర్కొనబడింది: "ఒక నిమిషం పనికిరాని సమయం $100 ఖర్చు అయినప్పుడు ఏమి చేయాలి"? ముందుకు చూస్తే, మా సంఖ్యలు పోల్చదగినవి.

EcommPay IT ఏమి చేస్తుంది?

మనం ఎవరం? నేను ఇక్కడ మీ ముందు ఎందుకు నిలబడి ఉన్నాను? మీకు ఇక్కడ ఒక విషయం చెప్పే హక్కు నాకు ఎందుకు ఉంది? మరియు మనం ఇక్కడ మరింత వివరంగా ఏమి మాట్లాడుతాము?

EcommPay గ్రూప్ ఆఫ్ కంపెనీలు అంతర్జాతీయ కొనుగోలుదారు. మేము ప్రపంచవ్యాప్తంగా చెల్లింపులను ప్రాసెస్ చేస్తాము - రష్యా, యూరప్, ఆగ్నేయాసియా (ప్రపంచమంతా). మాకు 9 కార్యాలయాలు ఉన్నాయి, మొత్తం 500 మంది ఉద్యోగులు ఉన్నారు మరియు వారిలో దాదాపు సగం కంటే కొంచెం తక్కువ మంది IT నిపుణులు. మనం చేసే ప్రతి పని, డబ్బు సంపాదించే ప్రతిది మనమే చేసాము.

మేము మా ఉత్పత్తులన్నింటినీ వ్రాసాము (మరియు మా వద్ద చాలా ఉన్నాయి - మా పెద్ద IT ఉత్పత్తుల వరుసలో మేము సుమారు 16 విభిన్న భాగాలను కలిగి ఉన్నాము) మనమే; మనమే వ్రాస్తాము, మనల్ని మనం అభివృద్ధి చేసుకుంటాము. మరియు ప్రస్తుతానికి మేము రోజుకు ఒక మిలియన్ లావాదేవీలను నిర్వహిస్తాము (మిలియన్లు చెప్పడానికి బహుశా సరైన మార్గం). మేము చాలా యువ సంస్థ - మేము కేవలం ఆరు సంవత్సరాల వయస్సు మాత్రమే.

6 సంవత్సరాల క్రితం వ్యాపారంతో పాటు అబ్బాయిలు వచ్చినప్పుడు ఇది అలాంటి స్టార్టప్. వారు ఒక ఆలోచనతో ఏకమయ్యారు (ఒక ఆలోచన తప్ప మరేమీ లేదు), మరియు మేము పరిగెత్తాము. ఏదైనా స్టార్టప్ లాగా, మేము వేగంగా పరిగెత్తాము... మాకు, నాణ్యత కంటే వేగం ముఖ్యం.

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

మీరు కొత్త ఉత్పత్తిని తయారు చేస్తారు, మీరు దానిని ఉత్పత్తిలో ఉంచారు, కానీ ఇప్పటికీ ఎక్కడో ఏదో తప్పు జరుగుతుంది. మరియు ఈ రోజు మనం కొత్త నాణ్యత స్థాయిని ఎలా చేరుకోవాలో (మేము దీన్ని ఎలా చేసాము, మా అనుభవం గురించి) గురించి మాట్లాడతాము, సమీకరణం నుండి అభివృద్ధి మరియు పరీక్షను తీసుకోవడం; మేము ఆపరేషన్‌కు అందుబాటులో ఉన్న వాటి గురించి మాట్లాడుతాము - ఏ ఆపరేషన్ స్వయంగా చేయగలదు, నాణ్యతను ప్రభావితం చేయడానికి ఇది పరీక్షకు ఏమి అందించగలదు.

పనికిరాని సమయాలు. ఆపరేషన్ యొక్క ఆదేశాలు.

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

మేము మా విధానాలను మార్చడం ప్రారంభించినప్పుడు, మేము 4 ఆజ్ఞలను ఏర్పరుచుకున్నాము. నేను వాటిని స్లయిడ్‌లలో ప్రదర్శించాను:

ఈ ఆజ్ఞలు చాలా సరళమైనవి:

• సమస్యను త్వరగా గుర్తించండి.
• మరింత వేగంగా వదిలించుకోండి.
• కారణాన్ని అర్థం చేసుకోవడంలో సహాయపడండి (తరువాత, డెవలపర్‌ల కోసం).
• మరియు విధానాలను ప్రామాణికం చేయండి.

నేను మీ దృష్టిని పాయింట్ నం. 2కి ఆకర్షించాలనుకుంటున్నాను. మేము సమస్యను వదిలించుకుంటున్నాము, దాన్ని పరిష్కరించడం లేదు. నిర్ణయం తీసుకోవడం ద్వితీయం. మాకు, ప్రాథమిక విషయం ఏమిటంటే వినియోగదారు ఈ సమస్య నుండి రక్షించబడ్డారు. ఇది కొన్ని వివిక్త వాతావరణంలో ఉంటుంది, కానీ ఈ పర్యావరణం దానితో ఎలాంటి సంబంధాన్ని కలిగి ఉండదు. వాస్తవానికి, మేము ఈ నాలుగు సమస్యల సమూహాల ద్వారా వెళ్తాము (కొన్ని మరింత వివరంగా, కొన్ని తక్కువ వివరంగా), మేము ఏమి ఉపయోగిస్తాము, పరిష్కారాలలో మనకు ఎలాంటి సంబంధిత అనుభవం ఉందో నేను మీకు చెప్తాను.

ట్రబుల్షూటింగ్: అవి ఎప్పుడు జరుగుతాయి మరియు వాటి గురించి ఏమి చేయాలి?

కానీ మేము ఆర్డర్ నుండి ప్రారంభిస్తాము, మేము పాయింట్ నంబర్ 2 తో ప్రారంభిస్తాము - సమస్యను త్వరగా ఎలా వదిలించుకోవాలి? సమస్య ఉంది - మేము దాన్ని పరిష్కరించాలి. "దీని గురించి మనం ఏమి చేయాలి?" - ప్రధాన ప్రశ్న. మరియు మేము సమస్యను ఎలా పరిష్కరించాలో ఆలోచించడం ప్రారంభించినప్పుడు, ట్రబుల్షూటింగ్ తప్పనిసరిగా అనుసరించాల్సిన కొన్ని అవసరాలను మేము అభివృద్ధి చేసాము.

ఈ అవసరాలను రూపొందించడానికి, మనల్ని మనం ప్రశ్నించుకోవాలని నిర్ణయించుకున్నాము: "మాకు ఎప్పుడు సమస్యలు ఉన్నాయి"? మరియు సమస్యలు, అది ముగిసినట్లుగా, నాలుగు సందర్భాలలో సంభవిస్తాయి:

• హార్డ్‌వేర్ వైఫల్యం.
• బాహ్య సేవలు విఫలమయ్యాయి.
• సాఫ్ట్‌వేర్ సంస్కరణను మార్చడం (అదే విస్తరణ).
• పేలుడు లోడ్ పెరుగుదల.

మేము మొదటి రెండింటి గురించి మాట్లాడము. హార్డ్‌వేర్ లోపం చాలా సరళంగా పరిష్కరించబడుతుంది: మీరు ప్రతిదీ నకిలీని కలిగి ఉండాలి. ఇవి డిస్క్‌లు అయితే, డిస్క్‌లు తప్పనిసరిగా RAIDలో అసెంబుల్ చేయబడాలి; ఇది సర్వర్ అయితే, సర్వర్ తప్పనిసరిగా నకిలీ చేయబడాలి; మీకు నెట్‌వర్క్ ఇన్‌ఫ్రాస్ట్రక్చర్ ఉంటే, మీరు నెట్‌వర్క్ ఇన్‌ఫ్రాస్ట్రక్చర్ యొక్క రెండవ కాపీని సరఫరా చేయాలి, అంటే, మీరు దానిని తీసుకోవాలి మరియు దానిని నకిలీ చేయండి. మరియు ఏదైనా విఫలమైతే, మీరు రిజర్వ్ పవర్‌కి మారండి. ఇక్కడ ఇంకేమీ చెప్పడం కష్టం.

రెండవది బాహ్య సేవల వైఫల్యం. చాలా మందికి, సిస్టమ్ సమస్య కాదు, కానీ మాకు కాదు. మేము చెల్లింపులను ప్రాసెస్ చేస్తున్నందున, మేము వినియోగదారు (అతని కార్డ్ డేటాను నమోదు చేసేవారు) మరియు బ్యాంకులు, చెల్లింపు వ్యవస్థలు (వీసా, మాస్టర్ కార్డ్, మీరా, మొదలైనవి) మధ్య ఉండే అగ్రిగేటర్. మా బాహ్య సేవలు (చెల్లింపు వ్యవస్థలు, బ్యాంకులు) విఫలమవుతాయి. మేము లేదా మీరు (మీకు అలాంటి సేవలు ఉంటే) దీనిని ప్రభావితం చేయలేరు.

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

వాస్తవానికి, ఈ నాలుగింటిలో, సాఫ్ట్‌వేర్ సంస్కరణల మార్పును మేము ప్రత్యేకంగా ప్రభావితం చేయవచ్చు - విస్తరణల సందర్భంలో మరియు లోడ్‌లో పేలుడు పెరుగుదల సందర్భంలో పరిస్థితిలో మెరుగుదలకి దారితీసే చర్యలు తీసుకోండి. నిజానికి మనం చేసింది అదే. ఇక్కడ, మళ్ళీ, ఒక చిన్న గమనిక ...

ఈ నాలుగు సమస్యలలో, మీకు క్లౌడ్ ఉంటే చాలా వెంటనే పరిష్కరించబడతాయి. మీరు మైక్రోసాఫ్ట్ అజూర్, ఓజోన్ క్లౌడ్‌లలో ఉన్నట్లయితే లేదా Yandex లేదా మెయిల్ నుండి మా క్లౌడ్‌లను ఉపయోగిస్తుంటే, కనీసం హార్డ్‌వేర్ లోపం వారి సమస్యగా మారుతుంది మరియు హార్డ్‌వేర్ లోపం ఉన్న సందర్భంలో మీకు ప్రతిదీ వెంటనే చక్కగా మారుతుంది.

మేము కొద్దిగా సంప్రదాయేతర సంస్థ. ఇక్కడ అందరూ “కుబెర్నెట్స్” గురించి, మేఘాల గురించి మాట్లాడుతున్నారు - మనకు “కుబర్నెట్స్” లేదా మేఘాలు లేవు. కానీ మనకు చాలా డేటా సెంటర్లలో హార్డ్‌వేర్ ర్యాక్‌లు ఉన్నాయి మరియు మేము ఈ హార్డ్‌వేర్‌తో జీవించవలసి వస్తుంది, వీటన్నింటికీ మేము బాధ్యత వహించాల్సి వస్తుంది. అందువల్ల, మేము ఈ సందర్భంలో మాట్లాడుతాము. కాబట్టి, సమస్యల గురించి. మొదటి రెండు బ్రాకెట్ల నుండి తీసివేయబడ్డాయి.

సాఫ్ట్‌వేర్ సంస్కరణను మార్చడం. స్థావరాలు

మా డెవలపర్‌లకు ఉత్పత్తికి ప్రాప్యత లేదు. అది ఎందుకు? మేము PCI DSS సర్టిఫికేట్ పొందాము మరియు మా డెవలపర్‌లకు "ఉత్పత్తి"లోకి ప్రవేశించే హక్కు లేదు. అంతే, కాలం. అస్సలు. అందువల్ల, డెవలప్‌మెంట్ బిల్డ్‌ను విడుదల కోసం సమర్పించిన క్షణంలో డెవలప్‌మెంట్ బాధ్యత ముగుస్తుంది.

మనకు ఉన్న మన రెండవ ఆధారం, ఇది మనకు చాలా సహాయపడుతుంది, ప్రత్యేకమైన పత్రాలు లేని జ్ఞానం లేకపోవడం. మీకూ అలాగే ఉంటుందని నేను ఆశిస్తున్నాను. ఎందుకంటే ఇది కాకపోతే, మీకు సమస్యలు వస్తాయి. ఈ ప్రత్యేకమైన, పత్రాలు లేని జ్ఞానం సరైన సమయంలో సరైన స్థలంలో లేనప్పుడు సమస్యలు తలెత్తుతాయి. ఒక నిర్దిష్ట భాగాన్ని ఎలా అమర్చాలో మీకు తెలిసిన ఒక వ్యక్తిని కలిగి ఉన్నారని అనుకుందాం - వ్యక్తి అక్కడ లేడు, అతను సెలవులో ఉన్నాడు లేదా అనారోగ్యంతో ఉన్నాడు - అంతే, మీకు సమస్యలు ఉన్నాయి.

మరియు మేము వచ్చిన మూడవ ఆధారం. మేము నొప్పి, రక్తం, కన్నీళ్ల ద్వారా దానికి వచ్చాము - మా బిల్డ్‌లలో ఏదైనా లోపం లేనిదే అయినా లోపాలు ఉన్నాయని మేము నిర్ధారణకు వచ్చాము. మేము దీన్ని మన కోసం నిర్ణయించుకున్నాము: మేము ఏదైనా అమలు చేసినప్పుడు, మేము ఏదైనా ఉత్పత్తికి రోల్ చేసినప్పుడు, మనకు లోపాలతో కూడిన బిల్డ్ ఉంటుంది. మా సిస్టమ్ తప్పనిసరిగా సంతృప్తి పరచాల్సిన అవసరాలను మేము రూపొందించాము.

సాఫ్ట్‌వేర్ సంస్కరణను మార్చడానికి అవసరాలు

మూడు అవసరాలు ఉన్నాయి:

• మేము త్వరగా విస్తరణను వెనక్కి తీసుకోవాలి.
• విఫలమైన విస్తరణ యొక్క ప్రభావాన్ని మనం తప్పక తగ్గించాలి.
• మరియు మేము త్వరగా సమాంతరంగా అమలు చేయగలగాలి.
  సరిగ్గా ఆ క్రమంలోనే! ఎందుకు? ఎందుకంటే, మొదటగా, కొత్త సంస్కరణను అమలు చేస్తున్నప్పుడు, వేగం ముఖ్యం కాదు, కానీ ఏదైనా తప్పు జరిగితే, త్వరగా వెనక్కి వెళ్లడం మరియు తక్కువ ప్రభావాన్ని కలిగి ఉండటం మీకు ముఖ్యం. కానీ మీరు ఉత్పత్తిలో సంస్కరణల సమితిని కలిగి ఉంటే, దాని కోసం లోపం ఉందని తేలింది (నీలం నుండి, విస్తరణ లేదు, కానీ లోపం ఉంది) - తదుపరి విస్తరణ వేగం మీకు ముఖ్యం. ఈ డిమాండ్లను నెరవేర్చడానికి మేము ఏమి చేసాము? మేము ఈ క్రింది పద్దతిని ఆశ్రయించాము:

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

  ఇక్కడ రెండవ ప్రశ్నకు పరిష్కారం కనిష్టీకరణ: మీరు మీ ట్రాఫిక్‌లో కొంత భాగాన్ని మాత్రమే కొత్త లైన్‌కు, కొత్త కోడ్‌తో ఉన్న లైన్‌కు పంపవచ్చు (ఉదాహరణకు, 2% ఉండనివ్వండి). మరియు ఈ 2% 100% కాదు! విఫలమైన విస్తరణ కారణంగా మీరు మీ ట్రాఫిక్‌లో 100% కోల్పోయినట్లయితే, అది భయానకంగా ఉంటుంది; మీరు మీ ట్రాఫిక్‌లో 2% కోల్పోయినట్లయితే, అది అసహ్యకరమైనది, కానీ అది భయంకరమైనది కాదు. అంతేకాకుండా, వినియోగదారులు దీన్ని ఎక్కువగా గమనించలేరు, ఎందుకంటే కొన్ని సందర్భాల్లో (అన్నింటిలో కాదు) అదే వినియోగదారు, F5 నొక్కడం, మరొక, పని చేసే సంస్కరణకు తీసుకువెళతారు.

  నీలం/ఆకుపచ్చ విస్తరణ. రూటింగ్

  అయితే, ప్రతిదీ చాలా సులభం కాదు “బ్లూ/గ్రీన్ డిప్లాయ్”... మా అన్ని భాగాలను మూడు గ్రూపులుగా విభజించవచ్చు:

  • ఇది ఫ్రంటెండ్ (మా క్లయింట్లు చూసే చెల్లింపు పేజీలు);
  • ప్రాసెసింగ్ కోర్;
  • చెల్లింపు వ్యవస్థలతో పని చేయడానికి అడాప్టర్ (బ్యాంకులు, మాస్టర్ కార్డ్, వీసా...).

  మరియు ఇక్కడ ఒక స్వల్పభేదం ఉంది - స్వల్పభేదాన్ని పంక్తుల మధ్య రూటింగ్‌లో ఉంటుంది. మీరు కేవలం 100% ట్రాఫిక్‌ను మార్చుకుంటే, మీకు ఈ సమస్యలు ఉండవు. కానీ మీరు 2% మారాలనుకుంటే, మీరు ప్రశ్నలను అడగడం ప్రారంభించండి: "దీన్ని ఎలా చేయాలి?" సరళమైన విషయం నేరుగా ముందుకు ఉంటుంది: మీరు యాదృచ్ఛిక ఎంపిక ద్వారా nginxలో రౌండ్ రాబిన్‌ని సెటప్ చేయవచ్చు మరియు మీకు ఎడమవైపు 2%, కుడివైపు 98% ఉంటుంది. కానీ ఇది ఎల్లప్పుడూ తగినది కాదు.

  ఉదాహరణకు, మా విషయంలో, వినియోగదారు ఒకటి కంటే ఎక్కువ అభ్యర్థనలతో సిస్టమ్‌తో పరస్పర చర్య చేస్తారు. ఇది సాధారణం: 2, 3, 4, 5 అభ్యర్థనలు - మీ సిస్టమ్‌లు ఒకేలా ఉండవచ్చు. మరియు వినియోగదారు యొక్క అన్ని అభ్యర్థనలు మొదటి అభ్యర్థన వచ్చిన అదే లైన్‌కు రావడం లేదా (రెండవ పాయింట్) వినియోగదారు యొక్క అన్ని అభ్యర్థనలు స్విచ్ తర్వాత కొత్త లైన్‌కు రావడం మీకు ముఖ్యమైనది అయితే (అతను ముందుగా పని చేయడం ప్రారంభించి ఉండవచ్చు సిస్టమ్, స్విచ్ ముందు), - అప్పుడు ఈ యాదృచ్ఛిక పంపిణీ మీకు తగినది కాదు. అప్పుడు క్రింది ఎంపికలు ఉన్నాయి:

  
  
  మొదటి ఎంపిక, సరళమైనది, క్లయింట్ (IP హాష్) యొక్క ప్రాథమిక పారామితులపై ఆధారపడి ఉంటుంది. మీకు IP ఉంది మరియు మీరు దానిని IP చిరునామా ద్వారా కుడి నుండి ఎడమకు విభజించారు. అప్పుడు నేను వివరించిన రెండవ కేసు మీ కోసం పని చేస్తుంది, విస్తరణ జరిగినప్పుడు, వినియోగదారు ఇప్పటికే మీ సిస్టమ్‌తో పనిచేయడం ప్రారంభించవచ్చు మరియు విస్తరణ క్షణం నుండి అన్ని అభ్యర్థనలు కొత్త లైన్‌కి వెళ్తాయి (అదే ఒకటి, చెప్పండి).

  కొన్ని కారణాల వల్ల ఇది మీకు సరిపోకపోతే మరియు వినియోగదారు యొక్క ప్రారంభ, ప్రారంభ అభ్యర్థన వచ్చిన లైన్‌కు మీరు తప్పనిసరిగా అభ్యర్థనలను పంపాలి, అప్పుడు మీకు రెండు ఎంపికలు ఉన్నాయి...
  మొదటి ఎంపిక: మీరు చెల్లించిన nginx+ని కొనుగోలు చేయవచ్చు. స్టిక్కీ సెషన్‌ల మెకానిజం ఉంది, ఇది వినియోగదారు యొక్క ప్రారంభ అభ్యర్థనపై, వినియోగదారుకు సెషన్‌ను కేటాయించి, దానిని ఒకటి లేదా మరొక అప్‌స్ట్రీమ్‌కు బంధిస్తుంది. సెషన్ జీవితకాలంలో అన్ని తదుపరి వినియోగదారు అభ్యర్థనలు సెషన్ పోస్ట్ చేయబడిన అదే అప్‌స్ట్రీమ్‌కు పంపబడతాయి.

  మేము ఇప్పటికే సాధారణ nginxని కలిగి ఉన్నందున ఇది మాకు సరిపోలేదు. nginx+కి మారడం ఖరీదైనది కాదు, ఇది మాకు కొంత బాధాకరమైనది మరియు చాలా సరైనది కాదు. "స్టిక్స్ సెషన్స్", ఉదాహరణకు, "స్టిక్స్ సెషన్స్" "ఎయిదర్-లేదా" ఆధారంగా రూటింగ్‌ను అనుమతించవు అనే సాధారణ కారణంతో మాకు పని చేయలేదు. అక్కడ మీరు మేము "స్టిక్స్ సెషన్స్" ఏమి చేస్తామో పేర్కొనవచ్చు, ఉదాహరణకు, IP చిరునామా లేదా IP చిరునామా మరియు కుక్కీల ద్వారా లేదా పోస్ట్‌పారామీటర్ ద్వారా, కానీ అక్కడ "ఏదైనా-లేదా" మరింత క్లిష్టంగా ఉంటుంది.

  అందువల్ల, మేము నాల్గవ ఎంపికకు వచ్చాము. మేము స్టెరాయిడ్స్‌పై nginx తీసుకున్నాము (ఇది ఓపెన్‌రెస్టీ) - ఇదే nginx, ఇది అదనంగా చివరి స్క్రిప్ట్‌లను చేర్చడానికి మద్దతు ఇస్తుంది. మీరు చివరి స్క్రిప్ట్‌ను వ్రాయవచ్చు, దానికి “ఓపెన్ రెస్ట్” ఇవ్వండి మరియు వినియోగదారు అభ్యర్థన వచ్చినప్పుడు ఈ చివరి స్క్రిప్ట్ అమలు చేయబడుతుంది.

  మరియు మేము వ్రాసాము, వాస్తవానికి, అటువంటి స్క్రిప్ట్, మనల్ని మనం "openresti" సెట్ చేసాము మరియు ఈ స్క్రిప్ట్‌లో మేము 6 విభిన్న పారామితులను "లేదా" ద్వారా క్రమబద్ధీకరించాము. ఒకటి లేదా మరొక పరామితి ఉనికిని బట్టి, వినియోగదారు ఒక పేజీ లేదా మరొక, ఒక లైన్ లేదా మరొకదానికి వచ్చారని మాకు తెలుసు.

  నీలం/ఆకుపచ్చ విస్తరణ. ప్రయోజనాలు మరియు అప్రయోజనాలు

  వాస్తవానికి, దీన్ని కొంచెం సరళంగా చేయడం బహుశా సాధ్యమే (అదే “అంటుకునే సెషన్‌లను” ఉపయోగించండి), కానీ మేము ఒక లావాదేవీ యొక్క ఒక ప్రాసెసింగ్ ఫ్రేమ్‌వర్క్‌లో వినియోగదారు మాతో సంభాషించడమే కాకుండా అటువంటి స్వల్పభేదాన్ని కూడా కలిగి ఉన్నాము... కానీ చెల్లింపు వ్యవస్థలు కూడా మాతో పరస్పర చర్య చేస్తాయి: మేము లావాదేవీని ప్రాసెస్ చేసిన తర్వాత (చెల్లింపు వ్యవస్థకు అభ్యర్థనను పంపడం ద్వారా), మేము కూల్‌బ్యాక్‌ను అందుకుంటాము.
  మరియు మన సర్క్యూట్‌లో మనము అన్ని అభ్యర్థనలలో వినియోగదారు యొక్క IP చిరునామాను ఫార్వార్డ్ చేయగలిగితే మరియు IP చిరునామా ఆధారంగా వినియోగదారులను విభజించగలిగితే, మేము అదే “వీసా” అని చెప్పము: “డ్యూడ్, మేము అలాంటి రెట్రో కంపెనీ, మేము అనిపిస్తుంది అంతర్జాతీయంగా ఉండటానికి (వెబ్‌సైట్‌లో మరియు రష్యాలో)... దయచేసి అదనపు ఫీల్డ్‌లో వినియోగదారు యొక్క IP చిరునామాను మాకు అందించండి, మీ ప్రోటోకాల్ ప్రమాణీకరించబడింది”! అందుకు వారు అంగీకరించరని స్పష్టం చేశారు.

  
  
  అందువల్ల, ఇది మాకు పని చేయలేదు - మేము ఓపెన్‌రెస్టీ చేసాము. దీని ప్రకారం, రూటింగ్‌తో మనకు ఇలాంటివి లభించాయి:

  బ్లూ/గ్రీన్ డిప్లాయ్‌మెంట్‌కు అనుగుణంగా, నేను పేర్కొన్న ప్రయోజనాలు మరియు అప్రయోజనాలు ఉన్నాయి.

  రెండు ప్రతికూలతలు:

  • మీరు రూటింగ్‌తో ఇబ్బంది పడాలి;
  • రెండవ ప్రధాన ప్రతికూలత ఖర్చు.

  మీకు రెండు రెట్లు ఎక్కువ సర్వర్లు అవసరం, మీకు రెండు రెట్లు ఎక్కువ కార్యాచరణ వనరులు అవసరం, ఈ మొత్తం జంతుప్రదర్శనశాలను నిర్వహించడానికి మీరు రెండు రెట్లు ఎక్కువ కృషిని ఖర్చు చేయాలి.

  మార్గం ద్వారా, ప్రయోజనాలలో నేను ఇంతకు ముందు ప్రస్తావించని మరో విషయం ఉంది: లోడ్ పెరుగుదల విషయంలో మీకు రిజర్వ్ ఉంది. మీరు లోడ్‌లో పేలుడు వృద్ధిని కలిగి ఉన్నట్లయితే, మీకు పెద్ద సంఖ్యలో వినియోగదారులు ఉన్నారు, అప్పుడు మీరు 50 నుండి 50 పంపిణీలో రెండవ పంక్తిని చేర్చండి - మరియు మీరు మరిన్ని సర్వర్‌లను కలిగి ఉన్న సమస్యను పరిష్కరించే వరకు మీరు వెంటనే మీ క్లస్టర్‌లో x2 సర్వర్‌లను కలిగి ఉంటారు.

  త్వరిత విస్తరణ ఎలా చేయాలి?

  కనిష్టీకరణ మరియు శీఘ్ర రోల్‌బ్యాక్ సమస్యను ఎలా పరిష్కరించాలో మేము మాట్లాడాము, కానీ ప్రశ్న మిగిలి ఉంది: "త్వరగా ఎలా అమలు చేయాలి?"

  
  
  ఇది ఇక్కడ చిన్నది మరియు సరళమైనది.

  • మీరు తప్పనిసరిగా CD సిస్టమ్ (నిరంతర డెలివరీ) కలిగి ఉండాలి - మీరు అది లేకుండా జీవించలేరు. మీకు ఒక సర్వర్ ఉంటే, మీరు మాన్యువల్‌గా అమలు చేయవచ్చు. మన దగ్గర ఒకటిన్నర వేల సర్వర్లు మరియు ఒకటిన్నర వేల హ్యాండిల్స్ ఉన్నాయి, అయితే - మేము ఈ గది పరిమాణంలో ఒక డిపార్ట్‌మెంట్‌ని అమర్చవచ్చు.
  • విస్తరణ తప్పనిసరిగా సమాంతరంగా ఉండాలి. మీ విస్తరణ సీక్వెన్షియల్ అయితే, ప్రతిదీ చెడ్డది. ఒక సర్వర్ సాధారణమైనది, మీరు రోజంతా ఒకటిన్నర వేల సర్వర్‌లను అమలు చేస్తారు.
  • మళ్ళీ, త్వరణం కోసం, ఇది బహుశా ఇకపై అవసరం లేదు. విస్తరణ సమయంలో, ప్రాజెక్ట్ సాధారణంగా నిర్మించబడుతుంది. మీకు వెబ్ ప్రాజెక్ట్ ఉంది, ఫ్రంట్-ఎండ్ పార్ట్ ఉంది (మీరు అక్కడ వెబ్ ప్యాక్ చేస్తారు, మీరు npm ను కంపైల్ చేస్తారు - అలాంటిదే), మరియు ఈ ప్రక్రియ సూత్రప్రాయంగా, స్వల్పకాలికం - 5 నిమిషాలు, కానీ ఈ 5 నిమిషాలు విమర్శనాత్మకంగా ఉండండి. అందుకే, ఉదాహరణకు, మేము అలా చేయము: మేము ఈ 5 నిమిషాలను తీసివేసాము, మేము కళాఖండాలను అమలు చేస్తాము.

    ఒక కళాఖండం అంటే ఏమిటి? ఆర్టిఫ్యాక్ట్ అనేది అసెంబుల్డ్ బిల్డ్, దీనిలో అన్ని అసెంబ్లీ భాగాలు ఇప్పటికే పూర్తయ్యాయి. మేము ఈ కళాఖండాన్ని కళాఖండాల నిల్వలో నిల్వ చేస్తాము. ఒకప్పుడు మేము అలాంటి రెండు స్టోరేజీలను ఉపయోగించాము - అది Nexus మరియు ఇప్పుడు jFrog ఆర్టిఫ్యాక్టరీ). మేము మొదట్లో “Nexus”ని ఉపయోగించాము ఎందుకంటే మేము ఈ విధానాన్ని జావా అప్లికేషన్‌లలో ప్రాక్టీస్ చేయడం ప్రారంభించాము (ఇది బాగా సరిపోతుంది). అప్పుడు వారు PHPలో వ్రాసిన కొన్ని అప్లికేషన్లను అక్కడ ఉంచారు; మరియు "Nexus" ఇకపై తగినది కాదు, అందువల్ల మేము jFrog ఆర్టిఫ్యాక్టరీని ఎంచుకున్నాము, ఇది దాదాపు అన్నిటినీ కృత్రిమంగా మార్చగలదు. మేము ఈ ఆర్టిఫ్యాక్ట్ రిపోజిటరీలో సర్వర్‌ల కోసం సేకరించే మా స్వంత బైనరీ ప్యాకేజీలను నిల్వ చేస్తాము.

  పేలుడు లోడ్ పెరుగుదల

  మేము సాఫ్ట్‌వేర్ సంస్కరణను మార్చడం గురించి మాట్లాడాము. మేము కలిగి ఉన్న తదుపరి విషయం లోడ్లో పేలుడు పెరుగుదల. ఇక్కడ, నేను బహుశా లోడ్ యొక్క పేలుడు పెరుగుదల అంటే సరైన విషయం కాదు...

  మేము కొత్త వ్యవస్థను వ్రాసాము - ఇది సేవా ఆధారితమైనది, ఫ్యాషన్, అందమైనది, ప్రతిచోటా కార్మికులు, ప్రతిచోటా క్యూలు, ప్రతిచోటా అసమకాలికత. మరియు అటువంటి వ్యవస్థలలో, డేటా వివిధ ప్రవాహాల ద్వారా ప్రవహిస్తుంది. మొదటి లావాదేవీకి, 1వ, 3వ, 10వ వర్కర్‌ను ఉపయోగించవచ్చు, రెండవ లావాదేవీకి - 2వ, 4వ, 5వ. మరియు ఈ రోజు, ఉదయం మీరు మొదటి ముగ్గురు కార్మికులను ఉపయోగించే డేటా ఫ్లోని కలిగి ఉన్నారని చెప్పండి మరియు సాయంత్రం అది నాటకీయంగా మారుతుంది మరియు ప్రతిదీ ఇతర ముగ్గురు కార్మికులను ఉపయోగిస్తుంది.

  మరియు ఇక్కడ మీరు ఏదో ఒకవిధంగా కార్మికులను స్కేల్ చేయాల్సిన అవసరం ఉందని తేలింది, మీరు మీ సేవలను ఏదో ఒకవిధంగా స్కేల్ చేయాలి, కానీ అదే సమయంలో వనరుల ఉబ్బును నిరోధించండి.

  
  
  మేము మా అవసరాలను నిర్వచించాము. ఈ అవసరాలు చాలా సరళమైనవి: సర్వీస్ డిస్కవరీ, పారామీటర్‌లైజేషన్ - అటువంటి స్కేలబుల్ సిస్టమ్‌లను నిర్మించడానికి ప్రతిదీ ప్రామాణికం, ఒక పాయింట్ మినహా - వనరు తరుగుదల. సర్వర్‌లు గాలిని వేడి చేసేలా వనరులను రద్దు చేయడానికి మేము సిద్ధంగా లేమని మేము చెప్పాము. మేము "కాన్సుల్" తీసుకున్నాము, మేము మా కార్మికులను నిర్వహించే "నోమాడ్" తీసుకున్నాము.

  ఇది మాకు ఎందుకు సమస్య? కొంచెం వెనక్కి వెళ్దాం. ఇప్పుడు మా వెనుక దాదాపు 70 చెల్లింపు వ్యవస్థలు ఉన్నాయి. ఉదయం, ట్రాఫిక్ Sberbank గుండా వెళుతుంది, అప్పుడు Sberbank పడిపోయింది, ఉదాహరణకు, మరియు మేము దానిని మరొక చెల్లింపు వ్యవస్థకు మారుస్తాము. మేము స్బేర్‌బ్యాంక్‌కు ముందు 100 మంది కార్మికులను కలిగి ఉన్నాము మరియు ఆ తర్వాత మేము మరొక చెల్లింపు వ్యవస్థ కోసం 100 మంది కార్మికులను తీవ్రంగా పెంచాలి. మరియు మానవ భాగస్వామ్యం లేకుండా ఇవన్నీ జరగడం మంచిది. ఎందుకంటే మానవ భాగస్వామ్యం ఉంటే, అక్కడ 24/7 కూర్చున్న ఇంజనీర్ ఉండాలి, ఎవరు మాత్రమే దీన్ని చేయాలి, ఎందుకంటే 70 సిస్టమ్‌లు మీ వెనుక ఉన్నప్పుడు ఇలాంటి వైఫల్యాలు క్రమం తప్పకుండా జరుగుతాయి.

  అందువల్ల, మేము ఓపెన్ ఐపిని కలిగి ఉన్న నోమాడ్‌ని చూశాము మరియు మా స్వంత విషయం వ్రాసాము, స్కేల్-నోమాడ్ - స్కేల్‌నో, ఇది సుమారుగా ఈ క్రింది వాటిని చేస్తుంది: ఇది క్యూ పెరుగుదలను పర్యవేక్షిస్తుంది మరియు డైనమిక్‌లను బట్టి కార్మికుల సంఖ్యను తగ్గిస్తుంది లేదా పెంచుతుంది క్యూ యొక్క. మేము దీన్ని చేసినప్పుడు, మేము అనుకున్నాము: "బహుశా మనం దానిని ఓపెన్ సోర్స్ చేయగలమా?" అప్పుడు వారు ఆమెను చూశారు - ఆమె రెండు కోపెక్‌ల వలె సరళంగా ఉంది.

  ఇప్పటివరకు మేము దీన్ని ఓపెన్ సోర్స్ చేయలేదు, కానీ అకస్మాత్తుగా నివేదిక తర్వాత, మీకు అలాంటిది అవసరమని తెలుసుకున్న తర్వాత, మీకు ఇది అవసరం, నా పరిచయాలు చివరి స్లైడ్‌లో ఉన్నాయి - దయచేసి నాకు వ్రాయండి. కనీసం 3-5 మంది ఉంటే, మేము దానిని స్పాన్సర్ చేస్తాము.

  
  
  అది ఎలా పని చేస్తుంది? చూద్దాం! ముందుకు చూస్తే: ఎడమ వైపున మా పర్యవేక్షణ యొక్క భాగం ఉంది: ఇది ఒక లైన్, ఎగువన ఈవెంట్ ప్రాసెసింగ్ సమయం, మధ్యలో లావాదేవీల సంఖ్య, దిగువన కార్మికుల సంఖ్య.

  మీరు చూస్తే, ఈ చిత్రంలో ఒక లోపం ఉంది. టాప్ చార్ట్‌లో, చార్ట్‌లలో ఒకటి 45 సెకన్లలో క్రాష్ అయ్యింది - చెల్లింపు సిస్టమ్‌లలో ఒకటి డౌన్ అయింది. వెంటనే, ట్రాఫిక్ 2 నిమిషాల్లో తీసుకురాబడింది మరియు కార్మికులు లేని మరొక చెల్లింపు వ్యవస్థలో క్యూ పెరగడం ప్రారంభమైంది (మేము వనరులను ఉపయోగించలేదు - దీనికి విరుద్ధంగా, మేము వనరును సరిగ్గా పారవేసాము). మేము వేడి చేయడానికి ఇష్టపడలేదు - కనిష్ట సంఖ్య, సుమారు 5-10 మంది కార్మికులు ఉన్నారు, కానీ వారు భరించలేకపోయారు.

  చివరి గ్రాఫ్ "హంప్"ని చూపుతుంది, అంటే "స్కలెనో" ఈ మొత్తాన్ని రెట్టింపు చేసింది. ఆపై, గ్రాఫ్ కొద్దిగా పడిపోయినప్పుడు, అతను దానిని కొద్దిగా తగ్గించాడు - కార్మికుల సంఖ్య స్వయంచాలకంగా మార్చబడింది. ఈ విషయం ఎలా పనిచేస్తుంది. మేము పాయింట్ నంబర్ 2 గురించి మాట్లాడాము - “కారణాలను త్వరగా వదిలించుకోవడం ఎలా.”

  పర్యవేక్షణ. సమస్యను త్వరగా ఎలా గుర్తించాలి?

  ఇప్పుడు మొదటి పాయింట్ “సమస్యను త్వరగా గుర్తించడం ఎలా?” పర్యవేక్షణ! మనం కొన్ని విషయాలను త్వరగా అర్థం చేసుకోవాలి. మనం ఏ విషయాలను త్వరగా అర్థం చేసుకోవాలి?

  
  
  మూడు విషయాలు!

  • మన స్వంత వనరుల పనితీరును మనం త్వరగా అర్థం చేసుకోవాలి మరియు అర్థం చేసుకోవాలి.
  • మేము వైఫల్యాలను త్వరగా అర్థం చేసుకోవాలి మరియు మనకు బాహ్యంగా ఉండే సిస్టమ్‌ల పనితీరును పర్యవేక్షించాలి.
  • మూడవ అంశం తార్కిక లోపాలను గుర్తించడం. సిస్టమ్ మీ కోసం పని చేస్తున్నప్పుడు ఇది, అన్ని సూచికల ప్రకారం ప్రతిదీ సాధారణమైనది, కానీ ఏదో తప్పు జరుగుతుంది.

  నేను బహుశా మీకు ఇక్కడ అద్భుతమైన ఏదైనా చెప్పను. నేను కెప్టెన్‌గా ఉంటాను. మార్కెట్‌లో ఏముందో వెతికాము. మాకు "సరదా జూ" ఉంది. ఇప్పుడు మనకు ఉన్న జంతుప్రదర్శనశాల ఇదే:

  
  
  హార్డ్‌వేర్‌ను పర్యవేక్షించడానికి, సర్వర్‌ల ప్రధాన సూచికలను పర్యవేక్షించడానికి మేము Zabbixని ఉపయోగిస్తాము. మేము డేటాబేస్ల కోసం Okmeter ఉపయోగిస్తాము. మేము మొదటి రెండింటికి సరిపోని అన్ని ఇతర సూచికల కోసం "గ్రాఫానా" మరియు "ప్రోమెథియస్"ని ఉపయోగిస్తాము, కొన్ని "గ్రాఫానా" మరియు "ప్రోమేతియస్" మరియు కొన్ని "గ్రాఫానా"తో "ఇన్‌ఫ్లక్స్" మరియు టెలిగ్రాఫ్‌తో ఉంటాయి.

  ఒక సంవత్సరం క్రితం మేము కొత్త రెలిక్ని ఉపయోగించాలనుకుంటున్నాము. మంచి విషయం, ఇది ప్రతిదీ చేయగలదు. కానీ ఆమె ప్రతిదీ చేయగలదు, ఆమె చాలా ఖరీదైనది. మేము 1,5 వేల సర్వర్‌ల వాల్యూమ్‌కు పెరిగినప్పుడు, ఒక విక్రేత మా వద్దకు వచ్చి ఇలా అన్నాడు: "వచ్చే సంవత్సరానికి ఒక ఒప్పందాన్ని ముగించుదాం." మేము ధర చూసి, లేదు, మేము అలా చేయము అని చెప్పాము. ఇప్పుడు మేము కొత్త రెలిక్‌ను వదిలివేస్తున్నాము, న్యూ రెలిక్ పర్యవేక్షణలో మాకు దాదాపు 15 సర్వర్లు మిగిలి ఉన్నాయి. ధర పూర్తిగా క్రూరంగా మారింది.

  మరియు మనమే అమలు చేసుకున్న ఒక సాధనం ఉంది - ఇది డీబగ్గర్. మొదట మేము దానిని "బాగర్" అని పిలుస్తాము, కాని ఒక ఆంగ్ల ఉపాధ్యాయుడు అటుగా వెళ్ళాడు, విపరీతంగా నవ్వాడు మరియు "డిబాగర్" అని పేరు మార్చాడు. అదేంటి? ఇది ఒక సాధనం, వాస్తవానికి, సిస్టమ్ యొక్క "బ్లాక్ బాక్స్" వంటి ప్రతి భాగంపై 15-30 సెకన్లలో, భాగం యొక్క మొత్తం పనితీరుపై పరీక్షలను అమలు చేస్తుంది.

  ఉదాహరణకు, బాహ్య పేజీ (చెల్లింపు పేజీ) ఉన్నట్లయితే, అతను దానిని తెరిచి, అది ఎలా ఉండాలో చూస్తాడు. ఇది ప్రాసెస్ చేయబడుతుంటే, అతను ఒక పరీక్ష "లావాదేవీ"ని పంపి, ఈ "లావాదేవీ" వచ్చేలా చూసుకుంటాడు. ఇది చెల్లింపు వ్యవస్థలతో కనెక్షన్ అయితే, మేము తదనుగుణంగా ఒక పరీక్ష అభ్యర్థనను పంపుతాము, అక్కడ మనం చేయగలము మరియు మాతో ప్రతిదీ బాగానే ఉందని చూస్తాము.

  పర్యవేక్షణ కోసం ఏ సూచికలు ముఖ్యమైనవి?

  మనం ప్రధానంగా ఏమి పర్యవేక్షిస్తాము? ఏ సూచికలు మనకు ముఖ్యమైనవి?

  
  

  • ఫ్రంట్‌లలో ప్రతిస్పందన సమయం / RPS చాలా ముఖ్యమైన సూచిక. అతను వెంటనే మీకు ఏదో తప్పు అని సమాధానం ఇస్తాడు.
  • అన్ని క్యూలలో ప్రాసెస్ చేయబడిన సందేశాల సంఖ్య.
  • కార్మికుల సంఖ్య.
  • ప్రాథమిక ఖచ్చితత్వ కొలమానాలు.

  చివరి పాయింట్ "బిజినెస్", "బిజినెస్" మెట్రిక్. మీరు అదే విషయాన్ని పర్యవేక్షించాలనుకుంటే, మీ కోసం ప్రధాన సూచికలైన ఒకటి లేదా రెండు కొలమానాలను మీరు నిర్వచించాలి. మా మెట్రిక్ నిర్గమాంశ (ఇది మొత్తం లావాదేవీల ప్రవాహానికి విజయవంతమైన లావాదేవీల సంఖ్య నిష్పత్తి). 5-10-15 నిమిషాల వ్యవధిలో దానిలో ఏదైనా మారితే, మనకు సమస్యలు ఉన్నాయని అర్థం (అది సమూలంగా మారితే).

  ఇది మాకు కనిపించేది మా బోర్డులలో ఒకదానికి ఉదాహరణ:

  
  
  ఎడమ వైపున 6 గ్రాఫ్‌లు ఉన్నాయి, ఇది పంక్తుల ప్రకారం - కార్మికుల సంఖ్య మరియు క్యూలలోని సందేశాల సంఖ్య. కుడి వైపున - RPS, RTS. క్రింద అదే "వ్యాపార" మెట్రిక్ ఉంది. మరియు "బిజినెస్" మెట్రిక్‌లో రెండు మధ్య గ్రాఫ్‌లలో ఏదో తప్పు జరిగిందని మనం వెంటనే చూడవచ్చు... ఇది మన వెనుక పడిపోయిన మరొక వ్యవస్థ.

  మేము చేయవలసిన రెండవ విషయం బాహ్య చెల్లింపు వ్యవస్థల పతనాన్ని పర్యవేక్షించడం. ఇక్కడ మేము OpenTracing తీసుకున్నాము - పంపిణీ చేయబడిన వ్యవస్థలను గుర్తించడానికి మిమ్మల్ని అనుమతించే ఒక మెకానిజం, స్టాండర్డ్, పారాడిగ్మ్; మరియు అది కొద్దిగా మార్చబడింది. ప్రతి వ్యక్తి అభ్యర్థన కోసం మేము ఒక ట్రేస్‌ను నిర్మిస్తామని ప్రామాణిక OpenTracing నమూనా చెబుతోంది. మాకు ఇది అవసరం లేదు మరియు మేము దానిని సారాంశం, అగ్రిగేషన్ ట్రేస్‌లో చుట్టాము. మేము మా వెనుక ఉన్న సిస్టమ్‌ల వేగాన్ని ట్రాక్ చేయడానికి అనుమతించే సాధనాన్ని తయారు చేసాము.

  
  
  చెల్లింపు వ్యవస్థలలో ఒకటి 3 సెకన్లలో స్పందించడం ప్రారంభించిందని గ్రాఫ్ చూపిస్తుంది - మాకు సమస్యలు ఉన్నాయి. అంతేకాకుండా, సమస్యలు ప్రారంభమైనప్పుడు, 20-30 సెకన్ల వ్యవధిలో ఈ విషయం ప్రతిస్పందిస్తుంది.

  మరియు ఉనికిలో ఉన్న పర్యవేక్షణ లోపాల యొక్క మూడవ తరగతి తార్కిక పర్యవేక్షణ.

  నిజం చెప్పాలంటే, ఈ స్లయిడ్‌పై ఏమి గీయాలి అని నాకు తెలియదు, ఎందుకంటే మనకు సరిపోయే దాని కోసం మేము చాలా కాలంగా మార్కెట్లో వెతుకుతున్నాము. మాకు ఏమీ దొరకలేదు, కాబట్టి మనమే చేయాల్సి వచ్చింది.

  
  
  లాజికల్ మానిటరింగ్ అంటే నా ఉద్దేశం ఏమిటి? బాగా, ఊహించుకోండి: మీరు మీరే ఒక వ్యవస్థను తయారు చేసుకుంటారు (ఉదాహరణకు, టిండెర్ క్లోన్); మీరు దీన్ని చేసారు, ప్రారంభించారు. విజయవంతమైన మేనేజర్ వాస్య పుప్కిన్ దానిని తన ఫోన్‌లో ఉంచాడు, అక్కడ ఒక అమ్మాయిని చూశాడు, ఆమెను ఇష్టపడ్డాడు ... మరియు అలాంటిది ఆ అమ్మాయికి వెళ్లదు - అదే వ్యాపార కేంద్రం నుండి సెక్యూరిటీ గార్డు మిఖాలిచ్‌కి ఇష్టం. మేనేజర్ క్రిందికి వెళ్లి, ఆశ్చర్యపోతాడు: "ఈ సెక్యూరిటీ గార్డు మిఖాలిచ్ అతనిని చూసి ఎందుకు అంత ఆహ్లాదకరంగా నవ్వుతున్నాడు?"

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

  సమస్యను త్వరగా ఎలా గుర్తించాలనే దాని గురించి ఇది వివరించబడింది.

  విస్తరణకు కారణాలను ఎలా గుర్తించాలి

  మేము పరిష్కరించే సమస్యలలో మూడవ సమూహం ఏమిటంటే, మేము సమస్యను గుర్తించిన తర్వాత, దాన్ని వదిలించుకున్న తర్వాత, అభివృద్ధికి కారణాన్ని అర్థం చేసుకోవడం, పరీక్షించడం మరియు దాని గురించి ఏదైనా చేయడం మంచిది. దీని ప్రకారం, మేము దర్యాప్తు చేయాలి, మేము లాగ్లను పెంచాలి.

  
  
  మేము లాగ్‌ల గురించి మాట్లాడుతున్నట్లయితే (ప్రధాన కారణం లాగ్‌లు), మా లాగ్‌లలో ఎక్కువ భాగం ELK స్టాక్‌లో ఉన్నాయి - దాదాపు ప్రతి ఒక్కరికీ ఒకే విధంగా ఉంటుంది. కొందరికి, ఇది ELKలో ఉండకపోవచ్చు, కానీ మీరు గిగాబైట్‌లలో లాగ్‌లను వ్రాస్తే, ముందుగానే లేదా తరువాత మీరు ELKకి వస్తారు. మేము వాటిని టెరాబైట్లలో వ్రాస్తాము.

  
  
  ఇక్కడ ఒక సమస్య ఉంది. మేము దాన్ని సరిదిద్దాము, వినియోగదారు కోసం లోపాన్ని సరిదిద్దాము, అక్కడ ఉన్నదాన్ని త్రవ్వడం ప్రారంభించాము, కిబానాలోకి ఎక్కాము, అక్కడ లావాదేవీల ఐడిని నమోదు చేసాము మరియు ఇలాంటి ఫుట్‌క్లాత్‌ను పొందాము (చాలా చూపిస్తుంది). మరియు ఈ ఫుట్‌క్లాత్‌లో ఖచ్చితంగా ఏమీ స్పష్టంగా లేదు. ఎందుకు? అవును, ఎందుకంటే ఏ భాగం ఏ కార్మికుడికి చెందినదో, ఏ భాగం ఏ కాంపోనెంట్‌కు చెందినదో స్పష్టంగా తెలియదు. మరియు ఆ సమయంలో మాకు ట్రేసింగ్ అవసరమని మేము గ్రహించాము - నేను మాట్లాడిన అదే ఓపెన్‌ట్రేసింగ్.

  మేము దీన్ని ఒక సంవత్సరం క్రితం అనుకున్నాము, మా దృష్టిని మార్కెట్ వైపు మళ్లించాము మరియు అక్కడ రెండు సాధనాలు ఉన్నాయి - “జిప్‌కిన్” మరియు “జేగర్”. "జాగర్" నిజానికి అటువంటి సైద్ధాంతిక వారసుడు, "జిప్కిన్" యొక్క సైద్ధాంతిక వారసుడు. జిప్‌కిన్‌లో అన్నీ బాగున్నాయి, అది ఎలా అగ్రిగేట్ చేయాలో తెలియదు, ట్రేస్‌లో లాగ్‌లను ఎలా చేర్చాలో తెలియదు, టైమ్ ట్రేస్ మాత్రమే. మరియు "జాగర్" దీనికి మద్దతు ఇచ్చింది.

  మేము “జాగర్”ని చూశాము: మీరు అప్లికేషన్‌లను ఇన్‌స్ట్రుమెంట్ చేయవచ్చు, మీరు Apiలో వ్రాయవచ్చు (ఆ సమయంలో PHP కోసం Api ప్రమాణం ఆమోదించబడలేదు - ఇది ఒక సంవత్సరం క్రితం, కానీ ఇప్పుడు ఇది ఇప్పటికే ఆమోదించబడింది), కానీ అక్కడ ఖచ్చితంగా క్లయింట్ కాదు. "సరే," మేము ఆలోచించి, మా స్వంత క్లయింట్‌ని వ్రాసాము. మేము ఏమి పొందాము? ఇది సుమారుగా ఇలా కనిపిస్తుంది:

  
  
  జేగర్‌లో, ప్రతి సందేశానికి స్పాన్‌లు సృష్టించబడతాయి. అంటే, ఒక వినియోగదారు సిస్టమ్‌ను తెరిచినప్పుడు, అతను ప్రతి ఇన్‌కమింగ్ అభ్యర్థన కోసం ఒకటి లేదా రెండు బ్లాక్‌లను చూస్తాడు (1-2-3 - వినియోగదారు నుండి ఇన్‌కమింగ్ అభ్యర్థనల సంఖ్య, బ్లాక్‌ల సంఖ్య). వినియోగదారులకు సులభతరం చేయడానికి, మేము లాగ్‌లు మరియు టైమ్ ట్రేస్‌లకు ట్యాగ్‌లను జోడించాము. దీని ప్రకారం, లోపం సంభవించినట్లయితే, మా అప్లికేషన్ లాగ్‌ను తగిన ఎర్రర్ ట్యాగ్‌తో గుర్తు చేస్తుంది. మీరు ఎర్రర్ ట్యాగ్ ద్వారా ఫిల్టర్ చేయవచ్చు మరియు లోపం ఉన్న ఈ బ్లాక్‌ను కలిగి ఉన్న స్పాన్‌లు మాత్రమే ప్రదర్శించబడతాయి. మేము స్పాన్‌ని విస్తరింపజేస్తే ఇలా కనిపిస్తుంది:

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

  తదనుగుణంగా, మాకు మంచి జరిగింది. మేము మా స్వంత పొడిగింపును వ్రాసాము మరియు మేము దానిని ఓపెన్ సోర్స్ చేసాము. మీరు ట్రేసింగ్‌తో పని చేయాలనుకుంటే, మీరు PHPలో “జాగర్”తో పని చేయాలనుకుంటే, మా పొడిగింపు ఉంది, వారు చెప్పినట్లు ఉపయోగించడానికి స్వాగతం:

  
  
  మేము ఈ పొడిగింపును కలిగి ఉన్నాము - ఇది OpenTracing Api కోసం ఒక క్లయింట్, ఇది php-పొడిగింపుగా తయారు చేయబడింది, అంటే, మీరు దీన్ని సమీకరించి సిస్టమ్‌లో ఇన్‌స్టాల్ చేయాలి. ఒక సంవత్సరం క్రితం భిన్నంగా ఏమీ లేదు. ఇప్పుడు భాగాలు వంటి ఇతర క్లయింట్లు ఉన్నాయి. ఇక్కడ ఇది మీ ఇష్టం: మీరు కంపోజర్‌తో కాంపోనెంట్‌లను పంప్ అవుట్ చేయండి లేదా మీ వరకు పొడిగింపును ఉపయోగించండి.

  కార్పొరేట్ ప్రమాణాలు

  మేము మూడు ఆజ్ఞల గురించి మాట్లాడాము. నాల్గవ ఆజ్ఞ విధానాలను ప్రామాణీకరించడం. ఇది దేని గురించి? ఇది దీని గురించి:

  
  
  ఇక్కడ "కార్పొరేట్" అనే పదం ఎందుకు వచ్చింది? మేము పెద్ద లేదా బ్యూరోక్రాటిక్ కంపెనీ కాబట్టి కాదు, లేదు! నేను ఇక్కడ "కార్పొరేట్" అనే పదాన్ని ఉపయోగించాలనుకుంటున్నాను, ప్రతి కంపెనీ, ప్రతి ఉత్పత్తికి మీతో సహా దాని స్వంత ప్రమాణాలు ఉండాలి. మనకు ఎలాంటి ప్రమాణాలు ఉన్నాయి?

  
  

  • మాకు విస్తరణ నిబంధనలు ఉన్నాయి. ఆయన లేకుండా మనం ఎక్కడికీ కదలడం లేదు. మేము వారానికి 60 సార్లు నియోగిస్తాము, అంటే, మేము దాదాపు నిరంతరం అమలు చేస్తాము. అదే సమయంలో, మేము ఉదాహరణకు, విస్తరణ నిబంధనలలో శుక్రవారం విస్తరణలపై నిషేధాన్ని కలిగి ఉన్నాము - సూత్రప్రాయంగా, మేము అమలు చేయము.
  • మాకు డాక్యుమెంటేషన్ అవసరం. మా RnD స్పెషలిస్ట్‌ల కలం కింద పుట్టినప్పటికీ, దానికి సంబంధించిన డాక్యుమెంటేషన్ లేనట్లయితే ఒక్క కొత్త భాగం కూడా ఉత్పత్తిలోకి రాదు. ఈ కాంపోనెంట్ ఎలా పని చేస్తుందో, దాన్ని ఎలా ట్రబుల్‌షూట్ చేయాలి అనే వాటి నుండి విస్తరణ సూచనలు, మానిటరింగ్ మ్యాప్ మరియు స్థూల వివరణ (ప్రోగ్రామర్లు వ్రాయగలిగే విధంగా) మాకు అవసరం.
  • మేము సమస్య యొక్క కారణాన్ని కాదు, కానీ సమస్యను పరిష్కరిస్తాము - నేను ఇప్పటికే చెప్పాను. సమస్య నుండి వినియోగదారుని రక్షించడం మాకు ముఖ్యం.
  • మాకు అనుమతులు ఉన్నాయి. ఉదాహరణకు, మేము రెండు నిమిషాల్లో 2% ట్రాఫిక్‌ను కోల్పోయినట్లయితే మేము దానిని పనికిరాని సమయంగా పరిగణించము. ఇది ప్రాథమికంగా మా గణాంకాలలో చేర్చబడలేదు. ఇది శాతం పరంగా లేదా తాత్కాలికంగా ఎక్కువ అయితే, మేము ఇప్పటికే లెక్కించాము.
  • మరియు మేము ఎల్లప్పుడూ పోస్ట్‌మార్టం వ్రాస్తాము. మనకు ఏమి జరిగినా, ప్రొడక్షన్‌లో ఎవరైనా అసాధారణంగా ప్రవర్తించిన ఏదైనా పరిస్థితి పోస్ట్‌మార్టంలో ప్రతిబింబిస్తుంది. పోస్ట్‌మార్టం అనేది మీకు ఏమి జరిగిందో, వివరణాత్మక సమయం, దాన్ని సరిచేయడానికి మీరు ఏమి చేసారు మరియు (ఇది తప్పనిసరి బ్లాక్!) భవిష్యత్తులో ఇలా జరగకుండా నిరోధించడానికి మీరు ఏమి చేస్తారో వ్రాసే పత్రం. తదుపరి విశ్లేషణకు ఇది తప్పనిసరి మరియు అవసరం.

  ఏది పనికిరాని సమయంగా పరిగణించబడుతుంది?

  
  
  ఇదంతా దేనికి దారితీసింది?

  గత 6 నెలల్లో మా స్థిరత్వ సూచిక 99,97గా ఉంది (స్థిరతతో మాకు కొన్ని సమస్యలు ఉన్నాయి, ఇది క్లయింట్‌లకు లేదా మాకు సరిపోదు) వాస్తవం దారితీసింది. ఇది చాలా ఎక్కువ కాదని మనం చెప్పగలం. అవును, మనం ప్రయత్నించడానికి ఏదో ఉంది. ఈ సూచికలో, దాదాపు సగం స్థిరత్వం, అది మాది కాదు, మా వెబ్ అప్లికేషన్ ఫైర్‌వాల్, ఇది మా ముందు నిలబడి సేవగా ఉపయోగించబడుతుంది, కానీ క్లయింట్లు దీని గురించి పట్టించుకోరు.

  రాత్రి పడుకోవడం నేర్చుకున్నాం. చివరగా! ఆరు నెలల క్రితం మేం కుదరలేదు. మరియు ఫలితాలతో కూడిన ఈ నోట్‌పై, నేను ఒక గమనిక చేయాలనుకుంటున్నాను. గత రాత్రి అణు రియాక్టర్ నియంత్రణ వ్యవస్థ గురించి అద్భుతమైన నివేదిక వచ్చింది. ఈ సిస్టమ్‌ను వ్రాసిన వ్యక్తులు నా మాట వినగలిగితే, దయచేసి “2% పనికిరాని సమయం” గురించి నేను చెప్పిన దాని గురించి మరచిపోండి. మీ కోసం, 2% డౌన్‌టైమ్, రెండు నిమిషాలు అయినా!

  అంతే! మీ ప్రశ్నలు.

  
  

  బ్యాలెన్సర్‌లు మరియు డేటాబేస్ మైగ్రేషన్ గురించి

  ప్రేక్షకుల నుండి ప్రశ్న (ఇకపై – B): – శుభ సాయంత్రం. అటువంటి నిర్వాహక నివేదిక కోసం చాలా ధన్యవాదాలు! మీ బ్యాలెన్సర్‌ల గురించి ఒక చిన్న ప్రశ్న. మీకు WAF ఉందని మీరు పేర్కొన్నారు, అంటే, నేను అర్థం చేసుకున్నట్లుగా, మీరు ఒక రకమైన బాహ్య బ్యాలెన్సర్‌ని ఉపయోగిస్తున్నారు...

  EK: – లేదు, మేము మా సేవలను బ్యాలెన్సర్‌గా ఉపయోగిస్తాము. ఈ సందర్భంలో, WAF మాకు ప్రత్యేకంగా DDoS రక్షణ సాధనం.

  AT: – మీరు బాలన్సర్ల గురించి కొన్ని మాటలు చెప్పగలరా?

  EK: – నేను ఇప్పటికే చెప్పినట్లుగా, ఇది ఓపెన్‌రెస్టీలో ఉన్న సర్వర్ల సమూహం. మేము ఇప్పుడు ప్రత్యేకంగా ప్రతిస్పందించే 5 రిజర్వ్ సమూహాలను కలిగి ఉన్నాము... అంటే, ప్రత్యేకంగా ఓపెన్‌రెస్టీగా పనిచేసే సర్వర్, ఇది ట్రాఫిక్‌ను మాత్రమే ప్రాక్సీ చేస్తుంది. తదనుగుణంగా, మనం ఎంత పట్టుకున్నామో అర్థం చేసుకోవడానికి: ఇప్పుడు మనకు అనేక వందల మెగాబిట్ల సాధారణ ట్రాఫిక్ ప్రవాహం ఉంది. వారు భరించవలసి ఉంటుంది, వారు మంచి అనుభూతి చెందుతారు, వారు తమను తాము వక్రీకరించరు.

  AT: – కూడా ఒక సాధారణ ప్రశ్న. ఇక్కడ బ్లూ/గ్రీన్ డిప్లాయ్‌మెంట్ ఉంది. ఉదాహరణకు, డేటాబేస్ మైగ్రేషన్‌లతో మీరు ఏమి చేస్తారు?

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

  మిత్రులారా, మిమ్మల్ని ప్రోత్సహించడానికి నా దగ్గర ఒక చిన్న బహుమతి కూడా ఉంది - ఒక పుస్తకం. మరియు ఉత్తమ ప్రశ్నకు నాకు అవార్డు ఇవ్వాలి.

  AT: - హలో. నివేదిక అందించినందుకు ధన్యవాదాలు. ప్రశ్న ఇది. మీరు చెల్లింపులను పర్యవేక్షిస్తారు, మీరు కమ్యూనికేట్ చేసే సేవలను పర్యవేక్షిస్తారు... అయితే ఒక వ్యక్తి మీ చెల్లింపు పేజీకి ఎలాగైనా వచ్చి, చెల్లింపు చేసి, ప్రాజెక్ట్ అతనికి డబ్బు జమ చేసేలా మీరు ఎలా పర్యవేక్షిస్తారు? అంటే, మార్చాంట్ అందుబాటులో ఉన్నారని మరియు మీ కాల్‌బ్యాక్‌ను అంగీకరించారని మీరు ఎలా పర్యవేక్షిస్తారు?

  EK: - ఈ సందర్భంలో మాకు "వ్యాపారి" అనేది చెల్లింపు వ్యవస్థ వలె సరిగ్గా అదే బాహ్య సేవ. మేము వ్యాపారి ప్రతిస్పందన వేగాన్ని పర్యవేక్షిస్తాము.

  డేటాబేస్ ఎన్క్రిప్షన్ గురించి

  AT: - హలో. నాకు కొంచెం సంబంధిత ప్రశ్న ఉంది. మీ వద్ద PCI DSS సెన్సిటివ్ డేటా ఉంది. మీరు బదిలీ చేయాల్సిన క్యూలలో మీరు PANలను ఎలా నిల్వ చేస్తారో నేను తెలుసుకోవాలనుకుంటున్నాను? మీరు ఏదైనా ఎన్‌క్రిప్షన్‌ని ఉపయోగిస్తున్నారా? మరియు ఇది రెండవ ప్రశ్నకు దారి తీస్తుంది: PCI DSS ప్రకారం, మార్పులు (నిర్వాహకుల తొలగింపు, మొదలైనవి) విషయంలో డేటాబేస్ను క్రమానుగతంగా తిరిగి గుప్తీకరించడం అవసరం - ఈ సందర్భంలో ప్రాప్యతకు ఏమి జరుగుతుంది?

  
  
  EK: - అద్భుతమైన ప్రశ్న! ముందుగా, మేము పాన్‌లను క్యూలలో నిల్వ చేయము. పాన్‌ను స్పష్టమైన రూపంలో ఎక్కడైనా నిల్వ చేసే హక్కు మాకు లేదు, సూత్రప్రాయంగా, కాబట్టి మేము ఒక ప్రత్యేక సేవను ఉపయోగిస్తాము (మేము దీనిని “కడెమాన్” అని పిలుస్తాము) - ఇది ఒక పని మాత్రమే చేసే సేవ: ఇది ఇన్‌పుట్‌గా సందేశాన్ని స్వీకరించి పంపుతుంది గుప్తీకరించిన సందేశం. మరియు మేము ఈ గుప్తీకరించిన సందేశంతో ప్రతిదాన్ని నిల్వ చేస్తాము. దీని ప్రకారం, మా కీ పొడవు కిలోబైట్ కంటే తక్కువగా ఉంటుంది, తద్వారా ఇది తీవ్రమైనది మరియు నమ్మదగినది.

  AT: – మీకు ఇప్పుడు 2 కిలోబైట్లు అవసరమా?

  EK: – ఇది నిన్న 256 లాగా ఉంది... సరే, ఇంకెక్కడ?!

  దీని ప్రకారం, ఇది మొదటిది. మరియు రెండవది, ఉన్న పరిష్కారం, ఇది రీ-ఎన్‌క్రిప్షన్ విధానానికి మద్దతు ఇస్తుంది - రెండు జతల “కెక్స్” (కీలు) ఉన్నాయి, ఇవి గుప్తీకరించే “డెక్‌లను” ఇస్తాయి (కీలు కీలు, డెక్ ఎన్‌క్రిప్ట్ చేసే కీల ఉత్పన్నాలు) . మరియు ప్రక్రియ ప్రారంభించబడితే (ఇది క్రమం తప్పకుండా జరుగుతుంది, 3 నెలల నుండి ± కొన్ని వరకు), మేము కొత్త జత “కేక్‌లను” డౌన్‌లోడ్ చేస్తాము మరియు మేము డేటాను మళ్లీ గుప్తీకరిస్తాము. మేము మొత్తం డేటాను చీల్చి, కొత్త మార్గంలో గుప్తీకరించే ప్రత్యేక సేవలను కలిగి ఉన్నాము; డేటా ఎన్‌క్రిప్ట్ చేయబడిన కీ యొక్క ఐడెంటిఫైయర్ పక్కన నిల్వ చేయబడుతుంది. దీని ప్రకారం, మేము కొత్త కీలతో డేటాను గుప్తీకరించిన వెంటనే, మేము పాత కీని తొలగిస్తాము.

  కొన్నిసార్లు చెల్లింపులు మాన్యువల్‌గా చేయాలి...

  AT: – అంటే, ఏదైనా ఆపరేషన్ కోసం వాపసు వచ్చినట్లయితే, మీరు దానిని పాత కీతో డీక్రిప్ట్ చేస్తారా?

  EK: - అవును.

  AT: – తర్వాత మరో చిన్న ప్రశ్న. ఒక రకమైన వైఫల్యం, పతనం లేదా సంఘటన సంభవించినప్పుడు, లావాదేవీని మాన్యువల్‌గా నెట్టడం అవసరం. అలాంటి పరిస్థితి ఉంది.

  EK: - అవును కొన్నిసార్లు.

  AT: - మీరు ఈ డేటాను ఎక్కడ నుండి పొందుతారు? లేక ఈ స్టోరేజీ సదుపాయానికి మీరే వెళ్తారా?

  EK: – లేదు, అయితే, మేము మా మద్దతు కోసం ఇంటర్‌ఫేస్‌ను కలిగి ఉన్న బ్యాక్-ఆఫీస్ సిస్టమ్‌ని కలిగి ఉన్నాము. లావాదేవీ ఏ స్థితిలో ఉందో మాకు తెలియకపోతే (ఉదాహరణకు, చెల్లింపు వ్యవస్థ గడువు ముగిసిన తర్వాత ప్రతిస్పందించే వరకు), మాకు ముందస్తుగా తెలియదు, అంటే, మేము పూర్తి విశ్వాసంతో మాత్రమే తుది స్థితిని కేటాయిస్తాము. ఈ సందర్భంలో, మేము మాన్యువల్ ప్రాసెసింగ్ కోసం లావాదేవీని ప్రత్యేక హోదాకు కేటాయిస్తాము. ఉదయం, మరుసటి రోజు, అటువంటి మరియు అటువంటి లావాదేవీలు చెల్లింపు వ్యవస్థలో మిగిలి ఉన్నాయని మద్దతు సమాచారం అందుకున్న వెంటనే, వారు వాటిని ఈ ఇంటర్‌ఫేస్‌లో మాన్యువల్‌గా ప్రాసెస్ చేస్తారు.

  
  
  AT: – నాకు రెండు ప్రశ్నలు ఉన్నాయి. వాటిలో ఒకటి PCI DSS జోన్ యొక్క కొనసాగింపు: మీరు వారి సర్క్యూట్‌ను ఎలా లాగ్ చేస్తారు? డెవలపర్ ఏదైనా లాగ్స్‌లో ఉంచవచ్చు కాబట్టి ఈ ప్రశ్న! రెండవ ప్రశ్న: మీరు హాట్‌ఫిక్స్‌లను ఎలా తయారు చేస్తారు? డేటాబేస్లో హ్యాండిల్స్ ఒక ఎంపిక, కానీ ఉచిత హాట్-ఫిక్స్‌లు ఉండవచ్చు - అక్కడ విధానం ఏమిటి? మరియు మూడవ ప్రశ్న బహుశా RTO, RPOకి సంబంధించినది. మీ లభ్యత 99,97, దాదాపు నాలుగు తొమ్మిది, కానీ నేను అర్థం చేసుకున్నట్లుగా, మీకు రెండవ డేటా సెంటర్, మూడవ డేటా సెంటర్ మరియు ఐదవ డేటా సెంటర్ ఉన్నాయి... మీరు వాటిని ఎలా సమకాలీకరించాలి, వాటిని పునరావృతం చేయాలి మరియు మిగతావన్నీ ఎలా ఉన్నాయి?

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

  "నాలుగు తొమ్మిది" గురించి. మేము ఇప్పుడు కలిగి ఉన్న సంఖ్య నిజంగా సాధించబడింది మరియు మేము దాని కోసం మరొక డేటా సెంటర్‌లో ప్రయత్నించాము. ఇప్పుడు మనకు రెండవ డేటా సెంటర్ ఉంది మరియు మేము వాటి మధ్య మార్గాన్ని ప్రారంభించాము మరియు క్రాస్-డేటా సెంటర్ రెప్లికేషన్ సమస్య నిజంగా చిన్నవిషయం కాని ప్రశ్న. మేము వేర్వేరు మార్గాలను ఉపయోగించి ఒకేసారి పరిష్కరించడానికి ప్రయత్నించాము: మేము అదే “టరాన్టులా” ను ఉపయోగించడానికి ప్రయత్నించాము - ఇది మాకు పని చేయలేదు, నేను వెంటనే మీకు చెప్తాను. అందుకే మేము "సెన్స్"ని మాన్యువల్‌గా ఆర్డర్ చేయడం ముగించాము. వాస్తవానికి, మా సిస్టమ్‌లోని ప్రతి అప్లికేషన్ డేటా కేంద్రాల మధ్య అవసరమైన “మార్పు - పూర్తయింది” సమకాలీకరణను అసమకాలికంగా అమలు చేస్తుంది.

  AT: - మీకు రెండవది వస్తే, మీరు మూడవదాన్ని ఎందుకు పొందలేదు? ఎందుకంటే ఇంకా ఎవరికీ మెదడు విడిపోలేదు...

  EK: - కానీ మాకు స్ప్లిట్ బ్రెయిన్ లేదు. ప్రతి అప్లికేషన్ మల్టీమాస్టర్ ద్వారా నడపబడుతున్నందున, అభ్యర్థన ఏ కేంద్రానికి వచ్చిందో మాకు పట్టింపు లేదు. మా డేటా సెంటర్‌లలో ఒకటి విఫలమైతే (మేము దీనిపై ఆధారపడతాము) మరియు వినియోగదారు అభ్యర్థన మధ్యలో రెండవ డేటా సెంటర్‌కు మారితే, మేము ఈ వినియోగదారుని కోల్పోవడానికి సిద్ధంగా ఉన్నాము; కానీ ఇవి యూనిట్లు, సంపూర్ణ యూనిట్లు.

  AT: - శుభ సాయంత్రం. నివేదిక అందించినందుకు ధన్యవాదాలు. మీరు మీ డీబగ్గర్ గురించి మాట్లాడారు, ఇది ఉత్పత్తిలో కొన్ని పరీక్ష లావాదేవీలను అమలు చేస్తుంది. అయితే పరీక్ష లావాదేవీల గురించి చెప్పండి! అది ఎంత లోతుకు వెళుతుంది?

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

  AT: - మీరు దానిని ఎక్కడ కత్తిరించారు? ఇక్కడ కోర్ పంపబడింది...

  EK: – మేము పరీక్ష లావాదేవీల కోసం ఈ సందర్భంలో “కోర్” వెనుక ఉన్నాము... మాకు రూటింగ్ వంటి విషయం ఉంది: “కోర్”కి ఏ చెల్లింపు వ్యవస్థను పంపాలో తెలుసు - మేము నకిలీ చెల్లింపు వ్యవస్థకు పంపుతాము, ఇది కేవలం http సిగ్నల్‌ని ఇస్తుంది మరియు అంతే.

  AT: – దయచేసి నాకు చెప్పండి, మీ అప్లికేషన్ ఒక భారీ ఏకశిలాతో వ్రాయబడిందా లేదా మీరు దానిని కొన్ని సేవలు లేదా మైక్రోసర్వీస్‌లుగా కట్ చేసారా?

  EK: – మాకు ఏకశిలా లేదు, అయితే, మా వద్ద సేవా ఆధారిత అప్లికేషన్ ఉంది. మా సేవ ఏకశిలాలతో తయారు చేయబడిందని మేము జోక్ చేస్తాము - అవి నిజంగా చాలా పెద్దవి. దీన్ని మైక్రోసర్వీస్ అని పిలవడం కష్టం, కానీ ఇవి పంపిణీ చేయబడిన యంత్రాల కార్మికులు పనిచేసే సేవలు.

  సర్వర్‌లో సేవ రాజీపడితే...

  AT: – అప్పుడు నాకు తదుపరి ప్రశ్న ఉంది. ఇది ఏకశిలా అయినప్పటికీ, మీ వద్ద ఈ ఇన్‌స్టంట్ సర్వర్‌లు చాలా ఉన్నాయని మీరు ఇప్పటికీ చెప్పారు, అవన్నీ ప్రాథమికంగా డేటాను ప్రాసెస్ చేస్తాయి మరియు ప్రశ్న: “ఇన్‌స్టంట్ సర్వర్‌లలో ఒకటి లేదా అప్లికేషన్‌లో ఏదైనా రాజీ ఏర్పడిన సందర్భంలో, ఏదైనా వ్యక్తిగత లింక్ , వారికి కొన్ని రకాల యాక్సెస్ నియంత్రణ ఉందా? వారిలో ఎవరు ఏమి చేయగలరు? ఏ సమాచారం కోసం నేను ఎవరిని సంప్రదించాలి?

  
  
  EK: - అవును, ఖచ్చితంగా. భద్రతా అవసరాలు చాలా తీవ్రమైనవి. ముందుగా, మేము ఓపెన్ డేటా కదలికలను కలిగి ఉన్నాము మరియు పోర్ట్‌లు మాత్రమే ట్రాఫిక్ కదలికను ముందుగానే అంచనా వేస్తాము. ఒక భాగం 5-4-3-2 ద్వారా డేటాబేస్ (చెప్పండి, ముస్కుల్‌తో)తో కమ్యూనికేట్ చేస్తే, దానికి 5-4-3-2 మాత్రమే తెరవబడుతుంది మరియు ఇతర పోర్ట్‌లు మరియు ఇతర ట్రాఫిక్ దిశలు అందుబాటులో ఉండవు. అదనంగా, మా ఉత్పత్తిలో సుమారు 10 వేర్వేరు భద్రతా లూప్‌లు ఉన్నాయని మీరు అర్థం చేసుకోవాలి. మరియు అప్లికేషన్ ఏదో ఒకవిధంగా రాజీపడినప్పటికీ, దేవుడు నిషేధించినప్పటికీ, దాడి చేసే వ్యక్తి సర్వర్ మేనేజ్‌మెంట్ కన్సోల్‌ను యాక్సెస్ చేయలేరు, ఎందుకంటే ఇది వేరే నెట్‌వర్క్ సెక్యూరిటీ జోన్.

  AT: – మరియు ఈ సందర్భంలో, నాకు మరింత ఆసక్తికరమైన విషయం ఏమిటంటే, మీకు సేవలతో నిర్దిష్ట ఒప్పందాలు ఉన్నాయి - వారు ఏమి చేయగలరు, ఏ “చర్యల” ద్వారా వారు ఒకరినొకరు సంప్రదించగలరు... మరియు సాధారణ ప్రవాహంలో, కొన్ని నిర్దిష్ట సేవలు కొన్నింటిని అభ్యర్థించవచ్చు. వరుస, మరొకదానిపై "చర్యల" జాబితా. వారు సాధారణ పరిస్థితిలో ఇతరులకు మారినట్లు కనిపించరు మరియు వారికి ఇతర బాధ్యతలు ఉన్నాయి. వాటిలో ఒకటి రాజీపడితే, అది ఆ సేవ యొక్క “చర్యలకు” అంతరాయం కలిగించగలదా?..

  EK: - నాకు అర్థమైనది. ఒక సాధారణ పరిస్థితిలో మరొక సర్వర్ కమ్యూనికేషన్ అనుమతించబడితే, అవును. SLA ఒప్పందం ప్రకారం, మీరు మొదటి 3 "చర్యలు" మాత్రమే అనుమతించబడతారని మేము పర్యవేక్షించము మరియు మీరు 4 "చర్యలు" అనుమతించబడరు. ఇది బహుశా మాకు అనవసరమైనది, ఎందుకంటే మేము ఇప్పటికే సర్క్యూట్ల కోసం సూత్రప్రాయంగా 4-స్థాయి రక్షణ వ్యవస్థను కలిగి ఉన్నాము. మేము ఇన్‌సైడ్‌ల స్థాయిలో కాకుండా ఆకృతులతో మనల్ని మనం రక్షించుకోవడానికి ఇష్టపడతాము.

  వీసా, మాస్టర్ కార్డ్ మరియు స్బేర్‌బ్యాంక్ ఎలా పని చేస్తాయి

  AT: – వినియోగదారుని ఒక డేటా సెంటర్ నుండి మరొక డేటాకు మార్చడం గురించి నేను ఒక విషయాన్ని స్పష్టం చేయాలనుకుంటున్నాను. నాకు తెలిసినంత వరకు, Visa మరియు MasterCard 8583 బైనరీ సింక్రోనస్ ప్రోటోకాల్‌ను ఉపయోగించి పనిచేస్తాయి మరియు అక్కడ మిక్స్‌లు ఉన్నాయి. మరియు నేను తెలుసుకోవాలనుకున్నాను, ఇప్పుడు మనం మారడం అంటే - ఇది నేరుగా "వీసా" మరియు "మాస్టర్ కార్డ్" లేదా చెల్లింపు వ్యవస్థల ముందు, ప్రాసెస్ చేయడానికి ముందు?

  EK: - ఇది మిశ్రమాలకు ముందు. మా మిక్స్‌లు ఒకే డేటా సెంటర్‌లో ఉన్నాయి.

  AT: – స్థూలంగా చెప్పాలంటే, మీకు ఒక కనెక్షన్ పాయింట్ ఉందా?

  EK: – “వీసా” మరియు “మాస్టర్ కార్డ్” - అవును. వీసా మరియు మాస్టర్‌కార్డ్‌లకు రెండవ జత మిశ్రమాలను పొందేందుకు వేర్వేరు ఒప్పందాలను ముగించడానికి మౌలిక సదుపాయాలపై చాలా తీవ్రమైన పెట్టుబడులు అవసరం కాబట్టి, ఉదాహరణకు. అవి ఒక డేటా సెంటర్‌లో రిజర్వ్ చేయబడ్డాయి, అయితే, దేవుడు నిషేధించినట్లయితే, వీసా మరియు మాస్టర్‌కార్డ్‌లకు కనెక్ట్ చేయడానికి మిక్స్‌లు ఉన్న మా డేటా సెంటర్ చనిపోతే, వీసా మరియు మాస్టర్‌కార్డ్‌తో కనెక్షన్ కోల్పోతాము...

  AT: - వారు ఎలా రిజర్వ్ చేయబడతారు? వీసా సూత్రప్రాయంగా ఒక కనెక్షన్‌ని మాత్రమే అనుమతిస్తుంది అని నాకు తెలుసు!

  EK: - వారు స్వయంగా పరికరాలను సరఫరా చేస్తారు. ఏదైనా సందర్భంలో, మేము లోపల పూర్తిగా అనవసరమైన పరికరాలను అందుకున్నాము.

  AT: – కాబట్టి స్టాండ్ వారి కనెక్ట్స్ ఆరెంజ్ నుండి ఉందా?..

  EK: - అవును.

  AT: – అయితే ఈ కేసు గురించి ఏమిటి: మీ డేటా సెంటర్ అదృశ్యమైతే, మీరు దానిని ఉపయోగించడం ఎలా కొనసాగించవచ్చు? లేక ట్రాఫిక్ ఆగిపోతుందా?

  EK: - లేదు. ఈ సందర్భంలో, మేము కేవలం ట్రాఫిక్‌ను మరొక ఛానెల్‌కి మారుస్తాము, ఇది సహజంగానే, మాకు చాలా ఖరీదైనది మరియు మా క్లయింట్‌లకు మరింత ఖరీదైనది. కానీ ట్రాఫిక్ వీసా, మాస్టర్ కార్డ్‌కి మా ప్రత్యక్ష కనెక్షన్ ద్వారా వెళ్లదు, కానీ షరతులతో కూడిన స్బేర్‌బ్యాంక్ ద్వారా (చాలా అతిశయోక్తి).

  నేను స్బేర్‌బ్యాంక్ ఉద్యోగులను బాధపెట్టినట్లయితే నేను క్రూరంగా క్షమాపణలు కోరుతున్నాను. కానీ మా గణాంకాల ప్రకారం, రష్యన్ బ్యాంకులలో, స్బేర్బ్యాంక్ చాలా తరచుగా వస్తుంది. స్బేర్‌బ్యాంక్‌లో ఏదో పడిపోకుండా ఒక నెల కాదు.

  
  
  

  కొన్ని ప్రకటనలు 🙂

  మాతో ఉన్నందుకు ధన్యవాదాలు. మీరు మా కథనాలను ఇష్టపడుతున్నారా? మరింత ఆసక్తికరమైన కంటెంట్‌ని చూడాలనుకుంటున్నారా? ఆర్డర్ చేయడం ద్వారా లేదా స్నేహితులకు సిఫార్సు చేయడం ద్వారా మాకు మద్దతు ఇవ్వండి, $4.99 నుండి డెవలపర్‌ల కోసం క్లౌడ్ VPS, ఎంట్రీ-లెవల్ సర్వర్‌ల యొక్క ప్రత్యేకమైన అనలాగ్, ఇది మీ కోసం మా ద్వారా కనుగొనబడింది: $5 నుండి VPS (KVM) E2697-3 v6 (10 కోర్లు) 4GB DDR480 1GB SSD 19Gbps గురించి పూర్తి నిజం లేదా సర్వర్‌ను ఎలా భాగస్వామ్యం చేయాలి? (RAID1 మరియు RAID10తో అందుబాటులో ఉంది, గరిష్టంగా 24 కోర్లు మరియు 40GB DDR4 వరకు).

  ఆమ్‌స్టర్‌డామ్‌లోని ఈక్వినిక్స్ టైర్ IV డేటా సెంటర్‌లో Dell R730xd 2x చౌకగా ఉందా? ఇక్కడ మాత్రమే $2 నుండి 2 x ఇంటెల్ టెట్రాడెకా-కోర్ జియాన్ 5x E2697-3v2.6 14GHz 64C 4GB DDR4 960x1GB SSD 100Gbps 199 TV నెదర్లాండ్స్‌లో! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 నుండి! గురించి చదవండి ఇన్‌ఫ్రాస్ట్రక్చర్ కార్పొరేషన్‌ను ఎలా నిర్మించాలి. ఒక పెన్నీకి 730 యూరోల విలువైన Dell R5xd E2650-4 v9000 సర్వర్‌ల వాడకంతో తరగతి?

మూలం: www.habr.com