, ,

క్లౌడ్ డిపెండెన్సీ పారడాక్స్: నమ్మదగిన టెక్నాలజీ ఉన్నా, business continuity కు హామీ ఉండదు

Atlassian, Delta, AWS, Cloudflare, Microsoft లో జరిగిన అంతరాయాలు క్లౌడ్ dependencies గురించి ఏమి చెబుతున్నాయి, uptime కు ఆవల continuity ని ఎలా పరీక్షించాలి.

ఈ భాషల్లో చదవండి: English · తెలుగు · हिन्दी · Français · Español

విషయసూచిక

  1. ఒక సంస్థ సొంత సిస్టమ్‌లు సక్రమంగా ఉన్నా వ్యాపారానికి అంతరాయం కలగవచ్చు
  2. ఐదేళ్ల ముఖ్యమైన అంతరాయాలు
  3. బ్యాకప్‌లు ఉండటానికీ, పనిని తిరిగి పొందడానికీ ఉన్న తేడా: Atlassian
  4. ఉమ్మడి లావాదేవీ సర్వీస్: Change Healthcare
  5. కంప్యూటర్లు తిరిగి పనిచేసినా కార్యకలాపాలు కొనసాగనప్పుడు: CrowdStrike, Delta
  6. ప్రొవైడర్ వెనుక ఉన్న ఒక dependency: Google Cloud, Cloudflare
  7. ఒక భాగం పునరుద్ధరణ అయినా AWS రికవరీ ఎందుకు పూర్తికాలేదు
  8. ఇటీవలి Microsoft 365 సంఘటన అదనంగా ఏమి చెబుతుంది
  9. ప్రమాదం అప్లికేషన్‌లో మాత్రమే కాదు, వ్యాపార ప్రక్రియలో ఉంది
  10. నష్టాలు వాస్తవానికి మనకు ఏమి చెబుతున్నాయి?
  11. ఒక సంస్థ ఇకపై ఏమి భిన్నంగా చేయాలి?
  12. AI కి పరిమితమైన పాత్ర
  13. విశ్వసనీయతను, resilience ను కలిపి కొలవాలి
  14. సూచనలు, మరింత చదవడానికి
నాలుగు క్లౌడ్ ప్రొవైడర్ల డేటా సెంటర్లు, నెట్‌వర్క్ లైన్ల ద్వారా ఒక కార్యాలయం, ఒక ఆసుపత్రి, ఒక విమానాశ్రయం, ఒక గోదాముతో అనుసంధానమై ఉన్న భావనాత్మక చిత్రం. కేంద్ర హబ్ వద్ద ఒక లోపం గుర్తించబడింది. కనిపించే ప్రొవైడర్ గుర్తులు ఉదాహరణలను సూచిస్తాయి, ధ్రువీకరించిన సిస్టమ్ ఆర్కిటెక్చర్‌ను లేదా ఆమోదాన్ని కాదు.

ఐదేళ్ల ప్రధాన టెక్నాలజీ అంతరాయాలు ఉమ్మడి dependencies గురించి, వ్యాపారంపై ప్రభావం గురించి, resilience నిర్ణయాల గురించి ఏమి చెబుతున్నాయి.

ఒక సంస్థ సొంత సిస్టమ్‌లు సక్రమంగా ఉన్నా వ్యాపారానికి అంతరాయం కలగవచ్చు

ఒక సంస్థకు రెండు నెట్‌వర్క్ కనెక్షన్లు, క్లస్టర్డ్ సర్వర్లు, రెప్లికేట్ చేసిన డేటాబేస్‌లు, బ్యాకప్‌లు, ఒక disaster recovery సైట్ ఉన్నాయి. దాని ఇంజనీర్లు తెలిసిన అంతర్గత వైఫల్య పాయింట్లను తొలగించడానికి ఏళ్ల తరబడి కృషి చేశారు. ఆ తర్వాత ఉద్యోగులు ఒక ముఖ్యమైన బాహ్య సర్వీస్‌కు యాక్సెస్ కోల్పోతారు. సంస్థ సొంత పరికరాలు పనిచేస్తున్నాయి, అయినా ఒక ముఖ్యమైన వ్యాపార ప్రక్రియ సాధారణంగా కొనసాగలేకపోతుంది.

క్లౌడ్ కంప్యూటింగ్ విశ్వసనీయతను బలహీనపరిచిందని దీని అర్థం కాదు. చాలా సందర్భాల్లో క్లౌడ్ ప్లాట్‌ఫామ్‌లు, ఒక సంస్థ ఆర్థికంగా సొంతంగా నిర్మించుకోగలిగిన దానికంటే బలమైన availability ని, భద్రతను, ఆపరేషనల్ సామర్థ్యాన్ని అందిస్తాయి. అయితే సిస్టమ్‌లను బాహ్య ప్రొవైడర్‌కు మార్చడం వల్ల, ఏ వైఫల్యాలను కంపెనీ నివారించగలదు, ఏవి నేరుగా తానే రికవర్ చేయగలదు, వేరొకరు సర్వీస్‌ను పునరుద్ధరించే వరకు ఏవి భరించాల్సి ఉంటుంది అనేవి మారతాయి.

ఈ తేడా ముఖ్యం, ఎందుకంటే ఒక వ్యాపార ప్రక్రియ అరుదుగా ఒకే అప్లికేషన్‌పై ఆధారపడుతుంది. ఒక కస్టమర్ ఆర్డర్‌కు ఒక identity సర్వీస్, ఒక payment intermediary, ఒక నెట్‌వర్క్ సెక్యూరిటీ ప్లాట్‌ఫామ్, ఒక డేటా సిస్టమ్ అవసరం కావచ్చు. మిగిలినవి పనిచేస్తున్నా వాటిలో ఏ ఒక్కటైనా అడ్డంకిగా మారవచ్చు.

ప్రశ్న, వ్యాపారాలు క్లౌడ్, software-as-a-service (SaaS, అంటే ఇంటర్నెట్ ద్వారా అందించే సాఫ్ట్‌వేర్ సర్వీస్) ప్రొవైడర్లను నివారించాలా అన్నది కాదు. ముఖ్యమైన సర్వీస్‌లను అందించడానికి అవసరమైన టెక్నాలజీ, సంస్థల పూర్తి గొలుసును వారి business continuity (అంటే అంతరాయం ఎదురైనా వ్యాపార కార్యకలాపాలు కొనసాగేలా చూసే) ప్లాన్‌లు పరిగణనలోకి తీసుకుంటున్నాయా అన్నదే.

