অ্যালার্টিং ও অন-কল/SRE প্র্যাকটিস

১ · অ্যালার্ট ফেটিগ — সবচেয়ে বড় ব্যর্থতার কারণ

অ্যালার্টিংAlertingএকটি মেট্রিক্স (L41) কোনো থ্রেশহোল্ড ছাড়ালে স্বয়ংক্রিয়ভাবে একজন মানুষকে জানানোর প্র্যাকটিস, যাতে সমস্যা মানুষ নিজে খুঁজে বের করার আগেই জানা যায়। শোনায় সহজ — একটি থ্রেশহোল্ড ঠিক করুন, ছাড়ালেই নোটিফাই করুন। কিন্তু বাস্তবে সবচেয়ে বড় ঝুঁকি হলো অ্যালার্ট ফেটিগAlert Fatigueঅতিরিক্ত নয়েজি বা নন-একশনেবল অ্যালার্টের কারণে মানুষ ধীরে ধীরে অ্যালার্ট উপেক্ষা করতে শুরু করে — এমনকি সত্যিকারের ইনসিডেন্টের সময়ও। — যদি একটি সিস্টেম দিনে শতবার নন-একশনেবল অ্যালার্ট পাঠায়, অন-কল ইঞ্জিনিয়াররা ধীরে ধীরে সেগুলো মিউট/উপেক্ষা করতে শুরু করেন, এমনকি যখন একটি সত্যিকারের গুরুতর ইনসিডেন্ট আসে তখনও। এটি সিকিউরিটি কোর্সের সোশ্যাল-ইঞ্জিনিয়ারিং-প্রতিরোধ প্রশিক্ষণের একই সমস্যার প্রতিফলন — অতিরিক্ত সতর্কবার্তা মানুষকে অসাড় করে তোলে।

২ · ভালো অ্যালার্টের বৈশিষ্ট্য

একটি ভালো অ্যালার্ট দুটি শর্ত পূরণ করে — এটি একশনেবল (অন-কল ইঞ্জিনিয়ারকে বলে ঠিক কী চেক/করণীয়, শুধু "কিছু একটা ভুল" নয়) এবং এটি সত্যিকারের ইউজার-ফেসিং প্রভাব নির্দেশ করে (যেমন এলিভেটেড এরর রেট বা লেটেন্সি — উপসর্গ) — নিছক কোনো রিসোর্স মেট্রিক্স (যেমন CPU ৯০%) কোনো নির্দিষ্ট নির্বিচারে থ্রেশহোল্ড ছাড়ালেই নয়, যদি না তা সত্যিই ইউজারকে প্রভাবিত করছে।

৩ · কনসেকিউটিভ ব্রিচ — নয়েজ কমানোর মূল কৌশল

একটি মেট্রিক্স মাঝে মাঝে একটি একক টিকে সংক্ষিপ্তভাবে থ্রেশহোল্ড ছাড়িয়ে যেতে পারে (একটি ক্ষণস্থায়ী নেটওয়ার্ক গ্লিচ, একটি সাময়িক GC পজ) — এটি প্রায়ই স্বতঃসংশোধনশীল এবং সত্যিকারের ইনসিডেন্ট নয়। যদি অ্যালার্টিং লজিক প্রতিটি একক ব্রিচে সাথে সাথে ফায়ার করে, এটি প্রচুর নয়েজি, নন-একশনেবল অ্যালার্ট তৈরি করবে। সমাধান — শুধুমাত্র থ্রেশহোল্ড পরপর কয়েকটি চেকে (কনসেকিউটিভ ব্রিচ) ছাড়ালেই অ্যালার্ট ফায়ার করা, একটি একক স্পাইকে নয়।

