مهاجرت موفق به Azure از روز انتقال شروع نمیشود؛ از زمانی شروع میشود که سازمان بداند چه چیزی را، چرا، با چه وابستگیهایی و با چه معیار موفقیتی منتقل میکند.
بخش بزرگی از ریسکهای مهاجرت، به خودِ فرایند انتقال مربوط نیستند. این ریسکها معمولاً از نبود فهرست دقیق سیستمها، ناآشنایی با وابستگیها، مشخصنبودن مسئولیتها، طراحینشدن دسترسیها یا نداشتن برنامه بازگشت در صورت مشکل ایجاد میشوند.
این چکلیست برای مدیران IT و تیمهای فنی طراحی شده است تا پیش از شروع پروژه، آمادگی یک Workload یا بار کاری مشخص را بررسی کنند. منظور از Workload میتواند یک اپلیکیشن، سرور، پایگاهداده، محیط توسعه یا مجموعهای از اجزای وابسته باشد.
برای تصمیمگیری درباره اینکه آیا اصولاً مهاجرت به Azure برای سازمان منطقی است یا نه، ابتدا مقالهٔ چه زمانی مهاجرت به Azure برای سازمان منطقی است؟ را بخوانید.
پیش از شروع: یک Workload مشخص انتخاب کنید
«مهاجرت به Cloud» یک هدف قابلاجرا نیست. نقطه شروع باید یک Workload روشن باشد که مالک، کاربران، دادهها، وابستگیها و اهمیت آن برای کسبوکار مشخص است.
برای هر Workload، این اطلاعات پایه را ثبت کنید:
- نام و کاربرد اصلی سیستم
- مالک کسبوکاری و مالک فنی
- کاربران یا واحدهای استفادهکننده
- سطح اهمیت برای عملیات سازمان
- زمانهای پرترافیک یا حساس
- معیار موفقیت پس از مهاجرت
اگر این اطلاعات روشن نیست، مهاجرت را آغاز نکنید. ابتدا باید تصویر مشترکی از سیستم و مسئولیتها ایجاد شود.
۱. هدف و محدوده پروژه را بررسی کنید
پیش از هر تصمیم فنی، مشخص کنید مهاجرت قرار است چه نتیجهای ایجاد کند.
- هدف اصلی مهاجرت مشخص است؛ مانند نوسازی زیرساخت، بهبود پایداری، ایجاد ظرفیت جدید یا مدرنسازی اپلیکیشن.
- مشخص است کدام Workloadها در این مرحله منتقل میشوند و کدام موارد خارج از محدوده هستند.
- برای هر Workload، مالک کسبوکاری و مسئول فنی تعیین شده است.
- معیارهای موفقیت مشخصاند؛ مانند زمان راهاندازی، پایداری، زمان پاسخ، کاهش کار دستی یا آمادگی برای رشد.
- ذینفعان اصلی از برنامه و اثر احتمالی آن بر کارشان آگاه هستند.
هدف روشن، انتخاب معماری، اولویتبندی و سنجش نتیجه را سادهتر میکند.
۲. موجودی سیستمها و وابستگیها را کامل کنید
یک سرور یا اپلیکیشن بهندرت بهتنهایی کار میکند. ممکن است به پایگاهداده، فایل، DNS، سرویس هویت، API، سامانه مالی، سرویس پیامک یا دستگاهی در شبکه داخلی وابسته باشد.
- سرورها، اپلیکیشنها، پایگاههای داده و فضای ذخیرهسازی مرتبط فهرست شدهاند.
- وابستگیهای داخلی و خارجی Workload ثبت شدهاند.
- ارتباط میان اپلیکیشن و پایگاهداده یا سرویسهای دیگر مشخص است.
- پورتها، مسیرهای ارتباطی و نیازهای شبکه اصلی بررسی شدهاند.
- سرویسهای شخص ثالث، لایسنسها و وابستگیهای نرمافزاری شناسایی شدهاند.
- ترتیب مناسب مهاجرت اجزای وابسته مشخص شده است.
نادیدهگرفتن وابستگیها میتواند باعث شود یک سیستم در محیط جدید روشن باشد، اما بهدرستی کار نکند.
۳. سازگاری فنی را ارزیابی کنید
همه Workloadها برای انتقال مستقیم آماده نیستند. نسخه سیستمعامل، پایگاهداده، نرمافزارهای وابسته، درایورها و معماری فعلی میتوانند بر مسیر مهاجرت اثر بگذارند.
- نسخههای سیستمعامل و نرمافزارهای اصلی ثبت و بررسی شدهاند.
- محدودیتهای فنی یا ناسازگاریهای احتمالی مشخص شدهاند.
- نیاز به تغییر پیکربندی، بهروزرسانی یا مدرنسازی پیش از مهاجرت بررسی شده است.
- نیازهای پردازشی، حافظه، ذخیرهسازی و شبکه با داده واقعی یا قابلاتکا برآورد شدهاند.
- روش انتقال متناسب با نوع Workload انتخاب شده است.
- تیم درباره اینکه انتقال با تغییر محدود انجام میشود یا نیاز به Modernization دارد، تصمیم اولیه گرفته است.
ابزارهایی مانند Azure Migrate میتوانند برای کشف اطلاعات، ارزیابی آمادگی، تحلیل وابستگیها و برآورد اولیه کمککننده باشند. با این حال، ابزار ارزیابی جایگزین بررسی معماری و تأیید تیم مسئول سیستم نیست.
۴. محیط پایه Azure را آماده کنید
پیش از انتقال اولین Workload، محیط Azure باید ساختار قابلکنترلی داشته باشد. ایجاد سریع منابع بدون ساختار دسترسی، نامگذاری و مسئولیت روشن، در آینده مدیریت و کنترل هزینه را دشوار میکند.
- ساختار Subscriptionها، Resource Groupها و نامگذاری منابع مشخص شده است.
- نقشها و سطح دسترسیهای مدیریتی تعریف شدهاند.
- مسئول ایجاد، تغییر و حذف منابع مشخص است.
- اصول اولیه Governance و ثبت تغییرات در نظر گرفته شدهاند.
- محیط توسعه، آزمایشی و عملیاتی در صورت نیاز از هم تفکیک شدهاند.
- منطقه یا Region هدف با توجه به نیازهای عملیاتی، کاربر و داده انتخاب شده است.
۵. شبکه، هویت و دسترسی را بررسی کنید
دسترسی کاربران و ارتباط میان محیط داخلی و Azure باید پیش از Cutover طراحی شود. بسیاری از مشکلات روز انتقال، به شبکه، DNS، هویت یا سطح دسترسی مربوطاند.
- روش اتصال امن میان محیط داخلی و Azure، در صورت نیاز، مشخص شده است.
- تنظیمات DNS و نامهای موردنیاز بررسی شدهاند.
- روش Authentication و دسترسی کاربران روشن است.
- حسابهای سرویس، کلیدها و Credentialهای موردنیاز شناسایی شدهاند.
- سطح دسترسی مدیران، اپلیکیشنها و کاربران بر اساس نقش واقعی تعریف شده است.
- دسترسیهای موقت یا اضطراری دارای مسئول و زمان بازبینی مشخص هستند.
مدیریت هویت و دسترسی باید بر اصل حداقل دسترسی استوار باشد؛ یعنی هر کاربر یا سرویس فقط مجوزهای لازم برای انجام وظیفه خود را داشته باشد.
۶. امنیت را از ابتدا در طراحی قرار دهید
امنیت مرحلهای نیست که پس از پایان مهاجرت به آن اضافه شود. از همان ابتدا باید مشخص باشد چه دادههایی حساساند، چه کسی به آنها دسترسی دارد و رویدادهای مهم چگونه ثبت و بررسی میشوند.
- دادههای حساس و سطحبندی آنها مشخص شده است.
- مسئولیتهای امنیتی میان تیم سازمان و تیم اجرایی روشن است.
- دسترسیهای مدیریتی و حسابهای حساس بازبینی شدهاند.
- سیاستهای شبکه، دسترسی و حفاظت از داده بررسی شدهاند.
- روش ثبت رخدادها و گزارشهای موردنیاز مشخص شده است.
- برنامه واکنش به رخداد و مسیر اطلاعرسانی در صورت مشکل وجود دارد.
۷. پشتیبانگیری، بازیابی و برنامه بازگشت داشته باشید
هیچ مهاجرتی نباید بدون برنامه برگشت یا Rollback اجرا شود. حتی اگر احتمال خطا کم باشد، سازمان باید بداند در صورت بروز مشکل چه کسی، در چه زمانی و با چه روشی تصمیم به بازگشت میگیرد.
- از دادهها و تنظیمات ضروری، نسخه پشتیبان قابلبازیابی وجود دارد.
- روش و زمان بازیابی در صورت خطا تعریف شده است.
- نقطه تصمیمگیری برای ادامه یا بازگشت مشخص است.
- مسئول تصمیمگیری در شرایط اضطراری تعیین شده است.
- فرایند بازیابی پیش از انتقال عملیاتی یا در محیط آزمایشی بررسی شده است.
- نیازهای تداوم کسبوکار برای Workload ثبت شدهاند.
پشتیبانگیری فقط داشتن یک نسخه از داده نیست؛ باید بتوان آن را در زمان موردنیاز، با نتیجه قابلقبول بازیابی کرد.
۸. هزینه و مسئولیت مالی را شفاف کنید
هزینه در Azure به منابع ایجادشده، روش استفاده و مدت بهرهبرداری وابسته است. بنابراین کنترل هزینه باید بخشی از آمادهسازی مهاجرت باشد، نه اقدامی پس از مشاهده قبض.
- برآورد اولیه هزینه برای Workload هدف تهیه شده است.
- مالک یا مسئول بررسی هزینه مشخص است.
- بودجه، هشدارها و فرایند بازبینی مصرف در نظر گرفته شدهاند.
- منابع غیرضروری، محیطهای آزمایشی و دوره نگهداری آنها مشخص شدهاند.
- هزینههای عملیاتی، پشتیبانی و ابزارهای جانبی نیز در تصمیمگیری دیده شدهاند.
- فرایند بررسی هزینه پس از مهاجرت تعریف شده است.
۹. برنامه اجرا و Cutover را آماده کنید
برنامه مهاجرت باید برای همه افراد درگیر قابلفهم باشد. یک برنامه خوب فقط شامل کارهای فنی نیست؛ زمانبندی، اطلاعرسانی، مسئولیتها و روش تأیید نتیجه را نیز پوشش میدهد.
- زمان اجرای مهاجرت با درنظرگرفتن کاربران و عملیات کسبوکار انتخاب شده است.
- مسئول هر مرحله و راه ارتباطی او مشخص است.
- تغییرات غیرضروری در دوره مهاجرت محدود یا مدیریت شدهاند.
- اطلاعرسانی موردنیاز به کاربران و ذینفعان آماده شده است.
- مراحل انتقال، بررسی، Cutover و Rollback مستند شدهاند.
- معیارهای تأیید موفقیت پس از انتقال مشخص شدهاند.
۱۰. پس از مهاجرت چه چیزی را تأیید میکنید؟
مهاجرت زمانی کامل نیست که منابع در Azure ایجاد شدهاند. باید مطمئن شوید سیستم از دید کاربر و مالک کسبوکار نیز درست کار میکند.
- کارکردهای اصلی اپلیکیشن آزمایش شدهاند.
- دسترسی کاربران و حسابهای سرویس بررسی شده است.
- دادههای ضروری از نظر کاملبودن و درستی تأیید شدهاند.
- اتصال به سامانههای وابسته آزمایش شده است.
- پشتیبانگیری، پایش و هشدارها فعال و بررسی شدهاند.
- تیم پشتیبانی مسیر رسیدگی به خطاهای احتمالی را میداند.
- مالک کسبوکار، عملکرد بخشهای اصلی را تأیید کرده است.
جمعبندی
این چکلیست قرار نیست جای ارزیابی فنی و طراحی معماری را بگیرد. هدف آن این است که سازمان پیش از شروع مهاجرت، سؤالهای مهم را فراموش نکند: چه چیزی منتقل میشود؟ چرا؟ چه وابستگیهایی دارد؟ چه کسی مسئول آن است؟ در صورت خطا چه میکنیم؟ و چگونه موفقیت را میسنجیم؟
هرچه پاسخ این سؤالها پیش از اجرا روشنتر باشد، مهاجرت قابلکنترلتر و ریسک آن کمتر خواهد بود.
برای بررسی آمادگی Workloadها، طراحی برنامه مهاجرت و تعیین مسیر اجرایی Azure، از طریق فرم تماس با کلود مشاور در ارتباط باشید یا سرویس مهاجرت و نوسازی زیرساخت را ببینید.
منابع و تاریخ بازبینی
- Cloud adoption plan template for migration — Microsoft Learn
- Prepare workloads for cloud migration — Microsoft Learn
- Execute migration to cloud — Microsoft Learn
- Cloud Adoption Framework for Azure — Microsoft Learn
آخرین بازبینی: ۲۱ شهریور ۱۴۰۵
