معماری و ظرفیت
منابع سرور، ذخیرهسازی، شبکه، محیط آزمون و ظرفیت رشد بر اساس بار واقعی تعریف شوند.
راهکار استقرار سازمانی
استقرار On-Premise نرم‌افزار حمل‌ونقل را با مسئولیت‌های روشن انتخاب کنید
استقرار داخل سازمان فقط محل نصب سرور نیست؛ تصمیمی درباره مالکیت زیرساخت، دسترسی شبکه، نسخه پشتیبان، پایش، بهروزرسانی، امنیت و تقسیم مسئولیت میان تیم فناوری اطلاعات و تأمین‌کننده است. این صفحه چک‌لیست تصمیم را ارائه می‌دهد و شرایط نهایی باید در پیشنهاد رسمی سپند تأیید شود.
این صفحه درباره مدل استقرار است، نه قیمت یا قابلیت ماژول‌ها
تعرفه‌ها در صفحه قیمت‌گذاری و امکانات در صفحات محصول و ماژول‌ها توضیح داده می‌شوند. این راهکار فقط تصمیم استقرار داخلی، پیش‌نیازها و مرز مسئولیت‌ها را پوشش می‌دهد.
راهنمای مسئولیت‌پذیری استقرار داخلیآخرین بازبینی محتوایی: شهریور ۱۴۰۵
On-Premise به‌خودی‌خود امنتر یا ارزان‌تر نیست. نتیجه به معماری، کنترل دسترسی، پشتیبان‌گیری، بهروزرسانی و توان تیم زیرساخت سازمان وابسته است.
خروجی مورد انتظار
پیش از انتخاب On-Premise باید سه موضوع قطعی شود
امنیت و تداوم خدمت
کنترل دسترسی، پایش، نسخه پشتیبان، آزمون بازیابی و برنامه رخداد مسئول مشخص داشته باشند.
مرز پشتیبانی
مسئول سیستم‌عامل، پایگاه داده، شبکه، برنامه، بهروزرسانی و بازیابی در سند استقرار روشن باشد.
آمادگی سازمان
چه زمانی استقرار On-Premise تصمیم قابل دفاعی است؟
انتخاب باید از الزام کسب‌وکار و توان عملیاتی شروع شود، نه صرفاً ترجیح نگهداری سرور در محل شرکت.
الزام داده و دسترسی
سیاست محل داده، شبکه خصوصی، دسترسی شعب، دسترسی راه‌دور و محدودیت‌های قراردادی یا نظارتی مکتوب باشد.
نشانه آمادگی: مالک امنیت و تأیید رسمی معماری دسترسیتوان زیرساخت
سرور، ذخیرهسازی، شبکه، برق، پایش، مجازی‌سازی و ظرفیت رشد باید تیم و بودجه مشخص داشته باشند.
نشانه آمادگی: ظرفیت‌سنجی و برنامه افزونگیتوان بهره‌برداری
مسئول پچ، نسخه پشتیبان، بازیابی، مانیتورینگ، گواهی‌ها و هماهنگی پشتیبانی باید در RACI تعیین شود.
نشانه آمادگی: پوشش روزمره و زمان پاسخ توافقشدهمعماری راهکار
چهار ستون برنامه استقرار داخلی
این موارد چک‌لیست تحلیل‌اند و بیانگر تعهد فنی نهایی نیستند؛ جزئیات نسخه و قرارداد باید رسمی تأیید شود.
زیرساخت و شبکه
محیط اجرا، ذخیرهسازی، دامنه، گواهی، دسترسی کاربران و ارتباط شعب باید پیش از نصب آماده و آزموده شوند.
معرفی محصول سپنددسترسی و امنیت
نقش‌های برنامه، دسترسی مدیران زیرساخت، ثبت رخداد و سیاست‌های سازمان باید در طرح استقرار هم‌راستا شوند.
چرا سپند؟پشتیبان‌گیری و بازیابی
تناوب نسخه، محل نگهداری، دوره حفظ، رمزگذاری و آزمون واقعی بازیابی باید مسئول و گزارش داشته باشد.
سؤالات متداول سپندبهروزرسانی و پشتیبانی
پنجره نگهداری، محیط آزمایشی، تغییر نسخه، بازگشت و نحوه دسترسی تیم پشتیبانی مکتوب شود.
درخواست بررسی فنیجریان عملیاتی
مسیر تصمیم تا بهره‌برداری On-Premise
عبور از هر مرحله باید خروجی قابل تأیید داشته باشد تا نصب زودهنگام به بدهی عملیاتی تبدیل نشود.
- 1
کشف الزام
علت استقرار داخلی، کاربران، شعب، داده و محدودیت‌های امنیتی مستند میشود.
- 2
طراحی و مسئولیت
معماری، ظرفیت، دسترسی‌ها و ماتریس مسئولیت سازمان و تأمین‌کننده توافق میشود.
- 3
آزمون و انتقال
محیط، داده نمونه، دسترسی، پشتیبان‌گیری و سناریوی بازیابی پیش از بهره‌برداری آزموده می‌شوند.
- 4
بهره‌برداری و پایش
پایش، نگهداری، بهروزرسانی، رخداد و بازبینی ظرفیت طبق برنامه ادامه می‌یابد.
معماری و حاکمیت
چهار لایه‌ای که در پیشنهاد استقرار داخلی باید مکتوب شوند
نام سرور و سیستم‌عامل کافی نیست؛ مسئولیت هر لایه در رخداد، تغییر نسخه و بازیابی باید قابل اجرا باشد.
01
زیرساخت و دسترس‌پذیری
ظرفیت و نقاط تک‌خرابی باید پیش از نصب روشن شوند.
- CPU، حافظه، فضای داده و رشد فایل‌ها در افق قرارداد
- شبکه شعب، دسترسی راه‌دور و وابستگی به سرویس‌های داخلی
- افزونگی، برق اضطراری، پایش ظرفیت و هشدار خرابی
02
امنیت و کنترل تغییر
مرز مسئولیت محصول، سیستم‌عامل، شبکه و کاربران تفکیک شود.
- هویت کاربر، سطح دسترسی، حساب مدیر و بازبینی دوره‌ای دسترسی
- پچ امنیتی، آنتی‌بدافزار، گواهی، لاگ و نگهداری شواهد
- فرایند درخواست، آزمون، تأیید و بازگشت تغییرات
03
پشتیبان‌گیری و تداوم
وجود فایل Backup بدون آزمون Restore تضمین بازیابی نیست.
- RPO و RTO مورد انتظار برای داده و فایل‌های پیوست
- نسخه پشتیبان مستقل، رمزگذاری و نگهداری خارج از نقطه اصلی
- آزمون دوره‌ای بازیابی و ثبت زمان و نتیجه
04
نسخه، پشتیبانی و خروج
چرخه عمر سامانه باید از روز اول تا پایان همکاری روشن باشد.
- پنجره نگهداری، روش ارتقا و سازگاری نسخه‌ها
- SLA رخداد، کانال پشتیبانی و دسترسی کنترل‌شده تیم فنی
- مالکیت داده، قالب خروجی و فرایند تحویل در پایان قرارداد
SLA و عملیات فناوری
شاخص‌هایی که سلامت استقرار داخلی را قابل مشاهده می‌کنند
هدف‌ها باید در قرارداد یا سند عملیاتی تعریف شوند و با گزارش واقعی زیرساخت سنجیده شوند.
دسترس‌پذیری سرویس
زمان قابل استفاده بودن سامانه با تعریف روشن از توقف برنامه‌ریزی‌شده و رخداد.
منبع داده: پایش مستقل و گزارش رخدادموفقیت پشتیبان‌گیری
نسبت اجرای موفق Backup به برنامه و تعداد نسخه‌هایی که کنترل سلامت شده‌اند.
منبع داده: گزارش Job و بازبینی مسئولزمان واقعی بازیابی
مدت لازم برای بازگرداندن سرویس و داده در آخرین مانور Restore.
منبع داده: صورت‌جلسه آزمون بازیابیعمر وصله و نسخه
فاصله انتشار اصلاح تأییدشده تا نصب کنترل‌شده آن در محیط سازمان.
منبع داده: تقویم نگهداری و ثبت تغییر
نقشه استقرار داخلی
از طراحی تا تحویل بهره‌برداری با معیار پذیرش
هر مرحله باید توسط مالک سازمانی مربوط تأیید شود؛ تیم فناوری، امنیت و صاحبان فرایند هم‌زمان درگیر هستند.
-
1
طراحی و ظرفیت‌سنجی
تعداد کاربر، حجم داده، رشد، شعب، سطح خدمت و معماری محیط‌ها مبنای پیشنهاد زیرساخت قرار گیرد.
تحویل‌دادنی: معماری تأییدشده و Bill of Materials -
2
امن‌سازی و نصب
حساب‌ها، دسترسی شبکه، گواهی، پایش و تنظیمات Backup پیش از ورود داده عملیاتی آماده شوند.
تحویل‌دادنی: چک‌لیست Hardening و نصب -
3
مهاجرت و Cutover
تمرین انتقال، تطبیق داده، زمان توقف، نقطه بازگشت و ارتباطات روز شروع رسمی برنامه‌ریزی شود.
تحویل‌دادنی: Runbook مهاجرت و Rollback -
4
تحویل عملیات
Restore آزمایش، مانیتورینگ مشاهده، آموزش مدیر سامانه و مسیر پشتیبانی در شرایط واقعی تمرین شود.
تحویل‌دادنی: صورت‌جلسه پذیرش و RACI نهایی
چک‌لیست اجرایی
چک‌لیست جلسه فنی استقرار
پاسخ‌ها باید در معماری یا پیوست فنی قرارداد ثبت شوند.
تعداد کاربر هم‌زمان، رشد داده و دوره نگهداری فایل‌ها چگونه برآورد شده است؟
هدف زمان بازیابی و میزان داده قابل از دست رفتن چیست و چه کسی آن را آزمون می‌کند؟
تیم پشتیبانی در چه شرایطی، با چه تأیید و چه ثبت رویدادی دسترسی می‌گیرد؟
نسخه جدید ابتدا کجا آزموده میشود و برنامه بازگشت در صورت خطا چیست؟
مسیرهای مرتبط
اطلاعات مکمل تصمیم استقرار
برای ادامه بررسی هر بخش، از مسیر تخصصی مرتبط استفاده کنید.
هزینه و پلن
برای مدل قیمت‌گذاری کاربران و ماژول‌ها به صفحه تعرفه مراجعه کنید؛ هزینه زیرساخت جداگانه ارزیابی میشود.
تعرفه‌های نرم‌افزار سپنددامنه محصول
برای آشنایی با فرایند CRM تا عملیات و مالی، معرفی محصول را بخوانید.
معرفی محصول در عملتحلیل فنی اختصاصی
جزئیات نسخه، توپولوژی، مسئولیت و زمانبندی فقط پس از بررسی نیاز سازمان قطعی میشود.
درخواست جلسه فنیپرسشهای متداول
سؤالات متداول استقرار On-Premise
آیا On-Premise همیشه امنتر است؟
خیر. امنیت به معماری، پیکربندی، وصلهها، کنترل دسترسی، پایش، نسخه پشتیبان و توان تیم بهرهبردار وابسته است. محل استقرار بهتنهایی امنیت را تضمین نمیکند.
هزینه On-Premise فقط خرید سرور است؟
خیر. سختافزار یا ماشین مجازی، ذخیرهسازی، شبکه، نسخه پشتیبان، پایش، نیروی نگهداری، بهروزرسانی و زمان بازیابی بخشی از هزینه کل مالکیتاند.
چه کسی مسئول نسخه پشتیبان است؟
پاسخ باید در قرارداد و ماتریس مسئولیت مشخص شود. حتی اگر ابزار یا راهنما ارائه شود، اجرای منظم و آزمون بازیابی نباید بدون مالک باقی بماند.
آیا شرایط On-Premise سپند برای همه سازمانها یکسان است؟
خیر. نسخه، ظرفیت، الزامات شبکه، دامنه خدمات و زمانبندی پس از تحلیل فنی مشخص و در پیشنهاد رسمی تأیید میشود.
پیش‌نیازهای استقرار داخلی سازمان خود را بررسی کنید
الزام‌ها، معماری موجود و مسئولیت‌های تیم فناوری اطلاعات را مطرح کنید تا امکان و دامنه استقرار به‌صورت فنی ارزیابی شود.
این موضوع در کدام بخش فرایند ادامه پیدا می‌کند؟
این مسیرها بر اساس ارتباط واقعی فرایندها انتخاب شده‌اند؛ هر لینک دامنه مستقل صفحه مقصد را توضیح می‌دهد.
برای تصمیم دقیق‌تر درباره کنترل Workspace، Role، Permission و Audit، امنیت و مدیریت دسترسی را کنار این صفحه ببینید. برای دیدن ارتباط ماژول‌ها در معماری محصول، معرفی کامل محصول سپند را بررسی کنید. برای تصمیم دقیق‌تر درباره اجرای سناریوی واقعی در جلسه ارزیابی، رزرو جلسه بررسی محصول را کنار این صفحه ببینید.