মিশন-ক্রিটিক্যাল ডেটাবেজ কেন রাত ৩টায় ব্যর্থ হয় — এবং কীভাবে এমন একটি তৈরি করবেন যা হয় না

আপনার ডেটাবেজ অফিস সময়ে ব্যর্থ হয় না, যখন একঘর ভর্তি ইঞ্জিনিয়ার ড্যাশবোর্ড দেখছেন। এটি ব্যর্থ হয় রাত ৩টায় — একটি লম্বা ছুটির দিনে, ব্যাকআপের মাঝপথে, এমন একটি ব্যাচ জব চলাকালীন যা কেউ ডকুমেন্ট করেনি, যখন সিস্টেমটি বোঝেন এমন একজনই মানুষ ঘুমিয়ে আছেন এবং তাঁকে পাওয়া যাচ্ছে না। ব্যাংক, ফার্মাসিউটিক্যাল কোম্পানি, টেলিকম ও সরকারি সিস্টেমের জন্য ১৮+ বছর প্রোডাকশন Oracle চালিয়ে আমি শিখেছি যে একটি সিস্টেম "চালু" আর একটি সিস্টেম "নিরাপদ" — এর মধ্যে পার্থক্য প্রায় কখনওই হার্ডওয়্যার বা লাইসেন্স টিয়ার নয়। এটি সেই নিরস, চাকচিক্যহীন ইঞ্জিনিয়ারিং যা বাজেট টানাটানিতে সবার আগে কাটা পড়ে: টেস্টেড রিকভারি, বাস্তব মনিটরিং এবং এমন high availability যা আসলেই ডিজাইন করা হয়েছিল — ধরে নেওয়া নয়।

যে সংখ্যাটি কেউ হিসাব করতে চায় না

অধিকাংশ প্রতিষ্ঠান কখনও এক ঘণ্টা ডাউনটাইমের বাস্তব একটি অঙ্ক বসায়নি — আর এই একটিমাত্র অনুপস্থিত সংখ্যাই কারণ কেন নির্ভরযোগ্যতা কম বাজেট পায়।

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

টিকে থাকা ডেটাবেজের তিনটি স্তম্ভ

একটি সত্যিকারের স্থিতিস্থাপক সিস্টেম তিনটি স্তম্ভের ওপর দাঁড়ায়। যেকোনো একটিতে দুর্বলতা পুরোটাকে নামিয়ে ফেলে — আর আমাকে যেসব ব্যর্থতা ঠিক করতে ডাকা হয় তার অধিকাংশই একটি দুর্বল স্তম্ভ যাকে সবাই ধরে নিয়েছিল শক্তিশালী।

স্তম্ভ ১ — High Availability: যে ব্যর্থতা আপনি আসতে দেখেননি তা টিকিয়ে থাকা

High availability হলো একটি কম্পোনেন্ট মারা গেলে — একটি নোড, একটি ডিস্ক, একটি নেটওয়ার্ক পথ — অনলাইন থাকা। Oracle-এর জন্য গোল্ড স্ট্যান্ডার্ড এখনও Real Application Clusters (RAC): একই ডেটাবেজ চালানো একাধিক সার্ভার, যাতে একটি নোড হারালে সেবা নেমে না যায়। কিন্তু RAC যা নয় এবং যেখানে আমি সবচেয়ে ব্যয়বহুল ভুল দেখি তা এখানে:

• RAC কোনো ব্যাকআপ নয়। এটি হার্ডওয়্যার ও ইনস্ট্যান্স ব্যর্থতা থেকে রক্ষা করে — একটি ড্রপ করা টেবিল, প্রতিটি নোডে তাৎক্ষণিকভাবে রেপ্লিকেটেড একটি করাপ্ট ব্লক, বা একটি খারাপ ডিপ্লয়মেন্ট থেকে নয়। একটি ভুলকে ক্লাস্টার করা কেবল ভুলটাকে highly available করে তোলে।
• RAC "সেট করে ভুলে যাওয়ার" জিনিস নয়। Interconnect ভুল কনফিগারেশন, অসম সার্ভিস প্লেসমেন্ট এবং অটেস্টেড failover-ই কারণ কেন ক্লাস্টার ঠিক সেই ঘটনার সময়ই ব্যর্থ হয় যা টিকিয়ে থাকতে সেটি কেনা হয়েছিল।
• খারাপভাবে করা RAC কোনো RAC না থাকার চেয়ে খারাপ — বেশি নড়াচড়া করা অংশ, ব্যর্থ হওয়ার বেশি উপায় এবং নিরাপত্তার একটি মিথ্যা অনুভূতি।