ఐదేళ్ల ముఖ్యమైన అంతరాయాలు

కింది సంఘటనలను వాటి నమోదైన పరిణామాల కోసం, భిన్నమైన వైఫల్య విధానాల కోసం ఎంచుకున్నారు. ఇది ఉదాహరణల జాబితా మాత్రమే, ప్రపంచవ్యాప్త అంతరాయాల పూర్తి లెక్క కాదు. వ్యవధులు, ప్రభావాలు వేర్వేరు కొలతలను సూచిస్తాయి. కాబట్టి వాటిని ఒకే గణాంకంగా పోల్చకూడదు.

తేదీసంఘటననమోదైన కార్యకలాపాల లేదా ఆర్థిక ప్రభావంఈ సందర్భం ఏమి చూపిస్తుంది
ఏప్రిల్ 2022Atlassian Cloud775 కస్టమర్లకు చెందిన 883 సైట్‌లు తొలగిపోయాయి, కొన్నింటి పునరుద్ధరణ 14 రోజుల వరకు సాగిందిభారీ స్థాయిలో రికవరీ, సాధారణ failover కంటే భిన్నంగా ఉండవచ్చు Atlassian సమీక్ష
ఫిబ్రవరి 2024Change HealthcareUnitedHealth నివేదించిన ప్రకారం 2024లో ప్రత్యక్ష ప్రతిస్పందన ఖర్చులు $2.2 బిలియన్, Optum Insight వ్యాపార అంతరాయ ప్రభావాలు $867 మిలియన్కీలకమైన లావాదేవీ మధ్యవర్తులు, లేకపోతే వేరువేరుగా ఉండే అనేక సంస్థలను కలుపుతాయి UnitedHealth 2024 Form 10-K
జూలై 2024CrowdStrike సాఫ్ట్‌వేర్ అప్‌డేట్Delta నివేదించిన ప్రకారం సుమారు 7,000 విమానాలు రద్దయ్యాయి, ఆదాయంపై ప్రభావం $380 మిలియన్, అదనపు ఖర్చులు $170 మిలియన్ఉమ్మడి సాఫ్ట్‌వేర్ భాగాలు సుదీర్ఘ కార్యకలాపాల రికవరీకి దారితీయవచ్చు Delta 2024 Form 10-K
జూన్ 2025Google Cloudఉమ్మడి API-నిర్వహణ మౌలిక సదుపాయంలో ప్రారంభమైన విస్తృత సర్వీస్ అంతరాయంగ్లోబల్ policy, control dependencies అనేక సర్వీస్‌లను ప్రభావితం చేయవచ్చు Google Cloud సంఘటన నివేదిక
జూన్ 2025Cloudflareఅనేక ప్రోడక్ట్‌లను ప్రభావితం చేసిన 2 గంటల 28 నిమిషాల అంతరాయాన్ని Cloudflare నివేదించిందిఒక ప్లాట్‌ఫామ్ మరొక ప్రొవైడర్ స్టోరేజ్ సర్వీస్‌పై ఆధారపడవచ్చు Cloudflare జూన్ 2025 postmortem
అక్టోబర్ 2025AWS us-east-1DynamoDB సంబంధిత DNS సమస్యల తర్వాత EC2, load-balancer రికవరీలో ఇబ్బందులు ఎదురయ్యాయిప్రారంభ లోపాన్ని పరిష్కరించినా, ఆధారపడిన అన్ని సర్వీస్‌లు వెంటనే పునరుద్ధరించబడవు AWS సంఘటన నివేదిక
నవంబర్ 2025Cloudflareవ్యాపించిన configuration డేటా వల్ల విస్తృత అంతరాయంఉమ్మడి configuration మార్గాలు ఉమ్మడి ముప్పును సృష్టించవచ్చు Cloudflare నవంబర్ 2025 postmortem
ఫిబ్రవరి 2026Google Vertex AI Gemini APIసుమారు 1 గంట 58 నిమిషాల పాటు API లోపాలు పెరిగాయిAI ఆధారిత అప్లికేషన్‌లు సంప్రదాయ ప్లాట్‌ఫామ్ dependencies ను పంచుకోవచ్చు Google Cloud స్టేటస్ నివేదిక
నవంబర్ 2026Microsoft Exchange Onlineనవంబర్ 12 నుంచి 13 వరకు మెయిల్‌బాక్స్ కనెక్టివిటీ, కొన్ని ఆధారిత Microsoft 365 ఫీచర్లు ప్రభావితమయ్యాయి. Microsoft ప్రాథమిక మూల కారణంగా, ఇంతకు ముందు చేసిన నెట్‌వర్క్ సామర్థ్య అప్‌గ్రేడ్‌ను పేర్కొంది. మొత్తం ఆర్థిక నష్టాలు ధ్రువీకరించబడలేదుప్రోడక్ట్ పేర్లు వేరుగా ఉన్నా, SaaS ఫీచర్లు అంతర్లీన సర్వీస్‌లను పంచుకోవచ్చు Microsoft సంఘటన నివేదికల PennO365 సారాంశం

అంతరాయాలు ఎక్కువగా జరుగుతున్నాయని ఈ పట్టిక మాత్రమే నిరూపించలేదు. వాస్తవానికి Uptime Institute 2025 పరిశోధన, మొత్తం అంతరాయాల తరచుదనం, సాధారణంగా నమోదైన తీవ్రత వరుసగా నాలుగో ఏడాది తగ్గాయని నివేదించింది. పారదర్శకత పరిమితంగా ఉండటం, నమ్మదగిన నివేదికలు తక్కువగా ఉండటం వల్ల అంతరాయ డేటాను సందేహంతో చూడాలని కూడా అది హెచ్చరించింది. Uptime Institute విశ్లేషణ

మరింత ఉపయోగకరమైన పోలిక, ఒక అంతరాయం సాంకేతిక భాగం నుంచి వ్యాపార ప్రక్రియలోకి ఎలా చేరింది, దానిపై ఆధారపడిన వారికి ఎలాంటి రికవరీ సాధ్యంగా మిగిలింది అని అడుగుతుంది.

బ్యాకప్‌లు ఉండటానికీ, పనిని తిరిగి పొందడానికీ ఉన్న తేడా: Atlassian

