"আমার জুতা হাঁটা" - অপেক্ষা করুন, তারা চিহ্নিত আছে?

2019 সাল থেকে, রাশিয়ায় বাধ্যতামূলক লেবেলিংয়ের একটি আইন রয়েছে। আইনটি পণ্যের সমস্ত গ্রুপের জন্য প্রযোজ্য নয় এবং পণ্য গোষ্ঠীগুলির জন্য বাধ্যতামূলক লেবেল প্রয়োগের জন্য প্রবেশের তারিখগুলি আলাদা। তামাক, জুতা, এবং ওষুধগুলি প্রথমে বাধ্যতামূলক লেবেলিং সাপেক্ষে হবে; অন্যান্য পণ্যগুলি পরে যোগ করা হবে, উদাহরণস্বরূপ, পারফিউম, টেক্সটাইল এবং দুধ৷ এই আইনী উদ্ভাবনটি নতুন আইটি সমাধানগুলির বিকাশের জন্য উদ্বুদ্ধ করেছে যা একটি পণ্যের সম্পূর্ণ জীবন শৃঙ্খলকে উত্পাদন থেকে ক্রয় পর্যন্ত শেষ ভোক্তাদের দ্বারা, প্রক্রিয়ার সমস্ত অংশগ্রহণকারীদের কাছে ট্র্যাক করা সম্ভব করবে: উভয় রাজ্য নিজেই এবং সমস্ত সংস্থা যা পণ্য বিক্রি করছে বাধ্যতামূলক লেবেলিং।

X5-এ, যে সিস্টেমটি লেবেলযুক্ত পণ্যগুলিকে ট্র্যাক করবে এবং রাষ্ট্র এবং সরবরাহকারীদের সাথে ডেটা বিনিময় করবে তাকে "মার্কাস" বলা হয়। আসুন আমরা আপনাকে বলি কিভাবে এবং কারা এটি তৈরি করেছে, এর প্রযুক্তি স্ট্যাক কী এবং কেন আমাদের গর্ব করার মতো কিছু আছে।

রিয়েল হাইলোড

"মার্কাস" অনেক সমস্যার সমাধান করে, প্রধানটি হল X5 তথ্য সিস্টেম এবং লেবেলযুক্ত পণ্যগুলির গতিবিধি ট্র্যাক করার জন্য লেবেলযুক্ত পণ্যগুলির (GIS MP) জন্য রাষ্ট্রীয় তথ্য ব্যবস্থার মধ্যে ইন্টিগ্রেশন মিথস্ক্রিয়া। প্ল্যাটফর্মটি আমাদের দ্বারা প্রাপ্ত সমস্ত লেবেলিং কোড এবং বস্তু জুড়ে এই কোডগুলির চলাচলের সম্পূর্ণ ইতিহাস সঞ্চয় করে এবং লেবেলযুক্ত পণ্যগুলির পুনরায় গ্রেডিং দূর করতে সহায়তা করে। তামাকজাত দ্রব্যের উদাহরণ ব্যবহার করে, যা লেবেলযুক্ত পণ্যের প্রথম গ্রুপে অন্তর্ভুক্ত ছিল, সিগারেটের মাত্র একটি ট্রাকে প্রায় 600 প্যাক রয়েছে, যার প্রত্যেকটির নিজস্ব অনন্য কোড রয়েছে। এবং আমাদের সিস্টেমের কাজ হল গুদাম এবং স্টোরের মধ্যে এই জাতীয় প্রতিটি প্যাকের গতিবিধির বৈধতা ট্র্যাক করা এবং যাচাই করা এবং শেষ পর্যন্ত শেষ ক্রেতার কাছে তাদের বিক্রির গ্রহণযোগ্যতা যাচাই করা। এবং আমরা প্রতি ঘন্টায় প্রায় 000 নগদ লেনদেন রেকর্ড করি, এবং আমাদের এও রেকর্ড করতে হবে যে এই ধরনের প্রতিটি প্যাক কীভাবে দোকানে প্রবেশ করেছে৷ এইভাবে, বস্তুর মধ্যে সমস্ত গতিবিধি বিবেচনায় নিয়ে, আমরা প্রতি বছর কয়েক বিলিয়ন রেকর্ড আশা করছি।

