GitHub நின்றால், மென்பொருள் வழங்கலும் நிற்கும்: ஒன்பது மணி நேர இடையூறிலிருந்து நிர்வாகப் பாடங்கள்

2026 ஆகஸ்ட் 6 அன்று 15:22 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, ஆகஸ்ட் 7 அன்று 00:06 UTC-இல், தொடங்கிய சுமார் ஒன்பது மணி நேரத்திற்குப் பிறகு, சீர்குலைவு தணிக்கப்பட்டதாக அறிவித்தது. ஒரு பணிநாளின் பெரும் பகுதிக்கு, உலகின் மென்பொருள் வழங்கல் திறனின் குறிப்பிடத்தக்க பங்கு பாதிக்கப்பட்டது.

இது ஏன் இப்போது முக்கியம்

GitHub இனி வெறும் கோப்பு களஞ்சியம் (code repository) அல்ல. இது நவீன மென்பொருள் வழங்கலின் இயக்க தளம்: குறியீடு வாழும் இடம், continuous integration இயங்கும் இடம், deployment-கள் தொடங்கப்படும் இடம், மேலும் பெருகிய வகையில், AI coding agents தங்கள் பணியைச் செய்யும் இடம். Copilot code review மற்றும் Copilot coding agent, Actions-உடன் சேர்ந்து செயலிழந்தபோது, தங்கள் வழங்கல் செயல்முறையில் AI உதவியை இணைத்திருந்த நிறுவனங்கள், தங்கள் pipeline-களை இழந்த அதே தருணத்தில் அந்தத் திறனையும் இழந்தன. மேம்பாடு, தன்னியக்கம் மற்றும் AI கருவிகளை ஒரே தளத்தில் நாம் அதிகம் ஒருங்கிணைக்கும்போது, ஒரு தனி சம்பவம் பரவலான பொருட்சார் நிகழ்வு போல நடந்துகொள்கிறது.

என்ன நடந்தது

GitHub-இன் அதிகாரப்பூர்வ நிலைப் பக்கத்தின்படி, முக்கியத் தோல்வி runners-க்கு தவறான job ஒதுக்கீடுகள் கிடைப்பதை உள்ளடக்கியது; அதே நேரத்தில் self-hosted runners வேலைகளை எடுக்கத் தவறி, பதிவின் போது பிழைகள் மற்றும் rate limiting-ஐ எதிர்கொண்டன. Workflow run-கள் தொடங்கவோ முடிக்கவோ தவறின, வரிசையில் காத்திருந்த வேலைகள் காலாவधியாயின, Actions REST API பிழைகளை வழங்கியது, மற்றும் webhook மூலம் தொடங்கப்பட்ட workflow-கள் தாமதமாயின. மீட்க, கணினியெங்கும் பாக்கி இருந்த வரிசைகளை வெளியேற்றுதல், runner job ஒதுக்கீட்டிற்கான திருத்தங்களை பயன்படுத்துதல், webhook மூலம் தொடங்கப்படும் workflow செயல்திறனை மீட்டெடுத்தல் மற்றும் self-hosted runners-ஐ படிப்படியாக மீண்டும் இயக்குதல் தேவைப்பட்டன. GitHub இன்னும் விரிவான மூலக்காரண பகுப்பாய்வை வெளியிடவில்லை. இந்தச் சம்பவம் நம்பகத்தன்மை நிகழ்வுகளின் சிரமமான தொடரைப் பின்தொடர்ந்தது: The Register ஏப்ரலில் 26 சம்பவங்கள், மேயில் 23, ஜூனில் 23 மற்றும் ஜூலையில் 26 என அறிவிக்கிறது; மேலும் GitHub-இன் சொந்த நிலைப் பக்கம் Actions-க்கு 90 நாள் uptime-ஐ 99.42 சதவீதமாகக் காட்டுகிறது, இது நிறுவனங்கள் தங்கள் முழு வழங்கல் சங்கிலியையும் ஒரே விற்பனையாளரிடம் ஒப்படைக்கும்போது எதிர்பார்க்கும் அளவுக்கு முக்கியமாகக் குறைவானது.

தொழில்நுட்பம் மற்றும் கட்டமைப்பு தாக்கங்கள்