2022 ఏప్రిల్‌లో, ఒక Atlassian మెయింటెనెన్స్ స్క్రిప్ట్, ఉద్దేశించిన అప్లికేషన్ సమాచారాన్ని మాత్రమే కాకుండా పూర్తి క్లౌడ్ సైట్‌లనే తొలగించింది. Atlassian post-incident review (సంఘటన తర్వాత చేసిన సమీక్ష నివేదిక) 883 సైట్‌లను, ప్రభావితమైన 775 కస్టమర్లను నమోదు చేసింది, చివరి పునరుద్ధరణలు ఏప్రిల్ 18న పూర్తయ్యాయి. కొందరు కస్టమర్లు 14 రోజుల వరకు అంతరాయాన్ని ఎదుర్కొన్నారు. Atlassian సమీక్ష

Atlassian వద్ద రికవరీ యంత్రాంగాలు ఉన్నాయి, కానీ దాని స్థిరపడిన పునరుద్ధరణ ప్రక్రియ వ్యక్తిగత సైట్‌లకు లేదా చిన్న సమూహాలకు సరిపోయేలా ఉండేది. అనుసంధానమైన ప్రోడక్ట్‌లలో వందలాది సైట్‌లను తిరిగి నిర్మించడానికి అదనపు విధానాలు, ఆటోమేషన్ అవసరమయ్యాయి. సైట్ రికార్డులను తొలగించడం వల్ల, కస్టమర్లతో కమ్యూనికేట్ చేయడానికి వాడే సంప్రదింపు, సపోర్ట్ వర్క్‌ఫ్లోలు ఎలా దెబ్బతిన్నాయో కూడా కంపెనీ సమీక్ష వివరిస్తుంది.

అర్థవంతమైన తేడా మూడు ప్రశ్నల మధ్య ఉంది: ఒక భాగం విఫలమైనా మౌలిక సదుపాయం నిలబడగలదా? డేటా రక్షించబడిందా? పూర్తి వ్యాపార సర్వీస్‌ను అవసరమైన స్థాయిలో, అవసరమైన వేగంతో పునరుద్ధరించగలమా? వాటిలో ఒకదానికి అవును అనే సమాధానం ఉంటే, మిగిలినవాటికి హామీ లభించదు.

ఒక కస్టమర్‌కు ఇది, దామాషా ప్రకారం continuity పరీక్షను సూచిస్తుంది. SaaS ప్రోడక్ట్ ఒక రోజు లేదా ఒక వారం అందుబాటులో లేకపోతే ఏ పని ఆగిపోతుందో గుర్తించండి. ముఖ్యమైన పత్రాలు, సంప్రదింపు వివరాలు, ఆమోదాలు, పని సూచనలు ఆమోదిత స్వతంత్ర పద్ధతి ద్వారా అందుబాటులో ఉన్నాయో లేదో నిర్ధారించండి. పూర్తి నకలు SaaS ప్లాట్‌ఫామ్ అవసరం కాకపోవచ్చు. అత్యంత ముఖ్యమైన పనిని కొనసాగించడానికి పరీక్షించిన ఒక మార్గం మరింత ఉపయోగకరంగా ఉండవచ్చు.

ఉమ్మడి లావాదేవీ సర్వీస్: Change Healthcare

2024 ఫిబ్రవరిలో Change Healthcare పై జరిగిన సైబర్ దాడి, ఆరోగ్య సంరక్షణ లావాదేవీ సర్వీస్‌లను అంతరాయపరిచింది. ముప్పును అదుపు చేయడానికి UnitedHealth ప్రభావిత సిస్టమ్‌లను వేరు చేసింది. ఇది ఆ ప్లాట్‌ఫామ్‌పై ఆధారపడిన సంస్థలకు క్లెయిమ్‌లు, చెల్లింపులకు సంబంధించిన వర్క్‌ఫ్లోలు అంతరాయపడటానికి దోహదపడింది. ఇది ఒక సైబర్‌సెక్యూరిటీ సంఘటన, సాధారణ క్లౌడ్ మౌలిక సదుపాయాల అంతరాయం కాదు. UnitedHealth 2024 Form 10-K

తన 2024 వార్షిక ఫైలింగ్‌లో UnitedHealth $2.2 బిలియన్ ప్రత్యక్ష ప్రతిస్పందన ఖర్చులను, Optum Insight లో $867 మిలియన్ అంచనా వ్యాపార అంతరాయ ప్రభావాలను నివేదించింది. 2024 చివరి వరకు సంరక్షణ ప్రొవైడర్లకు $9 బిలియన్ కంటే ఎక్కువ వడ్డీ రహిత రుణాలు ఇచ్చినట్లు కూడా నివేదించింది. ఆ రుణాలను అందించడానికి అయిన ఖర్చులు కూడా ఈ $2.2 బిలియన్ ప్రత్యక్ష ప్రతిస్పందన ఖర్చులలో ఉన్నాయని ఫైలింగ్ చెబుతోంది. రుణాలు ఆర్థిక సహాయాన్ని సూచిస్తాయి, వాటిని సంఘటన నష్టాలకు కలపకూడదు. ఫైలింగ్‌లోని ఆర్థిక వర్గాలను పరిశ్రమ మొత్తం నష్టం అంచనాగా మార్చకూడదు. UnitedHealth 2024 Form 10-K

ఒక మధ్యవర్తి, లేకపోతే స్వతంత్రంగా ఉండే అనేక సంస్థల మధ్య లావాదేవీలకు ఎలా అవసరం కాగలదో ఈ సంఘటన చూపిస్తుంది. వారి సొంత సర్వర్లు, నెట్‌వర్క్‌లు అందుబాటులో ఉండవచ్చు. అయినా అవసరమైన ఒక బాహ్య దశ పూర్తికాకపోవడం వల్ల క్లెయిమ్‌లు, చెల్లింపులు ఆగిపోవచ్చు.

ఆచరణాత్మక అంశం, ప్రతి ఆరోగ్య సంరక్షణ ప్రొవైడర్ తన సొంత లావాదేవీ నెట్‌వర్క్‌ను నిర్వహించాలా అన్నది కాదు. కీలకమైన వ్యాపార ప్రక్రియలను ఆ బాహ్య మధ్యవర్తి ద్వారా మ్యాప్ చేశారా, ప్రత్యామ్నాయ ఏర్పాట్లు ఒప్పందపరంగా, సాంకేతికంగా సాధ్యమేనా, సుదీర్ఘ అంతరాయానికి నగదు ప్రవాహం లేదా manual ప్రక్రియ ఏర్పాట్లు సరిపోతాయా అన్నదే.

