যখন GitHub থেমে যায়, সফটওয়্যার ডেলিভারি থেমে যায়: নয় ঘণ্টার বিঘ্ন থেকে নির্বাহী শিক্ষা

৬ আগস্ট ২০২৬-এ ১৫:২২ UTC-এ, GitHub, GitHub Actions-এর জন্য মন্দ প্রদর্শনের খবর দেওয়া শুরু করে — এটি সেই স্বয়ংক্রিয় সেবা যা লক্ষ লক্ষ সংস্থার জন্য সফটওয়্যার তৈরি, পরীক্ষা ও শিপ করে। কয়েক ঘণ্টার মধ্যে এই বিঘ্ন GitHub Pages, Actions REST API, Copilot code review, Copilot coding agent, hosted ও self-hosted runners, webhook ডেলিভারি এবং GitHub Enterprise Importer migrations পর্যন্ত ছড়িয়ে পড়ে। GitHub ৭ আগস্ট ০০:০৬ UTC-এ, শুরু হওয়ার প্রায় নয় ঘণ্টা পর, মন্দ পরিস্থিতি নিয়ন্ত্রণাধীন বলে ঘোষণা করে। কার্যদিবসের বেশিরভাগ সময় জুড়ে, বিশ্বের সফটওয়্যার ডেলিভারি সামর্থ্যের একটি উল্লেখযোগ্য অংশ ব্যাহত হয়।

এটি এখন কেন গুরুত্বপূর্ণ

GitHub এখন আর শুধু একটি কোড রিপোজিটরি নয়। এটি আধুনিক সফটওয়্যার ডেলিভারির পরিচালন স্নায়ু: যেখানে কোড থাকে, যেখানে continuous integration চলে, যেখানে deployments শুরু হয় এবং ক্রমশ যেখানে AI coding agents তাদের কাজ করে। যখন Copilot code review ও Copilot coding agent, Actions-এর পাশাপাশি অফলাইনে চলে যায়, তখন যে সংস্থাগুলি তাদের ডেলিভারি প্রক্রিয়ায় AI সহায়তা বুনিয়েছিল, তারা pipelines থেমে যাওয়ার সেই মুহূর্তেই সেই সামর্থ্য হারায়। আমরা যত বেশি উন্নয়ন, স্বয়ংক্রিয়করণ ও AI টুলিং একই প্ল্যাটফর্মে কেন্দ্রীভূত করি, একটি একক ঘটনা তত বেশি অর্থনীতি-ব্যাপী ঘটনার মতো আচরণ করে।

কী ঘটেছে

GitHub-এর সরকারি স্ট্যাটাস পৃষ্ঠা অনুযায়ী, অন্তর্নিহিত ব্যর্থতায় runners-এ অবৈধ কাজের বরাদ্দ পাওয়া জড়িত ছিল, আর self-hosted runners কাজ তুলতে ব্যর্থ হয় এবং নিবন্ধনের সময় ত্রুটি ও rate limiting-এর সম্মুখীন হয়। Workflow runs শুরু বা সম্পূর্ণ হতে ব্যর্থ হয়, সারিতে থাকা কাজগুলির সময় শেষ হয়, Actions REST API ত্রুটি ফেরত দেয়, এবং webhook দ্বারা চালিত workflows বিলম্বিত হয়। পুনরুদ্ধারের জন্য সিস্টেমজুড়ে জমে থাকা সারিগুলি খালি করা, runner কাজের বরাদ্দের জন্য সংশোধন মোতায়েন করা, webhook-চালিত workflow থ্রুপুট পুনরুদ্ধার করা এবং self-hosted runners ধাপে ধাপে পুনরায় সক্রিয় করা প্রয়োজন ছিল। GitHub এখনও বিস্তারিত মূল কারণ বিশ্লেষণ প্রকাশ করেনি। এই ঘটনাটি নির্ভরযোগ্যতা ঘটনার এক কঠিন ধারাবাহিকতার পরে আসে: The Register এপ্রিলে ২৬টি, মে মাসে ২৩টি, জুনে ২৩টি এবং জুলাইয়ে ২৬টি ঘটনার খবর দেয়, এবং GitHub-এর নিজস্ব স্ট্যাটাস পৃষ্ঠা Actions-এর জন্য ৯০ দিনের আপটাইম ৯৯.৪২ শতাংশ দেখায়, যা সেই স্তরের চেয়ে উল্লেখযোগ্যভাবে কম যা উদ্যোগগুলি তাদের সম্পূর্ণ ডেলিভারি চেইন একজন বিক্রেতার উপর রাখলে প্রত্যাশা করে।

প্রযুক্তি ও আর্কিটেকচার সংক্রান্ত প্রভাব