# অ্যালার্ট-ইভ্যালুয়েশন — শুধুমাত্র পরপর কয়েকটি ব্রিচ হলেই অ্যালার্ট ফায়ার করে, একক স্পাইকে নয়
def evaluate_alerts(metric_name, readings, threshold, min_consecutive=3):
    """
    readings-এর প্রতিটি টিকে থ্রেশহোল্ড ব্রিচ হয়েছে কিনা চেক করে, কনসেকিউটিভ ব্রিচ কাউন্ট রাখে।
    consecutive_breaches >= min_consecutive হলেই কেবল অ্যালার্ট True হয় — একটি একক ক্ষণস্থায়ী
    স্পাইক কখনোই অ্যালার্ট ট্রিগার করবে না, কারণ পরের রিডিং স্বাভাবিক হলেই কাউন্ট রিসেট হয়ে যায়।
    """
    results = []
    consecutive = 0
    for tick, value in enumerate(readings):
        if value > threshold:
            consecutive += 1
        else:
            consecutive = 0
        alert = consecutive >= min_consecutive
        results.append({"tick": tick, "value": value, "consecutive": consecutive, "alert": alert})
    return results

def report(title, results):
    print(f"\n--- {title} ---")
    print(f"{'টিক':>4}{'মান':>7}{'পরপর ব্রিচ':>12}{'অ্যালার্ট':>10}")
    fired = False
    for r in results:
        flag = "FIRE" if r["alert"] else "—"
        if r["alert"]:
            fired = True
        print(f"{r['tick']:>4}{r['value']:>7}{r['consecutive']:>12}{flag:>10}")
    print(f"সিদ্ধান্ত: {'অ্যালার্ট ট্রিগার হয়েছে' if fired else 'কোনো অ্যালার্ট ট্রিগার হয়নি'}")
    return fired

threshold = 80  # ইলাস্ট্রেটিভ error-rate/latency থ্রেশহোল্ড

# দৃশ্যকল্প ১ · ক্ষণস্থায়ী স্পাইক — এক টিকের জন্য থ্রেশহোল্ড ছাড়ায়, তারপর স্বাভাবিক
transient = [45, 48, 92, 50, 47, 46, 49]
transient_fired = report("দৃশ্যকল্প ১ · ক্ষণস্থায়ী স্পাইক", evaluate_alerts("error_rate_pct", transient, threshold))
assert transient_fired is False, "ক্ষণস্থায়ী স্পাইকে অ্যালার্ট ট্রিগার হওয়ার কথা নয়!"

# দৃশ্যকল্প ২ · স্থায়ী ব্রিচ — পরপর কয়েক টিক ধরে থ্রেশহোল্ডের উপরে থাকে
sustained = [45, 48, 85, 88, 91, 90, 47]
sustained_fired = report("দৃশ্যকল্প ২ · স্থায়ী ব্রিচ", evaluate_alerts("error_rate_pct", sustained, threshold))
assert sustained_fired is True, "স্থায়ী ব্রিচে অ্যালার্ট ট্রিগার হওয়ার কথা ছিল!"

print("\nনিশ্চিত হলো: শুধু পরপর কয়েকবার ব্রিচ হলেই অ্যালার্ট ফায়ার করে, একটিমাত্র স্পাইকে নয়।")

৪ · অন-কল রোটেশন ও SRE-এর এরর বাজেট

অন-কল রোটেশন — ব্যবসায়িক সময়ের বাইরেও অ্যালার্টের জবাব দেওয়ার জন্য দায়িত্বপ্রাপ্ত ইঞ্জিনিয়ারদের একটি নির্ধারিত রোস্টার। SRE (Site Reliability Engineering) প্র্যাকটিস এটিকে সরাসরি এরর বাজেটের সাথে যুক্ত করে — একটি এরর বাজেট ঠিক করে কতটা অনির্ভরযোগ্যতা গ্রহণযোগ্য (যেমন মাসে ০.১% ডাউনটাইম), এবং অ্যালার্টিং-এর লক্ষ্য হলো সেই বাজেট-হুমকিদায়ক সমস্যাগুলো যথেষ্ট আগে ধরা, যাতে সংশোধনের সময় থাকে — প্রতিটি ছোট গ্লিচে কাউকে জাগানো নয়, শুধু যা সত্যিই বাজেট বিপন্ন করছে তাতেই।