چهار چرخه عمر نرمافزاری پنهان در هر دستگاه Edge مبتنی بر هوش مصنوعی (و اینکه چرا مدیریت آنها بهعنوان یک چرخه واحد، ناوگان شما را با مشکل مواجه میکند)
در بخش بزرگی از دهه گذشته، مدیریت دستگاههای Edge عمدتاً بر یک وظیفه متمرکز بود: مدیریت و نگهداری تصویر سیستمعامل (Firmware Image). تیمها نسخه جدید را توسعه میدادند، روی دستگاهها مستقر میکردند، آن را اعتبارسنجی میکردند و انتظار داشتند تا زمان انتشار بهروزرسانی بعدی، نیازی به تغییر خاصی نباشد. در آن زمان، دستگاهها و بارهای کاری ساده بودند و مدیریت نرمافزار نیز پیچیدگی چندانی نداشت.
اما آن دوران به پایان رسیده است.
دستگاه Edge که امروز در حال استقرار آن هستید، در واقع یک رایانه لینوکسی کوچک و قدرتمند است. به احتمال زیاد به GPU یا شتابدهنده پردازش عصبی (NPU) مجهز است، کانتینرها را اجرا میکند، مدلهای هوش مصنوعی را میزبانی میکند و دیگر تنها با یک نرمافزار سروکار ندارد. اکنون چهار بخش نرمافزاری مستقل روی آن اجرا میشوند که هرکدام چرخه عمر، زمانبندی، ریسکها و حتی تیم مسئول خود را دارند.
اگر در مدیریت ناوگان (Fleet Management) این چهار بخش را بهعنوان یک جزء واحد در نظر بگیرید، ممکن است در پروژههای کوچک مشکلی احساس نکنید؛ اما با افزایش تعداد دستگاهها، مشکلات بهصورت تصاعدی ظاهر میشوند. بسیاری از سازمانها زمانی متوجه این مسئله میشوند که دیگر مهاجرت به یک معماری صحیح، ساده و کمهزینه نیست.
در ادامه بررسی میکنیم که درون هر دستگاه Edge مبتنی بر هوش مصنوعی چه اتفاقی رخ میدهد و چرا شناخت این چهار چرخه عمر اهمیت زیادی دارد.
چرخه عمر اول: سیستمعامل (Operating System)
سیستمعامل، کندترین لایه در کل پشته نرمافزاری است. فرقی نمیکند از Ubuntu Core، نسخه سختسازیشده Yocto، Talos یا یک توزیع سفارشی لینوکس استفاده کنید؛ در دستگاههای صنعتی Edge معمولاً بهروزرسانی سیستمعامل در بازههای زمانی چندماهه یا حتی فصلی انجام میشود، نه روزانه.
نسخههای اصلی سیستمعامل بهندرت منتشر میشوند و حتی وصلههای امنیتی نیز قبل از استقرار باید بهدقت آزمایش شوند، زیرا در صورت بروز خطا، دستگاه ممکن است تا زمان مراجعه فیزیکی یک تکنسین از دسترس خارج شود.
به همین دلیل، بهروزرسانی سیستمعامل فرآیندی حساس، پرریسک و زمانبر است. امروزه در بسیاری از توزیعهای تغییرناپذیر (Immutable)، استفاده از بهروزرسانی اتمی (Atomic Update) همراه با قابلیت Rollback به الگوی رایج تبدیل شده است، هرچند بسیاری از سامانههای صنعتی هنوز از لینوکسهای سنتی مبتنی بر مدیریت بستهها استفاده میکنند.
مسئولیت این بخش معمولاً بر عهده تیم فناوری اطلاعات (IT) یا تیم مهندسی پلتفرم است و ریسک آن بسیار بالاست؛ زیرا اگر بهروزرسانی سیستمعامل با شکست مواجه شود، ممکن است کل دستگاه غیرقابل استفاده شود.
نکته مهم اینجاست که اگرچه بهروزرسانی سیستمعامل نیازمند برنامهریزی دقیق و انتشار مرحلهای است، اما معمولاً بیشترین حجم عملیات روزمره در این لایه انجام نمیشود. عمده فعالیتهای عملیاتی در لایههای بالاتر اتفاق میافتد.
چرخه عمر دوم: محیط اجرای کانتینر (Container Runtime)
لایه بعدی، Container Runtime است؛ نرمافزاری مانند Docker، Podman یا containerd که معمولاً همراه با توزیعهای سبک Kubernetes مانند KubeSolo مورد استفاده قرار میگیرد.
این لایه بین سیستمعامل و برنامه کاربردی قرار دارد و هرچند بهروزرسانی آن نسبت به سیستمعامل بیشتر است، اما همچنان بسیار کمتر از خود برنامه انجام میشود.
نسخههای جدید Runtime ممکن است تغییرات ناسازگار ایجاد کنند و وصلههای امنیتی آن نیز معمولاً با فاصله زمانی بیشتری نسبت به نسخههای جدید نرمافزار منتشر میشوند.
مدیریت این بخش نیز معمولاً بر عهده تیم مهندسی پلتفرم است. توسعهدهندگان نرمافزار اغلب مستقیماً با این لایه سروکار ندارند، اما تغییر در Runtime میتواند رفتار شبکه، نحوه اتصال Volumeها یا سیاستهای Restart کانتینرها را تغییر دهد. در بسیاری از مواقع، تیم توسعه زمانی متوجه این تغییرات میشود که برنامه بهطور ناگهانی رفتار متفاوتی از خود نشان دهد.
مدیریت Runtime دشوار است، زیرا برخلاف یک محصول نهایی، تنها یک وابستگی (Dependency) محسوب میشود. هیچ تیمی صرفاً برای بهروزرسانی Runtime برنامهریزی نمیکند؛ این کار معمولاً در پاسخ به آسیبپذیریهای امنیتی یا نیازهای جدید نرمافزار انجام میشود. از آنجا که این تغییرات وابسته به سایر اجزای سیستم هستند، زمان انجام آنها معمولاً با برنامه انتشار هیچ تیمی همسو نیست.
چرخه عمر سوم: کانتینر برنامه کاربردی (Application Container)
بیشترین حجم عملیات روزانه در همین لایه انجام میشود.
برنامههای اجراشده روی دستگاههای Edge معمولاً بهصورت هفتگی یا حتی با فاصله زمانی کمتر بهروزرسانی میشوند تا قابلیتهای جدید اضافه شوند، خطاها برطرف شوند یا تنظیمات تغییر کنند.
زمان انتشار این نسخهها توسط تیم توسعه نرمافزار تعیین میشود، نه بر اساس چرخه عمر سختافزار.
بهطور معمول، هر بهروزرسانی مستقل کانتینر ریسک کمی دارد؛ کافی است تصویر جدید دریافت شود، کانتینر مجدداً راهاندازی گردد و لاگها بررسی شوند. اما وقتی تعداد دستگاهها و دفعات بهروزرسانی افزایش پیدا میکند، همین ریسکهای کوچک نیز روی هم انباشته میشوند.
در پروژههای کوچک، استقرار دستی نسخههای جدید امکانپذیر است؛ اما زمانی که صدها یا هزاران سایت درگیر باشند، خودکارسازی (Automation) به یک ضرورت تبدیل میشود.
در چنین مقیاسی، سامانه استقرار باید بتواند بین این دو وضعیت تفاوت قائل شود:
- این بهروزرسانی روی ۴۸۰ دستگاه با موفقیت انجام شده است.
- این بهروزرسانی روی ۲۰ دستگاه در یک منطقه جغرافیایی مشخص با همان خطا مواجه شده است.
در این لایه، قابلیت Rollback سریع اهمیت بسیار زیادی دارد، زیرا هرگونه خطا مستقیماً عملکرد نرمافزار را تحت تأثیر قرار میدهد.
چرخه عمر چهارم: مدل هوش مصنوعی (AI Model)
مدل هوش مصنوعی همان بخشی است که اغلب ابزارهای سنتی مدیریت ناوگان، اساساً برای مدیریت آن طراحی نشدهاند.
مدل هوش مصنوعی یک موجودیت مستقل از برنامهای است که از آن استفاده میکند. این مدل دارای فرآیند آموزش، نسخهبندی، اعتبارسنجی و حتی مکانیزم بازگشت به نسخه قبل (Rollback) مخصوص به خود است.
برای مثال، یک مدل بینایی ماشین که در خط تولید فعالیت میکند، ممکن است هر هفته با استفاده از دادههای آموزشی جدید بهبود یافته و نسخه جدیدی از آن منتشر شود. در مقابل، یک مدل نگهداری و تعمیرات پیشگویانه (Predictive Maintenance) شاید با فاصله زمانی بیشتری بهروزرسانی شود، اما پیش از انتشار نیازمند اعتبارسنجی بسیار سختگیرانهتری باشد، زیرا یک مدل ضعیف میتواند پیشبینیهای اشتباهی درباره خرابی تجهیزات ارائه دهد.
در نتیجه، زمانبندی بهروزرسانی مدل کاملاً به نوع کاربرد آن بستگی دارد، نه به سختافزار یا دستگاه Edge.
موضوع مالکیت این لایه نیز با سایر چرخههای عمر متفاوت است. مسئولیت مدلهای هوش مصنوعی معمولاً بر عهده تیم علوم داده (Data Science) یا مهندسان یادگیری ماشین (ML Engineering) است، نه تیم فناوری اطلاعات یا مهندسی پلتفرم.
همچنین انتقال مدل از مرحله «آماده برای انتشار» به مرحله «استقرار روی کل ناوگان» دقیقاً همان نقطهای است که بسیاری از سازمانها ابزار مناسبی برای مدیریت آن در اختیار ندارند.
خرابی مدلهای هوش مصنوعی نیز با خرابی نرمافزار تفاوت دارد. اگر برنامه دچار مشکل شود، معمولاً بلافاصله متوجه خواهید شد؛ اما عملکرد ضعیف یک مدل ممکن است بهصورت کاملاً پنهان کیفیت استنتاج (Inference) را کاهش دهد و اثر آن تنها دو هفته بعد، مثلاً در افزایش نرخ محصولات مردود خط تولید، مشخص شود؛ نه در لاگهای سیستم.
این چهار چرخه، یک فرآیند واحد نیستند
بیشتر ابزارهای سنتی مدیریت ناوگان بر اساس یک مفهوم طراحی شدهاند: تصویر دستگاه (Device Image).
در این رویکرد، یک Image ساخته میشود، امضا میشود، روی دستگاهها ارسال میشود و سپس اجرای صحیح آن تأیید میگردد.
این مدل ساده، قابل فهم و سالها کارآمد بود؛ اما در مواجهه با دستگاههای Edge مجهز به هوش مصنوعی دیگر پاسخگوی نیازها نیست.
اگر سیستمعامل، Runtime، برنامه کاربردی و مدل هوش مصنوعی را در قالب یک Image واحد بستهبندی کنید، حداقل با سه مشکل اساسی روبهرو خواهید شد.
۱. سرعت انتشار شما به کندترین لایه محدود میشود
اگر تنها بتوانید هر سه ماه یکبار Image جدید منتشر کنید، زیرا بهروزرسانی سیستمعامل نیازمند آزمایشهای طولانی است، تیم توسعه نرمافزار دیگر قادر نخواهد بود هر هفته قابلیت جدید منتشر کند.
در چنین شرایطی، توسعهدهندگان یا مجبور میشوند با استفاده از اسکریپتها و اتصال SSH محدودیتها را دور بزنند یا انتشار قابلیتهای جدید به تعویق خواهد افتاد.
۲. فرآیند Rollback بسیار پیچیده میشود
بازگرداندن یک مدل هوش مصنوعی نباید نیازمند تغییر سیستمعامل باشد.
همچنین بازگشت از یک نسخه Runtime نباید باعث حذف آخرین نسخه برنامه کاربردی شود.
اما زمانی که همه اجزا در یک Image واحد قرار گرفته باشند، Rollback به یک عملیات «همه یا هیچ» تبدیل میشود و حتی تیمهایی که هیچ نقشی در ایجاد مشکل نداشتهاند نیز تحت تأثیر قرار میگیرند.
۳. مسئولیتها مبهم میشوند
اگر Image یکپارچه با مشکل مواجه شود، چه کسی مسئول است؟
- تیم IT به دلیل سیستمعامل؟
- تیم مهندسی پلتفرم به دلیل Runtime؟
- تیم توسعه نرمافزار به دلیل برنامه کاربردی؟
- یا تیم علوم داده به دلیل مدل هوش مصنوعی؟
ادغام همه اجزا در یک بسته واحد، مرز مسئولیتها را از بین میبرد و پاسخگویی را دشوار میکند.
نتیجه این وضعیت معمولاً قابل پیشبینی است. تیمها برای بخشهایی که بهسرعت تغییر میکنند، ابزار مدیریت ناوگان را کنار میگذارند و با استفاده از اسکریپتهای اختصاصی، ابزارهای پراکنده استقرار و دسترسی SSH، فرآیندهای جداگانهای ایجاد میکنند. در نهایت، ابزار مدیریت ناوگان تنها وظیفه بهروزرسانی سیستمعامل را بر عهده خواهد داشت و سایر بخشها خارج از کنترل آن مدیریت میشوند.
راهکار چیست؟
هر چرخه عمر را بهعنوان یک موجودیت مستقل مدیریت کنید.
راهکار مدیریت ناوگان باید این امکان را فراهم کند که:
- سیستمعامل مستقل از Runtime بهروزرسانی شود.
- Runtime مستقل از برنامه کاربردی نسخه جدید دریافت کند.
- برنامه کاربردی بدون وابستگی به مدل هوش مصنوعی منتشر شود.
- مدل هوش مصنوعی نیز چرخه انتشار اختصاصی خود را داشته باشد.
هر یک از این چهار لایه باید دارای موارد زیر باشند:
- خط لوله استقرار (Deployment Pipeline) مستقل
- مکانیزم Rollback اختصاصی
- ابزارهای مانیتورینگ و مشاهدهپذیری (Observability) مستقل
در عمل، این رویکرد معمولاً به معنی جداسازی کامل این چهار لایه است.
سیستمعامل بهعنوان یک Artifact مستقل مدیریت میشود و مطابق توصیه توزیع لینوکس بهروزرسانی خواهد شد. بسیاری از استقرارهای صنعتی به سمت استفاده از سیستمعاملهای تغییرناپذیر (Immutable OS) و Imageهای تکفایلی حرکت کردهاند، هرچند روشهای قدیمی مبتنی بر پارتیشنهای A/B همچنان استفاده میشوند. برای نمونه، توزیع Nova8 از Unified Kernel Image (UKI) استفاده میکند و زمان بهروزرسانی را به کمتر از ۴۰ ثانیه رسانده است.
Container Runtime نیز بهعنوان یک وابستگی مستقل نسخهبندی میشود و همانند سایر اجزای زیرساخت مدیریت خواهد شد.
کانتینرهای برنامه کاربردی از طریق یک لایه Orchestration منتشر میشوند که از قابلیتهایی مانند Rolling Deployment، Canary Deployment و Rollback مستقل برای هر سرویس پشتیبانی میکند.
مدل هوش مصنوعی نیز باید خط لوله انتشار اختصاصی خود را داشته باشد؛ معمولاً با استفاده از Model Registry و مجموعهای از مراحل اعتبارسنجی که پیش از استقرار مدل اجرا میشوند.
البته ابزارهای مورد استفاده بسته به زیرساخت هر سازمان متفاوت خواهند بود؛ اما اصل موضوع تغییری نمیکند:
اجزایی که با سرعتهای متفاوت تغییر میکنند را هرگز در یک بسته واحد قرار ندهید.
جمعبندی
اگر امروز در حال استقرار دستگاههای Edge مجهز به هوش مصنوعی هستید، اما همچنان همه اجزای نرمافزاری را در قالب یک Image واحد مدیریت میکنید، با مشکلی روبهرو هستید که هرچه تعداد دستگاههای شما بیشتر شود، آثار آن نیز شدیدتر خواهد شد.
این چهار چرخه عمر، چه ابزارهای فعلی شما آنها را به رسمیت بشناسند و چه نه، واقعیتی انکارناپذیر هستند و تیمهایی که مسئول مدیریت آنها هستند، این موضوع را بهخوبی میدانند.
چالش اصلی در اینجا بیش از آنکه فنی باشد، سازمانی و مدیریتی است. هر یک از این چهار چرخه معمولاً متعلق به تیمی متفاوت با مسئولیتها و اهداف مستقل است.
بنابراین، مهمترین سؤال این نیست که از چه ابزاری استفاده میکنید؛ بلکه این است که مدل عملیاتی سازمان شما این چهار چرخه را بهعنوان یک موجودیت واحد مدیریت میکند یا چهار چرخه مستقل؟
اگر هنوز همه آنها را یک چرخه واحد در نظر میگیرید، احتمالاً مشکلات از همین حالا در زیرساخت شما وجود دارند؛ حتی اگر هنوز آثار آنها بهطور کامل نمایان نشده باشد.
بدون دیدگاه