پیش از انتخاب Private AI باید مسیر توسعه انتقال داده و پایان همکاری روشن باشد

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

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

رشد را با واژه نامحدود توصیف نکنیم

هیچ زیرساختی ظرفیت نامحدود و فوری ندارد. در مدل Multi Tenant، منابع میان چند سازمان برنامه‌ریزی می‌شوند و در مدل اختصاصی نیز توسعه به فضا، برق، شبکه و زمان تأمین وابسته است. وعده کلی «هر زمان خواستید توسعه می‌دهیم» باید به فرایند و بازه تبدیل شود.

سازمان باید آستانه‌های هشدار، ظرفیت رزروشده، امکان Burst و Lead Time توسعه را بداند. اگر یک پروژه تاریخ اوج مشخص دارد، درخواست باید چه زمانی ثبت شود؟ اگر ظرفیت موجود کافی نبود، گزینه موقت چیست؟ پاسخ این پرسش‌ها در برنامه رشد می‌آید.

سناریوی مصرف پایه و اوج بسازیم

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

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

ظرفیت رزروشده و اشتراکی را مقایسه کنیم

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

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

آستانه توسعه را پیش از رسیدن به سقف تعیین کنیم

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

آستانه یک درصد عمومی برای همه نیست. سرعت رشد، Lead Time و حساسیت کاربرد بر آن اثر دارند. مسئول پیگیری نیز باید مشخص باشد؛ هشدار بدون مالک به تصمیم تبدیل نمی‌شود.

هزینه توسعه باید در مدل مالی دیده شود

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

اعداد نباید بر فرض استفاده کامل و دائمی بنا شوند. دوره‌های بلااستفاده، پروژه‌های متوقف و امکان آزادسازی ظرفیت نیز دیده می‌شوند. Showback به واحدها کمک می‌کند رزروهای غیرضروری را کاهش دهند.

انتقال از Multi Tenant به زیرساخت اختصاصی

ممکن است سازمان با سرویس شروع کند و پس از تثبیت مصرف یا افزایش حساسیت، به محیط اختصاصی نیاز داشته باشد. این انتقال باید از نظر داده، تنظیمات، هویت و وقفه بررسی شود. همه اجزای محیط الزاماً قابل انتقال مستقیم نیستند و برخی باید بازسازی شوند.

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

انتقال از اختصاصی به سرویس نیز ممکن است

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

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

فهرست دارایی‌های قابل خروج را بنویسیم

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

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

قالب و روش انتقال اهمیت عملی دارند

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

Checksum یا روش کنترل صحت نشان می‌دهد داده کامل رسیده است. مسئول تأیید در مقصد و مدت نگهداری نسخه موقت در مبدأ نیز تعیین می‌شوند. انتقال پایان نمی‌یابد تا سازمان دریافت و قابلیت استفاده را تأیید کند.

هزینه خروج را از ابتدا شفاف کنیم

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

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

حذف داده پس از پایان همکاری چگونه اثبات می‌شود

پس از تحویل و تأیید، نسخه‌های اصلی، Replica، Cache و Backup طبق سیاست حذف می‌شوند. ممکن است حذف از Backup به پایان دوره نگهداری وابسته باشد. این زمان و کنترل دسترسی تا حذف نهایی باید در قرارداد بیان شود.

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

پایان همکاری نباید دسترسی را باز بگذارد

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

مالک هر مرحله و نقطه تأیید مشخص است. گزارش نهایی باید نشان دهد چه دسترسی‌هایی لغو و چه مواردی به دلیل استثنا باقی مانده‌اند. حساب پیمانکار و یکپارچه‌سازی‌های ماشینی نیز فراموش نشوند.

تداوم در دوره انتقال را طراحی کنیم

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

نقطه Freeze، آخرین همگام‌سازی، آزمون مقصد و تصمیم Rollback باید نوشته شوند. اگر معیار رد شد، بازگشت چگونه انجام می‌شود؟ داشتن نسخه مبدأ تا پایان تأیید می‌تواند بخشی از بیمه انتقال باشد.

