یک اشتباه کوچک در تیم ایجنتیک ما و دو گیت ایمنی که متوقفش کردند

ممکن است یک به‌روزرسانی با موفقیت روی سرور قرار بگیرد، اما کاربر هنوز رابط دیروز را ببیند. چنین ناهماهنگی‌ای هم انسان و هم ایجنت را سردرگم می‌کند: گزارش فنی می‌گوید «جدید»، اما صفحه «قدیمی» است.

پنل ادمین تکرالب پس از بعضی به‌روزرسانی‌ها گاهی نسخه قبلی را نشان می‌داد. تکرار Deploy هم الزاماً چیزی را که مرورگرها نمایش می‌دادند تغییر نمی‌داد.

تغییر انجام شده بود، اما رابط عقب مانده بود

این فقط یک ایراد ظاهری نبود. یک ایجنت می‌توانست سرور را بررسی کند و کار را موفق بداند، درحالی‌که اپراتور با دیدن مرورگر گزارش می‌داد هیچ چیز عوض نشده است. هر دو مشاهده جداگانه درست بودند، اما تجربه نهایی هنوز غلط بود.

به همین دلیل بررسی واقعی پایان کار نمی‌تواند روی پیام سبز Build یا Deploy متوقف شود. سطحی که کاربر می‌بیند باید بررسی شود.

چه کسی تنظیم اشتباه را ساخت؟ پاسخ صادقانه: نمی‌دانیم

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

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

Merlin نشانه ظاهری را به سیاست Cache رساند

پس از گزارش تکرارشونده بنیان‌گذار، Merlin—بازبین تحلیلی تیم—نسخه‌ای را که مرورگر اجرا می‌کرد با نسخه موجود روی سرور مقایسه کرد. بررسی به نحوه Cache شدن سند ورودی رسید.

فایل‌های JavaScript و CSS نسخه‌دار می‌توانند از Cache طولانی سود ببرند، چون نامشان با Build تغییر می‌کند. سند ورودی نقش دیگری دارد: باید دوباره بررسی شود تا مرورگر نام فایل‌های جدید را پیدا کند. برخورد یکسان با هر دو می‌تواند رابط دیده‌شده را عقب نگه دارد.

دو گیت ایمنی به اصلاح عجولانه اجازه ندادند

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

پس از اصلاح تغییر و رفع هشدار، Alex—تصمیم‌گیر انسانی—اجرای نهایی را تأیید کرد. مسیر قفل‌شده تغییر را اعمال کرد و بررسی نشان داد سند ورودی نسخه تازه را پیدا می‌کند، درحالی‌که دارایی‌های نسخه‌دار مزیت سرعت خود را حفظ می‌کنند.

این تجربه درباره تیم ایجنتیک چه می‌گوید؟

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

این اتفاق سه قانون را محکم‌تر کرد: وقتی مدرک نداریم مسئول نسازیم؛ اصلاح را فقط با شواهد قابل‌ردگیری پیش ببریم؛ و موفقیت را از صفحه کاربر بسنجیم، نه فقط وضعیت زیرساخت. همین نگاه مدرک‌محور در تبدیل Logbook به رادار امن محتوا هم استفاده می‌شود.

این یک اشتباه کوچک Cache بود، اما یک الگوی مفید ساخت. تیم ایجنتیک قابل‌اعتماد تیمی نیست که هیچ‌وقت خطا نمی‌کند؛ تیمی است که خطا را قابل‌دیدن می‌کند، به کنترل‌های مستقل اجازه «نه» گفتن می‌دهد و اصلاح نهایی را قابل‌تأیید نگه می‌دارد.