2019 සිට රුසියාවට අනිවාර්ය ලේබල් කිරීම පිළිබඳ නීතියක් තිබේ. සියලුම භාණ්ඩ කාණ්ඩ සඳහා නීතිය අදාළ නොවන අතර නිෂ්පාදන කණ්ඩායම් සඳහා අනිවාර්ය ලේබල් කිරීම බලාත්මක වන දින වෙනස් වේ. දුම්කොළ, සපත්තු සහ ඖෂධ අනිවාර්ය ලේබල් කිරීමකට යටත් වන පළමු ඒවා වේ; වෙනත් නිෂ්පාදන පසුව එකතු කරනු ලැබේ, උදාහරණයක් ලෙස, සුවඳ විලවුන්, රෙදිපිළි සහ කිරි. මෙම ව්‍යවස්ථාදායක නවෝත්පාදනය නව තොරතුරු තාක්ෂණ විසඳුම් සංවර්ධනය කිරීමට පෙළඹවූ අතර එමඟින් නිෂ්පාදනයේ සමස්ත ජීවන දාමය නිෂ්පාදනයේ සිට මිලදී ගැනීම දක්වා ක්‍රියාවලියට සහභාගී වන සියලුම සහභාගිවන්නන්ට නිරීක්ෂණය කිරීමට හැකි වේ: රජයම සහ භාණ්ඩ අලෙවි කරන සියලුම සංවිධාන. අනිවාර්ය ලේබල් කිරීම.
X5 හි, ලේබල් කරන ලද භාණ්ඩ ලුහුබැඳීම සහ රාජ්‍යය සහ සැපයුම්කරුවන් සමඟ දත්ත හුවමාරු කරන පද්ධතිය "Marcus" ලෙස හැඳින්වේ. එය දියුණු කළේ කෙසේද සහ කවුරුන්ද, එහි තාක්ෂණික තොගය කුමක්ද සහ අපට ආඩම්බර වීමට යමක් ඇත්තේ මන්දැයි අපි ඔබට පිළිවෙලට කියමු.
සැබෑ හයිලෝඩ්
"Marcus" බොහෝ ගැටළු විසඳයි, ප්රධාන එක වන්නේ ලේබල් කරන ලද නිෂ්පාදනවල චලනය නිරීක්ෂණය කිරීම සඳහා X5 තොරතුරු පද්ධති සහ ලේබල් නිෂ්පාදන සඳහා රාජ්ය තොරතුරු පද්ධතිය (GIS MP) අතර ඒකාබද්ධ අන්තර්ක්රියා වේ. වේදිකාව අපට ලැබුණු සියලුම ලේබල් කිරීමේ කේත සහ වස්තූන් හරහා මෙම කේත චලනය කිරීමේ සම්පූර්ණ ඉතිහාසය ගබඩා කරයි, සහ ලේබල් කළ නිෂ්පාදන නැවත ශ්‍රේණිගත කිරීම ඉවත් කිරීමට උපකාරී වේ. ලේබල් කරන ලද භාණ්ඩවල පළමු කාණ්ඩවලට ඇතුළත් කර ඇති දුම්කොළ නිෂ්පාදනවල උදාහරණය භාවිතා කරමින්, එක් ට්‍රක් රථයක සිගරට් පැකට් 600 ක් පමණ අඩංගු වන අතර, ඒ සෑම එකක්ම තමන්ගේම අද්විතීය කේතයක් ඇත. අපගේ පද්ධතියේ කර්තව්‍යය වන්නේ ගබඩා සහ වෙළඳසැල් අතර එවැනි එක් එක් ඇසුරුමේ චලනයන්හි නීත්‍යානුකූලභාවය සොයා බැලීම සහ සත්‍යාපනය කිරීම සහ අවසානයේ අවසාන ගැනුම්කරුට ඒවා විකිණීමේ පිළිගැනීම තහවුරු කිරීමයි. තවද අපි පැයකට මුදල් ගනුදෙනු 000 ක් පමණ වාර්තා කරන අතර, එවැනි එක් පැකේජයක් ගබඩාවට ඇතුළු වූ ආකාරය ද වාර්තා කළ යුතුය. මේ අනුව, වස්තූන් අතර සියලු චලනයන් සැලකිල්ලට ගනිමින්, අපි වසරකට වාර්තා බිලියන දස දහස් ගණනක් අපේක්ෂා කරමු.
කණ්ඩායම එම්
මාකස් X5 තුළ ව්‍යාපෘතියක් ලෙස සලකනු ලැබුවද, එය ක්රියාත්මක වන්නේ නිෂ්පාදන ප්රවේශයක් භාවිතා කරමිනි. කණ්ඩායම Scrum අනුව ක්රියා කරයි. ව්‍යාපෘතිය පසුගිය ගිම්හානයේදී ආරම්භ වූ නමුත් පළමු ප්‍රති result ලය පැමිණියේ ඔක්තෝබර් මාසයේදී පමණි - අපගේම කණ්ඩායම සම්පූර්ණයෙන්ම එකලස් කර, පද්ධති ගෘහ නිර්මාණ ශිල්පය සංවර්ධනය කර උපකරණ මිලදී ගන්නා ලදී. දැන් කණ්ඩායමට පුද්ගලයින් 16 දෙනෙකු සිටින අතර, ඔවුන්ගෙන් හය දෙනෙකු පසුපෙළ සහ ඉදිරිපස සංවර්ධනයට සම්බන්ධ වන අතර, ඔවුන්ගෙන් තිදෙනෙකු පද්ධති විශ්ලේෂණයට සම්බන්ධ වේ. තවත් පුද්ගලයින් හය දෙනෙකු අතින්, පැටවීම, ස්වයංක්රීය පරීක්ෂාව සහ නිෂ්පාදන නඩත්තුව සඳහා සම්බන්ධ වේ. ඊට අමතරව, අපට SRE විශේෂඥයෙක් සිටී.
සංවර්ධකයින් පමණක් අපගේ කණ්ඩායම තුළ කේතය ලියන්නේ නැත; සියලුම පිරිමි ළමයින් පාහේ ස්වයංක්රීය පරීක්ෂණ ක්‍රමලේඛනය සහ ලිවීම, ස්ක්‍රිප්ට් පැටවීම සහ ස්වයංක්රීය ස්ක්‍රිප්ට් දනිති. නිෂ්පාදන සහාය සඳහා පවා ඉහළ මට්ටමේ ස්වයංක්‍රීයකරණයක් අවශ්ය වන බැවින් අපි මේ පිළිබඳව විශේෂ අවධානයක් යොමු කරමු. මීට පෙර වැඩසටහන්ගත නොකළ සගයන්ට උපදෙස් දීමට සහ උපකාර කිරීමට අපි සැමවිටම උත්සාහ කරමු, ඔවුන්ට වැඩ කිරීමට කුඩා කාර්යයන් කිහිපයක් ලබා දෙන්න.
කොරෝනා වයිරස් වසංගතය හේතුවෙන්, අපි මුළු කණ්ඩායමම දුරස්ථ වැඩකට මාරු කළෙමු; සංවර්ධන කළමනාකරණය සඳහා සියලුම මෙවලම් තිබීම, ජිරා සහ GitLab හි ගොඩනඟන ලද කාර්ය ප්‍රවාහය මෙම අදියර පහසුවෙන් පසු කිරීමට හැකි විය. දුරස්ථව ගත කළ මාස පෙන්නුම් කළේ කණ්ඩායමේ ඵලදායිතාව එහි ප්‍රති result ලයක් නොවන බවයි; බොහෝ දෙනෙකුට, රැකියාවේ සුවපහසුව වැඩි විය, අතුරුදහන් වූ එකම දෙය සජීවී සන්නිවේදනයයි.
දුරස්ථ කණ්ඩායම් රැස්වීම
දුරස්ථ වැඩ අතරතුර රැස්වීම්
විසඳුමේ තාක්ෂණික තොගය
X5 සඳහා සම්මත ගබඩාව සහ CI/CD මෙවලම GitLab වේ. අපි එය කේත ගබඩා කිරීම, අඛණ්ඩ පරීක්ෂා කිරීම සහ පරීක්ෂණ සහ නිෂ්පාදන සේවාදායකයන් වෙත යෙදවීම සඳහා භාවිතා කරමු. සංවර්ධකයා විසින් කේතයට කරන ලද වෙනස්කම් අනුමත කිරීමට අවම වශයෙන් සගයන් 2 දෙනෙකුට අවශ්ය වූ විට, අපි කේත සමාලෝචන භාවිතය ද භාවිතා කරමු. ස්ථිතික කේත විශ්ලේෂක SonarQube සහ JaCoCo අපගේ කේතය පිරිසිදුව තබා ගැනීමට සහ අවශ්ය ඒකක පරීක්ෂණ ආවරණය සහතික කිරීමට අපට උදවු කරයි. කේතයේ සියලුම වෙනස්කම් මෙම චෙක්පත් හරහා යා යුතුය. අතින් ධාවනය වන සියලුම පරීක්ෂණ ස්ක්‍රිප්ට් පසුව ස්වයංක්රීය වේ.
"මාකස්" විසින් ව්‍යාපාරික ක්‍රියාවලීන් සාර්ථකව ක්රියාත්මක කිරීම සඳහා, අපට තාක්ෂණික ගැටළු ගණනාවක් විසඳීමට සිදු විය, ඒ සෑම එකක්ම පිළිවෙලට.
කාර්යය 1. පද්ධතියේ තිරස් පරිමාණය සඳහා අවශ්යතාවය
මෙම ගැටළුව විසඳීම සඳහා, අපි ගෘහ නිර්මාණ ශිල්පය සඳහා ක්ෂුද්ර සේවා ප්රවේශයක් තෝරා ගත්තෙමු. ඒ අතරම, සේවාවන්හි වගකීම් ක්ෂේත්‍ර අවබෝධ කර ගැනීම ඉතා වැදගත් විය. ක්‍රියාවලීන්ගේ විශේෂතා සැලකිල්ලට ගනිමින් අපි ඒවා ව්‍යාපාරික මෙහෙයුම් වලට බෙදීමට උත්සාහ කළෙමු. නිදසුනක් වශයෙන්, ගබඩාවක පිළිගැනීම ඉතා සුලභ නමුත් ඉතා විශාල පරිමාණ මෙහෙයුමක් වන අතර, එම කාලය තුළ පිළිගනු ලබන භාණ්ඩ ඒකක පිළිබඳ රාජ්ය නියාමකයෙකුගෙන් තොරතුරු ඉක්මනින් ලබා ගැනීම අවශ්ය වන අතර, එක් භාරදීමකදී එම සංඛ්‍යාව 600000 දක්වා ළඟා වේ. , මෙම නිෂ්පාදනය ගබඩාවට පිළිගැනීමේ පිළිගැනීම පරීක්ෂා කර ගබඩා ස්වයංක්‍රීයකරණ පද්ධතිය සඳහා අවශ්ය සියලු තොරතුරු ආපසු ලබා දෙන්න. නමුත් ගබඩා වලින් නැව්ගත කිරීම වඩා වැඩි තීව්රතාවයක් ඇත, නමුත් ඒ සමගම කුඩා දත්ත පරිමාවන් සමඟ ක්රියා කරයි.
අපි සියලු සේවාවන් රාජ්ය රහිත පදනමක් මත ක්රියාත්මක කරන අතර අභ්‍යන්තර මෙහෙයුම් පියවරවලට බෙදීමට පවා උත්සාහ කරමු, අපි Kafka ස්වයං-මාතෘකා ලෙස හඳුන්වන දේ භාවිතා කරමු. මෙය සිදුවන්නේ ක්ෂුද්ර සේවාවක් තමාටම පණිවිඩයක් යවන විට, එමඟින් ඔබට වැඩි සම්පත්-දැඩි මෙහෙයුම් වල බර සමතුලිත කිරීමට සහ නිෂ්පාදන නඩත්තුව සරල කිරීමට ඉඩ සලසයි, නමුත් පසුව ඒ ගැන වැඩි විස්තර.
බාහිර පද්ධති සමඟ අන්තර්ක්රියා කිරීම සඳහා මොඩියුල වෙනම සේවාවන් බවට වෙන් කිරීමට අපි තීරණය කළෙමු. ව්‍යාපාරික ක්‍රියාකාරීත්වය සහිත සේවාවන් කෙරෙහි ප්‍රායෝගිකව කිසිදු බලපෑමක් නොමැතිව, බාහිර පද්ධතිවල API නිතර වෙනස් කිරීමේ ගැටලුව විසඳීමට මෙය හැකි විය.
සියලුම ක්ෂුද්ර සේවා OpenShift පොකුරක් තුළ යොදවා ඇත, එමඟින් එක් එක් ක්ෂුද්ර සේවා පරිමාණය කිරීමේ ගැටලුව දෙකම විසඳන අතර අපට තෙවන පාර්ශවීය සේවා සොයාගැනීම් මෙවලම් භාවිතා නොකිරීමට ඉඩ සලසයි.
කාර්යය 2. වේදිකා සේවා අතර ඉහළ බරක් සහ ඉතා තීව්‍ර දත්ත හුවමාරුවක් පවත්වා ගැනීමේ අවශ්යතාවය: ව්‍යාපෘති දියත් කිරීමේ අදියරේදී පමණක් තත්පරයකට මෙහෙයුම් 600ක් පමණ සිදු කෙරේ. සිල්ලර අලෙවිසැල් අපගේ වේදිකාවට සම්බන්ධ වන බැවින් මෙම අගය ops/sec 5000 දක්වා වැඩි වනු ඇතැයි අපි අපේක්ෂා කරමු.
කෆ්කා පොකුරක් යෙදවීමෙන් සහ වේදිකාවේ ක්ෂුද්ර සේවා අතර සමමුහුර්ත අන්තර්ක්රියා සම්පූර්ණයෙන්ම පාහේ අත්හැරීමෙන් මෙම ගැටළුව විසඳා ඇත. සියලුම මෙහෙයුම් අසමමුහුර්ත විය නොහැකි බැවින් මේ සඳහා පද්ධති අවශ්‍යතා පිළිබඳ ඉතා ප්‍රවේශමෙන් විශ්ලේෂණයක් අවශ්ය වේ. ඒ අතරම, අපි තැරැව්කරු හරහා සිදුවීම් සම්ප්‍රේෂණය කරනවා පමණක් නොව, අවශ්ය සියලුම ව්‍යාපාරික තොරතුරු පණිවිඩයේ සම්ප්‍රේෂණය කරන්නෙමු. මේ අනුව, පණිවිඩ ප්රමාණය කිලෝබයිට් සිය ගණනකට ළඟා විය හැකිය. Kafka හි පණිවිඩ ප්‍රමාණයේ සීමාව අපට පණිවිඩ ප්රමාණය නිවැරදිව පුරෝකථනය කිරීමට අවශ්ය වන අතර, අවශ්ය නම්, අපි ඒවා බෙදන්නෙමු, නමුත් බෙදීම තාර්කික ය, ව්‍යාපාර මෙහෙයුම් වලට සම්බන්ධ වේ.
උදාහරණයක් ලෙස, අපි මෝටර් රථයකින් පැමිණෙන භාණ්ඩ පෙට්ටිවලට බෙදන්නෙමු. සමමුහුර්ත මෙහෙයුම් සඳහා, වෙනම ක්ෂුද්ර සේවා වෙන් කර ඇති අතර සම්පූර්ණ බර පරීක්ෂාව සිදු කරනු ලැබේ. කෆ්කා භාවිතා කිරීම අපට තවත් අභියෝගයක් ඉදිරිපත් කළේය - කෆ්කා ඒකාබද්ධතාවය සැලකිල්ලට ගනිමින් අපගේ සේවාවේ ක්‍රියාකාරිත්වය පරීක්ෂා කිරීම අපගේ සියලුම ඒකක පරීක්ෂණ අසමමිතික කරයි. Embedded Kafka Broker භාවිතයෙන් අපගේම උපයෝගිතා ක්‍රම ලිවීමෙන් අපි මෙම ගැටලුව විසඳා ගත්තෙමු. මෙය තනි ක්‍රම සඳහා ඒකක පරීක්ෂණ ලිවීමේ අවශ්යතාවය ඉවත් නොකරයි, නමුත් අපි Kafka භාවිතයෙන් සංකීර්ණ අවස්ථා පරීක්ෂා කිරීමට කැමැත්තෙමු.
සේවා ක්රියාත්මක කිරීමේදී හෝ Kafka කණ්ඩායම සමඟ වැඩ කිරීමේදී ව්‍යතිරේක ඇති වූ විට ඒවායේ TraceId නැති නොවන පරිදි ලොග් සොයා ගැනීම කෙරෙහි වැඩි අවධානයක් යොමු කරන ලදී. පළමු එක සමඟ විශේෂ ගැටළු නොමැති නම්, දෙවන අවස්ථාවෙහිදී, කණ්ඩායම සමඟ පැමිණි සියලුම TraceId ලොග් කිරීමට අපට බල කෙරෙන අතර දිගටම ලුහුබැඳීම සඳහා එකක් තෝරන්න. ඉන්පසුව, මුල් TraceId මඟින් සෙවීමේදී, ලුහුබැඳීම දිගටම පැවතියේ කුමන ආකාරයෙන්ද යන්න පරිශීලකයාට පහසුවෙන් සොයාගත හැකිය.
කාර්යය 3. විශාල දත්ත ප්‍රමාණයක් ගබඩා කිරීමේ අවශ්යතාවය: දුම්කොළ සඳහා පමණක් වසරකට ලේබල් බිලියන 1 කට වඩා X5 වෙත පැමිණේ. ඔවුන්ට නිරන්තර හා ඉක්මන් ප්රවේශයක් අවශ්ය වේ. සමස්තයක් වශයෙන්, පද්ධතිය මෙම ලේබල් කළ භාණ්ඩවල සංචලන ඉතිහාසය පිළිබඳ වාර්තා බිලියන 10 ක් පමණ සැකසිය යුතුය.
තෙවන ගැටළුව විසඳීම සඳහා, NoSQL දත්ත සමුදාය MongoDB තෝරා ගන්නා ලදී. අපි නෝඩ් 5 ක කැබැල්ලක් සාදා ඇති අතර සෑම නෝඩයකටම සේවාදායක 3 ක අනුරූ කට්ටලයක් ඇත. මෙමගින් ඔබට පද්ධතිය තිරස් අතට පරිමාණය කිරීමටත්, පොකුරට නව සේවාදායකයන් එකතු කිරීමටත්, එහි වැරදි ඉවසීම සහතික කිරීමටත් ඉඩ සලසයි. මෙහිදී අපට තවත් ගැටලුවකට මුහුණ දීමට සිදු විය - තිරස් අතට පරිමාණය කළ හැකි ක්ෂුද්ර සේවා භාවිතය සැලකිල්ලට ගනිමින් මොංගෝ පොකුරේ ගනුදෙනුව සහතික කිරීම. උදාහරණයක් ලෙස, අපගේ පද්ධතියේ එක් කාර්යයක් වන්නේ එකම ලේබල් කිරීමේ කේත සහිත නිෂ්පාදන නැවත විකිණීමේ උත්සාහයන් හඳුනා ගැනීමයි. මෙහිදී, අයකැමියන් විසින් වැරදි ස්කෑන් කිරීම් හෝ වැරදි මෙහෙයුම් සමඟ උඩින් දිස් වේ. එවැනි අනුපිටපත් සැකසෙන එක් කෆ්කා කණ්ඩායමක් තුළ සහ සමාන්තරව සකසන ලද කණ්ඩායම් දෙකක් තුළ සිදු විය හැකි බව අපට පෙනී ගියේය. මේ අනුව, දත්ත සමුදාය විමසා අනුපිටපත් පරීක්ෂා කිරීම කිසිවක් ලබා දුන්නේ නැත. එක් එක් ක්ෂුද්ර සේවා සඳහා, අපි මෙම සේවාවේ ව්‍යාපාරික තර්කනය මත පදනම්ව ගැටලුව වෙන වෙනම විසඳා ගත්තෙමු. උදාහරණයක් ලෙස, චෙක්පත් සඳහා, අපි ඇතුළු කරන විට අනුපිටපත් පෙනුම සඳහා කණ්ඩායම සහ වෙනම සැකසුම් ඇතුළත චෙක්පතක් එකතු කළා.
මෙහෙයුම් ඉතිහාසය සමඟ පරිශීලකයින්ගේ වැඩ කටයුතු කිසිදු ආකාරයකින් වඩාත්ම වැදගත් දෙයට බලපාන්නේ නැති බව සහතික කිරීම සඳහා - අපගේ ව්‍යාපාර ක්‍රියාවලීන්ගේ ක්‍රියාකාරිත්වය, අපි සියලුම ඓතිහාසික දත්ත වෙනම දත්ත සමුදායක් සහිත වෙනම සේවාවකට වෙන් කර ඇති අතර එය Kafka හරහාද තොරතුරු ලැබේ. . මේ ආකාරයෙන්, පරිශීලකයන් හුදකලා සේවාවක් සමඟ වැඩ කරමින් පවතින මෙහෙයුම් සඳහා දත්ත සකසන සේවාවන්ට බලපෑම් නොකරයි.
කාර්යය 4: පෝලිම් නැවත සැකසීම සහ අධීක්ෂණය:
බෙදා හරින ලද පද්ධතිවල, දත්ත සමුදායන්, පෝලිම් සහ බාහිර දත්ත මූලාශ්‍ර ලබා ගැනීමේ දී ගැටළු සහ දෝෂ නොවැළැක්විය හැකිය. මාකස් සම්බන්ධයෙන් ගත් කල, එවැනි දෝෂ වල මූලාශ්රය වන්නේ බාහිර පද්ධති සමඟ ඒකාබද්ධ වීමයි. යම් නිශ්චිත කාල සීමාවක් සමඟ වැරදි ප්‍රතිචාර සඳහා නැවත නැවත ඉල්ලීම් කිරීමට ඉඩ සලසන විසඳුමක් සෙවීම අවශ්ය විය, නමුත් ඒ සමඟම ප්රධාන පෝලිමේ සාර්ථක ඉල්ලීම් සැකසීම නතර නොකරන්න. මෙම කාර්යය සඳහා, ඊනියා "මාතෘකාව පදනම් වූ නැවත උත්සාහ" සංකල්පය තෝරා ගන්නා ලදී. සෑම ප්රධාන මාතෘකාවක් සඳහාම, වැරදි පණිවිඩ යවනු ලබන නැවත උත්සාහ කිරීමේ මාතෘකා එකක් හෝ කිහිපයක් සාදනු ලබන අතර ඒ සමඟම ප්රධාන මාතෘකාවෙන් පණිවිඩ සැකසීමේ ප්‍රමාදය ඉවත් කරනු ලැබේ. අන්තර්ක්රියා යෝජනා ක්රමය -
එවැනි යෝජනා ක්රමයක් ක්රියාත්මක කිරීම සඳහා, අපට පහත සඳහන් දෑ අවශ්ය විය: මෙම විසඳුම වසන්තය සමඟ ඒකාබද්ධ කිරීම සහ කේත අනුපිටපත් කිරීම වැළැක්වීම. වෙබයේ සැරිසරන අතරතුර, අපට Spring BeanPostProccessor මත පදනම් වූ සමාන විසඳුමක් හමු වූ නමුත් එය අපට අනවශ්‍ය ලෙස අපහසු විය. අපගේ කණ්ඩායම පාරිභෝගිකයින් නිර්මාණය කිරීම සඳහා වසන්ත චක්‍රයට ඒකාබද්ධ වීමට සහ අතිරේකව නැවත උත්සාහ කරන්න පාරිභෝගිකයින් එක් කිරීමට ඉඩ සලසන සරල විසඳුමක් සාදා ඇත. අපි අපගේ විසඳුමේ මූලාකෘතියක් වසන්ත කණ්ඩායමට ඉදිරිපත් කළෙමු, ඔබට එය දැකිය හැකිය . නැවත උත්සාහ කරන පාරිභෝගිකයින් සංඛ්‍යාව සහ එක් එක් පාරිභෝගිකයා සඳහා වන උත්සාහයන් ව්‍යාපාර ක්‍රියාවලියේ අවශ්‍යතා මත පරාමිති හරහා වින්‍යාස කර ඇති අතර සෑම දෙයක්ම ක්රියාත්මක වීමට ඉතිරිව ඇත්තේ org.springframework.kafka.annotation.KafkaListener විවරණ එකතු කිරීම පමණි. , එය සියලුම වසන්ත සංවර්ධකයින්ට හුරුපුරුදුය.
සියලු නැවත උත්සාහ කිරීමෙන් පසුව පණිවිඩය සැකසීමට නොහැකි නම්, එය Spring DeadLetterPublishingRecoverer භාවිතයෙන් DLT (මළ අකුරු මාතෘකාව) වෙත යයි. සහාය ඉල්ලීම මත, අපි මෙම ක්‍රියාකාරිත්වය පුළුල් කර DLT, stackTrace, TraceId සහ ඒවා පිළිබඳ වෙනත් ප්‍රයෝජනවත් තොරතුරුවල ඇතුළත් පණිවිඩ බැලීමට ඔබට ඉඩ සලසන වෙනම සේවාවක් නිර්මාණය කළෙමු. ඊට අමතරව, සියලුම DLT මාතෘකා වෙත අධීක්ෂණය සහ ඇඟවීම් එකතු කරන ලද අතර, දැන්, ඇත්ත වශයෙන්ම, DLT මාතෘකාවක පණිවිඩයක් පෙනුම දෝෂයක් විශ්ලේෂණය කිරීමට සහ නිවැරදි කිරීමට හේතුවකි. මෙය ඉතා පහසු ය - මාතෘකාවේ නම අනුව, ගැටළුව ඇති වූ ක්‍රියාවලියේ කුමන පියවරේදීද යන්න අපි වහාම තේරුම් ගනිමු, එමඟින් එහි මූල හේතුව සෙවීම සැලකිය යුතු ලෙස වේගවත් කරයි.
ඉතා මෑතක දී, අපි ඔවුන්ගේ හේතු ඉවත් කිරීමෙන් පසුව (උදාහරණයක් ලෙස, බාහිර පද්ධතියේ ක්‍රියාකාරීත්වය යථා තත්ත්වයට පත් කිරීම) සහ, ඇත්ත වශයෙන්ම, විශ්ලේෂණය සඳහා අනුරූප දෝෂය ස්ථාපිත කිරීමෙන් පසු අපගේ සහාය භාවිතා කරමින් පණිවිඩ නැවත යැවීමට අපට ඉඩ සලසන අතුරු මුහුණතක් ක්රියාත්මක කර ඇත. අපගේ ස්වයං-මාතෘකා ප්‍රයෝජනවත් වන්නේ මෙහිදීය: දිගු සැකසුම් දාමයක් නැවත ආරම්භ නොකිරීමට, ඔබට එය අපේක්ෂිත පියවරෙන් නැවත ආරම්භ කළ හැකිය.
වේදිකා මෙහෙයුම
වේදිකාව දැනටමත් ඵලදායී ක්‍රියාකාරිත්වයේ පවතී, සෑම දිනකම අපි බෙදා හැරීම් සහ නැව්ගත කිරීම් සිදු කරන්නෙමු, නව බෙදාහැරීමේ මධ්‍යස්ථාන සහ වෙළඳසැල් සම්බන්ධ කරන්නෙමු. නියමුවාගේ කොටසක් ලෙස, පද්ධතිය "දුම්කොළ" සහ "සපත්තු" නිෂ්පාදන කණ්ඩායම් සමඟ ක්රියා කරයි.
අපගේ මුළු කණ්ඩායමම නියමුවන් මෙහෙයවීමට සහභාගී වේ, නැගී එන ගැටළු විශ්ලේෂණය කරයි සහ ලොග් වැඩි දියුණු කිරීමේ සිට ක්‍රියාවලි වෙනස් කිරීම දක්වා අපගේ නිෂ්පාදනය වැඩිදියුණු කිරීම සඳහා යෝජනා ඉදිරිපත් කරයි.
අපගේ වැරදි නැවත නොකිරීමට, නියමුවා තුළ සොයාගත් සියලුම සිද්ධීන් ස්වයංක්රීය පරීක්ෂණවලින් පිළිබිඹු වේ. ස්වයංක්රීය පරීක්ෂණ සහ ඒකක පරීක්ෂණ විශාල සංඛ්‍යාවක් තිබීම ඔබට ප්‍රතිගාමී පරීක්ෂණ සිදු කිරීමට සහ පැය කිහිපයක් ඇතුළත hotfix ස්ථාපනය කිරීමට ඉඩ සලසයි.
දැන් අපි අපගේ වේදිකාව සංවර්ධනය කිරීම සහ වැඩිදියුණු කිරීම දිගටම කරගෙන යන අතර නිරන්තරයෙන් නව අභියෝගවලට මුහුණ දෙන්නෙමු. ඔබ උනන්දුවක් දක්වන්නේ නම්, අපි පහත ලිපිවල අපගේ විසඳුම් ගැන කතා කරමු.
මූලාශ්රය: www.habr.com