معنای Multi Tenant در دریافت زیرساخت Private AI

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

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

یک بستر مشترک را به زبان سازمانی تصور کنیم

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

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

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

مشترک بودن زیرساخت و مجوز دیدن اطلاعات دو موضوع متفاوت‌اند

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

در طراحی ذخیره‌سازی Multi-Tenant، انتخاب روش جداسازی داده یک تصمیم مستقل است. راهنمای مایکروسافت نشان می‌دهد برای این کار سطح‌های مختلفی وجود دارد و باید با نیاز هر مشتری هماهنگ شود. [۳] نتیجه مدیریتی آن است که درباره داده، نسخه‌های پشتیبان و شرایط نگهداری سؤال جداگانه داشته باشیم و آن را از شکل ورود کاربران حدس نزنیم.

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

اختیار مدیر سازمان و ارائه‌دهنده را روشن کنیم

مدیر فناوری می‌پرسد چه بخشی از مدیریت محیط در اختیار خودش خواهد بود. آیا می‌تواند دسترسی افراد سازمان را تأیید یا لغو کند؟ چه گزارش‌هایی می‌بیند؟ برای تغییر ظرفیت یا تنظیم مهم، کدام درخواست را باید ثبت کند؟ پاسخ‌ها باید با مسئولیتی که از او انتظار می‌رود متناسب باشند.

در طرف دیگر، ارائه‌دهنده برای نگهداری زیرساخت به اختیاراتی نیاز دارد. سازمان باید درباره حدود این اختیارات، ثبت فعالیت و شرایط ورود پشتیبانی سؤال کند. لازم نیست برای مطرح کردن این خواسته، در نظر بگیریم هیچ مدیری هرگز به زیرساخت دسترسی نخواهد داشت. موضوع، کنترل و پاسخ‌گویی دسترسی‌های لازم است.

در محیط Multi-Tenant، شناسایی کاربر و تعیین مجوز او باید با مرز سازمان مربوط هماهنگ باشد. راهنمای هویت مایکروسافت نیز این ارتباط را از ملاحظات معماری می‌داند. [۴] برای مدیر خریدار، خروجی قابل استفاده یک فهرست روشن از نقش‌هاست: چه کسی درخواست می‌دهد، چه کسی تأیید می‌کند و چه کسی می‌تواند تغییر را اجرا کند.

اگر مشتری دیگری پرمصرف شد چه می‌شود

مدیر مالی نگرانی دیگری دارد: «اگر مشتری دیگری استفاده زیادی داشته باشد، سهم ما کم نمی‌شود؟» این پرسش درباره کیفیت خدمت است. در منابع مشترک، اثر مصرف مشتریان بر یکدیگر باید مدیریت شود. راهنمای معماری مایکروسافت نیز بر کنترل منابع و پایش برای کاهش این اثر تأکید می‌کند. [۲]

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

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

هزینه کمتر از کجا می‌تواند ایجاد شود

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

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

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

بخش اختصاصی در یک سرویس مشترک چه جایگاهی دارد

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

مدیر فناوری از ارائه‌دهنده می‌خواهد گزینه‌ها را به زبان نتیجه توضیح دهد. در گزینه اول، چه میزان اختیار و ظرفیت تحویل می‌شود؟ در گزینه دوم، چه چیزی تغییر می‌کند و چرا هزینه بیشتر می‌شود؟ این توضیح از فهرستی که فقط نام فناوری‌ها را کنار هم گذاشته قابل استفاده‌تر است.

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

مسئولیت هنگام اختلال را پیش از رخداد بنویسیم

مدیرعامل درباره روزی سؤال می‌کند که محیط در دسترس نباشد. چه کسی باید مشکل را ثبت کند؟ چه اطلاعاتی باید ارائه شود؟ سازمان از چه مسیری وضعیت را پیگیری می‌کند؟ این سؤال‌ها به خود مدل Multi-Tenant محدود نیستند، اما در دریافت سرویس اهمیت زیادی دارند چون اجرای بخشی از کار در اختیار ارائه‌دهنده است.

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

در جلسه، تیم تصمیم می‌گیرد یک رخداد ساده را روی کاغذ مرور کند. کاربر دسترسی ندارد؛ مسئول داخلی چه چیزی را بررسی می‌کند و چه زمانی درخواست به ارائه‌دهنده منتقل می‌شود؟ همین تمرین می‌تواند ابهام در نقش‌ها را آشکار کند. نتیجه آن باید به روش تماس و رسیدگی قابل استفاده تبدیل شود.

در دمو چه چیزی را درخواست کنیم

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

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

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

چگونه پاسخ‌ها را برای تصمیم مدیریت جمع کنیم

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

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

در سازمان، مدیرعامل پس از این بررسی دیگر Multi-Tenant را صرفاً به معنای «مشترک بودن همه چیز» نمی‌بیند. او می‌داند باید درباره مرز محیط، منابع و پاسخ‌گویی سؤال کند. مدیر مالی نیز می‌تواند هزینه پیشنهادی را به سطح خدمتی که واقعاً دریافت می‌شود وصل کند.

یک هلدینگ با چند شرکت چه سؤالی باید بپرسد

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

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

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

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

گفت‌وگو با راگا درباره سرویس Multi Tenant

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

اگر هنوز درباره بستر مشترک ابهام دارید، سؤال‌هایتان را به همان موارد قابل مشاهده تبدیل کنید: چه چیزی مشترک است، چه چیزی جداست و چگونه این موضوع بررسی می‌شود؟ طرح این پرسش‌ها با راگا می‌تواند مسیر نیازسنجی یا دموی متناسب با دغدغه مدیران شما را روشن کند.

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

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

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

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

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

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

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

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

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

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

منابع

[۱] مفهوم Tenant در راهنمای معماری Multi-Tenant مایکروسافت مشاهده منبع

[۲] جداسازی و مدیریت منابع مشترک در راهنمای مایکروسافت مشاهده منبع

[۳] تصمیم‌های جداسازی داده در راهنمای مایکروسافت مشاهده منبع

[۴] هویت و مجوز دسترسی در محیط Multi-Tenant مشاهده منبع

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

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