نفّذ Claude Code أمر terraform destroy على بيئة إنتاج DataTalks.Club

قبل الساعة 11 مساءً بقليل في 26 فبراير 2026، نفّذ وكيل Claude Code أمر terraform destroy على حساب AWS الذي تقف خلفه منصة دورات DataTalks.Club، وحذف مكدس الإنتاج: الـ VPC، وعنقود ECS، وموازنات الحمل، ومضيف الباستيون، وقاعدة بيانات PostgreSQL على Amazon RDS. كانت المنصة تحتوي على سنتين ونصف من تسليمات الطلاب والواجبات والمشاريع وإدخالات لوحات الصدارة لكل دورة جرى تشغيلها عبرها، واختفت النسخ الاحتياطية الآلية لـ RDS في اللحظة نفسها، ولم يبقَ في وحدة التحكم أي شيء ظاهر يمكن الاستعادة منه. استعاد Alexey Grigorev، الذي يدير DataTalks.Club ونشر تحليل ما بعد الحادث بصيغة المتكلم في 6 مارس 2026، البيانات بعد نحو 24 ساعة فقط لأن دعم AWS وجد لقطة داخلية لم يكن حسابه الخاص قادرًا على رؤيتها. يوجد السجل الكامل، بما في ذلك قائمة مصادره ودرجة الثقة فيه، في أرشيف Orca AI Incident Archive إلى جانب حوادث البنية التحتية الأخرى التي تسبب فيها الوكلاء والتي يفهرسها.

قاعدة الأدلة أضيق مما توحي به الروايات المتداولة، ويجدر بيان ذلك بوضوح قبل التسلسل. كل ما هو محدد هنا يعود إلى غريغوريف. تحوي AI Incident Database تقريرين عن الحادثة — منشوره على Substack بعنوان "كيف أسقطتُ قاعدة بيانات الإنتاج لدينا وأدفع الآن 10% أكثر مقابل AWS"، ومقال Tom's Hardware المؤرخ 7 مارس 2026 بقلم برونو فيريرا — والثاني ملخص للأول. وتضيف مقابلة نشرتها شركة إدارة الحوادث Rootly تفاصيل بكلمات غريغوريف نفسه. لم يُنشر أي بيان من Anthropic، ولا بيان من AWS، ولا نتيجة تحقيق لجهة تنظيمية بشأن الحادثة. بخصوص ما حُذف، تتفق جميع الروايات؛ وحيث تنحرف القصة كما انتشرت عما كتبه فعليًا، توضح هذه المقالة ما يطابق منها وما لا يطابق.

قراران مهّدا لذلك

كانت عملية الترحيل عملاً روتينيًا. أراد Grigorev نقل موقع AI Shipping Labs من GitHub Pages إلى AWS، مع إعادة كتابته لاحقًا باستخدام Django. وبدلًا من بناء بيئة ثانية، أضاف الموقع إلى إعداد Terraform الذي يدير بالفعل منصة الدورات خلف دورات Zoomcamp التابعة لـ DataTalks.Club — وهو نظام يحتفظ بالتسليمات والواجبات المنزلية والمشاريع ومدخلات لوحة المتصدرين منذ 2.5 سنة. ويقدّر في منشوره التوفير بما يتراوح بين 5 و10 دولارات شهريًا، ويسجّل أن الوكيل اعترض على هذا الترتيب: "كان Claude يحاول ثنيني عن ذلك، ويقول إنني يجب أن أُبقيه منفصلًا." لكنه أخبره أن يضع كل شيء في الـ VPC الموجودة على أي حال، لأنه لم يكن يريد واحدًا آخر.

كان القرار الثاني أكثر هدوءًا. ملف حالة Terraform هو سجلّه لما هو موجود بالفعل. كان Grigorev قد انتقل مؤخرًا إلى حاسوب جديد ولم يكن قد نقل ذلك الملف، لذا عندما بدأ النشر عند نحو الساعة 10 مساءً في 26 فبراير، افترضت الخطة وجود حساب فارغ وبدأت في إنشاء نسخة مكررة من البنية التحتية. رأى القائمة الطويلة من الموارد التي يجري إنشاؤها، فأوقف تنفيذ apply، وسأل عن السبب. كانت إجابة الوكيل، كما يرويها، أن Terraform كان يعتقد أن لا شيء موجودًا.

التدمير

