একসঙ্গে থেমেছিল ChatGPT, Claude ও Grok—কাজের backup কেন আলাদা চাই
৩ সেপ্টেম্বর ২০২৬-এ ChatGPT, Claude ও Grok কাছাকাছি সময়ে ব্যাহত হয়েছিল; পরে তিনটি সেবাই সচল হয়। ওই দিনের ঘটনাগুলো নিয়ে WIRED-এর অনুসন্ধানে OpenAI-এর routing error ও Grok-সংশ্লিষ্ট Memphis compute center outage-এর তথ্য মিলেছে, কিন্তু তিন provider-এর জন্য একটিমাত্র shared root cause প্রতিষ্ঠিত হয়নি।
৩ সেপ্টেম্বরের এই overlapping disruption দেখিয়েছে, শুধু দ্বিতীয় একটি chatbot account রাখলে AI-নির্ভর কাজের নির্ভরযোগ্য backup হয় না। তিনটি incident-ই resolved হলেও জরুরি workflow চালু রাখতে আলাদা provider-এর পাশাপাশি বহনযোগ্য working context এবং AI ছাড়াই ন্যূনতম কাজ শেষ করার পথ দরকার।
কখন কোন সেবা ব্যাহত হয়েছিল
ঘটনাগুলোর শুরু ও শেষের সময় অভিন্ন ছিল না। তবে UTC অনুযায়ী প্রকাশিত update সাজালে দেখা যায়, তিন provider-এর disruption একটি উল্লেখযোগ্য সময় ধরে overlap করেছিল:
- Claude: Sonnet 5-এর elevated errors নিয়ে তদন্ত শুরু হয় ১২:৩৭ UTC-তে; সেই incident ১২:৫৬ UTC-তে resolved হয়। পৃথক ও বিস্তৃত incident-এ একাধিক model-এর error নিয়ে তদন্ত শুরু হয় ১৩:২৬ UTC-তে, impact শেষ হয় ১৬:১৬ UTC-তে এবং resolved update আসে ১৬:২৩ UTC-তে।
- Grok: বিভিন্ন platform ও service-এ সমস্যা নিয়ে তদন্ত শুরু হয় প্রায় ১৩:৩০ UTC-তে। ১৭:০৫ UTC-তে traffic আবার healthy হওয়ার update দেওয়া হয়।
- ChatGPT ও Codex: OpenAI ১৪:৪৩ UTC-তে তদন্ত শুরু করে, ১৫:১৭ UTC-তে mitigation প্রয়োগের কথা জানায় এবং ১৬:৫৫ UTC-তে incident resolved হিসেবে চিহ্নিত করে।
OpenAI-এর incident record অনুযায়ী ChatGPT-এর ১৫টি ও Codex-এর ৪টি component আক্রান্ত হয়েছিল। একই record-এ সতর্ক করা হয়, ঘটনার পরে কিছু Codex remote control ব্যবহারকারীকে mobile device আবার pair করতে হতে পারে।
তিন provider-এর নিশ্চিত কারণ এক নয়
OpenAI সবচেয়ে নির্দিষ্ট ব্যাখ্যা দিয়েছে: ৭:৪৩ a.m. Pacific Time থেকে শুরু হওয়া routing error কিছু ব্যবহারকারীর জন্য বিভিন্ন platform-এ ChatGPT ও Codex unavailable করেছিল; ৮:১৭ a.m.-এর দিকে সমাধান কার্যকর হয়। এটি OpenAI-এর disruption ব্যাখ্যা করে, Claude বা Grok-এর incident-এর কারণ নয়।
Anthropic-এর status history দেখায়, Mythos/Fable 5.1, Mythos/Fable 5, Opus 5, Opus 4.8 ও Opus 4.6 কোনো না কোনো পর্যায়ে elevated errors-এর আওতায় ছিল। Anthropic ১৩:৪১ UTC-তে কারণ শনাক্ত এবং ১৬:০৬ UTC-তে fix deploy করার কথা লিখলেও প্রকাশ্য update-এ কারণটির প্রযুক্তিগত প্রকৃতি জানায়নি।
Grok-এর সমস্যার বিষয়ে SpaceX-এর প্রকাশ্য বক্তব্যে Memphis compute center-এর outage এবং প্রভাবিত compute partners-এর কাছে দুঃখ প্রকাশের কথা ছিল। কিন্তু compute center কেন ব্যর্থ হয়েছিল, কোন partner কতটা প্রভাবিত হয়েছিল বা ওই failure-এর সঙ্গে OpenAI ও Anthropic-এর কোনো যোগ ছিল কি না—এসব তথ্য প্রকাশ করা হয়নি।
একই সময়ের outage মানেই shared failure নয়
তিনটি সেবা একই সময়সীমার মধ্যে unavailable বা error-prone ছিল—এই correlation নিশ্চিত। কিন্তু shared cloud failure, cyberattack কিংবা coordinated event তিনটিকে থামিয়েছিল—এমন কোনো প্রকাশ্য প্রমাণ নেই। OpenAI ও Anthropic কেউই তাদের ঘটনার জন্য বাইরের provider-কে দায়ী করেনি; একই সময়ে Cloudflare, Amazon Web Services বা Microsoft Azure-ও এমন কোনো outage নথিভুক্ত করেনি যা তিনটি incident একসঙ্গে ব্যাখ্যা করে।
এখানে provider, component এবং failure mode আলাদা রাখা গুরুত্বপূর্ণ। OpenAI routing-এর কথা বলেছে, SpaceX Memphis-এর compute facility-র outage উল্লেখ করেছে, আর Anthropic কেবল কারণ শনাক্ত ও fix deploy করার তথ্য দিয়েছে। কাছাকাছি সময়ে ঘটা এই তিন ব্যর্থতাকে এক ঘটনা ধরে নিলে নিশ্চিত তথ্যের চেয়ে অনুমান বেশি হয়ে যায়।
IT operations দলের ক্ষেত্রেও একই সীমারেখা প্রযোজ্য। কোনো shared dependency প্রমাণিত হওয়ার আগে একটি নির্দিষ্ট cloud বা network layer-কে দায়ী করে architecture বদলানো ভুল লক্ষ্য বেছে নেওয়া হতে পারে। বরং provider-এর incident সময়ের সঙ্গে প্রতিষ্ঠানের নিজস্ব request log, error code এবং ব্যর্থ job-এর সময় মিলিয়ে দেখলে কোন workflow সত্যিই প্রভাবিত হয়েছিল তা আলাদা করা যায়।
কাজের backup কেন স্বাধীন হওয়া দরকার
একটি বিকল্প AI account পূর্ণাঙ্গ backup নয়। প্রথম স্তরে provider diversity দরকার, যাতে primary service ব্যাহত হলে অনুমোদিত অন্য provider-এ কাজ সরানো যায়। কিন্তু ৩ সেপ্টেম্বরের overlap দেখিয়েছে, প্রতিদ্বন্দ্বী provider-ও একই সময়ে সমস্যায় পড়তে পারে; ফলে continuity পরিকল্পনা সেখানে শেষ হলে জরুরি কাজ আবার আটকে যাবে।
দ্বিতীয় স্তর হলো বহনযোগ্য working context। Prompt template, অনুমোদিত reference, output format ও প্রয়োজনীয় instruction শুধু একটি provider-এর workspace-এ থাকলে অন্য service সচল থাকলেও কাজ দ্রুত স্থানান্তর করা কঠিন। এগুলো version-controlled repository বা অনুমোদিত অভ্যন্তরীণ storage-এ রাখলে provider বদলালেও কাজের শর্ত পুনর্গঠন করা যায়।
তৃতীয় স্তরে সীমিত non-AI procedure রাখা দরকার। যেমন ticket triage, document summary বা code review-এর ক্ষেত্রে outage চলাকালে কোন মূল নথি, template ও approval rule ব্যবহার করে ন্যূনতম গ্রহণযোগ্য ফল তৈরি হবে, তা আগে নির্ধারণ করা যায়। উদ্দেশ্য AI-এর স্বাভাবিক গতি অনুকরণ করা নয়; গুরুত্বপূর্ণ workflow যেন পুরোপুরি থেমে না যায়।
Fallback-এর operational নিয়মও পৃথক হওয়া দরকার: কতক্ষণ error চললে switch হবে, queued request আবার পাঠালে duplicate action হতে পারে কি না এবং primary service ফেরার পরে কোন output authoritative বলে গণ্য হবে। এ নিয়ম না থাকলে দেরিতে ফিরে আসা দুই provider-এর response একই ticket, document বা code change-এ পরস্পরবিরোধী কাজ শুরু করতে পারে।
সেবা ফিরলেও recovery আলাদাভাবে যাচাই করতে হয়
Status page-এ “resolved” লেখা মানে provider-এর incident শেষ; প্রতিটি প্রতিষ্ঠানের নিজস্ব workflow স্বয়ংক্রিয়ভাবে ঠিক হয়েছে, এমন নয়। Retry queue, expired session, অসম্পূর্ণ upload ও মাঝপথে থেমে থাকা automated job আলাদা অবস্থায় থেকে যেতে পারে। OpenAI-এর mobile device পুনরায় pair করার সতর্কতাই provider recovery এবং user-side recovery-এর এই পার্থক্য দেখায়।
তাই recovery যাচাইয়ের উপযুক্ত একক হলো ব্যবহৃত নির্দিষ্ট component এবং একটি controlled end-to-end request। শুধু web interface খোলা যাচ্ছে কি না দেখলে API endpoint, নির্বাচিত model, authentication বা downstream integration-এর অবস্থা বাদ পড়ে যেতে পারে। পুরোনো queued কাজ আবার চালুর আগে duplicate side effect-এর ঝুঁকিও যাচাই করা প্রয়োজন।
এখন তিনটি incident-ই resolved, কিন্তু root-cause picture অসম্পূর্ণ। OpenAI নিজের routing error চিহ্নিত করেছে, Grok-এর ক্ষেত্রে Memphis compute center outage-এর কথা এসেছে, আর Anthropic প্রকাশ্যে কারণের বিবরণ দেয়নি। অতিরিক্ত post-incident analysis না আসা পর্যন্ত এগুলোকে কাছাকাছি সময়ে ঘটা পৃথক incident ধরে স্বাধীন fallback তৈরি করাই উপলভ্য তথ্যের সঙ্গে সবচেয়ে সামঞ্জস্যপূর্ণ সিদ্ধান্ত।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।