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