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

# Claude ফিরেছে। আপনার ব্যবসারও পুনরুদ্ধার পরিকল্পনা দরকার

> ২২ সেপ্টেম্বরের Claude-সংক্রান্ত ঘটনা মিটেছে। 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.

২২ সেপ্টেম্বর Claude-এর একাধিক মডেলে ত্রুটি বেড়েছিল। Anthropic-এর চূড়ান্ত ঘটনা-হালনাগাদে প্রভাবের সময় ০০:৫০ থেকে ০২:১০ UTC—মোট ৮০ মিনিট। ০২:৩৫ UTC-তে ঘটনাটি সমাধান হয়েছে বলে চিহ্নিত করা হয়। প্রভাবিত উপাদানের তালিকায় claude.ai, API, Code এবং Cowork ছিল। নথিতে বলা নেই যে প্রতিটি অনুরোধ ব্যর্থ হয়েছিল; সমস্যার মূল কারণ সম্পর্কেও প্রকাশিত ব্যাখ্যা নেই। [Anthropic-এর ঘটনা-নথি](https://status.claude.com/incidents/7g1qpkyz5gxh)

কাজের প্রক্রিয়ায় AI ব্যবহার করা ব্যবসার জন্য সেবা ফের চালু হওয়া সমস্যার শুধু এক অংশের উত্তর। গ্রাহকের অনুরোধ তখনও অপেক্ষায় থাকতে পারে। স্বয়ংক্রিয় চেষ্টা চলার সময় কেউ হয়তো হাতে একটি ঘটনা সামলানো শুরু করেছেন। কোন কাজ আবার শুরু করা যাবে, কোনটির আগে পরীক্ষা দরকার—তা তত্ত্বাবধায়কের জানা দরকার।

কেউ চিন্তার খসড়া তৈরিতে ব্যবহার করলে মাঝে মাঝে assistant না-পাওয়া বিরক্তিকর। একই সেবা দিয়ে আগত ঘটনা শ্রেণিবদ্ধ করা, জবাবের খসড়া করা ও নথি হালনাগাদ করা হলে বিঘ্নটি পরিচালনাগত সমস্যায় পরিণত হয়। কার্যকর প্রস্তুতি হলো ছোট একটি ধারাবাহিকতা পরিকল্পনা, যা কর্মীরা AI সেবাটিতেই প্রবেশাধিকার না পেয়েও অনুসরণ করতে পারবেন।

এই নির্দেশিকায় কাল্পনিক একটি গ্রাহকসেবা ডেস্কের উদাহরণ দিয়ে পরিকল্পনাটি কীভাবে কাজ করতে পারে দেখানো হয়েছে। পদ্ধতিগুলো মানিয়ে নেওয়া ও মহড়ার প্রস্তাব—BIG CHANGE-এর পরীক্ষা নয়, এই ঘটনায় ক্ষতিগ্রস্ত গ্রাহকদের বিবরণও নয়।

## AI ছাড়াই যে সেবা চালাতে পারবেন, সেটি বেছে নিন

একটি ছোট যন্ত্রপাতি-সরবরাহকারী প্রতিষ্ঠানের কথা ভাবুন। তাদের assistant আগত সহায়তা-বার্তা শ্রেণিবদ্ধ করে এবং অনুমোদিত পণ্যের তথ্য দিয়ে জবাবের খসড়া বানায়। পাঠানোর আগে কর্মীরা জবাব যাচাই করেন। উত্তর দেওয়ার দায় মানুষেরই থাকলেও কাজের সারি সাজাতে ব্যবসাটি ব্যবস্থাটির ওপর নির্ভর করে।

assistant উত্তর দেওয়া বন্ধ করলে ডেস্ক যতটুকু সেবার প্রতিশ্রুতি রাখতে পারবে, ব্যবস্থাপকের প্রথম সিদ্ধান্ত সেটিই। কর্মীরা অনুরোধ পাওয়ার স্বীকৃতি জানাতে এবং অতি কাছের সময়সীমার ঘটনা সামলাতে পারেন; নিয়মিত পণ্য-সংক্রান্ত ব্যাখ্যা পরে দেওয়া যেতে পারে। assistant-এর বাইরে মূল বার্তা ও অনুমোদিত তথ্যসূত্রে তাঁদের প্রবেশাধিকার থাকা দরকার। তা না হলে “হাতে সামলান” কথাটি বাস্তব উপায়হীন নির্দেশ হয়ে দাঁড়ায়।

সীমিত এই সেবার ধরন আগেই বেছে নিন। কে তা চালু করতে পারবেন, কোন কাজ থামবে এবং বাকি কাজ কোন কর্মীরা সামলাবেন—নির্দিষ্ট করুন। পুনর্মূল্যায়নের সময় ঠিক করুন, যাতে অস্থায়ী ব্যবস্থা বিকেলভর কারো পুনর্বিবেচনা ছাড়াই চলতে না থাকে। গ্রাহককে দেওয়া বার্তায় বিলম্ব এবং জরুরি সহায়তার বিকল্প পথ ব্যাখ্যা করুন, আর দল যে প্রতিশ্রুতি রাখতে পারবে সেটিই দিন।

অতিরিক্ত চাপ সামলানো নিয়ে 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)