SLA در دوره خروج نیز ادامه دارد

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

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

قفل‌شدگی فقط به فناوری مربوط نیست

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

همه وابستگی‌ها بد نیستند. استفاده از قابلیت اختصاصی ممکن است ارزش زیادی بسازد. تصمیم آگاهانه یعنی منفعت آن از هزینه تغییر بیشتر باشد و مسیر جبرانی مشخص شود. وعده «بدون هیچ Lock In» معمولاً دقیق نیست.

آزمون خروج کوچک انجام دهیم

پیش از گسترش، یک پروژه آزمایشی را پایان دهید. داده نمونه، گزارش و تنظیمات قابل حمل را دریافت و در محل جدا بررسی کنید. سپس فرایند حذف و بستن دسترسی را ثبت کنید. این آزمون ابهام‌های قرارداد و ابزار را آشکار می‌کند.

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

حاکمیت تغییر باید رشد را همراهی کند

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

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

گزارش دوره‌ای تصمیم رشد را آسان می‌کند

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

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

نقش راگا در طراحی چرخه عمر

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

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

مالکیت داده و خروجی‌ها را صریح کنیم

قرارداد باید میان داده ورودی سازمان، خروجی تولیدشده، Metadata عملیاتی و دانش یا ابزار ارائه‌دهنده تفاوت بگذارد. مالکیت، حق استفاده و محدودیت نگهداری هر گروه روشن می‌شوند. عبارت کلی «تمام داده متعلق به مشتری است» ممکن است مرز فنی لازم را توضیح ندهد.

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

تغییر شرایط خدمت باید فرایند داشته باشد

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

ارائه‌دهنده نیز باید بتواند اصلاح امنیتی یا تغییر ضروری را اجرا کند. فرایند تغییر میان ثبات و نگهداری سالم تعادل ایجاد می‌کند. تغییرهای اضطراری گزارش بعدی و تغییرهای برنامه‌ریزی‌شده تقویم و تأیید لازم دارند.

تقویم تصمیم از فشار پایان قرارداد جلوگیری می‌کند

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

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

حذف امن را با دوره نگهداری هماهنگ کنیم

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

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

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

تصمیم مدیر فناوری

سازمان تصمیم می‌گیرد پایلوت را در مدل Multi Tenant آغاز کند، اما سه پیوست به توافق اضافه می‌شود: برنامه ظرفیت و Lead Time، فهرست دارایی‌های قابل انتقال و چک‌لیست خروج. یک آستانه مصرف برای بررسی زیرساخت اختصاصی نیز تعیین می‌گردد.

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

چک‌لیست تصمیم‌گیری

• نیاز و مالک کسب‌وکاری مشخص باشد.
• نوع داده و محدودیت دسترسی ثبت شود.
• ظرفیت پایه و اوج مصرف جدا محاسبه شوند.
• مدل اختصاصی یا Multi‑Tenant با معیار مشترک مقایسه شود.

سؤالات متداول

Private AI را از کجا شروع کنیم؟

از یک نیاز تأییدشده، مالک مشخص، نوع داده، الگوی مصرف و معیار موفقیت شروع کنید؛ نه از فهرست تجهیزات.

زیرساخت اختصاصی بهتر است یا سرویس Multi‑Tenant؟

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

ظرفیت Private AI چگونه تعیین می‌شود؟

هم‌زمانی، زمان پاسخ، حجم داده، دسترس‌پذیری، رشد و ظرفیت رزرو باید کنار هم سنجیده شوند.

منابع

[۱] Microsoft Learn — رویکردهای معماری منابع در راهکارهای Multi Tenant مشاهده منبع

[۲] Microsoft Learn — ملاحظات چرخه عمر Tenant مشاهده منبع

مطالب مرتبط در سایت راگا

برای تکمیل این مسیر، راهنمای Private AI روی VCF و مقاله «دموی زیرساخت Private AI باید مسیر دریافت ظرفیت کنترل دسترسی توسعه و پشتیبانی را نشان دهد» را ببینید.