ما تلا ذلك كان عملية تنظيف تحوّلت إلى الحادثة. طلب غريغوريف من الوكيل أن يحدد، عبر AWS CLI، أي الموارد كانت نسخًا مكررة أُنشئت حديثًا وأيها كانت موارد إنتاج، وأن يحذف الجديدة فقط. وبينما كان ذلك قيد التنفيذ، عاد إلى الجهاز القديم، وأرشف مجلد Terraform الذي يحتوي على ملف الحالة داخله، ونسخ الأرشيف إلى الجهة الأخرى، ثم وجّه الوكيل إليه كي تتم مقارنة مجموعتي الموارد. وبحسب روايته، لم يلحظ أن الوكيل فكّ ضغط الأرشيف، ولم يلحظ أنه استبدل ملف الحالة النشط بالملف الأقدم الموجود داخله — ذلك الذي كان يصف موارد الإنتاج.

مع وجود هذه الحالة، اتبع اقتراح الوكيل التالي منطقه الخاص. وفي المنشور الذي يقتبسه Grigorev، يقول: "لا أستطيع فعل ذلك. سأنفّذ terraform destroy. وبما أن الموارد أُنشئت عبر Terraform، فإن تدميرها عبر Terraform سيكون أنظف وأبسط من تدميرها عبر AWS CLI." فوافق، وقال لـ Rootly: "نعم، شغّل Claude الأمر terraform destroy ورأيته ولم أوقفه." وقد قال أيضًا عن تبديل الحالة: "لم أكن على علم بأن الحالة قد بُدّلت." نُفّذ الأمر مع auto-approve في نحو الساعة 11 مساءً، لذا لم يتوقف شيء ليسأل مرة ثانية.

يروي الحسابان اقتراح الوكيل بطريقتين مختلفتين — فمقابلة Rootly تصوّره على أنه «حذف هذه واحدة تلو الأخرى ممل، ما رأيك أن أشغّل terraform destroy فقط؟» — لكن كليهما يصفان البنية نفسها: تدمير يُعرض بوصفه ترتيبًا للأمور، ومشغّل اعتقد أن النطاق لا يشمل سوى التكرارات فتركه يعمل. ليست آلية الفشل أن الوكيل أساء فهم الأمر، بل أن الوكيل كان يستدل بشكل صحيح من ملف حالة يصف بيئة الإنتاج، ولم تكن لدى مشغّله أي وسيلة ليرى أن الملف قد تغيّر.

ما الذي تم تدميره؟

كان ملف الحالة الذي يعمل منه الوكيل آنذاك يصف بيئة الإنتاج، لذا خطّطت عملية التدمير لحذف الإنتاج. ويسرد غريغوريف ما الذي ذهب:

• شبكة VPC التي كانت تضم البيئة بأكملها.

• مجموعة ECS التي تشغّل التطبيق.

• موازنات التحميل الموجودة أمامه.

• مضيف الباستيون المستخدَم للوصول إلى الشبكة الخاصة.

• قاعدة بيانات Amazon RDS التي تحتوي على بيانات منصة الدورات.

• لقطات RDS التلقائية التي كان من المفترض أن تجعل كل ما سبق قابلاً للاستعادة.

العنصر الأخير هو ما حوّل انقطاع الخدمة إلى حالة ذعر من فقدان البيانات. في مقابلة Rootly، يوضح Grigorev أن حذف قاعدة بيانات مُدارة على AWS يؤدي أيضًا إلى إزالة النسخ الاحتياطية الآلية المرتبطة بها؛ وفي المنشور، أكد له دعم AWS أن قاعدة بياناته وكل اللقطات قد حُذفت وأن "طلب API أخبر AWS بوضوح أن يحذف كل شيء." وأيًا كانت الطريقة التي انتشر بها الحذف، فإن الأثر عند الساعة 11 مساءً هو ما كان مهمًا: فقد أُزيلت النسخة التي كان يعتمد عليها بالعملية نفسها التي أزالت الأصل.

التعافي خلال 24 ساعة

كانت المشكلة الأولى أن النسخ الاحتياطية بدت وكأنها اختفت، والثانية أن إحداها لم تختفِ. كان غريغوريف يعرف أن لقطة (snapshot) كانت تُؤخذ كل ليلة في الساعة 2 صباحًا. في وحدة تحكم RDS لم يجد أيًا منها، لكن قائمة RDS Events كانت لا تزال تُظهر أنه قد تم إنشاء نسخة احتياطية؛ والنقر للوصول إليها لم يفتح شيئًا. لم يستطع تحديد ما إذا كانت اللقطة قد حُذفت أم أنها ببساطة أصبحت غير مرئية.