## কথোপকথনের বাইরে কাজের নথি রাখুন

মডেল না-পাওয়া গেলেও পড়া যায়—এমন ঘটনা-নথি সেবা-ডেস্কের দরকার। সেটি তাদের বর্তমান সহায়তা-ব্যবস্থা হতে পারে। মূল কথা হলো, বিঘ্নিত assistant-কে কাজ পুনর্গঠন করতে না বলেই ব্যবসাটি কী ঘটেছে জানতে পারবে।

প্রতিটি ঘটনার জন্য মূল অনুরোধ, দায়িত্বপ্রাপ্ত ব্যক্তি বা প্রক্রিয়া এবং সর্বশেষ নিশ্চিত পদক্ষেপ সংরক্ষণ করুন। সংরক্ষিত খসড়া আর পাঠানো জবাব এক নয়। গ্রাহকের নথিতে প্রস্তাবিত পরিবর্তন আর সেই ব্যবস্থায় নিশ্চিত হওয়া পরিবর্তনও আলাদা। পার্থক্য বোঝার প্রয়োজনীয় প্রমাণ রাখুন, আর গ্রাহকের মূল তথ্যের মতোই প্রবেশাধিকার সীমিত করুন।

বিঘ্নের সময় কাজকে ব্যবহারিক এই শ্রেণিগুলোতে আলাদা করুন:

- শুরু করার জন্য প্রস্তুত: কোনো প্রক্রিয়াকরণ বা বাইরের পদক্ষেপ শুরু হয়নি।
- আংশিক প্রস্তুত: শ্রেণিবিভাগ বা খসড়া আছে, তবে পরের ধাপটি অসমাপ্ত।
- সম্পন্ন নিশ্চিত: গন্তব্য ব্যবস্থায় অভিপ্রেত পদক্ষেপের নথি আছে।
- অনিশ্চিত: পদক্ষেপ নেওয়ার চেষ্টা হয়েছে, কিন্তু নিশ্চয়তা মেলেনি।

আবার শুরু করার আগে প্রাসঙ্গিক ব্যবস্থা পরীক্ষা করতে পারেন—এমন কাউকে অনিশ্চিত ঘটনা দিন। সংযোগ বিচ্ছিন্ন হওয়ার সময় assistant জবাব তৈরি করছিল হলে নতুন খসড়া নিরীহ হতে পারে। কিন্তু আলাদা কোনো সরঞ্জাম জবাবটি পাঠাচ্ছিল হলে পুরো কাজ আবার করলে তা দুবার পাঠানো হতে পারে। কর্মপ্রবাহের নথিতে এই পার্থক্য থাকা দরকার।

