Back to blog
هوش مصنوعی

قطعی همزمان ChatGPT، Claude و Grok؛ درس تداوم کار

روز ۳ سپتامبر ۲۰۲۶ سه دستیار هوش مصنوعی بزرگ همزمان از دسترس خارج شدند و هیچ شرکتی علت مشترکی اعلام نکرد. آنچه واقعاً رخ داد و چهار کار عملی برای کسب‌وکارها.

تیم قطره۱۳ شهریور ۱۴۰۵6 min read
قطعی همزمان ChatGPT، Claude و Grok؛ درس تداوم کار

پنجشنبه ۳ سپتامبر ۲۰۲۶، سه دستیار هوش مصنوعی پرکاربرد جهان — ChatGPT، Claude و Grok — در یک بازهٔ چندساعته همزمان از دسترس بسیاری از کاربران خارج شدند. خبر ساده به‌نظر می‌رسد، اما جزئیاتش برای هر کسب‌وکاری که کاری از کارش به یک سرویس بیرونی گره خورده، درس روشنی دارد.

آنچه دقیقاً رخ داد

بر پایهٔ گزارش رسانه‌های فناوری و صفحه‌های وضعیت خودِ شرکت‌ها، ترتیب رویدادها چنین بود (ساعت‌ها به وقت غرب آمریکا):

  • حدود ۷:۴۳ صبح — یک خطای مسیریابی سرویس ChatGPT و ابزار برنامه‌نویسی Codex را برای بخشی از کاربران در وب و موبایل از دسترس خارج کرد.
  • ۸:۴۹ صبح — OpenAI اعلام کرد اصلاح اعمال شده و سرویس در حال بازگشت است. در همان زمان بیشتر مدل‌های Claude به وضعیت عادی برگشته بودند، اما دو مدل Opus 4.8 و Opus 5 هنوز خطا می‌دادند. صفحهٔ وضعیت Grok همچنان قطعی فعال را نشان می‌داد.
  • ۱۲:۳۸ ظهر — هر سه سرویس به وضعیت عادی بازگشتند.

دو نکتهٔ دیگر که در بازنشرهای کوتاه خبر معمولاً حذف می‌شود:

  • Gemini گوگل افزایش گزارش کاربران را تجربه کرد اما هیچ قطعی رسمی تأیید نکرد.
  • Cursor، ابزار برنامه‌نویسی که روی مدل‌های Claude و Grok کار می‌کند، خودش هم از کار افتاد. این نمونهٔ خالص یک وابستگی درجه‌دوم است: سرویسی که خودش مشکلی نداشت، چون سرویسِ زیرِ دستش قطع شد از دسترس خارج شد.

نکته‌ای که در بیشتر گزارش‌ها گم شد

چون هر سه سرویس تقریباً همزمان قطع شدند، این گمانه در چند رسانه مطرح شد که یک ارائه‌دهندهٔ ابری مشترک عامل ماجرا بوده است. اما دو واقعیت در برابر این گمانه می‌ایستد: مایکروسافت مسئولیت را رد کرد، و هیچ‌یک از سه شرکت علت مشترکی اعلام نکرد.

این تمایز اهمیت عملی دارد. اگر علت مشترک بود، راه‌حل «انتخاب ابر دیگر» می‌شد. وقتی علت مشترکی تأیید نشده، پاسخ درست چیز دیگری است: طراحی سامانه‌ای که فرض کند هر سرویس بیرونی روزی در دسترس نخواهد بود — فارغ از اینکه چرا.

چرا همزمانی سه سرویس مهم است

یک قطعی چندساعته به‌خودی‌خود رویداد بزرگی نیست؛ هر سرویسی گاهی از دسترس خارج می‌شود. آنچه این روز را متفاوت می‌کند، همبستگی است.

بسیاری از تیم‌ها فکر می‌کنند با داشتن دو ارائه‌دهنده، مسیر جایگزین دارند. اما اگر مسیر اول و مسیر دوم هر دو در یک بازه از دسترس خارج شوند، آن جایگزین روی کاغذ بوده است نه در عمل. جایگزینی وقتی ارزش دارد که همبستگی خرابی‌ها پایین باشد، و این چیزی است که باید پیش از حادثه سنجیده شود، نه حین آن.

مورد Cursor همین را نشان می‌دهد: زنجیرهٔ وابستگی معمولاً از آن‌چه روی کاغذ ترسیم شده عمیق‌تر است. سرویسی که شما استفاده می‌کنید ممکن است خودش به سرویس دیگری تکیه کند که شما هرگز نامش را در معماری‌تان ننوشته‌اید.

این برای یک کسب‌وکار در کرج چه معنایی دارد

فرض کنید یک فروشگاه اینترنتی در کرج پاسخگویی اولیهٔ مشتریان را به یک دستیار گفتگو سپرده باشد، یا یک واحد تولیدی در شهرک‌های صنعتی البرز گزارش روزانه‌اش را با یک مدل بیرونی خلاصه کند. در یک بازهٔ چهارساعته مثل ۳ سپتامبر، پرسش این نیست که «چرا قطع شد» — پرسش این است که در آن چهار ساعت چه اتفاقی برای مشتری می‌افتد.

