درس ۴ مسیر استقرار ServiceDesk Plus ــ On-Premises | درس قبل: سازمان، سایت و تقویم کاری | فهرست مسیر یادگیری
کارشناس تازه وارد تیم شده است. نامش در نرمافزار وجود دارد، اما نمیتواند وارد شود. برای حل فوری مشکل، کسی دسترسی ادمین به او میدهد؛ ورود درست میشود، ولی حالا او تنظیماتی را هم میبیند که قرار نبود تغییر دهد. مسئله از ابتدا «کمبود دسترسی ادمین» نبود؛ هویت کاربر، امکان ورود و نقش کاری با یکدیگر اشتباه شده بودند.
در این درس یک کارشناس سطح اول برای محیط آزمایشی میسازیم. هدف آن است که درخواست مربوط به کارش را ببیند و رسیدگی کند، نه اینکه برای هر خطای دسترسی، یک مجوز قدرتمندتر بگیرد. تنظیمات را ابتدا روی حساب آزمایشی انجام دهید؛ حساب واقعی کارشناسان را برای تمرین از گروهها و سایتها جدا نکنید.
پیشنیاز: تعریف شغل، نه فقط انتخاب نام نقش
برای مثال آموزشی ما، کارشناس سطح اول باید درخواستهای تیم پشتیبانی کاربران را بررسی کند، پاسخ بدهد و نتیجه رسیدگی را ثبت کند. تغییر تنظیمات ایمیل، حذف درخواستها و مدیریت همه سایتها جزو مسئولیت او نیست. این توصیف را پیش از بازکردن صفحه Role بنویسید. نامهایی مانند «کارشناس»، «ارشد» و «مدیر» بهتنهایی مشخص نمیکنند چه عملی باید مجاز باشد.
یک برگه سهستونی بسازید: عملیات موردنیاز، دامنه داده قابل مشاهده و مسئول تأیید. مثلاً «ویرایش درخواست» یک عملیات است، اما «درخواستهای گروه خود» دامنه آن است. تأیید یکی از این دو، جای تأیید دیگری را نمیگیرد.
گام اول: نقش محدود و قابل توضیح بسازید
در Admin، عبارت Roles را جستوجو کنید و Add New Role را بزنید. نام یکتا و توضیح مسئولیت وارد کنید؛ مجوزهای ماژولها و سپس Advanced Permissions را بررسی و ذخیره کنید. در مستند رسمی، Complete Access همه عملیات پایه، از جمله حذف، را فعال میکند؛ آن را معادل «دسترسی معمول کارشناس» نگیرید. دامنه مشاهده نیز گزینههای مستقلی مانند همه موارد، سایتهای مرتبط، گروه و موارد تخصیصیافته، یا فقط موارد تخصیصیافته دارد. این Roleها برای تکنسینها هستند و تنظیم نقش درخواستکنندگان سازوکار یکسانی ندارد. منبع: راهنمای Roles.
در تمرین ما، نامی مانند «پشتیبانی سطح اول ــ پایلوت» انتخاب کنید و علت هر مجوز را در توضیح پروژه بنویسید. اگر عملیات خاصی هنگام آزمون مسدود شد، همان عملیات را بررسی کنید؛ اضافهکردن نقش ادمین، نتیجه آزمون نقش محدود را بیمعنا میکند.
گام دوم: تکنسین و امکان ورود
در بخش Admin → Users → Technicians، از Add New استفاده کنید. مشخصات فرد را وارد کنید، در صورت نیاز گزینه Enable login for this Technician را فعال کنید و اطلاعات ورود را تعیین کنید. نقش منتخب را از Available Roles به Assigned Roles منتقل و ذخیره کنید. کاربر واردشده از AD، LDAP یا CSV نیز میتواند از فهرست Requesters با Change as Technician تبدیل شود؛ سپس باید سایت، گروه و مجوزهای او تنظیم شوند. ایجاد رکورد تکنسین و فعالبودن ورود، دو موضوع جدا هستند. منبع: راهنمای Technicians.
برای حساب آزمایشی، نام مشخص و نشانی ایمیل تحت کنترل تیم آزمون استفاده کنید. کاربر واردشده از دایرکتوری را بدون بررسی دوباره با یک نام دیگر نسازید. اگر همنامها وجود دارند، ایمیل، نام ورود و منبع هویت را کنار هم مقایسه کنید؛ نام نمایشی بهتنهایی کلید مطمئن تطبیق نیست.
گام سوم: گروه پشتیبانی
در Admin → Users → Support Groups، Add New Group را انتخاب کنید، نام گروه را بنویسید و تکنسینهای مرتبط را اضافه کنید. تنظیم گیرندگان اعلان درخواست جدید و درخواست برداشتهنشده هم در این بخش وجود دارد. در راهنمای سازنده، آدرسهای گروه برای دریافت ایمیل باید به صندوقی متصل باشند که سامانه واقعاً آن را دریافت میکند؛ نوشتن یک آدرس در فرم، صندوق ایمیل ایجاد نمیکند. منبع: راهنمای Support Groups.
در پایلوت فقط یک گروه با مسئول روشن بسازید. توضیح گروه باید بگوید چه نوع درخواستهایی را میپذیرد و مرز مسئولیت آن با زیرساخت یا نرمافزار چیست. گروهی که همه عضو آن هستند و همه درخواستها به آن میروند، شاید راهاندازی را سریع کند، ولی تفکیک مسئولیت را به شما نمیدهد.
آزمون مثبت: کاری که باید انجام شود
از مرورگر یا نشست جدا با حساب تکنسین وارد شوید. درخواست آزمایشی متعلق به گروه او را باز کنید؛ پاسخ و نتیجه رسیدگی را مطابق دامنه تعریفشده ثبت کنید. سپس با مسئول آزمون بررسی کنید نام ثبتکننده عملیات درست است. در طول این آزمون، نشست ادمین را بهجای کارشناس به کار نبرید.
برای هر عملیات، نتیجه موردانتظار و نتیجه واقعی را بنویسید. «ورود موفق» فقط پذیرش احراز هویت است؛ پذیرش نقش کاری زمانی اتفاق میافتد که عملیات ضروری نیز در دامنه صحیح اجرا شوند.
آزمون منفی: کاری که نباید انجام شود
با همان حساب، یک درخواست آزمایشی خارج از دامنه مصوب را بررسی کنید. آیا در فهرست دیده میشود؟ آیا از نشانی مستقیم قابل دسترسی است؟ آیا کارشناس میتواند وارد تنظیمات حساس شود؟ این آزمایش را فقط روی داده آزمایشی و با هماهنگی ادمین انجام دهید. هدف، یافتن خطای پیکربندی پیش از ورود داده واقعی است.
اگر دسترسی بیشتر از انتظار بود، مجموع نقشهای حساب، عضویت گروه، سایت و شیوه اشتراک درخواست را بررسی کنید. نام کمخطر یک Role تضمین نمیکند مجموعه مجوزهای نهایی محدود باشد. همچنین نبود یک دکمه در صفحه، بهتنهایی شاهد کافی برای کنترل دسترسی نیست؛ نتیجه دسترسی به داده را هم بسنجید.
وقتی کارشناس وارد نمیشود
ابتدا نام ورود، فعالبودن Login و روش احراز هویت منتخب را کنترل کنید. خطای ورود را از نبود دسترسی به درخواست تفکیک کنید. در گزارش خطا، زمان، شناسه حساب آزمایشی و متن پیام را بنویسید، اما رمز، توکن و کلید API را ثبت نکنید. برای ورود معمول کارشناس، تولید بیدلیل کلید API جزو این تمرین نیست.
سخن پایانی
دسترسی مناسب یعنی فرد بتواند کار خودش را انجام دهد، نه اینکه برای آسانشدن کار ادمین، اختیار همهچیز را بگیرد. حسابی که فقط وارد میشود هنوز آماده بهرهبرداری نیست؛ باید هم توانایی لازم و هم محدودیت لازم را در آزمون نشان دهد.
در ادامه مسیر آموزش ادمین، ایمیل ورودی و خروجی را راهاندازی میکنیم. سناریو و آزمونهای این درس تألیف مدانتاند؛ مراحل محصول بر منابع رسمی پیوندشده تکیه دارند. بازبینی منابع: ۱۸ سپتامبر ۲۰۲۶.