ঠিকভাবে করলে, RAC-এর সাথে সঠিক সার্ভিস ও কানেকশন ম্যানেজমেন্ট মানে একটি নোড উধাও হয়ে যেতে পারে আর আপনার ব্যবহারকারীরা প্রায় টেরই পান না। এটাই লক্ষ্য: ব্যর্থতা একটি non-event হিসেবে।

স্তম্ভ ২ — Disaster Recovery: যে পরিকল্পনা আপনি আশা করেন কখনও চালাতে হবে না

High availability ব্যর্থ কম্পোনেন্ট সামলায়। Disaster recovery ব্যর্থ সাইট সামলায় — আগুন, বন্যা, র‍্যানসমওয়্যার, একটি অঞ্চল অফলাইন, বা মানুষের ভুল যা আপনার প্রাইমারি করাপ্ট করে। দুটি সংখ্যা আপনার কৌশল নির্ধারণ করে, আর প্রতিটি ব্যবসার নিজেরটা জানা উচিত:

• RPO (Recovery Point Objective): আপনি কতটা ডেটা হারানো সহ্য করতে পারেন? সেকেন্ড? এক ঘণ্টা? এক দিন?
• RTO (Recovery Time Objective): ক্ষতি অগ্রহণযোগ্য হওয়ার আগে আপনি কতক্ষণ ডাউন থাকতে পারেন?

Oracle-এর জন্য Data Guard একটি সিঙ্ক্রোনাইজড স্ট্যান্ডবাই ডেটাবেজ রক্ষণাবেক্ষণ করে — প্রায়ই অন্য একটি সাইটে — দায়িত্ব নিতে প্রস্তুত। একটি সুশৃঙ্খল ব্যাকআপ কৌশলের (RMAN, ভ্যালিডেটেড, অফ-সাইট, এনক্রিপ্টেড) সাথে মিলিয়ে এটি "যদি আমরা সব হারাই" প্রশ্নের একটি বাস্তব উত্তর দেয়। কিন্তু এই পুরো গাইডের সবচেয়ে গুরুত্বপূর্ণ বাক্যটি হলো:

যে ব্যাকআপ আপনি কখনও রিস্টোর করেননি তা কোনো ব্যাকআপ নয়। এটি একটি আশা।

আমি বহু প্রতিষ্ঠানে ঢুকেছি যেখানে প্রতি রাতে একটি সবুজ "backup successful" আলো জ্বলে — অথচ এমন একটি ব্যাকআপ যা যখন সত্যিই দরকার তখন আসলে রিস্টোর করা যায়নি: হারানো archive log, একটি অটেস্টেড প্রক্রিয়া, এমন একটি টেপ যা কেউ পড়তে পারেনি। একমাত্র যে ব্যাকআপটি গোনায় ধরা হয় তা হলো যেটি থেকে আপনি প্রমাণ করেছেন যে পুনরুদ্ধার করতে পারেন, একটি শিডিউলে, একটি ড্রিল হিসেবে। এই ত্রৈমাসিকে আর কিছু টেস্ট না করলেও, আপনার রিস্টোর টেস্ট করুন।

স্তম্ভ ৩ — Performance: যে ব্যর্থতা ধীরে ধীরে আসে

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

পারফরম্যান্স একটি নির্ভরযোগ্যতার সমস্যা, কারণ ব্যবহার করার পক্ষে খুব ধীর একটি সিস্টেম ব্যবসার জন্য ডাউন-ই। কারণগুলো খুব কমই রহস্যময়: অনুপস্থিত বা ভুল ইনডেক্স, ডেটা প্রবৃদ্ধির সাথে তাল না রাখা statistics, unbounded কোয়েরি, contention এবং এমন একটি ডেটা ভলিউম যা দ্বিগুণ হয়েছে অথচ ডিজাইন স্থির থেকে গেছে। সমাধান হলো পদ্ধতিগত ডায়াগনসিস — অনুমান নয়, বরং আসল execution plan ও wait event পড়া — এবং এমন ক্যাপাসিটি প্ল্যানিং যা ধরে নেয় আপনার ডেটা বাড়বেই, কারণ বাড়বে।

যে স্তম্ভ সবাই ভুলে যায়: হিউম্যান লেয়ার

