একটি AI-চালিত অ্যাসিস্ট্যান্ট সাত দিন ধরে আমার অন-কল (on-call) দায়িত্ব পালন করেছে, ১১টি অ্যালার্ট প্রসেস করেছে এবং সমস্যা সমাধানের গড় সময় ৪৫ মিনিট থেকে কমিয়ে ২০ মিনিটে নিয়ে এসেছে। এই পরীক্ষাটি গুরুত্বপূর্ণ কারণ একটি মাঝারি পরিসরের ল্যাঙ্গুয়েজ মডেল কঠোর মানুষের তত্ত্বাবধান বজায় রেখেও ইনসিডেন্ট রেসপন্স (incident response) বা ঘটনা মোকাবিলায় আধা ঘণ্টা সময় কমিয়ে দিতে পারে।
কেন আমি একটি AI-কে অন-কল ডিউটিতে নিযুক্ত করলাম
ক্লাউড টিমগুলো তাদের শিফটের বেশিরভাগ সময় লগ (logs) খোঁজা, সাম্প্রতিক ডিপ্লয়মেন্ট (deployments) পরীক্ষা করা এবং একটি স্কেলিং রিকোয়েস্ট নিরাপদ কি না তা নিশ্চিত করতে ব্যয় করে। এই "একঘেয়ে" কাজগুলো পুনরাবৃত্তিমূলক, ডেটা-নির্ভর এবং মানুষের ক্লান্তির কারণে ভুল হওয়ার সম্ভাবনা থাকে। লার্জ ল্যাঙ্গুয়েজ মডেলের (LLM) সাম্প্রতিক অগ্রগতিগুলো ঠিক এই ধরনের প্যাটার্ন-ম্যাচিং কাজগুলো অটোমেট করার প্রতিশ্রুতি দিলেও, বেশিরভাগ পাবলিক ডেমো স্যান্ডবক্স এনভায়রনমেন্টে চলে। আমি দেখতে চেয়েছিলাম যে, প্রকৃত গ্রাহকদের সেবা প্রদানকারী একটি প্রোডাকশন-গ্রেড ক্লাস্টারে এই হাইপ বা উত্তেজনা টিকে থাকে কি না।
পরীক্ষার সেটআপ
- Access – এজেন্টটি প্রতিটি মেট্রিক, লগ এবং ডিপ্লয়মেন্ট ডেফিনিশন পড়তে পারত। এটি শুধুমাত্র একটি নির্দিষ্ট হোয়াইটলিস্টে (whitelist) লিখতে পারত: একটি পড (pod) রিস্টার্ট করা, রেপ্লিকা কাউন্ট (replica count) বাড়ানো বা একটি ডিপ্লয়মেন্ট স্কেল করা। এই কাজগুলোর বাইরে যেকোনো কিছুর জন্য আমার স্পষ্ট অনুমোদনের প্রয়োজন ছিল।
- Role – আমি মডেলটিকে তার প্রথম অন-কল শিফটে থাকা একজন জুনিয়র ইঞ্জিনিয়ার হিসেবে বিবেচনা করেছি। এটি অ্যালার্ট গ্রহণ করত, বিশ্লেষণ চালাত এবং ইনসিডেন্ট চ্যানেলে একটি সুপারিশ (recommendation) পোস্ট করত।
- Safety nets – সমস্ত রাইট অ্যাকশন (write actions) একটি ম্যানুয়াল "হ্যাঁ/না" প্রম্পটের মাধ্যমে নিয়ন্ত্রিত ছিল। খরচ নিয়ন্ত্রণে রাখার জন্য আমি মডেলের টোকেন ব্যবহারের সীমাও নির্ধারণ করে দিয়েছিলাম।
যেখানে AI দারুণ পারফর্ম করেছে
এজেন্টের গতি ছিল সবচেয়ে উল্লেখযোগ্য উন্নতি। একটি অ্যালার্ট আসার সাথে সাথেই এটি প্রাসঙ্গিক লগ সংগ্রহ করত, সাম্প্রতিক মেট্রিকগুলো প্লট করত এবং শেষ তিনটি ডিপ্লয়মেন্টের তালিকা তৈরি করত। আমি যখন ল্যাপটপ খুললাম, প্রাথমিক গোয়েন্দাগিরি বা তদন্তের কাজ ততক্ষণে শেষ হয়ে গিয়েছিল। ১১টি অ্যালার্টের মধ্যে:
- ৮টি ছিল রুটিন সমস্যা (মেমরি স্পাইক, কন্টেইনার রিস্টার্ট, সাধারণ মিসকনফিগারেশন)। AI প্রতিবারই সঠিকভাবে মূল কারণ (root cause) শনাক্ত করতে পেরেছে।
- একটি মাইক্রোসার্ভিসে মেমরির ক্রমিক বৃদ্ধি এটি শনাক্ত করেছিল, যা রাত ২টার বড় ধরনের আউটটেজ (outage) হওয়ার আগেই টিমকে দ্রুত পদক্ষেপ নেওয়ার সুযোগ করে দিয়েছিল।
- পুরো সপ্তাহের টোকেন খরচ ছিল প্রায় $৩০, যা সীমা নির্ধারণ করার ফলে একটি সাধারণ অন-কল বাজেটের মধ্যেই ছিল।
এই ফলাফলগুলো মিন টাইম টু রেজোলিউশন (MTTR) ৪৫ মিনিট থেকে কমিয়ে ২০ মিনিটে নিয়ে এসেছে, যা ইঞ্জিনিয়ারদের উচ্চ-প্রভাবশালী কাজে মনোযোগ দেওয়ার সুযোগ করে দেয়।
যেখানে এটি ভুল করেছে
আত্মবিশ্বাস মানেই সঠিকতা নয়। ১১টি অ্যালার্টের মধ্যে ৩টি ক্ষেত্রে AI আত্মবিশ্বাসের সাথে ভুল করেছে:
- একটি ডেটাবেস কানেক্টিভিটি ফেইলিউরের জন্য এটি সাম্প্রতিক কোড ডিপ্লয়মেন্টকে দায়ী করেছিল, কিন্তু সেই ব্যাখ্যাটি ভুল ছিল।
- একটি অপরিচিত নেটওয়ার্কিং অ্যানোমালি (anomaly) বা অস্বাভাবিকতার সম্মুখীন হলে, এটি সাধারণ কিছু সমাধান দিয়েছিল যা মূল সমস্যার সমাধান করতে পারেনি।
- লোড-সংক্রান্ত একটি অ্যালার্টের সময়, এটি একটি সার্ভিসকে ৩টি থেকে ৩০টি রেপ্লিকাতে স্কেল করার পরামর্শ দিয়েছিল। সমস্যাটি লোড নিয়ে ছিল না; সমস্যাটি ছিল একটি ভুল কনফিগারেশন নিয়ে।
যেহেতু আমার গার্ডরেলগুলো (guardrails) যেকোনো রাইট অপারেশনের জন্য ম্যানুয়াল অনুমোদনের প্রয়োজন ছিল, তাই মডেলের ভুলগুলো বড় কোনো ক্ষতি করার আগেই ধরা পড়েছিল। তবুও, এই ঘটনাটি একটি মূল ঝুঁকিকে সামনে এনেছে: মডেলটি বিশ্বাসযোগ্য মনে হয় এমন কিন্তু ভুল সুপারিশ তৈরি করতে পারে, বিশেষ করে নতুন বা অপরিচিত সমস্যার ক্ষেত্রে।
খরচ এবং ঝুঁকি ব্যবস্থাপনা
$৩০-এর টোকেন বিল দেখায় যে ব্যবহার পর্যবেক্ষণ করলে প্রোডাকশন লুপে একটি LLM চালানো সস্তা হতে পারে। তবে আসল খরচ হলো অপারেশনাল ঝুঁকি। একটি ডিপ্লয়মেন্ট ভুলভাবে স্কেল করলে ক্লাউড খরচ অনিয়ন্ত্রিতভাবে বেড়ে যেতে পারে এবং একটি ভালো রিলিজ রোলব্যাক করলে গ্রাহকের আস্থা নষ্ট হতে পারে। এই পরীক্ষাটি দুটি সুরক্ষা ব্যবস্থা নিশ্চিত করেছে:
- Action gating – মানুষের ক্লিক ছাড়া মডেলটিকে শুধুমাত্র পরামর্শ দেওয়ার অনুমতি দিন, সরাসরি কার্যকর করার নয়।
- Budget caps – টোকেন ব্যবহারের কঠোর সীমা নির্ধারণ করুন এবং মডেলটি সীমার কাছাকাছি পৌঁছালে টিমকে সতর্ক করুন।
পরবর্তীতে যা খেয়াল রাখতে হবে
ততদিন পর্যন্ত, টিমগুলোর উচিত:
- AI-জেনারেটেড পরামর্শগুলোর কত শতাংশ ম্যানুয়াল ওভাররাইড (manual override) প্রয়োজন হচ্ছে তা ট্র্যাক করা।
- বিভিন্ন ধরনের ইনসিডেন্ট ক্যাটাগরিতে (রুটিন বনাম নতুন) MTTR-এর ওপর প্রভাব পরিমাপ করা।
- প্রোডাকশনে রাইট রাইটস (write rights) দেওয়ার আগে সিন্থেটিক অ্যালার্ট ব্যবহার করে একটি স্টেজিং এনভায়রনমেন্টে মডেলটি পরীক্ষা করা।
অপারেশনস (Ops) টিমের জন্য মূল শিক্ষা
- ৮০% একঘেয়ে কাজ অটোমেট করুন – লগ অ্যাগ্রিগেশন (log aggregation), মেট্রিক কোরিলেশন (metric correlation) এবং প্রাথমিক হাইপোথিসিস তৈরির জন্য AI ব্যবহার করুন।
- ঝুঁকিপূর্ণ ২০% মানুষের জন্য রাখুন – একটি নির্দিষ্ট সীমার বেশি স্কেলিং, রোলব্যাক এবং ডিলিট করার মতো কাজগুলো ম্যানুয়াল অনুমোদনের ধাপের অধীনে রাখা উচিত।
- মডেলটিকে একজন পার্টনার হিসেবে বিবেচনা করুন, প্রতিস্থাপক হিসেবে নয় – সিস্টেম সম্পর্কে জানা একজন ইঞ্জিনিয়ার একজন নতুন মানুষের চেয়ে দ্রুত AI-এর আউটপুট যাচাই করতে পারেন, যা এই অ্যাসিস্ট্যান্টকে কাজের গতি বহুগুণ বাড়িয়ে দেয় (force multiplier)।
একটি AI এজেন্ট এখনও একা কোনো ক্লাউড অপারেশন পরিচালনা করতে পারে না, তবে ট্রায়াজ পার্টনার হিসেবে এটি ইতিমধ্যে কাজের গতি উল্লেখযোগ্যভাবে বাড়িয়ে দিচ্ছে। মূল বিষয়টি হলো এর ওপর নির্ভরতা নিয়ন্ত্রণে রাখা, কঠোর গাইডরেল (guardrails) প্রয়োগ করা এবং মডেলটিকে পুনরাবৃত্তিমূলক ও ক্লান্তিকর কাজগুলো করতে দেওয়া, যেখানে মানুষের বিশেষজ্ঞ জ্ঞান গুরুত্বপূর্ণ সিদ্ধান্তগুলো পরিচালনা করবে।