Markdown आवृत्ती

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

# Claude पुन्हा सुरू झाले; तरी तुमच्या व्यवसायाला पुनर्प्राप्ती योजना हवी

> 22 सप्टेंबरची Claude मधील सेवा-घटना आता सुटली आहे. एआय बंद पडल्यावर मर्यादित सेवा कशी सुरू ठेवावी, अपूर्ण काम कसे जतन करावे आणि स्वतःची प्रलंबित कामे कशी पुन्हा हाताळावीत यासाठीचे व्यावहारिक मार्गदर्शन.

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 सप्टेंबर रोजी अनेक मॉडेल्समध्ये त्रुटींचे प्रमाण वाढले, असे Anthropic ने नोंदवले. कंपनीच्या अंतिम घटना-अद्ययावतात परिणामांचा कालावधी 00:50 ते 02:10 UTC—म्हणजे 80 मिनिटे—असा दिला आहे. 02:35 UTC ला घटना सुटल्याचे चिन्हांकित केले. प्रभावित घटकांत claude.ai, API, Code आणि Cowork यांचा समावेश आहे. प्रत्येक विनंती अयशस्वी झाली असे नोंदीत म्हटलेले नाही; मूळ कारणाचे प्रकाशित स्पष्टीकरणही दिलेले नाही. [Anthropic ची घटना-नोंद](https://status.claude.com/incidents/7g1qpkyz5gxh)

कामाच्या प्रक्रियेत एआय वापरणाऱ्या व्यवसायासाठी सेवा पुन्हा सुरू होणे हा समस्येचा एक भागच सोडवतो. ग्राहकांच्या विनंत्या अजूनही प्रतीक्षेत असू शकतात. स्वयंचलित प्रयत्न सुरू असतानाच एखाद्याने प्रकरण हाताने हाताळायला सुरुवात केली असू शकते. कोणते काम पुन्हा सुरू करावे आणि आधी कोणते तपासावे, हे पर्यवेक्षकाला माहीत हवे.

कल्पना सुचवण्यासाठी सहाय्यक अधूनमधून उपलब्ध नसणे गैरसोयीचे असते. पण तीच सेवा आलेली प्रकरणे वर्गीकृत करत असेल, उत्तरांचे मसुदे बनवत असेल आणि नोंदी अद्ययावत करत असेल, तर व्यत्यय हा कामकाजाचा प्रश्न बनतो. एआय सेवेशिवाय कर्मचाऱ्यांना वापरता येईल अशी छोटी सातत्य-योजना तयार ठेवणे उपयुक्त ठरते.

या मार्गदर्शकात काल्पनिक ग्राहक-सेवा विभाग वापरून योजना कशी काम करू शकते हे दाखवले आहे. येथे दिलेल्या प्रक्रिया जुळवून घेऊन सराव करण्यासाठीचे प्रस्ताव आहेत; BIG CHANGE ने केलेली चाचणी किंवा या घटनेचा फटका बसलेल्या ग्राहकांचे वर्णन नाही.

## एआयशिवाय टिकवता येईल अशी सेवा निवडा

समर्थनासाठी आलेले संदेश वर्गीकृत करून मान्यताप्राप्त उत्पादन-माहितीवरून उत्तरे तयार करणाऱ्या सहाय्यकाची कल्पना करा. पाठवण्याआधी कर्मचारी उत्तर तपासतात. उत्तरे देण्याची जबाबदारी लोकांकडेच असली, तरी कामांची रांग लावण्यासाठी व्यवसाय या प्रणालीवर अवलंबून आहे.

सहाय्यकाने उत्तर देणे थांबवले, तर विभाग कोणती आश्वासने देऊ शकतो हे व्यवस्थापकाने आधी ठरवावे. कर्मचारी विनंती मिळाल्याची पोच देत राहू शकतात आणि जवळची अंतिम मुदत असलेली प्रकरणे हाताळू शकतात; नेहमीची उत्पादन-माहिती काही काळ पुढे ढकलता येईल. सहाय्यकाबाहेर मूळ संदेश आणि मान्यताप्राप्त संदर्भ-माहिती त्यांच्यापर्यंत पोहोचली पाहिजे. नाहीतर “हाताने काम करा” ही कृतीची साधने नसलेली सूचना ठरेल.

सेवा कमी क्षमतेत कधी चालवायची ते आधी ठरवा. ती सुरू करण्याचा अधिकार कोणाला आहे, कोणते काम थांबेल आणि उरलेली कामे कोण करेल हे ठरवा. तात्पुरती व्यवस्था दुपारभर कोणाच्या लक्षात न येता चालू राहू नये म्हणून पुनरावलोकनाची वेळ ठेवा. ग्राहकांना विलंब आणि तातडीच्या मदतीचा उपलब्ध मार्ग कळवताना पथक पूर्ण करू शकेल अशीच आश्वासने द्या.

भारित प्रणालींच्या संदर्भात 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)

