ঘটনার সময় রিড-ওনলি মোড: পড়া চালিয়ে রাখুন, লেখাকে ব্লক করুন
ইনসিডেন্ট চলাকালীন রিড-ওনলি মোড কীভাবে লেখাগুলো ব্লক করে, গুরুত্বপূর্ণ পড়াগুলো চালিয়ে রাখে, এবং আপনার ডাটাবেস চাপযুক্ত হলে UI-তে স্পষ্টভাবে কী জানাবে তা জানুন।
যখন ডাটাবেস চাপের মধ্যে থাকে, প্রথমে কী ভেঙে যায়
আপনার ডাটাবেস অতিভার হলে ব্যবহারকারীরা ritidy একটি পরিষ্কার "ডাউন" বার্তা কম দেখে। তারা টাইমআউট, অর্ধেক লোড হওয়া পেজ, চিরন্তনভাবে ঘূর্ণন করা বোতাম এবং এমন কার্যকলাপ দেখতে পায় যা মাঝে মাঝে কাজ করে এবং মাঝে মাঝে ব্যর্থ হয়। একটি সেভ একবার সফল হতে পারে, তারপর পরেরবার "কিছু ভুল হয়েছে" ত্রুটি দেখায়। এই অনিশ্চয়তা ঘটনার সময় পরিস্থিতিকে বিশৃঙ্খল মনে করায়।
প্রথমে ভাঙে সাধারণত write-heavy পাথগুলো: রেকর্ড এডিট, চেকআউট ফ্লো, ফর্ম সাবমিট, ব্যাকগ্রাউন্ড আপডেট এবং যেটা ট্রানজেকশন ও লক চায়। চাপের সময় লেখাগুলো ধীর হয়, তারা একে অপরকে ব্লক করে, এবং পড়াগুলোও ধীর করে দিতে পারে কারণ লক ধরে রাখা হয় বা অতিরিক্ত কাজ ঘটে।
অপ্রত্যাশিত ত্রুটি একটি নিয়ন্ত্রিত সীমাবদ্ধতার চেয়ে খারাপ অনুভব হয় কারণ ব্যবহারকারীরা বুঝতে পারে না পরবর্তী কী করা উচিত। তারা রিট্রাই করে, রিফ্রেশ করে, আবার ক্লিক করে, এবং আরও লোড তৈরি করে। সাপোর্ট টিকিট বেড়ে যায় কারণ সিস্টেম "কিন্তু কাজ করছে" মনে হয়, কিন্তু কাউকেই বিশ্বাস করার মতো কিছু নেই।
ইনসিডেন্টে রিড-ওনলি মোডের উদ্দেশ্য পারফেকশন নয়। উদ্দেশ্য হলো সবচেয়ে গুরুত্বপূর্ণ অংশগুলো ব্যবহারযোগ্য রাখা: মূল রেকর্ড দেখা, সার্চ করা, স্ট্যাটাস দেখা এবং লোকেরা কাজ চালিয়ে নিতে যা দরকার তা ডাউনলোড করা। আপনি ইচ্ছাকৃতভাবে ঝুঁকিপূর্ণ অ্যাকশনগুলো (লেখাগুলো) থামান বা বিলম্ব করেন যাতে ডাটাবেস পুনরুদ্ধার পায় এবং বাকি পড়াগুলো রেসপনসিভ থাকে।
স্পষ্টভাবে প্রত্যাশা স্থাপন করুন। এটি একটি অস্থায়ী সীমা, এবং এর মানে ডেটা মুছে ফেলা হচ্ছে না। অধিকাংশ ক্ষেত্রে ব্যবহারকারীর পূর্ববর্তী ডেটা এখনও সেখানে আছে এবং নিরাপদ—সিস্টেম শুধু ডাটাবেস সুস্থ না হওয়া পর্যন্ত পরিবর্তনগুলো স্থগিত করছে।
রিড-ওনলি মোড আসলে কী মানে
ইনসিডেন্ট চলাকালীন রিড-ওনলি মোড হলো একটি অস্থায়ী অবস্থা যেখানে আপনার প্রোডাক্ট দেখা যায় কিন্তু ডেটা পরিবর্তন করে এমন কিছুই গ্রহণ করে না। লক্ষ্য সহজ: সার্ভিসকে সাহায্যযোগ্য রাখা এবং ডাটাবেসকে অতিরিক্ত কাজ থেকে রক্ষা করা।
সরল কথায়, মানুষ এখনও খোঁজ নিতে পারবে, কিন্তু তারা এমন জিনিস পরিবর্তন করতে পারবে না যা লেখার ট্রিগার দেয়। সাধারণত ব্রাউজিং পেজ, সার্চ, ফিল্টার এবং রেকর্ড খোলা কাজ করবে। ফর্ম সেভ, সেটিংস এডিট, কমেন্ট পোস্ট, ফাইল আপলোড, বা নতুন অ্যাকাউন্ট তৈরি করা ব্লক করা হবে।
প্রায়োগিকভাবে ভাবলে: যদি কোনো অ্যাকশন সারি আপডেট করে, সারি তৈরি করে, সারি মুছে ফেলে, বা কিউতে লেখে—তাহলে তা অনুমোদিত নয়। অনেক দল "গোপন লেখাগুলো" ও ব্লক করে, যেমন অ্যানালিটিক্স ইভেন্ট যা প্রাইমারি ডাটাবেসে রাখা হয়, সিংক্রোনাস অডিট লগ, এবং "last seen" টাইমস্ট্যাম্প।
রিড-ওনলি মোড সেই সময় ঠিক যখন পড়াগুলো প্রায় ক স্বাভাবিক কাজ করছে, কিন্তু লেখার লেটেন্সি বাড়ছে, লক কনটেনশন বাড়ছে, বা লেখাভিত্তিক কাজের ব্যাকলগ সবকিছু ধীর করে দিচ্ছে।
যখন এমনকি বেসিক পড়াও টাইমআউট করে, আপনার ক্যাশও প্রয়োজনীয় জিনিস সরবরাহ করতে পারে না, বা সিস্টেম বিশ্বাসযোগ্যভাবে বলতে পারে না ব্যবহারকারীরা কী নিরাপদভাবে করতে পারে—তখন পুরোপুরি অফলাইন যান।
কেন এটা সাহায্য করে: লেখাগুলো প্রায়ই একটি সাধারণ রিডের তুলনায় অনেক বেশি খরচ করে। একটি লেখা ইনডেক্স, কনস্ট্রেইন্ট, লক এবং অনুসৃত কুয়েরি ট্রিগার করতে পারে। লেখাগুলো ব্লক করলে রিট্রাই স্টর্মও প্রতিরোধ হয়, যেখানে ক্লায়েন্টরা ব্যর্থ সেভগুলো পুনরায় জমা দিয়ে আরও ক্ষতি বাড়ায়।
উদাহরণ: একটি CRM ইনসিডেন্ট চলাকালীন, ব্যবহারকারীরা এখনও অ্যাকাউন্ট সার্চ করতে, কনট্যাক্ট ডিটেইল খুলতে এবং সাম্প্রতিক ডিল দেখতে পারে, কিন্তু Edit, Create, এবং Import অ্যাকশনগুলো নিষ্ক্রিয় থাকবে এবং কোনো সেভ অনুরোধ দ্রুত প্রত্যাখ্যাত হবে একটি স্পষ্ট বার্তা দিয়ে।
কোন পড়াগুলো রাখতে হবে এবং কোন লেখাগুলো বন্ধ করবেন
ইনসিডেন্টে রিড-ওনলি মোডে স্যুইচ করলে লক্ষ্য "সবকিছু কাজ করুক" নয়। লক্ষ্য হলো সবচেয়ে গুরুত্বপূর্ণ স্ক্রিনগুলো লোড হয়, যখন যেকোনো জিনিস যা ডাটাবেসে চাপ বাড়ায় তা দ্রুত এবং নিরাপদে বন্ধ করা হয়।
শুরু করুন কিছু ব্যবহারকারীর কার্যকলাপ নাম করে যেগুলো খারাপ দিনে কাজ করা জরুরি। সাধারণত এগুলো ছোট পড়া যা সিদ্ধান্তে সহায়ক: সাম্প্রতিক রেকর্ড দেখা, স্ট্যাটাস চেক করা, ছোট তালিকা সার্চ করা, বা ইতিমধ্যেই ক্যাশ করা রিপোর্ট ডাউনলোড করা।
তারপর নির্ধারণ করুন কী আপনি স্থগিত করতে পারেন বড় ক্ষতি ছাড়াই। অধিকাংশ লেখার পথ ইনসিডেন্টে "থাকলে ভালো" শ্রেণীর: এডিট, বাল্ক আপডেট, ইমপোর্ট, মন্তব্য, অ্যাটাচমেন্ট, অ্যানালিটিক্স ইভেন্ট, এবং যেকোনো কিছু যা অতিরিক্ত কুয়েরি ট্রিগার করে।
একটি সহজ উপায় সিদ্ধান্ত নেওয়ার জন্য কাজগুলো তিনটি বাল্কেটে ভাগ করুন:
- Must keep: ছোট, দ্রুত পড়া যা টাটকা সিদ্ধান্ত আনলক করে
- Can pause: লেখাগুলো এবং ভারী পড়া যা লোড বা লক বাড়ায়
- Can degrade: এমন ফিচার যা ক্যাশড ডেটা বা আংশিক ভিউ দেখাতে পারে
একটি সময়সীমাও ঠিক করুন। যদি মনে হয় ক’ মিনিট লাগবে, আপনি কঠোর হতে পারেন এবং প্রায় সব লেখাই ব্লক করতে পারেন। যদি ঘন্টা ধরে প্রবলেম চলতে পারে, সীমিত নিরাপদ লেখাগুলো (যেমন পাসওয়ার্ড রিসেট বা জরুরি স্ট্যাটাস আপডেট) অনুমোদন বিবেচনা করুন এবং বাকিগুলো কিউ করুন।
প্রায়োরিটি আগে থেকেই ঠিক করুন: পূর্ণতার চেয়ে নিরাপত্তা। একটি স্পষ্ট "চেঞ্জগুলো স্থগিত" বার্তা দেখানোটা ভাল, বনাম এমন একটি লেখা অনুমোদন করা যা আংশিক সফল হয়ে ডেটা অসংগত রেখে যায়।
কখন চালু করবেন তা কিভাবে সিদ্ধান্ত নেবেন
রিড-ওনলি চালু করা একটি ব্যবসা: এখন কম ফিচার, কিন্তু একটি ব্যবহারযোগ্য প্রোডাক্ট এবং একটি সুস্থ ডাটাবেস। লক্ষ্য হলো ব্যবহারকারীরা রিট্রাই, টাইমআউট, এবং আটকে থাকা কানেকশনের দিকে না ঠেলে আগে থেকেই উদ্যোগ নেওয়া।
এক বাক্যে বোঝানো যায় এমন কয়েকটি সিগন্যাল দেখুন। যদি একযোগে দুই বা ততোধিক পাওয়া যায়, এটাকে একটি প্রাথমিক সতর্কতা হিসেবে নিন:
- রিকোয়েস্ট টাইমআউট হচ্ছে বা একটি পরিষ্কার লেটেন্সি থ্রেশহোল্ড পার করছে (উদাহরণ: p95 300 ms থেকে 3 s-এ চলে গিয়েছে)
- ডাটাবেস CPU কয়েক মিনিট ধরে উচ্চ স্তরে আটকে আছে, শুধু একটি ছোট স্পাইক নয়
- কানেকশন পুল এক্সহস্টেড (রিকোয়েস্টগুলো লাইন করছে কারণ কোনো কানেকশন নেই)
- স্লো কুয়েরি লগ একই কয়েকটি কুয়েরি দিয়ে হরে ভরে যাচ্ছে
- লক ওয়েট, ডেডলক, বা ব্যর্থ ট্রানজেকশনের কারণে ত্রুটি হার বাড়ছে
শুধু মেট্রিকসই ট্রিগার হওয়া উচিত নয়। একটি মানব সিদ্ধান্ত যোগ করুন: অন-কল ব্যক্তি ইনসিডেন্ট ঘোষণা করে এবং রিড-ওনলি চালু করে। এটা চাপের মধ্যে বিতর্ক বন্ধ করে এবং কাজটিকে অডিটেবল করে।
থ্রেশহোল্ডগুলো সহজে মনে রাখার মতো এবং যোগাযোগযোগ্য রাখুন। "Writes are paused because the database is overloaded" বলাটা "we hit saturation" বলার চেয়ে পরিষ্কার। এছাড়াও নির্ধারণ করুন কে সুইচ চাইলে ফেলতে পারে এবং কোথায় কন্ট্রোল আছে।
মোডের মধ্যে বারবার দোলাচলের থেকে বিরত থাকুন। সহজ হিস্টেরেসিস যোগ করুন: একবার রিড-ওনলি গেলে একটি ন্যূনতম সময় (১০-১৫ মিনিট) ধরে থাকুন এবং কেবল তখনই ফিরিয়ে আনুন যখন মূল সিগন্যালগুলো কিছুটা স্থিতিশীল থাকে। এতে ব্যবহারকারীরা এক মিনিটে ফর্ম কাজ করছে আর পরের মিনিটে ব্যর্থ হচ্ছে—এ রকম বিভ্রান্তির সম্মুখীন হবে না।
ধাপে ধাপে: নিরাপদভাবে রিড-ওনলি চালু করা
রিড-ওনলি মোডকে একটি নিয়ন্ত্রিত পরিবর্তন হিসেবে বিবেচনা করুন, হুড়োহুড়ি নয়। লক্ষ্য হলো ডাটাবেসকে রক্ষা করা লেখাগুলো বন্ধ করে, যখন সবচেয়ে মূল্যবান পড়াগুলো কাজ করে রাখতে হবে।
একটি নিরাপদ রোলআউট সিকোয়েন্স
সম্ভব হলে, ফ্লিপ করা আগে কোড পাথ ডিপ্লয় করুন। এভাবে রিড-ওনলি চালু করা কেবল একটি টগল হবে, লাইভ এডিট নয়।
- একটি ইনসিডেন্ট টগল তৈরী করুন (ফিচার ফ্ল্যাগ বা কনফিগ সেটিং) যেটা পুরো সিস্টেম পড়ে। এটাকে গ্লোবাল এবং সাধারণ রাখুন:
READ_ONLY=true. একাধিক ফ্ল্যাগ এড়ান যা সিঙ্ক থেকে বিচ্যুত হতে পারে। - UI আপডেট করুন যাতে লেখা প্রচেষ্টা প্রতিরোধ করা যায়। Save বোতাম অক্ষম করুন, এডিট ফর্ম লুকান এবং ইনপুটগুলোকে প্লেইন টেক্সটে রূপান্তর করুন। ডেটা দেখানো চালিয়ে যান যাতে মানুষ কাজ চালিয়ে যেতে পারে (দেখা, সার্চ, এক্সপোর্ট)।
- সার্ভারে জোর দিন, কেবল UI-তে নয়। এক জায়গায় লেখাগুলো ব্লক করুন (মিডলওয়্যার, কন্ট্রোলার গার্ড, বা সার্ভিস লেয়ার) যাতে সব ক্লায়েন্ট কভার হয়—মোবাইল অ্যাপ, API ব্যবহারকারী, এবং অটোমেশনও।
- ব্লক করা লেখাগুলোর জন্য একটি স্পষ্ট, সংগত ত্রুটি ফেরত দিন। একটি দিয়েডিকেটেড স্ট্যাটাস কোড এবং বার্তা ব্যবহার করুন, উদাহরণ: "Editing is temporarily disabled while we stabilize the system. Your data is safe. Try again later." সাধারণ 500 ফেরত দিবেন না যা ডেটা লসের মতো মনে হয়।
- প্রতিটি ব্লক করা লেখা চেষ্টা লগ করুন। ব্যবহারকারী, এন্ডপয়েন্ট, এবং অ্যাকশন টাইপ ধরুন। লোড সীমিত রাখার জন্য পেয়লোড ছোট রাখুন যাতে সংবেদনশীল ডেটা লগে না যায়। এই লগগুলো UX গ্যাপ ফিক্স করতে এবং প্রয়োজনে ক্রিটিক্যাল অ্যাকশনগুলো পরে রিপলেতে সাহায্য করে।
একটি ছোট বিস্তারিত যা পুনরাবৃত্তি প্রতিরোধ করে
রিড-ওনলি সক্রিয় থাকলে, ডাটাবেসে পৌঁছানোর আগে দ্রুত ব্যর্থ করুন। ভ্যালিডেশনের জন্য কুয়েরি চালিয়ে তারপর ব্লক করবেন না। সবচেয়ে দ্রুত ব্লক করা রিকোয়েস্টটি সেটাই যা আপনার চাপের ডাটাবেসে কখনোই পৌঁছায় না।
UI বার্তা যা বিভ্রান্তি এবং সাপোর্ট টিকিট কমায়
রিড-ওনলি চালু করলে UI নিজেই ফিক্সে অংশীদার। যদি মানুষ বার বার Save চাপা রেখে অস্পষ্ট ত্রুটি পায়, তারা রিট্রাই, রিফ্রেশ করবে এবং টিকিট খুলবে। স্পষ্ট বার্তা লোড ও হতাশা কমায়।
একটি ভাল প্যাটার্ন হলো অ্যাপের উপরে একটি দৃশ্যমান, স্থায়ী ব্যানার। সংক্ষিপ্ত এবং বিষয়ভিত্তিক রাখুন: কী হচ্ছে, ব্যবহারকারীরা কী আশা করবে, এবং তারা এখন কী করতে পারে। এটাকে একটি অদৃশ্য টোস্টে লুকাবেন না যা অদৃশ্য হয়ে যায়।
কী কাজ করে, কী স্থগিত, এবং পরবর্তী কী
ব্যবহারকারীরা মূলত জানতে চান তারা কাজ চালিয়ে যেতে পারবে কিনা। সরল ভাষায় এটা বলুন। বেশিরভাগ প্রোডাক্টে এর মানে:
- এখনো কাজ করে: রেকর্ড দেখা, সার্চ, ডাউনলোড, ড্যাশবোর্ড পড়া
- বৃহৎ: তৈরি করা, এডিট, ডিলিট, আপলোড, পেমেন্ট, বার্তা পাঠানো স্থগিত
- পরিবর্তে করুন: মূল তথ্য কপি করুন, ভিউ এক্সপোর্ট করুন, পরে রিট্রাই করুন
- আপডেট: "আমরা এখানে ১৫ মিনিটে একটি আপডেট পোস্ট করব।"
একটি সরল স্ট্যাটাস লেবেলও মানুষকে অগ্রগতি বুঝতে সাহায্য করে। "Investigating" মানে আপনি এখনও কারণ খুঁজছেন। "Stabilizing" মানে আপনি লোড কমাচ্ছেন এবং ডেটা রক্ষা করছেন। "Recovering" মানে লেখাগুলো শীঘ্রই ফিরবে, কিন্তু ধীর হতে পারে।
স্বর শান্ত এবং নির্দিষ্ট রাখুন
কিন্তু দোষারোপী বা অস্পষ্ট টেক্সট এড়ান যেমন "Something went wrong" বা "You did not have permission." যদি কোনো বোতাম নিষ্ক্রিয় থাকে তাহলে লেবেল দিন: "Editing is temporarily paused while we stabilize the system."
একটি ছোট উদাহরণ: একটি CRM-এ কনট্যাক্ট এবং ডিল পেজ পড়ার যোগ্য রাখুন, কিন্তু Edit, Add note, এবং New deal নিষ্ক্রিয় করুন। কেউ যদি তবুও চেষ্টা করে, একটি সংক্ষিপ্ত ডায়লগ দেখান: "Changes are paused right now. You can copy this record or export the list, then try again later."
মূল পড়াগুলো বজায় রাখুন তবে লোড বাড়াবেন না
রিড-ওনলি চালু করলে লক্ষ্য "সব কিছু দৃশ্যমান রাখুন" নয়—লক্ষ্য হলো "মানুষ যারা নির্ভর করে তাদের কয়টি পেজ রাখুন", ডাটাবেসে অতিরিক্ত চাপ না বাড়িয়ে।
সবচেয়ে ভারী স্ক্রিনগুলো কাটুন। দীর্ঘ টেবিল যেখানে অনেক ফিল্টার, বহু-ফিল্ড ফ্রি-টেক্সট সার্চ, এবং জটিল সোর্ট প্রায়ই ধীর কুয়েরি ট্রিগার করে। রিড-ওনলি-তে ঐ স্ক্রিনগুলো সরল করুন: কম ফিল্টার অপশন, একটি নিরাপদ ডিফল্ট সোর্ট, এবং একটি কাটা তারিখ পরিসর দিন।
যেই পেজগুলো গুরুত্বপূর্ণ, সেগুলোর জন্য ক্যাশ বা প্রি-ক্যালকুলেটেড ভিউ ব্যবহার করুন। একটি সহজ "account overview" যা ক্যাশ বা সারাংশ টেবিল থেকে পড়ে তা সাধারণত কাঁচা ইভেন্ট লগ বা অনেক টেবিল জয়েন করার চেয়ে নিরাপদ।
প্রায়োগিক উপায়গুলো:
- ছোট পেজ সাইজ ব্যবহার করুন এবং "show all" সরান
- জটিল সোর্টগুলোর বদলে একটি ডিফল্ট অর্ডার দিন (উদাহরণ: "most recent first")
- অপ্রয়োজনীয় পড়া (অ্যানালিটিক্স, রিকমেন্ডেশন, অ্যাক্টিভিটি চার্ট) পিছিয়ে রাখুন
- কাঁচা ইতিহাসের চাইতে ক্যাশড সারাংশ প্রাধান্য দিন
- কোর পেজ রেসপনসিভ রাখার জন্য খানিকটা স্টেল ডেটা অনুমোদন করুন
একটি বাস্তব উদাহরণ: CRM ইনসিডেন্টে View contact, View deal status, এবং View last note কাজ করবে। অস্থায়ী ভাবে Advanced search, Revenue chart, এবং Full email timeline লুকিয়ে রাখুন, এবং একটি নোট দেখান যে ডেটা কয়েক মিনিট পুরনো হতে পারে।
জব, ওয়েবহুক, এবং ইন্টিগ্রেশন নিয়ে কী করবেন
রিড-ওনলি স্যুইচ করলে অবাক করার মতো বিষয়টি প্রায়ই UI নয়। সেটা হলো অদৃশ্য লেখাগুলো: ব্যাকগ্রাউন্ড জব, শিডিউলড সিঙ্ক, অ্যাডমিন বাল্ক অ্যাকশন, এবং তৃতীয়-পক্ষ ইন্টিগ্রেশন যা ডাটাবেসে বারবার লেখে।
প্রথমে সেই ব্যাকগ্রাউন্ড কাজগুলো থামান যা রেকর্ড তৈরি বা আপডেট করে। সাধারণ ক্ষেত্রে অপরাধী হলো ইমপোর্ট, নাইটলি সিঙ্ক, ইমেইল পাঠানোর সময় ডেলিভারি লগ লেখা, অ্যানালিটিক্স রোলআপ, এবং ব্যর্থ আপডেটটিকে বারবার রিট্রাই করার লুপ। এসব স্থগিত করলে দ্রুত চাপ কমে এবং দ্বিতীয় ঢেউয়ের লোড প্রতিরোধ হয়।
নিরাপদ ডিফল্ট হলো write-heavy জবগুলো থামানো বা থ্রটল করা এবং যেকোনো কিউ কনসিউমার যারা ফলাফল প্রিজিস্ট করে সেগুলো স্থগিত করা, অ্যাডমিন বাল্ক অ্যাকশন (মাস আপডেট, বাল্ক ডিলিট, বড় রি-ইন্ডেক্স) নিষ্ক্রিয় করা, এবং টাইমআউট না করে একটি স্পষ্ট অস্থায়ী উত্তর ফেরত দেওয়া।
ওয়েবহুক এবং ইন্টিগ্রেশনের জন্য স্পষ্টতা আশার চেয়ে ভাল। আপনি যদি একটি ওয়েবহুক গ্রহণ করেন কিন্তু এটি প্রসেস করতে না পারেন, আপনি ম্যাচমিস তৈরি করবেন এবং সাপোর্ট বাড়াবেন। লেখাগুলো স্থগিত হলে প্রেরককে পরে পুনরায় চেষ্টা করতে বলার মতো একটি টেম্পোরারি ফেলিওর ফিরিয়ে দিন, এবং নিশ্চিত করুন আপনার UI বার্তা ব্যাকএন্ড আচরণের সাথে মেলে।
"পরে কিউ করুন" কনসেপ্টটি বন্ধ মনে হলেও এটা এমন একটি ব্যাকলগ তৈরি করতে পারে যা লেখার পুনরায় চালু হলে সিস্টেমকে প্লাবিত করে। কেবল ব্যবহারকারীর লেখাগুলো কিউ করুন যদি আপনি আইডেম্পটেন্সি নিশ্চিত করতে পারেন, কিউ সাইজ ক্যাপ করে রাখুন, এবং ব্যবহারকারীকে প্রকৃত অবস্থা দেখান (pending vs saved)।
অবশেষে, আপনার নিজের পণ্যেই লুকানো বড়-লেখক অটোমেশনগুলো অডিট করুন। যদি কোনো অটোমেশন হাজার হাজার সারি আপডেট করতে পারে, তবে রিড-ওনলি মোডে সেটিকে বাধ্যতামূলকভাবে বন্ধ করুন এমনকি বাকি অ্যাপ লোড হলে ও।
সাধারণ ভুল যা ইনসিডেন্ট খারাপ করে
সবচেয়ে দ্রুত একটি খারাপ ইনসিডেন্টকে খারাপ করে তোলা হলো রিড-ওনলি মোডকে সারফেসিয়াল পরিবর্তন হিসেবে দেখা। যদি আপনি কেবল UI-তে বাটন নিষ্ক্রিয় করেন, মানুষ তখনও API, পুরনো ট্যাব, মোবাইল অ্যাপ, এবং ব্যাকগ্রাউন্ড জবের মাধ্যমে লিখে যাবে। ডাটাবেস চাপের মধ্যে থাকবে, এবং আপনি বিশ্বাসও হারাবেন কারণ এক জায়গায় "saved" দেখছে আর অন্য জায়গায় পরিবর্তনী নেই।
একটি বাস্তব রিড-ওনলি মোডের জন্য একটি স্পষ্ট নিয়ম লাগে: সার্ভার সব ক্লায়েন্টের জন্য সব সময় লেখাকে প্রত্যাখ্যান করবে।
দেখতে থাকা ভুলগুলো
এই প্যাটার্নগুলো প্রায়শই দেখা যায়:
- কেবল UI-তে এডিট ব্লক করা হলেও ব্যাকএন্ড POST, PUT, PATCH, DELETE গ্রহণ করে থাকা
- লুকানো পথ ভুলে যাওয়া: অ্যাডমিন প্যানেল, ইন্টার্নাল টুল, ইমপোর্ট এন্ডপয়েন্ট, এবং ইন্টিগ্রেশন দ্বারা ব্যবহৃত পাবলিক API
- সিস্টেমকে প্রতি মিনিটে নর্মাল এবং রিড-ওনলি মোডের মধ্যে দোলাতে দেয়া
- অস্পষ্ট মেসেজ দেখানো যেমন "Something went wrong"
- আংশিক লেখাকে অনুমোদন করা যা ডেটা অসংগত রেখে যায়
এগুলো কীভাবে এড়াবেন
সিস্টেমকে ভবিধর্মী হিসেবে কাজ করান। একটি একক সার্ভার-সাইড সুইচ প্রয়োগ করুন যা লেখাকে স্পষ্ট উত্তর দিয়ে প্রত্যাখ্যান করে। এক কুলডাউন যোগ করুন যাতে একবার রিড-ওনলি গেলে একটি নির্দিষ্ট সময় (উদাহরণ: ১০-১৫ মিনিট) ধরে থাকে, যদি না কোনো অপারেটর আলাদাভাবে পরিবর্তন করে।
ডেটা ইন্টিগ্রিটির ব্যাপারে কড়া হন। যদি কোনো লেখা পুরোপুরি সম্পন্ন না হতে পারে, পুরো অপারেশন ব্যর্থ করুন এবং ব্যবহারকারীকে পরবর্তী কী করতে হবে তা জানান। একটি সহজ বার্তা যেমন "Read-only mode: viewing works, changes are paused. Try again later." রিট্রাই কমায়।
ইনসিডেন্টের আগে ও চলাকালীন দ্রুত চেকগুলো
রিড-ওনলি মোড কেবল তখনই সাহায্য করে যখন এটি দ্রুত চালু করা যায় এবং সব জায়গায় একই আচরণ করে। সমস্যার আগে নিশ্চিত করুন একটি একক টগল (ফিচার ফ্ল্যাগ, কনফিগ, অ্যাডমিন সুইচ) আছে যা অন-কল কয়েক সেকেন্ডেই সক্রিয় করতে পারে, কোন ডিপ্লয় ছাড়াই।
ডাটাবেস অতিভার সন্দেহ হলে দ্রুত একটি পাস করুন যা মৌলিকগুলো নিশ্চিত করে:
- একটি নিরাপদ এনভায়রনমেন্টে টগল ফ্লিপ করুন এবং নিশ্চিত করুন তা তৎক্ষণাৎ কার্যকর হয়
- কয়েকটি লিখনের অ্যাকশন (সেভ, ডিলিট, ইমপোর্ট) চালিয়ে দেখুন প্রতিটি লিখে যাওয়া এন্ডপয়েন্ট একই ব্লক করা উত্তর এবং স্ট্যাটাস কোড দেয়
- ব্যানার টেক্সট সংক্ষিপ্ত ও দৃশ্যমান আছে কিনা চেক করুন
- আপনার টপ ৩ পেজ লোড করুন (উদাহরণ: লগইন, ড্যাশবোর্ড, রেকর্ড ভিউ) এবং নিশ্চিত করুন এগুলো চাপেও রেন্ডার করে
- সাপোর্টের কাছে একটি এক-প্যারাগ্রাফ স্ক্রিপ্ট রাখুন যা বলে কি কাজ করে, কী স্থগিত, এবং কোথায় আপডেট দেখা যাবে
ইনসিডেন্ট চলাকালীন, একটি মানুষকে UX যাচাই করার উপর মনোনিবেশ করুন, কেবল ড্যাশবোর্ডগুলো নয়। একটি ইনকগনিটো উইন্ডোতে দ্রুত স্পট চেক করে দেখুন লুকানো ব্যানার, ভাঙা ফর্ম, বা অনন্ত স্পিনার আছে কি না—এইগুলো রিফ্রেশ ট্রাফিক বাড়ায়।
চালু করার আগে একটি exit পরিকল্পনা রাখুন। "স্বাস্থ্যবান" হওয়ার শর্ত কী (লেটেন্সি, ত্রুটি হার, রিপ্লিকেশন লাগ) ঠিক করুন এবং ফিরিয়ে আনার পর সংক্ষিপ্ত যাচাই করুন: একটি টেস্ট রেকর্ড তৈরি করুন, এডিট করুন, এবং নিশ্চিত করুন গণনা ও সাম্প্রতিক কার্যকলাপ সঠিক।
উদাহরণ ইনসিডেন্ট: CRM-কে ব্যবহারযোগ্য রাখা যখন এডিট ব্লক করা আছে
সময় 10:20 AM. আপনার CRM ধীর, এবং ডাটাবেস CPU পিন করা। সাপোর্ট টিকিট আসছে: ব্যবহারকারীরা কনট্যাক্ট ও ডিল-এ এডিট সেভ করতে পারছে না। কিন্তু টিম এখনও ফোন নাম্বার খুঁজে দেখতে, ডিল স্টেজ দেখার এবং সর্বশেষ নোট পড়ার প্রয়োজন আছে।
আপনি একটি সহজ নিয়ম বেছে নেন: যা কিছু লেখে freeze করে দিন, সবচেয়ে মূল্যবান পড়াগুলো রাখুন। বাস্তবে, কনট্যাক্ট সার্চ, কনট্যাক্ট ডিটেইল পেজ, এবং ডিল পাইপলাইন ভিউ চালু থাকবে। কনট্যাক্ট এডিট, নতুন ডিল সৃষ্টি, নোট যোগ, এবং বাল্ক ইমপোর্ট ব্লক করা হবে।
UI-তে পরিবর্তনটি স্পষ্ট এবং শান্ত হওয়া উচিত। এডিট স্ক্রিনে Save বোতাম নিষ্ক্রিয় থাকবে এবং ফর্ম দেখা থাকবে যাতে মানুষ টাইপ করা কপি করতে পারে। উপরের দিকে একটি ব্যানার বলবে: "Read-only mode is on due to high load. Viewing is available. Changes are paused. Please try again later." কেউ যদি তবুও API কল করে লিখতে চায়, একটি স্পষ্ট বার্তা ফেরত দিন এবং ডাটাবেসে হামাগুড়ি দেওয়ার মতো অটো-রিট্রাই এড়িয়ে চলুন।
অপারেশনালি, গতিপথটি সংক্ষিপ্ত এবং পুনরাবৃত্যযোগ্য রাখুন। রিড-ওনলি চালু করুন এবং যাচাই করুন সব লিখে যাওয়া এন্ডপয়েন্ট এটাকে মানে। ব্যাকগ্রাউন্ড জব (সিঙ্ক, ইমপোর্ট, ইমেইল লগিং, অ্যানালিটিক্স ব্যাকফিল) থামান। ওয়েবহুক এবং ইন্টিগ্রেশন থ্রটল বা স্থগিত করুন। ডাটাবেস লোড, ত্রুটি হার, এবং স্লো কুয়েরি মনিটর করুন। কি প্রভাবিত (এডিট) এবং কি কাজ করে (সার্চ ও ভিউ) তা স্ট্যাটাস আপডেটে পোস্ট করুন।
পুনরুদ্ধার কেবল সুইচ ফিরিয়ে আনা নয়। লেখাগুলো ধীরগতিকভাবে পুনরায় চালু করুন, ব্যর্থ সেভের জন্য ত্রুটি লোগ পরীক্ষা করুন, এবং কিউ করা জবগুলোর থেকে একটি লেখার ঝড় এলে নজর রাখুন। তারপর পরিষ্কারভাবে জানাবেন: "Read-only mode is off. Saving is restored. If you tried to save between 10:20 and 10:55, please recheck your last changes."
পরবর্তী ধাপ: রিড-ওনলি মোডকে আপনার প্লেবুকের অংশ বানান
ইনসিডেন্টে রিড-ওনলি মোড সেরা কাজ করে যখন এটি সাধারণ এবং পুনরাবৃত্যনযোগ্য। লক্ষ্য হলো একটি ছোট স্ক্রিপ্ট অনুসরণ করা যার স্পষ্ট মালিক এবং চেক আছে।
একটি ছোট, ব্যবহারযোগ্য প্লেবুক বানান
এক পৃষ্ঠায় রাখুন। আপনার ট্রিগারগুলো (কয়েকটি সিগন্যাল যা রিড-ওনলি চালুর কারণ), আপনি কী সুইচ ফ্লিপ করবেন এবং কীভাবে লিখাগুলো ব্লক হচ্ছে তা কনফার্ম করবেন, কয়টি কোর রিড যা অবশ্যই কাজ করা উচিত, স্পষ্ট ভূমিকা (কে সুইচ ফ্লিপ করে, কে মেট্রিক দেখবে, কে সাপোর্ট হ্যান্ডল করবে), এবং exit ক্রাইটেরিয়া (কী সত্য হতে হবে লেখাগুলো পুনরায় চালুর আগে, এবং কিভাবে ব্যাকলগ ড্রেন করবেন) অন্তর্ভুক্ত করুন।
UI কপি আগে থেকেই প্রস্তুত করুন
এখনই টেক্সট লিখুন এবং অনুমোদন করুন যাতে আউটেজের সময় শব্দ নিয়ে তর্ক করতে না হয়। সাধারণভাবে নিচেরগুলি যথেষ্ট:
- ব্যানার: "We are in read-only mode while we restore performance. You can view data, but changes are temporarily disabled."
- ব্লক করা অ্যাকশনে: "Saving is paused right now. Your changes were not applied. Please try again in a few minutes."
- স্ট্যাটাস বিবরণ: "Last updated at HH:MM. Next update in 10 minutes."
স্টেজিং-এ সুইচ অনুশীলন করুন এবং সময় নিন। নিশ্চিত করুন সাপোর্ট ও অন-কল দ্রুত টগলটি খুঁজে পায় এবং লগে ব্লক করা লেখাগুলো স্পষ্টভাবে দেখা যায়। প্রতিটি ইনসিডেন্টের পরে পর্যালোচনা করুন কোন পড়াগুলো সত্যিই গুরুত্বপূর্ণ ছিল, কোনগুলো ছিল ভালো-থাকলে, এবং কোনগুলো দুর্ঘটনায় লোড সৃষ্টি করেছে—তারপর চেকলিস্ট আপডেট করুন।
যদি আপনি Koder.ai (koder.ai)-এ প্রোডাক্ট বানান, তাহলে রিড-ওনলি-কে আপনার জেনারেট করা অ্যাপে প্রথম শ্রেণির টগল হিসেবে বিবেচনা করা উপকারী হতে পারে যাতে UI এবং সার্ভার-সাইড লিখা রক্ষা একই থাকে যখন সবচেয়ে দরকার।
সাধারণ প্রশ্ন
What usually breaks first when the database is overloaded?
সাধারণত আপনার write-পাথগুলো প্রথমে খারাপ হয়: সেভ, এডিট, চেকআউট, ইমপোর্ট এবং যেসব অপারেশন ট্রানজেকশন চায়। লোড বাড়লে লক এবং ধীর কমিটগুলো লেখাগুলোকে একে অপরকে ব্লক করে, এবং সেগুলোই পড়াকে ধীর করে দিতে পারে।
Why do random errors feel worse than a clear outage?
কারণ এটি অনিশ্চিত মনে হয়। যদি কোনো কাজ মাঝে মাঝে কাজ করে এবং মাঝেমধ্যে ব্যর্থ হয়, ব্যবহারকারীরা বার বার রিট্রাই করে, রিফ্রেশ করে, ক্লিক করে — যা আরও লোড নিয়ে আসে এবং আরও টাইমআউট ও আটকে থাকা রিকোয়েস্ট তৈরি করে।
What does “read-only mode” actually mean?
এটি একটি অস্থায়ী অবস্থা যেখানে প্রোডাক্ট দেখার জন্য কাজে আসে কিন্তু পরিবর্তন প্রত্যাখ্যান করে। ব্যবহারকারীরা ব্রাউজ, সার্চ এবং রেকর্ড খুলতে পারবেন, কিন্তু যেকোনো কাজ যা ডেটা তৈরি, আপডেট বা ডিলিট করে তা ব্লক করা হবে।
What should be blocked in read-only mode besides obvious edits?
প্রাথমিক ডাটাবেসে লেখে এমন যেকোনো কাজকে ব্লক করা ভাল—এতে “অদৃশ্য লেখাগুলো” অন্তর্ভুক্ত: অডিট লগ, last-seen টাইমস্ট্যাম্প, এবং যদি analytics ইভেন্টগুলো প্রাইমারি ডাটাবেসে জমা হয় তবে সেগুলোও। যদি এটি কোনো সারিতে পরিবর্তন আনে বা পরে লেখবে এমন কাজ এনকিউ করে, তাহলে এটাকে লেখা ধরে নিন।
When should we switch to read-only mode?
যদি আপনি টাইমআউট, বাড়তে থাকা p95 লেটেন্সি, লক ওয়েট, কানেকশন পুল এক্সহাস্ট বা পুনরাবৃত্ত ধীর কুয়েরি দেখেন তবে চালু করুন। লেখাগুলো ছড়াতে শুরু করার আগেই অনা ভাল—রিট্রাই স্টর্ম শুরু হলে সমস্যা দ্রুত বড় হয়।
How do we implement read-only mode safely without missing some paths?
একটি গ্লোবাল টগল রাখুন এবং সার্ভার-সাইডে এটি জোর করে প্রয়োগ করুন, শুধু UI-তে না। UI Save বোতাম অক্ষম করুন, কিন্তু প্রতিটি লিখে যাওয়া এন্ডপয়েন্টও তাড়াতাড়ি ফিরিয়ে দেবে যাতে ডাটাবেসে পৌঁছানোই না হয়।
What should the UI say so users don’t panic or spam retries?
একটি স্থায়ী ব্যানার দেখান যা বলছে কি ঘটছে, কী কাজ করছে এবং কী স্থগিত আছে—সহজ ভাষায়। ব্লক করা অ্যাকশনগুলো স্পষ্টভাবে দেখান যাতে ব্যবহারকারীরা বারবার রিট্রাই না করে এবং আপনাকে "কিছু ভুল হয়েছে" টিকিটের ঢেউ না আসে।
How do we keep key reads working without making the load worse?
অনেক সময় কোর পেজগুলোই রাখা জরুরি এবং ভারী কুয়েরি দূর করুন: ক্যাশড সামারি ব্যবহার করুন, পেজ সাইজ ছোট রাখুন, নিরাপদ ডিফল্ট সোর্ট দিন, এবং একটু স্টেলে থাকা ডেটা অনুমোদন করুন যদি তা কোর পেজকে রেসপনসিভ রাখে।
What should we do about background jobs, webhooks, and integrations during read-only?
ব্যাকগ্রাউন্ড জব, সিঙ্ক, ইমপোর্ট এবং কিউ কনসিউমারগুলো যেগুলো লিখে—সেগুলো থামান বা থ্রটল করুন। ওয়েবহুক নিলে কিন্তু প্রসেস না করতে পারলে তা সঙ্গত নয়—বিবৃতি ফিরিয়ে দিন যাতে প্রেরক পরে রিট্রাই করে।
What are the most common read-only mode mistakes during incidents?
শুধু UI-তে বাটন নিষ্ক্রিয় করাই বড় ভুল—API, মোবাইল ক্লায়েন্ট এবং পুরনো ট্যাব থেকে লেখাগুলো চলতেই থাকবে। আরেকটি সাধারণ সমস্যা হল দ্রুত বারবার মোড বদলানো; read-only-তে গেলে একটি ন্যূনতম সময় রাখুন এবং মেট্রিক স্থির না হওয়া পর্যন্ত ফিরিয়ে না আনুন।
How do we avoid common mistakes?
একটি সার্ভার-সাইড সুইচ রাখুন যা একই উত্তর দেয় সব লিখে যাওয়া অনুরোধকে। একটি কুলডাউন যোগ করুন যাতে মোড বার বার বদলায় না। যদি কোনো লেখা পুরোপুরি সম্পন্ন না হয়, পুরো অপারেশন ব্যর্থ করুন এবং ব্যবহারকারীকে পরবর্তী কী করতে হবে তা বলুন—উদাহরণ: “Read-only mode: viewing works, changes are paused. Try again later.”