కంప్యూటర్లు తిరిగి పనిచేసినా కార్యకలాపాలు కొనసాగనప్పుడు: CrowdStrike, Delta

2024 జూలై 19న, లోపభూయిష్టమైన ఒక CrowdStrike సెక్యూరిటీ కంటెంట్ అప్‌డేట్, Windows సిస్టమ్‌లలో విస్తృత వైఫల్యాలకు దారితీసింది. అంతర్లీన సమస్య ఒక ఉమ్మడి సాఫ్ట్‌వేర్ భాగం, క్లౌడ్ రీజియన్ మొత్తం ఆగిపోవడం కాదు. Delta 2024 Form 10-K

Delta Air Lines ఐదు రోజుల్లో సుమారు 7,000 విమానాల రద్దును, అంచనా వేసిన $380 మిలియన్ ప్రత్యక్ష ఆదాయ ప్రభావాన్ని, సుమారు $170 మిలియన్ అదనపు నిర్వహణ ఖర్చులను వెల్లడించింది. విమానాల రద్దు వల్ల సుమారు $50 మిలియన్ ఇంధన ఖర్చు మిగిలిందని కూడా పేర్కొంది. ఇవి కంపెనీ నివేదించిన వేర్వేరు ఆర్థిక ప్రభావాలు, మొత్తం సంఘటనకు ధ్రువీకరించిన నికర నష్టం లెక్క కాదు. Delta 2024 Form 10-K

ఒక విమానయాన సంస్థ విమానాలను, సిబ్బందిని, ప్రయాణికులను, విమానాశ్రయాలను, షెడ్యూళ్లను సమన్వయం చేయాలి. ఒక కంప్యూటర్‌ను పునరుద్ధరించినంత మాత్రాన ఆ అంశాలన్నీ వెంటనే సరైన కార్యకలాప స్థితికి రావు. ఆలస్యాలు backlog లను సృష్టిస్తాయి, backlog లు అదనపు రికవరీ పనిని సృష్టిస్తాయి.

ఈ తేడా విమానయాన సంస్థలకు మించి వర్తిస్తుంది. పునరుద్ధరించిన ఆర్డర్ సిస్టమ్‌లో ఇంకా సరిపోల్చాల్సిన లావాదేవీలు ఉండవచ్చు. పునరుద్ధరించిన కస్టమర్ సర్వీస్ ప్లాట్‌ఫామ్ పేరుకుపోయిన క్యూను ఎదుర్కోవచ్చు. ఒక ఆసుపత్రి సిస్టమ్‌లో చికిత్సను తిరిగి షెడ్యూల్ చేయాల్సి రావచ్చు. కాబట్టి ఒక సంస్థ టెక్నాలజీ తిరిగి వచ్చే వరకు పట్టే సమయాన్ని మాత్రమే కాకుండా, వ్యాపారం మళ్లీ ఆమోదయోగ్యమైన సర్వీస్ ఇవ్వగలిగే వరకు పట్టే సమయాన్ని కూడా కొలవాలి.

ప్రొవైడర్ వెనుక ఉన్న ఒక dependency: Google Cloud, Cloudflare

2025 జూన్ 12న, ప్రపంచవ్యాప్తంగా పంపిణీ అయ్యే policy సమాచారంలో జరిగిన ఒక మార్పు, Google Cloud API-నిర్వహణ మౌలిక సదుపాయంలోని ఒక సాఫ్ట్‌వేర్ లోపంతో కలిసి ప్రతిస్పందించింది. అనేక Google సర్వీస్‌లు అంతరాయాన్ని ఎదుర్కొన్నాయి. Google సంఘటన నివేదిక చెప్పిన ప్రకారం, కొత్త కోడ్ మార్గంలో error handling, feature-flag రక్షణ లేవు. అందువల్ల సెకన్లలో ప్రపంచమంతా ప్రతిరూపమైన ఖాళీ policy ఫీల్డ్‌లు, ప్రతి రీజియన్‌లో policy-తనిఖీ సర్వీస్ పదేపదే క్రాష్ అయ్యేలా చేశాయి. ఒక kill switch సుమారు 40 నిమిషాల్లో ప్రధాన ప్రభావాన్ని ముగించింది, అయితే us-central1 లో రికవరీకి సుమారు 2 గంటల 40 నిమిషాల వరకు పట్టింది. Google Cloud సంఘటన నివేదిక

అదే రోజు Cloudflare, Workers KV, Access, Gateway, WARP, Turnstile సహా సర్వీస్‌లపై రెండు గంటల 28 నిమిషాల ప్రభావాన్ని నివేదించింది. దాని సొంత టైమ్‌లైన్ కొంచెం ఎక్కువగా, సుమారు రెండు గంటల 36 నిమిషాలు ఉంది. Workers KV వాడే ఒక బాహ్య స్టోరేజ్ dependency వైఫల్యాన్ని దగ్గరి కారణంగా Cloudflare గుర్తించింది. అనేక Cloudflare ప్రోడక్ట్‌లు configuration, authentication లేదా కంటెంట్ డెలివరీ కోసం ఆ సర్వీస్‌పై ఆధారపడ్డాయి. ప్రభావితం కాని ముఖ్యమైన సర్వీస్‌లు, core DNS, CDN కార్యాచరణలో చాలా భాగం సహా, పనిచేస్తూనే ఉన్నాయని కంపెనీ నివేదించింది. Cloudflare జూన్ 2025 postmortem

ఇక్కడ ఒక వ్యాపారం Cloudflare పై ఆధారపడగా, Cloudflare స్వయంగా మరొక మౌలిక సదుపాయ సర్వీస్‌పై ఆధారపడింది. ఆ అంతర్లీన ప్రొవైడర్‌తో వ్యాపారానికి ప్రత్యక్ష సంబంధం ఉండకపోవచ్చు. నేరుగా ఉన్న vendor లను లెక్కించడం, లేదా వేర్వేరు ప్లాట్‌ఫామ్‌లపై అప్లికేషన్‌లను నడపడం, వైఫల్య మార్గాలు స్వతంత్రమని తప్పనిసరిగా నిరూపించదు.

