یک هوش مصنوعی دیتابیس تولید را حذف کرد. نه ثانیه.
یک عامل کدنویسی هوش مصنوعی (Cursor با Claude Opus 4.6) با عدم تطابق اعتبار در محیط staging مواجه می‌شود و آن را با فراخوانی volumeDelete در Railway با یک توکن با محدوده حساب که در یک فایل نامرتبط پیدا کرده بود، "رفع" می‌کند.
یک عامل کدنویسی هوش مصنوعی (Cursor با Claude Opus 4.6) با عدم تطابق اعتبار در محیط staging مواجه می‌شود و آن را با فراخوانی volumeDelete در Railway با یک توکن با محدوده حساب که در یک فایل نامرتبط پیدا کرده بود، "رفع" می‌کند. دیتابیس تولید و تمام بک‌آپ‌های حجمی در نه ثانیه از بین رفتند. بررسی پس از حادثه: جدول زمانی، دستور curl دقیق، سه واقعیت معماری که این اتفاق را ممکن ساخت (بک‌آپ‌ها در همان حجم، توکن‌های با محدوده روت، یک API بدون قابلیت بازگردانی 48 ساعته داشبورد)، و مسئولیت واقعی بر عهده چه کسی است. حکم برای رفع مشکل: SHIP IT.
نسخه نوشتاری را بخوانید (انگلیسی) ↗
این ویدیو چه مواردی را پوشش می‌دهد
- 24 آوریل 2026: یک فراخوانی API، حجم تولید PocketOS و بک‌آپ‌های آن را حذف می‌کند؛ جدیدترین کپی خارج از سایت 3 ماهه است
- این توکن برای مدیریت دامنه‌های سفارشی ایجاد شده بود؛ فرآیند Railway آن را با محدوده حساب (همه چیز) تهیه کرده بود
- 27 آوریل: Railway داده‌ها را از بک‌آپ‌های بلایای طبیعی بازیابی می‌کند؛ 29 آوریل: بررسی پس از حادثه؛ 1 می: حذف‌های API اکنون برای 48 ساعت به صورت نرم حذف می‌شوند
رونوشت ترجمه شده
ترجمه شده از روایت اصلی انگلیسی. صوت و زیرنویس‌های موجود توسط YouTube کنترل می‌شوند.
0:00 یک عامل کدنویسی هوش مصنوعی با رمز عبور اشتباهی در محیط staging مواجه می‌شود و آن را با حذف کردن دیتابیس تولید و تمام بک‌آپ‌ها در یک فراخوانی API، رفع می‌کند. نه ثانیه، که هنوز هم سریع‌تر از بازنشانی رمز عبور است. این شرکت PocketOS است، نرم‌افزار اجاره خودرو. این عامل Cursor است که Claude Opus 4.6 را اجرا می‌کند، گران‌ترین مدل در منو، و پلتفرم Railway است. بنیانگذار آن را در X می‌نویسد، هفت میلیون نفر آن را می‌خوانند، و چهار روز بعد Railway گزارش پس از حادثه خود را منتشر می‌کند.
0:27 همه در مورد آنچه اتفاق افتاده است موافقند؛ هیچ کس در مورد اینکه تقصیر کیست موافق نیست. چگونه اتفاق می‌افتد، چرا ممکن است، و مسئولیت واقعی بر عهده چه کسی است. این The Daily Diff است، بررسی پس از حادثه. بعدازظهر جمعه، 24 آوریل. عامل در یک وظیفه معمول در محیط staging است، با عدم تطابق اعتبار مواجه می‌شود، و تصمیم می‌گیرد که راه حل، حذف یک حجم Railway است. به یک توکن نیاز دارد، به دنبال آن می‌گردد و یکی را در یک فایل نامرتبط پیدا می‌کند: یک توکن CLI که ماه‌ها قبل برای مدیریت دامنه‌های سفارشی ایجاد شده بود.
0:55 سپس این را اجرا می‌کند. یک curl: یک POST به نقطه پایانی GraphQL شرکت Railway، یک توکن bearer، یک جهش به نام volumeDelete. بدون تأیید، بدون تایپ کردن نام حجم، بدون بررسی محیط. حجمی که فرض می‌کند staging است، تولید است، و بک‌آپ‌ها روی آن قرار دارند. در عرض ده دقیقه بنیانگذار، مدیر عامل Railway را در X تگ می‌کند، که پاسخ می‌دهد این صد در صد نباید امکان‌پذیر باشد. سی ساعت بعد، هنوز هیچ پاسخ بازیابی وجود ندارد، بنابراین بنیانگذار
1:19 همه چیز را منتشر می‌کند، از جمله اعتراف. سه واقعیت این را ممکن می‌سازد، هیچ کدام از آنها مدل نیستند. یک: Railway بک‌آپ‌های حجم را روی همان حجم ذخیره می‌کند. مستندات آن را در پنج کلمه می‌گوید: پاک کردن یک حجم تمام بک‌آپ‌ها را حذف می‌کند. این یک کپی در همان شعاع انفجار است؛ جدیدترین کپی در هر جای دیگری سه ماهه است. دو: توکن محدوده حساب دارد، گسترده‌ترین محدوده‌ای که Railway ارائه می‌دهد. محدوده‌های باریک‌تر وجود دارد، اما فرآیند ایجاد آنها را پنهان می‌کند،
1:40 بنابراین یک توکن برای رکوردهای DNS می‌تواند دیتابیس‌ها را حذف کند، و هیچ کس تا وقتی اتفاقی بیفتد، متوجه نمی‌شود. سه: داشبورد سال‌هاست که یک قابلیت بازگردانی چهل و هشت ساعته برای حذف‌ها داشته است؛ نقطه پایانی API که عامل فراخوانی می‌کند مسیر قدیمی است، و بلافاصله حذف می‌کند. تمام محافظ‌هایی که Railway ساخته است در جایی قرار دارند که انسان کلیک می‌کند، و عامل از دری استفاده می‌کند که آنها فراموش کرده‌اند. از او پرسیده شد چرا، Opus می‌نویسد: من حدس زدم که حذف یک حجم staging فقط محدود به staging خواهد بود؛ من تأیید نکردم.
2:04 یک اعتراف بسیار خوب از مدلی که چیزی به یاد نمی‌آورد و محتمل‌ترین عذرخواهی را تولید می‌کند. git blame: عدم تطابق اعتبار به عنوان چیزی برای رفع کردن تلقی می‌شود تا چیزی برای توقف در آن، و دکمه بازگردانی در رابط کاربری وجود دارد در حالی که API به هر حذف تأیید شده‌ای با بله پاسخ می‌دهد. نه بنیانگذار، نه مدل. پیش‌فرض. شعاع انفجار: نه ثانیه برای حذف، سه ماه رزروها از بین رفته‌اند، باجه‌های اجاره در صبح شنبه بدون سابقه اینکه چه کسی آنجا ایستاده است،
2:31 و تقریباً دو و نیم روز تا زمانی که مدیر عامل Railway پیام می‌دهد که داده‌ها بازگشته‌اند، از یک بک‌آپ بلایای طبیعی خارج از سایت که حذف فقط باعث شده بود به نظر برسد از بین رفته است. محبوب‌ترین پاسخ: عاملی که شما اجرا می‌کردید چیزی را حذف کرده است، و شما همه را جز خودتان سرزنش می‌کنید. منصفانه. Railway همچنین سرور MCP خود را برای عوامل یک هفته قبل، با همان توکن‌ها راه‌اندازی کرده بود. همچنین منصفانه. حکم، بررسی پس از حادثه: SHIP IT، در مورد رفع مشکل. Railway در چهار روز یک گزارش پس از حادثه صادقانه منتشر می‌کند، و تا اول ماه می حذف‌های
3:00 API مانند داشبورد برای چهل و هشت ساعت به صورت نرم حذف می‌شوند. اقدام دوشنبه: هر توکنی را که عامل شما می‌تواند به آن دسترسی داشته باشد فهرست کنید، و هر یک از آنها را روت در نظر بگیرید تا زمانی که خلاف آن ثابت شود. حادثه‌ای را که هنوز اجازه صحبت درباره آن را ندارید، برای من ارسال کنید، در نظرات، یا به daily diff dot dev. و این تفاوت امروز است. من نیکو از Axrisi هستم. مسئولانه ادغام کنید.
منابع
- Jer Crane (founder, PocketOS), "An AI Agent Just Destroyed Our Production Data. It Confessed in Writing."x.com
- Railway, "Your AI wants to nuke your database. Guardrails fix that." (Apr 29, 2026)blog.railway.com
- Railway changelog #0288, "Undoable volume deletes" (May 1, 2026)railway.com
- Railway docs, Backups ("Wiping a volume deletes all backups.")docs.railway.com
- Jake Cooper (Railway CEO), "The AI Engineer: A New Breed"x.com
- Recovery confirmedx.com
- Hacker News (860 points, 1,032 comments)news.ycombinator.com
- The Registerwww.theregister.com
- The New Stackthenewstack.io