আর্কিটেকচারের শিক্ষা হলো coupling সম্পর্কে। অনেক উদ্যোগ নীরবে একজন বিক্রেতাকে সোর্স কোড, বিল্ড, পরীক্ষা, ডিপ্লয়মেন্ট, ডকুমেন্টেশন হোস্টিং এবং AI সহায়তার জন্য control plane হয়ে উঠতে দিয়েছে। এর প্রতিটি আলাদাভাবে যুক্তিসিদ্ধ। একসাথে এগুলি এমন একটি নির্ভরতা গ্রাফ তৈরি করে যেখানে একটি ব্যর্থ scheduler ডাউনস্ট্রিম সবকিছু থামিয়ে দেয়। বিশেষত, self-hosted runners, যেগুলি অনেক দল বিশেষভাবে GitHub-এর অবকাঠামোর উপর নির্ভরশীলতা কমাতে চালায়, সেগুলিও ব্যাহত হয়, কারণ সেগুলি কাজের বরাদ্দ ও নিবন্ধনের জন্য এখনও GitHub-এর control plane-এর উপর নির্ভর করে। নিজস্ব compute থাকার অর্থ নিজস্ব প্রাপ্যতা থাকা নয়। আর্কিটেক্টদের ম্যাপ করা উচিত কোন সামর্থ্যগুলি একসাথে ব্যর্থ হয়, অক্ষম অপারেশনের পদ্ধতি নির্ধারণ করা উচিত, এবং নিশ্চিত করা উচিত যে প্রাথমিক প্ল্যাটফর্মের মধ্য দিয়ে না যায় এমন জরুরি ডিপ্লয়মেন্ট পথ বিদ্যমান।

ব্যবসায়িক ও প্রতিযোগিতামূলক প্রভাব

নয় ঘণ্টার pipeline বিঘ্ন কোনো প্রকৌশল অসুবিধা নয়। এটি স্থগিত রিলিজ, বিলম্বিত সমাধান, নিষ্ক্রিয় দল এবং, গ্রাহকমুখী পরিবর্তন ক্রমাগত শিপ করা প্রতিষ্ঠানগুলির জন্য, সরাসরি ব্যবসায়িক প্রভাব। প্রতিযোগিতামূলক কোণও ততটাই বাস্তব: পরীক্ষিত ফলব্যাক পথযুক্ত সংস্থাগুলি অন্যরা অপেক্ষা করার সময়ও শিপ করতে থাকে। ডেলিভারি চেইনের নির্ভরযোগ্যতা নিজে থেকেই একটি পার্থক্যকারী উপাদান হয়ে উঠছে, এবং প্রভাবশালী কণ্ঠস্বরগুলি ইতিমধ্যেই প্ল্যাটফর্ম নির্ভরশীলতা নিয়ে প্রশ্ন তুলছে। The Register ডেভেলপার Mitchell Hashimoto-কে উদ্ধৃত করে যে GitHub এখন আর ডেভেলপারদের গুরুতর কাজ হোস্ট করার জায়গা নয়। একমত হোক বা না হোক, প্রভাবশালী প্রকৌশলীদের মধ্যে এই অনুভূতি নিজেই এমন একটি সংকেত যা বোর্ডগুলির নথিভুক্ত করা উচিত।

ঝুঁকি ও গভর্ন্যান্স বিবেচনা

বেশিরভাগ এন্টারপ্রাইজ ঝুঁকি রেজিস্টার GitHub-কে গুরুত্বপূর্ণ অবকাঠামো নয়, একটি উন্নয়ন টুল হিসেবে বিবেচনা করে। এই ঘটনা পুনঃশ্রেণীবিভাগের জন্য যুক্তি সরবরাহ করে। গভর্ন্যান্সের প্রশ্ন স্বাভাবিকভাবেই আসে। ডেলিভারি প্ল্যাটফর্ম অফলাইনে গেলে তার প্রকৃত পুনরুদ্ধার সময় কত, তা কি সংস্থাটি জানে? AI coding agents এবং স্বয়ংক্রিয় পর্যালোচনা ধাপগুলিকে কি পরিবর্তন ব্যবস্থাপনায় ব্যর্থতার একক বিন্দু হতে দেওয়া হয়েছে? নিয়ন্ত্রক বাধ্যবাধকতা, বিশেষত operational resilience কাঠামোর অধীনে আর্থিক পরিষেবায়, কি সফটওয়্যার ডেলিভারি চেইন পর্যন্ত বিস্তৃত? এবং উৎস, বিল্ড, ডিপ্লয়মেন্ট ও AI টুলিং-এর জন্য এক সরবরাহকারীর সাথে কেন্দ্রীকরণ কি বিক্রেতা কৌশলে ঝুঁকি হিসেবে অন্তর্ভুক্ত করা হয়েছে, নাকি এটি ডিফল্টরূপে জমে উঠেছে?

CEO-দের কী করা উচিত

