2,000+ Discord সার্ভারে একটা বট চালিয়ে আমরা যা শিখেছি

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

এখানে চারটি দেওয়া হলো যেগুলো আমাদের সত্যিকারের বিভ্রাট ঘটিয়েছে।

1. ব্যর্থতা সমানভাবে ছড়ায় না, লুকিয়ে থাকে

AlphaCloud কয়েকটি প্রসেসে ভাগ হয়ে চলে, যাদের শার্ড বলে। কোন সার্ভার কোন শার্ডে যাবে তা Discord ঠিক করে, আর প্রতিটি শার্ড শুধু নিজের সার্ভারগুলো চেনে।

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

শিক্ষাটা চমকহীন আর সর্বজনীন: প্রতিটি বাইরে যাওয়া কলের একটা ঊর্ধ্বসীমা দরকার। যে কল চিরকাল অপেক্ষা করে তা ব্যর্থ হওয়া কলের চেয়েও খারাপ, কারণ ব্যর্থতা অন্তত চোখে পড়ে।

2. রিস্টার্ট কোনো সমাধান নয়, এটা একটা সময়সীমা

যতক্ষণ আমরা কারণ জানতাম না, ক্ষতিগ্রস্ত শার্ড রিস্টার্ট করলে নির্ভরযোগ্যভাবে কাজ হতো। রিস্টার্টের সমস্যা ঠিক এটাই: এগুলো কাজ করে, আর তাতে কারণ খোঁজার চাপ চলে যায়।

এখন আমরা "রিস্টার্টে কি কাজ হয়?" প্রশ্নটাকে প্রতিকার নয়, রোগনির্ণয় হিসেবে দেখি। কাজ হলে ভাঙা অবস্থাটা মেমরিতে থাকে, আর কোডে এমন একটা জায়গা আছে যা সেটা গড়ে তোলে আর কখনো ভাঙে না।

উল্টোটাও সত্য: যা কিছু রিস্টার্টের পরও টিকে থাকতে হবে, তার জায়গা ডেটাবেসে। কোনো বহু ধাপের কাজ চলতে থাকলে, ধরুন হাজার হাজার সদস্যের রোল বদল, আর প্রসেস মাঝপথে মারা গেলে, কাজটা এমনি এমনি হারিয়ে যেতে পারে না। পরের চালুর সময় এটা শনাক্ত করে চালিয়ে যেতে হবে।

3. Discord-এর সীমা বট অনুযায়ী, প্রসেস অনুযায়ী নয়

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

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

একটা সম্পর্কিত ফাঁদ: নিয়মিত কাজগুলো নির্দিষ্ট বিরতিতে চলে, ধরুন প্রতি পাঁচ মিনিটে। সব শার্ড একই সময়ে শুরু হলে তারা চিরকাল একই মুহূর্তে নিজেদের কাজ চালায়। তখন থেকে প্রতিটি প্রসেস শুরুর সময় একটা এলোমেলো অফসেট পায়।

4. মানুষ আসলে যা কনফিগার করে তা আপনার প্রত্যাশা নয়

প্রযুক্তিগত অংশ একটা অর্ধেক। অন্যটা: বেশিরভাগ সার্ভারের জন্য ডিফল্টই হলো সেটিং। যে মডিউলের ডিফল্ট ভুল, সেটা বিপুল সংখ্যক সার্ভারে ভুলভাবে কনফিগার করা, সেটিংসের পেজ যত ভালোই হোক।

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

এটাই এমন এক সিদ্ধান্তের পেছনের কারণ যা প্রথমে উল্টো শোনায়: v1.8.0 থেকে বটের পাঠানো প্রায় প্রতিটি মেসেজ স্বাধীনভাবে ডিজাইন করা যায়। কিন্তু সতর্কতার DM-এর কারণ বা টিকিট প্যানেলের ক্যাটাগরি মেনুর মতো বাধ্যতামূলক ব্লক সরানো যায়, মোছা যায় না। ডিজাইনের স্বাধীনতা হ্যাঁ, কিন্তু এতটা নয় যে কোনো সার্ভার ভুল করে এমন কিছু বানিয়ে ফেলে যা কাজ করছে বলে মনে হয় অথচ করে না।

মূল সুতো

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

তাই নতুন কোড সম্পর্কে আমরা এখন প্রথমে যে প্রশ্নটা করি তা "এটা কি কাজ করে" নয়, বরং "এটা কাজ না করলে কেমন দেখায়, আর আমরা কি তা লক্ষ করব"।