দল এম

মার্কাসকে X5 এর মধ্যে একটি প্রকল্প হিসাবে বিবেচনা করা সত্ত্বেও, এটি একটি পণ্য পদ্ধতি ব্যবহার করে বাস্তবায়িত হচ্ছে। দলটি স্ক্রাম অনুযায়ী কাজ করে। প্রকল্পটি গত গ্রীষ্মে শুরু হয়েছিল, তবে প্রথম ফলাফল শুধুমাত্র অক্টোবরে এসেছিল - আমাদের নিজস্ব দল সম্পূর্ণরূপে একত্রিত হয়েছিল, সিস্টেমের আর্কিটেকচার তৈরি করা হয়েছিল এবং সরঞ্জাম কেনা হয়েছিল। এখন দলটিতে 16 জন রয়েছে, যাদের মধ্যে ছয়জন ব্যাকএন্ড এবং ফ্রন্টএন্ড বিকাশের সাথে জড়িত, যাদের মধ্যে তিনজন সিস্টেম বিশ্লেষণে জড়িত। ম্যানুয়াল, লোড, স্বয়ংক্রিয় পরীক্ষা এবং পণ্য রক্ষণাবেক্ষণের সাথে আরও ছয়জন জড়িত। এছাড়াও, আমাদের একজন SRE বিশেষজ্ঞ আছে।

আমাদের দলে শুধুমাত্র ডেভেলপাররাই কোড লেখেন না; প্রায় সব ছেলেই জানে কিভাবে অটোটেস্ট, লোড স্ক্রিপ্ট এবং অটোমেশন স্ক্রিপ্ট প্রোগ্রাম এবং লিখতে হয়। আমরা এটিতে বিশেষ মনোযোগ দিই, যেহেতু এমনকি পণ্য সমর্থনের জন্য উচ্চ স্তরের অটোমেশন প্রয়োজন। আমরা সর্বদা তাদের সহকর্মীদের পরামর্শ এবং সাহায্য করার চেষ্টা করি যারা আগে প্রোগ্রাম করেনি এবং তাদের কাজ করার জন্য কিছু ছোট কাজ দিই।

করোনাভাইরাস মহামারীর কারণে, আমরা পুরো দলকে দূরবর্তী কাজে স্থানান্তরিত করেছি; উন্নয়ন পরিচালনার জন্য সমস্ত সরঞ্জামের প্রাপ্যতা, জিরা এবং গিটল্যাবে তৈরি ওয়ার্কফ্লো সহজেই এই পর্যায়টি অতিক্রম করা সম্ভব করেছে। দূরবর্তীভাবে কাটানো মাসগুলি দেখায় যে দলের উত্পাদনশীলতা ফলস্বরূপ ক্ষতিগ্রস্থ হয়নি; অনেকের জন্য, কর্মক্ষেত্রে স্বাচ্ছন্দ্য বৃদ্ধি পেয়েছে, একমাত্র জিনিসটি অনুপস্থিত ছিল লাইভ যোগাযোগ।

দূরবর্তী দলের মিটিং

দূরবর্তী কাজের সময় মিটিং

সমাধান প্রযুক্তি স্ট্যাক

X5 এর জন্য স্ট্যান্ডার্ড রিপোজিটরি এবং CI/CD টুল হল GitLab। আমরা কোড স্টোরেজ, ক্রমাগত পরীক্ষা, এবং পরীক্ষা এবং উৎপাদন সার্ভারে স্থাপনার জন্য এটি ব্যবহার করি। আমরা কোড পর্যালোচনার অনুশীলনও ব্যবহার করি, যখন কমপক্ষে 2 জন সহকর্মীকে কোডে বিকাশকারী দ্বারা করা পরিবর্তনগুলি অনুমোদন করতে হবে। স্ট্যাটিক কোড বিশ্লেষক SonarQube এবং JaCoCo আমাদের কোড পরিষ্কার রাখতে এবং ইউনিট পরীক্ষা কভারেজের প্রয়োজনীয় স্তর নিশ্চিত করতে সাহায্য করে। কোডের সমস্ত পরিবর্তন এই চেকের মধ্য দিয়ে যেতে হবে। ম্যানুয়ালি চালানো সমস্ত পরীক্ষা স্ক্রিপ্ট পরবর্তীতে স্বয়ংক্রিয় হয়।

