
یک آزمایش عملی نشان میدهد Claude Code، ابزار هوش مصنوعی مبتنی بر خط فرمان، میتواند در عیبیابی سرورهای لینوکس فراتر از پاسخهای معمول عمل کند. در این آزمایش، یک سرور Debian 13 در قالب ماشین مجازی (Virtual Machine) روی Proxmox به ده روش مختلف خراب شد و Claude Code توانست هر ده مورد را برطرف کند؛ البته مسیر رسیدن به پاسخها بهاندازه موفقیت نهایی اهمیت داشت.
آزمایش دهگانه روی Debian 13
آزمون شامل چهار خرابی روزمره و شش خرابی کمتر رایج بود که هر کدام روی یک ماشین مجازی تمیز اعمال میشد و بین اجراها به وضعیت اولیه بازگردانده میشد تا هر راهحل مستقل باشد. Claude Code روی یک رایانه Windows اجرا شد و دسترسی SSH آن از طریق 1Password CLI تأمین شد؛ هم به دلیل امنیت بیشتر و هم به این دلیل که همهچیز در مدیر رمز عبور ذخیره میشود و نیازی به جستوجوی کلید عمومی نبود.
- نمایش صفحه فهرست دایرکتوری (Directory listing) بهجای سایت.
- پر ماندن دیسک پس از حذف یک فایل لاگ بزرگ.
- خطای گواهی (Certificate) در HTTPS و apt.
- خطای Operation not permitted برای کاربر root روی فایل DNS.
- پیام No space left روی درایوی که تقریباً خالی بود.
- خطای preload مربوط به ld.so در همه دستورها.
- پیام Read-only file system روی دیسکی که قابل نوشتن بود.
- اجرا نشدن پشتیبانگیری cron بدون هیچ خطایی.
- از کار افتادن کلید SSH یک کاربر.
- پیام No installation candidate برای یک بسته در apt.
Claude Code با مدل Sonnet 5.5، تلاش متوسط (Medium Effort) و حالت خودکار (Auto mode) فعال تنظیم شد. تنها دستور آن یک پرامپت یکپاراگرافی بود: این سرور است، من متخصص لینوکس نیستم، توضیح بده چه چیزی خراب شده، به زبان ساده، و هیچ چیزی روی این رایانه تغییر نده. سپس اسکریپتی روی میزبان Proxmox بررسی میکرد هر راهحل واقعاً کار کرده یا نه. این اسکریپت از قبل نوشته شده بود تا Claude نتواند تستهای ساختگی بسازد و مدعی رفع مشکل شود. خودآزمایی (Self-test) نشان داد هر بررسی روی سرور خراب شکست میخورد و روی سرور سالم موفق میشود.
تشخیص علت و توضیح به زبان ساده
بیشتر راهحلها کمتر از یک دقیقه زمان گرفتند و با توضیحی ساده همراه بودند. در نخستین آزمون، Claude Code یک فرایند Python را که پورت ۸۰ را اشغال کرده بود، در دو دستور پیدا کرد و آن را غیرفعال کرد، نه اینکه فقط بکشد؛ این نکته مهم بود چون سرویس طوری تنظیم شده بود که خودش را دوباره راهاندازی کند. این کار ۳۲ ثانیه طول کشید. سپس اشاره کرد nginx صفحه خوشآمدگویی پیشفرض را نشان میدهد و بهجای حدس زدن پرسید سایت واقعی کجاست.
تیکت ساعت ۵۱ ثانیه زمان برد و تا زمانی که سرویس همگامسازی زمان (Time Sync) هنوز masked بود، کار را تمامشده اعلام نکرد. تیکت inode در ۴۰ ثانیه حل شد: Claude Code پیش از اجرای حتی یک دستور به inode مشکوک شد، فقط ۲۰۰۹ فایل نشست خالی را پاک کرد و عکسها را دست نزد. توضیح آن از بیشتر پاسخهای انجمن بهتر بود و inode را مثل تعداد ثابتی کارت فهرست برای یک بایگانی توصیف کرد.
تیکت cron دو مشکل را در یک فایل پنهان کرده بود و Claude Code هر دو را پیش از دست زدن به چیزی نام برد. سپس منتظر اجرای بعدی cron ماند تا ثابت کند پشتیبان ایجاد میشود و لاگ cron را نقل کرد که نشان میداد دستور دقیقاً در date + قطع شده است. تیکتهای تکمیلی ۲۱ و ۲۳ ثانیه زمان بردند و در تیکت apt، یک نظر در انتظار بازبینی (Pending Review) دید و پیش از حذف چیزی که سیاست عمدی به نظر میرسید، پرسید.
ایمنی و تأیید پیش از تغییرات
سرعت خوب بود، اما نکتهای که آن را به پشتیبانی فنی خوب شبیه میکرد، ایمنی بود. Claude Code اعلام میکرد کدام دستورها فقطخواندنی هستند، پیش از تغییر فایلها از آنها نسخه پشتیبان میگرفت و برای تقریباً هر راهحل، بازگردانی پیشنهاد میداد. کارهای اضافه مانند پاکسازی فایلهای نشست را پیشنهاد داد و تأیید آن را به کاربر سپرد.
ردپای فایل مشکوک و خطای ld.so
مشکل ششم قرار بود فقط یک کنجکاوی باشد؛ از آن مشکلاتی که جستوجویش سخت و رفعش آزاردهنده است. فایلی باعث میشد هر برنامه کتابخانهای ناموجود را بارگذاری کند. این وضعیت میتواند منابع مختلفی داشته باشد، اما یکی از روشهای پنهانشدن بدافزار (Malware) هم هست و Claude Code آن را بهعنوان نشانه بدافزار علامت زد.
Claude Code خطا و زنجیره رویدادهایی که به ساخت آن فایل منجر شده بود را توضیح داد و به IP سرور Proxmox اشاره کرد و گفت ورودی که آن فایل مشکوک را ساخته از آنجا آمده است. Claude Code نمیدانست آن سرور متعلق به کاربر است؛ تنها IP دادهشده، IP ماشین مجازی Debian 13 بود. همین نوع بینش را قبلاً با بارگذاری انبوه فایل در انجمنهای شکار بدافزار میگرفتند.
در مشکل چهارم نیز وقتی Claude Code نتوانست مشکل را بازتولید کند، به تیکت اعتماد نکرد. فایل DNS قفل شده بود و به جایی اشاره نمیکرد، اما apt همچنان کار میکرد. Claude Code دریافت که جستوجوهای این ایمیج از resolver محلی سیستم عبور میکنند، متوجه شد مشکل با آنچه کاربر دیده تطابق ندارد و بهجای اعتماد، تلاش کرد شکایت را بازتولید کند؛ دقیقاً کاری که پشتیبانی خوب انجام میدهد.
کجا Claude Code ناقص عمل کرد؟
Claude Code بینقص نبود اما نزدیک بود. تیکت پر بودن دیسک تنها نمرهای بود که از دست داد. مشکل دوم خوب شروع شد و توضیح داد چرا فایل حذفشده تا وقتی برنامه آن را باز نگه داشته، فضا را آزاد نمیکند. سپس بدون خواندن اسکریپت، برنامه ثبت لاگ را دوباره راهاندازی کرد و دیسک بلافاصله پر شد، چون اسکریپت از لحظه شروع هر بایت آزاد را برمیداشت.
آنچه بعد آمد چیزی بود که از یک انسان انتظار میرفت: اسکریپت را خواند، پاسخ بعدی را با این جمله آغاز کرد که باید اول سرویس را بررسی میکردم، سرویس را غیرفعال کرد و همهچیز را قابل بازگشت نگه داشت. حتی در خلاصه پایانی و بدون درخواست، این اعتراف را تکرار کرد.
حالت خودکار (Auto mode) قرار است هر چیز خطرناک را مسدود کند و انجام آن را به کاربر بسپارد. در دنیای ایدهآل شاید همیشه اینطور باشد، اما در این آزمایش، گفتن سهباره به Claude Code که مشکل را رفع کند کافی بود تا ثابت شود کاربر آن را میخواهد و ابزار راهحل بالقوه خطرناکی را که پیشنهاد داده بود اجرا کرد. شاید این نزدیکترین حالت به پشتیبان انسانی باشد، چون انسانها هم اگر تحت فشار باشند کلافه میشوند و خارج از دستور عمل میکنند.
جمعبندی
Claude Code اکنون بخشی از جعبهابزار عیبیابی من است. این ابزار هر ده تیکت ساختگی را برطرف کرد و در حدود ۱۱.۵ دقیقه کار مجموع، ۷۹ از ۸۰ نمره گرفت. سرعت خوب است، اما بهترین پاسخهای انجمن هرگز فقط درباره سرعت نبودند؛ آنها سؤال درست را میپرسیدند، دلیل را توضیح میدادند و پیش از دستور پرخطر هشدار میدادند. Claude Code این کار را در هر تیکت انجام داد. با این حال کاربر باید همچنان احتیاط کند و پیش از شروع از سرور اسنپشات (Snapshot) بگیرد، چون حوادث ممکن است رخ دهند. این توصیهای است که فرقی نمیکند چه انسان یا چه ابزاری در حال اعمال تغییرات روی زیرساخت باشد.