GitHub ఆగిపోయినప్పుడు, సాఫ్ట్‌వేర్ డెలివరీ ఆగిపోతుంది: తొమ్మిది గంటల అంతరాయం నుండి కార్యనిర్వాహక పాఠాలు

6 ఆగస్టు 2026న 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 ఇక కేవలం కోడ్ రిపాజిటరీ కాదు. ఇది ఆధునిక సాఫ్ట్‌వేర్ డెలివరీ యొక్క కార్యాచరణ నాడి: కోడ్ నివసించే చోటు, 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 ఏప్రిల్‌లో 26 సంఘటనలు, మేలో 23, జూన్‌లో 23 మరియు జూలైలో 26 నివేదిస్తుంది, మరియు GitHub స్వంత స్థితి పేజీ Actions కోసం 90 రోజుల uptime 99.42 శాతంగా చూపిస్తుంది, ఇది సంస్థలు తమ మొత్తం డెలివరీ గొలుసును ఒకే విక్రేత మీద ఉంచినప్పుడు ఊహించే స్థాయి కంటే గణనీయంగా తక్కువ.

సాంకేతికత మరియు ఆర్కిటెక్చర్ చిక్కులు

ఆర్కిటెక్చర్ పాఠం కప్లింగ్ గురించి. చాలా సంస్థలు నిశ్శబ్దంగా ఒకే విక్రేతకు మూల కోడ్, బిల్డ్, పరీక్ష, డిప్లాయ్‌మెంట్, డాక్యుమెంటేషన్ హోస్టింగ్ మరియు 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 చేయండి. విక్రేత control plane అందుబాటులో లేనప్పుడు self-hosted సామర్థ్యం శాంతియుతంగా క్షీణించేలా రూపొందించండి, self-hosting అంటే స్వాతంత్ర్యమని అనుకోకుండా. చివరగా, మీ తలలో ఉన్న మార్కెటింగ్ గణాంకాల కంటే విక్రేత యొక్క వాస్తవ ప్రచురిత uptimeతో పోల్చి అంతర్గత లభ్యత అంచనాలను సెట్ చేయండి, మరియు దానికి అనుగుణంగా 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.