"মার্কাস" দ্বারা ব্যবসায়িক প্রক্রিয়াগুলির সফল বাস্তবায়নের জন্য, আমাদের বেশ কয়েকটি প্রযুক্তিগত সমস্যা সমাধান করতে হয়েছিল, প্রতিটি সম্পর্কে ক্রমানুসারে।

টাস্ক 1. সিস্টেমের অনুভূমিক মাপযোগ্যতার প্রয়োজন

এই সমস্যাটি সমাধান করার জন্য, আমরা স্থাপত্যের জন্য একটি মাইক্রোসার্ভিস পদ্ধতি বেছে নিয়েছি। একই সময়ে, পরিষেবাগুলির দায়িত্বের ক্ষেত্রগুলি বোঝা খুব গুরুত্বপূর্ণ ছিল। আমরা তাদের ব্যবসায়িক ক্রিয়াকলাপে বিভক্ত করার চেষ্টা করেছি, প্রক্রিয়াগুলির সুনির্দিষ্টতা বিবেচনা করে। উদাহরণস্বরূপ, একটি গুদামে গ্রহণ করা খুব ঘন ঘন নয়, তবে খুব বড় আকারের অপারেশন, যার সময় গৃহীত পণ্যগুলির ইউনিট সম্পর্কে রাষ্ট্র নিয়ন্ত্রকের কাছ থেকে দ্রুত তথ্য পাওয়া প্রয়োজন, যার সংখ্যা এক ডেলিভারিতে 600000 ছুঁয়েছে। , গুদামে এই পণ্যটি গ্রহণ করার গ্রহণযোগ্যতা পরীক্ষা করুন এবং গুদাম অটোমেশন সিস্টেমের জন্য প্রয়োজনীয় সমস্ত তথ্য ফেরত দিন। তবে গুদামগুলি থেকে চালানের তীব্রতা অনেক বেশি, তবে একই সময়ে অল্প পরিমাণে ডেটা দিয়ে কাজ করে।

আমরা রাষ্ট্রহীন ভিত্তিতে সমস্ত পরিষেবা বাস্তবায়ন করি এবং এমনকি কাফকা স্ব-বিষয়গুলিকে ব্যবহার করে অভ্যন্তরীণ ক্রিয়াকলাপগুলিকে ধাপে ভাগ করার চেষ্টা করি। এটি যখন একটি মাইক্রোসার্ভিস নিজের কাছে একটি বার্তা পাঠায়, যা আপনাকে আরও সম্পদ-নিবিড় ক্রিয়াকলাপের উপর ভারসাম্য বজায় রাখতে দেয় এবং পণ্য রক্ষণাবেক্ষণকে সহজ করে, কিন্তু পরবর্তীতে আরও বেশি।

আমরা আলাদা পরিষেবাগুলিতে বাহ্যিক সিস্টেমের সাথে মিথস্ক্রিয়া করার জন্য আলাদা মডিউল করার সিদ্ধান্ত নিয়েছি। এটি বাহ্যিক সিস্টেমের ঘন ঘন এপিআই পরিবর্তন করার সমস্যা সমাধান করা সম্ভব করেছে, ব্যবসায়িক কার্যকারিতা সহ পরিষেবাগুলিতে কার্যত কোন প্রভাব নেই।

সমস্ত মাইক্রোসার্ভিস একটি ওপেনশিফ্ট ক্লাস্টারে স্থাপন করা হয়, যা প্রতিটি মাইক্রোসার্ভিস স্কেল করার উভয় সমস্যার সমাধান করে এবং আমাদের তৃতীয়-পক্ষ পরিষেবা আবিষ্কার সরঞ্জামগুলি ব্যবহার না করার অনুমতি দেয়।

