عامل تازهٔ AWS هر هفته معماری را می‌سنجد؛ دسترسی از Business+ شروع می‌شود

AWS در ۱ اکتبر ۲۰۲۶ پیش‌نمایش عمومی AWS Well-Architected Agent را منتشر کرد. طبق یادداشت انتشار AWS، عامل محیط ابری را به‌طور پیوسته تحلیل می‌کند، پیشنهادهای زمان‌بندی‌شده را هفتگی تازه می‌کند و دسترسی به آن از طرح پشتیبانی Business+ آغاز می‌شود.

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

پیشنهادها در چه سطحی تولید می‌شوند؟

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

واحد تعیین دامنه، «پروفایل عامل» است. تیم در آن حساب‌ها، مناطق، حوزه‌های بهینه‌سازی و هدف‌های تجاری را مشخص می‌کند. راهنمای AWS برای عامل ظرفیت هر پروفایل را تا ۱۰۰ حساب و منابع همهٔ مناطق تجاری AWS توصیف می‌کند. این ظرفیت، سقف حساب‌های قابل تحلیل است و به معنی پوشش همهٔ انواع منابع در هر حساب نیست.

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

چه چیزی، چه زمانی و با کدام طرح بررسی می‌شود؟

مسیرهای پیش‌نمایش از نظر ورودی و زمان تولید نتیجه یکسان نیستند. خلاصهٔ زیر دامنهٔ هر مسیر، تناوب، خروجی و شرط دسترسی آن را کنار هم می‌گذارد:

• منابع حساب‌های انتخاب‌شده: عامل پیکربندی و داده‌های مربوط به منابع را در چرخهٔ زمان‌بندی‌شده بررسی می‌کند؛ خروجی، پیشنهاد مربوط به منبع و راهنمای اصلاح است؛ دسترسی به Business+ یا یکی از طرح‌های واجد شرایط بالاتر نیاز دارد.
• منابع مرتبط در یک برنامه: بررسی در چرخهٔ زمان‌بندی‌شده انجام می‌شود؛ خروجی، پیشنهادی با درنظرگرفتن ارتباط اجزای برنامه است؛ همان شرط طرح پشتیبانی برقرار است. پیشنهادهای این سطح هنوز در مرحلهٔ بتا هستند.
• قالب معماری و کد زیرساخت: بررسی با درخواست کاربر آغاز می‌شود و از چرخهٔ پایش زمان‌بندی‌شده جداست؛ خروجی می‌تواند یافتهٔ معماری و تغییر پیشنهادی در قالب باشد؛ همان طرح پشتیبانی واجد شرایط لازم است.

در پیش‌نمایش، بیان تناوب در بخش‌های مختلف مستندات یکدست نیست. بررسی فنی Creuto به تفاوت میان توصیف تازه‌سازی هفتگی و توضیح تولید تقریباً روزانهٔ پیشنهادهای منبع و برنامه اشاره می‌کند. بنابراین زمان دقیق رسیدن یک یافتهٔ تازه را نباید صرفاً از عبارت «هفتگی» نتیجه گرفت. نکتهٔ قطعی برای برنامه‌ریزی تغییر این است که پیشنهاد معماریِ مبتنی بر قالب، نتیجهٔ بررسی درخواستی است.

شرط Business+ و محل استقرار پروفایل

پیش‌نمایش در دسترس دارندگان Business+، Enterprise On-Ramp، Enterprise Support و Unified Operations است. حساب‌های دارای طرح Developer یا Business به عامل دسترسی ندارند. این شرط به طرح پشتیبانی مربوط است؛ قرار داشتن منابع در یکی از مناطق قابل اسکن، به‌تنهایی امکان ساخت پروفایل را فراهم نمی‌کند.

پروفایل عامل در US East (N. Virginia)، US East (Ohio) یا US West (Oregon) میزبانی می‌شود، هرچند می‌تواند منابع مناطق تجاری دیگر AWS را بررسی کند. محل میزبانی پروفایل و محل استقرار منابعِ زیر بررسی، دو موضوع جداگانه‌اند. برای تیمی که الزام‌های داخلی دربارهٔ منطقهٔ پردازش داده یا دسترسی میان حساب‌ها دارد، این تفاوت بخشی از ارزیابی پیش از راه‌اندازی است.

ساخت پروفایل همچنین مستلزم تعیین دامنهٔ حساب‌ها و تنظیم نقش‌های IAM برای خواندن اطلاعات مورد نیاز عامل است. دامنهٔ گسترده‌تر می‌تواند منابع بیشتری را وارد تحلیل کند، اما هم‌زمان مرز دسترسی را در حساب‌های بیشتری تعریف می‌کند. ارزش پیشنهاد چندحسابی زمانی روشن‌تر است که تیم بداند کدام حساب‌ها و برنامه‌ها واقعاً در پروفایل قرار گرفته‌اند و یافته‌ها به کدام بخش محیط اشاره می‌کنند.

پیشنهاد آمادهٔ اصلاح، تصمیم آمادهٔ اجرا نیست

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

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

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

بیشتر بخوانید:

• Wise Business یا Revolut Business؛ آخر هفته می‌تواند برنده را عوض کند
• Docker یا Podman؛ سرعت تقریباً برابر است، مدل دسترسی تصمیم را عوض می‌کند
• Trebellar هجده میلیون دلار گرفت؛ اجاره‌نامه‌ها خوراک عامل‌های AI شدند