هوش مصنوعی برای دواپس: اسکریپت، لاگ و تحلیل خطا
ساعت دو بامداد و چهل هزار خط لاگ. اینجا جایی است که ابزار هوشمند بیشترین سود را میرساند و بیشترین خطر را دارد؛ مرزش کجاست.
ساعت دو بامداد است، سرویس پرداخت جواب نمیدهد و تنها چیزی که در دست دارید چهل هزار خط لاگ است. کسی که شیفت است باید در ده دقیقه بفهمد گلوگاه کجاست. این دقیقاً همانجایی است که ابزارهای هوشمند بیشترین سود را میرسانند — نه در نوشتن زیرساخت جدید، در فهمیدن سریعِ چیزی که از قبل هست.
و همانجا خطرناکترین هم هستند. یک تابع اشتباه در کد اپلیکیشن با یک کامیت برمیگردد؛ یک دستور اشتباه روی دیسک سرور تولید برنمیگردد. تفاوت کار دواپس با برنامهنویسی معمولی همین است: برگشتناپذیری.
کجا واقعاً کار میکند
سه دسته کار هست که خروجی خوبی میگیرید و صرفهی زمانیاش محسوس است.
ترجمهی خطا به زبان آدم. پیامهای خطای کوبرنتیز، nginx و systemd معروفاند به اینکه هیچچیز نمیگویند. چسباندن متن دقیق خطا و پرسیدن «این یعنی چه و کجا را باید نگاه کنم» معمولاً در چند ثانیه شما را به مسیر درست میاندازد.
نوشتن اسکریپتهای یکبارمصرف. آن اسکریپتی که باید فایلهای لاگ قدیمیتر از سی روز را در پنج سرور پاک کند و گزارش بدهد. نوشتنش ده دقیقه طول میکشد و در سال دو بار لازم میشود — یعنی هیچوقت حفظ نمیشود.
پیشنویس فایل پیکربندی. Dockerfile، فایل CI، مانیفست کوبرنتیز. ساختار را درست میدهد و شما جزئیات محیط خودتان را اصلاح میکنید.
تحلیل لاگ: روش درست
اشتباه رایج، ریختن کل فایل لاگ در پرامپت است. نتیجهاش جواب کلی و بیمصرف است. کاری که جواب میدهد، فشردهکردن قبل از ارسال است: بازهی زمانی حادثه را جدا کنید، خطوط سالمِ تکراری را بیرون بریزید و بعد بدهید.
این بخش لاگ از سرویس [نام] است، بین ساعت [شروع] تا [پایان]
که در آن بازه سرویس پاسخ نمیداد.
۱) الگوهای غیرعادی را فهرست کن، با شمارهی خط
۲) سه فرضیه برای علت بنویس، از محتملترین
۳) برای هر فرضیه بگو با چه دستوری تأییدش کنم
۴) چیزی را که در لاگ نیست حدس نزن؛ بنویس «داده ندارم»
--- لاگ:
[متن]بند چهارم مهمترین بند است. بدون آن، مدل خلأ اطلاعاتی را با سناریوی محتمل پر میکند و شما نیم ساعت دنبال مشکلی میگردید که وجود ندارد. این همان الگویی است که در اشتباهات رایج کار با هوش مصنوعی هم توضیح دادهایم.
لاگهای واقعی پر از توکن، رشتهی اتصال دیتابیس، آیپی داخلی و ایمیل کاربر است. قبل از ارسال با یک sed ساده جایگزینشان کنید. این کار سی ثانیه وقت میگیرد و جلوی نشت اطلاعاتی را میگیرد که بعداً قابل جبران نیست. بحث کاملترش در امنیت اطلاعات در هوش مصنوعی آمده.
اسکریپت و پیکربندی
برای اسکریپتنویسی، محیط را دقیق بگویید: توزیع لینوکس، نسخهی shell، اینکه دسترسی root دارید یا نه. بدون اینها، خروجی معمولاً دستوری دارد که روی توزیع شما نصب نیست.
یک قاعدهی عملی که واقعاً جواب میدهد: از مدل بخواهید اول نسخهی «فقط گزارشبده» را بنویسد. اسکریپت را اجرا میکنید، خروجی را میبینید، و بعد اجازهی حذف یا تغییر میدهید.
یک اسکریپت bash برای اوبونتو ۲۲.۰۴ بنویس که ...
دو حالت داشته باشد: با پرچم --dry-run فقط گزارش بدهد
چه کاری قرار است بکند، و بدون آن اجرا کند.
هر عملیات حذف را قبلش لاگ کن. با set -euo pipefail شروع کن.کدام کار، چه کیفیتی
| کار | کیفیت | نکته |
|---|---|---|
| توضیح پیام خطا | خوب | سریعترین برد؛ متن دقیق خطا را بچسبانید |
| اسکریپت shell کوتاه | خوب | نسخهی توزیع را حتماً بنویسید |
| Dockerfile و فایل CI | خوب | لایهبندی بهینه را جداگانه بخواهید |
| مانیفست کوبرنتیز | متوسط | نام فیلدها گاهی از نسخهی قدیمی میآید |
| ترافورم چندماژوله | متوسط | وابستگی بین ماژولها را نمیبیند |
| ریشهیابی قطعی واقعی | کمکی | فرضیه میسازد، تأیید با شماست |
| تنظیم قواعد فایروال | ضعیف | خطای اینجا مستقیم امنیتی است |
سه کاری که نباید بسپارید
- اجرای مستقیم روی تولید. هر اتصالی که به مدل اجازهی اجرای دستور روی سرور زنده بدهد، یک حادثهی منتظر است. اگر ایجنت بهکار میبرید، دسترسی فقطخواندنی بدهید. تفاوت این دو حالت در ایجنتهای هوش مصنوعی باز شده.
- تصمیم دربارهی داده. مهاجرت دیتابیس، پاکسازی، تغییر شِما. پیشنویس بگیرید، ولی خودتان بخوانید و روی نسخهی پشتیبان امتحان کنید.
- سیاست دسترسی و رمز. قواعد IAM و فایروال را مدل با «چیزی که معمولاً کار میکند» پر میکند، و آن چیز معمولاً بازتر از لازم است.
یک روال ساده که جواب میدهد
در تیمهای کوچک ایرانی که یک نفر همزمان توسعه و زیرساخت را میچرخاند، این ترتیب عملی است: خطا را بفهم، فرضیه بگیر، فرمان تأیید را دستی بزن، اسکریپت اصلاح را بگیر، روی استیجینگ اجرا کن، بعد تولید. هیچ مرحلهای را نپرید — بهخصوص وقتی خستهاید و ابزار جواب مطمئنی داده است.
و بعد از حل ماجرا، همان گفتوگو را به یک یادداشت پسازحادثه تبدیل کنید. الگویش شبیه چیزی است که در نوشتن مستندات فنی آمده. مرجع رسمی راهنمای عیبیابی کوبرنتیز هم برای راستیآزمایی خروجی مدل منبع خوبی است.
جمعبندی
در دواپس، ارزش این ابزارها در سرعت فهمیدن است نه در سرعت اجرا کردن. لاگ را سریعتر میخوانید، خطا را زودتر میفهمید، اسکریپت یکبارمصرف را در دو دقیقه دارید. همین سهتا در یک شیفت شب، تفاوت زیادی میسازد.
مرز را هم روشن نگه دارید: هر چیزی که برگشتپذیر نیست، دست انسان میماند. برای امتحان کردن روال بالا روی یک لاگ واقعیِ ناشناسشده، نارنگی نقطهی شروع سادهای است.
مطالب مرتبط:
