কেস স্টাডি: মাল্টি-ক্লাউড ডিজাস্টার রিকভারি স্ট্র্যাটেজি

১ · কনটেক্সট — সমস্যা

একটি কোম্পানির সম্পূর্ণ প্রোডাকশন সিস্টেম বর্তমানে একটি মাত্র ক্লাউড প্রোভাইডারে চলে। প্রশ্ন: যদি সেই প্রোভাইডারের একটি পুরো রিজন — বা পুরো প্রোভাইডারই — কোনো বড় আউটেজে পড়ে (বিরল কিন্তু বাস্তবে ঘটে থাকা ঘটনা), তাহলে কী হবে? লক্ষ্য: এমন একটি DR স্ট্র্যাটেজি ডিজাইন করা যাতে একটি প্রোভাইডারের সম্পূর্ণ ব্যর্থতাতেও সার্ভিস (হয়তো কমে যাওয়া ক্যাপাসিটিতে হলেও) চালু থাকে।

২ · অ্যাপ্রোচ — কোন পাঠের কৌশল কোথায় প্রয়োগ হলো

প্রথমে ক্রিটিক্যাল ডেটা একাধিক প্রোভাইডার/রিজন জুড়ে রেপ্লিকেট করা হয়, একটি নির্দিষ্ট RPO/RTO লক্ষ্য অনুযায়ী (M3/L12 — কত ঘণ্টার ডেটা হারানো গ্রহণযোগ্য, কত দ্রুত পুরোপুরি সুস্থ হতে হবে তা স্ন্যাপশট ফ্রিকোয়েন্সি ঠিক করে)। ওয়ার্কলোড দুই প্রোভাইডারেই ডিপ্লয়যোগ্য রাখা হয় পোর্টেবল টেকনোলজি চয়েস ব্যবহার করে (M12/L52-এর পোর্টেবিলিটি নীতি — কন্টেইনার, Kubernetes, Terraform)। ট্রাফিক ফেইলওভার হয় হেলথ-চেক-ভিত্তিক DNS রাউটিং দিয়ে (M4/L15) — প্রাইমারি প্রোভাইডার আনহেলদি হলে স্বয়ংক্রিয়ভাবে সেকেন্ডারিতে ট্রাফিক পাঠানো হয়, কোনো ম্যানুয়াল হস্তক্ষেপ ছাড়াই। সবশেষে — এবং প্রায়ই উপেক্ষিত সবচেয়ে গুরুত্বপূর্ণ ধাপ — এই পুরো ফেইলওভার প্রক্রিয়া নিয়মিত সময়ান্তরে বাস্তবে পরীক্ষা করা হয় (একটি "গেম ডে" চালিয়ে ইচ্ছাকৃতভাবে প্রাইমারিকে অফলাইন করে দেখা হয় ফেইলওভার আসলেই কাজ করে কিনা)।

৩ · মূল ট্রেড-অফ — অ্যাক্টিভ-অ্যাক্টিভ বনাম অ্যাক্টিভ-প্যাসিভ

৪ · কোড — হেলথ-চেক-ভিত্তিক ফেইলওভার সিলেক্টর

# প্রতিটি প্রোভাইডারের সিমুলেটেড হেলথ-চেক স্ট্যাটাস
provider_health = {
    "provider_a_primary":   "healthy",
    "provider_b_secondary": "healthy",
}

preferred_order = ["provider_a_primary", "provider_b_secondary"]

def select_active_provider(providers, order):
    for name in order:
        if providers.get(name) == "healthy":
            return name
    return None   # কোনো প্রোভাইডারই healthy নয় — সম্পূর্ণ আউটেজ

# --- স্বাভাবিক অবস্থা ---
active = select_active_provider(provider_health, preferred_order)
print(f"স্বাভাবিক অবস্থা              -> সক্রিয় প্রোভাইডার: {active}")

# --- সিমুলেটেড প্রাইমারি আউটেজ ---
provider_health["provider_a_primary"] = "unhealthy"
active_after_outage = select_active_provider(provider_health, preferred_order)
print(f"প্রাইমারি আউটেজের পর           -> সক্রিয় প্রোভাইডার: {active_after_outage}")

# --- সিমুলেটেড উভয় প্রোভাইডার ডাউন (worst case) ---
provider_health["provider_b_secondary"] = "unhealthy"
active_full_outage = select_active_provider(provider_health, preferred_order)
print(f"উভয় প্রোভাইডার ডাউনের পর        -> সক্রিয় প্রোভাইডার: {active_full_outage}")

৫ · ফলাফল

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