টাস্ক 2. প্ল্যাটফর্ম পরিষেবাগুলির মধ্যে একটি উচ্চ লোড এবং খুব নিবিড় ডেটা বিনিময় বজায় রাখার প্রয়োজন: শুধুমাত্র প্রকল্প লঞ্চ পর্বের সময়, প্রতি সেকেন্ডে প্রায় 600টি অপারেশন সঞ্চালিত হয়। রিটেল আউটলেটগুলি আমাদের প্ল্যাটফর্মের সাথে সংযুক্ত হওয়ার কারণে আমরা এই মানটি 5000 অপস/সেকেন্ডে বাড়বে বলে আশা করছি।

এই সমস্যাটি একটি কাফকা ক্লাস্টার স্থাপন করে এবং প্ল্যাটফর্মের মাইক্রোসার্ভিসের মধ্যে সিঙ্ক্রোনাস মিথস্ক্রিয়া প্রায় সম্পূর্ণরূপে পরিত্যাগ করে সমাধান করা হয়েছিল। এটির জন্য সিস্টেমের প্রয়োজনীয়তাগুলির একটি অত্যন্ত যত্নশীল বিশ্লেষণের প্রয়োজন, যেহেতু সমস্ত অপারেশন অ্যাসিঙ্ক্রোনাস হতে পারে না। একই সময়ে, আমরা কেবল ব্রোকারের মাধ্যমে ইভেন্টগুলি প্রেরণ করি না, বার্তায় সমস্ত প্রয়োজনীয় ব্যবসায়িক তথ্যও প্রেরণ করি। সুতরাং, বার্তার আকার কয়েকশ কিলোবাইটে পৌঁছাতে পারে। কাফকার বার্তার আকারের সীমার জন্য আমাদের বার্তার আকারের সঠিকভাবে পূর্বাভাস দিতে হবে, এবং প্রয়োজনে আমরা সেগুলিকে ভাগ করি, কিন্তু বিভাগটি যৌক্তিক, ব্যবসায়িক ক্রিয়াকলাপের সাথে সম্পর্কিত।
উদাহরণস্বরূপ, আমরা গাড়িতে আসা পণ্যগুলিকে বাক্সে ভাগ করি। সিঙ্ক্রোনাস অপারেশনের জন্য, পৃথক মাইক্রোসার্ভিস বরাদ্দ করা হয় এবং পুঙ্খানুপুঙ্খ লোড পরীক্ষা করা হয়। কাফকা ব্যবহার করা আমাদের আরেকটি চ্যালেঞ্জের সাথে উপস্থাপন করেছে - কাফকা ইন্টিগ্রেশন বিবেচনায় নিয়ে আমাদের পরিষেবার ক্রিয়াকলাপ পরীক্ষা করা আমাদের সমস্ত ইউনিট পরীক্ষাকে অ্যাসিঙ্ক্রোনাস করে তোলে। আমরা এম্বেডেড কাফকা ব্রোকার ব্যবহার করে আমাদের নিজস্ব ইউটিলিটি পদ্ধতি লিখে এই সমস্যার সমাধান করেছি। এটি পৃথক পদ্ধতির জন্য ইউনিট পরীক্ষা লেখার প্রয়োজনীয়তা দূর করে না, তবে আমরা কাফকা ব্যবহার করে জটিল ক্ষেত্রে পরীক্ষা করতে পছন্দ করি।

