কীভাবে একটা ওয়েব অ্যাপ ডিজাইন ও বানাবেন যা SLA অনুপালন ট্র্যাক করে: মেট্রিক সংজ্ঞায়িত করা, ইভেন্ট সংগ্রহ করা, ফলাফল গণনা, ব্রিচে সতর্ক করে এবং সঠিকভাবে রিপোর্ট করা।
SLA অনুপালন মানে হলো Service Level Agreement (SLA)-তে নির্দিষ্ট পরিমাপযোগ্য প্রতিশ্রুতি পূরণ করা—একটি প্রদানকারী এবং গ্রাহকের মধ্যে চুক্তি। আপনার অ্যাপের কাজ হলো প্রমাণ সহ একটি সহজ প্রশ্নের উত্তর দেওয়া: এই গ্রাহকের জন্য, এই সময়কালে আমরা কী প্রতিশ্রুতি পূরণ করেছি?
তিনটি সংক্রান্ত টার্ম আলাদা করে দেখা ভালো:
অধিকাংশ SLA ট্র্যাকিং ওয়েব অ্যাপ ছোট সেট দিয়ে শুরু করে যা বাস্তব অপারেশনাল ডেটার সাথে মানানসই:
বিভিন্ন ব্যবহারকারীরা একই সত্য চান, কিন্তু ভিন্নভাবে প্রদর্শিত:
এই প্রোডাক্টটি ট্র্যাকিং, প্রমাণ, এবং রিপোর্টিং সম্পর্কিত: সিগন্যাল সংগ্রহ করা, সম্মত নিয়ম প্রয়োগ করা, এবং অডিট-ফ্রেন্ডলি ফলাফল জেনারেট করা। এটা পারফর্ম্যান্স গ্যারান্টি দেয় না; এটি সেটাকে পরিমাপ করে—সঠিকভাবে, ধারাবাহিকভাবে, এবং এমনভাবে যাতে পরে আপনার পক্ষে তা যুক্তি করা যায়।
টেবিল ডিজাইন বা কোড লেখার আগে, ব্যবসায় আপনার কাছে "অনুপালন" কী বলতে চায় সেটা ব্যাথা করে পরিষ্কার করুন। বেশিরভাগ SLA ট্র্যাকিং সমস্যা প্রযুক্তিগত নয়—ওগুলো প্রয়োজনীয়তার সমস্যা।
সূত্রগুলো সংগ্রহ করে শুরু করুন:
এগুলো স্পষ্ট নিয়ম হিসাবে লিখে রাখুন। যদি কোনো নিয়ম স্পষ্টভাবে বলা না যায়, তা নির্ভরযোগ্যভাবে গণনা করা যাবেনা।
সেই বাস্তব জিনিসগুলো তালিকাভুক্ত করুন যা SLA সংখ্যাকে প্রভাবিত করতে পারে:
এছাড়াও নির্ধারণ করুন কে কী চায়: সাপোর্ট রিয়েল-টাইম ব্রিচ রিস্ক চান; ম্যানেজাররা সাপ্তাহিক রোলআপ চান; গ্রাহকরা সরল সারসংক্ষেপ চান (প্রায়ই স্ট্যাটাস পেজের জন্য)।
স্কোপ ছোট রাখুন। ন্যূনতম সেট বেছে নিন যা সিস্টেমকে end-to-end প্রমাণ করবে, যেমন:
এক পৃষ্ঠার চেকলিস্ট তৈরি করুন যা পরে পরীক্ষা করা যাবে:
সাফল্য দেখতে হবে এভাবে: দুই জন ব্যক্তি একই নমুনা মাস ম্যানুয়ালি গণনা করলে আপনার অ্যাপটি একেবারেই মিলে যায়।
একটি সঠিক SLA ট্র্যাকার এমন একটি ডেটা মডেল দিয়ে শুরু করা উচিত যা ব্যাখ্যা করতে পারে কেন একটি সংখ্যা এমন আছে। যদি আপনি একটি মাসিক অ্যাভেলিবিলিটি সংখ্যাকে সঠিক ইভেন্ট এবং প্রয়োগ করা নিয়মের সাথে ঘটনার ট্রেস ব্যাক করতে না পারেন, আপনি গ্রাহক বিরোধ ও অভ্যন্তরীণ অনিশ্চয়তার মুখোমুখি হবেন।
ন্যূনতম মডেল করুন:
একটি দরকারী সম্পর্ক: customer → service → SLA policy (সম্ভবত plan-র মাধ্যমে)। ইনসিডেন্ট ও ইভেন্টগুলো তারপর সার্ভিস ও গ্রাহককে রেফার করবে।
টাইম-বাগ হচ্ছে SLA গণনার #1 কারণ। সংরক্ষণ করুন:
occurred_at হিসাবে UTC (টাইমজোন সেমান্টিক্স সহ)received_at (যখন আপনার সিস্টেম এটিকে দেখেছে)source (মনিটর নাম, ইন্টিগ্রেশন, ম্যানুয়াল)external_id (রিট্রাই ডিডুপ করার জন্য)payload (ভবিষ্যৎ ডিবাগিংয়ের জন্য র' JSON)এছাড়াও customer.timezone (IANA স্ট্রিং যেমন America/New_York) প্রদর্শন ও ব্যবসায়িক ঘণ্টার লজিকের জন্য রাখুন, কিন্তু ইভেন্ট টাইম পুনর্লিখতে ব্যবহার করবেন না।
যদি রেসপন্স-টাইম SLA ব্যবসায়িক ঘণ্টার বাইরে থেমে যায়, ক্যালেন্ডারগুলিকে স্পষ্টভাবে মডেল করুন:
working_hours প্রতি গ্রাহক (বা প্রতি রিজিওন/সার্ভিস): সপ্তাহের দিন + শুরু/শেষ সময়holiday_calendar রিজিওন বা গ্রাহকের সাথে লিঙ্ক, তারিখ-রেঞ্জ ও লেবেলসহনিয়মগুলো ডেটা-ড্রিভেন রাখুন যাতে অপস অপসেপ ছাড়া ছুটি আপডেট করা যায়।
কাঁচা ইভেন্টগুলো একটি অ্যাপেন্ড-অনলি টেবিলে সংরক্ষণ করুন, এবং হিসাব করা ফলাফল আলাদা রাখুন (যেমন sla_period_result)। প্রতিটি রেজাল্ট রোতে থাকা উচিত: পিরিয়ড বাউন্ডারি, ইনপুট ভার্সন (পলিসি ভার্সন + ইঞ্জিন ভার্সন), এবং ব্যবহৃত ইভেন্ট আইডি রেফারেন্স। এটি পুনরায় গণনা নিরাপদ করে এবং গ্রাহকের প্রশ্নে আপনি বলতে পারবেন, “আপনি কোন আউটেজ মিনিটগুলো গণ্য করেছেন?”
আপনার SLA সংখ্যা যতটা বিশ্বাসযোগ্য তা ইনজেস্ট করা ইভেন্টের মান দ্বারা নির্ধারিত। লক্ষ্য সহজ: প্রতিটি গুরুত্বপূর্ণ পরিবর্তন (আউটেজ শুরু, ইনসিডেন্ট স্বীকৃতি, সার্ভিস রিস্টোর) ক্যাপচার করা, ধারাবাহিক টাইমস্ট্যাম্প এবং গণনার জন্য যথেষ্ট প্রেক্ষাপট নিয়ে।
বেশিরভাগ দল মিশ্র সিস্টেম থেকে টেনে আনে:
Webhooks সাধারণত রিয়েল-টাইম সঠিকতার জন্য এবং কম লোডের জন্য ভাল: সোর্স সিস্টেম আপনার এন্ডপয়েন্টে ইভেন্ট পুশ করে।
পোলিং তখন ভাল যখন ওয়েবহুক না থাকে: আপনার অ্যাপ নির্দিষ্ট পবিত্রতার পরে পরিবর্তনগুলো ফেচ করে। রেট-লিমিট হ্যান্ডলিং ও কেয়ারফুল “since” লজিক দরকার।
CSV ইমপোর্ট ব্যাকফিল এবং মাইগ্রেশনের জন্য সহায়ক। এটিকে প্রথম শ্রেণির ইনজেশন পাথ হিসেবে বিবেচনা করুন যাতে ঐতিহাসিক পিরিয়ড পুনরায় প্রসেস করা যায়।
সবকিছু একটি একক অভ্যন্তরীণ "ইভেন্ট" শেপে নরমালাইজ করুন:
event_id (প্রয়োজনীয়): রিট্রাইয়ে স্থায়ী ও ইউনিক। সোর্সের GUID পছন্দযোগ্য; নতুবা ডিটারমিনিস্টিক হ্যাশ জেনারেট করুন।source (প্রয়োজনীয়): যেমন datadog, servicenow, manual।event_type (প্রয়োজনীয়): যেমন incident_opened, incident_acknowledged, service_down, service_up।occurred_at (প্রয়োজনীয়): ইভেন্ট ঘটার সময় (যা আপনি দেখেছেন তা নয়), টাইমজোন সহ।received_at (সিস্টেম): কখন আপনার অ্যাপ এটি ইনজেস্ট করেছে।service_id (প্রয়োজনীয়): যে SLA-র প্রাসঙ্গিক সার্ভিস ইভেন্টটি প্রভাবিত করে।incident_id (ঐচ্ছিক কিন্তু সুপারিশকৃত): একাধিক ইভেন্টকে একটি ইনসিডেন্টে লিংক করে।attributes (ঐচ্ছিক): প্রায়োরিটি, রিজিওন, গ্রাহক সেগমেন্ট ইত্যাদি।ইভেন্ট-আইডিতে ইউনিক কনস্ট্রেইন্ট রাখুন যাতে ইনজেশন আইডেম্পোটেন্ট হয়: রিট্রাই ডুপ্লিকেট তৈরি করবে না।
এইসব ইভেন্ট ফিরিয়ে দিন বা কয়ারেন্টিন করুন যদি:
occurred_at ভবিষ্যতে অনেক দূরে থাকে।service_id-এর সাথে ম্যাপ না করে (অথবা একটি স্পষ্ট “unmapped” ওয়ার্কফ্লো দাবি করে)।event_id-এর ডুপ্লিকেট হয়।এই শৃঙ্খলা আপনাকে রিপোর্ট নিয়ে বিতর্ক থেকে রক্ষা করবে—কারণ আপনি পরিষ্কার, ট্রেসযোগ্য ইনপুট দেখাতে পারবেন।
আপনার ক্যালকুলেশন ইঞ্জিন হচ্ছে যেখানে "কাঁচা ইভেন্ট"গুলো SLA আউটকামে পরিণত হয় যা আপনি যুক্তি দিতে পারবেন। মূল কথা হলো এটিকে হিসাবরক্ষণীর মত মনে করা: সিদ্ধান্তাত্মক নিয়ম, স্পষ্ট ইনপুট, এবং পুনরায় চালানো যোগ্য ট্রেল।
সবকিছুকে একটি একক অর্ডারড স্ট্রিম-এ রূপান্তর করুন (প্রতি ইনসিডেন্ট বা প্রতি সার্ভিস-ইমপ্যাক্ট):
এই টাইমলাইন থেকে, ইন্টারভাল যোগ করে সময় গণনা করুন—কোনো একটি স্টার্ট/এন্ড স্ট্যাম্পের সরাসরি বিয়োগ না করে।
TTFR সংজ্ঞায়িত করুন হচ্ছে incident_start এবং first_agent_response (বা acknowledged, আপনার SLA ভাষ্য অনুযায়ী) এর মধ্যে চার্জযোগ্য বিলম্ব। TTR হলো incident_start থেকে resolved পর্যন্ত চার্জযোগ্য বিলম্ব।
“চার্জযোগ্য” মানে আপনি যে ইন্টারভ্যালগুলো গণ্য করবেন সেইগুলো বাদ দেবেন:
ইম্প্লিমেন্টেশনের বিবরণ: একটি ক্যালেন্ডার ফাংশন সংরক্ষণ করুন (ব্যবসায়িক ঘণ্টা, ছুটি) এবং একটি রুল ফাংশন যা একটি টাইমলাইন নিয়ে বিলেেবল ইন্টারভাল রিটার্ন করে।
পূর্বেই সিদ্ধান্ত নিন আপনি কিভাবে গণনা করবেন:
আংশিক আউটেজের জন্য, ওজন ব্যবহার করুন কেবল যদি আপনার SLA চুক্তি তা চায়; নয়তো “ডিগ্রেডেড” আলাদা ব্রিচ ক্যাটেগরি হিসেবে বিবেচনা করুন।
প্রতিটি ক্যালকুলেশন পুনরুত্পাদনযোগ্য হওয়া উচিত। সংরক্ষণ করুন:
যখন নিয়ম বদলে যায়, আপনি ভার্সন দিয়ে পুনরায় চালিয়ে ইতিহাস বদলে ফেলবেন না—এটি অডিট ও গ্রাহক বিরোধের ক্ষেত্রে খুব গুরুত্বপূর্ণ।
রিপোর্টিং হচ্ছে যেখানে SLA ট্র্যাকিং বিশ্বাসযোগ্যতা অর্জন করে—অথবা প্রশ্নের জন্ম দেয়। আপনার অ্যাপটিকে স্পষ্ট করতে হবে কোন সময় পরিসর পরিমাপ করা হচ্ছে, কোন মিনিটগুলো গণ্য হয়েছে, এবং চূড়ান্ত সংখ্যা কীভাবে উদ্ভূত হয়েছে।
গ্রাহকরা যে পিরিয়ডগুলো বাস্তবে ব্যবহার করে সেগুলো সাপোর্ট করুন:
পিরিয়ডগুলো স্পষ্ট স্টার্ট/এন্ড টাইমস্ট্যাম্প হিসেবে সংরক্ষণ করুন (না যে "month = 3") যাতে পরে গণনা রিপ্লে করা যায়।
একটি বিভ্রান্তির উৎস হল ডেনমিনেটর পুরো পিরিয়ড নাকি কেবল “যোগ্য” সময়—এটা কাকে ধরে।
প্রতিটি পিরিয়ডে দুইটি মান সংজ্ঞায়িত করুন:
তারপর হিসাব করুন:
availability_percent = 100 * (eligible_minutes - downtime_minutes) / eligible_minutes
যদি eligible minutes শূন্য হয় (উদাহরণ: একটি সার্ভিস শুধুমাত্র ব্যবসায়িক ঘণ্টায় মনিটর করা হয় এবং পিরিয়ডে কোনো মিনিট নেই), অগ্রিম নিয়ম সংজ্ঞায়িত করুন: “N/A” বা 100%—কিন্তু ধারাবাহিকভাবে প্রয়োগ করুন এবং ডকুমেন্ট করুন।
অধিকাংশ SLA উভয় একটি শতাংশ এবং একটি বাইনারি আউটকাম চায়:
ড্যাশবোর্ডে "ব্রিচ বাকি" (রিমেইনিং ডাউনটাইম বাজেট) দেখান যাতে প্রয়োজনীয় পূর্বকালীন সতর্কতা পাঠানো যায়।
সবশেষে, কাঁচা ইনপুট (অন্তর্ভুক্ত/বর্জিত ইভেন্ট এবং অ্যাডজাস্টমেন্ট) সংরক্ষণ করুন যাতে প্রতিটি রিপোর্ট সহজেই উত্তর দিতে পারে “এই সংখ্যাটি কেন এমন?”।
আপনার ক্যালকুলেশন ইঞ্জিন যতই নিখুঁত হোক না কেন, যদি UI মৌলিক প্রশ্নের উত্তর না দেয় (“আমরা কি এখন SLA পূরণ করছি, এবং কেন?”) ব্যবহারকারীরা হতাশ হবেন। প্রতিটি স্ক্রিনকে একটি স্পষ্ট স্ট্যাটাস দিয়ে শুরু করুন, তারপর মানুষকে নীচে সংখ্যাগুলো ও কাঁচা ইভেন্টগুলোতে ড্রিল করতে দিন।
ওভারভিউ ড্যাশবোর্ড (অপারেটর ও ম্যানেজারদের জন্য). ছোট টাইলস দিয়ে নেতৃত্ব দিন: বর্তমান পিরিয়ড কমপ্লায়েন্স, অ্যাভেলিবিলিটি, রেসপন্স-টাইম কমপ্লায়েন্স, এবং "ব্রিচের আগে বাকি সময়" যেখানে প্রযোজ্য। লেবেলগুলো স্পষ্ট রাখুন (উদাহরণ: “Availability (this month)” এর পরিবর্তে "Uptime" ব্যবহার করবেন না)। যদি একাধিক SLA সাপোর্ট করে, সবচেয়ে খারাপ স্ট্যাটাস প্রথম দেখান এবং এক্সপ্যান্ড করার অপশন দিন।
কাস্টমার ডিটেইল (অ্যাকাউন্ট টিম ও গ্রাহক-ফেসিং রিপোর্টিং). একটি কাস্টমার পেজ সব সার্ভিস ও SLA টিয়ার সারাংশ দেখাবে, সহজ পাস/ওয়ার্ন/ফেইল স্টেট এবং সংক্ষিপ্ত ব্যাখ্যা ("2টি ইনসিডেন্ট গণ্য; 18মিনিট ডাউনটাইম গণ্য")। /status লিংক ও রিপোর্ট এক্সপোর্টের লিংক দিন।
সার্ভিস ডিটেইল (ডিপ ইনভেস্টিগেশনের জন্য). এখানে আপনি সঠিক SLA নিয়ম, ক্যালকুলেশন উইন্ডো, এবং কিভাবে কমপ্লায়েন্স সংখ্যা গঠিত হয়েছে তার ব্রেকডাউন দেখাবেন। একটি অ্যাভেলিবিলিটি চার্ট এবং সেই পিরিয়ডে গণ্য ইনসিডেন্টের তালিকা রাখুন।
ইনসিডেন্ট টাইমলাইন (অডিটের জন্য). একটি ইনসিডেন্ট ভিউ টাইমলাইনের সাথে দেখাবে (ডিটেক্টেড, স্বীকৃত, প্রশমিত, সমাধান) এবং কোন টাইমস্ট্যাম্পগুলো রেসপন্স ও রেজল্যুশন মেট্রিকসে ব্যবহার করা হয়েছে।
ফিল্টারগুলো স্ক্রিন জুড়ে কনসিস্টেন্ট রাখুন: তারিখ পরিসর, গ্রাহক, সার্ভিস, টিয়ার, এবং সেভারিটি। সব জায়গায় একই ইউনিট ব্যবহার করুন (মিনিট বনাম সেকেন্ড; শতাংশ একই দশমিক)। যখন ব্যবহারকারী তারিখ রেঞ্জ বদলায়, সব মেট্রিক আপডেট করুন যাতে কোনো mismatch না হয়।
প্রতিটি সারাংশ মেট্রিকের জন্য একটি "কেন?" পথ রাখুন:
টুলটিপ কম ব্যবহার করুন—শর্তের সংজ্ঞাগুলো যেমন “Excluded downtime” বা “Business hours” স্পষ্ট করতে এবং সার্ভিস পেজে সঠিক নিয়ম টেক্সট দেখান যাতে অনুমান না হয়।
সংক্ষিপ্ত শব্দের বদলে সাধারণ ভাষা পছন্দ করুন ("Response time" এর বদলে "MTTA" কেবল আপনার দর্শক বুঝলে ব্যবহার করুন)। স্ট্যাটাসের জন্য রঙ ও টেক্সট লেবেল একসাথে ব্যবহার করুন ("At risk: 92% of error budget used") যাতে দ্ব্যর্থতা না থাকে। যদি আপনার অ্যাপ অডিট লগ সাপোর্ট করে, SLA নিয়ম ও এক্সক্লুশনের পাশে একটি ছোট "Last changed" বক্স দিন যা /audit-এ লিংক করে যাতে ব্যবহারকারীরা পরিবর্তন যাচাই করতে পারেন।
এলার্টিং হচ্ছে যেখানে আপনার SLA ট্র্যাকিং ওয়েব অ্যাপ প্যাসিভ রিপোর্ট থেকে বাধ্যতামূলক সহায়ক সিস্টেমে পরিণত হয়। সেরা এলার্টগুলো সময়োপযোগী, নির্দিষ্ট এবং কার্যকর—অর্থাৎ তারা কেবল “খারাপ” বলবে না, বরং পরবর্তী করণীয় বলবে।
তিনটি ট্রিগার টাইপ দিয়ে শুরু করুন:
ট্রিগারগুলি গ্রাহক/সার্ভিস/SL A অনুযায়ী কনফিগারযোগ্য রাখুন—ভিন্ন চুক্তি ভিন্ন থ্রেশহোল্ড সহ্য করতে পারে।
এলার্ট পাঠান যেখানে মানুষ সত্যিই সাড়া দেয়:
প্রতিটি এলার্টে ডিপ-লিংক থাকা উচিত যেমন /alerts, /customers/{id}, /services/{id}, এবং সংশ্লিষ্ট ইনসিডেন্ট/ইভেন্ট ডিটেইল পেজ যাতে প্রতিক্রিয়াকারীরা দ্রুত সংখ্যাগুলো যাচাই করতে পারে।
ডেডুপ্লিকেশন ইমপ্লিমেন্ট করুন: একই কী (customer + service + SLA + period) সহ এলার্টগুলো গ্রুপ করে কুলডাউন উইন্ডোতে পুনরাবৃত্তি প্রতিহত করুন।
কোয়েট আওয়ারস যোগ করুন (প্রতি টিম টাইমজোন) যাতে নন-ক্রিটিক্যাল “approaching breach” এলার্টগুলো ব্যবসায়িক ঘণ্টায় পর্যন্ত অপেক্ষা করে, যেখানে “breach occurred” উচ্চ সেভারিটির ক্ষেত্রে ওভাররাইড করতে পারে।
অবশেষে, Escalation rules সাপোর্ট করুন (উদা. 10 মিনিটে অন-কল নোটিফাই, 30 মিনিটে ম্যানেজারে এস্কেলেট) যাতে এলার্ট একটি ইনবক্সে আটকে না থাকে।
SLA ডেটা সংবেদনশীল কারণ এটি অভ্যন্তরীণ পারফরম্যান্স ও গ্রাহক-নির্দিষ্ট সুবিধা প্রকাশ করতে পারে। অ্যাক্সেস কন্ট্রোলকে SLA "গণিতে" অন্তর্ভুক্ত করবেন: একই ইনসিডেন্ট ভিন্ন গ্রাহকের SLA প্রয়োগ অনুযায়ী ভিন্ন ফলাফল দিতে পারে।
সাধারণ রাখুন, পরে সূক্ষ্ম-গ্রেডে বাড়ান:
একটি বাস্তবিক ডিফল্ট হলো RBAC + টেন্যান্ট স্কোপিং:
গ্রাহক-নির্দিষ্ট ডেটা সম্পর্কে স্পষ্ট থাকুন:
শুরু করুন ইমেইল/পাসওয়ার্ড দিয়ে এবং অভ্যন্তরীণ রোলে MFA বাধ্যতামূলক করুন। পরে SSO (SAML/OIDC) জন্য পরিকল্পনা রাখুন—আইডেন্টিটি (কে তারা) এবং অথরাইজেশন (ওরা কী অ্যাক্সেস পায়) আলাদা রাখুন। ইন্টিগ্রেশনের জন্য, সংক্ষিপ্ত স্কোপের সাথে API কী ইস্যু করুন এবং রোটেশন সাপোর্ট দিন।
অবিচল অডিট এন্ট্রি যোগ করুন:
কিনুন কে, কি পরিবর্তন করেছিল (আগে/পরে), কখন, কোথায় (IP/ইউজার-এজেন্ট), এবং একটি করেলেশন ID। অডিট লগ সার্চেবল ও এক্সপোর্টেবল করুন (উদা. /settings/audit-log)।
একটি SLA ট্র্যাকিং অ্যাপ সাধারণত একাকী থাকবে না। মনিটরিং টুল, টিকেটিং সিস্টেম, এবং অভ্যন্তরীণ ওয়ার্কফ্লোগুলোকে ইনসিডেন্ট তৈরি, ইভেন্ট পুশ, এবং রিপোর্ট টানার জন্য একটি API লাগে।
ভার্সনড বেস পাথ ব্যবহার করুন (উদাহরণ: /api/v1/...) যাতে আপনি পে-লোড পরিবর্তন করতে পারেন বিদ্যমান ইন্টিগ্রেশন ভাঙা ছাড়া।
কতগুলো অপরিহার্য এন্ডপয়েন্ট:
POST /api/v1/events স্টেট চেঞ্জ ইনজেস্ট করতে; GET /api/v1/events অডিট ও ডিবাগিং-এর জন্য।POST /api/v1/incidents, PATCH /api/v1/incidents/{id} (acknowledge, resolve, assign), GET /api/v1/incidents।GET /api/v1/slas, POST /api/v1/slas, PUT /api/v1/slas/{id} কনট্রাক্ট ও থ্রেশহোল্ড ম্যানেজ করার জন্য।GET /api/v1/reports/sla?service_id=...&from=...&to=... কমপ্লায়েন্স সমারি টানার জন্য।POST /api/v1/alerts/subscriptions ওয়েবহুক/ইমেইল টার্গেট ম্যানেজ করার জন্য; GET /api/v1/alerts এলার্ট হিস্ট্রি।একটি কনভেনশন নিন এবং সব জায়গায় ব্যবহার করুন। উদাহরণ: limit, cursor পেজিনেশন, প্লাস স্ট্যান্ডার্ড ফিল্টারগুলো service_id, sla_id, status, from, এবং to। সোর্টিং পূর্বানুমেয় রাখুন (উদা. sort=-created_at)।
স্ট্রাকচার্ড এরর রিটার্ন করুন স্থির ফিল্ড দিয়ে:
{ "error": { "code": "VALIDATION_ERROR", "message": "service_id is required", "fields": { "service_id": "missing" } } }
স্পষ্ট HTTP স্ট্যাটাস ব্যবহার করুন (400 validation, 401/403 auth, 404 not found, 409 conflict, 429 rate limit)। ইভেন্ট ইনজেশন-এর ক্ষেত্রে আইডেম্পোটেন্সি (Idempotency-Key) বিবেচনা করুন যাতে রিট্রাই ইনসিডেন্ট ডুপ্লিকেট না করে।
প্রতি টোকেনে রিয়াসোনেবল রেট লিমিট প্রয়োগ করুন (ইনজেশন এন্ডপয়েন্টগুলোর জন্য কঠোর)। ইনপুট স্যানিটাইজ করুন, টাইমস্ট্যাম্প/টাইমজোন ভ্যালিডেট করুন। স্কোপড API টোকেন পছন্দ করুন (রিড-অনলি রিপোর্টিং বনাম রাইট অ্যাক্সেস টু ইনসিডেন্ট), এবং সব কল লগ করুন ট্রেসেবিলিটির জন্য (অডিট লগ সেকশনে বিস্তারিত, /blog/audit-logs)।
SLA সংখ্যাগুলো তখনই মূল্যবান যখন মানুষ তাদের বিশ্বাস করে। SLA ট্র্যাকিং অ্যাপের টেস্টিং পেজ লোড চেকের থেকে বেশি "চুক্তি অনুযায়ী টাইম ম্যাথে কি সঠিক হচ্ছে"-তে ফোকাস করা উচিত। আপনার ক্যালকুলেশন রুলগুলোকে একটি প্রোডাক্ট ফিচারের মত একক টেস্ট স্যুট হিসেবে বিবেচনা করুন।
ক্যালকুলেশন ইঞ্জিন ইউনিট-টেস্ট দিয়ে শুরু করুন নির্ধারিত ইনপুট নিয়ে: একটি টাইমলাইনের ইভেন্ট (ইনসিডেন্ট ওপেন, স্বীকৃত, প্রশমিত, রেজলভ) এবং স্পষ্ট SLA রুলসেট। স্থির টাইমস্ট্যাম্প এবং "টাইম ফ্রিজ" ব্যবহার করুন যাতে টেস্ট ক্লক-নির্ভর না হয়। সেই এজ-কেসগুলো কভার করুন:
ছোট সেট এন্ড-টু-এন্ড টেস্ট যোগ করুন যা পুরো ফ্লো চালায়: ইভেন্ট ইনজেস্ট → কমপ্লায়েন্স ক্যালকুলেট → রিপোর্ট জেনারেট → UI রেন্ডার। এগুলো ইঞ্জিন ক্যালকুলেশন ও ড্যাশবোর্ড দেখায় এমন কোনো mismatch ধরবে। কেসগুলো কয়েকটি কিন্তু উচ্চ-মুল্যের রাখুন, এবং চূড়ান্ত সংখ্যায় assert করুন (অ্যাভেলিবিলিটি %, ব্রিচ হ্যাঁ/না, টাইম-টু-অ্যাক)।
ব্যবসায়িক ঘণ্টা, ছুটি, ও টাইমজোনের টেস্ট ফিক্সচার তৈরি করুন। আপনি পুনরাবৃত্ত পケース চান যেমন "ইনসিডেন্ট শুক্রবার 17:55 লোকাল টাইমে" এবং "ছুটিগুলো রেসপন্স-টাইম গণনা কীভাবে সরাতে পারে"।
টেস্ট ডেপ্লয়ের পরেও কাজ শেষ হয় না। জব ফেইলিউর, কিউ/বেকলগ সাইজ, পুনর্গণনার সময়, এবং এরর রেটের জন্য মনিটরিং যোগ করুন। যদি ইনজেশন ল্যাগ করে বা নৈটলি জব ফেল হয়, আপনার SLA রিপোর্ট ভুল হতে পারে এমনকি কোড সঠিক থাকলেও।
SLA ট্র্যাকিং অ্যাপ শিপ করা ফ্যান্সি ইনফ্রা নয় বরং পূর্বানুমেয় অপারেশন সম্পর্কে: আপনার গণনা সময়মত চলতে হবে, ডেটা নিরাপদ থাকতে হবে, এবং রিপোর্ট পুনরুত্পাদনযোগ্য হতে হবে।
ম্যানেজড সার্ভিস দিয়ে শুরু করুন যাতে আপনি সঠিকতায় মনোযোগ দিতে পারেন:
ইনভায়রনমেন্টগুলোকে সীমিত রাখুন: dev → staging → prod, প্রতিটির আলাদা ডাটাবেস ও সিক্রেট।
SLA ট্র্যাকিং পুরোপুরি রিকোয়েস্ট/রেসপন্স নয়; এটি নির্ধারিত কাজের উপর নির্ভর করে।
জবগুলোওয়ার্কার প্রসেস + কিউ দিয়ে চালান অথবা একটি ম্যানেজড শেডিউলার ব্যবহার করুন। জবগুলো আইডেম্পোটেন্ট রাখুন (রিট্রাই-সেফ) এবং প্রতিটি রান লগ করুন অডিটযোগ্যতার জন্য।
ডেটা টাইপ দ্বারা রিটেনশন সংজ্ঞায়িত করুন: ডেরাইভড কমপ্লায়েন্স ফলাফল কাঁচা ইভেন্ট স্ট্রিমের চেয়ে বেশি সময় রাখুন। এক্সপোর্টের জন্য প্রথমে CSV অফার করুন (দ্রুত, স্বচ্ছ), পরে PDF টেমপ্লেট। স্পষ্ট করুন: এক্সপোর্টগুলি “বেস্ট-এফোর্ট ফরম্যাটিং”, ডাটাবেস হল সোর্স অফ ট্রুথ।
আপনি যদি আপনার ডেটা মডেল, ইনজেশন ফ্লো, এবং রিপোর্টিং UI দ্রুত যাচাই করতে চান, একটি ভিব-কোডিং প্ল্যাটফর্ম যেমন Koder.ai আপনাকে দ্রুত end-to-end প্রোটোটাইপ দেয়—চ্যাটের মাধ্যমে ওয়েব UI + ব্যাকএন্ড উত্পন্ন করে। এটি ব্যবহার করে আপনি দ্রুত পেতে পারেন:
একবার প্রয়োজনীয়তা ও ক্যালকুলেশন প্রমাণিত হলে (যা কঠিন অংশ), আপনি সোর্স কোড এক্সপোর্ট করে আরও ঐতিহ্যবাহী বিল্ড-অ্যান্ড-অপারেট ওয়ার্কফ্লোতে যেতে পারেন—প্রতিটি দ্রুত পুনরুদ্ধার ও রোলব্যাক ফিচার রেখে দ্রুত ইটারেট করার সময়।
একটি SLA ট্র্যাকার একটি প্রশ্ন প্রমাণসহ উত্তর দেয়: নির্দিষ্ট গ্রাহক ও সময়কালের জন্য চুক্তিভিত্তিক অঙ্গীকারগুলো আমরা পূরণ করেছি কি না?
বাস্তবে, এর মানে হল কাঁচা সিগন্যাল (মনিটরিং, টিকিট, ম্যানুয়াল আপডেট) ইনজেস্ট করা, গ্রাহকের নিয়ম (ব্যবসায়িক ঘণ্টা, বর্জ্যসমূহ) প্রয়োগ করা, এবং অডিট-ফ্রেন্ডলি পাস/ফেইল ফলাফল ও সহায়ক বিবরণ তৈরি করা।
পৃথকভাবে ব্যবহার করুন:
এগুলো আলাদা মডেল করলে আপনি বিশ্বাসযোগ্যতা বাড়াতে পারবেন (SLO বদলে সরাসরি কনট্রাক্ট ফলাফল পরিবর্তন হবে না)।
একটি শক্ত MVP সাধারণত 1–3 মেট্রিক end-to-end ট্র্যাক করে:
এগুলো বাস্তব ডেটা উৎসের সাথে ভালোভাবে ম্যাপ করে এবং আপনাকে পিরিয়ড, ক্যালেন্ডার, এক্সক্লুশনগুলোর জটিলতা তাড়াতাড়ি হ্যান্ডল করতে বাধ্য করে।
চারণ বা ক্যালকুলেটর লিখার আগে নিচিগুলো সংগ্রহ করুন—দমনীয় নিয়মগুলোই প্রায়শই ব্যর্থতার কারণ:
যদি কোনো নিয়ম পরিষ্কারভাবে লেখা না থাকে, সেটি কোডে অনুমান করবেন না—স্পষ্ট করুন।
শুরুর জন্য যুক্তিসঙ্গত, স্পষ্ট এন্টিটি রাখুন:
লক্ষ্য রাখুন: প্রতিটি রিপোর্ট করা সংখ্যাকে নির্দিষ্ট এবং পলিসি ভার্সনের সাথে লিঙ্ক করা উচিত।
সময় সঠিকভাবে এবং ধারাবাহিকভাবে সংরক্ষণ করুন:
occurred_at UTC-তে সংরক্ষণ করুন (টাইমজোন সহ)received_at (যে সময় আপনি ইনজেস্ট করেছেন)পিরিয়ডগুলো স্পষ্টভাবে (start/end timestamps) রাখুন যাতে DST বা পরবর্তী পুনরোত্থানে রিপোর্ট পুনরুত্পাদন করা যায়।
সবকিছুকে একটি অভ্যন্তরীণ একই "ইভেন্ট" শেপে নরমালাইজ করুন এবং স্থায়ী ইউনিক আইডি ব্যবহার করুন:
event_id (স্থায়ী, রিট্রাই-সাম্য)source, event_type, , সময়-গণনা সবসময় একটি টাইমলাইনের ইন্টারভাল যোগ করে করুন, দুটি টাইমস্ট্যাম্পের সরাসরি বিয়োগ না করে।
chargeable সময় বলতে বোঝায় যে আপনি নিম্নলিখিত ইন্টারভালগুলো বাদ দেবেন:
উৎপন্ন ইন্টারভাল এবং কারণ-কোডগুলো সংরক্ষণ করুন যাতে কী গণ্য করা হয়েছে তা ব্যাখ্যা করা যায়।
স্পষ্টভাবে দুইটি অঙ্ক রাখুন:
তারপর হিসাব:
availability_percent = 100 * (eligible_minutes - downtime_minutes) / eligible_minutes
এবং সিদ্ধান্ত নিন যদি শূন্য হয় তাহলে কী দেখাবেন (উদাহরণ: )। ডকুমেন্ট করুন এবং ধারাবাহিকভাবে প্রয়োগ করুন।
UI-কে সহজে এক নজরে উত্তর দিতে হবে: "আমরা কি এখন SLA পূরণ করছি, এবং কেন?"
এলার্টগুলোর জন্য: অ্যাপ্রোচিং ব্রিচ, ব্রিচ প্রসারিত এবং পুনরাবৃত্তি-ভায়োলেশনকে অগ্রাধিকার দিন—প্রতিটি সংশ্লিষ্ট পেজে ডিপ-লিংক সহ।
event_idoccurred_atservice_idincident_id এবং attributesevent_id-এ ইউনিক কনস্ট্রেইন্ট রাখুন যাতে রিট্রাই ডুপ্লিকেট না করে। মানপত্র মিসম্যাপ বা আউট-অফ-অর্ডারে আসলে সেগুলোকে কয়ারান্টিন/ফ্ল্যাগ করুন—স্বয়ংক্রিয়ভাবে
eligible_minutes