এরর বাজেট ও বার্ন-রেট অ্যালার্ট: সঠিক কারণে জাগানো

ব্যবহারকারীর অভিজ্ঞতা থেকে শুরু করুন

বেশিরভাগ গোলমেলে অ্যালার্ট আসে কারণের ওপর অ্যালার্ট দেওয়া থেকে — CPU, মেমরি, রিস্টার্ট হওয়া পড — ব্যবহারকারী কী অনুভব করছেন তার ওপর নয়। সার্ভিস-লেভেল ইন্ডিকেটর (SLI) সরাসরি এটি মাপে: বৈধ অনুরোধের মধ্যে কতগুলো ভালো ছিল। ভালো মানে হতে পারে সার্ভার এরর ছাড়া উত্তর, একটি সীমার চেয়ে দ্রুত উত্তর, বা দুটোই।

সার্ভিস-লেভেল অবজেক্টিভ (SLO) একটি সময়সীমায় এই অনুপাতের লক্ষ্য ঠিক করে, যেমন ৩০ দিনে ৯৯.৯% অনুরোধ সফল। ১০০%-এর সঙ্গে ব্যবধানটিই এরর বাজেট: এখানে ০.১% অনুরোধ, অর্থাৎ মাসে প্রায় ৪৩ মিনিটের সম্পূর্ণ আউটেজ।

কেন থ্রেশহোল্ড অ্যালার্ট ব্যর্থ হয়

“৫ মিনিট ধরে এরর হার ১%-এর বেশি” ধরনের অ্যালার্ট একই সঙ্গে খুব সংবেদনশীল ও খুব ধীর। এটি এমন এক মুহূর্তের স্পাইকে জাগায় যা বাজেটের সামান্য অংশ খরচ করেছে, অথচ ০.৫% এরর হারে কখনো বাজে না, যা চুপচাপ এক সপ্তাহে পুরো বাজেট শেষ করে দেয়।

বার্ন রেট এর সমাধান করে। এটি SLO-এর তুলনায় বাজেট খরচের গতি: বার্ন রেট ১ পুরো সময়সীমায় ঠিক বাজেটটুকু খরচ করে; বার্ন রেট ১৪.৪ ত্রিশ দিনের বাজেট দুই দিনের সামান্য বেশি সময়ে শেষ করে।

মাল্টি-উইন্ডো, মাল্টি-বার্ন-রেট অ্যালার্ট

Google-এর SRE Workbook-এ বর্ণিত পদ্ধতিতে প্রতিটি বার্ন-রেট থ্রেশহোল্ডকে একটি দীর্ঘ উইন্ডোর সঙ্গে জোড়া হয়, যা প্রমাণ করে সমস্যাটি গুরুতর, আর একটি ছোট উইন্ডোর সঙ্গে, যা প্রমাণ করে এটি এখনো চলছে। ৩০ দিনে ৯৯.৯% SLO-এর জন্য একটি প্রচলিত শুরুর বিন্দু:

• জাগান: ১ ঘণ্টা ও ৫ মিনিট — দুটোতেই বার্ন রেট ১৪.৪-এর বেশি — এক ঘণ্টায় বাজেটের ২% খরচ।
• জাগান: ৬ ঘণ্টা ও ৩০ মিনিট — দুটোতেই বার্ন রেট ৬-এর বেশি — বাজেটের ৫% খরচ।
• টিকিট: ৩ দিন ও ৬ ঘণ্টা — দুটোতেই বার্ন রেট ১-এর বেশি — বাজেটের ১০% খরচ।

# Fast-burn page for a 99.9% availability SLO (error budget = 0.001)
(
  sum(rate(http_requests_total{job="api", code=~"5.."}[1h]))
    / sum(rate(http_requests_total{job="api"}[1h]))
) > (14.4 * 0.001)
and
(
  sum(rate(http_requests_total{job="api", code=~"5.."}[5m]))
    / sum(rate(http_requests_total{job="api"}[5m]))
) > (14.4 * 0.001)

ছোট উইন্ডোটি দীর্ঘটির মতোই গুরুত্বপূর্ণ: ফিক্স কার্যকর হলেই ৫ মিনিটের অনুপাত নেমে যায় এবং অ্যালার্ট বাকি ঘণ্টা বাজতে না থেকে থেমে যায়।

যে খুঁটিনাটি ঠিক করে এটি কাজ করবে কি না

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

বাজেট কীসের জন্য

বাজেট সিদ্ধান্তের হাতিয়ার, শুধু পেজার নয়। যতক্ষণ এটি সুস্থ, টিম দ্রুত রিলিজ করতে ও বেশি ঝুঁকির পরিবর্তন নিতে পারে। এটি শেষ হলে প্রবণতা না সারা পর্যন্ত নির্ভরযোগ্যতার কাজ ফিচারের আগে যায়। প্রথম লঙ্ঘনের আগেই, তার মধ্যে নয়, প্রোডাক্টের দায়িত্বপ্রাপ্তদের সঙ্গে এই নীতিতে একমত হোন।