প্রথমত, আপনার প্রযুক্তি নেতৃত্বকে একটি প্রশ্ন জিজ্ঞাসা করুন: GitHub বা তার সমতুল্য কিছু সারাদিন অফলাইনে থাকলে গ্রাহকদের প্রতি আমাদের প্রতিশ্রুতির কী হয়। আশ্বাসের পরিবর্তে স্পষ্ট, প্রমাণসহ উত্তর চান। দ্বিতীয়ত, ডেভেলপার প্ল্যাটফর্ম নির্ভরশীলতাকে সরবরাহকারী কেন্দ্রীকরণ ঝুঁকি হিসেবে বিবেচনা করুন এবং cloud কেন্দ্রীকরণের মতোই বোর্ড দৃশ্যমানতা দিন। তৃতীয়ত, স্থিতিস্থাপকতার কাজের জন্য স্পষ্টভাবে অর্থ বরাদ্দ করুন। ফলব্যাক পথ, mirrored রিপোজিটরি এবং অনুশীলনকৃত অক্ষম পদ্ধতি হলো বীমা প্রিমিয়ামের মতো, এবং সেগুলি সবসময়ই সেই বিঘ্নের চেয়ে সস্তা যা সেগুলির অনুপস্থিতি প্রমাণ করে।

CTO-দের কী করা উচিত

আপনার ডেলিভারি প্ল্যাটফর্মের blast radius সৎভাবে ম্যাপ করুন, যার মধ্যে এখন পর্যালোচনা ও কোডিং workflows-এ এম্বেড করা AI টুলও রয়েছে। আপনার সবচেয়ে গুরুত্বপূর্ণ পরিষেবাগুলির জন্য একটি স্বাধীন জরুরি ডিপ্লয়মেন্ট পথ বজায় রাখুন এবং ত্রৈমাসিকভাবে অনুশীলন করুন। নিয়মিতভাবে সোর্স কোডকে গৌণ স্থানে mirror করুন। Self-hosted সামর্থ্য এমনভাবে ডিজাইন করুন যাতে বিক্রেতার control plane অনুপলব্ধ হলে তা শান্তিপূর্ণভাবে ক্ষয়প্রাপ্ত হয়, self-hosting মানেই স্বাধীনতা ধরে না নিয়ে। অবশেষে, আপনার মাথায় বসে থাকা মার্কেটিং পরিসংখ্যানের পরিবর্তে বিক্রেতার প্রকৃত প্রকাশিত আপটাইমের বিপরীতে অভ্যন্তরীণ প্রাপ্যতার প্রত্যাশা নির্ধারণ করুন এবং সেই অনুযায়ী error budgets তৈরি করুন।

কৌশলগত উপসংহার

এই বিঘ্ন কয়েক দিনের মধ্যে শিরোনাম থেকে অদৃশ্য হয়ে যাবে। যে নির্ভরশীলতা এটি উন্মোচন করেছে, তা অদৃশ্য হবে না। দিকটি কম নয়, বরং বেশি কেন্দ্রীকরণের দিকে: AI agents ডেলিভারি প্রক্রিয়ার আরও বেশি অংশ নেবে, এবং সেগুলি এই সপ্তাহে যে প্ল্যাটফর্মগুলি ব্যর্থ হয়েছিল সেগুলির উপরই চলবে। নেতাদের এই ঘটনাটিকে একটি বিনামূল্যের stress test হিসেবে বিবেচনা করা উচিত। এটি আপনার সংস্থা সম্পর্কে কী প্রকাশ করেছে তা অধ্যয়ন করুন, শূন্যস্থানগুলি সচেতনভাবে বন্ধ করুন এবং প্ল্যাটফর্ম স্থিতিস্থাপকতাকে জরুরি প্রতিক্রিয়া নয়, প্রযুক্তি কৌশলের একটি স্থায়ী অংশ করুন।

এই সপ্তাহে যখন আপনার ডেলিভারি প্ল্যাটফর্ম নীরব হয়ে গেল, আপনার সংস্থা কি শিপ করতে থেকেছিল, নাকি এটি এমন একটি ব্যর্থতার একক বিন্দু আবিষ্কার করেছিল যা কখনও মূল্যায়ন করা হয়নি। আপনার দলগুলি এটি কীভাবে মোকাবিলা করেছে তা শুনতে আমি আগ্রহী।

গাণিতিকভাবে চিন্তা করুন। বুদ্ধিমত্তার সাথে ইঞ্জিনিয়ার করুন। কৌশলগতভাবে নেতৃত্ব দিন। দায়িত্বের সাথে তৈরি করুন। বিশ্বব্যাপী সম্প্রসারণ করুন। কৃত্রিম বুদ্ধিমত্তার মাধ্যমে প্রকৃত ব্যবসায়িক মূল্য তৈরি করুন।

#GitHub #DevOps #EnterpriseArchitecture #TechnologyStrategy #BusinessContinuity #PlatformEngineering #ArtificialIntelligence #RiskManagement #CTO #CEO

Originally published on LinkedIn by Keshavan Thiagaraja. Read the original on LinkedIn.