আপনি প্রতিটি লাইসেন্স ও প্রতিটি সার্ভার কিনতে পারেন, তবু একটি কীস্ট্রোক দূরত্বে বিপর্যয়ের কাছে থাকতে পারেন — কারণ যাকে কেউ সত্যিকারভাবে বোঝে না এমন স্থিতিস্থাপক প্রযুক্তি ভঙ্গুর। আপনি একটি সত্যিকার ইনসিডেন্ট টিকিয়ে থাকবেন কিনা তা যে প্রশ্নগুলো নির্ধারণ করে সেগুলো মানবিক। যখন প্রাইমারি রাত ৩টায় ব্যর্থ হয়, কেউ কি জানে — তাৎক্ষণিকভাবে, স্বয়ংক্রিয়ভাবে — নাকি আপনি সকাল ৯টায় রাগান্বিত গ্রাহকদের কাছ থেকে জানেন? একটি ডকুমেন্টেড, অনুশীলিত runbook আছে, নাকি আপনি সর্বোচ্চ চাপের মধ্যে বানিয়ে বানিয়ে চলবেন? আপনার পুনরুদ্ধার কি একজন অপরিবর্তনীয় মানুষের ওপর নির্ভর করে যিনি ছুটিতে থাকতে পারেন, নাগালের বাইরে থাকতে পারেন, বা চলে গেছেন?

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

নির্ভরযোগ্য ডেটা থেকে ভালো সিদ্ধান্ত

নির্ভরযোগ্যতা ভিত্তি — কিন্তু সেই একই সুপরিচালিত ডেটাবেজ আপনার সবচেয়ে কম-ব্যবহৃত কৌশলগত সম্পদও। আধুনিক সুযোগটি হলো সেই বিশ্বাসযোগ্য অপারেশনাল ডেটাকে সিদ্ধান্তে রূপান্তর করা: ERP ইন্টিগ্রেশন যা আপনার সিস্টেমগুলোকে ম্যানুয়াল রি-কিয়িং-এ বাধ্য না করে সংযুক্ত করে, এবং AI যা আপনার টিমকে সাধারণ ভাষায় নিজেদের ডেটা নিয়ে প্রশ্ন করতে ও সেকেন্ডে উত্তর পেতে দেয়।

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

একটি নির্ভরযোগ্যতা ম্যাচুরিটি যাচাই

একটি দ্রুত, সৎ স্ব-মূল্যায়ন। প্রতিটির জন্য জিজ্ঞেস করুন "আমাদের কি এটি আছে?" নয়, বরং "আমরা কি এটি প্রমাণ করেছি?"

• Single points of failure — কোনো একটি সার্ভার, ডিস্ক বা মানুষ কি ব্যবসা নামিয়ে ফেলতে পারে? (যদি হ্যাঁ, সেটাই আপনার শীর্ষ অগ্রাধিকার।)
• টেস্টেড রিকভারি — গত ৯০ দিনে আপনি কি ব্যাকআপ থেকে end to end রিস্টোর করেছেন?
• RPO / RTO সংজ্ঞায়িত — আপনি কি আপনার লক্ষ্য জানেন, এবং আপনার আর্কিটেকচার কি আসলেই তা পূরণ করে?
• বাস্তব মনিটরিং — আপনার গ্রাহকদের আগে আপনি কি একটি ব্যর্থতা সম্পর্কে জানবেন?
• ডকুমেন্টেড ও মহড়া-দেওয়া runbook — আপনার সবচেয়ে সিনিয়র ব্যক্তি ছাড়া অন্য কেউ কি একটি পুনরুদ্ধার চালাতে পারবেন?
• পারফরম্যান্স হেডরুম — সিস্টেমটি কি দুই বছর আগের নয়, বরং দুই বছর পরে আপনার যে ডেটা ভলিউম থাকবে তার জন্য ডিজাইন করা?
• প্যাচ ও সিকিউরিটি অবস্থা — আপনি কি হালনাগাদ, নাকি নীরবে উন্মুক্ত?

অধিকাংশ প্রতিষ্ঠান যেসব কম্পোনেন্ট তারা কিনেছে সেগুলোতে ভালো স্কোর করে আর যেগুলো তাদের অনুশীলন করতে হতো সেগুলোতে খারাপ। সেই ফাঁকটাই ঠিক যেখানে রাত ৩টা বাস করে।

মূল কথা

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

CoreStack-এ, সেই নিরস, বুলেটপ্রুফ স্তরটিই হলো কাজ: আপনার বাস্তব failure mode-এর জন্য ডিজাইন করা Oracle RAC ও high availability, আপনি আসলেই প্রমাণ করেছেন এমন ডিজাস্টার রিকভারি, বাড়ার সাথে টিকে থাকা পারফরম্যান্স এবং ERP ও AI ইন্টিগ্রেশন যা নির্ভরযোগ্য ডেটাকে সিদ্ধান্তে রূপান্তর করে — সেইসব নিয়ন্ত্রিত, ডেটা-সংবেদনশীল এন্টারপ্রাইজের জন্য ইঞ্জিনিয়ার করা যেখানে ডাউনটাইম কোনো অসুবিধা নয়, এটি একটি সংকট। এটি তৈরির সেরা সময় ছিল রাত ৩টার কলের আগে। দ্বিতীয় সেরা সময় এখন।