கட்டமைப்புப் பாடம் இணைப்பு (coupling) பற்றியது. பல நிறுவனங்கள் ஒரே விற்பனையாளரை மூலக் குறியீடு, உருவாக்கம், சோதனை, deployment, ஆவண ஹோஸ்டிங் மற்றும் AI உதவி ஆகியவற்றின் கட்டுப்பாட்டுத் தளமாக (control plane) மெள்ள அனுமதித்துள்ளன. இவை ஒவ்வொன்றும் தனித்தனியாக நியாயமானவை. ஒன்றாக, ஒரு தோல்வியுறும் scheduler பின்னோக்கி உள்ள அனைத்தையும் நிறுத்திவிடும் சார்பு வரைபடத்தை அவை உருவாக்குகின்றன. குறிப்பாக, GitHub-இன் உள்கட்டமைப்பு மீதான சார்பைக் குறைக்கவே பல குழுக்கள் இயக்கும் self-hosted runners கூட பாதிக்கப்பட்டன, ஏனெனில் அவை job ஒதுக்கீடு மற்றும் பதிவுக்கு இன்னும் GitHub-இன் control plane-ஐயே சார்ந்திருக்கின்றன. உங்கள் சொந்த கணிமியை (compute) வைத்திருப்பது என்பது உங்கள் கிடைக்கும் தன்மையை (availability) வைத்திருப்பது அல்ல. கட்டமைப்பாளர்கள் எந்தத் திறன்கள் ஒன்றாகத் தோல்வியடைகின்றன என்பதை வரைபடமாக்கி, சீர்குலைந்த இயக்க முறைகளை வரையறுத்து, முதன்மைத் தளம் வழியாகச் செல்லாத அவசர deployment பாதைகள் உள்ளன என்பதை உறுதி செய்ய வேண்டும்.

வணிகம் மற்றும் போட்டி தாக்கங்கள்

ஒன்பது மணி நேர pipeline இடையூறு ஒரு பொறியியல் சிரமம் அல்ல. இது ஒத்திவைக்கப்பட்ட வெளியீடுகள், தாமதமான திருத்தங்கள், சும்மா இருக்கும் குழுக்கள் மற்றும் வாடிக்கையாளரை நேரடியாகச் சந்திக்கும் மாற்றங்களைத் தொடர்ந்து வழங்கும் நிறுவனங்களுக்கு நேரடி வணிகத் தாக்கம். போட்டிக் கோணமும் அதே அளவுக்கு உண்மையானது: சோதிக்கப்பட்ட மாற்றுப் பாதைகள் கொண்ட நிறுவனங்கள் மற்றவர்கள் காத்திருக்கும்போது வழங்கிக் கொண்டிருந்தன. வழங்கல் சங்கிலியின் நம்பகத்தன்மை தனித்துவமான வேறுபடுத்திகாரணியாக மாறிவருகிறது; மேலும் முக்கியமான குரல்கள் ஏற்கனவே தளச் சார்பைக் கேள்வி கேட்கின்றன. The Register, டெவலப்பர் Mitchell Hashimoto GitHub-ஐ இனி டெவலப்பர்கள் தீவிரமான வேலையை ஹோஸ்ட் செய்யும் இடமாக இல்லை என விவரிப்பதாக மேற்கோள் காட்டுகிறது. ஒருவர் ஒப்புக்கொண்டாலும் இல்லையென்றாலும், செல்வாக்குள்ள பொறியாளர்களிடையே அந்த உணர்வே வாரியங்கள் பதிவு செய்ய வேண்டிய ஒரு சமிக்ஞை.

அபாயங்கள் மற்றும் ஆளுகைக் கருத்துகள்

