১৭ আগস্ট সন্ধ্যায় বাংলাদেশের অনেক ডেভেলপার হয়তো দেখেছেন, পুল রিকোয়েস্টের পাতা খুলছে না, ইস্যু লোড হচ্ছে না, ডিপ্লয়মেন্টের কাজ আটকে আছে, আর Copilot সাড়া দিচ্ছে না। সমস্যাটা তাঁদের ইন্টারনেট বা কম্পিউটারে ছিল না। সমস্যা ছিল বিশ্বের সবচেয়ে বড় কোড-হোস্টিং প্ল্যাটফর্ম GitHub-এ।
GitHub-এর নিজস্ব ঘটনা সারাংশ অনুযায়ী, এই বিভ্রাট চলেছে ১৩:২৮ থেকে ২১:১৫ ইউটিসি পর্যন্ত, মোট ৭ ঘণ্টা ৪৭ মিনিট। বাংলাদেশ সময়ে তা ১৭ আগস্ট সন্ধ্যা ৭টা ২৮ মিনিট থেকে পরদিন ভোর ৩টা ১৫ মিনিট। তবে পুরো সময় সবকিছু বন্ধ ছিল না, এবং ঘটনার ভেতরের গল্পটা প্রতিটি ডেভেলপারের জন্যই শিক্ষণীয়।
কতটা ক্ষতি হয়েছিল
GitHub জানিয়েছে, Issues, Pull Requests, এপিআই, Actions ও Copilot-এ ত্রুটি ও ধীরগতি দেখা দেয়। সর্বোচ্চ অবস্থায় ওয়েব ও এপিআইতে ত্রুটির হার ছিল প্রায় ২০ শতাংশ, আর আর্কাইভ ও র কনটেন্ট ডাউনলোডে প্রায় ৫০ শতাংশ। SAML/OIDC লগইন, SCIM ও Team Sync-ও আক্রান্ত হয়। অর্থাৎ অনেক অনুরোধ তখনো সফল হচ্ছিল, কিন্তু কাজ চালানোর মতো নির্ভরযোগ্যতা ছিল না।
- রাত ১০টা ৩৬ মিনিট (১৬:৩৬ ইউটিসি): সেন্ট্রাল ইউএস ডেটা সেন্টার সেরে ওঠায় বেশিরভাগ সেবা ফেরে।
- রাত প্রায় ১২টা ০৩ মিনিট (১৮:০৩ ইউটিসি): Actions-এর সমস্যা কাটে।
- ভোর ৩টা ০২ মিনিট (২১:০২ ইউটিসি): Copilot Token Service পুরোপুরি ঠিক হয়।
তাই "প্রায় আট ঘণ্টা" কথাটা সঠিক, তবে সেটি পুরো ঘটনার সময়সীমা। বেশিরভাগ সেবার সমস্যা ছিল প্রায় তিন ঘণ্টা, শেষ অংশটি মূলত Copilot-কে ঘিরে।
ভেতরে কী ভেঙেছিল
বড় প্ল্যাটফর্মে বিপর্যয় সাধারণত একটি বড় ভুলে হয় না, একের পর এক ছোট ব্যর্থতায় হয়। GitHub-এর বিবরণ এর ভালো উদাহরণ। ভাষাটা একটু সহজ করে দেখা যাক।
প্রতিদিনের বিপুল অনুরোধ একাধিক সার্ভারে ভাগ করে দেয় লোড ব্যালান্সার। একে ব্যস্ত রাস্তার ট্রাফিক পুলিশ ভাবতে পারেন। আর প্রতিটি সেবার পাশে থাকে একটি ছোট সহকারী প্রোগ্রাম, যাকে সাইডকার বলে। এটি সেবার হয়ে নেটওয়ার্কের যোগাযোগ সামলায়।
GitHub জানিয়েছে, শুরুটা এই সাইডকারে। একটি Istio সাইডকার তার একসঙ্গে কাজ সামলানোর সীমায় পৌঁছায়, কিন্তু স্বয়ংক্রিয়ভাবে আরও কপি চালু হয়নি। কারণ অটোস্কেলিং নীতিটি ভুলভাবে সাজানো ছিল: সেটি মূল সেবার দিকে নজর রাখছিল, সাইডকারের সীমার দিকে নয়। অনেকটা এমন, যেন গাড়ির ইঞ্জিনের তাপমাত্রা দেখছেন, কিন্তু রেডিয়েটরের পানি শেষ হয়ে যাচ্ছে সেটা দেখার কোনো মিটার নেই।
এরপর শৃঙ্খল বিক্রিয়া। নতুন সর্বোচ্চ ট্রাফিকে সেন্ট্রাল ইউএসের লোড ব্যালান্সারে নেটওয়ার্ক স্যাচুরেট হয়ে যায়। একটি ব্যর্থতা থেকে ছড়িয়ে চারটি HAProxy নোড তাদের ফ্লো সীমা শেষ করে ফেলে। এতে গেটওয়ের প্রমাণীকরণ পথ দুর্বল হয়, ফলে যে সেবাগুলো লগইন যাচাইয়ের ওপর নির্ভরশীল, সবগুলোতে ধীরগতি ও ব্যর্থতা ছড়ায়। শেষ পর্যন্ত ওই নোডগুলোতে HAProxy একসঙ্গে থামিয়ে দেওয়ায় তাৎক্ষণিক ও ব্যাপক উন্নতি হয়। ইঞ্জিনিয়াররা কিছু ব্যর্থ ট্রাফিক নর্দার্ন ভার্জিনিয়াতেও সরিয়ে নেন।
এখান থেকে একটি বড় নকশাগত শিক্ষা পাওয়া যায়। প্রমাণীকরণ এমন একটি পথ, যার ওপর প্রায় সব সেবা দাঁড়িয়ে থাকে। তাই Issues বা Pull Requests নিজেরা ঠিক থাকলেও লগইন যাচাই আটকে গেলে ব্যবহারকারীর কাছে পুরো সাইটই নষ্ট মনে হয়। অনেক সেবা যখন একটি সাধারণ পথ ভাগাভাগি করে, তখন সেই পথের দুর্বলতা সবার দুর্বলতা হয়ে দাঁড়ায়। আপনার নিজের প্রকল্পেও এমন একটি অংশ আছে কি না, ভেবে দেখুন।
রিট্রাই: সাহায্য যখন আঘাত হয়ে ওঠে
এই ঘটনার সবচেয়ে শিক্ষণীয় অংশ এটাই। কোনো অনুরোধ ব্যর্থ হলে সফটওয়্যার সাধারণত আবার চেষ্টা করে, একে রিট্রাই বলে। একজন ব্যবহারকারীর জন্য এটি ভালো। কিন্তু লাখো ক্লায়েন্ট একসঙ্গে বারবার চেষ্টা করলে আহত সার্ভারের ওপর আরও চাপ পড়ে, ঠিক যেন ভিড়ে দরজা আটকে গেলে সবাই একসঙ্গে ধাক্কা দেওয়া শুরু করল।
GitHub জানিয়েছে, অভ্যন্তরীণ একটি এন্ডপয়েন্টের দেরিতে সাড়া VS Code-এর একটি সুপ্ত রিট্রাই ত্রুটি চালু করে দেয়, যা ট্রাফিক প্রায় ১০ গুণ বাড়িয়ে দেয়। স্বাভাবিক অবস্থায় Copilot Token Service-এ প্রতি সেকেন্ডে ৭ থেকে ৯ হাজার অনুরোধ আসে, সেটি বেড়ে দাঁড়ায় ৭০ হাজার থেকে ১ লাখে। গেটওয়ের আশাবাদী রিট্রাই নীতিও চাপ বাড়িয়েছে।
তাই ইঞ্জিনিয়ারদের গেটওয়ের রিট্রাই সাময়িকভাবে কমাতে হয়েছে এবং Copilot Token Service-এর আগত অনুরোধ লোড ব্যালান্সারেই আটকে ধাপে ধাপে ট্রাফিক ফেরাতে হয়েছে। সেবা ফেরাতে কিছু অনুরোধ ইচ্ছা করে ফিরিয়ে দিতে হয়েছে, বিষয়টা শুনতে উল্টো হলেও বড় সিস্টেমে এটি স্বাভাবিক কৌশল। পাশাপাশি GitHub বলেছে, codeload এন্ডপয়েন্টে কিছু স্ক্র্যাপিং হামলাও পুনরুদ্ধারে বাধা দিয়েছে। প্রতিষ্ঠানটি অটোস্কেলিং নীতি ঠিক করা, সীমাগুলো নিরীক্ষা করা, রিট্রাই ও ব্যাকঅফ পর্যালোচনা, VS Code-এর আচরণ সংশোধন এবং অঞ্চলভিত্তিক ফেইলওভারের সুরক্ষা উন্নত করার কথা জানিয়েছে।
একটি প্ল্যাটফর্মের ওপর ভরসার ঝুঁকি
এই ঘটনাকে বিচ্ছিন্নভাবে দেখলে চলবে না। এপ্রিলে GitHub-এর প্রধান প্রযুক্তি কর্মকর্তা লিখেছিলেন, এজেন্টভিত্তিক ডেভেলপমেন্টের কারণে ডিসেম্বর ২০২৫-এর শেষ থেকে প্ল্যাটফর্মে কাজের চাপ দ্রুত বেড়েছে, আর তারা ১০ গুণ থেকে পরিকল্পনা বাড়িয়ে ৩০ গুণ সক্ষমতার নকশা করছে। একই লেখায় এপ্রিলের দুটি ঘটনার কথাও আছে। ২৩ এপ্রিল merge queue-এর একটি ত্রুটিতে ৬৫৮টি রিপোজিটরির ২,০৯২টি পুল রিকোয়েস্ট আক্রান্ত হয়, আর ২৭ এপ্রিল একটি Elasticsearch ক্লাস্টার ওভারলোড হওয়ায় সার্চনির্ভর অংশগুলো বিঘ্নিত হয়। অর্থাৎ চাপ বাড়ছে, এবং সেটি GitHub নিজেই স্বীকার করছে।
মনে রাখবেন, Git নিজে একটি ডিস্ট্রিবিউটেড ব্যবস্থা। আপনার কম্পিউটারে থাকা ক্লোনে পুরো ইতিহাস থাকে, GitHub বন্ধ থাকলেও আপনি কমিট করতে পারেন। কিন্তু আজকের কাজের ধারা Git-এর ওপর আর থেমে নেই: কোড রিভিউ, ইস্যু, সিআই/সিডি, প্যাকেজ, এআই সহায়ক, এমনকি লগইনও এক জায়গায় জমা হয়েছে। আমাদের মতে, আসল নির্ভরতা Git-এর ওপর নয়, এই চারপাশের সেবাগুলোর ওপর।
বাংলাদেশের ডেভেলপাররা কী শিখবেন
সময়টা লক্ষ করুন। বিভ্রাটটি শুরু হয় বাংলাদেশের সন্ধ্যায়। ইউরোপ বা আমেরিকার ক্লায়েন্টের সঙ্গে কাজ করা ফ্রিল্যান্সার ও আউটসোর্সিং দলগুলোর জন্য এই সময়টা প্রায়ই ডেলিভারির সময়। এর ক্ষতির কোনো হিসাব আমাদের কাছে নেই, তবে কয়েকটি অভ্যাস ঝুঁকি কমাতে পারে।
- স্থানীয় কপি হালনাগাদ রাখুন: নিয়মিত pull করুন, যাতে বিভ্রাটের সময়ও সর্বশেষ কোডে কাজ করতে পারেন।
- গুরুত্বপূর্ণ রিপোজিটরির মিরর রাখুন: GitLab, Bitbucket বা নিজের সার্ভারে একটি স্বয়ংক্রিয় মিরর জরুরি অবস্থায় কাজে দেয়।
- ম্যানুয়াল ডিপ্লয়ের পথ রাখুন: সিআই বন্ধ থাকলে কীভাবে প্রোডাকশনে জরুরি হটফিক্স দেবেন, তা লিখে রাখুন এবং পরীক্ষা করে দেখুন।
- ডিপেন্ডেন্সি ক্যাশ করুন: বিল্ড যদি সরাসরি বাইরের কোনো সংগ্রহশালা থেকে ফাইল নামায়, তবে সেটি একক ঝুঁকি।
- নিজের কোডে রিট্রাই ঠিকভাবে লিখুন: এক্সপোনেনশিয়াল ব্যাকঅফ ব্যবহার করুন, অর্থাৎ প্রথমে ১ সেকেন্ড, তারপর ২, ৪, ৮ সেকেন্ড অপেক্ষা করে চেষ্টা করুন। সঙ্গে এলোমেলো বিরতি (জিটার) যোগ করুন, যাতে সব ক্লায়েন্ট একই মুহূর্তে ফিরে না আসে, আর সর্বোচ্চ চেষ্টার একটি সীমা রাখুন। GitHub-এর ঘটনা দেখায়, সীমাহীন রিট্রাই একটি সমস্যাকে বিপর্যয়ে বদলে দিতে পারে।
- সব সীমা মনিটর করুন: অটোস্কেলিং শুধু মূল সেবা দেখে করলে সহায়ক অংশের সীমা চোখ এড়িয়ে যেতে পারে।
- লগইনের বিকল্প ভাবুন: আপনার প্রতিষ্ঠান যদি SAML বা অন্য একক লগইন ব্যবহার করে, তবে সেই পথ বন্ধ হলে কে কীভাবে জরুরি কাজ করবেন, তা ঠিক করে রাখুন।
- ক্লায়েন্টকে আগে জানান: কোন প্ল্যাটফর্মের ওপর ডেলিভারি নির্ভর করছে, তা চুক্তিতে উল্লেখ করুন এবং GitHub Status নজরে রাখুন।
সব কিছুর বিকল্প রাখা ছোট দলের পক্ষে বাস্তবসম্মত নয়, দরকারও নেই। প্রশ্নটা হলো, একটি দিনের বিভ্রাটে আপনার কোন কাজটি একেবারে থেমে যাবে, আর তার জন্য ন্যূনতম বিকল্প কী। সেই উত্তর শান্ত সময়ে লিখে রাখা, বিভ্রাটের রাতে খোঁজার চেয়ে অনেক সহজ।