عیب یابی سیستم با کمک هوش مصنوعی

وقتی یک سرویس از کار می افتد، معمولا مشکل اصلی کمبود دستور نیست.

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

یک خطای 502 می تواند از Nginx باشد، از Upstream باشد، از DNS باشد، از Container باشد، از Timeout باشد یا حتی از برنامه ای که در ظاهر سالم است اما روی پورت دیگری گوش می دهد.

هوش مصنوعی در اینجا می تواند مفید باشد، نه به عنوان کسی که جواب قطعی را می داند، بلکه به عنوان یک دستیار برای ساخت فرضیه و مرتب کردن مسیر عیب یابی.

مرز مهم همین است:

AI باید به شما بگوید چه چیزهایی را بررسی کنید؛ نه اینکه بدون شواهد اعلام کند مشکل حتما از کجاست.

عیب یابی خوب از زمینه شروع می شود

پرامپتی مثل این ضعیف است:

Nginx من 502 می دهد. مشکل چیست؟

مدل تقریبا هیچ چیز نمی داند:

• Nginx روی Host اجرا می شود یا داخل Container؟
• Upstream چیست؟
• خطا برای همه Routeها رخ می دهد یا فقط یکی؟
• مشکل از چه زمانی شروع شده؟
• قبل از آن چه تغییری انجام شده؟
• وضعیت DNS، Port و Process چیست؟
• متن دقیق Error Log چیست؟

پرامپت بهتر:

روی Ubuntu یک Nginx روی Host دارم که HTTPS را Terminate می کند و درخواست را به Container روی شبکه Docker می فرستد.
از امروز فقط دامنه api.example.com خطای 502 می دهد.
Container در حال اجراست و Healthcheck سبز است.
آخرین تغییر، Deploy نسخه جدید برنامه بوده.
این بخش از Nginx error.log است:
...

لطفا 5 فرضیه را به ترتیب احتمال پیشنهاد بده و برای هر فرضیه یک Check غیرمخرب بده که نتیجه آن فرضیه را تایید یا رد کند.

این درخواست بسیار ارزشمندتر است، چون مدل را مجبور می کند فرضیه + آزمون تولید کند.

فرمول ساده برای استفاده از AI در Troubleshooting

برای بیشتر مشکلات فنی می توانید اطلاعات را در این قالب آماده کنید:

1. محیط

مثلا:

• Ubuntu 24.04
• Docker Compose
• Nginx روی Host
• PostgreSQL روی سرور جدا
• برنامه Django یا Node.js

2. علامت مشکل

دقیق بگویید چه چیزی خراب است:

• 502 Bad Gateway
• Timeout
• CPU بالا
• Connection refused
• DNS resolve نمی شود
• سرویس بالا می آید ولی Healthcheck Fail می شود

3. محدوده مشکل

این بخش خیلی مهم است:

• همه کاربران یا فقط بعضی ها؟
• فقط یک سرور یا کل Cluster؟
• فقط IPv6 یا IPv4؟
• فقط یک Endpoint؟
• فقط بعد از Deploy؟

4. آخرین تغییر

خیلی از Incidentها بعد از تغییر رخ می دهند.

بگویید:

• Deploy جدید
• تغییر Firewall
• تغییر DNS
• Rotation Certificate
• Upgrade Package
• تغییر Environment Variable

5. شواهد

به جای توضیح مبهم، خروجی واقعی بدهید:

• Log
• Status سرویس
• Port listening
• DNS result
• HTTP response
• Container health

حالا AI ماده خام کافی برای فکر کردن دارد.

از مدل بخواهید فرضیه ها را رتبه بندی کند

یک روش حرفه ای این است:

بر اساس شواهد فعلی، فرضیه ها را در جدول زیر مرتب کن:

• فرضیه
• شواهد موافق
• شواهد مخالف
• تست بعدی
• ریسک تست

اگر شواهد برای نتیجه گیری کافی نیست، صریحا بگو.

این ساختار جلوی یکی از بدترین رفتارهای مدل را می گیرد: پریدن مستقیم روی یک جواب با اعتماد به نفس بالا.

اول Checkهای Read-only

قبل از هر تغییر، از AI بخواهید فقط Checkهای غیرمخرب پیشنهاد دهد.

مثلا در Linux ممکن است این دسته بررسی ها مطرح شوند:

• وضعیت Process
• Portهای Listening
• Logهای اخیر
• Disk Usage
• Memory
• DNS Resolution
• اتصال TCP
• HTTP Health Endpoint
• Docker Network

در Prompt اضافه کنید:

در مرحله اول فقط دستورهای Read-only و Diagnostic پیشنهاد بده. هیچ Restart، Delete، chmod، تغییر Firewall یا ویرایش Config پیشنهاد نده.

این یک محدودیت بسیار مفید است.

خروجی دستورها را دوباره به مدل برگردانید

Troubleshooting یک مکالمه چند مرحله ای است.

اشتباه رایج این است که همه چیز را یکجا بپرسید و انتظار جواب نهایی داشته باشید.

روش بهتر:

1. زمینه و علامت را بدهید.
2. مدل 3 تا 5 Check پیشنهاد دهد.
3. فقط Checkهای امن را اجرا کنید.
4. خروجی واقعی را برگردانید.
5. مدل فرضیه ها را Update کند.

