Markdown ایڈیشن

AI-translated from English; not yet reviewed by a fluent editor.

# Claude واپس آ گیا ہے، مگر آپ کے کاروبار کو اب بھی بحالی کا منصوبہ درکار ہے

> Claude کا 22 ستمبر کا واقعہ حل ہو چکا ہے۔ یہ عملی رہنما بتاتا ہے کہ AI سروس بند ہونے پر کاروبار محدود خدمت کیسے جاری رکھ سکتے ہیں، نامکمل کام محفوظ رکھ سکتے ہیں اور اپنا زیرِ التوا کام کیسے نمٹا سکتے ہیں۔

By BIG CHANGE Editorial

Published: 2026-09-22T08:51:37.833Z
Updated: 2026-09-22T08:51:37.833Z
Canonical: https://bigchange.ai/blog/claude-outage-ai-business-continuity

![An intact desktop document machine sits beside an open ledger with an orange bookmark and an orderly stack of folders.](https://bigchange.ai/api/media/file/preserved-work-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. When an AI service pauses, a business still needs accessible records of unfinished work. The bookmarked ledger represents preserving the stopping place. Conceptual illustration, not evidence of damaged equipment or lost data.

22 ستمبر کو Claude کے متعدد ماڈلز میں خرابیوں کی شرح بڑھ گئی۔ Anthropic کی آخری واقعہ رپورٹ کے مطابق اثرات کا دورانیہ 00:50 سے 02:10 UTC تک، یعنی 80 منٹ تھا۔ واقعے کو 02:35 UTC پر حل شدہ قرار دیا گیا۔ متاثرہ اجزا میں claude.ai، API، Code اور Cowork شامل تھے۔ رپورٹ یہ نہیں کہتی کہ ہر درخواست ناکام ہوئی، اور اس میں بنیادی وجہ کی کوئی شائع شدہ وضاحت بھی نہیں ہے۔ [Anthropic کی واقعے کی رپورٹ](https://status.claude.com/incidents/7g1qpkyz5gxh)

کام کے عمل میں AI استعمال کرنے والے کاروبار کے لیے سروس بحال ہونا مسئلے کا صرف ایک حصہ حل کرتا ہے۔ صارفین کی درخواستیں اب بھی منتظر ہو سکتی ہیں۔ خودکار کوشش جاری ہونے کے دوران کسی نے معاملہ دستی طور پر سنبھالنا شروع کیا ہو سکتا ہے۔ نگران کو جاننا چاہیے کہ کون سا کام دوبارہ شروع ہو سکتا ہے اور کس کام کو پہلے جانچنے کی ضرورت ہے۔

خیالات سوچنے میں مدد دینے والا معاون کبھی کبھار دستیاب نہ ہو تو یہ محض زحمت ہے۔ لیکن جب یہی سروس آنے والے معاملات کی درجہ بندی، جوابات کے مسودے اور ریکارڈ کی تازہ کاری میں مدد دے تو تعطل عملیاتی مسئلہ بن جاتا ہے۔ مفید تیاری ایک مختصر تسلسل منصوبہ ہے جس پر عملہ خود AI سروس تک رسائی کے بغیر بھی عمل کر سکے۔

یہ رہنما ایک فرضی کسٹمر سروس ڈیسک کی مثال سے دکھاتا ہے کہ ایسا منصوبہ کیسے کام کر سکتا ہے۔ طریقہ کار کو اپنانے اور مشق کرنے کی تجاویز دی گئی ہیں؛ یہ نہ BIG CHANGE کا کیا ہوا تجربہ ہے اور نہ اس واقعے سے متاثرہ صارفین کی تفصیل۔

## ایسی خدمت منتخب کریں جسے AI کے بغیر جاری رکھ سکیں

تصور کریں کہ سامان فراہم کرنے والے ایک چھوٹے کاروبار کا معاون، معاونت کے لیے آنے والے پیغامات کی درجہ بندی کرتا اور منظور شدہ مصنوعات کی معلومات سے جوابات تیار کرتا ہے۔ بھیجنے سے پہلے عملہ جوابات کا جائزہ لیتا ہے۔ جوابات کی ذمہ داری لوگوں پر رہنے کے باوجود کاروبار قطار منظم کرنے کے لیے اس نظام پر انحصار کرتا ہے۔

اگر معاون جواب دینا بند کر دے تو منتظم کا پہلا فیصلہ یہ ہے کہ ڈیسک اب بھی کس خدمت کا وعدہ کر سکتا ہے۔ عملہ درخواستیں موصول ہونے کی تصدیق جاری رکھ سکتا ہے اور قریب آتی آخری تاریخ والے معاملات سنبھال سکتا ہے، جبکہ معمول کی مصنوعات سے متعلق وضاحتیں مؤخر کر دے۔ معاون سے باہر اصل پیغامات اور منظور شدہ حوالہ جاتی مواد تک رسائی ضروری ہے۔ ورنہ، “دستی طریقے پر منتقل ہو جائیں” ایسی ہدایت ہے جس پر عمل کرنے کے وسائل موجود نہیں۔

محدود خدمت پہلے سے طے کریں۔ اس شخص کا نام لکھیں جو اسے فعال کر سکتا ہے، وہ کام جو روکنے چاہییں، اور باقی کام سنبھالنے والے عملے کی شناخت کریں۔ جائزے کا وقت مقرر کریں تاکہ عارضی انتظام دوپہر بھر بغیر دوبارہ غور کے جاری نہ رہے۔ صارفین کے لیے اطلاع میں تاخیر اور فوری مدد کا دستیاب راستہ واضح ہو، اور ایسے ہی وعدے کیے جائیں جو ٹیم پورے کر سکے۔

اوورلوڈ سے متعلق Google کی انجینئرنگ رہنمائی محدود فعالیت کے ساتھ خدمت جاری رکھنے، ٹریفک محدود کرنے اور وسائل کم ہونے پر اہم درخواستوں کو ترجیح دینے کا ذکر کرتی ہے۔ یہ قابلِ اعتماد نظاموں کی معروف تکنیکیں ہیں، اس Claude واقعے کی تشخیص نہیں۔ سروس ڈیسک پر ان کا اطلاق معمول کی کارروائی جاری نہ رہ سکے تو دائرۂ کار دانستہ کم کرنے کی تائید کرتا ہے۔ [Google SRE: اوورلوڈ سے نمٹنا](https://sre.google/sre-book/handling-overload/)

محدود خدمت کے لیے گنجائش کی حد بھی درکار ہے۔ دو افراد خاموشی سے ایسے خودکار نظام کا سارا کام نہیں سنبھال سکتے جو معمول میں کہیں زیادہ درخواستیں نمٹاتا ہو۔ درج کریں کہ وہ کتنا کام کر سکتے ہیں، کیا انتظار کرے گا، اور اضافی مدد کب ضروری ہو گی۔ صارفین کے لیے قابلِ اعتبار جوابی مدت، ایسی خودکار تصدیق سے زیادہ مفید ہے جو معمول کی خدمت جاری ہونے کا تاثر دے۔

![Two rightward arrows connect a lowered stop lever, a folder under a magnifying glass, and a tray of work beside a raised lever.](/api/media/file/pause-review-restart-inline-v1.png)

## گفتگو سے باہر کام کا ریکارڈ رکھیں

سروس ڈیسک کو ایسے معاملات کا ریکارڈ چاہیے جسے ماڈل دستیاب نہ ہونے پر بھی پڑھا جا سکے۔ یہ موجودہ معاونتی نظام ہو سکتا ہے۔ اہم بات یہ ہے کہ کاروبار یہ معلوم کر سکے کہ کیا ہوا، بغیر اس رکے ہوئے معاون سے اسے دوبارہ تشکیل دینے کو کہے۔

ہر معاملے کے لیے اصل درخواست، ذمہ دار شخص یا عمل، اور آخری تصدیق شدہ کارروائی محفوظ رکھیں۔ محفوظ کیا گیا مسودہ بھیجے گئے جواب سے مختلف ہے۔ صارف کے ریکارڈ میں مجوزہ تبدیلی، اس نظام سے تصدیق شدہ تبدیلی کے برابر نہیں۔ ان میں فرق کرنے کے لیے درکار ثبوت اسی رسائی پابندی کے ساتھ محفوظ کریں جو متعلقہ صارف معلومات پر لاگو ہوتی ہے۔

تعطل کے دوران کام کو ان عملی زمروں میں الگ کریں:

- شروع کرنے کے لیے تیار: کارروائی یا بیرونی عمل ابھی شروع نہیں ہوا۔
- جزوی طور پر تیار: درجہ بندی یا مسودہ موجود ہے، مگر اگلا مرحلہ نامکمل ہے۔
- مکمل ہونے کی تصدیق: منزل کے نظام میں مطلوبہ کارروائی درج ہے۔
- غیر یقینی: کارروائی کی کوشش ہوئی، مگر تصدیق موجود نہیں۔

غیر یقینی معاملات کسی ایسے شخص کو دیں جو انہیں دوبارہ شروع کرنے سے پہلے متعلقہ نظام دیکھ سکے۔ اگر رابطہ ٹوٹنے کے وقت معاون جواب تیار کر رہا تھا تو نیا مسودہ بنانا بے ضرر ہو سکتا ہے۔ لیکن اگر کوئی الگ ٹول وہ جواب بھیج رہا تھا تو پورا کام دہرانے سے جواب دو بار بھیجا جا سکتا ہے۔ یہ فرق ورک فلو کے ریکارڈ میں واضح ہونا چاہیے۔

Anthropic کی API دستاویزات کے مطابق، ابتدائی HTTP 200 کامیابی کے جواب کے بعد بھی اسٹریمنگ جواب ناکام ہو سکتا ہے۔ پہلی عبارت ظاہر ہونا یا ابتدائی اسٹیٹس ملنا اس بات کا ثبوت نہیں کہ پورا جواب پہنچ گیا۔ انٹیگریشن سے کہیں کہ وہ تکمیل کی شناخت کرے اور جزوی کام کو جزوی ہی محفوظ رکھے۔ [Claude API کی خرابیوں سے متعلق دستاویزات](https://platform.claude.com/docs/en/api/errors)

## دوبارہ کوششوں کی حد اور ذمہ دار شخص مقرر کریں

دوبارہ کوشش سے عارضی خرابی دور ہو سکتی ہے۔ لیکن اگر ہر تہہ الگ سے وہی کام دہرائے تو غیر یقینی بڑھ بھی سکتی ہے۔ دوبارہ کوشش کا بٹن یا خودکار چکر شامل کرنے سے پہلے سافٹ ویئر فراہم کنندہ سے پوچھیں کہ آیا اس کی کلائنٹ لائبریری میں پہلے ہی دوبارہ کوششیں ہوتی ہیں۔

Anthropic کے مطابق اس کے سرکاری SDK عارضی خرابیوں پر بطورِ طے شدہ دو خودکار دوبارہ کوششیں کرتے ہیں، وقفہ بتدریج بڑھاتے ہیں اور ہدایت موجود ہو تو retry-after پر عمل کرتے ہیں۔ اس کی خرابیوں کی دستاویزات عارضی سرور مسائل کو تصدیق، اجازت اور غلط ساخت والی درخواستوں کی خرابیوں سے الگ بھی کرتی ہیں۔ یہ فرض نہیں کیا جا سکتا کہ ایک ہی درخواست دہرانے سے ہر قسم کی خرابی دور ہو جائے گی۔ [Claude کے دستاویزی دوبارہ کوشش کے رویے](https://platform.claude.com/docs/en/api/errors)

سروس ڈیسک کے عملی ضابطے میں طے ہو کہ خودکار کوششیں کب رکیں گی اور اس کے بعد معاملہ کس کے حوالے ہو گا۔ مسئلے کی تشخیص کے لیے درخواست کا شناختی نمبر محفوظ رکھیں۔ عملے کو دکھائیں کہ کام منتظر ہے، دوبارہ آزمایا جا رہا ہے یا کسی شخص کی کارروائی کا منتظر ہے، تاکہ وہ انجانے میں متوازی کوششیں شروع نہ کریں۔

AWS وضاحت کرتا ہے کہ جواب کبھی نہ پہنچنے کے باوجود کارروائی کامیاب ہو سکتی ہے۔ اس کے idempotent APIs بار بار آنے والی درخواستوں کی شناخت اور اضافی ضمنی اثرات روکنے کے لیے مخصوص درخواست شناختی نمبر استعمال کرتے ہیں۔ وصول کرنے والی سروس کو اس معاہدے پر عمل کرنا لازم ہے؛ صرف اندرونی کیس نمبر منسلک کرنا ایسا تحفظ فراہم نہیں کرتا۔ [محفوظ دوبارہ کوششوں کے بارے میں AWS](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)

اپنے ورک فلو میں ہونے والی کارروائیوں کے بارے میں خاص طور پر پوچھیں۔ کیا دوبارہ کوشش سے ایک اور معاونتی ٹکٹ بن سکتا ہے یا ایک اور ای میل جا سکتی ہے؟ جہاں نقل ہونے سے روکنے کا طریقہ موجود نہ ہو، اگلی کوشش سے پہلے منصوبے میں منزل کے ریکارڈ کی جانچ شامل کریں۔ عبارت دوبارہ تیار کرنا اور پورا کاروباری عمل دہرانا الگ فیصلے ہیں۔

## متبادل ماڈل کے لیے محدود کام متعین کریں

متبادل AI سروس کام جاری رکھنے میں مدد دے سکتی ہے، مگر دوسرا اکاؤنٹ بنانا متبادل انتظام کا صرف آغاز ہے۔ متبادل سروس کو درست ہدایات، منظور شدہ حوالہ جاتی مواد اور ڈیٹا سنبھالنے کی اجازت درکار ہے۔ کاروبار کو ضرورت پڑنے پر اس میں کافی گنجائش بھی ہونی چاہیے۔

مکمل نظام کی جگہ لینے کی کوشش سے پہلے محدود متبادل کام منتخب کریں۔ ہماری فرضی سروس ڈیسک میں دوسرا ماڈل معمول کے پیغامات کی درجہ بندی کر سکتا ہے جبکہ عملہ صارفین کو بھیجے جانے والے جوابات سنبھالے۔ ٹیم اسے نمائندہ معاملات پر جانچ سکتی ہے، جن میں مبہم مصنوعات کے نام اور کسی شخص کو بھیجی جانے والی درخواستیں شامل ہوں۔ صرف رواں جواب یہ ثابت نہیں کرتا کہ ماڈل نے کمپنی کے معاونتی قواعد پر عمل کیا۔

واقعہ پیش آنے سے پہلے طے کریں کہ متبادل سروس کو کون سی معلومات بھیجی جا سکتی ہیں۔ عملے کو ذاتی اکاؤنٹس میں صارفین کا ریکارڈ چسپاں کرکے خود سے فیصلہ نہیں کرنا چاہیے۔ خریداری کے جائزے میں متبادل سروس کی ڈیٹا سنبھالنے کی شرائط اور رسائی کے انتظامات بھی دیکھیں، ساتھ ہی اس کے جواب کا معیار اور قیمت بھی۔

ماڈل کے مختلف نام بھی دستیابی کی آزادی ثابت نہیں کرتے۔ متبادل اب بھی اسی لاگ اِن، نیٹ ورک کنکشن، دستاویزات کے ذخیرے یا آرکیسٹریشن سافٹ ویئر پر منحصر ہو سکتا ہے۔ نقشہ بنائیں کہ مجوزہ متبادل حقیقت میں کن انحصارات سے بچتا ہے۔ اس مشق سے معلوم ہو سکتا ہے کہ اسی ناکام کنکشن کے پیچھے ایک اور ماڈل کے مقابلے میں، قابلِ رسائی حوالہ جاتی دستاویزات کے ساتھ دستی قطار زیادہ مفید تحفظ دیتی ہے۔

ہدایات بدلنے اور مصنوعات سے متعلق معلومات پرانی ہونے کے ساتھ متبادل نظاموں کی دیکھ بھال ضروری ہے۔ عملے کو ان طریقہ کار کی مشق درکار ہے جو وہ شاذ ہی استعمال کرتے ہیں۔ چھوٹا کاروبار پورا عمل نقل کرنے پر خرچ کرنے کے بجائے معقول طور پر سست دستی خدمت برقرار رکھ سکتا ہے۔ انتخاب میں مؤخر کام کی لاگت اور غلط جواب کے نقصان کو ملحوظ رکھیں۔

## جائزہ شدہ قطار سے کام دوبارہ شروع کریں

فراہم کنندہ کی بحالی کی اطلاع کے بعد معمول کی کارروائی کھولنے سے پہلے اپنے ورک فلو کے چند معاملات آزمائیں۔ ایسا معاملہ شامل کریں جس میں کاروبار کے لیے ضروری دستاویز تلاش اور ریکارڈ کی تازہ کاری ہو۔ ماڈل کا کامیاب جواب یہ ثابت نہیں کرتا کہ ہر منسلک نظام تیار ہے۔

پھر منتظر کام کا جائزہ لیں۔ دستی طور پر نمٹائے گئے معاملات نکالیں، غیر یقینی کارروائیوں کی جانچ کریں اور ان درخواستوں کی شناخت کریں جن کے حالات بدل گئے ہیں۔ تعطل کے دوران صارف نئی معلومات دے سکتا ہے۔ معاملے کے پرانے ورژن سے جواب تیار کرنے سے تکنیکی خرابی ختم ہونے کے بعد نیا مسئلہ پیدا ہو سکتا ہے۔

باقی کام کو قابو میں رکھے گئے مرحلوں میں جاری کریں۔ نئی فوری درخواستوں کے لیے گنجائش رکھیں اور دیکھیں کہ قطار کم ہو رہی ہے یا نہیں۔ اگر آنے والی طلب ساری دستیاب کارروائی کی گنجائش کھا جائے تو ہر نئی کوشش کامیاب ہونے کے باوجود زیرِ التوا کام باقی رہے گا۔ اسے نمٹانے کے لیے اضافی عملہ، عارضی طور پر محدود خدمت یا جوابی مدت میں دیانت دارانہ توسیع درکار ہو سکتی ہے۔

الگ عددی مثال کے طور پر فرض کریں کہ فی گھنٹہ 24 معاملات آتے ہیں اور کارروائی 30 منٹ رک جاتی ہے۔ اس سے 12 معاملات منتظر رہیں گے۔ اگر اس کے بعد ڈیسک فی گھنٹہ 36 معاملات سنبھالے اور ہر گھنٹے 24 نئے معاملات آتے رہیں تو زیرِ التوا کام ختم کرنے میں ایک گھنٹہ لگے گا۔ یہ وضاحتی مفروضے ہیں، Claude واقعے کی پیمائش نہیں۔

سروس لیول مقاصد سے متعلق Google کی رہنمائی صارفین کے لیے اہم نتیجے اور اسے دینے کے لیے درکار انحصارات سے شروع ہوتی ہے۔ اس ڈیسک کے لیے ایک مفید پیمانہ یہ ہو سکتا ہے کہ فوری معاملات میں سے کتنے وعدہ شدہ مدت کے اندر مناسب جواب پاتے ہیں۔ فراہم کنندہ کی دستیابی اہم ہے، مگر کاروبار کو یہ بھی جاننا چاہیے کہ صارفین کو خدمت ملی یا نہیں۔ [Google SRE: سروس لیول مقاصد کا نفاذ](https://sre.google/workbook/implementing-slos/)

معمول کی کسٹمر سروس بحال ہونے کا وقت، حل طلب معاملات کی تعداد اور بعد میں درکار کسی بھی اصلاح کو درج کریں۔ یہ پیمانے بحالی کے اس کام کو ظاہر کرتے ہیں جس کا مشاہدہ فراہم کنندہ کا اسٹیٹس صفحہ نہیں کر سکتا۔

## خودکاری بڑھانے سے پہلے ایک تعطل کی مشق کریں

مختصر ٹیبل ٹاپ مشق حقیقی صارفین کو متاثر کیے بغیر رسائی یا ذمہ داری کے غیر واضح پہلو سامنے لا سکتی ہے۔ معاونت کے چند فرضی معاملات لے کر اس ترتیب پر عمل کریں:

1. فرض کریں کہ جواب تیار کرتے وقت ماڈل دستیاب نہیں رہتا۔ پوچھیں کہ محدود خدمت کون فعال کرے گا اور عملے کو اصل درخواست کہاں ملے گی۔
2. ایک معاملے میں بھیجا گیا جواب تصدیق شدہ رکھیں اور دوسرے میں بھیجنے کی کوشش غیر یقینی۔ جانچیں کہ ٹیم جانتی ہے کہ نتیجے کی تصدیق کون سا نظام کر سکتا ہے۔
3. فرض کریں کہ فراہم کنندہ بحال ہو گیا ہے جبکہ نئے معاملات آتے رہتے ہیں۔ طے کریں کہ کون سا کام پہلے دوبارہ شروع ہو اور دستی طور پر مکمل معاملات زیرِ التوا فہرست سے کیسے نکالے جائیں۔
4. منصوبہ لکھنے والے کے علاوہ کسی شخص سے طریقہ کار سمجھانے اور بتانے کو کہیں کہ اس کے پاس کون سی اجازت یا ریکارڈ موجود نہیں۔

جو سوالات مشق کے دوران جواب طلب رہ گئے انہیں لکھ لیں۔ ممکنہ اصلاحات معمولی ہو سکتی ہیں: موجودہ قطار تک رسائی، واضح توقف کنٹرول، محفوظ تصدیق یا بحالی کا نامزد ذمہ دار۔ ان میں سے کوئی بھی بلا تعطل خدمت کی ضمانت نہیں دیتا۔ لیکن ہر ایک خودکاری کے فوائد ترک کیے بغیر تعطل محدود رکھنے میں مدد دے سکتا ہے۔

معاون کو ایک اور عملیاتی ذمہ داری دینے سے پہلے کسی ساتھی سے دکھانے کو کہیں کہ تعطل کے دوران یہ ذمہ داری کیسے سنبھالی جائے گی۔ اگر جواب اس بات پر منحصر ہو کہ غیر دستیاب معاون کو یاد ہو کہ وہ کیا کر رہا تھا، تو تسلسل کے منصوبے میں ابھی کام باقی ہے۔

## Sources

- [Claude Status: متعدد ماڈلز میں خرابیوں کی شرح بڑھی](https://status.claude.com/incidents/7g1qpkyz5gxh) — فراہم کنندہ کی واقعہ رپورٹ 80 منٹ کا متاثرہ دورانیہ اور بعد کا حل ہونے کا وقت دیتی ہے۔ عوامی JSON الگ سے پڑھا گیا۔ رپورٹ خرابیوں میں اضافے کا ذکر کرتی ہے، ہر درخواست کی ناکامی کا نہیں، اور بنیادی وجہ کی کوئی شائع شدہ وضاحت نہیں دیتی۔
- [Claude Platform: API کی خرابیاں](https://platform.claude.com/docs/en/api/errors) — موجودہ دستاویزات میں خرابیاں، SDK کی طے شدہ دوبارہ کوششیں اور اسٹریمنگ شروع ہونے کے بعد ناکامیاں شامل ہیں۔ یہ طریقے نہ کاروباری کام کی تکمیل ثابت کرتے ہیں اور نہ منسلک ٹولز میں دوہری کارروائی روکتے ہیں۔
- [AWS Builders’ Library: idempotent APIs کے ذریعے دوبارہ کوششیں محفوظ بنانا](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) — غیر یقینی جوابات اور نقل روکنے کے بارے میں Malcolm Featonby کی وضاحت۔ API کے اس معاہدے کو وصول کرنے والی سروس میں نافذ کرنا ضروری ہے؛ صرف شناختی نمبر کافی نہیں۔
- [Google SRE: اوورلوڈ سے نمٹنا](https://sre.google/sre-book/handling-overload/) — محدود فعالیت، ترجیحات اور حدبند دوبارہ کوششوں سے متعلق مستحکم انجینئرنگ رہنمائی۔ مضمون ان اصولوں کو فرضی سروس ڈیسک پر لاگو کرتا ہے؛ یہ Anthropic کے واقعے کی وجہ کی تشخیص نہیں کرتے۔
- [Google SRE Workbook: سروس لیول مقاصد کا نفاذ](https://sre.google/workbook/implementing-slos/) — صارف کے نتائج اور اہم انحصارات پر مبنی قابلِ اعتماد خدمت کے مقاصد کی وضاحت۔ مجوزہ کسٹمر سروس پیمانہ اور زیرِ التوا کام کی مثال وضاحتی اطلاق ہیں، مشاہدہ شدہ نتائج یا عالمگیر ہدف نہیں۔