పాఠం ఏమిటంటే, ఒక కీలకమైన వ్యాపార విధికి ముఖ్యమైన స్థాయిలో dependencies ను గుర్తించాలి. ప్రొవైడర్ యొక్క ప్రతి ఫీచర్ విఫలమైందని ఊహించకపోవడం కూడా ముఖ్యం. ఏ సర్వీస్‌లు ప్రభావితమయ్యాయో కచ్చితంగా గుర్తించడం, నిజాయితీగల resilience అంచనాలో భాగం.

ఒక భాగం పునరుద్ధరణ అయినా AWS రికవరీ ఎందుకు పూర్తికాలేదు

2025 అక్టోబర్‌లో, us-east-1 రీజియన్‌లో Amazon DynamoDB కు సంబంధించిన ఒక DNS-నిర్వహణ సమస్య, ఒక ప్రాంతీయ endpoint కు కనెక్షన్‌లను ప్రభావితం చేసింది. ఆ తర్వాత EC2 ఇన్‌స్టెన్స్ ప్రారంభాలు, host నిర్వహణ, Network Load Balancer health check లలో తలెత్తిన సమస్యలను AWS పోస్ట్-ఈవెంట్ నివేదిక వివరిస్తుంది. AWS సంఘటన నివేదిక

ప్రారంభ DynamoDB సమస్య, ఆధారపడిన అన్ని ఆపరేషన్‌లు రికవర్ కాకముందే పరిష్కారమైంది. ఇప్పటికే ఉన్న కొన్ని EC2 ఇన్‌స్టెన్స్‌లు ఆరోగ్యంగా ఉండగా, కొత్తవాటిని ప్రారంభించడం దెబ్బతింది. ఈ తేడా కస్టమర్లు వాస్తవంగా అనుభవించేదాన్ని మారుస్తుంది. తగినంత ఉన్న సామర్థ్యంపై నడిచే workload కొనసాగవచ్చు, అయితే కొత్త ఇన్‌స్టెన్స్‌లు, భర్తీ సామర్థ్యం లేదా కొన్ని నిర్వహణ ఆపరేషన్‌లు అవసరమైనది ఇబ్బంది పడుతుంది.

సంబంధిత ఇంజనీరింగ్ ఆందోళన, అనేక availability zone లు ఉన్నాయా అన్నది మాత్రమే కాదు. ప్రతిపాదిత రికవరీ చర్య, దెబ్బతిని ఉండగల ఒక ఉమ్మడి సర్వీస్‌పై ఆధారపడుతుందా అన్నదే. ఉదాహరణకు, కొత్త సామర్థ్యం అవసరమయ్యే failover ప్లాన్‌ను, ప్రొవిజనింగ్ ఎప్పుడూ విజయవంతమవుతుందని ఊహించకుండా, సామర్థ్యం, control-service పరిమితులకు వ్యతిరేకంగా పరీక్షించాలి.

TechiesJournal లోని క్లౌడ్ కంట్రోల్ ప్లేన్ అంతరాయాలు: సర్వర్లు నడుస్తున్నాయంటే సర్వీస్ పనిచేస్తోందని కాదు ఆ control సర్వీస్‌లు ఎలా విఫలమవుతాయో వివరిస్తుంది. ప్రొవైడర్ తన మౌలిక సదుపాయాన్ని పునరుద్ధరించడానికీ, కస్టమర్ తన వ్యాపార విధిని పునరుద్ధరించడానికీ మధ్య ఉన్న అంతరాన్ని వివరించడానికి అవి ఉపయోగపడతాయి కాబట్టి మాత్రమే అవి ఇక్కడ ముఖ్యమైనవి.

ఇటీవలి Microsoft 365 సంఘటన అదనంగా ఏమి చెబుతుంది

2026 నవంబర్ 12న Microsoft, Outlook on the web ను, అనేక కనెక్షన్ ప్రోటోకాల్‌లను ప్రభావితం చేయగల Exchange Online మెయిల్‌బాక్స్ కనెక్టివిటీ సమస్యలను నివేదించింది. సంఘటన సమయంలో వచ్చిన అప్‌డేట్‌లు, పెద్ద సంఖ్యలో సర్వర్లు ఊహించకుండా అందుబాటులో లేకుండా పోవడం వల్ల లోడ్ మిగిలిన మౌలిక సదుపాయంపైకి మారిందని, ప్రభావిత సర్వర్లపై ఒక core ప్రక్రియ ఓవర్‌లోడ్ అయిందని వివరించాయి. తర్వాతి అప్‌డేట్‌లు, ఒక upstream authentication, routing configuration భాగానికి Microsoft ఒక ప్యాచ్ వర్తింపజేసిన తర్వాత స్థిరత్వం మెరుగుపడుతోందని వివరించాయి. Microsoft సంఘటన నివేదికల PennO365 సారాంశం

నవంబర్ 14 నాటికి, Microsoft University of Pennsylvania యొక్క PennO365 సర్వీస్‌కు పంపిన రికార్డులు రెండు సంఘటనలనూ సర్వీస్ పునరుద్ధరించబడినట్లు చూపించాయి. Microsoft ఒక ప్రాథమిక మూల కారణాన్ని ఇచ్చింది: ఇంతకు ముందు చేసిన నెట్‌వర్క్ సామర్థ్య అప్‌గ్రేడ్ సమయంలో ప్రవేశించిన, ఇటీవలి నెట్‌వర్క్ మార్పు తర్వాత బయటపడిన ఒక సమస్య. ఇది సైబర్‌కు లేదా AI కి సంబంధం లేని సాంకేతిక సమస్య అని, పూర్తి Post-Incident Report తర్వాత వస్తుందని అది చెప్పింది.

Exchange Online పై ఆధారపడిన ఇతర Microsoft 365 ప్రోడక్ట్‌లలోని నిర్దిష్ట కార్యాచరణపై కూడా ప్రభావాలను Microsoft నివేదించింది. అనుసంధానమైన ప్రతి ప్రోడక్ట్ లేదా ప్రతి ఫీచర్ అందుబాటులో లేదని దీని అర్థం కాదు.