பெரும்பாலான நிறுவன அபாயப் பதிவுகள் GitHub-ஐ முக்கியமான உள்கட்டமைப்பாக அல்லாமல் ஒரு மேம்பாட்டுக் கருவியாகவே கருதுகின்றன. இந்தச் சம்பவம் மறுவகைப்படுத்தலுக்கான வாதத்தை முன்வைக்கிறது. ஆளுகைக் கேள்விகள் இயல்பாகத் தொடர்கின்றன. வழங்கல் தளம் செயலிழக்கும்போது நிறுவனம் தனது உண்மையான மீட்பு நேரத்தை அறிவதா? AI coding agents மற்றும் தன்னியக்க மதிப்பாய்வுப் படிகள் மாற்று மேலாண்மையில் ஒற்றைத் தோல்விப் புள்ளிகளாக அனுமதிக்கப்படுகின்றனவா? ஒழுங்குமுறைக் கடமைகள், குறிப்பாக operational resilience விதிமுறைகளின் கீழ் நிதிச் சேவைகளில், மென்பொருள் வழங்கல் சங்கிலிக்கு நீண்டு செல்கின்றனவா? மேலும், மூலம், உருவாக்கம், deployment மற்றும் AI கருவிகளை ஒரே வழங்குநரிடம் ஒருங்கிணைப்பதன் அபாயம் விற்பனையாளர் உத்தியில் விலையிடப்பட்டுள்ளதா, அல்லது அது இயல்பாகவே சேர்ந்துவிட்டதா?

CEO-கள் என்ன செய்ய வேண்டும்

முதலில், உங்கள் தொழில்நுட்பத் தலைமையிடம் ஒரு கேள்வி கேளுங்கள்: GitHub, அல்லது அதற்குச் சமமானது, முழு நாளும் செயலிழந்தால், வாடிக்கையாளர்களுக்கான நமது உறுதிமொழிகளுக்கு என்ன ஆகும். ஆறுதல் அளிப்பதற்குப் பதிலாக தெளிவான, ஆதாரமுள்ள பதிலைக் கோருங்கள். இரண்டாவதாக, டெவலப்பர் தளச் சார்பை வழங்குநர் ஒருங்கிணைப்பு அபாயமாகக் கருதி, cloud ஒருங்கிணைப்புக்கு அளிக்கும் அதே வாரிய வெளிப்பாட்டை அதற்கும் கொடுங்கள். மூன்றாவதாக, நம்பகத்தன்மைப் பணிக்கு வெளிப்படையாக நிதி ஒதுக்குங்கள். மாற்றுப் பாதைகள், mirror செய்யப்பட்ட களஞ்சியங்கள் மற்றும் rehearsal செய்யப்பட்ட சீர்குலைந்த முறைகள் ஆகியவை காப்பீட்டுப் பிரீமியங்கள்; அவை எப்போதும் அவற்றின் இல்லாமையை நிரூபிக்கும் இடையூறைவிட மலிவானவை.

CTO-கள் என்ன செய்ய வேண்டும்

உங்கள் வழங்கல் தளத்தின் வெடிப்பு வீச்சை (blast radius) நேர்மையாக வரைபடமாக்குங்கள்; இதில் இப்போது மதிப்பாய்வு மற்றும் குறியீட்டு workflow-களில் பொதிந்துள்ள AI கருவிகளையும் சேர்க்கவும். உங்கள் மிக முக்கியமான சேவைகளுக்கு சுயாதீன அவசர deployment பாதையை பராமரித்து, அதை காலாண்டுக்கொருமுறை rehearsal செய்யுங்கள். வழக்கமான நடைமுறையாக மூலக் குறியீட்டை இரண்டாம் நிலை இடத்திற்கு mirror செய்யுங்கள். Self-hosting என்பது சுயாதீனம் என்று கருதாமல், விற்பனையாளரின் control plane கிடைக்காதபோது self-hosted திறன் மெதுவாகச் சீர்குலையும் வகையில் வடிவமையுங்கள். இறுதியாக, உங்கள் மனதில் உள்ள சந்தைப்படுத்தல் எண்ணிக்கைக்கு அல்ல, விற்பனையாளரின் உண்மையான வெளியிடப்பட்ட uptime-க்கு எதிராக உள் கிடைக்கும் தன்மை எதிர்பார்ப்புகளை அமைத்து, அதற்கேற்ப error budget-களை உருவாக்குங்கள்.

மூலோபாய முடிவு

இந்த இடையூறு சில நாட்களில் தலைப்புச் செய்திகளிலிருந்து மறைந்துவிடும். இது வெளிப்படுத்திய சார்பு மறையாது. பயணத் திசை குறைவான ஒருங்கிணைப்பு அல்ல, அதிகமானது: 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.