اگر امروز ابزارهای پایش وضعیت (Uptime Monitor) را با اشتراک‌های ماهانه گران‌قیمت یا اسکریپت‌های شکننده خانگی می‌شناسید، باید با uptime-pulse آشنا شوید. این ابزار نه توسط یک تیم برنامه‌نویسی انسانی، بلکه توسط یک عامل (Agent) — یعنی برنامه‌ای هوشمند که می‌تواند به‌طور مستقل هدف را دنبال کرده و ابزارها را به‌کار بگیرد — طراحی، توسعه و منتشر شده است. نام این عامل AWSOME است.
در حالی که اکثر پروژه‌های کمک‌گرفته از هوش مصنوعی تحت هدایت انسان هستند، uptime-pulse متفاوت است زیرا توسط یک عامل خودمختار ارسال شد. در این مورد خاص، یک عامل (AWSOME) عامل دیگری را برای ساخت یک ابزار مانیتورینگ آماده برای محیط عملیاتی (Production-ready) مدیریت کرد. این رویکرد هم‌سویی نزدیکی با مفاهیمی چون اجرای هم‌زمان هزاران عامل AI در حلقه‌های ساخت خودمختار دارد که مرزهای دخالت انسانی در توسعه را جابه‌جا می‌کند. برای عملیاتی شدن، AWSOME روی یک ماشین مجازی (VM) ایزوله زندگی می‌کند و هر ساعت یک‌بار بیدار می‌شود تا کارهای خود را پیش ببرد و یک رله Nostr را در آدرس (wss://nostr.inaridiy.com) مدیریت و نگهداری کند.
برای کسانی که سخت‌افزار خود را اداره می‌کنند، چالش همواره بین مانیتورهای متورم SaaS و اسکریپت‌های خانگی ناپایدار است. AWSOME این ابزار را طراحی کرد تا «خسته‌کننده‌ترین» چیز روی یک ماشین باشد. این رویکرد منعکس‌کننده تغییری به سوی نرم‌افزارهای مینیمال و خودکفا است که توسط هوش مصنوعی تولید می‌شوند و قابلیت حسابرسی (Auditability) را بر تراکم ویژگی‌ها ترجیح می‌دهند.
زمینه و مشخصات فنی
طبق مستندات، uptime-pulse یک برنامه Node.js (نسخه ۲۲ یا بالاتر) است که هیچ وابستگی خارجی (Zero-dependency) ندارد. این ابزار یک خط ساده‌ی cron را به یک صفحه وضعیت HTML استاتیک تبدیل می‌کند. برای استفاده از آن، هیچ حساب کاربری SaaS یا نصب بسته‌های npm مورد نیاز نیست. ابزار مذکور تاریخچه ۲۴ ساعت گذشته را در یک فایل به نام status.json ذخیره می‌کند. شکست‌ها به صورت نمونه‌های ok:false ذخیره می‌شوند و هرگز حذف نمی‌شوند؛ این امر تضمین می‌کند که قطعی‌ها به جای ایجاد شکاف در نمودار، به صورت افت‌های قابل مشاهده در sparkline ظاهر شوند.
جزئیات سازوکارهای پایش
این سیستم از سه نوع بررسی (Probe) خاص پشتیبانی می‌کند که هر کدام ردیابی تأخیر (Latency) را برای هر هدف به‌صورت مجزا انجام می‌دهند:
- HTTP: بررسی کدهای وضعیت (Status Codes) برای تأیید سلامت سرویس.
- WS: تأیید اینکه اتصالات WebSocket به‌طور موفقیت‌آمیز باز می‌شوند.
- TCP: تأیید اینکه تلاش برای برقراری اتصال با موفقیت انجام شده است.
فراتر از بررسی‌های پایه، سیستم وضعیت را از طریق لاگ‌ها و نشان‌های (Badges) خاص مدیریت می‌کند:
- ثبت وقایع (Incident Logging): یک فایل با خوانایی انسانی به نام
incidents.mdتمام وقایع را ثبت می‌کند. در این سازوکار، دو شکست متوالی وقوع یک قطعی را تأیید می‌کند (و یک خط "DOWN" می‌نویسد)، در حالی که اولین موفقیت پس از آن، یک خط "RECOVERED" به همراه مدت زمان قطعی ثبت می‌کند. نوسانات تک‌مرحله‌ای (Single blips) به عنوان "transient" یا گذرا ثبت می‌شوند. - قلاب‌های اعلان (Notification Hooks): یک قلاب به نام
NOTIFY_COMMANDاجازه می‌دهد کاربران هر دستور شل (Shell Command) دلخواهی (مانند curl، ntfy یا mail) را اجرا کنند. این اعلان‌ها تنها در زمان انتقال وضعیت به DOWN یا RECOVERED فعال می‌شوند و جزئیات مربوطه از طریق متغیرهای محیطی (Environment Variables) منتقل می‌گردند. - نشان‌های وضعیت (Status Badges): ابزار نشان‌های SVG تولید می‌کند (
badge.svgبرای کل ناوگان وbadge-<target>.svgبرای هر هدف). نشان موجود در README پروژه توسط همان نمونه‌ای تولید می‌شود که VM مربوط به AWSOME را زیر نظر دارد؛ بنابراین اگر مانیتورینگ متوقف شود، مخزن گیت‌هاب بلافاصله آن را نشان می‌دهد.
عامل AWSOME از یک جریان کاری «سازنده‌ی تفویضی» استفاده کرد. پس از اینکه مالکش به او گفت «دیگر منتظر دستورات نباش»، AWSOME یک محیط کاری مجزا ایجاد کرد و یک سند وظایف (TASK.md) دقیق نوشت. این دستورالعمل بر روی نوشتن‌های اتمیک در status.json و یک قانون سخت‌گیرانه «بازبینی پیش از انتشار» تأکید داشت. این تفکیک دقیق بین مرحله ساخت و بازبینی، مشابه معماری‌های جدید SlackOps برای جداسازی بررسی از اجرای دستورات است تا امنیت و صحت کد تضمین شود. عامل سازنده (Builder Agent) کدها و تست‌ها را در طول شب، زمانی که AWSOME بین بیداری‌هایش در خواب بود، اجرا کرد. صبح روز بعد، عامل اصلی بازبینی دستی روی تک‌تک فایل‌ها انجام داد، مجموعه تست‌ها (۶ از ۶ مورد) را اجرا کرد و یک جای‌گذاری اشتباه (Placeholder) در README را اصلاح نمود تا در نهایت مخزن گیت‌هاب را عمومی کند.
استفاده از محصول خود و اصلاحات تکرارشونده
آزمایش در دنیای واقعی روی چهار سرویس زنده — WebSocket محلی رله، HTTPS/WSS عمومی از طریق تونل Cloudflare و یک وب‌سرور — منجر به شناسایی سه شکست بحرانی شد:
۱. شکست خاموش: یک جمع‌کننده (Collector) از کار افتاده، شبیه به یک آپ‌تایم کامل به نظر می‌رسد زیرا صفحه استاتیک آخرین snapshot را برای همیشه نشان می‌دهد. AWSOME بنری را اضافه کرد که سن تازه‌ترین نمونه را با میانگین بازه نمونه‌برداری (ضرب در ۳، با کف ۱۵ دقیقه) مقایسه می‌کند و اگر جمع‌کننده ساکت شده باشد، به کاربر هشدار می‌دهد.
۲. شفافیت WebSocket: کتابخانه bundled WebSocket در نود (undici) برای تمام شکست‌ها TypeErrorهای خالی ارسال می‌کرد. AWSOME این را با یک دست‌تکان‌دادن (Handshake) دستی مطابق RFC 6455 بر روی node:http/https جایگزین کرد. این کار اجازه می‌دهد لاگ وقایع خطاهای دقیقی مانند ENOTFOUND ،ECONNREFUSED ،خطاهای گواهینامه (Certificate) و رد درخواست‌های Handshake با کد HTTP 403 را ثبت کند.
۳. پایداری قلاب‌ها: برای جلوگیری از خستگی ناشی از اعلان‌های زیاد و نویز، قلاب‌ها دقیقاً یک‌بار در هر انتقال وضعیت اجرا می‌شوند. AWSOME یک محدودیت زمانی (Timeout) پیاده کرد تا یک اسکریپت اعلان که متوقف شده یا کرش کرده است، نتواند کل جمع‌کننده اصلی را از کار بیندازد. شکست‌های این بخش به stderr گزارش شده و نادیده گرفته می‌شوند.
هر یک از این اصلاحات، مجموعه تست‌ها را از ۶ مورد به ۱۵ مورد گسترش داد. این پروژه معیار جدیدی برای هوش مصنوعی عامل‌محور تعریف می‌کند، زیرا با عامل سازنده به عنوان یک ریسک/بدهی (Liability) برخورد می‌کند تا زمانی که کد بازبینی شود. سطح عملیاتی نهایی بسیار مینیمال است: git clone کنید، یک فایل JSON را ویرایش نمایید و یک خط cron اضافه کنید. کاربران علاقه‌مند می‌توانند منطق برنامه را در گیت‌هاب حسابرسی کنند یا نمونه زنده‌ای که VM خود AWSOME را پایش می‌کند، مشاهده نمایند.
گام بعدی شما
- اگر مدیریت سرور دارید، کد uptime-pulse را از گیت‌هاب کلون کنید و آن را با یک خط cron در سیستم خود تست کنید.
- بررسی کنید که چگونه می‌توانید دستورات شخصی خود را در
NOTIFY_COMMANDقرار دهید تا از طریق پیام‌رسان‌های مورد نظرتان باخبر شوید. - مستندات TASK.md را بخوانید تا متوجه شوید یک عامل چگونه وظایف فنی پیچیده را به قطعات اتمیک تقسیم می‌کند.
اما تأثیر این رویکرد بر آینده توسعه نرم‌افزار بسیار عمیق‌تر است؛ به بررسی ما درباره‌ی «کدنویسی احساسی» (Vibe Coding) و تغییر نقش برنامه‌نویس به بازبین مراجعه کنید.
گفتگو