## संभाषणाबाहेर कामाची नोंद ठेवा

मॉडेल उपलब्ध नसतानाही वाचता येईल अशी प्रकरण-नोंद सेवा-विभागाला लागते. त्यासाठीची विद्यमान समर्थन-प्रणाली वापरता येईल. व्यत्यय आलेल्या सहाय्यकाला आठवणीने घटनाक्रम पुन्हा तयार करायला न लावता काय घडले हे व्यवसाय ठरवू शकणे, हा महत्त्वाचा गुण आहे.

प्रत्येक प्रकरणासाठी मूळ विनंती, जबाबदार व्यक्ती किंवा प्रक्रिया आणि शेवटची पुष्टी झालेली कृती जतन करा. जतन केलेला मसुदा म्हणजे पाठवलेले उत्तर नव्हे. ग्राहकाच्या नोंदीतील प्रस्तावित बदल म्हणजे त्या प्रणालीने पुष्टी केलेला बदल नव्हे. हे वेगळे ओळखण्यासाठी आवश्यक पुरावे, मूळ ग्राहक-माहितीला लागू असलेल्या प्रवेश-मर्यादांसह, साठवा.

व्यत्ययादरम्यान कामाचे हे व्यावहारिक प्रकार वेगळे ठेवा:

- सुरू करायचे: प्रक्रिया किंवा बाह्य कृती सुरू झालेली नाही.
- अंशतः तयार: वर्गीकरण किंवा मसुदा तयार आहे; पुढचा टप्पा अपूर्ण आहे.
- पूर्ण झाल्याची पुष्टी: गंतव्य प्रणालीत अपेक्षित कृती नोंदली आहे.
- अनिश्चित: कृतीचा प्रयत्न झाला; पण पुष्टी मिळालेली नाही.

अनिश्चित प्रकरण पुन्हा सुरू करण्याआधी संबंधित प्रणाली तपासू शकणाऱ्या व्यक्तीकडे द्या. जोडणी तुटली तेव्हा सहाय्यक उत्तराचा मसुदा तयार करत असेल, तर नवा मसुदा तयार करणे कदाचित निरुपद्रवी असेल. वेगळे साधन ते उत्तर पाठवत असेल, तर संपूर्ण काम पुन्हा केल्याने ते दोनदा जाऊ शकते. कामकाजाच्या नोंदीत हा फरक दिसला पाहिजे.