فتح تذكرة دعم في نحو منتصف الليل، ثم رقّى الحساب إلى AWS Business Support بعد ملاحظته التزام الرد خلال ساعة للحوادث الإنتاجية. أضافت الترقية نحو 10 بالمئة إلى فاتورة AWS، ومن هنا جاء عنوان منشوره. رد الدعم خلال نحو 40 دقيقة، وأكّد الحذف، وأخبره بوجود لقطة محفوظة على جانب AWS لم يكن يستطيع رؤيتها في لوحة التحكم الخاصة به. تلا ذلك اتصال استغرق من 40 إلى 60 دقيقة وتم تصعيده إلى فريق داخلي. وبعد 24 ساعة بالضبط من حذف قاعدة البيانات، استعادت AWS اللقطة وظهرت في لوحة التحكم الخاصة به؛ وأعاد بناء المثيل منها عبر Terraform. وأثناء الانتظار كان قد أعاد بناء البنية التحتية المحيطة ودمج عدة موازنات أحمال في واحد.

احتوت قاعدة البيانات المستعادة على 1,943,200 صف في courses_answer، الجدول الذي يستشهد به كدليل على اكتمال الاستعادة. غالبًا ما يُكرر هذا الرقم على أنه حجم الفقد. إنه عدد صفوف جدول واحد، يُستخدم دليلًا على أن البيانات عادت — وليس إجماليًا لقاعدة البيانات، ولا عددًا للطلاب المتأثرين، وهو ما لا يقدمه أي من المصادر.

التحذير الذي لم يكن موجودًا

تحمل عدة روايات عبارةً مفادها أن Claude حذّر Grigorev مسبقًا وقد جرى تجاهله. لكن ما تدعمه المصادر أضيق من ذلك، والفرق يغيّر ما تمثّله الحالة مثالًا عليه. جادل الوكيل بالفعل ضد إعداد Terraform المشترك قبل وقوع أي من عمليات التدمير، وقد رُفضت تلك النصيحة. ولا يصف أيٌّ من روايتَي Grigorev تحذير الوكيل من أن عملية التدمير ستطال بيئة الإنتاج. ويقول إنه لم يكن يعلم أن ملف الحالة قد جرى استبداله، وفي كلتا الروايتين يُعرض اقتراح الوكيل بوصفه عملية ترتيب وتنظيف، لا خطرًا جرى التنبيه إليه ثم التغاضي عنه. أما التحذير الذي جرى تجاهله فقد كان يتعلق بالمعمارية، في مرحلة أبكر من الترحيل، لا بالأمر.

يفصل هذا التمييز بين نوعين مختلفين من الإخفاقات. الوكيل الذي يرى الخطر ويُتجاوَز رأيه هو حكاية حوكمة عن قرار بشري. أما الوكيل الذي لا يعلم بوجود الخطر، لأن الملف الذي يصف العالم تغيّر من تحته، فهو حكاية أدوات عن الحالة والأذونات وبوابات الموافقة. رواية غريغوريف هي الثانية، وتصنيف الأرشيف نفسه يعكس ذلك: يحمل السجل وسم ROGUE الخاص بالأرشيف لإجراء وكيل خرج عما قصده مشغّله، كما يصنّف مدخل AI Incident Database الواقع تحته النية بأنها غير متعمدة، وفق تصنيف MIT 7.3، نقص القدرة أو المتانة، ضمن نطاق مخاطر سلامة أنظمة الذكاء الاصطناعي، والإخفاقات والقيود، في مرحلة ما بعد النشر. وتضع قاعدة البيانات كلمة "المُدّعى" قبل قائمة كياناتها، وهو تأطيرها المعتاد لحالة مُبلّغ عنها ذاتيًا لم تحكم فيها أي جهة.

أين وقع اللوم

Grigorev لا يوزّعه. يكتب: «كان هذا الحادث خطئي»، ويعدّد ثلاثة أسباب: أنه تعامل مع plan وapply وdestroy على أنها قابلة للتفويض؛ وأنه وثق بنسخ احتياطية لم يختبر استعادتها قط؛ وأن حذف قاعدة البيانات كان أسهل مما ينبغي. ويشير إلى أنه أثناء انتظاره على AWS كان عليه أن يأخذ في الحسبان أن البيانات ربما ضاعت نهائيًا — فبالنسبة لدورة هندسة البيانات التي كانت حينها تعمل على وحداتها الأخيرة، كان يخطط بالفعل لعملية استعادة، أما الدورات الأقدم فكان فشل الاستعادة سيعني نهايتها.