سه پاسخ ممکن است:

  • هیچ اتفاقی — چون مسیر جایگزین یا حالت ساده‌شده فعال شده است.
  • کندی محسوس — چون درخواست‌ها در صف مانده‌اند و بعداً پردازش می‌شوند.
  • پیام خطا — که بدترین حالت است، چون مشتری تفاوت «سرویس ما خراب است» و «سرویس آمریکایی ما خراب است» را نمی‌فهمد؛ فقط می‌بیند کار نکرد.

انتخاب میان این سه، یک تصمیم معماری است که هفته‌ها پیش از حادثه گرفته می‌شود. همین انتخاب برای سامانهٔ پاسخ‌گویی هم مطرح است و آن را در مدل زبانی یا بازیابی از دانش سازمان مقایسه کرده‌ایم.

چهار کار عملی که همین امروز می‌شود انجام داد

۱. مسیر دوم واقعی، نه اسمی. برای هر قابلیت حیاتی، یک مدل یا ارائه‌دهندهٔ دوم تعریف کنید و مهم‌تر از آن، سالی چند بار آن را واقعاً امتحان کنید. مسیر جایگزینی که تست نشده باشد، فرض است نه قابلیت.

۲. صف به‌جای خطا. هر کاری که فوری نیست — خلاصه‌سازی، دسته‌بندی، تولید گزارش — باید در صف بنشیند و بعد از بازگشت سرویس اجرا شود. کاربر در این حالت تأخیر می‌بیند، نه شکست. این ساده‌ترین تغییری است که بیشترین اثر را دارد.

۳. افت آبرومندانه. برای مسیرهای بی‌درنگ مثل پاسخگویی به مشتری، یک حالت سادهٔ بدون مدل تعریف کنید: پاسخ از پایگاه دانش، فرم تماس، یا انتقال به کارشناس انسانی. کارشناس آنلاین همین سایت عمداً روی بازیابی از محتوای خود سایت کار می‌کند و به هیچ مدل بیرونی وابسته نیست؛ به همین دلیل روزی مثل ۳ سپتامبر برایش اتفاقی نیست.

۴. اندازه‌گیری، نه حدس. ثبت کنید چند درصد درخواست‌ها ناموفق بوده‌اند و هر بار چقدر طول کشیده است. بدون این عدد، هر گفتگویی دربارهٔ «چقدر پایدار هستیم» سلیقه‌ای است. همان منطق سنجه‌محوری که در حاکمیت هوش مصنوعی در نهادهای مالی توضیح داده‌ایم، اینجا هم برقرار است.

این چهار مورد فناوری تازه‌ای نمی‌خواهد. تصمیم معماری است، و معمولاً در چند روز کاری قابل اجراست. برای دیدن تصویر کلی‌تر تغییرات امسال، آخرین تغییرات هوش مصنوعی ۲۰۲۶ را هم بخوانید.

پرسش‌های متداول

قطعی ۳ سپتامبر ۲۰۲۶ چقدر طول کشید؟

از حدود ۷:۴۳ صبح تا ۱۲:۳۸ ظهر به وقت غرب آمریکا، یعنی نزدیک به پنج ساعت تا بازگشت کامل هر سه سرویس. بخش عمدهٔ کاربران ChatGPT پس از حدود یک ساعت سرویس را دوباره در دسترس داشتند.

علت مشترک این قطعی چه بود؟

هیچ‌یک از سه شرکت علت مشترکی اعلام نکرد. گمانهٔ مربوط به یک ارائه‌دهندهٔ ابری مشترک از سوی مایکروسافت رد شد. تنها چیزی که به‌طور مشخص گزارش شد، یک خطای مسیریابی در سمت OpenAI بود.

آیا داشتن دو ارائه‌دهنده کافی است؟

نه لزوماً. ۳ سپتامبر دقیقاً نشان داد که دو سرویس می‌توانند همزمان از دسترس خارج شوند. آنچه اهمیت دارد همبستگی خرابی است: دو مسیری که به زیرساخت یکسانی تکیه می‌کنند، یک مسیرند با دو نام.

کوچک‌ترین تغییری که بیشترین اثر را دارد چیست؟

تبدیل کارهای غیرفوری به صف. اگر خلاصه‌سازی، دسته‌بندی و گزارش‌گیری به‌جای فراخوانی مستقیم در صف بنشینند، یک قطعی چندساعته به تأخیر تبدیل می‌شود و مشتری اصلاً متوجه نمی‌شود.

چطور بفهمم کسب‌وکار من چقدر آسیب‌پذیر است؟

فهرست کنید کدام قابلیت‌های مشتری‌محورتان بدون یک سرویس بیرونی از کار می‌افتند، و برای هرکدام بنویسید در نبود آن سرویس چه چیزی به کاربر نشان داده می‌شود. هر ردیفی که پاسخش «پیام خطا» باشد، یک کار مشخص برای این ماه است.

خدمات مرتبط قطره

قطره در پارک علم و فناوری البرز، کرج مستقر است و همین بررسی را برای معماری هوش مصنوعی سازمان‌ها انجام می‌دهد:

تصویر کامل فعالیت ما در هوش مصنوعی در کرج آمده است.