“నా షూస్‌లో నడవడం” - వేచి ఉండండి, అవి గుర్తించబడ్డాయా?

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

X5లో, రాష్ట్రం మరియు సరఫరాదారులతో లేబుల్ చేయబడిన వస్తువులను ట్రాక్ చేసే మరియు డేటాను మార్పిడి చేసే వ్యవస్థను "మార్కస్" అంటారు. దీన్ని ఎలా మరియు ఎవరు అభివృద్ధి చేసారు, దాని టెక్నాలజీ స్టాక్ ఏమిటి మరియు మనం ఎందుకు గర్వపడాల్సిన అవసరం ఉందో క్రమంగా మీకు తెలియజేస్తాము.

రియల్ హైలోడ్

"మార్కస్" అనేక సమస్యలను పరిష్కరిస్తుంది, ప్రధానమైనది X5 సమాచార వ్యవస్థలు మరియు లేబుల్ చేయబడిన ఉత్పత్తుల కదలికను ట్రాక్ చేయడానికి లేబుల్ చేయబడిన ఉత్పత్తుల (GIS MP) కోసం రాష్ట్ర సమాచార వ్యవస్థ మధ్య ఏకీకరణ పరస్పర చర్య. ప్లాట్‌ఫారమ్ మేము అందుకున్న అన్ని లేబులింగ్ కోడ్‌లను మరియు వస్తువుల అంతటా ఈ కోడ్‌ల కదలిక యొక్క మొత్తం చరిత్రను కూడా నిల్వ చేస్తుంది మరియు లేబుల్ చేయబడిన ఉత్పత్తుల యొక్క రీ-గ్రేడింగ్‌ను తొలగించడంలో సహాయపడుతుంది. లేబుల్ చేయబడిన వస్తువుల యొక్క మొదటి సమూహాలలో చేర్చబడిన పొగాకు ఉత్పత్తుల ఉదాహరణను ఉపయోగించి, కేవలం ఒక ట్రక్కు సిగరెట్‌లు దాదాపు 600 ప్యాక్‌లను కలిగి ఉంటాయి, వీటిలో ప్రతి దాని స్వంత ప్రత్యేక కోడ్‌ను కలిగి ఉంటుంది. మరియు గిడ్డంగులు మరియు దుకాణాల మధ్య అటువంటి ప్రతి ప్యాక్ యొక్క కదలికల యొక్క చట్టబద్ధతను ట్రాక్ చేయడం మరియు ధృవీకరించడం మరియు చివరికి కొనుగోలుదారుకు వాటి విక్రయం యొక్క ఆమోదయోగ్యతను ధృవీకరించడం మా సిస్టమ్ యొక్క పని. మరియు మేము గంటకు 000 నగదు లావాదేవీలను రికార్డ్ చేస్తాము మరియు అలాంటి ప్రతి ప్యాక్ స్టోర్‌లోకి ఎలా వచ్చిందో కూడా మేము రికార్డ్ చేయాలి. ఈ విధంగా, వస్తువుల మధ్య అన్ని కదలికలను పరిగణనలోకి తీసుకుంటే, మేము సంవత్సరానికి పదుల బిలియన్ల రికార్డులను ఆశిస్తున్నాము.

బృందం M