ট্রেসিং লগগুলিতে অনেক মনোযোগ দেওয়া হয়েছিল যাতে পরিষেবাগুলি পরিচালনার সময় বা কাফকা ব্যাচের সাথে কাজ করার সময় ব্যতিক্রম ঘটলে তাদের ট্রেসআইডি হারিয়ে না যায়। এবং যদি প্রথমটির সাথে কোনও বিশেষ সমস্যা না থাকে তবে দ্বিতীয় ক্ষেত্রে আমরা ব্যাচের সাথে আসা সমস্ত ট্রেসআইডগুলি লগ করতে এবং ট্রেসিং চালিয়ে যাওয়ার জন্য একটি নির্বাচন করতে বাধ্য হব৷ তারপরে, আসল TraceId দ্বারা অনুসন্ধান করার সময়, ব্যবহারকারী সহজেই খুঁজে পাবে কোনটির সাহায্যে ট্রেসিং অব্যাহত ছিল৷

টাস্ক 3. প্রচুর পরিমাণে ডেটা সঞ্চয় করার প্রয়োজন: শুধুমাত্র তামাকের জন্য প্রতি বছর 1 বিলিয়নেরও বেশি লেবেল X5 এ আসে। তাদের ধ্রুবক এবং দ্রুত অ্যাক্সেস প্রয়োজন। মোট, সিস্টেমটিকে এই লেবেলযুক্ত পণ্যগুলির চলাচলের ইতিহাসের প্রায় 10 বিলিয়ন রেকর্ড প্রক্রিয়া করতে হবে।

তৃতীয় সমস্যা সমাধানের জন্য, NoSQL ডাটাবেস MongoDB বেছে নেওয়া হয়েছিল। আমরা 5টি নোডের একটি শার্ড তৈরি করেছি এবং প্রতিটি নোডে 3টি সার্ভারের রেপ্লিকা সেট রয়েছে। এটি আপনাকে সিস্টেমটিকে অনুভূমিকভাবে স্কেল করতে দেয়, ক্লাস্টারে নতুন সার্ভার যোগ করে এবং এর ত্রুটি সহনশীলতা নিশ্চিত করে। এখানে আমরা আরেকটি সমস্যার সম্মুখীন হয়েছি - মঙ্গো ক্লাস্টারে লেনদেন নিশ্চিত করা, অনুভূমিকভাবে স্কেলযোগ্য মাইক্রোসার্ভিসের ব্যবহার বিবেচনা করে। উদাহরণস্বরূপ, আমাদের সিস্টেমের কাজগুলির মধ্যে একটি হল একই লেবেলিং কোডগুলির সাথে পণ্যগুলি পুনঃবিক্রয় করার প্রচেষ্টা সনাক্ত করা৷ এখানে, ওভারলেগুলি ভুল স্ক্যান বা ক্যাশিয়ারদের দ্বারা ভুল অপারেশন সহ প্রদর্শিত হয়। আমরা দেখেছি যে এই ধরনের সদৃশগুলি প্রক্রিয়া করা একটি কাফকা ব্যাচের মধ্যে এবং সমান্তরালভাবে প্রক্রিয়া করা দুটি ব্যাচের মধ্যে উভয়ই ঘটতে পারে। এইভাবে, ডাটাবেস অনুসন্ধান করে ডুপ্লিকেটগুলি পরীক্ষা করে কিছুই দেয়নি। প্রতিটি মাইক্রোসার্ভিসের জন্য, আমরা এই পরিষেবার ব্যবসায়িক যুক্তির উপর ভিত্তি করে আলাদাভাবে সমস্যার সমাধান করেছি। উদাহরণস্বরূপ, চেকের জন্য, আমরা ব্যাচের ভিতরে একটি চেক যোগ করেছি এবং সন্নিবেশ করার সময় সদৃশগুলির উপস্থিতির জন্য পৃথক প্রক্রিয়াকরণ।

ক্রিয়াকলাপের ইতিহাসের সাথে ব্যবহারকারীদের কাজ কোনভাবেই সবচেয়ে গুরুত্বপূর্ণ বিষয়কে প্রভাবিত করে না তা নিশ্চিত করার জন্য - আমাদের ব্যবসায়িক প্রক্রিয়াগুলির কার্যকারিতা, আমরা সমস্ত ঐতিহাসিক ডেটাকে একটি পৃথক ডেটাবেস সহ একটি পৃথক পরিষেবাতে আলাদা করেছি, যা কাফকার মাধ্যমেও তথ্য গ্রহণ করে। . এইভাবে, ব্যবহারকারীরা চলমান ক্রিয়াকলাপের জন্য ডেটা প্রক্রিয়া করে এমন পরিষেবাগুলিকে প্রভাবিত না করে একটি বিচ্ছিন্ন পরিষেবার সাথে কাজ করে৷