पहिला HTTP 200 यश-प्रतिसाद आल्यानंतरही प्रवाहातून येणारे उत्तर अयशस्वी होऊ शकते, असे Anthropic च्या API कागदपत्रांत म्हटले आहे. पहिला मजकूर दिसणे किंवा सुरुवातीची स्थिती मिळणे म्हणजे पूर्ण उत्तर मिळाले असे नाही. जोडणीने पूर्णता ओळखावी आणि अपूर्ण काम अपूर्णच म्हणून जतन करावे. [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 API मध्ये स्पष्ट विनंती-ओळख क्रमांक वापरून पुनरावृत्ती ओळखली जाते आणि अतिरिक्त परिणाम रोखले जातात. ही हमी स्वीकारणाऱ्या सेवेने लागू करावी; फक्त अंतर्गत प्रकरण क्रमांक जोडल्याने असे संरक्षण मिळत नाही. [पुनर्प्रयत्न सुरक्षित करण्याबाबत AWS](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)

कामकाजात होणाऱ्या कृतींबद्दल नेमके विचारा. पुन्हा प्रयत्न केल्याने समर्थनासाठी दुसरे तिकीट तयार होऊ शकते किंवा दुसरा ईमेल पाठवला जाऊ शकतो का? पुनरावृत्ती रोखता येत नसेल तर आणखी प्रयत्न करण्यापूर्वी गंतव्य नोंद तपासणे योजनेत असावे. मजकूर तयार करण्याचा पुनर्प्रयत्न आणि संपूर्ण व्यवसाय-प्रक्रिया पुन्हा चालवणे यांसाठी वेगवेगळे निर्णय हवेत.

## पर्यायी मॉडेलला अधिक मर्यादित काम द्या

पर्यायी एआय सेवा काम सुरू ठेवण्यास मदत करू शकते; पण दुसरे खाते उघडणे ही पर्यायी व्यवस्था उभारण्याची सुरुवात आहे. पर्यायाला योग्य सूचना, मान्यताप्राप्त संदर्भ-सामग्री आणि माहिती हाताळण्याची परवानगी हवी. व्यवसायाला त्याची गरज असेल तेव्हा क्षमताही उपलब्ध हवी.

संपूर्ण बदल करण्याआधी मर्यादित पर्यायी काम निवडा. काल्पनिक ग्राहक-सेवा विभागात दुसरे मॉडेल नेहमीचे संदेश वर्गीकृत करेल आणि कर्मचारी ग्राहकांना जाणारी उत्तरे हाताळतील. संदिग्ध उत्पादन-नावे आणि व्यक्तीकडे पाठवावी लागणारी विनंती यांसह प्रतिनिधिक प्रकरणांवर पथक त्याची चाचणी घेऊ शकते. उत्तर ओघवते आहे एवढ्याने कंपनीचे समर्थन-नियम पाळले याचा पुरावा मिळत नाही.

घटना घडण्याआधी पर्यायी सेवेला कोणती माहिती पाठवता येईल ते ठरवा. कर्मचारी गडबडीत ग्राहकांच्या नोंदी वैयक्तिक खात्यांत चिकटवणार नाहीत याची खात्री करा. खरेदीच्या वेळी पर्यायाच्या माहिती-हाताळणीच्या अटी आणि प्रवेश-व्यवस्था तपासा; उत्तरांची गुणवत्ता आणि किंमतही विचारात घ्या.

वेगवेगळी मॉडेल-नावे असल्याने स्वतंत्र उपलब्धता सिद्ध होत नाही. पर्यायी सेवाही त्याच लॉगिन, नेटवर्क जोडणी, दस्तऐवज-साठा किंवा कामकाज-सॉफ्टवेअरवर अवलंबून असू शकते. प्रस्तावित पर्याय नेमके कोणते अवलंबित्व टाळतो याची यादी करा. कदाचित त्याच बिघडलेल्या जोडणीमागे दुसरे मॉडेल ठेवण्यापेक्षा उपलब्ध संदर्भ-दस्तऐवजांसह हाताने चालणारी कामांची रांग अधिक संरक्षण देईल.

सूचना बदलल्यावर आणि उत्पादनांची माहिती जुनी झाल्यावर पर्यायी सेवा सांभाळावी लागते. क्वचित वापरल्या जाणाऱ्या प्रक्रियांचा कर्मचाऱ्यांनी सराव करायला हवा. संपूर्ण कामकाजाची नक्कल उभारण्याऐवजी मंद गतीची हाताळणी सेवा राखणे छोट्या व्यवसायाला रास्त वाटू शकते. विलंबित कामाचा खर्च आणि चुकीच्या उत्तराची हानी यांवरून हा निर्णय घ्यावा.

## तपासलेल्या रांगेतून पुन्हा सुरू करा

पुरवठादाराने सेवा पूर्ववत झाल्याचे सांगितल्यानंतर सामान्य प्रक्रिया पुन्हा सुरू करण्याआधी स्वतःच्या कामातील थोड्या प्रकरणांची तपासणी करा. आवश्यक दस्तऐवज-शोध आणि नोंद-अद्ययावत करण्याची चाचणी त्यात असू द्या. मॉडेलचे उत्तर यशस्वी आले म्हणजे जोडलेल्या प्रत्येक प्रणालीची तयारी झाली असे सिद्ध होत नाही.

मग प्रतीक्षेतील काम तपासा. हाताने आधीच हाताळलेली प्रकरणे काढा, अनिश्चित कृती तपासा आणि परिस्थिती बदललेल्या विनंत्या ओळखा. व्यत्ययादरम्यान ग्राहकाने नवी माहिती दिली असू शकते. प्रकरणाच्या आधीच्या आवृत्तीवर उत्तर तयार केल्याने तांत्रिक अडचण संपल्यानंतर नवी समस्या निर्माण होऊ शकते.

उरलेले काम नियंत्रित गटांतून सुरू करा. नव्या तातडीच्या विनंत्यांसाठी क्षमता राखा आणि रांग कमी होत आहे का ते पाहा. प्रत्येक नवा प्रयत्न यशस्वी झाला तरी आलेली मागणी उपलब्ध प्रक्रियाक्षमतेइतकीच असेल, तर प्रलंबित कामे तशीच राहतील. भरून काढण्यासाठी अधिक कर्मचारी, तात्पुरती कमी सेवा किंवा प्रतिसादाच्या वेळेबद्दल प्रामाणिक मुदतवाढ लागू शकते.

वेगळ्या संख्यात्मक उदाहरणासाठी समजा दर तासाला 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 API मुळे पुनर्प्रयत्न सुरक्षित करणे](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/) — वापरकर्त्यांच्या निकालांवर आणि महत्त्वाच्या अवलंबित्वांवर आधारित विश्वासार्हता-उद्दिष्टे स्पष्ट करते. प्रस्तावित ग्राहक-सेवा मोजमाप आणि प्रलंबित कामाचे उदाहरण हे दाखले आहेत; निरीक्षित निकाल किंवा सर्वत्र लागू लक्ष्य नाहीत.