మార్కస్ X5 లోపల ప్రాజెక్ట్‌గా పరిగణించబడుతున్నప్పటికీ, ఇది ఉత్పత్తి విధానాన్ని ఉపయోగించి అమలు చేయబడుతోంది. బృందం స్క్రమ్ ప్రకారం పనిచేస్తుంది. ప్రాజెక్ట్ గత వేసవిలో ప్రారంభమైంది, కానీ మొదటి ఫలితాలు అక్టోబర్‌లో మాత్రమే వచ్చాయి - మా స్వంత బృందం పూర్తిగా సమావేశమైంది, సిస్టమ్ ఆర్కిటెక్చర్ అభివృద్ధి చేయబడింది మరియు పరికరాలు కొనుగోలు చేయబడ్డాయి. ఇప్పుడు బృందంలో 16 మంది ఉన్నారు, వీరిలో ఆరుగురు బ్యాకెండ్ మరియు ఫ్రంటెండ్ డెవలప్‌మెంట్‌లో పాల్గొంటున్నారు, వీరిలో ముగ్గురు సిస్టమ్ విశ్లేషణలో పాల్గొంటున్నారు. మరో ఆరుగురు వ్యక్తులు మాన్యువల్, లోడ్, ఆటోమేటెడ్ టెస్టింగ్ మరియు ఉత్పత్తి నిర్వహణలో పాల్గొంటున్నారు. అదనంగా, మాకు SRE స్పెషలిస్ట్ ఉన్నారు.

మా బృందంలో డెవలపర్‌లు మాత్రమే కోడ్‌ని వ్రాయరు; ఆటోటెస్ట్‌లు, లోడ్ స్క్రిప్ట్‌లు మరియు ఆటోమేషన్ స్క్రిప్ట్‌లను ప్రోగ్రామ్ చేయడం మరియు వ్రాయడం ఎలాగో దాదాపు అందరు అబ్బాయిలకు తెలుసు. ఉత్పత్తి మద్దతుకు కూడా అధిక స్థాయి ఆటోమేషన్ అవసరం కాబట్టి మేము దీనిపై ప్రత్యేక శ్రద్ధ చూపుతాము. ఇంతకు ముందు ప్రోగ్రామ్ చేయని సహోద్యోగులకు సలహా ఇవ్వడానికి మరియు సహాయం చేయడానికి మేము ఎల్లప్పుడూ ప్రయత్నిస్తాము మరియు వారికి పని చేయడానికి కొన్ని చిన్న పనులను అందిస్తాము.

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

రిమోట్ బృందం సమావేశం

రిమోట్ పని సమయంలో సమావేశాలు

పరిష్కారం యొక్క సాంకేతిక స్టాక్

X5 కోసం ప్రామాణిక రిపోజిటరీ మరియు CI/CD సాధనం GitLab. మేము కోడ్ నిల్వ, నిరంతర పరీక్ష మరియు పరీక్ష మరియు ఉత్పత్తి సర్వర్‌లకు విస్తరణ కోసం దీనిని ఉపయోగిస్తాము. డెవలపర్ కోడ్‌లో చేసిన మార్పులను కనీసం 2 మంది సహోద్యోగులు ఆమోదించాల్సిన అవసరం వచ్చినప్పుడు కూడా మేము కోడ్ సమీక్ష అభ్యాసాన్ని ఉపయోగిస్తాము. స్టాటిక్ కోడ్ ఎనలైజర్లు SonarQube మరియు JaCoCo మా కోడ్‌ను శుభ్రంగా ఉంచడంలో మరియు యూనిట్ టెస్ట్ కవరేజీని అవసరమైన స్థాయిని నిర్ధారించడంలో మాకు సహాయపడతాయి. కోడ్‌లోని అన్ని మార్పులు తప్పనిసరిగా ఈ తనిఖీల ద్వారా జరగాలి. మాన్యువల్‌గా అమలు చేయబడిన అన్ని టెస్ట్ స్క్రిప్ట్‌లు తర్వాత ఆటోమేట్ చేయబడతాయి.

"మార్కస్" ద్వారా వ్యాపార ప్రక్రియలను విజయవంతంగా అమలు చేయడానికి, మేము అనేక సాంకేతిక సమస్యలను పరిష్కరించాల్సి ఉంటుంది, వాటిలో ప్రతి ఒక్కటి.

టాస్క్ 1. సిస్టమ్ యొక్క క్షితిజ సమాంతర స్కేలబిలిటీ అవసరం

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

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