Anthropic-এর API নথিতে বলা হয়েছে, প্রাথমিক HTTP 200 সফলতার জবাব এলেও streaming প্রতিক্রিয়া পরে ব্যর্থ হতে পারে। প্রথম লেখা দেখা যাওয়া বা ওই প্রাথমিক status পাওয়া মানে পুরো উত্তর এসে গেছে—এটা নয়। একীভূত সফটওয়্যারে সম্পন্ন হওয়া শনাক্ত করতে হবে এবং আংশিক কাজকে আংশিক হিসেবেই রাখতে হবে। [Claude API-র ত্রুটি-সংক্রান্ত নথি](https://platform.claude.com/docs/en/api/errors)

## পুনরায় চেষ্টার সীমা ও দায়িত্বপ্রাপ্ত ব্যক্তি ঠিক করুন

পুনরায় চেষ্টা করলে সাময়িক ব্যর্থতা কাটতে পারে। তবে প্রতিটি স্তর আলাদাভাবে একই কাজ আবার চালালে অনিশ্চয়তা দীর্ঘও হতে পারে। নতুন retry button বা স্বয়ংক্রিয় loop যোগ করার আগে সফটওয়্যার সরবরাহকারীকে জিজ্ঞেস করুন, তার client library-তেই পুনঃচেষ্টা হয় কি না।

Anthropic-এর নথি অনুযায়ী, তাদের আনুষ্ঠানিক SDK-গুলো সাময়িক ব্যর্থতায় default হিসেবে ক্রমে বাড়তে থাকা বিরতিতে দুবার স্বয়ংক্রিয় retry করে এবং নির্দেশ থাকলে retry-after মানে। ত্রুটি-সংক্রান্ত নথিতে সাময়িক server সমস্যা থেকে authentication, permission ও ভুল request আলাদা করা হয়েছে। সব ধরনের ব্যর্থতা একই অনুরোধ আবার পাঠালেই ঠিক হবে—এমন ধরে নেওয়া যায় না। [Claude-এ নথিভুক্ত retry আচরণ](https://platform.claude.com/docs/en/api/errors)

সেবা-ডেস্কের পরিচালনাগত নিয়মে স্বয়ংক্রিয় চেষ্টা কখন বন্ধ হবে এবং পরে ঘটনাটি কে পাবেন তা বলা উচিত। সমস্যা খোঁজার জন্য অনুরোধের identifier সংরক্ষণ করুন। কাজ অপেক্ষায়, retry হচ্ছে, নাকি কারো পদক্ষেপের অপেক্ষায়—কর্মীদের তা দেখতে দিন, যাতে অজান্তে একাধিক প্রতিদ্বন্দ্বী চেষ্টা শুরু না হয়।

কোনো কাজ সফল হলেও তার জবাব নাও আসতে পারে—AWS বিষয়টি ব্যাখ্যা করেছে। তাদের idempotent API-তে স্পষ্ট request identifier ব্যবহার করে পুনরাবৃত্তি শনাক্ত করা ও অতিরিক্ত পার্শ্বপ্রতিক্রিয়া ঠেকানো হয়। গ্রহণকারী সেবাকেই এ চুক্তি মানতে হবে; শুধু অভ্যন্তরীণ case number জুড়ে দিলেই এমন সুরক্ষা আসে না। [retry নিরাপদ করা নিয়ে AWS](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)

কর্মপ্রবাহে ব্যবহৃত পদক্ষেপগুলো নিয়েই সুনির্দিষ্টভাবে জিজ্ঞেস করুন। একই অনুরোধ আবার দিলে আরেকটি সহায়তা-ticket বা ইমেইল তৈরি হতে পারে কি? পুনরাবৃত্তি ঠেকানোর উপায় না থাকলে আরেকবার চেষ্টা করার আগে গন্তব্য নথি পরীক্ষা করতে হবে। শুধু লেখা তৈরি আবার চেষ্টা করা আর পুরো ব্যবসায়িক প্রক্রিয়া পুনরাবৃত্তি করা—এগুলো আলাদা সিদ্ধান্ত।

## বিকল্প মডেলের জন্য আরও সীমিত কাজ নির্ধারণ করুন

বিকল্প AI সেবা কাজ চালিয়ে যেতে সাহায্য করতে পারে, তবে দ্বিতীয় অ্যাকাউন্টই fallback-এর শুরু মাত্র। বিকল্পটিতে উপযুক্ত নির্দেশনা, অনুমোদিত তথ্যসূত্র এবং তথ্য সামলানোর অনুমতি থাকতে হবে। ব্যবসার যখন দরকার হবে তখন তার সক্ষমতাও থাকতে হবে।

পুরো ব্যবস্থা প্রতিস্থাপনের আগে সীমিত একটি বিকল্প কাজ বেছে নিন। আমাদের কাল্পনিক ডেস্কে অন্য একটি মডেল নিয়মিত বার্তা শ্রেণিবদ্ধ করতে পারে, আর কর্মীরা গ্রাহকমুখী জবাব সামলাবেন। অস্পষ্ট পণ্যের নাম এবং মানুষের কাছে পাঠাতে হবে এমন অনুরোধসহ প্রতিনিধিত্বমূলক ঘটনা দিয়ে সেটি যাচাই করা যায়। সাবলীল উত্তর একা কোম্পানির সহায়তা-নিয়ম মানা প্রমাণ করে না।

ঘটনার আগে ঠিক করুন, বিকল্প সেবায় কোন তথ্য পাঠানো যাবে। গ্রাহকের নথি ব্যক্তিগত অ্যাকাউন্টে কপি করে কর্মীরা যেন তাৎক্ষণিকভাবে সমাধান না খোঁজেন। কেনাকাটার সময় বিকল্পটির তথ্য ব্যবস্থাপনার শর্ত ও প্রবেশাধিকারের ব্যবস্থা পরীক্ষা করুন; তার উত্তরের মান ও দামও বিবেচনা করুন।

মডেলের নাম আলাদা হলেই আলাদা প্রাপ্যতা নিশ্চিত হয় না। বিকল্পটিও একই login, network connection, document store বা orchestration software-এর ওপর নির্ভর করতে পারে। আপনার প্রস্তাবিত বিকল্প বাস্তবে কোন নির্ভরতা এড়ায় তা মানচিত্রে দেখুন। এতে বোঝা যেতে পারে, একই ব্যর্থ সংযোগের পেছনে থাকা আরেকটি মডেলের চেয়ে সহজে পাওয়া তথ্যসূত্রসহ হাতে চালানো কাজের সারি বেশি সুরক্ষা দেয়।

নির্দেশনা বদলায় এবং পণ্যের জ্ঞান পুরোনো হয় বলে বিকল্পেরও রক্ষণাবেক্ষণ দরকার। কদাচিৎ ব্যবহার করা প্রক্রিয়ার মহড়া কর্মীদের করতে হবে। পুরো কার্যক্রমের নকল ব্যবস্থা বানানোর খরচ না দিয়ে ছোট ব্যবসা ধীরগতির হাতে-চালানো সেবা রাখাকে যুক্তিসংগত মনে করতে পারে। কাজ পিছোনোর খরচ এবং ভুল জবাবের ক্ষতি ধরে সিদ্ধান্ত নিন।

## পর্যালোচনা করা কাজের সারি দিয়ে আবার শুরু করুন

সরবরাহকারী সেবা পুনরুদ্ধারের কথা জানালে স্বাভাবিক প্রক্রিয়া চালুর আগে নিজের কর্মপ্রবাহের অল্প কয়েকটি ঘটনা পরীক্ষা করুন। ব্যবসার দরকারি নথি খোঁজা ও হালনাগাদের কাজ যাচাই করে এমন ঘটনাও রাখুন। মডেলের উত্তর সফল হলেই প্রতিটি সংযুক্ত ব্যবস্থা প্রস্তুত—তা প্রমাণ হয় না।

তারপর অপেক্ষমাণ কাজ পরীক্ষা করুন। হাতে সামলানো হয়ে গেছে—এমন ঘটনা বাদ দিন, অনিশ্চিত পদক্ষেপ খতিয়ে দেখুন এবং যে অনুরোধের পরিস্থিতি বদলেছে তা চিহ্নিত করুন। বিঘ্নের মধ্যে গ্রাহক নতুন তথ্য দিয়ে থাকতে পারেন। ঘটনার পুরোনো সংস্করণ ধরে জবাব তৈরি করলে প্রযুক্তিগত সমস্যা শেষ হওয়ার পরও নতুন সমস্যা হতে পারে।

বাকি কাজ নিয়ন্ত্রিত দলে ছাড়ুন। নতুন জরুরি অনুরোধের জন্য সক্ষমতা রাখুন এবং সারি ছোট হচ্ছে কি না দেখুন। নতুন চাহিদা যদি সব উপলভ্য প্রক্রিয়াকরণ-সক্ষমতা ব্যবহার করে ফেলে, তবে প্রতিটি নতুন চেষ্টা সফল হলেও জমে থাকা কাজ থেকে যাবে। কাজ পুষিয়ে নিতে বাড়তি কর্মী, সাময়িকভাবে কমানো সেবা বা সৎভাবে জবাবের সময় বাড়ানোর দরকার হতে পারে।

আলাদা একটি সংখ্যার উদাহরণ ধরা যাক: প্রতি ঘণ্টায় ২৪টি ঘটনা আসে এবং ৩০ মিনিট কাজ বন্ধ থাকে। তাতে ১২টি অপেক্ষমাণ ঘটনা জমে। পরে ডেস্ক প্রতি ঘণ্টায় ৩৬টি সামলাতে পারলেও নতুন করে প্রতি ঘণ্টায় ২৪টি এলে জমে থাকা কাজ সরাতে এক ঘণ্টা লাগবে। এগুলো ব্যাখ্যামূলক অনুমান; Claude-ঘটনার পরিমাপ নয়।

Google-এর service-level objective নির্দেশিকা ব্যবহারকারীর কাছে জরুরি ফল এবং তা দেওয়ার জন্য প্রয়োজনীয় নির্ভরতাকে দিয়ে শুরু করে। এই ডেস্কের জন্য উপযোগী মাপকাঠি হতে পারে—প্রতিশ্রুত সময়ের মধ্যে যথাযথ জবাব পাওয়া জরুরি ঘটনার অনুপাত। সরবরাহকারীর প্রাপ্যতা প্রাসঙ্গিক, কিন্তু গ্রাহক সেবা পেয়েছেন কি না ব্যবসাটিরও জানা দরকার। [Google SRE: service-level objective বাস্তবায়ন](https://sre.google/workbook/implementing-slos/)

স্বাভাবিক গ্রাহকসেবা কখন ফিরেছে, কত ঘটনা এখনো অমীমাংসিত এবং পরে কী সংশোধন দরকার হয়েছে—নথি রাখুন। এসব মাপ পুনরুদ্ধারে যে কাজ লাগে তা দেখায়, যা সরবরাহকারীর status page দেখতে পায় না।

## স্বয়ংক্রিয়তা বাড়ানোর আগে একটি বিঘ্নের মহড়া দিন

সংক্ষিপ্ত tabletop মহড়ায় বাস্তব গ্রাহককে বিঘ্নিত না করেই প্রবেশাধিকার বা দায়িত্বে ঘাটতি খুঁজে পাওয়া যায়। কল্পিত কয়েকটি সহায়তা-ঘটনা নিয়ে এই ধাপগুলো অনুসরণ করুন:

1. জবাব তৈরির মাঝপথে মডেল অনুপলব্ধ হয়েছে ধরে নিন। কে সীমিত সেবা চালু করবেন এবং কর্মীরা কোথায় মূল অনুরোধ পাবেন তা জিজ্ঞেস করুন।
2. একটি ঘটনায় পাঠানো জবাব নিশ্চিত, আরেকটিতে পাঠানোর চেষ্টা অনিশ্চিত ধরে নিন। ফল জানার জন্য কোন ব্যবস্থা পরীক্ষা করতে হবে, দল তা জানে কি না দেখুন।
3. নতুন ঘটনা আসতে থাকার মধ্যেই সরবরাহকারীর সেবা ফিরে এসেছে ধরে নিন। কোন কাজ আগে শুরু হবে এবং হাতে সম্পন্ন হওয়া ঘটনা কীভাবে জমে থাকা সারি থেকে বাদ যাবে ঠিক করুন।
4. পরিকল্পনার লেখক ছাড়া অন্য কাউকে পদ্ধতিটি ব্যাখ্যা করতে এবং তার কাছে কোন অনুমতি বা নথি নেই তা চিহ্নিত করতে বলুন।

মহড়ায় যেসব প্রশ্নের উত্তর মেলেনি, লিখে রাখুন। সমাধান ছোট হতে পারে: বর্তমান সারিতে প্রবেশাধিকার, স্পষ্ট pause control, সংরক্ষিত নিশ্চিতকরণ বা পুনরুদ্ধারের দায়িত্বপ্রাপ্ত ব্যক্তি। কোনোটিই নিরবচ্ছিন্ন সেবার নিশ্চয়তা দেয় না। প্রতিটিই স্বয়ংক্রিয়তার সুবিধা না হারিয়ে বিঘ্ন সামলানো সহজ করতে পারে।

assistant-কে আরেকটি পরিচালনাগত দায়িত্ব দেওয়ার আগে সহকর্মীকে দেখাতে বলুন, সেবা বন্ধ হলে সেটি কীভাবে সামলানো হবে। উত্তর যদি নির্ভর করে অনুপলব্ধ assistant মনে রাখবে সে কী করছিল, তবে ধারাবাহিকতা পরিকল্পনার কাজ এখনো বাকি।

## Sources

- [Claude Status: একাধিক মডেলে ত্রুটি বেড়েছিল](https://status.claude.com/incidents/7g1qpkyz5gxh) — সরবরাহকারীর ঘটনা-নথিতে ৮০ মিনিটের প্রভাবের সময় এবং পরে সমাধান হওয়ার সময় দেওয়া হয়েছে। প্রকাশ্য JSON আলাদাভাবে পড়া হয়েছে। এতে ত্রুটি বৃদ্ধির কথা আছে, সবার অনুরোধ ব্যর্থ হওয়ার নয়; সমস্যার মূল কারণের প্রকাশিত বিবরণও নেই।
- [Claude Platform: API-র ত্রুটি](https://platform.claude.com/docs/en/api/errors) — বর্তমান নথিতে ত্রুটি, SDK-র default retry এবং stream শুরু হওয়ার পর ব্যর্থতার বিবরণ আছে। এসব পদ্ধতি ব্যবসার কাজ সম্পন্ন হওয়া প্রমাণ করে না বা সংযুক্ত সরঞ্জামে একই পদক্ষেপের পুনরাবৃত্তি ঠেকায় না।
- [AWS Builders’ Library: idempotent API দিয়ে retry নিরাপদ করা](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) — অনিশ্চিত জবাব ও পুনরাবৃত্ত পদক্ষেপ ঠেকানো নিয়ে Malcolm Featonby-এর ব্যাখ্যা। গ্রহণকারী সেবাকে API-র এ চুক্তি বাস্তবায়ন করতে হয়; identifier একা যথেষ্ট নয়।
- [Google SRE: অতিরিক্ত চাপ সামলানো](https://sre.google/sre-book/handling-overload/) — সেবা কম সুবিধায় চালানো, অগ্রাধিকার ও সীমাবদ্ধ retry নিয়ে প্রতিষ্ঠিত প্রকৌশল নির্দেশনা। নিবন্ধে কাল্পনিক সেবা-ডেস্কে নীতিগুলো প্রয়োগ করা হয়েছে; Anthropic-এর ঘটনার কারণ নির্ধারণে নয়।
- [Google SRE Workbook: SLO বাস্তবায়ন](https://sre.google/workbook/implementing-slos/) — ব্যবহারকারীর ফল এবং গুরুত্বপূর্ণ নির্ভরতার ওপর নির্ভরযোগ্যতার লক্ষ্য ব্যাখ্যা করে। প্রস্তাবিত গ্রাহকসেবা-মাপকাঠি ও জমে থাকা কাজের উদাহরণ ব্যাখ্যামূলক প্রয়োগ; পর্যবেক্ষিত ফল বা সর্বজনীন লক্ষ্য নয়।