این مقاله کمک می‌کند مدیرعامل و مدیر فناوری پیش از قرارداد، مسئولیت، سطح خدمت و مسیر پاسخ‌گویی را به زبان قابل سنجش تعریف کنند. هدف وعده دسترس‌پذیری مطلق نیست. هیچ زیرساختی از اختلال مصون نیست؛ ارزش قرارداد در این است که رفتار دو طرف پیش از رخداد معلوم باشد.
در این راهنما، موضوع از چند زاویه بررسی می‌شود: سؤال مدیرعامل از زمان توقف شروع می‌شود، SLA باید نتیجه قابل مشاهده را تعریف کند، SLO و SLA یک نقش ندارند. هدف این است که مخاطب پس از مطالعه، معیارهای تصمیم‌گیری و اقدام بعدی را روشن‌تر ببیند.
در این مقاله می‌خوانید
- سؤال مدیرعامل از زمان توقف شروع می‌شود
- SLA باید نتیجه قابل مشاهده را تعریف کند
- SLO و SLA یک نقش ندارند
- مرز مسئولیت در مدل Multi Tenant
سؤال مدیرعامل از زمان توقف شروع می‌شود
همه کاربردهای AI حساسیت یکسانی ندارند. یک محیط آزمایش داخلی ممکن است چند ساعت توقف را تحمل کند، اما سرویسی که وارد فرایند روزانه واحدهای کسب‌وکار شده، به پاسخ سریع‌تری نیاز دارد. سازمان باید اثر توقف را بر کاربر، زمان کارکنان، تعهد مشتری و تصمیم‌های وابسته توضیح دهد.
وقتی اثر روشن شد، می‌توان سطح خدمت متناسب تعریف کرد. درخواست عدد بسیار بالا بدون شناخت کاربرد، هزینه را افزایش می‌دهد. پذیرش سطح پایین برای کاربرد حیاتی نیز ریسک پنهان می‌سازد. نقطه شروع SLA، دسته‌بندی مصرف‌هاست نه انتخاب یک درصد عمومی برای همه.
SLA باید نتیجه قابل مشاهده را تعریف کند
توافق سطح خدمت باید بگوید چه چیزی اندازه‌گیری می‌شود، در چه بازه‌ای و با چه روشی. دسترس‌پذیری پورتال، امکان دریافت ظرفیت، اتصال شبکه و دسترسی به Storage می‌توانند شاخص‌های جدا باشند. اگر تنها یک عدد کلی ثبت شود، ممکن است پورتال باز باشد اما کار واقعی سازمان انجام نشود.
تعریف زمان نیز مهم است. ماه تقویمی، ساعت کاری یا تمام شبانه‌روز نتایج متفاوتی دارند. نگهداری برنامه‌ریزی‌شده، شرایط خارج از کنترل و اختلال سمت سازمان باید شفاف باشند. متن دقیق از اختلاف پس از رخداد جلوگیری می‌کند.
SLO و SLA یک نقش ندارند
SLO هدف عملیاتی برای کیفیت یک جزء یا خدمت است؛ SLA تعهدی است که در توافق دو طرف ثبت می‌شود و ممکن است پیامد قراردادی داشته باشد. ارائه‌دهنده می‌تواند اهداف داخلی سخت‌گیرانه‌تری از تعهد بیرونی داشته باشد تا پیش از نقض قرارداد هشدار دریافت کند.
مدیر لازم نیست درگیر همه اصطلاحات شود، اما باید بداند عدد قرارداد چگونه از هدف عملیاتی پشتیبانی می‌شود. اگر هیچ مانیتورینگ یا ظرفیت پشتیبان برای هدف وجود ندارد، عدد روی کاغذ اطمینان واقعی نمی‌سازد.
مرز مسئولیت در مدل Multi Tenant
در سرویس Multi Tenant، ارائه‌دهنده زیرساخت مشترک را اداره می‌کند و هر سازمان محیط و دسترسی مستقل خود را دریافت می‌کند. ارائه‌دهنده مسئول سلامت لایه‌های توافق‌شده، جداسازی منابع، پایش و پاسخ اولیه است. سازمان مصرف‌کننده مسئول هویت کاربران خود، تعریف مجوزها، شیوه مصرف و اطلاعاتی است که وارد محیط می‌کند.
این تقسیم باید برای Backup، نگهداری داده، اتصال سازمانی، مدیریت کلید و رخداد امنیتی نیز نوشته شود. عبارت کلی «امنیت با ارائه‌دهنده است» خطرناک است. هر کنترل یک مالک، ورودی و مسیر Escalation می‌خواهد.
مالک هر جزء را در یک ماتریس کوچک بنویسیم
یک ماتریس مسئولیت می‌تواند برای هر موضوع چهار حالت داشته باشد: اجراکننده، تأییدکننده، مشورت‌شونده و فردی که باید مطلع شود. برای نمونه، ارائه‌دهنده ظرفیت را تخصیص می‌دهد، سازمان درخواست و بودجه آن را تأیید می‌کند و تیم امنیت در تغییر دسترسی حساس مشورت می‌دهد.
ماتریس نباید ده‌ها صفحه باشد. اجزای حیاتی شامل دریافت ظرفیت، تغییر ظرفیت، اتصال شبکه، ساخت حساب، Backup، بازیابی، رخداد، نگهداری و پایان سرویس‌اند. اگر یک ردیف بدون مالک بماند، همان ردیف در بحران به تأخیر تبدیل می‌شود.
زمان پاسخ با زمان رفع تفاوت دارد
پشتیبانی ممکن است در پانزده دقیقه درخواست را دریافت کند، اما رفع مشکل چند ساعت طول بکشد. مدیر باید هر دو زمان را بداند. همچنین سطح شدت رخداد باید تعریف شود؛ اختلال کامل یک سرویس حیاتی با سؤال درباره گزارش مصرف یکسان نیست.
برای هر شدت، زمان تأیید دریافت، آغاز بررسی، بازه به‌روزرسانی و هدف بازیابی نوشته می‌شود. اگر علت در اختیار طرف دیگری باشد، ارائه‌دهنده همچنان مسئول هماهنگی و اطلاع‌رسانی طبق توافق است. کاربر نباید میان چند تیم بدون مالک جابه‌جا شود.
مسیر Escalation باید پیش از رخداد آزموده شود
شماره‌ای که فقط در فایل قرارداد است، در نیمه‌شب کمک زیادی نمی‌کند. افراد شیفت، کانال تماس، جانشین و سطح تصمیم باید شناخته شوند. رخداد پرشدت ممکن است به مدیر عملیات، امنیت و مدیر ارتباطات نیاز داشته باشد. این مسیر باید در یک تمرین کوتاه آزمایش شود.
سازمان مصرف‌کننده نیز یک مسئول داخلی می‌خواهد. اگر ده کاربر جداگانه برای یک اختلال درخواست ثبت کنند، تشخیص و ارتباط دشوار می‌شود. نقطه تماس داخلی اطلاعات را جمع می‌کند، شدت را تأیید و پیام‌های ارائه‌دهنده را به مدیریت منتقل می‌سازد.
مانیتورینگ باید دید مشترک بسازد
ارائه‌دهنده زیرساخت را از درون می‌بیند و سازمان اثر را روی کاربر و فرایند خود مشاهده می‌کند. هر دو دید لازم‌اند. داشبورد یا گزارش باید مصرف ظرفیت، رخدادهای اصلی، دسترس‌پذیری و تغییرهای مهم را در سطحی نشان دهد که محرمانگی سایر Tenantها حفظ شود.
در اختلاف، منبع اندازه‌گیری اهمیت پیدا می‌کند. ساعت سیستم‌ها، تعریف شروع و پایان رخداد و روش محاسبه باید یکسان باشد. گزارش پس از حادثه نیز باید خط زمانی، علت شناخته‌شده، اقدام اصلاحی و مسئول پیگیری را ارائه کند.
Capacity Incident همیشه قطعی کامل نیست
سرویس ممکن است روشن باشد اما به دلیل کمبود ظرفیت، صف طولانی یا رقابت منابع، کیفیت آن کاهش یابد. در زیرساخت AI، درخواست برای پردازنده شتاب‌دهنده، حافظه و Storage می‌تواند نوسان داشته باشد. SLA باید فقط روشن یا خاموش بودن را نبیند.
شاخص‌هایی مانند زمان دریافت ظرفیت، عملکرد در محدوده توافق‌شده و نرخ رد درخواست می‌توانند برای مصرف سازمانی مهم باشند. در مدل Multi Tenant، سیاست جلوگیری از Noisy Neighbor و نحوه اولویت‌بندی باید توضیح داده شود. وعده ظرفیت نامحدود قابل دفاع نیست؛ روش رزرو و توسعه مهم است.
تغییر برنامه‌ریزی‌شده باید قابل پیش‌بینی باشد
زیرساخت برای Patch، ارتقا و نگهداری به تغییر نیاز دارد. حذف همه پنجره‌های نگهداری معمولاً عملی نیست. ارائه‌دهنده باید زمان اطلاع، مدت، اثر احتمالی و مسیر اعتراض برای دوره‌های حساس سازمان را مشخص کند. سازمان نیز تقویم اوج مصرف خود را اعلام می‌کند.
تغییر اضطراری امنیتی ممکن است خارج از برنامه انجام شود. قرارداد باید نحوه اطلاع و گزارش بعدی را تعیین کند. هدف متوقف‌کردن اصلاح امنیتی نیست؛ سازمان باید بداند چه تغییری رخ داده و آیا اقدام تکمیلی در سمت خود لازم است.
Backup و بازیابی را در قرارداد پیدا کنیم
عبارت «داده روی Storage پایدار است» با Backup یکسان نیست. باید روشن باشد چه داده‌ای، با چه تناوب و چه دوره‌ای محافظت می‌شود، بازیابی در چه سطحی ممکن است و درخواست آن چگونه ثبت می‌شود. بعضی داده‌های موقت یا Cache شاید خارج از دامنه باشند.
سازمان باید نیاز خود را بر اساس ارزش داده تعریف کند. اگر بازسازی محیط از ابتدا ممکن است اما مجموعه داده ورودی حیاتی است، حفاظت آن‌ها متفاوت خواهد بود. آزمون بازیابی پیش از استفاده گسترده، فاصله میان تصور و تعهد را آشکار می‌کند.
رخداد امنیتی مسیر جدا می‌خواهد
اختلال همیشه خرابی فنی نیست. دسترسی مشکوک، نشت Credential یا رفتار غیرعادی می‌تواند نیازمند محدودکردن سرویس باشد. ارائه‌دهنده و سازمان باید زمان اطلاع، حفظ شواهد، جداسازی محیط و تصمیم بازگشت را از قبل تعیین کنند.
در مدل Multi Tenant، اطلاع‌رسانی باید بدون افشای اطلاعات سایر سازمان‌ها انجام شود. طرف مصرف‌کننده حق دارد اثر بر محیط خود و اقدام لازم را بداند. جزئیات غیرمرتبط با Tenant دیگر نباید در گزارش قرار گیرد. این تعادل بخشی از بلوغ عملیات سرویس است.
اعتبار خدمت فقط جبران مالی نیست
برخی قراردادها برای نقض SLA اعتبار مالی یا Service Credit تعریف می‌کنند. این بند می‌تواند مسئولیت را رسمی کند، اما زیان توقف فرایند کسب‌وکار را جبران نمی‌کند. اولویت مدیر باید کاهش احتمال رخداد و زمان بازیابی باشد.
جبران باید با اقدام اصلاحی همراه شود. رخداد تکرارشونده حتی با Credit قابل قبول نیست. حق دریافت گزارش، برنامه اصلاح و بازبینی ظرفیت برای سازمان ارزش عملی بیشتری دارد. شرایط خاتمه در صورت نقض‌های مکرر نیز باید روشن باشد.
خروج و تداوم داده را از ابتدا ببینیم
اگر سرویس برای مدت طولانی در دسترس نباشد یا همکاری پایان یابد، سازمان چگونه داده و تنظیمات ضروری را دریافت می‌کند؟ قالب خروج، زمان تحویل، هزینه انتقال و حذف نسخه‌های باقی‌مانده باید در توافق باشد. این سؤال نشانه بی‌اعتمادی نیست؛ بخشی از مدیریت ریسک است.
طرح جایگزین می‌تواند شامل نگهداری نسخه داده در محل دیگر، امکان بازسازی محیط یا انتقال موقت به ظرفیت اختصاصی باشد. همه سناریوها برای همه سازمان‌ها لازم نیستند. سطح تداوم باید با اهمیت کاربرد هماهنگ شود.
داشبورد مدیریتی باید کوتاه و قابل اقدام باشد
مدیرعامل به صدها متریک زیرساخت نیاز ندارد. گزارش ماهانه می‌تواند دسترس‌پذیری، رخدادهای پرشدت، زمان پاسخ و رفع، مصرف ظرفیت، تغییرهای مهم و اقدام‌های باز را نشان دهد. هر انحراف باید مالک و تاریخ اصلاح داشته باشد.
مدیر فناوری به جزئیات بیشتر برای روند مصرف و پیش‌بینی نیاز دارد. این دو سطح گزارش باید از یک داده مشترک تولید شوند. اختلاف میان گزارش مدیریتی و فنی، اعتماد را کاهش می‌دهد.
پایلوت سطح خدمت را واقعی می‌کند
پیش از انتقال کاربرد مهم، یک دوره پایلوت می‌تواند درخواست ظرفیت، افزایش و کاهش، رخداد آزمایشی، Backup و تماس با پشتیبانی را بررسی کند. تیم باید زمان واقعی هر مرحله و کیفیت ارتباط را ثبت کند. تجربه پایلوت بندهای مبهم را پیش از تعهد بزرگ نشان می‌دهد.
پایلوت نباید فقط در ساعات کم‌بار و با حضور همه متخصصان انجام شود. یک سناریوی عادی پشتیبانی و یک سناریوی اختلال کنترل‌شده تصویر واقعی‌تری می‌سازد. نتیجه برای اصلاح SLA و Runbook دو طرف استفاده می‌شود.
نقش راگا در تعریف خدمت
راگا به‌عنوان ارائه‌دهنده زیرساخت Private AI باید دامنه خدمت، روش تخصیص ظرفیت، جداسازی محیط، مانیتورینگ و پشتیبانی را شفاف کند. در مدل Multi Tenant، سازمان می‌تواند بدون خرید کامل تجهیزات شروع کند، اما باید بداند چه سطحی از منابع و پاسخ‌گویی دریافت می‌کند.
برای سازمان‌هایی که کنترل یا ظرفیت اختصاصی می‌خواهند، طراحی زیرساخت اختصاصی نیز قابل بررسی است. انتخاب میان دو مدل به حساسیت داده، الگوی مصرف، بودجه و مسئولیت عملیات بستگی دارد. جلسه نیازسنجی باید این تفاوت‌ها را به تصمیم تبدیل کند.
کاتالوگ خدمت باید دامنه هر گزینه را نشان دهد
سازمان باید بداند بسته یا سطح انتخابی دقیقاً چه منابع، ساعات پشتیبانی، Backup و گزارش‌هایی را شامل می‌شود. نام‌های عمومی مانند پایه و سازمانی بدون جدول دامنه کافی نیستند. هر سطح می‌تواند ظرفیت، زمان پاسخ و امکان توسعه متفاوتی داشته باشد.
کاتالوگ همچنین موارد خارج از دامنه را بیان می‌کند. برای نمونه، اتصال اختصاصی، نگهداری طولانی‌تر یا بازیابی ویژه ممکن است خدمت جدا باشد. بیان شفاف این موارد از انتظار پنهان و اختلاف صورتحساب جلوگیری می‌کند.
بازبینی حقوقی باید با سناریوی عملیاتی همراه شود
تیم حقوقی متن تعهد و مسئولیت را بررسی می‌کند، اما برای فهم اصطلاحات به سناریوی فناوری نیاز دارد. یک رخداد فرضی از آغاز هشدار تا بازیابی روی بندهای قرارداد اجرا می‌شود. هر جا مالک، زمان یا مدرک نامعلوم است، متن نیاز به اصلاح دارد.
همین روش برای تغییر ظرفیت و پایان همکاری نیز به کار می‌رود. قرارداد خوانا باید به مدیر و تیم عملیات کمک کند بدانند چه کنند. پیوست فنی می‌تواند جزئیات اندازه‌گیری را نگه دارد و متن اصلی نتیجه مدیریتی را بیان کند.
تمرین مشترک پس از شروع سرویس
SLA پس از امضا ثابت و فراموش‌شده نیست. یک تمرین در هفته‌های نخست می‌تواند تماس پشتیبانی، Escalation، بازیابی نمونه و گزارش رخداد را بیازماید. هدف ایجاد اختلال واقعی نیست؛ طرفین مسیر ارتباط و دسترسی را در شرایط کنترل‌شده بررسی می‌کنند.
یافته‌ها به Runbook، فهرست تماس و تعریف شدت برمی‌گردند. سپس در بازه‌های دوره‌ای، سطح خدمت با رشد مصرف بازبینی می‌شود. کاربردی که از آزمایش به فرایند حیاتی رسیده، ممکن است SLA و ظرفیت متفاوتی لازم داشته باشد.
تغییر مالک داخلی نیز باید در همین بازبینی ثبت شود. اگر نقطه تماس سازمان عوض شده باشد اما فهرست Escalation به‌روز نشود، بهترین SLA در لحظه نیاز به فرد اشتباه می‌رسد. کنترل ساده اطلاعات تماس، بخشی از آمادگی خدمت است.
پرسش‌هایی که باید به رویداد آورده شوند
سازمان بهتر است فهرست کوتاهی همراه داشته باشد: کاربردهای اولیه چه هستند، چند تیم استفاده می‌کنند، چه ساعات و اوج مصرفی دارند، توقف چه اثری می‌گذارد، چه داده‌ای حیاتی است و چه کسی در داخل مالک سرویس خواهد بود. نیازی به ارائه داده محرمانه در فرم عمومی نیست.
با این اطلاعات می‌توان درباره سطح خدمت، ظرفیت رزرو، Backup، مسیر پشتیبانی و توسعه آینده گفت‌وگو کرد. هدف رویداد فقط دیدن زیرساخت نیست؛ باید ابهام‌های تصمیم کاهش یابند.
پاسخ نهایی به مدیرعامل
مدیر فناوری سازمان پس از بازبینی، به‌جای عبارت کلی «پشتیبانی کامل»، یک جدول یک‌صفحه‌ای ارائه می‌کند. در آن، دامنه زیرساخت، زمان پاسخ برای شدت‌های مختلف، روش گزارش، مسئول هر طرف، حفاظت داده و مسیر Escalation ثبت شده است. مواردی که هنوز قطعی نیستند به‌عنوان موضوع مذاکره علامت خورده‌اند.
اکنون مدیرعامل می‌تواند ریسک را ببیند و میان سرعت شروع، هزینه و سطح کنترل تصمیم بگیرد. سؤال «چه کسی پاسخ‌گو است» با یک نام حل نمی‌شود؛ پاسخ درست مجموعه‌ای از تعهد قابل اندازه‌گیری، مالک مشخص و فرایند آزموده است.
چک‌لیست تصمیم‌گیری
- نیاز و مالک کسب‌وکاری مشخص باشد.
- نوع داده و محدودیت دسترسی ثبت شود.
- ظرفیت پایه و اوج مصرف جدا محاسبه شوند.
- مدل اختصاصی یا Multi‑Tenant با معیار مشترک مقایسه شود.
برای تصمیم‌گیری درباره Private AI
نیاز، ظرفیت، داده و مدل بهره‌برداری سازمان را پیش از خرید یا دریافت سرویس بررسی کنید.
سؤالات متداول
Private AI را از کجا شروع کنیم؟
از یک نیاز تأییدشده، مالک مشخص، نوع داده، الگوی مصرف و معیار موفقیت شروع کنید؛ نه از فهرست تجهیزات.
زیرساخت اختصاصی بهتر است یا سرویس Multi‑Tenant؟
پاسخ به حساسیت داده، زمان شروع، الگوی مصرف، توان بهره‌برداری و سطح کنترل موردنیاز بستگی دارد.
ظرفیت Private AI چگونه تعیین می‌شود؟
هم‌زمانی، زمان پاسخ، حجم داده، دسترس‌پذیری، رشد و ظرفیت رزرو باید کنار هم سنجیده شوند.
منابع
[۱] Microsoft Learn — ملاحظات عملیاتی معماری‌های Multi Tenant مشاهده منبع
[۲] NIST — راهنمای مدیریت رخدادهای امنیت رایانه‌ای مشاهده منبع
مطالب مرتبط در سایت راگا
برای تکمیل این مسیر، راهنمای Private AI روی VCF و مقاله «خرید زیرساخت یا دریافت سرویس؛ سناریوی سازمان خود را به رویداد Private AI راگا بیاورید» را ببینید.