మేము బాహ్య సిస్టమ్‌లతో పరస్పర చర్య కోసం మాడ్యూల్‌లను ప్రత్యేక సేవలుగా విభజించాలని నిర్ణయించుకున్నాము. వ్యాపార కార్యాచరణతో సేవలపై వాస్తవంగా ఎటువంటి ప్రభావం లేకుండా, బాహ్య వ్యవస్థల యొక్క తరచుగా మారుతున్న APIల సమస్యను పరిష్కరించడం ఇది సాధ్యపడింది.

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

టాస్క్ 2. ప్లాట్‌ఫారమ్ సేవల మధ్య అధిక లోడ్ మరియు చాలా ఇంటెన్సివ్ డేటా మార్పిడిని నిర్వహించాల్సిన అవసరం: ప్రాజెక్ట్ ప్రయోగ దశలోనే, సెకనుకు దాదాపు 600 ఆపరేషన్లు జరుగుతాయి. రిటైల్ అవుట్‌లెట్‌లు మా ప్లాట్‌ఫారమ్‌కి కనెక్ట్ అయినందున ఈ విలువ 5000 ops/సెకనుకు పెరుగుతుందని మేము ఆశిస్తున్నాము.

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

సేవలను నిర్వహించేటప్పుడు లేదా కాఫ్కా బ్యాచ్‌తో పనిచేసేటప్పుడు మినహాయింపులు సంభవించినప్పుడు వారి ట్రేస్‌ఐడ్ కోల్పోకుండా ఉండేలా లాగ్‌లను గుర్తించడంపై చాలా శ్రద్ధ పెట్టారు. మరియు మొదటిదానితో ప్రత్యేక సమస్యలు లేనట్లయితే, రెండవ సందర్భంలో, బ్యాచ్‌తో వచ్చిన అన్ని ట్రేస్‌ఐడ్‌లను లాగిన్ చేసి, ట్రేసింగ్‌ను కొనసాగించడానికి ఒకదాన్ని ఎంచుకోవలసి వస్తుంది. అప్పుడు, అసలు TraceId ద్వారా శోధిస్తున్నప్పుడు, వినియోగదారు ఏ ట్రేసింగ్ కొనసాగిందో సులభంగా కనుగొంటారు.

పని 3. పెద్ద మొత్తంలో డేటాను నిల్వ చేయవలసిన అవసరం: పొగాకు కోసం సంవత్సరానికి 1 బిలియన్ కంటే ఎక్కువ లేబుల్‌లు X5కి వస్తాయి. వారికి స్థిరమైన మరియు శీఘ్ర ప్రాప్యత అవసరం. మొత్తంగా, ఈ లేబుల్ చేయబడిన వస్తువుల కదలిక చరిత్రకు సంబంధించిన 10 బిలియన్ల రికార్డులను సిస్టమ్ తప్పనిసరిగా ప్రాసెస్ చేయాలి.

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

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

టాస్క్ 4: క్యూ రీప్రాసెసింగ్ మరియు పర్యవేక్షణ:

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

