আমরা সবাই ড্রিল জানি, তাই না? আমরা কোড পরিবর্তনের কাজ শেষ করার পরে, এবং [আশা করি] আমাদের স্থানীয় মেশিনে এটি পরীক্ষা করার পরে, আমরা পরিবর্তনটিকে চক্রের পরবর্তী পর্যায়ে ঠেলে দিই। স্থানীয় পরীক্ষা খুবই পক্ষপাতদুষ্ট, এবং আদর্শভাবে, আমরা আরও স্থিতিশীল পরিবেশে পরিবর্তনটি যাচাই করতে চাই (এবং পরিবর্তনটি বাস্তবায়নকারী প্রকৌশলীর কাছ থেকে আসা শুধুমাত্র দৃষ্টিভঙ্গি অনুসরণ করব না)। একটি পরবর্তী ধাপ এখানে খুবই স্বাভাবিক বলে মনে হয়: পরিবর্তনগুলিকে একটি নির্ভরযোগ্য স্টেজিং পরিবেশে ঠেলে দিন এবং পরিবর্তনগুলি সরানোর আগে বৈধকরণে অংশীদার (QAs, PM, অন্যান্য প্রকৌশলী) সাহায্য করুন৷ এটি বাগ ফিক্সিং এবং পুনরায় বৈধতা দ্বারা অনুসরণ করা হবে যতক্ষণ না আমরা বিশ্বাস করি যে এটি উত্পাদনে ঠেলে দেওয়ার জন্য যথেষ্ট ভাল। দারুণ! বেশিরভাগ প্রসঙ্গে, তবে, এটি কেবল ঘটবে না। এটি বিভিন্ন কারণে হতে পারে, তবে কারণ যাই হোক না কেন, ফলাফলটি হল যে আমাদের প্রায়শই প্রোডাকশন সার্ভারে পরিবর্তনগুলিকে উন্নীত করতে হয় সেগুলি পরীক্ষা বা যাচাই করার আগে। সমস্যা হল… কিছু ভেঙ্গে গেলে কি হবে? আসলে, আগে কিভাবে সমস্যা সনাক্ত করতে? সুসংবাদ: উৎপাদনে পরীক্ষা এবং যাচাইকরণের জন্য কিছু সরঞ্জাম এবং অনুশীলন গ্রহণ করা সম্ভব নয় শুধুমাত্র আপনার এবং আপনার কোম্পানির জন্য একটি নিরাপদ অনুশীলন, তবে এটি একটি ভাল ধারণাও হতে পারে। বেসলাইন: মেট্রিক্স আমরা উৎপাদন পরীক্ষায় ঝাঁপিয়ে পড়ার আগে, আমাদের মেট্রিক্স সম্পর্কে কথা বলতে হবে: আমাদের তাদের যাচাই করতে হবে যে আমরা যে পরিবর্তনটি শিপিং করছি তা পছন্দসই প্রভাব তৈরি করে, অবাঞ্ছিত পার্শ্বপ্রতিক্রিয়া সৃষ্টি করে না, পণ্যটি এখনও স্থিতিশীল, ইত্যাদি। -প্রতিষ্ঠিত মেট্রিক্স, পরিবর্তনগুলি রোল আউট করার সময় আমরা মূলত অন্ধ। আমরা নিবন্ধের অনেক বিষয়ের মেট্রিক্স উল্লেখ করব, তাই আসুন দুটি ভিন্ন ধরনের মেট্রিক্স দেখে নেওয়া যাক যা আমাদের মনে রাখা উচিত। ব্যবসার মেট্রিক্স ব্যবসা-সম্পর্কিত মেট্রিক্স যেমন KPIs, লক্ষ্য এবং ব্যবহারকারীর আচরণের প্রভাব মূল্যায়ন করার জন্য পরিবর্তনগুলি বাস্তবায়নের পর পর্যবেক্ষণ করা উচিত। কোনো পরিবর্তনের আগে, প্রভাবিত হতে পারে বলে আশা করা মেট্রিক্স চিহ্নিত করুন। একইভাবে গুরুত্বপূর্ণ হল গার্ডরেল মেট্রিক্স, যা পরিবর্তন করা উচিত নয় তার সূচক। এই গার্ডেলগুলিতে অপ্রত্যাশিত পরিবর্তনগুলি নতুন পরিবর্তনের সাথে সমস্যাগুলিকে নির্দেশ করতে পারে, একটি পর্যালোচনার প্রয়োজন৷ প্রযুক্তিগত মেট্রিক্স ব্যবসার মেট্রিক্স একবার সংজ্ঞায়িত হয়ে গেলে, প্রযুক্তিগত মেট্রিক্স বোঝাও গুরুত্বপূর্ণ। সময়ের সাথে সাথে পরিবর্তনগুলি চালু হওয়ার সাথে সাথে সিস্টেমগুলি সুস্থ থাকে তা নিশ্চিত করার জন্য এগুলি মৌলিক। এখানে আমরা সিস্টেমের স্থিতিশীলতা, ত্রুটির হার, ভলিউম, মেশিনের ক্ষমতার সীমাবদ্ধতা ইত্যাদি সম্পর্কে কথা বলছি। ব্যবসায়িক মেট্রিক্সে পরিলক্ষিত সমস্যাগুলি ব্যাখ্যা করার জন্য বা দ্রুত রিগ্রেশনের মূল কারণ খুঁজে বের করার জন্য ভাল প্রযুক্তিগত মেট্রিকগুলিও কার্যকর। উদাহরণ স্বরূপ, ধরা যাক আমরা শেষ সংস্করণ রোলআউটের পর ব্যবহারকারীদের একটি নির্দিষ্ট বৈশিষ্ট্যের সাথে অনেক কম জড়িত থাকতে দেখেছি। অনুরোধের সময়সীমা বৃদ্ধি বা ত্রুটির হার দ্রুত দেখাতে পারে কোন পরিষেবা/এন্ডপয়েন্ট সমস্যাটি ঘটাচ্ছে। মনিটরিং আমরা ব্যবসা এবং প্রযুক্তিগত মেট্রিক্স ভাল-সংজ্ঞায়িত আছে, ভাল! এখন, আমাদের তাদের পর্যবেক্ষণ করতে হবে। এটি করার অনেক উপায় আছে, কিন্তু একটি সাধারণ প্রথম ধাপ হল ড্যাশবোর্ড তৈরি করা যা সময়ের সাথে সাথে মেট্রিক্স ট্র্যাক করে, যা অস্বাভাবিক স্পাইকগুলিকে সহজে চিহ্নিত করে। আরও ভাল যদি ড্যাশবোর্ড নির্দিষ্ট সেগমেন্টের উপর ভিত্তি করে ডেটা দ্রুত ফিল্টার করার অনুমতি দেয় যা ব্যবসার জন্য বিশেষভাবে প্রাসঙ্গিক হতে পারে। সক্রিয়ভাবে ড্যাশবোর্ডগুলি পর্যবেক্ষণ করা সিস্টেমে একটি নতুন পরিবর্তন প্রবর্তিত প্রভাবগুলি দ্রুত কল্পনা করার একটি ভাল উপায়। কিছু কোম্পানি সক্রিয় পর্যবেক্ষণকে এত গুরুত্বপূর্ণ বলে মনে করে যে যত তাড়াতাড়ি সম্ভব সমস্যাগুলি সনাক্ত করতে এবং সমাধান করতে তাদের 24/7 মনিটরিং শিফট রয়েছে। মেট্রিক্স নিরীক্ষণ করার আরেকটি ভাল উপায় হল স্বয়ংক্রিয় সনাক্তকরণ এবং সতর্কতার মাধ্যমে। মূল মেট্রিক্সের জন্য, কিছু ভুল দেখা গেলে সতর্কতা রিয়েল-টাইম বিজ্ঞপ্তি প্রদান করতে পারে। ধরা যাক আমরা একটি বৈশিষ্ট্য চালু করা শুরু করি এবং প্রক্রিয়াটি শুরু হওয়ার কয়েক মিনিট পরে আমরা একটি সতর্কতা পাই যে ত্রুটির হার একটি নির্দিষ্ট থ্রেশহোল্ডের উপরে বাড়ছে। এই প্রারম্ভিক বিজ্ঞপ্তিটি আমাদের উত্পাদনে আরও পরিবর্তন প্রচার করা থেকে বিরত রাখতে পারে এবং আমাদের অনেক সমস্যা থেকে বাঁচাতে পারে! সবশেষে, আমাদের কতটা তথ্য এবং কোন পরিস্থিতিতে প্রয়োজন সে সম্পর্কে সচেতন হওয়া গুরুত্বপূর্ণ। যদিও ড্যাশবোর্ডগুলি পণ্য এবং সিস্টেমের কার্যকারিতার একটি ভিজ্যুয়াল আভাস প্রদানের জন্য খুব দরকারী, 1,000টি বিভিন্ন চার্ট যুক্ত করা স্বচ্ছতার চেয়ে আরও বিভ্রান্তি আনতে চলেছে৷ একইভাবে, যদি আমরা প্রতিদিন 1,000টি সতর্কতা পাই, তবে তাদের তদন্ত করা এবং কাজ করা অসম্ভব এবং সেগুলি উপেক্ষা করা হবে। নিরাপদ অবতরণ মেট্রিক্স সংজ্ঞায়িত, জায়গায় নিরীক্ষণ, মহান! সমস্যা এড়াতে, সমস্যাগুলি আগে শনাক্ত করতে এবং উৎপাদনে প্রভাব কমাতে সাহায্য করার জন্য এখন কিছু টুল এবং কৌশল দেখে নেওয়া যাক। উৎপাদন পরিবেশ কীভাবে সেট আপ করা হয়েছে তার উপর নির্ভর করে, এর মধ্যে কয়েকটি অন্যদের তুলনায় বাস্তবায়ন করা কঠিন হবে এবং একত্রিত হলে হয়তো খুব বেশি অর্থবোধক হবে না। যাইহোক, এখানে প্রতিটি আইটেম আমাদের একটি নিরাপদ এবং স্থিতিশীল উত্পাদন পরিবেশের কাছাকাছি যেতে সাহায্য করতে পারে। স্বয়ংক্রিয় পরীক্ষা স্বয়ংক্রিয় পরীক্ষা, প্রায়শই যখন প্রকল্পগুলি ট্র্যাক বন্ধ হয়ে যায়, তখন উন্নয়নকে ত্বরান্বিত করতে পারে এবং নিরাপদ এবং দ্রুত উৎপাদনে পরিবর্তন আনতে পারে। আগের সমস্যাগুলি ধরা পড়ে, দ্রুত সেগুলি ঠিক করা যেতে পারে, এইভাবে প্রক্রিয়াটিতে ব্যয় করা সামগ্রিক সময় হ্রাস করে৷ পরিবর্তনগুলি প্রত্যাবর্তন, ঠিক করা এবং আবার ঠেলে দেওয়ার প্রক্রিয়াটি সাধারণত খুব চাপযুক্ত এবং মূল্যবান সময় কেড়ে নিতে পারে। ইউনিট, ইন্টিগ্রেশন এবং এন্ড-টু-এন্ড টেস্ট সহ 100% টেস্ট কভারেজের লক্ষ্য করা বেশিরভাগ প্রকল্পের জন্য আদর্শ হতে পারে। পরিবর্তে, প্রচেষ্টা বনাম সুবিধার উপর ভিত্তি করে পরীক্ষাগুলিকে অগ্রাধিকার দিন। মেট্রিক্স এটিকে গাইড করতে পারে: মূল ব্যবসার বৈশিষ্ট্যগুলিকে কভার করা সম্ভবত কম-প্রভাবিত কুলুঙ্গি বৈশিষ্ট্যগুলির চেয়ে আরও গুরুত্বপূর্ণ, তাই না? মূল বৈশিষ্ট্যগুলি দিয়ে শুরু করুন, সিস্টেমের বিকাশের সাথে সাথে প্রসারিত হচ্ছে৷ পাবলিশ-টু-প্রোডাকশন প্রক্রিয়ায় উৎপাদনে মোতায়েন করার আগে টেস্ট স্যুট চালানো অন্তর্ভুক্ত করা উচিত। পরীক্ষায় ব্যর্থ হলে প্রকাশনা বন্ধ করা উচিত, উৎপাদন সমস্যা প্রতিরোধ করা উচিত। পরের দিন এটি সম্পূর্ণরূপে ত্রুটিযুক্ত তা আবিষ্কার করার চেয়ে এটির প্রকাশে বিলম্ব করা ভাল। ডগফুডিং ডগফুডিং হল চূড়ান্ত ব্যবহারকারীদের কাছে পৌঁছানোর আগে অভ্যন্তরীণ পরীক্ষার জন্য একটি বৈশিষ্ট্য প্রকাশ করার প্রক্রিয়া। ডগফুডিংয়ের সময়, বৈশিষ্ট্যটি উৎপাদনে উপলব্ধ করা হয়, তবে শুধুমাত্র অভ্যন্তরীণ ব্যবহারকারীদের (কর্মচারী, দলের সদস্য ইত্যাদি) জন্য। এইভাবে, আমরা পরীক্ষা এবং যাচাই করতে পারি যে নতুন বৈশিষ্ট্যটি প্রত্যাশিতভাবে কাজ করছে কিনা, প্রকৃত উৎপাদন ডেটা ব্যবহার করে, বহিরাগত ব্যবহারকারীদের প্রভাবিত না করে। ডগফুডিংয়ের জন্য বিভিন্ন কৌশল রয়েছে। একটি সরলীকৃত ওভারভিউয়ের জন্য, আমরা তাদের দুটি বড় বালতিতে গোষ্ঠীবদ্ধ করতে পারি: : এটি সাধারণ, উদাহরণস্বরূপ, iOS/Android অ্যাপে, যেখানে নির্দিষ্ট ব্যবহারকারীদের জন্য একটি নতুন অ্যাপ সংস্করণ প্রকাশ করার জন্য আমাদের কাছে অন্তর্নির্মিত সরঞ্জাম রয়েছে এবং তারপরে দোকানে সাধারণ জনগণের জন্য এই একই সংস্করণটি উপলব্ধ করা যায়। সম্পূর্ণ নিদর্শন ডগফুডিং : কখনও কখনও, পুরো নিদর্শন ডগফুড করা সম্ভব হয় না (বা এমনকি কাঙ্খিত), কিন্তু আমরা এখনও নির্দিষ্ট ব্যবহারকারীর তথ্যের উপর ভিত্তি করে ডগফুড করার অনুমতি দিতে পারি। ধরা যাক, উদাহরণস্বরূপ, আমরা কিছু ডেটা ক্রস করে কর্মীদের সনাক্ত করতে সক্ষম। অ্যাপ্লিকেশনটিকে তারপরে এই ডেটাতে একটি চেক করে এবং ব্যবহারকারীকে পছন্দসই আচরণে শাখা করে একটি নির্দিষ্ট বৈশিষ্ট্য সক্ষম/অক্ষম করতে কনফিগার করা যেতে পারে। অ্যাপ্লিকেশনটিতে তখন উভয় বৈশিষ্ট্যই রয়েছে, তবে শুধুমাত্র কিছু ব্যবহারকারী নতুন পরিবর্তন দ্বারা প্রভাবিত হবে। আমরা পরবর্তী বিষয়গুলিতে এই ধারণাগুলির কয়েকটিতে ফিরে আসব। নির্বাচনী ডগফুডিং ক্যানারি রিলিজ ক্যানারি রিলিজ হল একটি রিলিজ প্রক্রিয়া যেখানে সমস্ত সার্ভারে একবারে উৎপাদনের পরিবর্তনগুলি রোল আউট করার পরিবর্তে, পরিবর্তনটি তাদের একটি ছোট উপসেটে উপলব্ধ করা হয় এবং কিছু সময়ের জন্য পর্যবেক্ষণ করা হয়। পরিবর্তনটি স্থিতিশীল তা প্রত্যয়িত করার পরেই, এটি উত্পাদন পরিবেশে ঠেলে দেওয়া হয়। এটি নতুন বৈশিষ্ট্য এবং ঝুঁকিপূর্ণ পরিবর্তনগুলি পরীক্ষা করার জন্য সবচেয়ে শক্তিশালী সরঞ্জামগুলির মধ্যে একটি, এইভাবে উত্পাদনে কিছু ভাঙার সম্ভাবনা হ্রাস করে। ব্যবহারকারীদের একটি গোষ্ঠীর উপর পরিবর্তন পরীক্ষা করে, বেশিরভাগ ব্যবহারকারীর উপর প্রভাব এড়াতে, কোনো সমস্যা সনাক্ত হলে আমরা রোলআউট প্রক্রিয়াটি বন্ধ/প্রত্যাবর্তন করতে পারি। নীল সবুজ স্থাপনা ব্লু গ্রিন ডিপ্লোয়মেন্ট, একটি DevOps অনুশীলন, দুটি সার্ভার ক্লাস্টার (নীল এবং সবুজ) ব্যবহার করে এবং তাদের মধ্যে উত্পাদন ট্রাফিক স্যুইচ করার মাধ্যমে ডাউনটাইম প্রতিরোধ করা লক্ষ্য করে। বৈশিষ্ট্য রোলআউটের সময়, পরিবর্তনগুলি একটি সেটে (সবুজ) প্রকাশ করা হয় এবং অপরটি (নীল) অপরিবর্তিত রাখে। সমস্যা দেখা দিলে, ট্রাফিক দ্রুত ব্লু সার্ভারগুলিতে ফিরিয়ে আনা যেতে পারে, কারণ সেগুলি পূর্ববর্তী সংস্করণের সাথে চলমান ছিল৷ ব্লু গ্রিন ডিপ্লোয়মেন্ট প্রায়ই ক্যানারি রিলিজের সাথে বিপরীত হয় যা আমরা আগে আলোচনা করেছি। আমরা এই আলোচনার বিশদ বিবরণে ডুব দেব না, তবে কোন সরঞ্জামগুলি আমাদের কাজের জন্য আরও উপযুক্ত তা সিদ্ধান্ত নেওয়ার সময় আমাদের সাহায্য করার জন্য এটি উল্লেখ করা গুরুত্বপূর্ণ৷ কিল সুইচ এবং ফিচার টগল কিল সুইচগুলি সফ্টওয়্যার প্রকৌশলের প্রেক্ষাপটে উদ্ভূত নয় এবং তাদের ব্যবহার বোঝার সর্বোত্তম উপায় হল মূল অভিপ্রায় এবং নকশার দিকে ফিরে তাকানো। শিল্পে ব্যবহৃত যন্ত্রপাতিগুলিতে, কিল সুইচগুলি হল নিরাপত্তা ব্যবস্থা যা একটি খুব সাধারণ মিথস্ক্রিয়া (সাধারণত একটি সাধারণ বোতাম বা অন/অফ সুইচ) এর মাধ্যমে যত তাড়াতাড়ি সম্ভব বন্ধ করে দেয়। এগুলি জরুরী পরিস্থিতির জন্য বিদ্যমান, একটি ঘটনা প্রতিরোধ করতে (উদাহরণস্বরূপ, মেশিনের ত্রুটি) আরও খারাপ ঘটনা ঘটাতে (জখম বা মৃত্যু)। সফ্টওয়্যার ইঞ্জিনিয়ারিং-এ, কিল সুইচগুলি একই উদ্দেশ্যে কাজ করে: আমরা সিস্টেমকে চালু এবং চালু রাখার প্রয়াসে একটি নির্দিষ্ট বৈশিষ্ট্য হারানো (বা হত্যা) স্বীকার করি। বাস্তবায়ন হল, একটি উচ্চ স্তরে, একটি শর্ত পরীক্ষা (নীচে কোড স্নিপেট দেখুন), সাধারণত একটি নির্দিষ্ট পরিবর্তন বা বৈশিষ্ট্যের এন্ট্রি পয়েন্টে যোগ করা হয়। if (feature_is_enabled('feature_x')) {xNewBehaviour();} else {xOldBehaviour();} ধরা যাক, উদাহরণস্বরূপ, আমরা একটি নতুন থার্ড-পার্টি API-এ একটি মাইগ্রেশন শিপিং করছি। পরীক্ষায় সবকিছু ঠিক আছে, ক্যানারি রিলিজে স্থিতিশীল এবং তারপর পরিবর্তনটি 100% উৎপাদনে নিয়ে যাওয়া হয়। কিছু সময় পরে, নতুন API ভলিউমের সাথে লড়াই করতে শুরু করে এবং অনুরোধগুলি ব্যর্থ হতে শুরু করে (প্রযুক্তিগত মেট্রিক্স মনে রাখবেন?)। যেহেতু আমাদের কাছে একটি কিল সুইচ আছে, API অনুরোধগুলি তাত্ক্ষণিকভাবে পুরানো API-এ প্রত্যাবর্তন করা যেতে পারে এবং আমাদের পূর্ববর্তী সংস্করণে প্রত্যাবর্তন করতে হবে না বা দ্রুত হটফিক্স পাঠাতে হবে না। প্রযুক্তিগতভাবে বলতে গেলে, কিল সুইচগুলি আসলে বৈশিষ্ট্য টগল (ওরফে বৈশিষ্ট্য পতাকা) এর একটি নির্দিষ্ট ব্যবহারের ক্ষেত্রে। যেহেতু আমরা বিষয়টিতে আছি, এটি বৈশিষ্ট্য টগলের আরেকটি দুর্দান্ত সুবিধা উল্লেখ করার মতো: ট্রাঙ্ক-ভিত্তিক বিকাশ সক্ষম করা। বৈশিষ্ট্য টগলের জন্য ধন্যবাদ, নতুন কোড নিরাপদে উৎপাদনে ঠেলে দেওয়া যেতে পারে, এমনকি যদি এটি অসম্পূর্ণ বা এখনও পরীক্ষিত না হয়। পুরানো আচরণ অ্যাক্সেসযোগ্য রাখা উপরে উল্লিখিত কোডটি সম্ভবত আমাদের মধ্যে কেউ কেউ ভাবছে যে এটি আসলে একটি ভাল প্যাটার্ন কিনা, একই সময়ে অ্যাপ্লিকেশনটিতে থাকা পুরানো এবং নতুন উভয় আচরণের সাথে। আমি সম্মত যে এটি সম্ভবত আমাদের কোডবেসের জন্য আমরা চাই শেষ অবস্থা নয়, অন্যথায়, কোডের প্রতিটি একক অংশ if/else ধারা দ্বারা বেষ্টিত হয়ে যাবে, যা কোডটিকে কিছুক্ষণের মধ্যে অপঠনযোগ্য করে তুলবে। যাইহোক, আমাদের সবসময় পুরানো আচরণ মুছে ফেলার জন্য তাড়াহুড়ো করা উচিত নয়। হ্যাঁ, এটি ব্যবহার করা বন্ধ হওয়ার সাথে সাথে কোডটি পরিষ্কার করা এবং প্রযুক্তিগত ঋণ এড়ানো খুব লোভনীয়। তবে এটি একটি বৈশিষ্ট্য টগলের অধীনে কিছু সময়ের জন্য সেখানে রেখে দেওয়াও ভাল। কখনও কখনও, নতুন বৈশিষ্ট্যটি স্থিতিশীল না হওয়া পর্যন্ত এটি কিছুটা সময় নিতে পারে, এবং একটি ব্যাকআপ বিকল্প থাকা একটি নিরাপদ প্রক্রিয়া যদি আমাদের এটিতে ফিরে যেতে হয়, এমনকি অল্প সময়ের জন্য হলেও। প্রতিটি রিলিজের জীবনচক্র ভিন্ন, এবং পুরানো কোড থেকে মুক্তি পাওয়ার জন্য কখন এটি একটি ভাল সময় তা ট্র্যাক রাখা একটি ভাল অভ্যাস। কোডটি পরিষ্কার রাখা এবং রক্ষণাবেক্ষণের ওভারহেড হ্রাস করা বিপরীত পরিস্থিতি এড়াতে পারে যেখানে, যদিও আমাদের কোডটিতে বৈশিষ্ট্যটি নিষ্ক্রিয় করা আছে, তবে এটি নিষ্ক্রিয় হওয়ার পর কতক্ষণ হয়েছে তা সম্ভবত ভেঙে গেছে। ছায়া পরীক্ষা নিরাপদ পরিবর্তনগুলি বাস্তবায়নের জন্য আমার প্রিয় কৌশলগুলির মধ্যে একটি হল শ্যাডো টেস্টিং বা শ্যাডো মোড। এটি ফলাফলের তুলনা করার জন্য পুরানো এবং নতুন উভয় আচরণ সম্পাদন করে তবে প্রযোজ্য হিসাবে কিছু নতুন আচরণের পার্শ্ব প্রতিক্রিয়াগুলিকে নিষ্ক্রিয় করে। আসুন এই সহজ উদাহরণটি একবার দেখে নেওয়া যাক: int sum(int a, int b) {int currentResult = currentMathLib.sum(a, b);int newResult = newMathLib.sum(a, b);logDivergences(a, b, currentResult, newResult);return currentResult;}void logSumDivergences(int a, int b, int currentResult, int newResult) {if (currentResult != newResult) {logger.warn( 'Divergence detected when executing {0} + {1}: {2} != {3}',a, b, currentResult, newResult);}} যদিও উভয় সমষ্টির ক্রিয়াকলাপ সম্পাদিত হয়, তবে নতুনটি শুধুমাত্র তুলনা এবং ভিন্নতা লগ্ন করতে ব্যবহৃত হয়। এই কৌশলটি জটিল সিস্টেম পরিবর্তনগুলি নিরীক্ষণ করতে বিশেষভাবে কার্যকর এবং আমরা পুরানো এবং নতুন আচরণের মধ্যে কিছু সমতা আশা করি। আরেকটি দুর্দান্ত ব্যবহারের ক্ষেত্রে যখন আমাদের এমন পণ্যগুলিতে পরিবর্তন করতে হয় যেগুলির সাথে আমরা খুব বেশি পরিচিত নই, বা যখন আমরা ভালভাবে জানি না কোন প্রান্তের ক্ষেত্রে অভিপ্রেত পরিবর্তন দ্বারা প্রভাবিত হতে পারে। আরও জটিল পরিস্থিতিতে, ছায়া পরীক্ষা সক্ষম করার আগে আমাদের কিছু পার্শ্ব প্রতিক্রিয়া নিষ্ক্রিয় করতে হতে পারে। উদাহরণ স্বরূপ, ধরা যাক আমরা ব্যবহারকারীদের সাইন আপ করতে এবং ডিবিতে সংরক্ষণ করার জন্য একটি নতুন ব্যাকএন্ড API প্রয়োগ করছি, ব্যবহারকারী আইডি ফেরত দিয়েছি। সম্পূর্ণ প্রক্রিয়াটি চালানোর জন্য আমাদের কাছে একটি শ্যাডো ডিবিও থাকতে পারে, তবে প্রতিটি ব্যাকএন্ড API-এর জন্য দুবার "নিবন্ধন সফল" ইমেল পাঠানো অবশ্যই ভাল ধারণা নয়। এছাড়াও একই উদাহরণে, আমাদের একটি গভীর তুলনা যুক্তির প্রয়োজন হবে, কারণ শুধুমাত্র ফিরে আসা ব্যবহারকারী আইডিগুলির তুলনা করা খুব কার্যকর হবে না। সবশেষে, কী কী নিরীক্ষণ ও পরীক্ষা করা দরকার তা বোঝা গুরুত্বপূর্ণ এবং সমতা অর্জন না হলে কী মানদণ্ড প্রয়োগ করা হবে। কিছু সমালোচনামূলক পরিস্থিতিতে, ফলাফলগুলি ঠিক একই না হওয়া পর্যন্ত আমাদের ছায়া পরীক্ষার পুনরাবৃত্তি করতে হবে। অন্যদের ক্ষেত্রে, নতুন বাস্তবায়ন যখন ক্ষতির চেয়ে বেশি সুবিধা প্রদান করে তখন কিছু % ভিন্নতা থাকা ঠিক হতে পারে। লগ এমনকি দৃঢ় সুরক্ষার সাথে, সিস্টেমগুলি নড়বড়ে হতে পারে। যখন এটি ঘটবে, আমাদের সঠিক স্তরের বিশদ সহ, কী ঘটছে তা বুঝতে সক্ষম হতে হবে, অন্যথায়, একটি দক্ষ সমাধান করা অত্যন্ত কঠিন হতে পারে। দিন বাঁচাতে লগ আসে যেখানে এখানে. যদিও লগিং একটি নতুন ধারণা নয় এবং অনেকগুলি সহজ-তে-বাস্তবায়ন সমাধান বিদ্যমান, কার্যকর লগগুলি নিশ্চিত করা চ্যালেঞ্জিং। প্রায়শই, লগগুলি অস্পষ্ট, অত্যধিক জটিল, অভাব, বা অপ্রাসঙ্গিক এন্ট্রিতে প্লাবিত হয়, যা সমস্যা সমাধানকে কঠিন করে তোলে। যাইহোক, লগগুলি শুধুমাত্র সমস্যা সমাধানের জন্য নয়। সঠিক লগিং নতুন বৈশিষ্ট্য এবং পরিবর্তনের কার্যকারিতা যাচাই করতে সাহায্য করে। লগ এন্ট্রির নমুনা নেওয়ার মাধ্যমে, কেউ ব্যবহারকারীর যাত্রা ট্রেস করতে পারে এবং সিস্টেমের কার্যকারিতা নিশ্চিত করতে পারে। সর্বশেষ ভাবনা উৎপাদনে শিপিং কোড কখনও কখনও বিপজ্জনক, কিন্তু প্রক্রিয়াটিকে আরও নিরাপদ করতে আমাদের অনেক কৌশল রয়েছে৷ এমনকি যদি আমরা একটি সমস্যা চিহ্নিত করি, তাহলে কী গ্রহণযোগ্য বা না তা জানাও গুরুত্বপূর্ণ। সমস্ত ব্যর্থতার একটি রোলব্যাক হতে হবে না। যদি আমরা একটি গুরুতর নিরাপত্তা ত্রুটি ঠিক করার চেষ্টা করি, বা একটি নতুন নিয়ম মেনে চলি? স্পষ্ট মানদণ্ড থাকা এবং পরিবর্তনটি কতটা সমালোচনামূলক তা বোঝা অত্যন্ত গুরুত্বপূর্ণ যে কখন গর্ভপাত করা উচিত বা সমস্যার ক্ষেত্রে এগিয়ে যেতে হবে। শুরুতে ফিরে যাওয়া, সিদ্ধান্ত নেওয়ার প্রক্রিয়ায় আমাদের সাহায্য করার জন্য মূল মেট্রিক্স রয়েছে। নিরাপদ অবতরণ, সবাই!