సాక్ష్యాల పరిమితి, 2026 నవంబర్ 14న సమీక్షించినది: సమీక్షించిన రికార్డులలో Microsoft అధికారిక మూల-కారణ ఫీల్డ్ ఇంకా ఖాళీగా ఉంది, దాని పూర్తి Post-Incident Report ఇంకా ప్రచురించబడలేదు. కాబట్టి ప్రాథమిక కారణం మారవచ్చు. రెండు సంఘటన రికార్డులు వేర్వేరు ముగింపు సమయాలను కూడా ఇస్తున్నాయి. మొత్తం వ్యాపార ఆర్థిక నష్టాలు ధ్రువీకరించబడలేదు. అందువల్ల ఈ సంఘటన SaaS functional dependencies కు ఇటీవలి ఉదాహరణ మాత్రమే, ఆర్థిక నష్టం వాదనకు లేదా కారణాన్ని నిర్ద్వంద్వంగా ఆపాదించడానికి ఆధారం కాదు.

ప్రమాదం అప్లికేషన్‌లో మాత్రమే కాదు, వ్యాపార ప్రక్రియలో ఉంది

ఈ సందర్భాలన్నీ కలిపి చూస్తే, ముఖ్యమైన పని ఆగిపోవడానికి నాలుగు భిన్న మార్గాలు కనిపిస్తాయి. డేటాను భారీ స్థాయిలో పునరుద్ధరించడం కష్టం కావచ్చు. లావాదేవీ మధ్యవర్తి అందుబాటులో లేకపోవచ్చు. ఉమ్మడి సాఫ్ట్‌వేర్ ఒకేసారి అనేక సంస్థలను అంతరాయపరచవచ్చు. స్వతంత్రంగా కనిపించే ఒక సర్వీస్, మరొక ప్రొవైడర్‌పై లేదా ఉమ్మడి control భాగంపై ఆధారపడి ఉండవచ్చు.

విశ్లేషణకు ఉపయోగకరమైన ప్రమాణం ఒక ముఖ్యమైన వ్యాపార సర్వీస్. ఆన్‌లైన్ చెల్లింపును స్వీకరించే ఒక కంపెనీని ఊహించండి. payment intermediary అందుబాటులో లేనప్పుడు కూడా దాని storefront సక్రమంగా ఉండవచ్చు. లేదా దాని storefront ఆఫ్‌లైన్‌లో ఉన్నా, ఆమోదిత టెలిఫోన్ లేదా manual ప్రక్రియ పరిమితంగా కొంత ముఖ్యమైన వ్యాపారాన్ని కాపాడవచ్చు. రెండు పరిస్థితులలోనూ, అప్లికేషన్ uptime శాతం మాత్రమే కస్టమర్ అనుభవానికి అసంపూర్ణ కొలమానం.

ఒక్క లింక్ తెగితే సక్రమ సర్వీస్ ఆగుతుందిఆన్‌లైన్ చెల్లింపును స్వీకరించే ఒక వ్యాపార సర్వీస్, ఐదు లింక్‌ల గొలుసుపై ఆధారపడుతుంది: స్టోర్‌ఫ్రంట్, ఐడెంటిటీ సర్వీస్, payment intermediary, సెక్యూరిటీ ప్లాట్‌ఫామ్, డేటా సిస్టమ్. నాలుగు లింక్‌లు పనిచేస్తున్నాయి, payment intermediary ఆగిపోయింది. ప్లాన్ లేకపోతే కస్టమర్ చెల్లించలేరు, వ్యాపార సర్వీస్ ఆగిపోతుంది. పరీక్షించిన ప్రత్యామ్నాయం ఉంటే, ఆమోదిత ఫోన్ లేదా మాన్యువల్ ప్రక్రియ తెగిన లింక్‌ను దాటవేస్తుంది, ముఖ్యమైన చెల్లింపులు పరిమితంగా కొనసాగుతాయి. భావనాత్మకం: ఒక లింక్ విఫలమైతే సర్వీస్ ఆగవచ్చు. {“publisher”: “TechiesJournal”, “author”: “Prasad Kukkala”, “asset”: “cloud-dependency-paradox-business-continuity-visual-wf”, “role”: “diagram”, “creator”: “TechiesJournal, authored as programmatic SVG by Claude (AI agent), not a generative image model”, “generation_method”: “AI-assisted programmatic SVG from a shared visual vocabulary (tools/agentic-under-the-hood/vocab.py)”, “source_slug”: “cloud-dependency-paradox-business-continuity”, “source_revision”: “V1.1”, “created”: “2026-11-14”, “rights”: “Copyright 2026 TechiesJournal. All rights reserved.”, “external_licence”: “none, no third-party material”, “watermark”: “visible TechiesJournal wordmark, lower right, part of the SVG”, “language”: “language-neutral (English labels)”, “viewBox”: “0 0 440 336”, “format”: “inline SVG”, “theme”: “light and dark via the theme switch”} ఒక్క లింక్ తెగితే సక్రమ సర్వీస్ ఆగుతుందిసర్వీస్: ఆన్‌లైన్ చెల్లింపు స్వీకరణస్టోర్‌ఫ్రంట్ఐడెంటిటీ సర్వీస్పేమెంట్ ఇంటర్మీడియరీసెక్యూరిటీ ప్లాట్‌ఫామ్డేటా సిస్టమ్పరీక్షించిన ఫాల్‌బ్యాక్‌తోఫోన్ లేదా మాన్యువల్ పద్ధతిముఖ్యమైన చెల్లింపులుకొనసాగుతాయి (కొంతమేర)ప్లాన్ లేకపోతేకస్టమర్ చెల్లించలేరువ్యాపార సర్వీస్ ఆగిందినడుస్తోందిఆగిపోయిందిభావనాత్మకం. ఒక లింక్ విఫలమైతే సర్వీస్ ఆగవచ్చు. TechiesJournal
ఈ చిత్రానికి అందుబాటులో ఉండే టెక్స్ట్ ప్రత్యామ్నాయం

సర్వీస్ ఐదు లింక్‌ల గొలుసు: స్టోర్‌ఫ్రంట్, ఐడెంటిటీ సర్వీస్, payment intermediary, సెక్యూరిటీ ప్లాట్‌ఫామ్, డేటా సిస్టమ్.

నాలుగు లింక్‌లు పనిచేస్తున్నాయి. payment intermediary ఆగిపోయింది.

ప్లాన్ లేకపోతే కస్టమర్ చెల్లించలేరు, వ్యాపార సర్వీస్ ఆగిపోతుంది.

