مهاجرت به فضای ابری ممکن است نگهداری زیرساخت را سادهتر کند یا سرعت توسعه را بالا ببرد، اما «هزینهٔ سرویس ابری» با «هزینهٔ کامل مهاجرت» یکسان نیست. انتقال داده، ارزیابی برنامهها، تغییر معماری، اجرای همزمان دو محیط، آموزش تیم و آمادهسازی راه بازگشت میتوانند پیش از رسیدن به وضعیت پایدار هزینه ایجاد کنند. این راهنما کمک میکند این اقلام را پیش از تصمیمگیری شناسایی و برآورد کنید؛ نه اینکه یک مبلغ ثابت و غیرواقعی برای همهٔ پروژهها پیشنهاد دهد.
اگر هنوز با مدلهای زیرساخت ابری آشنا نیستید، ابتدا راهنمای رایانش ابری و کاربردهای آن را بخوانید. برای مقایسهٔ سرویسها و هزینهٔ کل نیز راهنمای انتخاب ارائهدهندهٔ خدمات ابری مکمل این مقاله است.
هزینهٔ مهاجرت با هزینهٔ ماهانهٔ ابر چه تفاوتی دارد؟
هزینهٔ مهاجرت معمولاً شامل کارهای موقت پروژه است؛ مانند کشف وابستگیها، انتقال داده، بازطراحی، آزمون و جابهجایی نهایی. هزینهٔ جاری پس از مهاجرت شامل پردازش، ذخیرهسازی، شبکه، پشتیبانگیری، پایش، پشتیبانی و نیروی انسانی برای ادارهٔ محیط است. این دو را در یک برآورد جداگانه ثبت کنید تا هزینهٔ یکباره با هزینهٔ تکرارشونده اشتباه نشود.
برای درک اجزای قبض ماهانه، مقالهٔ مدیریت هزینههای ابری و پایش مصرف را هم ببینید. آن مقاله روی کنترل هزینه پس از استقرار تمرکز دارد؛ این راهنما روی هزینههایی که هنگام مهاجرت یا بهدلیل خود مهاجرت ایجاد میشوند.
۱. کشف داراییها و ارزیابی پیش از مهاجرت
پیش از قیمتگذاری مقصد، باید بدانید چه چیزی را منتقل میکنید. فهرست سرورها، پایگاههای داده، نسخهٔ سیستمعامل، مجوز نرمافزار، وابستگیهای شبکه، حجم و رشد داده، الگوی مصرف و اهمیت تجاری هر برنامه را تهیه کنید. برنامهای که به سختافزار یا نسخهٔ قدیمی پایگاه داده وابسته است، ممکن است به اصلاح یا جایگزینی نیاز داشته باشد؛ در نتیجه، برآوردی که فقط تعداد ماشینهای مجازی را میشمارد ناقص است.
هزینهٔ این مرحله میتواند شامل زمان تیم داخلی، ابزارهای کشف، مشاوره و آزمون سازگاری باشد. آن را از ابتدا در بودجه بیاورید. راهنمای Microsoft Learn دربارهٔ طراحی معماری برای برآورد هزینه نیز بر ثبت معماری، انتخاب سرویس و بررسی نیازهای عملیاتی پیش از تخمین تأکید میکند.
۲. انتقال داده و هزینههای شبکه
انتقال حجم زیاد داده ممکن است به پهنای باند، اتصال اختصاصی، ابزار انتقال یا زمانبندی خارج از ساعات اوج نیاز داشته باشد. هزینه فقط به حجم داده وابسته نیست؛ مبدأ، مقصد، منطقه، نوع سرویس، جهت انتقال و قرارداد نیز میتوانند مؤثر باشند. انتقال داده به ابر، انتقال میان مناطق و خروج داده از ابر را در مدل هزینه جداگانه بررسی کنید.
از درج یک نرخ عمومی برای همهٔ ارائهدهندگان خودداری کنید. تعرفهها و برنامههای انتقال ممکن است تغییر کنند و برخی استثناها به سرویس یا شرایط واجد شرایط بودن وابستهاند. برای برآورد، از صفحهٔ قیمتگذاری شبکهٔ Google Cloud و راهنمای مدلسازی هزینهٔ انتقال داده در AWS Well-Architected شروع کنید و فرضها را با الگوی واقعی ترافیک خود تطبیق دهید.
حجم دادهٔ تکراری یا منسوخ را پیش از انتقال شناسایی کنید، صحت داده را بعد از کپیکردن بررسی کنید و برای همگامسازی نهایی، توقف سرویس و احتمال تکرار انتقال زمان و هزینه در نظر بگیرید.
۳. بازطراحی، سازگاری و مجوز نرمافزار
انتقال بدون تغییر، بازپلتفرمسازی و بازطراحی کامل هزینه و ریسک یکسانی ندارند. ممکن است لازم باشد برنامه با سرویس مدیریتشده سازگار شود، نسخهٔ زبان یا سیستمعامل تغییر کند، اتصالها بازنویسی شوند یا مجوزهای تجاری دوباره بررسی شوند. در مقابل، بازطراحی بیش از حد نیز میتواند پروژه را طولانی کند و زمان رسیدن به ارزش را عقب بیندازد.
برای هر بار کاری، گزینههای «انتقال با تغییر کم»، «تغییر محدود»، «بازطراحی»، «جایگزینی» یا «فعلاً عدم انتقال» را مقایسه کنید. هزینهٔ مهندسی، آزمون، سازگاری و پشتیبانی را جدا ثبت کنید. تصمیم را فقط بر اساس قیمت سرویس مقصد نگیرید؛ نیاز عملکردی، مهارت تیم و هزینهٔ نگهداری بلندمدت نیز اهمیت دارند.
۴. اجرای موازی، آزمون و برنامهٔ بازگشت
در بسیاری از مهاجرتها محیط قدیمی تا زمانی که محیط جدید آزموده نشده، خاموش نمیشود. در این دوره ممکن است برای هر دو محیط هزینهٔ پردازش، ذخیرهسازی، شبکه، پشتیبانی و مجوز پرداخت شود. همگامسازی داده و آزمون عملکرد نیز منابع مصرف میکند.
پیش از شروع، معیار پذیرش را مشخص کنید: چه سطحی از زمان پاسخ، نرخ خطا، دسترسپذیری و صحت داده قابل قبول است؟ چه کسی اجازهٔ تغییر نهایی را میدهد؟ اگر آزمون شکست خورد، بازگشت به محیط قبلی چقدر زمان میبرد و چه دادهای ممکن است از دست برود؟ هزینهٔ این آزمونها را حذف نکنید؛ آنها بخشی از کاهش ریسکاند.
۵. امنیت، پشتیبانگیری و الزامات انطباق
محیط مقصد به پیکربندی هویت و دسترسی، مدیریت کلیدها، رمزگذاری، ثبت رویدادها، دیوارهٔ آتش، اسکن آسیبپذیری و پشتیبانگیری نیاز دارد. برخی کنترلها ممکن است در سرویس انتخابی گنجانده شده باشند و برخی دیگر به ابزار یا نیروی انسانی جداگانه نیاز داشته باشند. این موارد را بهصورت خودکار «رایگان» فرض نکنید.
اگر دادهها محدودیت محل نگهداری، قرارداد یا مقررات دارند، هزینهٔ بررسی حقوقی و امنیتی را نیز لحاظ کنید. برای تعیین سطح حفاظت و بازیابی، راهنمای پشتیبانگیری ابری و بازیابی داده مکمل این مقاله است. هزینهٔ کنترل امنیتی را باید در کنار پیامد احتمالی اختلال یا نشت داده سنجید، نه صرفاً بهعنوان یک ردیف قابل حذف.
۶. آموزش تیم و تغییر شیوهٔ عملیات
پس از مهاجرت، تیم ممکن است به مهارتهای تازه در مدیریت هویت، شبکه، پایش، خودکارسازی، هزینه و پاسخ به رخداد نیاز داشته باشد. هزینهٔ دورهها تنها بخش ماجراست؛ زمان کارکنان برای یادگیری، مستندسازی، اصلاح فرایند استقرار و هماهنگی میان تیم فنی و مالی هم باید برآورد شود.
مسئولیت هر سرویس را مشخص کنید: چه کسی مصرف را بررسی میکند، چه کسی هشدار را دریافت میکند، چه کسی تغییر معماری را تأیید میکند و چه کسی در زمان رخداد پاسخگوست؟ نبود مالک مشخص ممکن است باعث منابع رهاشده، هزینهٔ غیرمنتظره یا تأخیر در حل مشکل شود.
۷. هزینهٔ وابستگی به ارائهدهنده و خروج احتمالی
استفاده از سرویسهای اختصاصی میتواند بهرهوری را بالا ببرد، اما خروج از آنها در آینده ممکن است به بازنویسی برنامه، تبدیل داده، جایگزینی ابزار، آزمون مجدد و آموزش نیاز داشته باشد. این به معنی اجتناب از سرویسهای مدیریتشده نیست؛ هدف این است که مزیت آنها را در برابر وابستگی و هزینهٔ تغییر بسنجید.
پیش از قرارداد، قالبهای خروجی داده، دسترسی به نسخههای پشتیبان، قابلیت انتقال تنظیمات، هزینههای انتقال و زمان لازم برای جایگزینی را بررسی کنید. راهبرد خروج را در حد یک سند عملی نگه دارید: داده کجاست، چه قالبی دارد، چه کسی مالک آن است و چگونه صحت آن پس از انتقال تأیید میشود.
جدول برآورد هزینههای پنهان مهاجرت
| قلم هزینه | روش برآورد | زمان وقوع |
|---|---|---|
| کشف داراییها و وابستگیها | ساعت تیم، ابزار و ارزیابی | پیش از مهاجرت |
| انتقال و اعتبارسنجی داده | حجم، مسیر، پهنای باند و آزمون صحت | حین انتقال |
| تغییر برنامه و مجوزها | تخمین مهندسی، آزمون و هزینهٔ مجوز | پیش و حین مهاجرت |
| اجرای موازی و بازگشت | منابع دو محیط و مدت همزمانی | آزمون و جابهجایی نهایی |
| امنیت و انطباق | ابزار، ممیزی، ذخیرهسازی پشتیبان و نیروی متخصص | پیش، حین و پس از مهاجرت |
| آموزش و عملیات | زمان کارکنان، پشتیبانی و تغییر فرایند | حین و پس از مهاجرت |
| بهینهسازی پس از انتقال | پایش مصرف، آزمون عملکرد و اصلاح منابع | ماههای نخست بهرهبرداری |
چطور یک برآورد قابل دفاع بسازیم؟
- خط پایه بسازید: مصرف، عملکرد، زمان توقف، هزینهٔ مجوز و حجم دادهٔ محیط فعلی را ثبت کنید.
- بارهای کاری را دستهبندی کنید: میزان اهمیت، وابستگی، حساسیت داده و روش مهاجرت هرکدام را مشخص کنید.
- معماری مقصد را تعریف کنید: سرویس، منطقه، سطح عملکرد، پشتیبانگیری و نیازهای شبکه را تعیین کنید؛ سپس از ماشینحساب رسمی قیمتگذاری استفاده کنید.
- سه سناریو بسازید: برآورد خوشبینانه، محتمل و پرریسک را با فرضهای روشن مقایسه کنید. اجرای موازی، تأخیر و کار دوباره را در سناریوی پرریسک فراموش نکنید.
- یک پایلوت اجرا کنید: یک بار کاری نماینده را منتقل کنید و هزینه و عملکرد واقعی را با تخمین مقایسه کنید.
- پس از انتقال بازبینی کنید: در هفتهها و ماههای نخست، انحراف هزینه، منابع بلااستفاده و هزینههای شبکه را پایش و مدل را بهروزرسانی کنید.
فرمول سادهٔ شروع این است: هزینهٔ کل مهاجرت = ارزیابی + انتقال داده + تغییر و آزمون + اجرای موازی + امنیت و آموزش + ذخیرهٔ ریسک. سپس هزینهٔ جاری ماهانه را جداگانه به مدل اضافه کنید. برای برآورد معماری و خدمات مقصد میتوانید از راهنمای برآورد معماری در Microsoft Learn و ماشینحساب قیمت ارائهدهندهٔ منتخب استفاده کنید.
اشتباههای رایج در برآورد
- محاسبهٔ هزینهٔ ماشینهای مجازی بدون شبکه، ذخیرهسازی، پشتیبانگیری و پایش.
- نادیدهگرفتن دورهٔ اجرای همزمان محیط قدیم و جدید.
- فرض اینکه همهٔ برنامهها بدون تغییر منتقل میشوند.
- نادیدهگرفتن آموزش، مجوزهای نرمافزاری و زمان کارکنان.
- اتکا به یک برآورد ثابت بدون آزمون بار کاری واقعی.
- در نظر نگرفتن روش بازگشت و هزینهٔ خروج احتمالی.
پرسشهای متداول
آیا مهاجرت به ابر همیشه هزینه را کاهش میدهد؟
خیر. نتیجه به الگوی مصرف، معماری، نیاز دسترسپذیری، مجوزها و توان تیم بستگی دارد. مقایسه باید هزینهٔ کل و ارزش عملیاتی را در بازهای مشخص بسنجد، نه فقط قیمت یک سرور.
چه زمانی باید هزینهٔ خروج داده را بررسی کنیم؟
از مرحلهٔ طراحی. مقدار و مسیر ترافیک، منطقه و سرویس انتخابی را بررسی کنید و تعرفهٔ فعلی ارائهدهنده را در زمان برآورد بخوانید؛ شرایط ممکن است تغییر کند یا استثنا داشته باشد.
آیا برای هر مهاجرتی به بازطراحی کامل نیاز است؟
خیر. روش مهاجرت باید برای هر بار کاری جدا انتخاب شود. گاهی انتقال با تغییر کم منطقی است؛ گاهی ناسازگاری، امنیت یا نیازهای عملیاتی، بازطراحی را توجیه میکند.
جمعبندی
هزینهٔ واقعی مهاجرت به ابر فراتر از قبض سرویس مقصد است. ارزیابی دقیق، انتقال داده، سازگاری برنامه، اجرای موازی، امنیت، آموزش و بهینهسازی پس از استقرار را جداگانه برآورد کنید. با ثبت فرضها، آزمون محدود و مقایسهٔ هزینهٔ واقعی با برآورد، میتوان تصمیمی شفافتر گرفت و احتمال غافلگیری بودجه را کاهش داد.
اعتبار تصویر شاخص: Esquilo، «PDC server room»، صفحهٔ منبع در Wikimedia Commons، مجوز CC BY-SA 3.0.
