پیش‌نیازهای استقرار ServiceDesk Plus | پیش از این مدخل، معرفی ServiceDesk Plus و تفاوت نسخه‌ها را بخوانید. فهرست راهنمای ادمین مسیر حرکت میان موضوع‌هاست.

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

این راهنما برای نصب داخلی یا On-Premises نوشته شده است؛ نه نسخه ابری و نه ServiceDesk Plus MSP. هدف، تحویل یک برگه تصمیم‌گیری پیش از نصب است. اندازه‌های محیط و نام‌های مثال، فرضی‌اند و باید با اطلاعات سازمان شما جایگزین شوند.

قبل از خرید سرور، دامنه پروژه را روشن کنید

فرض کنید سازمانی ۴۵۰ کاربر، دو ساختمان، ۹ کارشناس پشتیبانی و روزانه حدود ۱۲۰ درخواست دارد. این چهار عدد هنوز برای تعیین سرور کافی نیستند. باید حجم پیوست‌ها، مدت نگهداری اطلاعات، تعداد کاربران هم‌زمان، گزارش‌های سنگین، مدیریت دارایی و برنامه رشد نیز مشخص شوند. سازمانی که تصویر و فایل حجیم در هر درخواست می‌گذارد، با سازمانی که بیشتر درخواست‌های متنی دارد، الگوی ذخیره‌سازی یکسانی نخواهد داشت.

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

نسخه، Edition و Build را جدا ثبت کنید

Cloud یا On-Premises نوع استقرار است؛ Edition مجموعه قابلیت‌ها را تعیین می‌کند؛ Build شماره دقیق بسته نصب‌شده است. این سه را در یک خانه با عنوان «نسخه نرم‌افزار» ننویسید. در برگه پروژه، برای هرکدام جای مستقلی بگذارید. مرجع دریافت فایل نیز باید مشخص باشد؛ از راهنمای دانلود ServiceDesk Plus در مدانت استفاده کنید، نه فایل ناشناخته‌ای که نام مشابه دارد.

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

ظرفیت سخت‌افزار

در جدول رسمی پیش‌نیازها، ردیف تا ۵۰۰ درخواست روزانه و تا ۵۰ تکنسین، برای پایگاه داده همراه محصول، ۵۰۰ گیگابایت دیسک، ۱۲ گیگابایت حافظه و پردازنده سروری هشت‌هسته‌ای ۲ گیگاهرتز درج شده است. این اعداد، اطلاعات صفحه هنگام بازبینی این راهنما هستند؛ تضمین ظرفیت برای هر سازمان یا همه Buildهای قدیمی نیستند. بار هم‌زمان و برنامه‌های دیگر سرور نیز بر ظرفیت موردنیاز اثر دارند.

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

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

فهرست جاری سازنده هنگام بازبینی این مدخل شامل Windows Server 2025، 2022 و 2019؛ Debian 13، 12 و 11؛ RHEL 9، 8 و 7؛ Ubuntu 22 و 20؛ Ubuntu 24.04 Pro؛ و Rocky Linux 9.5 و 8.6 است. عنوان Ubuntu 24.04 Pro را به همه نصب‌های Ubuntu 24.04 تعمیم ندهید. این فهرست ممکن است تغییر کند و برای Buildهای قدیمی، بررسی سازگاری همان Build لازم است.

Windows Server Core برای اجرای محصول پشتیبانی نمی‌شود. در PostgreSQL خارجی، نسخه باید با PostgreSQL همراه برنامه یکسان باشد. سیستم‌عامل، نوع استقرار و پایگاه داده را به‌صورت یک مجموعه بررسی کنید؛ سازگاری هرکدام به‌تنهایی، سازگاری ترکیب آن‌ها را ثابت نمی‌کند.

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

نقشه ارتباطات را روی کاغذ بکشید

چهار مسیر اصلی را بررسی کنید: مرورگر کاربر تا سرور برنامه؛ برنامه تا پایگاه داده؛ برنامه تا سرویس ایمیل؛ و برنامه تا سامانه هویت یا یکپارچه‌سازی‌های موردنیاز. برای هر مسیر، مبدأ، مقصد، نام DNS، پروتکل، پورت واقعی و مالک تأیید را ثبت کنید. پورت را از معماری مصوب و تنظیمات همان نصب بردارید، نه از یک عدد حفظ‌شده در اینترنت.

در سناریوی ما، بازشدن صفحه از خود سرور فقط یک آزمون محلی است. باید همان نشانی از رایانه کاربر ساختمان دوم نیز آزموده شود. نتیجه آزمون را با ساعت، نام رایانه و متن خطا ثبت کنید. عبارت «شبکه مشکل دارد» شواهد کافی برای تحویل کار به تیم شبکه نیست.

نام، گواهی و ساعت را به روز آخر موکول نکنید

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

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

بکاپ، مسئول و آزمون بازگشت لازم دارد

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

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

برگه آماده‌بودن زیرساخت چه چیزی دارد؟

در پایان باید یک سند کوتاه داشته باشید که نوع استقرار، Edition و Build هدف، مشخصات سرور، ظرفیت دیسک، انتخاب پایگاه داده، نشانی نهایی، مسیرهای شبکه، مسئول ایمیل، روش بکاپ و مالک هر تصمیم را نشان دهد. روبه‌روی هر مورد، وضعیت «تأییدشده»، «نیازمند آزمون» یا «مانع نصب» بنویسید. موارد مبهم را با تیک سبز پنهان نکنید.

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

پرسش‌های متداول

آیا برای شروع می‌توان از ماشین مجازی استفاده کرد؟

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

آیا اعداد این مقاله برای همه نصب‌های سری ۱۵ کافی‌اند؟

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

مطالب مرتبط

نصب در ویندوز | نصب در لینوکس | تنظیم اتصال پایگاه داده | راه‌اندازی سرور | فهرست راهنما

سخن پایانی مدانت

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

منابع

ManageEngine — System Requirements؛ فهرست جاری سیستم‌عامل‌ها، ظرفیت سخت‌افزار و ملاحظات پایگاه داده.

ManageEngine — Installation on Windows؛ انتخاب‌های نصب.

مثال‌ها، برگه تصمیم و معیارهای پذیرش این مدخل، طراحی آموزشی مدانت‌اند و جایگزین ماتریس سازگاری سازنده نیستند. تاریخ بازبینی: ۱۸ سپتامبر ۲۰۲۶.