పరీక్షించిన ప్రత్యామ్నాయం ఉంటే, ఆమోదిత ఫోన్ లేదా మాన్యువల్ ప్రక్రియ తెగిన లింక్‌ను దాటవేస్తుంది, ముఖ్యమైన చెల్లింపులు పరిమితంగా కొనసాగుతాయి.

చిత్రం 1. TechiesJournal విశ్లేషణ. ఆన్‌లైన్ చెల్లింపును స్వీకరించడమనే ఒక వ్యాపార సర్వీస్‌ను, dependencies గొలుసుగా చూపించే భావనాత్మక దృశ్యం. payment intermediary తప్ప మిగతా ప్రతి లింక్ పనిచేస్తోంది, అయినా ప్లాన్ లేకపోతే మొత్తం సర్వీస్ ఆగిపోతుంది. పరీక్షించిన ప్రత్యామ్నాయ ప్రక్రియ ముఖ్యమైన చెల్లింపులను పరిమితంగా కొనసాగిస్తుంది.

ఇది కొత్త ఆవిష్కరణ కాదు. స్థిరపడిన contingency, operational-resilience పద్ధతులు ఇప్పటికే సాంకేతిక రికవరీని, కీలకమైన వ్యాపార విధుల కొనసాగింపు నుంచి వేరుగా చూస్తాయి. NIST contingency-planning మార్గదర్శకం, ఆర్థిక రంగ operational-resilience ఫ్రేమ్‌వర్క్‌లు వ్యాపార ప్రభావం, dependencies, రికవరీ ప్రాధాన్యతలు, పరీక్షలను ఒత్తి చెబుతాయి. NIST contingency-planning మార్గదర్శకం Bank of England resilience మార్గదర్శకం

ఆధునిక సంస్థకు మార్పు ఏమిటంటే, ఆ ప్రశ్నలను తాను నేరుగా నిర్వహించని బాహ్య, దిగువ సర్వీస్‌లకు వర్తింపజేయడం.

నష్టాలు వాస్తవానికి మనకు ఏమి చెబుతున్నాయి?

Delta, UnitedHealth ముఖ్యమైన ప్రభావాలను వెల్లడిస్తాయి, కానీ అవి వేర్వేరు ఖర్చు వర్గాలను, చాలా భిన్నమైన వ్యాపార వాతావరణాలను వివరిస్తాయి. ఆ లెక్కలను కలపడం వల్ల ఉపయోగకరమైన అర్థం లేని, ఆకట్టుకునే ఒక సంఖ్య మాత్రమే వస్తుంది.

Uptime Institute విస్తృత సందర్భాన్ని అందిస్తుంది. దాని 2025 వార్షిక అంతరాయ విశ్లేషణలో, తన 2024 సర్వేకు స్పందించినవారిలో 54%, తమ ఇటీవలి ముఖ్యమైన నుంచి తీవ్రమైన అంతరాయానికి $100,000 కంటే ఎక్కువ ఖర్చయిందని చెప్పారు, ఐదుగురిలో ఒకరు (20%) $1 మిలియన్ కంటే ఎక్కువ అని నివేదించారు. ఇవి ఎంపిక చేసిన ప్రభావవంతమైన అంతరాయాల గురించి సర్వే స్పందనలు, ఆ మొత్తాలను మించిన అన్ని క్లౌడ్ అంతరాయాల వాటా కాదు. అంతరాయాల కొలత అసంపూర్ణమని కూడా నివేదిక హెచ్చరిస్తుంది. Uptime Institute విశ్లేషణ

బదులుగా, ఒక కంపెనీ సొంత నిర్ణయం, ఒక వ్యాపార సర్వీస్‌ను ఒక గంట, ఒక రోజు లేదా అనేక రోజులు కోల్పోతే కలిగే సంభావ్య పర్యవసానంతో మొదలవ్వాలి. అది ఆగిపోయిన లావాదేవీలను, సిబ్బంది ఉత్పాదకతను, కస్టమర్‌కు జరిగే హానిని, నియంత్రణ బాధ్యతలను, నగదు ప్రవాహాన్ని, రికవరీ ఖర్చులను, సర్వీస్ పునరుద్ధరణ తర్వాత పేరుకుపోయిన backlog ను పరిగణనలోకి తీసుకోవాలి. కంపెనీ వద్ద సమర్థించుకోదగిన అంచనాలు లేనప్పుడు, వాటిని ప్రచురించిన నష్ట గణాంకాలుగా కాకుండా scenario లుగా పేర్కొనాలి.

ఒక సంస్థ ఇకపై ఏమి భిన్నంగా చేయాలి?

సరైన ప్రతిస్పందనకు ప్రతి టెక్నాలజీ ప్లాట్‌ఫామ్‌ను నకలు చేయాల్సిన అవసరం లేదు. వ్యాపారం భరించలేని అంతరాయానికి తగినట్లుగా రక్షణను సరిపోల్చడం అవసరం.

మొదట, కేవలం అప్లికేషన్‌ను కాకుండా, ముఖ్యమైన వ్యాపార సర్వీస్‌కు పేరు పెట్టండి. తర్వాత దాన్ని అందించడానికి అవసరమైన సిస్టమ్‌లను, బాహ్య ప్రొవైడర్లను, identity సర్వీస్‌లను, డేటా మూలాలను, లావాదేవీ మధ్యవర్తులను గుర్తించండి. వాటిలో ఏ dependencies పైకి స్వతంత్రంగా కనిపించే కార్యకలాపాల మధ్య ఉమ్మడిగా ఉన్నాయో నమోదు చేయండి.

తర్వాత, ఆమోదయోగ్యమైన అంతరాయాన్ని, కనీస సర్వీస్ స్థాయిని నిర్వచించండి. ఒక అంతర్గత knowledge సైట్ ఒక రోజు అంతరాయాన్ని తట్టుకోగలదు, కానీ ఒక చెల్లింపు లేదా అత్యవసర కమ్యూనికేషన్ విధి తట్టుకోలేదు. సమాధానం, టెక్నాలజీ ప్రతిష్ఠను కాకుండా వ్యాపార పర్యవసానాన్ని ప్రతిబింబించాలి.

