این مقاله یک چارچوب مدیریتی برای همان مقایسه است. قیمت روز یا پیشنهاد یک نسخه خاص ارائه نمی‌کند، چون آن‌ها به ترکیب محصول، شرایط پشتیبانی و استعلام معتبر نیاز دارند. هدف این است که مدیر فناوری بتواند پیشنهادش را به نیاز سرویس، هزینه بهره‌برداری و ریسک تغییر متصل کند.
در این راهنما، موضوع از چند زاویه بررسی می‌شود: نیاز سازمان را از نام پلتفرم جدا کنیم، سه سناریو را جداگانه بنویسیم، هزینه کل مالکیت را چگونه ببینیم. هدف این است که مخاطب پس از مطالعه، معیارهای تصمیم‌گیری و اقدام بعدی را روشن‌تر ببیند.
در این مقاله می‌خوانید
- نیاز سازمان را از نام پلتفرم جدا کنیم
- سه سناریو را جداگانه بنویسیم
- هزینه کل مالکیت را چگونه ببینیم
- یک مثال اقتصادی بدون قیمت‌سازی
نیاز سازمان را از نام پلتفرم جدا کنیم
نخست بنویسید زیرساخت چه خدماتی باید ارائه دهد: ظرفیت پردازش، دسترس‌پذیری، شبکه، ذخیره‌سازی، حفاظت از داده و مدیریت چرخه عمر. سپس قابلیت‌های واقعاً مورد استفاده را مشخص کنید. وجود یک امکان در بسته خریداری‌شده به معنی استفاده یا نیاز سازمان به آن نیست. این تفکیک می‌تواند دامنه گزینه‌های قابل بررسی را روشن‌تر کند.
در بعضی محیط‌ها، بخش عمده نیاز اجرای ماشین‌های مجازی با عملیات نسبتاً ساده است. در محیط دیگر، سیاست‌های شبکه، خودکارسازی، چندمستاجری و یکپارچگی عملیات نقش پررنگ‌تری دارند. مقایسه این دو فقط بر اساس تعداد ماشین یا پردازنده، تفاوت نیاز را پنهان می‌کند. باید وظایف عملیاتی و وابستگی‌ها هم دیده شوند.
همچنین VMware، vSphere، VCF و NSX نام‌های قابل جایگزینی با یکدیگر نیستند. دامنه و اجزای مورد استفاده سازمان باید مشخص باشد تا مقایسه به خطا نرود. سازمانی که مجموعه‌ای از قابلیت‌های یکپارچه را به کار گرفته، برای جایگزینی به بررسی بیشتر از انتقال فایل ماشین‌ها نیاز دارد. جزئیات بسته و نسخه باید از اسناد جاری تأیید شوند.
سه سناریو را جداگانه بنویسیم
سناریوی نخست، حفظ پلتفرم همراه با اصلاحات ضروری است. در این گزینه، سازمان فرض می‌کند بخشی از سرمایه‌گذاری فعلی همچنان مناسب است، اما وضعیت نسخه، دسترسی، ظرفیت یا پشتیبانی باید بهتر شود. هزینه نگهداری آینده و ریسک‌های باقی‌مانده باید روشن باشند. حفظ وضع موجود نباید به معنی نادیده گرفتن نیازهای اصلاحی باشد.
سناریوی دوم، ارتقا یا بازطراحی در همان خانواده است. این گزینه می‌تواند از مهارت و یکپارچگی موجود استفاده کند، اما همچنان به بررسی سازگاری، مسیر ارتقا و هزینه نیاز دارد. ممکن است بعضی تجهیزات یا ابزارها مقصد انتخاب‌شده را پشتیبانی نکنند. بنابراین ارتقا نیز پروژه‌ای با پیش‌نیاز و آزمون است.
سناریوی سوم، مهاجرت کامل یا بخشی از بارها به پلتفرم دیگر است. در آن باید هزینه انتقال، آموزش، ابزارهای جانبی و دوره هم‌زیستی محیط‌ها حساب شود. راهکار جایگزین باید نیازهای واقعی را پوشش دهد و امکان بهره‌برداری قابل اتکا داشته باشد. ارزانی مجوز یا آشنایی یک نفر با محصول، برای تصمیم کل سازمان کافی نیست.
هزینه کل مالکیت را چگونه ببینیم
برای مقایسه، یک دوره زمانی مشترک متناسب با برنامه سازمان انتخاب کنید. هزینه خرید و اشتراک، پشتیبانی، تجهیزات لازم، اجرای پروژه، آموزش و نگهداری در آن دوره جمع شوند. هزینه خروج از پلتفرم و مهاجرت بعدی نیز می‌تواند مهم باشد. همه گزینه‌ها باید با دامنه و فرض‌های یکسان برآورد شوند.
در سناریوی جایگزینی، هزینه دوره‌ای که دو محیط هم‌زمان فعال‌اند فراموش نشود. ممکن است سازمان برای مدت انتقال به ظرفیت اضافه، دو ابزار پایش یا دو قرارداد پشتیبانی نیاز داشته باشد. اگر این دوره در برآورد دیده نشود، صرفه‌جویی سال اول بیش از واقعیت گزارش می‌شود. زمان واقعی مهاجرت باید از پیچیدگی بارها به دست بیاید.
در سناریوی ماندن نیز هزینه‌های پنهان وجود دارند. نسخه بدون پشتیبانی، ظرفیت ناکافی یا وابستگی به دانش یک نفر ممکن است نیاز به اصلاح داشته باشد. مقایسه منصفانه، گزینه فعلی را به‌صورت رایگان و بی‌ریسک فرض نمی‌کند. هزینه‌های گذشته که دیگر قابل برگشت نیستند نیز نباید به‌تنهایی آینده تصمیم را تعیین کنند.
یک مثال اقتصادی بدون قیمت‌سازی
فرض کنید پیشنهاد جایگزین، هزینه اشتراک کمتری نشان می‌دهد. پیش از نتیجه‌گیری، از تیم بخواهید هزینه انتقال همان مجموعه سرویس، حفظ اهداف بازیابی و آموزش بهره‌برداری را اضافه کند. اگر این هزینه‌ها طی دوره بررسی از کاهش اشتراک بیشتر باشند، توجیه اولیه تغییر می‌کند. اگر کمتر باشند و معیارهای فنی هم محقق شوند، جایگزینی می‌تواند قابل دفاع‌تر شود.
در این محاسبه، احتمال قطعی را بدون داده به یک عدد قطعی تبدیل نکنید. می‌توان سناریوی محافظه‌کارانه و محتمل نوشت و پیامدهای کیفی را جدا نشان داد. مثلاً نبود مسیر پشتیبانی برای نرم‌افزار حیاتی، شرط مهمی است که شاید در یک عدد هزینه خلاصه نشود. تصمیم مدیریت باید این شرط را صریح ببیند.
همچنین کاهش هزینه را نسبت به وضعیتی مقایسه کنید که نیاز سازمان را واقعاً پوشش می‌دهد. ارزان‌تر بودن راهکاری که هدف بازیابی یا کنترل شبکه موردنیاز را تأمین نمی‌کند، مقایسه هم‌سطح نیست. ابتدا الزامات ضروری را تعیین کنید؛ سپس گزینه‌های واجد شرایط را از نظر هزینه و منفعت بررسی کنید.
سازگاری سخت‌افزار و نرم‌افزار را مستند کنیم
برای ارتقای ESXi، Broadcom بررسی سازگاری میزبان و اجزای مرتبط را پیش از اجرا توصیه می‌کند. [۱] در عمل باید مدل سرور، پردازنده، کنترلر، کارت شبکه، درایور و میان‌افزار برای مقصد انتخاب‌شده بررسی شوند. اینکه سخت‌افزار با نسخه قبلی کار کرده، سازگاری با نسخه بعدی را ثابت نمی‌کند.
این اصل برای پلتفرم جایگزین نیز برقرار است. سیستم‌عامل مهمان، نرم‌افزار کاربردی، پایگاه داده و ابزارهای جانبی باید در ترکیب جدید بررسی شوند. گاهی ماشین روشن می‌شود اما سازنده نرم‌افزار کاربردی آن ترکیب را پشتیبانی نمی‌کند. سازمان باید تفاوت «قابل اجرا» و «دارای مسیر پشتیبانی معتبر» را در تصمیم ببیند.
برای موارد مهم، شواهد در یک ماتریس نگهداری شوند: جزء، نسخه فعلی، مقصد، وضعیت سازگاری و اقدام لازم. اگر پاسخ هنوز نامعلوم است، همان‌طور ثبت شود. نامعلوم را نباید با تأیید جایگزین کرد. این ماتریس به برآورد زمان و ترتیب پروژه کمک می‌کند و از کشف دیرهنگام وابستگی‌ها جلوگیری می‌کند.
شبکه و NSX چه اثری بر مهاجرت دارند
اگر سازمان از مجازی‌سازی شبکه یا سیاست‌های امنیتی توزیع‌شده استفاده می‌کند، انتقال ماشین فقط بخشی از کار است. باید مشخص شود ارتباطات، قواعد، جداسازی و دسترسی مدیریتی چگونه در مقصد بازسازی یا جایگزین می‌شوند. نبود معادل مستقیم برای یک قابلیت، نیازمند طراحی راه‌حل جایگزین و آزمون آن است.
ابتدا جریان‌های لازم میان سرویس‌ها را ثبت کنید. کدام ارتباط برای کار واقعی ضروری است و کدام دسترسی تاریخی بدون نیاز باقی مانده؟ مهاجرت فرصت بازبینی است، اما تغییر هم‌زمان همه سیاست‌ها می‌تواند عیب‌یابی را دشوار کند. دامنه اصلاح شبکه باید روشن و با برنامه انتقال هماهنگ باشد.
در آزمون، فقط اتصال موفق بررسی نشود؛ مسدود ماندن دسترسی‌های غیرمجاز هم معیار است. اگر سامانه مالی کار کند ولی مرز آن با محیط‌های دیگر از بین برود، تحویل ناقص است. مالک امنیت و شبکه باید در تعریف معیار پذیرش حضور داشته باشد. نام محصول مقصد، به‌تنهایی حفظ سیاست فعلی را تضمین نمی‌کند.
Storage و بکاپ را وارد مقایسه کنیم
الگوی دسترسی به داده، ظرفیت، تأخیر و روش حفاظت در مقصد باید بررسی شود. یک پلتفرم ممکن است با ذخیره‌سازی موجود سازگار باشد یا برای معماری موردنظر به تغییر نیاز داشته باشد. این هزینه و ریسک نباید بعد از انتخاب ظاهر شود. آزمایش باید روی بار نزدیک به کاربرد واقعی و با فرض‌های مشخص انجام شود.
ابزار بکاپ نیز ممکن است قابلیت‌ها و محدودیت‌های متفاوتی برای هر محیط داشته باشد. باید ببینیم بازیابی فایل، ماشین یا برنامه در مقصد چگونه انجام می‌شود و نسخه‌های قبلی تا چه زمانی قابل استفاده‌اند. داشتن نام مشترک «بکاپ» به معنی یکسان بودن تجربه و اهداف بازیابی نیست. آزمون عملی باید این فاصله را روشن کند.
RTO و RPO موردنیاز سرویس بعد از مهاجرت همچنان معتبرند، مگر اینکه مدیریت آگاهانه آن‌ها را تغییر دهد. اگر انتقال باعث بدتر شدن زمان بازیابی شود، این اثر باید گزارش شود. پروژه نباید با روشن شدن ماشین‌ها تمام تلقی شود؛ حفاظت از داده و توان بازگرداندن عملیات بخشی از تحویل‌اند.
گزینه متن‌باز را با مدل بهره‌برداری بسنجیم
یک پلتفرم متن‌باز معتبر می‌تواند گزینه قابل بررسی باشد، اما بدون هزینه عملیاتی نیست. برای نمونه، Proxmox در برنامه اشتراک خود میان دسترسی به مخزن سازمانی و سطوح پشتیبانی تفاوت می‌گذارد. [۲] سازمان باید شرایط جاری خدمت، ساعات پوشش و توان تیم داخلی را برای همان گزینه بررسی کند.
اگر مسئولیت بیشتری به تیم داخلی منتقل می‌شود، مهارت، ظرفیت و جانشین‌پذیری آن تیم باید واقعی باشد. توان نصب آزمایشی محصول با توان نگهداری شبانه‌روزی محیط حساس یکسان نیست. برنامه آموزش، مستندات و مسیر رسیدگی به رخداد باید در برآورد قرار گیرند. این‌ها هزینه‌های قابل حذف از مقایسه نیستند.
در مقابل، وابستگی به یک فروشنده نیز باید آگاهانه ارزیابی شود. دسترسی به اصلاحیه، شرایط تمدید و امکان خروج از پلتفرم مهم‌اند. گزینه مناسب برای سازمانی با تیم بزرگ و باتجربه ممکن است برای تیم کوچک مناسب نباشد. تصمیم باید با مدل واقعی بهره‌برداری هماهنگ باشد، نه صرفاً محبوبیت فناوری.
مهاجرت مرحله‌ای چه زمانی مناسب است
گاهی انتقال همه بارها در یک مرحله لازم نیست. می‌توان از گروهی با وابستگی کمتر و امکان بازگشت روشن شروع کرد. این مرحله باید برای یادگیری درباره شبکه، ذخیره‌سازی، بکاپ و عملیات طراحی شود. انتخاب بار بسیار ساده که هیچ شباهتی به محیط اصلی ندارد، شواهد کافی برای انتقال سرویس حساس تولید نمی‌کند.
پس از هر مرحله، معیارهای فنی و کسب‌وکاری بررسی شوند. عملکرد، زمان نگهداری، روش بازیابی و تجربه تیم باید ثبت شود. اگر نتیجه با انتظار متفاوت است، برنامه مرحله بعد اصلاح شود. یک برنامه مرحله‌ای باید امکان تصمیم مجدد داشته باشد؛ ادامه خودکار صرفاً به دلیل شروع پروژه، منطقی نیست.
هم‌زیستی چند پلتفرم نیز هزینه دارد. تیم باید ابزار، مهارت و رویه‌های متفاوت را نگهداری کند. بنابراین مدل ترکیبی فقط وقتی مناسب است که منفعت آن از پیچیدگی اضافه بیشتر باشد. برای هر محیط، نقش و افق زمانی مشخص کنید تا معماری موقت بدون تصمیم به وضعیت دائمی تبدیل نشود.
معیارهای پذیرش را قبل از اجرا بنویسیم
این معیارها باید برای همه گزینه‌ها اعمال شوند. اگر یک گزینه فقط روی سرعت نصب و دیگری روی مجموعه کامل عملیات سنجیده شود، نتیجه مقایسه گمراه‌کننده است. در صورت تفاوت دامنه، آن تفاوت را روشن بنویسید. تصمیم مدیریت باید بر پایه نیاز پوشش‌داده‌شده و ریسک باقی‌مانده باشد.
برای هر معیار، مسئول تأیید مشخص شود. تیم اجرا نباید تنها داور موفقیت خودش باشد. مالک سرویس، امنیت و بهره‌برداری نقش‌های متفاوتی دارند. حضور آن‌ها پیش از اجرا کمک می‌کند اختلاف انتظار در زمان تحویل آشکار نشود و پروژه با تعریف مشترکی از موفقیت جلو برود.
رشد آینده را با فرض روشن وارد کنیم
برآورد فقط بر اساس بار امروز ممکن است عمر مفید تصمیم را کوتاه کند. پروژه‌های مصوب، افزایش داده و تغییر الگوی استفاده باید بررسی شوند، اما رشد نامعلوم را نباید بی‌دلیل بزرگ فرض کرد. برای هر فرض، مبنا و بازه عدم اطمینان بنویسید. این کار کمک می‌کند ظرفیت لازم از ظرفیت احتیاطی قابل تشخیص باشد و بودجه بر پایه عددی مبهم بسته نشود.
اگر برنامه Private AI هم وجود دارد، نیاز آن باید جدا اندازه‌گیری شود. لزوماً همه بارهای AI روی همان خوشه عمومی سازمان قرار نمی‌گیرند و لزوماً به تعویض کل محیط نیاز ندارند. نوع منابع، جداسازی، شبکه و مدل بهره‌برداری باید در طراحی مشخص شود. ارتباط پروژه‌ها را ببینید، اما هزینه یک نیاز نامعلوم را به کل نوسازی زیرساخت تحمیل نکنید.
برای تجهیزات موجود، عمر پشتیبانی و امکان تهیه قطعه هم اهمیت دارد. شاید یک گزینه نرم‌افزاری با سخت‌افزار فعلی اجرا شود، اما ادامه استفاده از آن سخت‌افزار در دوره برنامه‌ریزی محدودیت داشته باشد. برآورد باید زمان جایگزینی احتمالی را ببیند تا مقایسه فقط به هزینه سال نخست محدود نشود و شوک هزینه در سال بعد پنهان نماند.
بازگشت از مهاجرت را قبل از شروع تعریف کنیم
اگر بعد از انتقال یک سرویس مشکل جدی رخ دهد، آیا بازگشت ممکن است و داده‌های جدید چگونه مدیریت می‌شوند؟ نگه داشتن ماشین قدیمی به‌تنهایی پاسخ این سؤال نیست. پس از آغاز نوشتن داده در مقصد، بازگشت می‌تواند به تطبیق و انتقال تغییرات نیاز داشته باشد. روش باید برای همان برنامه و پایگاه داده طراحی و با مالک سرویس هماهنگ شود.
همچنین نقطه‌ای را که پس از آن بازگشت ساده ممکن نیست مشخص کنید. تصمیم ادامه یا توقف در آن نقطه باید با اطلاعات و اختیار روشن انجام شود. این موضوع بر پنجره مهاجرت و اطلاع‌رسانی به کاربران اثر دارد. برنامه‌ای که فقط مسیر رفت را توضیح می‌دهد، برای انتقال سامانه حیاتی کامل نیست، حتی اگر ابزار تبدیل ماشین در آزمایش موفق بوده باشد.
ارزیابی برای تصمیم مدیریت
ارزیابی اولیه باید موجودی و وابستگی‌ها، نیازهای ضروری، شکاف‌ها و گزینه‌های قابل اجرا را روشن کند. سپس برای هر گزینه، هزینه، زمان، پیش‌نیاز و ریسک ارائه شود. خروجی نباید صرفاً نام محصول پیشنهادی باشد. مدیریت باید بفهمد چرا آن گزینه با شرایط سازمان سازگارتر است و چه شواهدی هنوز لازم دارد.
در سازمان، نتیجه ممکن است حفظ بخشی از محیط و بررسی پایلوت جایگزین برای بخش دیگری باشد؛ یا ارتقا در پلتفرم فعلی توجیه بیشتری پیدا کند. تا پایان ارزیابی، پاسخ را از قبل تعیین نمی‌کنیم. موضوع اصلی، استمرار عملیات با هزینه و مسئولیت قابل مدیریت است.
راگا می‌تواند ارزیابی و مقایسه را از سطح فهرست تجهیزات به تصمیم درباره معماری و عملیات متصل کند. برای شروع، فهرست سرویس‌های حیاتی، قابلیت‌های واقعاً مورد استفاده و محدودیت بودجه را آماده کنید. بر اساس آن می‌توان نقشه راهی ساخت که هم سرمایه‌گذاری موجود را ببیند و هم انتخاب آینده را با دلیل و شاهد توضیح دهد.
چک‌لیست تصمیم‌گیری
- نیاز کسب‌وکار و قابلیت مورد استفاده مشخص شوند.
- هزینه ماندن و مهاجرت در یک بازه مشترک مقایسه شوند.
- مهاجرت به موج‌های دارای معیار پذیرش تقسیم شود.
- مسیر بازگشت، مستندات و انتقال دانش از ابتدا تعریف شوند.
مسیر VCF و مهاجرت را ارزیابی کنید
قابلیت‌های موردنیاز، هزینه تغییر، ریسک مهاجرت و مدل پشتیبانی را پیش از تصمیم نهایی بررسی کنید.
سؤالات متداول
ماندن روی پلتفرم فعلی یا مهاجرت چگونه مقایسه می‌شود؟
قابلیت موردنیاز، هزینه کل، ریسک عملیاتی، مهارت تیم و زمان تغییر باید در یک بازه مشترک سنجیده شوند.
مهاجرت مرحله‌ای چه مزیتی دارد؟
دامنه هر تغییر را محدود می‌کند و امکان پذیرش، یادگیری و بازگشت میان موج‌ها را فراهم می‌سازد.
پایان موفق مهاجرت چه زمانی است؟
وقتی سرویس‌ها پذیرفته شده‌اند و مستندات، دانش، دسترسی‌ها و پشتیبانی به تیم بهره‌بردار تحویل شده‌اند.
منابع
[۱] Broadcom — Checking Host Compatibility Before Upgrade | مشاهده منبع
[۲] Proxmox — Subscription Plans and Support | مشاهده منبع
مطالب مرتبط در سایت راگا
برای تکمیل این مسیر، نقشه خدمات VMware Cloud Foundation راگا و مقاله «مدیریت Patch و پایان پشتیبانی زیرساخت سازمان» را ببینید.