টাস্ক 4: সারি পুনঃপ্রক্রিয়াকরণ এবং পর্যবেক্ষণ:

ডিস্ট্রিবিউটেড সিস্টেমে, ডাটাবেস, সারি এবং বাহ্যিক ডেটা উত্সগুলির প্রাপ্যতার ক্ষেত্রে অনিবার্যভাবে সমস্যা এবং ত্রুটিগুলি দেখা দেয়। মার্কাসের ক্ষেত্রে, এই ধরনের ত্রুটির উৎস হল বহিরাগত সিস্টেমের সাথে একীকরণ। এটি একটি সমাধান খুঁজে বের করা প্রয়োজন ছিল যা কিছু নির্দিষ্ট সময়সীমার সাথে ভুল প্রতিক্রিয়াগুলির জন্য বারবার অনুরোধের অনুমতি দেবে, কিন্তু একই সাথে মূল সারিতে সফল অনুরোধগুলি প্রক্রিয়া করা বন্ধ করবে না। এই উদ্দেশ্যে, তথাকথিত "বিষয় ভিত্তিক পুনরায় চেষ্টা" ধারণাটি বেছে নেওয়া হয়েছিল৷ প্রতিটি প্রধান বিষয়ের জন্য, এক বা একাধিক পুনঃচেষ্টার বিষয় তৈরি করা হয় যেখানে ভুল বার্তা পাঠানো হয় এবং একই সময়ে মূল বিষয় থেকে বার্তা প্রক্রিয়াকরণে বিলম্ব দূর করা হয়। মিথস্ক্রিয়া পরিকল্পনা -

এই জাতীয় স্কিম বাস্তবায়নের জন্য, আমাদের নিম্নলিখিতগুলির প্রয়োজন: এই সমাধানটি স্প্রিংয়ের সাথে একীভূত করতে এবং কোডের অনুলিপি এড়াতে। ওয়েব সার্ফিং করার সময়, আমরা Spring BeanPostProccessor-এর উপর ভিত্তি করে একটি অনুরূপ সমাধান পেয়েছি, কিন্তু এটি আমাদের কাছে অপ্রয়োজনীয়ভাবে কষ্টকর বলে মনে হয়েছিল। আমাদের দল একটি সহজ সমাধান তৈরি করেছে যা আমাদেরকে ভোক্তা তৈরির জন্য বসন্ত চক্রের সাথে একীভূত করতে এবং অতিরিক্তভাবে পুনরায় চেষ্টা করার জন্য গ্রাহকদের যোগ করার অনুমতি দেয়। আমরা স্প্রিং টিমের কাছে আমাদের সমাধানের একটি প্রোটোটাইপ অফার করেছি, আপনি এটি দেখতে পারেন এখানে. ব্যবসায়িক প্রক্রিয়ার প্রয়োজনের উপর নির্ভর করে, পুনঃপ্রচেষ্টা ভোক্তাদের সংখ্যা এবং প্রতিটি ভোক্তার জন্য প্রচেষ্টার সংখ্যা পরামিতিগুলির মাধ্যমে কনফিগার করা হয় এবং সবকিছু কাজ করার জন্য, যা অবশিষ্ট থাকে তা হল org.springframework.kafka.annotation.KafkaListener যোগ করা। , যা সমস্ত স্প্রিং ডেভেলপারদের কাছে পরিচিত৷