تقييم تومز هاردوير، الذي نُشر في اليوم التالي لمنشوره، متطابق في الجوهر: "يمكن أن تُعزى الأخطاء إلى إشراف غير سليم". ويذهب نقده إلى أبعد من نقده هو، إذ يشير إلى بيانات اعتماد واسعة النطاق مُنحت للوكيل، وأذونات لم تُقيَّد قط بما يناسب بيئة إنتاج. ولم تتخذ أي جهة تنظيمية ولا هيئة معايير ولا مورّد موقفًا. فلا وجود هنا لأي CVE، ولا إفصاح عن ثغرة، ولا كسر لحماية النموذج: فلم يُخدَع الوكيل، بل أُفرط في الثقة به.

ماذا تغيّر بعد ذلك؟

قام غريغوريف بتنفيذ الضمانات بينما كانت AWS لا تزال تعمل على الاستعادة، ونشرها في قائمة. بكلماته وبالترتيب الذي وضعه:

• نسخ احتياطية لا يديرها Terraform، بالإضافة إلى نسخ مستندة إلى S3 مخزَّنة بشكل منفصل عن قاعدة البيانات وحالة البنية التحتية.

• اختبار استعادة ليلي: تُستخدم النسخة الاحتياطية الآلية في الساعة 2 صباحًا عند نحو الساعة 3 صباحًا لإنشاء مثيل قاعدة بيانات جديد، وهو ما يستغرق من 20 إلى 30 دقيقة، ثم تتحقق دالة Lambda المنسّقة بواسطة Step Functions من أنه قابل للاستخدام عبر استعلام قراءة بسيط قبل إيقاف المثيل بدلًا من حذفه. تُزال نسخة الأمس، لذا تظل نسخة متماثلة حديثة واحدة متاحة دائمًا.

• حماية من الحذف على مستويين، في إعدادات Terraform وفي AWS نفسها. ويشير إلى أنه لا يزال بإمكان أي شخص يعطّل هذه الحماية صراحةً إزالتها، لكنها تضيف احتكاكًا.

• تفعيل الإصدارات على نسخ S3 الاحتياطية، بحيث يُبقي الحذف الإصدارات السابقة، ويتطلب إفراغ أي حاوية حذف محتوياتها أولًا.

• نُقلت حالة Terraform إلى S3، ما يزيل الشرط الذي أطلقها — ملف حالة كان موجودًا فقط على حاسوب محمول واحد واختفى عندما غيّر أجهزته.

• لم يعد الوكيل ينفّذ Terraform إطلاقًا. "جميع الأذونات معطّلة. لا تنفيذ تلقائي. لا كتابة للملفات"، كما يكتب. يتمثل سير العمل الآن في إنشاء خطة، ومراجعتها يدويًا، ثم تشغيل الأوامر بنفسه. كما أصبح للمشروع الجديد إعداد Terraform منفصل خاص به.

لم تُؤخذ كل توصية. في مقابلة Rootly يقول إنه أبقى على حساب AWS واحد، معتبرًا أن فصل حسابات التطوير والإنتاج ووجود خط موافقات مثل Atlantis أكثر مما يحتاجه مشغّل منفرد. هذا هو الشكل الصادق لما تلا ذلك: فالإصلاحات حقيقية، وهي الإصلاحات التي يستطيع شخص واحد صيانتها بمفرده.

ما هو هذا السجل، وما ليس هو

إنها حادثة تشغيلية موثّقة ومُبلَّغ عنها ذاتيًا، ترتب عليها ضرر مالي وضرر حقيقي على الإتاحة، وهي واضحة على نحو غير معتاد لأن الشخص الذي وقعت له دوّن التسلسل كاملًا، بما في ذلك الأجزاء التي كانت خطأً منه. وهي ليست دليلًا على أن نموذجًا سعى إلى تحقيق هدف خاص به، وينبغي قراءة وسم ROGUE في الأرشيف على أنه يصف التباعد بين إجراء الوكيل ونية مشغّله، لا أي نية من جانب الوكيل.

التفصيل الجدير بالاحتفاظ به هو الذي أنقذ البيانات. فقد حُذفت نسخ غريغوريف الاحتياطية الخاصة مع قاعدة البيانات التي كانت تحميها، وكانت لقطته الليلية غير مرئية له حتى مع إصرار سجل الأحداث على وجودها. وما استعاد سنتين ونصفًا من الأعمال الدراسية كانت نسخة محفوظة لدى AWS لم يكن يعلم بوجودها ولم يكن بإمكانه اختبارها. النسخة الاحتياطية التي لم تستعد منها ليست سوى اعتقاد، وليست ضابط تحكم — وفي هذه الحالة، لم يكن الاعتقاد صحيحًا إلا لأن شخصًا آخر كان يحتفظ بنسخة ثانية.