دریافت زیرساخت Private AI به‌صورت سرویس، امکان بررسی شیوه متفاوت تأمین منابع را پیش روی مدیران می‌گذارد. می‌توان درباره ظرفیت پایه و شرایط ظرفیت بیشتر گفت‌وگو کرد. اما نتیجه اقتصادی و اجرایی این انتخاب به الگوی مصرف، تعهدات ارائه‌دهنده و زمان آماده‌سازی وابسته است. قبل از مقایسه هزینه، باید شکل واقعی نیاز را بفهمیم.
در این راهنما، موضوع از چند زاویه بررسی می‌شود: میانگین مصرف همه نیاز را نشان نمی‌دهد، برنامه کاری واحدها را کنار هم بگذاریم، ظرفیت پایه را برای نیاز قابل اتکا تعریف کنیم. هدف این است که مخاطب پس از مطالعه، معیارهای تصمیم‌گیری و اقدام بعدی را روشن‌تر ببیند.
در این مقاله می‌خوانید
- میانگین مصرف همه نیاز را نشان نمی‌دهد
- برنامه کاری واحدها را کنار هم بگذاریم
- ظرفیت پایه را برای نیاز قابل اتکا تعریف کنیم
- نیاز بیشتر را از قبل اعلام کنیم یا هنگام مصرف درخواست بدهیم
میانگین مصرف همه نیاز را نشان نمی‌دهد
مدیر مالی در ابتدا میانگین مصرف را مبنا قرار داده است. مدیر فناوری توضیح می‌دهد که میانگین می‌تواند ساعت‌های کم‌مصرف و پراستفاده را با هم ترکیب کند و فشار یک بازه حساس را پنهان سازد. اگر سازمان در همان بازه نتواند کار خود را انجام دهد، مناسب بودن میانگین برای بودجه‌بندی کمکی به عملیات نمی‌کند.
مسیر مطالعه Private AI: این مطلب بخشی از مرکز و نقشه راه Private AI راگا است؛ برای دیدن موضوعات مرتبط و مسیر کامل مطالعه از صفحه مادر شروع کنید.
در طرف مقابل، دیدن فقط بالاترین مصرف نیز تصویر ناقصی می‌دهد. ممکن است آن مقدار به یک رخداد استثنایی، آزمون نامتعارف یا کاری مربوط باشد که دیگر تکرار نمی‌شود. تأمین دائمی منابع بر اساس چنین نقطه‌ای می‌تواند ظرفیت بلااستفاده ایجاد کند. بنابراین باید علت و تکرار هر اوج مهم ثبت شود.
گزارش مفید برای تصمیم، زمان مصرف را کنار مقدار آن نشان می‌دهد. مدیران باید بفهمند کدام نیاز روزمره است، کدام دوره‌ای است و کدام هنوز فقط یک احتمال است. این تفکیک به بحث درباره ظرفیت پایه، منابع موقت یا رزرو قبلی معنا می‌دهد.
برنامه کاری واحدها را کنار هم بگذاریم
گاهی هر واحد به‌تنهایی الگوی مصرف قابل قبولی دارد، اما درخواست‌های آن‌ها در یک زمان جمع می‌شود. در سازمان، دو تیم پایان دوره کاری خود را برای روز مشابهی برنامه‌ریزی کرده‌اند. تیم سوم هم در همان بازه یک فعالیت جدید را آغاز می‌کند. بدون تقویم مشترک، فشار نهایی زیرساخت در هیچ‌کدام از درخواست‌های جداگانه دیده نمی‌شود.
مدیر فناوری لازم نیست از ابتدا برنامه همه روزهای سال را بگیرد. می‌تواند با زمان‌های حساس نزدیک شروع کند و از هر واحد بپرسد کدام فعالیت واقعاً به ساعت مشخصی وابسته است. بعضی کارها انعطاف دارند و بعضی ندارند. همین تفاوت به سازمان کمک می‌کند نیاز فوری را از استفاده قابل جابه‌جایی جدا کند.
اگر جابه‌جایی بخشی از فعالیت ممکن باشد، اثر آن باید با واحد مربوط بررسی شود. انتقال کار به ساعت دیگر نباید فقط برای بهتر شدن نمودار زیرساخت انجام شود و هزینه پنهانی به عملیات تحمیل کند. تصمیم باید مجموع زمان تحویل، هزینه و محدودیت نیروی انسانی را در نظر بگیرد.
ظرفیت پایه را برای نیاز قابل اتکا تعریف کنیم
ظرفیت پایه، بخشی از منابع است که سازمان برای استفاده معمول خود روی آن حساب می‌کند. مقدار آن باید با نیاز واقعی و سطح خدمت موردانتظار هماهنگ باشد. انتخاب عددی بسیار پایین فقط برای کوچک شدن مبلغ اولیه، می‌تواند به درخواست‌های مکرر افزایش یا انتظار ناخواسته منجر شود.
مدیران در این بررسی توافق می‌کنند ابتدا نیاز منظم واحد آغازین را مشخص کنند. سپس برای فعالیت‌های دوره‌ای، پیشنهاد جداگانه بخواهند. در این مقایسه، نوع منابع و شرایط استفاده باید سازگار باشند تا افزودن ظرفیت در زمان موردنیاز عملاً امکان‌پذیر باشد. منابع مختلف لزوماً جای یکدیگر را نمی‌گیرند.
ارائه‌دهنده باید توضیح دهد کدام مقدار از ظرفیت، در چه زمان و تحت چه شرایطی در اختیار سازمان قرار خواهد گرفت. اگر بخشی از منابع رزروشده است، شرایط رزرو باید روشن باشد. اگر استفاده از ظرفیت اضافه به موجود بودن آن وابسته است، همین محدودیت باید در تصمیم مدیران دیده شود.
نیاز بیشتر را از قبل اعلام کنیم یا هنگام مصرف درخواست بدهیم
دو نوع نیاز در جلسه مطرح می‌شود. یکی افزایش قابل پیش‌بینی پایان دوره است و دیگری درخواست ناگهانی که ممکن است در هر زمانی رخ دهد. این دو لزوماً شرایط تأمین یکسانی ندارند. برای نیاز قابل پیش‌بینی، سازمان می‌تواند درباره رزرو و زمان آماده‌سازی مذاکره کند. برای نیاز ناگهانی، باید محدوده پاسخ‌گویی و ظرفیت قابل اتکا معلوم باشد.
عنوان «قابل توسعه» برای تصمیم کافی نیست. توسعه چه مقدار زمان می‌برد؟ چه کسی آن را تأیید می‌کند؟ آیا نیاز به توقف یا تغییر در محیط وجود دارد؟ آیا ظرفیت موردنظر با منابع موجود سازگار است؟ پاسخ‌ها باید پیش از رسیدن به ساعت شلوغ مشخص شوند.
در تعریف عمومی رایانش ابری، NIST به گسترش و کاهش منابع متناسب با تقاضا اشاره می‌کند. [۱] بااین‌حال، این ویژگی را نمی‌توان بدون بررسی به هر پیشنهاد تجاری تعمیم داد. سازمان باید شرایط همان سرویس را ببیند و درباره محدوده تغییر منابع توافق کند، به‌خصوص وقتی زمان انجام کار قابل جابه‌جایی نیست.
هزینه کم‌مصرف بودن را درست حساب کنیم
مدیر مالی می‌خواهد بداند در روزهای خلوت چه هزینه‌ای باقی می‌ماند. در زیرساخت اختصاصی، بخشی از هزینه خرید و نگهداری مستقل از مقدار استفاده است. در سرویس نیز ممکن است مبلغ پایه، فضای نگهداری داده یا تعهد رزرو پابرجا باشد. بنابراین کاهش مصرف همیشه به همان نسبت مبلغ پرداختی را کم نمی‌کند.
برای مقایسه، باید روشن شود چه هزینه‌ای ثابت است، چه چیزی با تغییر ظرفیت عوض می‌شود و چه بخشی به زمان استفاده وابسته است. این تقسیم‌بندی از ساختن درصد صرفه‌جویی بر اساس ساعت‌های خالی جلوگیری می‌کند. ظرفیت بلااستفاده یک مشاهده مهم است، اما تبدیل آن به مبلغ قابل کاهش نیاز به شرایط واقعی قیمت‌گذاری دارد.
مدیر مالی از تیم می‌خواهد پیشنهاد سرویس را برای چند وضعیت مصرف دریافت کند. نیاز معمول، دوره پراستفاده و کاهش فعالیت پس از آن، هرکدام باید با فرض مشخص بررسی شوند. قیمت بازار یا تعرفه فرضی وارد محاسبه نمی‌شود؛ ارقام باید از پیشنهاد معتبر و دامنه خدمت یکسان بیایند.
یک مقایسه بدون عددسازی انجام دهیم
برای سازمان می‌توان سه گزینه روی میز گذاشت. گزینه نخست، تأمین ثابت ظرفیت کافی برای دوره پراستفاده است. گزینه دوم، ظرفیت پایه همراه با منابع بیشتر برای زمان‌های قابل پیش‌بینی است. گزینه سوم، شروع با ظرفیت پایه و بررسی افزایش در هنگام نیاز است. این سه گزینه در میزان اطمینان و تعهد زمانی یکسان نیستند.
اگر تأخیر در انجام فعالیت پیامد مهمی دارد، گزینه سوم تنها وقتی قابل اتکاست که زمان تأمین و مقدار منابع اضافه با آن نیاز هماهنگ باشد. در غیر این صورت، پایین بودن مبلغ اولیه ممکن است در عمل ارزش چندانی نداشته باشد. مدیران باید احتمال و پیامد در دسترس نبودن منابع را کنار هزینه ببینند.
گزینه دوم نیز به برنامه‌ریزی نیاز دارد. اگر واحدها زمان تقاضا را دیر اعلام کنند، مزیت رزرو قبلی از بین می‌رود. در گزینه نخست، سازمان هزینه آماده بودن ظرفیت را می‌پذیرد و باید بسنجد این آمادگی برایش چه ارزشی دارد. هیچ گزینه‌ای بدون شناخت نیاز، برنده همیشگی این مقایسه نیست.
مصرف بالای یک مشتری چه اثری بر بستر مشترک دارد
وقتی زیرساخت با مدل Multi-Tenant ارائه می‌شود، بخشی از منابع ممکن است میان چند مشتری مشترک باشد. سازمان باید بداند سهم و شرایط استفاده‌اش چگونه مشخص می‌شود. اگر مشتری دیگری در همان زمان مصرف زیادی داشته باشد، کنترل اثر آن بر خدمت ما بخشی از طراحی و مدیریت سرویس است.
راهنمای معماری مایکروسافت نیز برای منابع مشترک، مدیریت و پایش مصرف را ضروری می‌داند. [۲] برای مدیر خریدار، سؤال ساده است: ظرفیتی که روی آن حساب کرده‌ایم در بازه موردنیاز چگونه تأمین می‌شود و اگر شرایط توافق‌شده محقق نشد، مسیر پیگیری چیست؟
این پرسش نباید به درخواست منابع نامحدود و همواره آماده تبدیل شود. هر سرویس محدوده‌ای دارد که باید مشخص باشد. اگر سازمان به اطمینان یا جداسازی بیشتری نیاز دارد، لازم است گزینه رزرو یا ظرفیت اختصاصی، در صورت امکان ارائه، همراه با هزینه و زمان آن بررسی شود.
یک روز کندی را به نیاز دائمی تبدیل نکنیم
در دوره بررسی، یک روز زمان انجام کار طولانی‌تر می‌شود. پیش از افزایش منابع، تیم فناوری باید ببیند علت از کجا بوده است. شاید هم‌زمانی بیشتر شده، شاید ارتباطات مشکل داشته یا بخشی از فعالیت متفاوت از قبل اجرا شده است. تأمین ظرفیت بیشتر وقتی ارزش دارد که به علت مرتبط باشد.
مدیرعامل لازم نیست گزارش فنی مفصل را خودش تحلیل کند. او باید از تیم یک توضیح قابل تصمیم‌گیری بخواهد: چه چیزی رخ داده، چه شاهدی برای علت وجود دارد و هر اقدام چه هزینه و اثری دارد؟ اگر علت هنوز معلوم نیست، همان ابهام باید گفته شود تا تصمیم مالی بر پایه حدس قطعی شکل نگیرد.
پس از هر تغییر نیز نتیجه بررسی شود. اگر افزایش ظرفیت زمان موردانتظار را بهتر نکرد، ادامه همان مسیر نیاز به بازنگری دارد. ثبت اثر تغییر، کمک می‌کند سازمان به‌تدریج اندازه واقعی نیاز خود را بشناسد و بودجه را بر اساس تجربه قابل استناد تنظیم کند.
درخواست تغییر را به یک مسئول مشخص بسپاریم
مدیر مالی با انعطاف ظرفیت موافق است، اما می‌خواهد تغییر هزینه قابل کنترل بماند. چند واحد نباید بتوانند بدون اطلاع یکدیگر، منابع اضافه درخواست کنند. سازمان لازم است مسئول تأیید ظرفیت و بودجه را تعیین کند و برای وضعیت ضروری هم مسیر روشنی داشته باشد.
در کنار مبلغ، زمان کاهش منابع هم اهمیت دارد. اگر ظرفیت بیشتر برای یک دوره مشخص گرفته شده، چه کسی پایان آن دوره را اعلام می‌کند؟ آیا کاهش نیازمند درخواست است یا طبق توافق انجام می‌شود؟ فراموش شدن این مرحله می‌تواند باعث ادامه هزینه‌ای شود که دیگر نیاز عملیاتی ندارد.
تیم فناوری پیشنهاد می‌کند هر تغییر با تاریخ شروع، مسئول، دلیل و زمان بازبینی ثبت شود. این ثبت می‌تواند ساده باشد و الزاماً به فرایند اداری طولانی نیاز ندارد. هدف آن است که چند هفته بعد معلوم باشد چرا ظرفیت افزایش یافته و آیا همان دلیل همچنان وجود دارد.
اوج مصرف را در برنامه تحویل ببینیم
اگر انتظار داریم محیط در شرایط مشخصی پاسخ دهد، ارزیابی هم باید همان شرایط را تا حد مناسب نشان دهد. بررسی فقط در زمان خلوت، برای قضاوت درباره دوره پراستفاده کافی نیست. سازمان و ارائه‌دهنده باید درباره دامنه آزمون، داده مجاز و معیار موفقیت توافق کنند.
در این بررسی، مدیر فناوری یک سناریوی استفاده نماینده پیشنهاد می‌دهد. تعداد افراد هم‌زمان، مدت کار و زمان قابل قبول مشخص می‌شود. نتیجه آزمون به همین دامنه محدود می‌ماند. اگر بعداً مقدار استفاده افزایش پیدا کرد، ممکن است ارزیابی تازه‌ای لازم شود؛ یک آزمون اولیه، تمام نیازهای آینده را پوشش نمی‌دهد.
برای مدیریت، خروجی باید روشن باشد: ظرفیت فعلی در شرایط بررسی‌شده مناسب بوده، به تغییر نیاز دارد یا هنوز اطلاعات کافی برای قضاوت وجود ندارد. همراه نتیجه، اقدام بعدی و مسئول آن نوشته شود. این گزارش از عبارت مبهم «عملکرد خوب بود» برای تصمیم درباره هزینه مفیدتر است.
چه زمانی ظرفیت ثابت یا اختصاصی منطقی‌تر است
ممکن است بررسی نشان دهد مصرف سازمان در بیشتر دوره بالا و پایدار است. شاید فعالیتی حیاتی، تحمل انتظار برای تأمین منابع را نداشته باشد. در چنین شرایطی، ظرفیت ثابت رزروشده یا زیرساخت اختصاصی می‌تواند گزینه مناسبی برای مقایسه باشد. تصمیم باید با هزینه کل و توان بهره‌برداری همراه شود.
در مقابل، سازمانی که نیاز محدود یا متغیر دارد می‌تواند دریافت سرویس را جدی‌تر بررسی کند. مسئله فقط اندازه شرکت نیست؛ الگوی مصرف و محدودیت اجرایی اهمیت دارد. دو سازمان با تعداد کارکنان مشابه ممکن است به دو مسیر متفاوت برسند.
بهتر است مدیران برای تصمیم امروز، زمان بازبینی آینده را هم مشخص کنند. مصرفی که در آغاز متغیر است ممکن است با گسترش فعالیت پایدار شود. یا یک نیاز دوره‌ای کاهش پیدا کند. بازبینی منظم کمک می‌کند شیوه تأمین منابع با وضعیت واقعی سازمان هماهنگ بماند.
برآورد ظرفیت متناسب با سازمان در راگا
راگا برای بررسی زیرساخت Private AI، الگوی مصرف را در کنار بودجه، دسترسی و سطح خدمت می‌بیند. دریافت سرویس Multi-Tenant و مسیر زیرساخت اختصاصی باید بر اساس همین اطلاعات سنجیده شوند. اگر نیاز در طول ماه تغییر می‌کند، زمان‌های معمول و پرترافیک را جدا مطرح کنید تا پیشنهاد، آن تفاوت را منعکس کند.
برای جلسه اولیه، برنامه زمانی استفاده، بازه‌های حساس و حدود ظرفیت فعلی یا برآورد اولیه را آماده کنید. اگر اندازه دقیق روشن نیست، نمونه‌ای از شرایط استفاده می‌تواند مبنای بررسی قرار گیرد. پرسش اصلی این است که چه ظرفیتی، در چه زمانی و با چه تعهدی لازم دارید؛ پس از آن می‌توان هزینه گزینه‌ها را مقایسه کرد.
در پایان این بخش از روایت، مدیر مالی دیگر صرفاً دنبال کمترین مبلغ پایه نیست. او می‌خواهد هزینه منابع با زمان استفاده و اهمیت کار هماهنگ باشد. مدیر فناوری نیز برای درخواست توسعه، دلیل و معیار روشن دارد. قدم بعدی آن‌ها بررسی اعتماد به ارائه‌دهنده و مسئولیت‌های همکاری است؛ موضوعی که در ادامه کمپین Private AI راگا دنبال می‌کنیم.
این برآورد می‌تواند مبنای یک درخواست پیشنهاد مشخص و قابل مقایسه برای تصمیم بعدی مدیران سازمان قرار گیرد.
چک‌لیست تصمیم‌گیری
- نیاز و مالک کسب‌وکاری مشخص باشد.
- نوع داده و محدودیت دسترسی ثبت شود.
- ظرفیت پایه و اوج مصرف جدا محاسبه شوند.
- مدل اختصاصی یا Multi‑Tenant با معیار مشترک مقایسه شود.
برای تصمیم‌گیری درباره Private AI
نیاز، ظرفیت، داده و مدل بهره‌برداری سازمان را پیش از خرید یا دریافت سرویس بررسی کنید.
سؤالات متداول
Private AI را از کجا شروع کنیم؟
از یک نیاز تأییدشده، مالک مشخص، نوع داده، الگوی مصرف و معیار موفقیت شروع کنید؛ نه از فهرست تجهیزات.
زیرساخت اختصاصی بهتر است یا سرویس Multi‑Tenant؟
پاسخ به حساسیت داده، زمان شروع، الگوی مصرف، توان بهره‌برداری و سطح کنترل موردنیاز بستگی دارد.
ظرفیت Private AI چگونه تعیین می‌شود؟
هم‌زمانی، زمان پاسخ، حجم داده، دسترس‌پذیری، رشد و ظرفیت رزرو باید کنار هم سنجیده شوند.
منابع
[۱] تغییر منابع متناسب با تقاضا در سند NIST SP ۸۰۰-۱۴۵ مشاهده منبع
[۲] مدیریت منابع مشترک در راهنمای معماری Multi-Tenant مایکروسافت مشاهده منبع
مطالب مرتبط در سایت راگا
برای تکمیل این مسیر، راهنمای Private AI روی VCF و مقاله «معنای Multi Tenant در دریافت زیرساخت Private AI» را ببینید.