هر ورک‌فلو باید یک زنگ خطر داشته باشد

بدترین حالتِ یک اتوماسیون این نیست که خراب شود. این است که بی‌صدا خراب شود. تریگر می‌آید، یک قدم در میانه شکست می‌خورد، و هیچ‌کس نمی‌فهمد — تا وقتی که یک مشتری بپرسد چرا ایمیلش نرسیده.

اتوماسیونِ بی‌صدا از کارِ دستی هم خطرناک‌تر است. کارِ دستی حداقل یک آدم دارد که می‌بیند چیزی سر جایش نیست. ورک‌فلوی خودکار فقط یک لاگِ سبز نشان می‌دهد و تو خیالت راحت است.

هر ورک‌فلو دو خروجی دارد

من هیچ ورک‌فلویی را «تمام‌شده» حساب نمی‌کنم مگر این‌که دو مسیر داشته باشد:

• مسیر موفقیت — کاری که قرار است بکند.
• مسیر شکست — یک شاخه‌ی error که وقتی چیزی می‌شکند، به یک جای انسانی خبر می‌دهد.

در n8n این یعنی یک Error Trigger که به اسلک یا ایمیل وصل است. پنج دقیقه کار، و همان پنج دقیقه فرق بین «فهمیدیم و درستش کردیم» و «سه هفته بود کار نمی‌کرد» است.

زنگ خطرِ خوب سه چیز می‌گوید

یک نوتیفیکیشنِ «یک چیزی خراب شد» تقریباً بی‌فایده است. زنگ خطرِ مفید این‌ها را دارد:

• کجا شکست — نام ورک‌فلو و نودی که افتاد.
• چه ورودی‌ای باعثش شد — تا بتوانی بازتولیدش کنی.
• چه کاری باید کرد — یا لینک به لاگ، یا دستِ‌کم این‌که آیا خودکار دوباره تلاش می‌کند یا نه.

اگر زنگ خطر بهت نگوید بعدش چه کار کنی، فقط یک منبع اضطراب است، نه یک ابزار.

این را اول بساز، نه آخر

وسوسه این است که مانیتورینگ را بگذاری «برای بعد، وقتی پایدار شد». ولی ناپایدارترین لحظه‌ی هر سیستم، همان هفته‌ی اولِ پروداکشن است — دقیقاً وقتی که چشم لازم داری و نداری.

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