معماری نرم‌افزار خودمختار و APIها (APIs and Autonomic Software Architecture)
سامانه‌های خودمختار در چرخه هیجان گارتنر ۲۰۲۴ برای هوش مصنوعی معرفی شده‌اند؛ جایی که هنوز در ابتدای مسیر و در مرحله «محرک نوآوری» قرار دارند. تحلیلگران گارتنر این محرک را چنین توصیف می‌کنند: «…سامانه‌های فیزیکی یا نرم‌افزاری که خودشان را مدیریت می‌کنند، کارهای محدود به یک دامنه خاص را انجام می‌دهند و سه ویژگی اصلی دارند: خودمختاری، یادگیری و عاملیت.»
این نوشتار ساختاری برای سامانه‌های خودمختار پیشنهاد می‌کند که به‌طور ویژه برای نرم‌افزار طراحی شده است. ما آن را معماری نرم‌افزار خودمختار (ASA) می‌نامیم. این معماری کمک می‌کند دامنه‌های مرتبط با نرم‌افزار شناسایی و به یکدیگر متصل شوند و بستری ایجاد می‌کند تا تهدیدها و الگوهای استفاده تشخیص داده شده و سازگاری‌های لازم تحت کنترل انجام شوند. با این ساختار، ASA امکان خودتنظیمی برای پایداری، خودحفاظتی در برابر رخدادها و خودسازگاری برای هماهنگ شدن با ترجیحات کاربران را به نرم‌افزار می‌دهد.
ایده ASA از سیستم عصبی خودمختار (ANS) در بدن انسان الهام گرفته شده است. ANS کارکردهای درونی بدن مانند تنفس، ضربان قلب و فشار خون را تنظیم می‌کند و به‌طور خودکار تنظیماتی را که در برابر شرایط بیرونی لازم است انجام می‌دهد. ANS امکان «آلواستاز» را فراهم می‌کند؛ یعنی سازگاری سریع بدن در پاسخ به محرک‌ها و سپس بازگشت به حالت پایدار اولیه.
همان‌طور که سیستم‌های بدن ما برای مواجهه با شرایط مختلف سازگار و خودتنظیم می‌شوند، ASA نیز به نرم‌افزار اجازه می‌دهد در برابر رویدادها و روندهای استفاده، سازگاری‌های ایمن انجام دهد و بهتر با محیط خود هماهنگ شود. همچنین ASA کمک می‌کند تعیین کنیم چه زمانی یک سازگاری باید دائمی بماند یا بازگشت به حالت قبل برای ثبات سیستم مناسب‌تر است.
ASA یک هدف طبیعی برای سیستم‌های نرم‌افزاری است. اگر هوش در هوش مصنوعی بازتابی از هوش انسانی باشد، منطقی است که سیستم‌های هوشمند تلاش کنند از دیگر سامانه‌های انسانی مانند ANS نیز الگو بگیرند تا توانمندی‌های انسانی را بهتر شبیه‌سازی کنند.
توانمندسازهای سامانه‌های خودمختار
چند روند مهم در توسعه نرم‌افزار می‌تواند ASA را ممکن سازد. نخست، رویکرد «همه‌چیز به‌عنوان کد» است. یعنی نه‌تنها خود نرم‌افزار، بلکه همه چیز مربوط به ساخت، اجرای نرم‌افزار، زیرساخت، خط‌های تحویل، امنیت و… نیز در قالب کد تعریف می‌شوند.
اصل بعدی یادگیری ماشین است. ابزارهای مشاهده‌پذیری و قابلیت‌هایی مانند تشخیص الگو و تشخیص ناهنجاری کمک می‌کنند نحوه استفاده کاربران، عملکرد نرم‌افزار و رفتارهای مخرب شناسایی شوند.
خودکارسازی نیز عنصر مهمی در ASA است. ابزارهای خودکارسازی آزمون و استقرار به بلوغ رسیده‌اند و مبتنی بر کد هستند، بنابراین می‌توانند به‌طور خودکار کد را در صورت موفقیت در آزمون‌ها مستقر کنند.
آخرین و جدیدترین توانمندساز ASA، هوش مصنوعی مولد است که اکنون به سطحی رسیده که با دریافت دستورهای دقیق و بدون ابهام، قادر به تولید کد قابل‌اعتماد است.
توصیه‌هایی برای توسعه ASA
تفکیک ابعاد معماری
چارچوب ASA با تقسیم راه‌حل به ابعاد مجزا شکل می‌گیرد. مشابه معماری MVC که اجزای اصلی یک برنامه وب را جدا می‌کند، ASA کل راه‌حل نرم‌افزاری را براساس تفکیک مسئولیت‌ها ساماندهی می‌کند.
برای ساخت یک سامانه خودمختار باید ابعادی را تعیین کنید که معیارهای تحلیل مخصوص خود را دارند و با اقدامات مشخص تغییر می‌کنند. ابعاد معماری در نرم‌افزار شامل رابط کاربری، سرویس‌ها و توابع، امنیت، زیرساخت، ثبت لاگ‌ها و داده‌های نرم‌افزار است.
ماژول‌های MAR و عوامل تصمیم‌گیر
برای هر بُعد معماری، باید سه ماژول پایش، سازگاری و بازجهت‌دهی (MAR) پیاده‌سازی شود و یک عامل تصمیم‌گیر ارتباط میان آن‌ها را مدیریت کند. در ادامه عملکرد این ماژول‌ها را بررسی می‌کنیم.
ماژول پایش
این ماژول تهدیدها و الگوهای استفاده را که نشان‌دهنده نیاز به سازگاری هستند زیرنظر می‌گیرد. بُعد معماری مرتبط تعیین می‌کند چه محرک‌هایی باید در نظر گرفته شوند، آستانه‌ها چگونه باشند و چه اقدام‌هایی مجاز هستند.
به‌عنوان مثال، اگر بُعد امنیت مسئول پایش حملات brute force یا DoS باشد، تنها روی اقدام‌هایی مانند محدودسازی درخواست یا مسدود کردن IP تمرکز می‌کند.
برای ساخت این ماژول، باید ابزار پایش با پیکربندی قوی برای هشداردهی انتخاب شود یا ابزاری که امکان پرس‌وجوی زنده دارد. آستانه‌ها تنظیم می‌شوند تا در صورت عبور، هشدار ارسال شود یا پرس‌وجوهای هوشمند محرک سازگاری را شناسایی کنند. این ماژول همچنین از تحلیل‌های تاریخی و پیش‌بینی و سیاست‌های سازمانی برای تعیین اینکه سازگاری موقتی است یا دائمی استفاده می‌کند.
این ماژول جدولی از ارتباط میان محرک‌ها و اقدام‌های سازگاری دارد و اطلاعات محرک، اقدام مجاز و زمینه دامنه بُعد معماری را وارد ابزار تولید پرامپت می‌کند تا دستور لازم برای تولید کد سازگاری ایجاد شود.
عوامل تصمیم‌گیر
عوامل تصمیم‌گیر به‌عنوان دروازه‌هایی عمل می‌کنند تا مطمئن شوند سازگاری‌ها با سیاست‌های سازمانی همخوانی دارند. این عوامل با بُعد معماری مرتبط هستند.
در مثال امنیت، عامل تصمیم‌گیر ممکن است مطمئن شود تنظیمات محدودسازی در حد مجاز سازمان هستند یا برخی مشتریان در فهرست محافظت‌شده قرار دارند و نباید IP آن‌ها مسدود شود.
ماژول سازگاری
این ماژول اقدام‌های سازگاری را اجرا می‌کند و مسیر اجرای مشخصی دارد. از کد تولیدشده توسط ماژول پایش استفاده می‌شود و سپس آزمون‌ها و مراحل تأیید انجام می‌شود. در نهایت با خط تحویل سازگار با سیاست سازمان، کد مستقر می‌شود. این اطلاعات وارد ابزار تولید پرامپت می‌شود تا اسکریپت‌های آزمون و خط استقرار تولید شود.
در ادامه مثال امنیت، اگر اقدام مسدودسازی IP باشد، کد اولیه از ماژول پایش دریافت شده است. سپس آزمون‌هایی برای تأیید عملکرد و کدی برای خط استقرار تولید می‌شود.
ماژول بازجهت‌دهی
پس از استقرار سازگاری، این ماژول تعیین می‌کند تغییر دائمی است یا باید به حالت قبل بازگردد. همچنین می‌داند چه بخشی از مستندات باید به‌روزرسانی شود و چه تنظیماتی در پایش باید تغییر کند.
عامل تصمیم‌گیر میان سازگاری و بازجهت‌دهی بررسی می‌کند که سازگاری موفق بوده یا باید بازگردانده شود. اگر عملکرد پس از استقرار ضعیف باشد، بازگردانی انجام می‌شود.
اگر به مثال امنیت بازگردیم، اگر مسدود شدن IP بیش از حد باشد، این ماژول بازگردانی را انجام می‌دهد.
چگونه ASA می‌تواند برای APIها مفید باشد
یک مثال عملی بهتر مفهوم را منتقل می‌کند. فرض کنیم می‌خواهیم API بتواند به‌طور خودکار یک فیلتر جدید را که کاربران به‌طور ضمنی به آن نیاز دارند اضافه کند.
در معماری ASA برای APIها، ابعاد مختلف معماری مانند شکل زیر خواهند بود:
مثال API
فرض کنیم API زیر برای دریافت داده مشترک وجود دارد:
منبع:
/subscribers
عناصر داده:
{subscriberId، fName، lName، address، city، state، zip، subscribeDate، renewalDate، subscriptionLevel، paymentPlan، hyperLinkTransactionHistory}
فیلترهای Query/Header:
{subscriberId، state، subscribeDate، renewalDate، subscriptionLevel}
خلاصه رویداد ASA: شناسایی نیاز کاربران به فیلتر جدید و استقرار آن
ماژول پایش در بُعد قرارداد شناسایی می‌کند که برخی کاربران گاهی «zip» را به‌عنوان فیلتر ارسال می‌کنند. چون این فیلتر در قرارداد API تعریف نشده است، نادیده گرفته می‌شود. تعداد تکرار این رفتار از آستانه عبور می‌کند و سازگاری لازم تشخیص داده می‌شود. جریان کاری برای افزودن «zip» به‌عنوان فیلتر معتبر آغاز می‌شود.
جریان نمونه:
ماژول پایش
- شناسایی استفاده کاربران از ویژگی نامعتبر «zip»
- تشخیص اینکه اضافه کردن فیلتر مجاز است
- تولید پرامپت و ساخت کد برای پشتیبانی فیلتر «zip»
- تعیین دائمی بودن این سازگاری
عامل تصمیم‌گیر پایش–سازگاری
- بررسی انطباق کد با سیاست‌های سازمان
- اطمینان از اینکه تغییر برای کاربران مشکل‌ساز نیست
ماژول سازگاری
- تولید آزمون و خط تحویل براساس دستورالعمل‌های سازمان
- اجرای استقرار پس از موفقیت آزمون‌ها
- به‌روزرسانی مستندات API
عامل تصمیم‌گیر سازگاری–بازجهت‌دهی
- آزمون‌های پساتولید
- دستور مبناسازی API برای فیلتر جدید
ماژول بازجهت‌دهی
- مبناسازی جدید API
- انتشار مستندات با فیلتر «zip»
- اطلاع‌رسانی به ذی‌نفعان
- افزودن پایش‌های جدید برای فیلتر «zip»
نکات:
- فرض شده ابزار تولید آزمون خودکار در دسترس است
- ماژول پایش از طرح‌واره داده برای تشخیص امکان استفاده از «zip» استفاده کرده است
- تفکیک ابعاد معماری باعث جلوگیری از تأثیر تغییرات روی بخش‌های دیگر می‌شود
- می‌توان در هر مرحله تأیید دستی اضافه کرد
جمع‌بندی معماری نرم‌افزار خودمختار
ASA مفهومی نوظهور است، اما با بلوغ هوش مصنوعی مولد می‌تواند به واقعیت تبدیل شود. دستورالعمل‌های دقیق لازم است و هرکس علاقه‌مند باشد می‌تواند در این مسیر مشارکت کند.
در آینده، راهکارهای مدیریت API اجزای ASA را در پلتفرم خود ادغام خواهند کرد تا ایجاد معماری‌های خودمختار سریع‌تر شود. در آن زمان، طراحی API اهمیت بیشتری می‌یابد، چون باید امکان تکامل خودکار API را نیز در نظر بگیرد. باید APIها و سیاست‌های MAR طوری طراحی شوند که با استراتژی سازمان همسو بمانند.
در مسیر مهندسی نرم‌افزار، به سمت «همه‌چیز به‌عنوان کد» رفته‌ایم و اکنون با هوش مصنوعی مولد می‌توانیم به «کد همه‌چیز را ممکن می‌کند» برسیم. چابکی همیشه مهم بوده و اکنون ابزارهایی برای ساخت سامانه‌هایی داریم که تا حدی خودسازگاری و چابکی خودکار داشته باشند.