చివరగా, ఒక నిర్దిష్ట వైఫల్యాన్ని రిహార్సల్ చేయండి. సాధారణ identity లేదా collaboration ప్లాట్‌ఫామ్ అందుబాటులో లేకపోతే సిబ్బంది ఒక స్వతంత్ర అత్యవసర సంప్రదింపు జాబితాను చేరుకోగలరా? వచ్చే లావాదేవీలను సురక్షితంగా క్యూలో ఉంచి, సరిపోల్చగలరా? సాధారణ SaaS ఇంటర్‌ఫేస్ లేకుండా కీలక సమాచారాన్ని తిరిగి పొందగలరా? failover కు కూడా నిలిచిపోగల ఒక control సర్వీస్ అవసరమా? ఈ కసరత్తు, backlog లు, manual పని సహా, వ్యాపార విధి నిజమైన పునరుద్ధరణను కొలవాలి.

కొన్ని రాజీలు ఉన్నాయి. స్వతంత్ర ప్లాట్‌ఫామ్‌లు, బహుళ రీజియన్‌లు, multi-cloud ఆర్కిటెక్చర్‌లు కొన్ని పరస్పర సంబంధమున్న వైఫల్యాలను తగ్గించవచ్చు, కానీ అవి నిర్వహణ ఖర్చును, replication సంక్లిష్టతను, భద్రత బాధ్యతలను కూడా పెంచుతాయి. కొన్నిసార్లు పరీక్షించిన ప్రత్యామ్నాయ వ్యాపార ప్రక్రియ మరింత దామాషా ప్రకారం ఉండే నియంత్రణ. కొన్నిసార్లు ఖర్చు, పర్యవసానాలు గణనీయమైన సాంకేతిక redundancy ని సమర్థిస్తాయి. ఎంపిక, వ్యాపార అవసరాన్ని, వాస్తవిక పరీక్షను అనుసరించాలి.

AI కి పరిమితమైన పాత్ర

AI ఆధారిత ఆపరేషనల్ టూల్స్ log విశ్లేషణకు, alert లను సమూహపరచడానికి, పరిశోధన సూచనలకు సహాయపడగలవు. వాటి ప్రకటించిన సామర్థ్యాలు, ప్రధాన సంఘటనల్లో రికవరీని తగ్గిస్తాయనడానికి స్వయంగా సాక్ష్యం కావు. ప్రొడక్షన్‌ను మార్చే ఏ చర్యకైనా ఇప్పటికీ తగిన ధృవీకరణ, అధికారం అవసరం.

AI సర్వీస్‌లు కూడా dependencies గా మారవచ్చు. Cloudflare యొక్క 2025 జూన్ Workers KV సంఘటన సమయంలో Workers AI inference అభ్యర్థనలు విఫలమయ్యాయని Cloudflare నివేదించింది. ఒక ఆధునిక AI ఫీచర్, సంప్రదాయ configuration, ప్లాట్‌ఫామ్ మౌలిక సదుపాయంపై ఆధారపడటానికి ఇది ఒక నిర్దిష్ట ఉదాహరణ. Cloudflare జూన్ 2025 postmortem

అందువల్ల AI కూడా, ఇతర కీలక సర్వీస్‌ల లాగే అదే dependency, continuity అంచనాలో భాగం కావాలి. అది ఒక సంఘటనను పరిశోధించే బృందం సామర్థ్యాన్ని మెరుగుపరచవచ్చు, కానీ స్వతంత్ర కమ్యూనికేషన్‌ల అవసరాన్ని, రికవరీ పరీక్షల అవసరాన్ని, సరైన ఆపరేటింగ్ నియంత్రణల అవసరాన్ని తొలగించదు.

విశ్వసనీయతను, resilience ను కలిపి కొలవాలి

క్లౌడ్ సర్వీస్‌లు గణనీయమైన విశ్వసనీయత, రికవరీ సామర్థ్యాలను మరిన్ని సంస్థలకు అందుబాటులోకి తెచ్చాయి. ఈ సమీక్షలోని సంఘటనలు, మౌలిక సదుపాయాన్ని అవుట్‌సోర్స్ చేయడం వల్ల వ్యాపారం తక్కువ విశ్వసనీయంగా మారుతుందని నిరూపించవు, బహుళ ప్రొవైడర్లను నడపడం ఎల్లప్పుడూ మెరుగైనదని కూడా స్థాపించవు.

అయితే ప్లాట్‌ఫామ్ uptime, business continuity వేర్వేరు ఫలితాలు ఎందుకో అవి చూపిస్తాయి. ఒక సర్వీస్‌ను redundancy తో రూపొందించినా, ఉమ్మడి configuration వైఫల్యం ఎదురవ్వవచ్చు. ఒక ప్రొవైడర్ తన సాంకేతిక సిస్టమ్‌లను పునరుద్ధరించినా, దాని కస్టమర్లు ఇంకా వ్యాపార ప్రక్రియలను పునరుద్ధరించుకుంటూ ఉండవచ్చు. ఒక సంస్థ అసలు లోపాన్ని తప్పించుకున్నా, ఒక ముఖ్యమైన మధ్యవర్తి అందుబాటులో లేకపోవడం వల్ల పర్యవసానాలు ఎదుర్కోవచ్చు.

కాబట్టి ఉపయోగకరమైన resilience ప్లాన్, కొనసాగాల్సిన వ్యాపార సర్వీస్‌తో మొదలై, సంస్థ సొంత నెట్‌వర్క్‌కు ఆవల దాని dependencies ను అనుసరించి, అంతరాయం సమయంలో వాస్తవంగా ఏమి పనిచేయగలదో పరీక్షిస్తుంది. ప్రతి dependency ని తొలగించడానికి ప్రయత్నించే బదులు, వ్యాపార ప్రభావం ఖర్చును సమర్థించే చోట స్వతంత్రత కోసం ఖర్చు పెడుతుంది.

నమ్మదగిన టెక్నాలజీ వ్యాపారం నడవడానికి సహాయపడుతుంది. వ్యాపార resilience కు, ఆ టెక్నాలజీ అందుబాటులో లేనప్పుడు ఏమి చేయాలో చెప్పే ప్లాన్ కూడా అవసరం.

సూచనలు, మరింత చదవడానికి

మూలాలను 2026 నవంబర్ 14న చదవడం జరిగింది. Microsoft సంఘటన ఇంకా సమీక్షలో ఉంది, సంఘటన వివరాలు మారవచ్చు.

సవరణను తెలియజేయండి

సవరణలు ఎడిటర్‌కు చేరుతాయి; అవి ఎప్పుడూ ఆటోమేటిక్‌గా ప్రచురించబడవు. ఖాతా అవసరం లేదు.