ممکن است دسکتاپ مجازی در جلسه نمایش بهسرعت باز شود، اما کاربر در شعبه نتواند سند را اسکن کند، رسید چاپ کند یا تماس تصویری پایداری داشته باشد. برای تصمیم درباره گسترش VDI، باید مسیر کامل انجام کار را در شرایط نزدیک به بهرهبرداری بررسی کرد.
پایلوت VDI اجرای محدود و قابل سنجش دسکتاپ مجازی با کاربران نماینده است؛ هدف آن، بررسی تناسب راهکار با کار واقعی سازمان و شناسایی اصلاحات لازم پیش از توسعه است. نتیجه باید روشن کند کدام نیازها تأمین شدهاند، چه محدودیتهایی باقی مانده و مرحله بعد تحت چه شرایطی قابل اجراست.
1- هدف، محدوده و کاربران پایلوت را مشخص کنید
ابتدا مسئلهای را بنویسید که انتظار دارید VDI به حل آن کمک کند: مدیریت محیط کاری شعب، سادهترشدن آمادهسازی کاربران، کنترل بهتر دسترسی یا کاهش دشواری پشتیبانی. هر هدف باید به معیار قابل بررسی متصل شود.
کاربران نماینده چه کسانی هستند؟
گروه آزمایشی را فقط از کارکنان IT یا کاربران کممسئله انتخاب نکنید. نقشهای کاری، محل فعالیت، نوع برنامه و تجهیزات جانبی را در نظر بگیرید. کاربر ثبت سفارش، کارشناس مالی و اپراتور دارای اسکنر ممکن است نیازهای متفاوتی داشته باشند.
تعداد کاربران باید برای پوشش سناریوهای مهم و مشاهده رفتار همزمان کافی باشد. یک نسبت ثابت از کل کارکنان برای همه سازمانها مناسب نیست. نام گروههای پوششدادهشده و گروههایی که هنوز آزموده نشدهاند را در گزارش مشخص کنید.
مشخصات محیط آزمون را ثبت کنید
گروه آزمایشی را فقط از کارکنان IT یا کاربران کممسئله انتخاب نکنید. نقشهای کاری، محل فعالیت، نوع برنامه و تجهیزات جانبی را در نظر بگیرید. کاربر ثبت سفارش، کارشناس مالی و اپراتور دارای اسکنر ممکن است نیازهای متفاوتی داشته باشند.
تعداد کاربران باید برای پوشش سناریوهای مهم و مشاهده رفتار همزمان کافی باشد. یک نسبت ثابت از کل کارکنان برای همه سازمانها مناسب نیست. نام گروههای پوششدادهشده و گروههایی که هنوز آزموده نشدهاند را در گزارش مشخص کنید.
2- خط مبنا و معیار پذیرش را پیش از آزمون تعیین کنید
خط مبنا، وضعیت فعلی انجام کار است. زمان آمادهشدن محیط، بازشدن برنامه، تکمیل عملیات و مشکلات پرتکرار را در محیط موجود ثبت کنید. معیار پذیرش نیز نتیجهای است که سازمان برای تأیید سناریوی جدید انتظار دارد.
مثلاً «ورود سریع باشد» کافی نیست. مشخص کنید زمان از کدام لحظه تا کدام لحظه اندازهگیری میشود، چه تعداد کاربر همزمان فعالاند و چه کسی نتیجه را تأیید میکند. ورود اولیه، ورودهای بعدی و اتصال مجدد به نشست قبلی را جدا بسنجید.
آستانه زمانی باید با مسئول فرایند و بر اساس نیاز کار توافق شود. عددی که برای یک کار اداری قابل قبول است، الزاماً برای اپراتور پاسخگو به مشتری مناسب نیست. در ارزیابی امنیت نیز اجرای مجوزهای مصوب باید مستقل از رضایت کاربر آزموده شود.
اگر مسئله و نیازهای اولیه هنوز روشن نیستند، از چکلیست نیازسنجی زیرساخت IT برای آمادهسازی ورودی پایلوت استفاده کنید.
راهنمای مرتبط
چکلیست نیازسنجی زیرساخت IT
اگر مسئله و نیازهای اولیه هنوز روشن نیستند، این راهنما کمک میکند ورودی پایلوت را دقیقتر و قابل سنجش آماده کنید.
3- نرمافزارها و تجربه واقعی کاربر را بررسی کنید
برای هر نقش، چند کار اصلی و تکرارپذیر تعریف کنید؛ مانند ثبت سفارش و چاپ رسید، جستوجوی پرونده، تهیه گزارش یا ویرایش فایل. داده آزمون باید از نظر حجم و ساختار نماینده کار واقعی باشد و استفاده از آن با مجوز مناسب انجام شود.
مسیر کامل کار را آزمایش کنید
بازشدن نرمافزار فقط آغاز آزمون است. ورود به سامانه، خواندن داده، ثبت تغییر، ذخیره فایل، خروجیگرفتن و خروج از برنامه را بررسی کنید. فونت فارسی، چیدمان صفحهکلید، نمایش راستبهچپ و مسیر ذخیره پیشفرض نیز میتوانند بر کار روزانه اثر بگذارند.
پس از خروج و ورود مجدد، حفظ تنظیمات موردنیاز کاربر را کنترل کنید. در محیط اشتراکی، باید اطمینان حاصل شود که اطلاعات یا تنظیمات خصوصی یک کاربر برای کاربر بعدی قابل دسترسی نیست.
گزارش کاربر را به داده فنی متصل کنید
وقتی کاربر از کندی شکایت میکند، زمان رخداد، عملیات در حال انجام و شناسه نشست را ثبت کنید. سپس وضعیت برنامه، میزبان، ذخیرهسازی و ارتباط را در همان بازه بررسی کنید. استفاده پردازنده بهتنهایی توضیح کاملی از تجربه کاربر نمیدهد.
برای نمونه، در محیطهای ویندوزی پشتیبانیشده، شاخص User Input Delay مدت انتظار ورودی در صف پیش از دریافت آن توسط برنامه را اندازه میگیرد. این شاخص معادل تأخیر کامل شبکه و نمایش تصویر نیست. راهنمای شمارندههای عملکرد Remote Desktop مایکروسافت کاربرد و محدودیت آن را توضیح میدهد.
4- شبکه و ظرفیت را در شرایط همزمان بسنجید
آزمون را از محل واقعی کاربران انجام دهید. اتصال سالم در دفتر مرکزی، کیفیت تجربه شعبه یا دورکار را تأیید نمیکند. نوع ارتباط، مسیر اتصال و ساعت اجرای آزمون را همراه نتیجه ثبت کنید.
زمان رفتوبرگشت ارتباط یا RTT، پهنای باند قابل استفاده و در صورت امکان نوسان تأخیر و ازدسترفتن بستهها را بررسی کنید. خروجی تست عمومی سرعت اینترنت، جای سنجش مسیر واقعی نشست را نمیگیرد. برای نمونه، مستندات پایش کیفیت اتصال Azure Virtual Desktop روش بررسی RTT و پهنای باند برآوردی نشستها را ارائه میکند؛ ابزار متناظر در بستر انتخابی شما ممکن است متفاوت باشد.
ورود و فعالیت همزمان را پوشش دهید
ورود چند کاربر در شروع شیفت، بازشدن برنامهها، گزارشگیری و پخش محتوای تصویری میتوانند بار متفاوتی ایجاد کنند. همراه با تجربه کاربر، مصرف پردازنده و حافظه، زمان پاسخ ذخیرهسازی و در صورت استفاده، منابع گرافیکی را ثبت کنید.
میانگین مطلوب ممکن است کندیهای مقطعی را پنهان کند؛ زمانهای کند و شرایط رخداد آنها را نیز گزارش دهید. نتیجه پایلوت کوچک را مستقیماً به ظرفیت کل سازمان تعمیم ندهید. توسعه به کاربران بیشتر به بررسی ظرفیت منابع مشترک و بار کاری مورد انتظار نیاز دارد.
5- تجهیزات جانبی و تماس تصویری را جداگانه آزمون کنید
چاپگر، اسکنر و وسایل تخصصی
برای چاپگر، نوع اتصال، مدل، درایور، اندازه کاغذ و قابلیتهای موردنیاز مانند چاپ دورو را ثبت کنید. آزمون باید با خروجی واقعی برنامه انجام شود؛ چاپ یک صفحه آزمایشی همه نیازها را پوشش نمیدهد.
برای اسکنر، ورود مستقیم تصویر به نرمافزار، اسکن چندصفحهای و محل ذخیره فایل را بررسی کنید. بارکدخوان، کارتخوان یا ابزار تخصصی نیز باید با مدل و نسخه واقعی آزموده شوند.
وجود درگاه USB به معنی کارکرد همه وسایل در نشست مجازی نیست. هدایت وسیله محلی به نشست یا Redirection به نوع وسیله، نرمافزار اتصال، درایور و سیاستها وابسته است. مستندات USB Redirection در RDP نیز تفاوت روشهای هدایت و نقش تنظیمات سمت دستگاه و میزبان را توضیح میدهد. تنظیمات آن را نباید بدون تطبیق به بسترهای دیگر تعمیم داد.
چندنمایشگری، صدا و جلسه آنلاین
تعداد نمایشگر، وضوح تصویر، مقیاس نمایش و جابهجایی پنجرهها را با چیدمان واقعی کاربر بررسی کنید. سپس میکروفن، هدفون، دوربین و اشتراکگذاری صفحه را در جلسهای مشابه استفاده روزانه آزمون کنید.
برخی برنامهها برای VDI سازوکار بهینهسازی رسانه دارند که به نسخه و نوع دستگاه وابسته است. برای مثال، راهنمای Teams روی Azure Virtual Desktop پیشنیازها و روش کنترل فعالبودن بهینهسازی را مشخص میکند. صرف نصب برنامه، فعالبودن این قابلیت را ثابت نمیکند.
دستگاهی را بسنجید که قرار است تحویل شود
آزمون روی یک لپتاپ، سازگاری تینکلاینت یا زیروکلاینت منتخب را اثبات نمیکند. مدل نهایی، نسخه نرمافزار یا میانافزار، پروتکل، خروجی نمایشگر و وسایل جانبی را در پایلوت وارد کنید. این اصل برای انتخاب تجهیزات UNIVO نیز برقرار است.
پیش از قطعیکردن مدل، مرور اشتباهات خرید زیروکلاینت میتواند پرسشهای سازگاری را روشنتر کند. ویژگیهای هر مدل باید با مستندات روز همان محصول کنترل شوند.
6- دسترسی، اختلال و مسیر بازگشت را بررسی کنید
برای حسابهای آزمایشی با نقشهای متفاوت، دسترسی به برنامه و فایل را کنترل کنید. چاپ، حافظه جانبی، انتقال فایل و کلیپبورد باید مطابق سیاست مصوب رفتار کنند. موفقیت کاربر مجاز و جلوگیری از عملیات غیرمجاز، هر دو بخشی از آزموناند.
قطع کوتاه ارتباط، اتصال مجدد، خرابی دستگاه کاربر و توقف برنامه را در محیط و زمان هماهنگشده بررسی کنید. معلوم شود نشست حفظ میشود یا پایان مییابد، عملیات ناتمام چه وضعیتی دارد و کاربر چگونه ادامه میدهد. رفتار این موارد به بستر و تنظیمات وابسته است.
مسیر بازگشت باید مسئول اجرا، شرط فعالشدن و روش تطبیق دادههای ایجادشده در پایلوت را مشخص کند. بازگرداندن یک ماشین به وضعیت قبلی، بهتنهایی تضمین نمیکند دادههای ثبتشده در سامانههای دیگر سازگار باقی بمانند.
تیم پشتیبانی نیز باید بتواند نشست مشکلدار را پیدا کند، شواهد جمعآوری کند و مسئله را به مسئول مربوط ارجاع دهد. زمان و مراحل این کار را در ارزیابی ثبت کنید؛ پایلوت، آمادگی بهرهبرداری را هم میسنجد.
جدول ارزیابی و معیارهای پذیرش پایلوت VDI
مقادیر خالی جدول را پیش از شروع با مسئولان مربوط تکمیل کنید. این جدول قالب پیشنهادی است؛ آستانههای آن استاندارد ثابت برای همه سازمانها نیستند.
| محور | روش سنجش | شرط پذیرش پیشنهادی برای تکمیل | مسئول تأیید |
|---|---|---|---|
| زمانگیری ورود اول، بعدی و اتصال مجدد | هدف هر حالت: …؛ تعداد کاربران همزمان: … | زیرساخت و نماینده کاربران | |
| اجرای سناریوی کامل با داده مشخص | خروجی صحیح و زمان تکمیل حداکثر … | مالک فرایند | |
| ثبت کندی، زمان رخداد و شواهد نشست | سقف رخداد یا زمان اختلال: … | پشتیبانی و کاربران | |
| پایش نشست و منابع در بار همزمان | بار هدف: …؛ حدود فنی مورد تأیید: … | شبکه و زیرساخت | |
| چاپ، اسکن و آزمون وسایل ضروری | موفقیت سناریوهای ضروری فهرستشده | کاربر و پشتیبانی | |
| تماس، دوربین و اشتراک صفحه | شرایط و معیار کیفیت توافقشده: … | IT و واحد استفادهکننده | |
| آزمون نقش مجاز و غیرمجاز | انطباق با ماتریس دسترسی مصوب | امنیت و مالک داده | |
| اجرای سناریوی هماهنگشده | زمان بازگشت: …؛ صحت داده پس از آن | عملیات و زیرساخت |
پس از پایلوت چگونه تصمیم بگیریم؟
گزارش نهایی باید دامنه آزمون، نتایج، محدودیتها و پیشنهاد مرحله بعد را روشن کند. سه تصمیم معمول عبارتاند از:
- توسعه مرحلهای: نیازهای ضروری در دامنه آزمودهشده تأمین شده و ظرفیت و پشتیبانی مرحله بعد بررسی شدهاند.
- اصلاح و آزمون مجدد: مسئله قابل پیگیری است؛ مسئول، تغییر لازم و سناریوی بازآزمایی مشخص میشوند.
- بازنگری مدل برای یک گروه: محدودیت برنامه، وسیله جانبی یا ارتباط، استفاده از مدل فعلی را نامناسب کرده است.
برای مثال فرضی، ممکن است ثبت سفارش و چاپ رسید تأیید شوند، اما اسکن مستقیم سند در برنامه ضروری کار نکند. میانگین رضایت بالا، این نیاز حلنشده را جبران نمیکند. ابتدا باید مسیر اصلاح یا مدل جایگزین همان گروه بررسی شود.
برای ارزیابی جایگاه VDI در کنار رایانه مدیریتشده و مدل ترکیبی، صفحه راهکار Digital Workspace بهین تکنولوژی را ببینید. هنگام طرح درخواست بررسی، گروه کاربران، برنامههای اصلی، وسایل جانبی و نتایج آزمونهای انجامشده را مشخص کنید تا گفتوگو بر نیاز واقعی سازمان متمرکز باشد.
پرسشهای متداول درباره پایلوت VDI
پایلوت باید چند روز طول بکشد؟
زمان ثابت ندارد؛ باید چرخههای مهم کار، ساعت اوج مصرف، آزمون اختلال و فرصت اصلاح را پوشش دهد. اگر عملیات مهم فقط پایان ماه انجام میشود، نتیجه یک آزمون کوتاه را نباید به آن تعمیم داد.
تفاوت پایلوت و اثبات مفهوم یا PoC چیست؟
PoC معمولاً امکان فنی یک ایده یا قابلیت را بررسی میکند. پایلوت بر استفاده محدود در شرایط نزدیک به بهرهبرداری و معیار پذیرش تمرکز دارد. چون کاربرد اصطلاحات متفاوت است، دامنه و خروجی هر مرحله را مکتوب کنید.
آیا میتوان ابتدا با رایانههای فعلی آزمون کرد؟
بله، برای بخشی از ارزیابی؛ اما اگر دستگاه نهایی متفاوت است، آزمون سازگاری و تجربه کار باید روی آن هم انجام شود. نتایج را بر اساس مدل دستگاه و نسخه نرمافزار اتصال تفکیک کنید.
آیا پایلوت موفق، ظرفیت استقرار کامل را تضمین میکند؟
خیر. نتیجه فقط درباره شرایط و بار آزمودهشده شواهد میدهد. توسعه به کاربران بیشتر، شعب جدید یا برنامههای متفاوت به بررسی ظرفیت، منابع مشترک، پشتیبانی و در صورت نیاز آزمون تکمیلی نیاز دارد.