అటువంటి పథకాన్ని అమలు చేయడానికి, మాకు ఈ క్రిందివి అవసరం: ఈ పరిష్కారాన్ని స్ప్రింగ్‌తో ఏకీకృతం చేయడానికి మరియు కోడ్ డూప్లికేషన్‌ను నివారించడానికి. వెబ్‌లో సర్ఫింగ్ చేస్తున్నప్పుడు, మేము Spring BeanPostProccessor ఆధారంగా ఇదే విధమైన పరిష్కారాన్ని చూశాము, కానీ అది మాకు అనవసరంగా గజిబిజిగా అనిపించింది. మా బృందం వినియోగదారులను సృష్టించడం కోసం స్ప్రింగ్ సైకిల్‌లో కలిసిపోవడానికి మరియు వినియోగదారులను మళ్లీ జోడించడానికి అనుమతించే సరళమైన పరిష్కారాన్ని రూపొందించింది. మేము స్ప్రింగ్ బృందానికి మా పరిష్కారం యొక్క నమూనాను అందించాము, మీరు దానిని చూడవచ్చు ఇక్కడ. మళ్లీ ప్రయత్నించే వినియోగదారుల సంఖ్య మరియు ప్రతి వినియోగదారు కోసం ప్రయత్నాల సంఖ్య వ్యాపార ప్రక్రియ యొక్క అవసరాలపై ఆధారపడి పారామితుల ద్వారా కాన్ఫిగర్ చేయబడతాయి మరియు ప్రతిదీ పని చేయడానికి, ఉల్లేఖనాన్ని జోడించడం మాత్రమే మిగిలి ఉంది org.springframework.kafka.annotation.KafkaListener , ఇది స్ప్రింగ్ డెవలపర్‌లందరికీ సుపరిచితం.

అన్ని రీట్రీ ప్రయత్నాల తర్వాత సందేశాన్ని ప్రాసెస్ చేయలేకపోతే, అది స్ప్రింగ్ డెడ్‌లెటర్‌పబ్లిషింగ్ రికవర్‌ని ఉపయోగించి DLT (డెడ్ లెటర్ టాపిక్)కి వెళుతుంది. మద్దతు అభ్యర్థన మేరకు, మేము ఈ కార్యాచరణను విస్తరించాము మరియు DLT, stackTrace, traceId మరియు వాటి గురించిన ఇతర ఉపయోగకరమైన సమాచారంలో చేర్చబడిన సందేశాలను వీక్షించడానికి మిమ్మల్ని అనుమతించే ప్రత్యేక సేవను సృష్టించాము. అదనంగా, అన్ని DLT అంశాలకు పర్యవేక్షణ మరియు హెచ్చరికలు జోడించబడ్డాయి మరియు ఇప్పుడు, వాస్తవానికి, DLT అంశంలో సందేశం కనిపించడం అనేది లోపాన్ని విశ్లేషించడానికి మరియు పరిష్కరించడానికి ఒక కారణం. ఇది చాలా సౌకర్యవంతంగా ఉంటుంది - టాపిక్ పేరు ద్వారా, సమస్య ఏ ప్రక్రియలో తలెత్తిందో మేము వెంటనే అర్థం చేసుకుంటాము, ఇది దాని మూల కారణం కోసం శోధనను గణనీయంగా వేగవంతం చేస్తుంది.

ఇటీవల, మేము సందేశాలను వాటి కారణాలను తొలగించిన తర్వాత (ఉదాహరణకు, బాహ్య వ్యవస్థ యొక్క కార్యాచరణను పునరుద్ధరించడం) మరియు విశ్లేషణ కోసం సంబంధిత లోపాన్ని స్థాపించిన తర్వాత మా మద్దతును ఉపయోగించి మళ్లీ పంపడానికి అనుమతించే ఇంటర్‌ఫేస్‌ను అమలు చేసాము. ఇక్కడే మా స్వీయ-విషయాలు ఉపయోగపడతాయి: సుదీర్ఘ ప్రాసెసింగ్ గొలుసును పునఃప్రారంభించకుండా ఉండటానికి, మీరు కోరుకున్న దశ నుండి దాన్ని పునఃప్రారంభించవచ్చు.

ప్లాట్ఫారమ్ ఆపరేషన్

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

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

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

ఇప్పుడు మేము మా ప్లాట్‌ఫారమ్‌ను అభివృద్ధి చేయడం మరియు మెరుగుపరచడం కొనసాగిస్తున్నాము మరియు నిరంతరం కొత్త సవాళ్లను ఎదుర్కొంటాము. మీకు ఆసక్తి ఉంటే, మేము ఈ క్రింది కథనాలలో మా పరిష్కారాల గురించి మాట్లాడుతాము.

మూలం: www.habr.com