مثلا:

نتیجه Checkها:

• Container running
• port 8000 داخل Container listening
• nginx resolve برای upstream موفق
• curl از Host به upstream: connection refused

با این اطلاعات فرضیه ها را دوباره رتبه بندی کن و فقط مرحله بعدی را پیشنهاد بده.

این روش بسیار بهتر از دریافت 25 دستور پشت سر هم است.

مثال: عیب یابی 502

فرض کنید Nginx این خطا را دارد:

connect() failed (111: Connection refused) while connecting to upstream

به جای اینکه بپرسید «چطور درستش کنم؟»، بگویید:

Nginx روی Host است و Upstream داخل Docker قرار دارد.
خطا connection refused است.
قبل از هر تغییری، مشخص کن چه اطلاعاتی برای تفکیک بین این موارد لازم داری:

• Port اشتباه
• Process داخل Container گوش نمی دهد
• Binding فقط روی localhost
• Network یا Address اشتباه
• Container Restart loop

برای هر مورد یک Check بده.

حالا AI به جای حدس، یک Decision Tree کوچک می سازد.

لاگ را چطور به AI بدهیم؟

صدها هزار خط Log را بدون فکر داخل Chat نریزید.

اول محدوده را کوچک کنید:

• زمان Incident
• Service مربوط
• Error و Warning
• چند خط Context قبل و بعد

بعد بگویید:

این 80 خط Log مربوط به بازه 10:20 تا 10:25 است.
خطاهای تکراری را گروه بندی کن.
Timestamp، Error Signature و Component را استخراج کن.
هنوز راه حل نده؛ فقط الگوها را نشان بده.

بعد از شناخت الگوها وارد مرحله فرضیه شوید.

بین Correlation و Cause تفاوت بگذارید

مثلا مدل ممکن است ببیند همزمان CPU بالا رفته و نتیجه بگیرد CPU علت مشکل است.

اما ممکن است CPU بالا نتیجه مشکل باشد.

از مدل بخواهید:

برای هر نشانه مشخص کن آیا می تواند Cause، Symptom یا فقط Correlation باشد.

این سوال ساده کیفیت تحلیل را بالا می برد.

اطلاعات حساس را قبل از ارسال حذف کنید

Logها می توانند شامل این موارد باشند:

• Token
• Session ID
• API Key
• Internal Hostname
• IP خصوصی
• Email
• مسیر فایل های حساس
• Query یا Payload کاربر

قبل از ارسال به یک ابزار عمومی AI، اطلاعات محرمانه را Redact کنید.

مثلا:

Authorization: Bearer [REDACTED]

یا:

db-password=[REDACTED]

سرعت عیب یابی ارزش لو دادن Credential را ندارد.

از AI نخواهید دستور خطرناک را مستقیم اجرا کند

مدل ممکن است برای حل Permission Problem پیشنهادهایی مثل chmod گسترده یا اجرای سرویس با دسترسی بیشتر بدهد.

در محیط Production، این نوع میانبرها می توانند مشکل بزرگ تری بسازند.

برای هر دستور تغییر دهنده بپرسید:

این دستور دقیقا چه چیزی را تغییر می دهد؟
Scope تغییر چیست؟
چطور Rollback می شود؟
نسخه Read-only یا Dry-run دارد؟
چه ریسکی برای Production دارد؟

یک Prompt آماده برای عیب یابی

می توانید این قالب را نگه دارید:

نقش تو یک دستیار Troubleshooting است، نه اجراکننده تغییر.

محیط:
...

علامت مشکل:
...

محدوده:
...

آخرین تغییر:
...

شواهد فعلی:
...

خروجی را اینطور بده:

1. پنج فرضیه به ترتیب احتمال
2. شواهد موافق و مخالف هر فرضیه
3. فقط یک یا دو Check بعدی که Read-only باشند
4. نتیجه مورد انتظار هر Check و اینکه چه چیزی را تایید یا رد می کند

اگر اطلاعات کافی نیست، قبل از نتیجه گیری سوال بپرس.

AI در عیب یابی چه کاری را نباید انجام دهد؟

نباید جای این موارد را بگیرد:

• مشاهده واقعی سیستم
• Change Management
• Backup
• Rollback Plan
• تایید دسترسی و Permission
• بررسی Impact
• تجربه مهندس با معماری واقعی سیستم

مدل Architecture شما را فقط به اندازه اطلاعاتی که داده اید می شناسد.

اگر یک بخش مهم را نگویید، ممکن است روی یک معماری خیالی تحلیل کند.

جمع بندی

هوش مصنوعی برای عیب یابی زمانی بیشترین ارزش را دارد که به جای «جواب نهایی»، از آن برای ساختن مسیر بررسی استفاده کنید.

قاعده ساده:

Context → Evidence → Hypothesis → Safe Check → New Evidence

بعد این چرخه را تکرار کنید تا شواهد به اندازه کافی قوی شوند.

AI می تواند سرعت فکر کردن و پیدا کردن Blind Spotها را بالا ببرد، اما مسئولیت آخر هنوز با شماست:

قبل از تغییر، بدانید چه چیزی را تغییر می دهید، چرا تغییر می دهید و اگر بدتر شد چطور برمی گردید.