সমস্ত পুনঃপ্রচেষ্টার পরেও যদি বার্তাটি প্রসেস করা না যায়, তাহলে স্প্রিং ডেডলেটার পাবলিশিং রিকভার ব্যবহার করে এটি ডিএলটি (মৃত চিঠির বিষয়) এ যায়৷ সমর্থনের অনুরোধে, আমরা এই কার্যকারিতা প্রসারিত করেছি এবং একটি পৃথক পরিষেবা তৈরি করেছি যা আপনাকে DLT, স্ট্যাকট্রেস, ট্রেসআইডি এবং সেগুলি সম্পর্কে অন্যান্য দরকারী তথ্যগুলিতে অন্তর্ভুক্ত বার্তাগুলি দেখতে দেয়৷ এছাড়াও, সমস্ত ডিএলটি বিষয়গুলিতে মনিটরিং এবং সতর্কতা যুক্ত করা হয়েছিল এবং এখন, আসলে, একটি ডিএলটি বিষয়ে একটি বার্তার উপস্থিতি একটি ত্রুটি বিশ্লেষণ এবং সংশোধন করার একটি কারণ। এটি খুব সুবিধাজনক - বিষয়টির নাম দ্বারা, আমরা অবিলম্বে বুঝতে পারি যে প্রক্রিয়াটির কোন ধাপে সমস্যাটি দেখা দিয়েছে, যা এর মূল কারণ অনুসন্ধানকে উল্লেখযোগ্যভাবে ত্বরান্বিত করে।

অতি সম্প্রতি, আমরা একটি ইন্টারফেস প্রয়োগ করেছি যা আমাদের সমর্থন ব্যবহার করে বার্তাগুলিকে তাদের কারণগুলি দূর করার পরে (উদাহরণস্বরূপ, বাহ্যিক সিস্টেমের কার্যকারিতা পুনরুদ্ধার করা) এবং অবশ্যই, বিশ্লেষণের জন্য সংশ্লিষ্ট ত্রুটি স্থাপন করার অনুমতি দেয়। এখানেই আমাদের স্ব-বিষয়গুলি কাজে আসে: একটি দীর্ঘ প্রক্রিয়াকরণ চেইন পুনরায় চালু না করার জন্য, আপনি পছন্দসই পদক্ষেপ থেকে এটি পুনরায় চালু করতে পারেন।

প্ল্যাটফর্ম অপারেশন

প্ল্যাটফর্মটি ইতিমধ্যে উত্পাদনশীল অপারেশনে রয়েছে, প্রতিদিন আমরা ডেলিভারি এবং চালান চালাই, নতুন বিতরণ কেন্দ্র এবং স্টোরগুলিকে সংযুক্ত করি। পাইলটের অংশ হিসাবে, সিস্টেমটি "তামাক" এবং "জুতা" পণ্য গোষ্ঠীর সাথে কাজ করে।

আমাদের পুরো দল পাইলট পরিচালনায় অংশগ্রহণ করে, উদীয়মান সমস্যাগুলি বিশ্লেষণ করে এবং আমাদের পণ্যের উন্নতির জন্য পরামর্শ দেয়, লগগুলি উন্নত করা থেকে শুরু করে প্রক্রিয়াগুলি পরিবর্তন করা পর্যন্ত।

আমাদের ভুলের পুনরাবৃত্তি না করার জন্য, পাইলটের সময় পাওয়া সমস্ত ক্ষেত্রে স্বয়ংক্রিয় পরীক্ষায় প্রতিফলিত হয়। বিপুল সংখ্যক অটোটেস্ট এবং ইউনিট পরীক্ষার উপস্থিতি আপনাকে রিগ্রেশন টেস্টিং পরিচালনা করতে এবং কয়েক ঘন্টার মধ্যে আক্ষরিকভাবে একটি হটফিক্স ইনস্টল করতে দেয়।

এখন আমরা আমাদের প্ল্যাটফর্মের বিকাশ এবং উন্নতি চালিয়ে যাচ্ছি এবং ক্রমাগত নতুন চ্যালেঞ্জের মুখোমুখি হচ্ছি। আপনি যদি আগ্রহী হন তবে আমরা নিম্নলিখিত নিবন্ধগুলিতে আমাদের সমাধানগুলি সম্পর্কে কথা বলব।

উত্স: www.habr.com