راهنمای مهاجرت به زیرساخت ابری؛ از ارزیابی تا انتقال امن سرویس‌ها

راهنمای مهاجرت به زیرساخت ابری به مدیران، کارشناسان فناوری اطلاعات و صاحبان کسب‌وکار کمک می‌کند تا سرورها، نرم‌افزارها، پایگاه‌های داده و سرویس‌های سازمانی خود را با کمترین ریسک از زیرساخت سنتی به محیط ابری منتقل کنند.

مهاجرت به فضای ابری فقط به معنای انتقال چند سرور یا فایل نیست. این فرایند یک پروژه مهم سازمانی است که باید در آن معماری نرم‌افزار، امنیت اطلاعات، شبکه، هزینه‌ها، پشتیبان‌گیری، دسترسی کاربران، تداوم کسب‌وکار و نحوه مدیریت زیرساخت بررسی شود.

اگر مهاجرت بدون ارزیابی و برنامه‌ریزی انجام شود، ممکن است هزینه‌های سازمان افزایش پیدا کند، سرویس‌ها دچار اختلال شوند یا امنیت داده‌ها به خطر بیفتد. در مقابل، یک مهاجرت اصولی می‌تواند مقیاس‌پذیری، پایداری، سرعت ارائه خدمات و کنترل مدیریتی سازمان را بهبود دهد.

در این راهنمای مهاجرت به زیرساخت ابری تمام مراحل لازم، از ارزیابی زیرساخت فعلی تا انتقال اطلاعات، انتخاب معماری، کنترل هزینه و بهینه‌سازی پس از مهاجرت بررسی می‌شود.

زیرساخت ابری چیست؟

زیرساخت ابری مجموعه‌ای از منابع پردازشی، فضای ذخیره‌سازی، شبکه، پایگاه داده، ابزارهای امنیتی و سرویس‌های نرم‌افزاری است که بر اساس نیاز سازمان در اختیار آن قرار می‌گیرد.

در زیرساخت سنتی، سازمان برای افزایش ظرفیت باید سرور، ذخیره‌ساز، تجهیزات شبکه و سایر سخت‌افزارهای موردنیاز را خریداری کند. این فرایند ممکن است زمان‌بر و پرهزینه باشد.

در زیرساخت ابری، بسیاری از منابع را می‌توان در مدت کوتاهی ایجاد، افزایش، کاهش یا حذف کرد. سازمان می‌تواند متناسب با میزان مصرف خود از منابع استفاده کند و برای توسعه سرویس‌های جدید، منتظر خرید و نصب تجهیزات فیزیکی نماند.

منابع زیرساخت ابری معمولاً شامل موارد زیر هستند:

• ماشین‌های مجازی
• پردازنده و حافظه
• فضای ذخیره‌سازی
• شبکه‌های خصوصی
• فایروال و کنترل دسترسی
• پایگاه داده مدیریت‌شده
• سامانه پشتیبان‌گیری
• مانیتورینگ و ثبت لاگ
• ابزارهای استقرار نرم‌افزار
• سرویس‌های تحلیل داده
• زیرساخت کانتینری
• ابزارهای امنیتی

مهاجرت به زیرساخت ابری چیست؟

مهاجرت ابری یا Cloud Migration فرایندی است که در آن بخشی یا تمام دارایی‌های فناوری اطلاعات یک سازمان از سرورهای داخلی، دیتاسنتر فعلی یا یک ارائه‌دهنده دیگر به محیط ابری منتقل می‌شوند.

دارایی‌هایی که می‌توانند در این فرایند منتقل شوند عبارت‌اند از:

• وب‌سایت‌ها
• نرم‌افزارهای سازمانی
• سامانه‌های فروش و CRM
• پایگاه‌های داده
• فایل‌ها و اسناد سازمانی
• ماشین‌های مجازی
• سرویس‌های حسابداری
• ابزارهای مانیتورینگ
• سامانه‌های پشتیبان‌گیری
• محیط‌های توسعه و آزمایش
• سرویس‌های ارتباطی میان شعب
• سامانه‌های گزارش‌گیری
• نرم‌افزارهای اتوماسیون

مهاجرت ممکن است به‌صورت کامل یا مرحله‌ای انجام شود. برخی سازمان‌ها تمام زیرساخت خود را به کلود منتقل می‌کنند، اما برخی دیگر فقط سرویس‌های مشخصی را به محیط ابری انتقال می‌دهند.

در بسیاری از پروژه‌ها، مدل ترکیبی انتخاب می‌شود؛ یعنی بخشی از سرویس‌ها در داخل سازمان باقی می‌مانند و بخش دیگری به فضای ابری منتقل می‌شوند.

چرا سازمان‌ها به زیرساخت ابری مهاجرت می‌کنند؟

دلایل مهاجرت به فضای ابری در هر سازمان متفاوت است. بعضی کسب‌وکارها برای کاهش هزینه خرید تجهیزات به کلود مهاجرت می‌کنند و برخی دیگر به دنبال افزایش مقیاس‌پذیری، امنیت یا پایداری سرویس‌های خود هستند.

افزایش مقیاس‌پذیری

یکی از مهم‌ترین مزایای زیرساخت ابری، امکان افزایش یا کاهش سریع منابع است.

در زیرساخت سنتی، اگر تعداد کاربران یا حجم پردازش افزایش پیدا کند، ممکن است سازمان مجبور به خرید سرور جدید شود. این فرایند به بودجه، زمان خرید، نصب تجهیزات و پیکربندی نیاز دارد.

در محیط ابری، منابع پردازشی و فضای ذخیره‌سازی را می‌توان متناسب با میزان مصرف تغییر داد.

این قابلیت برای کسب‌وکارهای زیر اهمیت زیادی دارد:

• فروشگاه‌های اینترنتی
• پلتفرم‌های آموزشی
• سامانه‌های رزرو
• مراکز تماس
• نرم‌افزارهای سازمانی
• پلتفرم‌های خدمات آنلاین
• سامانه‌های مناسبتی و پرترافیک

کاهش زمان راه‌اندازی سرویس‌ها

خرید و آماده‌سازی یک سرور فیزیکی ممکن است چند روز یا حتی چند هفته طول بکشد. در زیرساخت ابری، می‌توان بسیاری از منابع را در مدت کوتاهی ایجاد کرد.

این ویژگی باعث می‌شود تیم فنی بتواند محیط توسعه، آزمایش یا تولید را سریع‌تر آماده کند و محصولات جدید در زمان کوتاه‌تری وارد بازار شوند.

افزایش پایداری سرویس‌ها

زیرساخت ابری امکان توزیع سرویس‌ها در چند سرور یا چند ناحیه را فراهم می‌کند. اگر معماری به‌درستی طراحی شود، خرابی یک سرور باعث توقف کامل سامانه نخواهد شد.

برای افزایش پایداری می‌توان از ابزارهای زیر استفاده کرد:

• Load Balancer
• سرورهای جایگزین
• پایگاه داده افزونه
• ذخیره‌سازی توزیع‌شده
• مانیتورینگ لحظه‌ای
• پشتیبان‌گیری خودکار
• بازیابی بحران
• مقیاس‌پذیری خودکار

کاهش وابستگی به تجهیزات فیزیکی

سرورهای فیزیکی به تعمیر، نگهداری، برق پایدار، سیستم سرمایش، فضای رک و تجهیزات شبکه نیاز دارند.

در مدل ابری، بخش مهمی از این مسئولیت‌ها بر عهده ارائه‌دهنده زیرساخت قرار می‌گیرد. البته سازمان همچنان مسئول امنیت نرم‌افزار، مدیریت دسترسی‌ها، تنظیمات سرورها و حفاظت از اطلاعات خود خواهد بود.

بهبود پشتیبان‌گیری و بازیابی بحران

در زیرساخت ابری می‌توان نسخه‌های پشتیبان را به‌صورت خودکار و در موقعیت‌های مختلف نگهداری کرد.

با این حال، داشتن فایل پشتیبان به‌تنهایی کافی نیست. سازمان باید بازیابی اطلاعات را نیز به‌صورت دوره‌ای آزمایش کند.

نسخه پشتیبانی که امکان بازیابی آن بررسی نشده باشد، نمی‌تواند تضمین مناسبی برای ادامه فعالیت سازمان باشد.

افزایش سرعت توسعه نرم‌افزار

زیرساخت ابری با ابزارهای DevOps، کانتینرها و فرایندهای CI/CD ترکیب می‌شود و به تیم‌های توسعه کمک می‌کند نسخه‌های جدید نرم‌افزار را سریع‌تر و کنترل‌شده‌تر منتشر کنند.

از جمله مزایای این رویکرد می‌توان به موارد زیر اشاره کرد:

• کاهش خطاهای انسانی
• استقرار خودکار نرم‌افزار
• امکان بازگشت سریع نسخه
• ایجاد محیط‌های مشابه
• ثبت تغییرات زیرساخت
• مانیتورینگ بهتر
• کاهش زمان انتشار نسخه جدید

دسترسی بهتر نیروهای دورکار و شعب

سازمان‌هایی که دارای چند شعبه یا نیروهای دورکار هستند، می‌توانند با طراحی صحیح زیرساخت ابری، دسترسی متمرکز و کنترل‌شده‌ای به سرویس‌های سازمانی ایجاد کنند.

این دسترسی باید با استفاده از ابزارهایی مانند VPN، احراز هویت چندمرحله‌ای، محدودیت سطح دسترسی و ثبت فعالیت کاربران ایمن شود.

چه زمانی سازمان برای مهاجرت ابری آماده است؟

مهاجرت به فضای ابری برای تمام سازمان‌ها و تمام سرویس‌ها ضروری نیست. قبل از تصمیم‌گیری باید مشکلات زیرساخت فعلی، هزینه‌ها، محدودیت‌های قانونی و برنامه‌های آینده سازمان بررسی شوند.

وجود نشانه‌های زیر می‌تواند نیاز به مهاجرت را مشخص کند:

• سرورها در ساعات پرترافیک پاسخ‌گو نیستند.
• خرید تجهیزات جدید هزینه زیادی دارد.
• راه‌اندازی محیط توسعه و آزمایش زمان‌بر است.
• سازمان برنامه مشخصی برای بازیابی بحران ندارد.
• تجهیزات فعلی قدیمی یا خارج از پشتیبانی هستند.
• منابع فعلی در بیشتر ساعات بلااستفاده باقی می‌مانند.
• مصرف منابع در دوره‌های مختلف تغییر زیادی دارد.
• انتشار نسخه‌های نرم‌افزار با خطای انسانی همراه است.
• شعب سازمان به دسترسی متمرکز نیاز دارند.
• کارکنان دورکار باید به سامانه‌های داخلی متصل شوند.
• زمان بازیابی سرویس‌ها طولانی است.
• نسخه‌های پشتیبان در همان محل سرورها نگهداری می‌شوند.
• سازمان قصد توسعه پروژه‌های داده و هوش مصنوعی دارد.

چه سرویس‌هایی نباید بدون بررسی به کلود منتقل شوند؟

برخی نرم‌افزارها یا سرویس‌ها ممکن است شرایط خاصی داشته باشند و انتقال مستقیم آن‌ها مناسب نباشد.

این موارد شامل سرویس‌های زیر هستند:

• نرم‌افزارهای وابسته به سخت‌افزار خاص
• برنامه‌های دارای قفل سخت‌افزاری
• سامانه‌های قدیمی بدون مستندات
• نرم‌افزارهایی که کد منبع آن‌ها در دسترس نیست
• سرویس‌های دارای محدودیت قانونی نگهداری داده
• برنامه‌های وابسته به شبکه محلی با تأخیر بسیار کم
• سامانه‌هایی با هزینه خروج اطلاعات بالا
• نرم‌افزارهایی که مجوز اجرای ابری ندارند
• سرویس‌هایی با وابستگی‌های ناشناخته

در این شرایط، ممکن است استفاده از ابر خصوصی، معماری هیبریدی یا نگهداری موقت سرویس در زیرساخت فعلی گزینه مناسب‌تری باشد.

انتخاب مدل مناسب زیرساخت ابری

یکی از بخش‌های مهم در راهنمای مهاجرت به زیرساخت ابری انتخاب مدل استقرار مناسب است.

ابر عمومی

در ابر عمومی، سازمان منابع موردنیاز خود را از زیرساخت یک ارائه‌دهنده دریافت می‌کند.

مزایای ابر عمومی عبارت‌اند از:

• راه‌اندازی سریع
• تنوع زیاد سرویس‌ها
• مقیاس‌پذیری
• کاهش نیاز به خرید تجهیزات
• پرداخت بر اساس مصرف
• دسترسی به ابزارهای مدیریت‌شده

محدودیت‌های آن نیز شامل وابستگی به ارائه‌دهنده، هزینه ترافیک، قوانین نگهداری داده و پیچیدگی مدیریت هزینه است.

ابر خصوصی

ابر خصوصی زیرساختی اختصاصی برای یک سازمان است. این زیرساخت می‌تواند در محل شرکت یا یک دیتاسنتر دیگر اجرا شود.

مزایای ابر خصوصی شامل موارد زیر است:

• کنترل بیشتر بر داده‌ها
• امکان سفارشی‌سازی
• تفکیک کامل منابع
• تطبیق بهتر با برخی الزامات امنیتی

در مقابل، هزینه راه‌اندازی و نگهداری ابر خصوصی معمولاً بیشتر است و سازمان به تیم متخصص نیاز خواهد داشت.

ابر ترکیبی

در مدل Hybrid Cloud، بخشی از سرویس‌ها در داخل سازمان و بخش دیگری در ابر عمومی یا خصوصی قرار می‌گیرند.

برای مثال، پایگاه داده حساس می‌تواند داخل سازمان باقی بماند، اما وب‌سرورها، سامانه پشتیبان‌گیری یا محیط توسعه به کلود منتقل شوند.

این مدل برای مهاجرت مرحله‌ای مناسب است، اما مدیریت شبکه، دسترسی‌ها، مانیتورینگ و انتقال اطلاعات در آن پیچیده‌تر خواهد بود.

معماری چندابری

در مدل Multi-Cloud، سازمان از خدمات چند ارائه‌دهنده ابری استفاده می‌کند.

این رویکرد می‌تواند برای کاهش وابستگی یا استفاده از امکانات تخصصی هر ارائه‌دهنده مفید باشد. بااین‌حال، استفاده از چند ابر بدون نیاز واقعی، پیچیدگی و هزینه مدیریت را افزایش می‌دهد.

استراتژی‌های مهاجرت به زیرساخت ابری

برای تمام نرم‌افزارها نمی‌توان از یک روش مهاجرت استفاده کرد. هر سرویس باید بر اساس ارزش تجاری، معماری، حساسیت، هزینه و وابستگی‌ها بررسی شود.

بازنشسته‌سازی سرویس

برخی نرم‌افزارها دیگر استفاده نمی‌شوند یا با سیستم جدیدی جایگزین شده‌اند. انتقال این سرویس‌ها به کلود فقط هزینه ایجاد می‌کند.

قبل از مهاجرت باید سامانه‌های قدیمی و بدون استفاده شناسایی و با فرایند مشخص خاموش شوند.

نگهداری در زیرساخت فعلی

ممکن است یک سرویس به دلیل محدودیت قانونی، وابستگی سخت‌افزاری یا قرارداد نرم‌افزاری فعلاً در محیط فعلی باقی بماند.

برای این سرویس‌ها باید زمان بازبینی مجدد تعیین شود.

انتقال مستقیم یا Rehost

در روش Rehost، نرم‌افزار با کمترین تغییر به یک ماشین مجازی در زیرساخت ابری منتقل می‌شود.

این روش که به Lift and Shift نیز شناخته می‌شود، سرعت بیشتری دارد؛ اما ممکن است تمام مزایای کلود را در اختیار سازمان قرار ندهد.

تغییر پلتفرم یا Replatform

در روش Replatform، معماری اصلی نرم‌افزار حفظ می‌شود، اما بخشی از زیرساخت آن تغییر می‌کند.

برای مثال:

• پایگاه داده به سرویس مدیریت‌شده منتقل می‌شود.
• برنامه در داخل کانتینر اجرا می‌شود.
• فایل‌ها به Object Storage منتقل می‌شوند.
• سیستم کش به سرویس مدیریت‌شده تبدیل می‌شود.

بازطراحی معماری

در روش Refactor یا Rearchitect، نرم‌افزار برای استفاده بهتر از امکانات ابری تغییر می‌کند.

ممکن است یک سامانه یکپارچه به چند سرویس مستقل تقسیم شود یا برای بخش‌های مختلف آن مقیاس‌پذیری جداگانه ایجاد شود.

این روش زمان و هزینه بیشتری دارد، اما برای سامانه‌های راهبردی و پرترافیک مناسب است.

جایگزینی نرم‌افزار

گاهی انتقال یک نرم‌افزار قدیمی منطقی نیست و استفاده از یک محصول SaaS می‌تواند هزینه و پیچیدگی کمتری داشته باشد.

سامانه‌های ایمیل، مدیریت پروژه، CRM و اتوماسیون از جمله سرویس‌هایی هستند که ممکن است با نرم‌افزارهای آماده جایگزین شوند.

بازسازی کامل

اگر نرم‌افزار فعلی پاسخ‌گوی نیازهای سازمان نیست، ممکن است بازسازی کامل آن بر پایه معماری جدید گزینه مناسب‌تری باشد.

این تصمیم باید با بررسی هزینه نگهداری نرم‌افزار قدیمی، ارزش تجاری و زمان توسعه گرفته شود.

مراحل اجرای مهاجرت به زیرساخت ابری

مرحله اول: تعیین اهداف تجاری

پروژه را با خرید سرور ابری آغاز نکنید. ابتدا مشخص کنید مهاجرت قرار است چه مشکلی را برطرف کند.

اهداف می‌توانند شامل موارد زیر باشند:

• افزایش دسترس‌پذیری
• کاهش زمان راه‌اندازی سرویس
• کاهش ریسک خرابی تجهیزات
• ایجاد بازیابی بحران
• افزایش ظرفیت در ساعات پرترافیک
• کاهش عملیات دستی
• بهبود امنیت
• آماده‌سازی زیرساخت توسعه محصولات جدید

اهداف باید قابل‌اندازه‌گیری باشند. برای مثال، به‌جای عبارت «افزایش پایداری»، می‌توان هدف را «کاهش زمان بازیابی سرویس از چهار ساعت به یک ساعت» تعریف کرد.

مرحله دوم: تهیه فهرست دارایی‌ها

تمام دارایی‌های زیرساختی باید شناسایی شوند:

• سرورها
• ماشین‌های مجازی
• پایگاه‌های داده
• دامنه‌ها
• گواهی‌های امنیتی
• فضای ذخیره‌سازی
• حساب‌های کاربری
• سرویس‌های زمان‌بندی‌شده
• APIها
• نرم‌افزارهای داخلی
• تجهیزات شبکه
• نسخه‌های پشتیبان

برای هر سرویس harus مالک فنی و مالک تجاری مشخص باشد.

مرحله سوم: شناسایی وابستگی‌ها

یکی از مهم‌ترین دلایل شکست مهاجرت، نادیده‌گرفتن وابستگی‌های پنهان است.

یک نرم‌افزار ممکن است به موارد زیر وابسته باشد:

• پایگاه داده روی سرور دیگر
• پوشه اشتراکی
• سرویس احراز هویت
• آدرس IP ثابت
• API قدیمی
• سرویس ایمیل
• صف پیام
• پرینتر شبکه
• سامانه حسابداری
• نرم‌افزار دیگر

وابستگی‌ها باید از طریق مستندات، بررسی تنظیمات، تحلیل ترافیک و گفت‌وگو با کاربران شناسایی شوند.

مرحله چهارم: اندازه‌گیری مصرف منابع

مشخصات اسمی سرورهای فعلی برای انتخاب منابع ابری کافی نیست.

مصرف واقعی موارد زیر را بررسی کنید:

• پردازنده
• حافظه
• فضای دیسک
• سرعت خواندن و نوشتن
• ترافیک شبکه
• تعداد کاربران
• تعداد درخواست‌ها
• ساعات اوج مصرف
• رشد ماهانه اطلاعات

انتخاب منابع بر اساس ظرفیت اسمی سرورهای قدیمی ممکن است هزینه زیرساخت ابری را افزایش دهد.

مرحله پنجم: محاسبه هزینه‌ها

در محاسبه هزینه فقط قیمت ماشین مجازی را در نظر نگیرید.

هزینه‌های زیر نیز باید بررسی شوند:

• فضای ذخیره‌سازی
• نسخه پشتیبان
• ترافیک خروجی
• IP
• Load Balancer
• فایروال
• مانیتورینگ
• ثبت لاگ
• مجوز نرم‌افزار
• پشتیبانی
• نیروی متخصص
• انتقال اطلاعات
• آموزش تیم
• بازطراحی نرم‌افزار
• ارتباط اختصاصی یا VPN

مرحله ششم: انتخاب ارائه‌دهنده

انتخاب ارائه‌دهنده نباید فقط بر اساس قیمت انجام شود.

معیارهای مهم عبارت‌اند از:

• محل دیتاسنتر
• کیفیت ارتباط
• سطح خدمات
• امکان دریافت پشتیبانی
• تعرفه ترافیک
• قابلیت پشتیبان‌گیری
• ابزارهای امنیتی
• تنوع سرویس‌ها
• امکان خروج اطلاعات
• قابلیت مانیتورینگ
• شرایط قرارداد
• زمان پاسخ‌گویی پشتیبانی

مرحله هفتم: طراحی بستر پایه

قبل از انتقال سرویس‌ها باید محیط پایه زیرساخت ابری طراحی شود. این محیط معمولاً Landing Zone نامیده می‌شود.

موارد زیر باید در بستر پایه مشخص شوند:

• ساختار حساب‌ها
• تفکیک محیط تولید و آزمایش
• شبکه‌های خصوصی
• Subnetها
• فایروال
• مسیرهای ارتباطی
• مدیریت هویت
• سطح دسترسی
• ثبت لاگ
• مانیتورینگ
• مدیریت رمزها
• بودجه‌بندی
• نام‌گذاری منابع
• برچسب‌گذاری
• پشتیبان‌گیری

انتقال سرویس‌ها به یک حساب ابری بدون ساختار، در آینده باعث پراکندگی منابع و افزایش ریسک امنیتی می‌شود.

مرحله هشتم: طراحی شبکه

شبکه یکی از اجزای اصلی مهاجرت ابری است.

قبل از انتقال باید موارد زیر بررسی شوند:

• پهنای باند
• کیفیت اینترنت
• تأخیر شبکه
• افزونگی ارتباط
• VPN
• DNS
• فایروال
• مسیریابی
• دسترسی شعب
• دسترسی کاربران دورکار
• ارتباط میان سرویس‌های قدیمی و جدید

اگر بخشی از زیرساخت داخل سازمان باقی می‌ماند، ارتباط میان محیط داخلی و کلود باید پایدار و امن باشد.

مرحله نهم: مهاجرت آزمایشی

پیش از انتقال سرویس‌های حیاتی، یک پروژه پایلوت اجرا کنید.

سرویس پایلوت باید دارای ریسک محدود و کاربرد واقعی باشد. انتقال یک سرویس کاملاً آزمایشی ممکن است مشکلات محیط تولید را نشان ندهد.

در مهاجرت پایلوت موارد زیر آزمایش می‌شوند:

• روش انتقال
• امنیت
• مانیتورینگ
• پشتیبان‌گیری
• استقرار نرم‌افزار
• عملکرد شبکه
• مدیریت دسترسی
• بازیابی
• کنترل هزینه
• مستندسازی

مرحله دهم: مهاجرت موج‌به‌موج

تمام سرویس‌ها را به‌صورت هم‌زمان منتقل نکنید.

سرویس‌ها باید بر اساس وابستگی، حساسیت، اولویت و پیچیدگی در چند موج قرار گیرند.

برای هر موج این اطلاعات را مشخص کنید:

• سرویس‌های مورد انتقال
• مسئول فنی
• مسئول تجاری
• زمان اجرا
• پیش‌نیازها
• زمان توقف احتمالی
• روش آزمایش
• برنامه بازگشت
• مسئول اطلاع‌رسانی
• معیار تأیید نهایی

امنیت در مهاجرت به زیرساخت ابری

امنیت باید از ابتدای پروژه در نظر گرفته شود. انتقال یک سرور ناامن به کلود باعث امن‌شدن آن نمی‌شود. تنظیمات سیستم‌عامل، نرم‌افزار، دسترسی و اطلاعات همچنان باید مدیریت شوند.

اصل دسترسی حداقلی

هر کاربر یا سرویس باید فقط به منابعی دسترسی داشته باشد که برای انجام وظیفه خود نیاز دارد.

اختصاص دسترسی مدیر به تمام کاربران، ریسک امنیتی بزرگی ایجاد می‌کند.

احراز هویت چندمرحله‌ای

برای حساب‌های مدیریتی و کاربران دارای دسترسی حساس، MFA را فعال کنید.

استفاده از رمز عبور به‌تنهایی برای حساب‌های مهم کافی نیست.

مدیریت رمزها

رمز پایگاه داده، توکن API و کلیدهای دسترسی را داخل کد، فایل عمومی یا پیام‌رسان نگهداری نکنید.

از ابزار مدیریت Secrets استفاده کنید و رمزها را به‌صورت دوره‌ای تغییر دهید.

رمزگذاری اطلاعات

داده‌ها باید هنگام انتقال و ذخیره‌سازی رمزگذاری شوند.

علاوه بر فعال‌کردن رمزگذاری، مدیریت کلیدها و سطح دسترسی به آن‌ها نیز اهمیت دارد.

ثبت لاگ‌ها

لاگ ورود کاربران، ایجاد منابع، حذف منابع، تغییر فایروال و تغییر سطح دسترسی باید ثبت شود.

لاگ‌ها باید در محلی نگهداری شوند که کاربران عادی امکان حذف یا تغییر آن‌ها را نداشته باشند.

تقسیم‌بندی شبکه

پایگاه داده، سرورهای برنامه، پنل مدیریت و سرویس‌های عمومی نباید بدون محدودیت در یک شبکه مشترک قرار گیرند.

استفاده از شبکه‌های خصوصی، فایروال و محدودکردن مسیرهای ارتباطی، سطح حمله را کاهش می‌دهد.

مدیریت به‌روزرسانی‌ها

سیستم‌عامل، کانتینرها، کتابخانه‌های نرم‌افزاری و تصاویر پایه باید به‌صورت منظم به‌روزرسانی شوند.

آسیب‌پذیری‌های شناخته‌شده می‌توانند مسیر نفوذ به زیرساخت سازمان باشند.

پاسخ به حادثه

پیش از وقوع حادثه مشخص کنید در شرایط زیر چه اقدامی انجام می‌شود:

• افشای رمز
• سرقت کلید دسترسی
• ورود غیرمجاز
• حذف اطلاعات
• آلوده‌شدن سرور
• افزایش ناگهانی هزینه
• قطع ارتباط شبکه

مسئول تصمیم‌گیری، مسیر اطلاع‌رسانی و روش بازیابی باید از قبل مشخص باشند.

مهاجرت اطلاعات و پایگاه داده

داده‌ها حساس‌ترین بخش پروژه مهاجرت هستند.

طبقه‌بندی اطلاعات

اطلاعات را بر اساس معیارهای زیر دسته‌بندی کنید:

• میزان حساسیت
• ارزش تجاری
• الزامات قانونی
• مدت نگهداری
• تعداد کاربران
• میزان تغییر
• حجم اطلاعات
• اهمیت برای ادامه فعالیت سازمان

تعیین RPO و RTO

RPO مشخص می‌کند سازمان حداکثر چه مقدار از اطلاعات جدید را می‌تواند از دست بدهد.

RTO نشان می‌دهد سرویس باید حداکثر در چه مدت زمانی بازیابی شود.

هرچه RPO و RTO کوتاه‌تر باشند، هزینه و پیچیدگی زیرساخت بیشتر خواهد شد.

انتقال اولیه و همگام‌سازی

در پروژه‌های دارای حجم زیاد، ابتدا اطلاعات اصلی منتقل می‌شوند و سپس تغییرات جدید تا زمان انتقال نهایی همگام‌سازی خواهند شد.

این روش می‌تواند مدت توقف سرویس را کاهش دهد.

بررسی صحت داده‌ها

بعد از انتقال، موارد زیر باید کنترل شوند:

• تعداد رکوردها
• ارتباط جداول
• مجموع‌های مالی
• مجوز فایل‌ها
• تاریخ‌ها
• کدگذاری متن
• حجم اطلاعات
• عملکرد Queryها
• صحت فایل‌ها
• اطلاعات کاربران

برنامه بازگشت

تا زمانی که صحت اطلاعات و عملکرد سامانه جدید تأیید نشده است، زیرساخت قدیمی را حذف نکنید.

برنامه بازگشت باید مشخص کند در صورت شکست مهاجرت، سرویس چگونه به محیط قبلی برمی‌گردد.

مدیریت هزینه‌های زیرساخت ابری

استفاده از فضای ابری بدون کنترل هزینه می‌تواند باعث افزایش صورتحساب شود.

بودجه‌بندی

برای هر پروژه، سرویس و واحد سازمانی بودجه مشخص کنید.

هشدار هزینه باید قبل از عبور از سقف بودجه ارسال شود.

برچسب‌گذاری منابع

تمام منابع را با اطلاعات زیر برچسب‌گذاری کنید:

• نام پروژه
• محیط
• مالک
• واحد سازمانی
• مرکز هزینه
• تاریخ ایجاد
• تاریخ بازبینی

خاموش‌کردن منابع غیرفعال

محیط‌های آزمایش و توسعه معمولاً نیازی به فعالیت شبانه‌روزی ندارند. می‌توان آن‌ها را در ساعات غیرکاری خاموش کرد.

حذف منابع بلااستفاده

موارد زیر را به‌صورت دوره‌ای بررسی کنید:

• دیسک‌های بدون اتصال
• Snapshotهای قدیمی
• IPهای بلااستفاده
• ماشین‌های خاموش
• نسخه‌های پشتیبان منقضی
• Load Balancerهای بدون ترافیک
• محیط‌های آزمایشی قدیمی

بررسی ترافیک خروجی

در بسیاری از سرویس‌های ابری، انتقال داده به داخل هزینه کمی دارد، اما خروج داده ممکن است هزینه‌بر باشد.

قبل از انتخاب معماری، حجم ترافیک میان سرویس‌ها و کاربران را تخمین بزنید.

اصلاح اندازه منابع

پس از مهاجرت، مصرف واقعی منابع را بررسی کنید.

اگر یک سرور ابری ظرفیت بسیار بیشتری از نیاز نرم‌افزار دارد، اندازه آن را کاهش دهید.

اشتباهات رایج در مهاجرت ابری

انتقال بدون شناخت وابستگی‌ها: نادیده‌گرفتن ارتباط میان نرم‌افزارها ممکن است باعث توقف سرویس‌های دیگر شود.

انتقال تمام سرورها به روش مستقیم: Lift and Shift برای تمام سرویس‌ها مناسب نیست و ممکن است مشکلات زیرساخت قبلی را به محیط جدید منتقل کند.

نداشتن برنامه بازگشت: هر مرحله مهاجرت باید دارای سناریوی Rollback باشد.

حذف سریع زیرساخت قبلی: پس از مهاجرت باید یک دوره تثبیت در نظر گرفته شود.

نادیده‌گرفتن هزینه سرویس‌های جانبی: هزینه ترافیک، مانیتورینگ، لاگ، پشتیبان‌گیری و امنیت ممکن است صورتحساب را افزایش دهد.

دسترسی بیش از حد کاربران: استفاده از حساب مشترک یا اختصاص نقش مدیر به تمام کاربران امنیت را کاهش می‌دهد.

آموزش‌ندادن تیم فنی: تیم باید مدیریت دسترسی، مانیتورینگ، استقرار، کنترل هزینه و پاسخ به حادثه را یاد بگیرد.

استفاده از ابزارهای پیچیده بدون نیاز: استفاده از Kubernetes یا معماری Microservices برای یک نرم‌افزار کوچک می‌تواند پیچیدگی غیرضروری ایجاد کند.

چک‌لیست مهاجرت به زیرساخت ابری

پیش از مهاجرت

• هدف پروژه مشخص شده است.
• مسئول اصلی پروژه تعیین شده است.
• فهرست دارایی‌ها تکمیل شده است.
• وابستگی سرویس‌ها مشخص شده است.
• مالک فنی و تجاری هر سامانه تعیین شده است.
• اطلاعات حساس طبقه‌بندی شده‌اند.
• مصرف واقعی منابع اندازه‌گیری شده است.
• روش مهاجرت هر سرویس مشخص شده است.
• هزینه ماهانه تخمین زده شده است.
• ارائه‌دهنده انتخاب شده است.
• بستر پایه طراحی شده است.
• شبکه و VPN آماده شده‌اند.
• MFA فعال شده است.
• سطح دسترسی کاربران مشخص شده است.
• نسخه پشتیبان تهیه شده است.
• بازیابی اطلاعات آزمایش شده است.
• RPO و RTO تعیین شده‌اند.
• برنامه بازگشت آماده است.
• کاربران از زمان مهاجرت مطلع شده‌اند.

هنگام مهاجرت

• تغییرات غیرضروری متوقف شده‌اند.
• نسخه پشتیبان نهایی تهیه شده است.
• تیم فنی در دسترس است.
• ظرفیت مقصد بررسی شده است.
• انتقال اطلاعات رمزگذاری شده است.
• لاگ مراحل ثبت می‌شود.
• همگام‌سازی نهایی انجام شده است.
• آزمایش فنی اجرا شده است.
• آزمایش امنیتی اجرا شده است.
• کاربران کلیدی سامانه را تأیید کرده‌اند.
• مسیر ترافیک تغییر کرده است.
• مانیتورینگ فعال است.
• معیار بازگشت بررسی شده است.

پس از مهاجرت

• سلامت سرویس‌ها بررسی شده است.
• صحت اطلاعات تأیید شده است.
• زمان پاسخ سامانه کنترل شده است.
• هشدارهای مانیتورینگ آزمایش شده‌اند.
• نسخه پشتیبان محیط جدید تهیه شده است.
• بازیابی محیط جدید آزمایش شده است.
• دسترسی‌های موقت حذف شده‌اند.
• رمزهای موقت تغییر کرده‌اند.
• هزینه واقعی بررسی شده است.
• منابع بیش‌ازحد بزرگ اصلاح شده‌اند.
• مستندات به‌روزرسانی شده‌اند.
• تیم پشتیبانی آموزش دیده است.
• مشکلات و درس‌آموخته‌ها ثبت شده‌اند.
• زمان خاموش‌کردن زیرساخت قبلی تعیین شده است.

یک نمونه عملی از مهاجرت ابری

فرض کنید یک شرکت خدماتی دارای نرم‌افزار CRM، سامانه حسابداری، پورتال مشتریان، فایل‌سرور و پایگاه داده است. تمام این سرویس‌ها روی چند سرور فیزیکی در دفتر مرکزی اجرا می‌شوند.

با افزایش تعداد کاربران، پورتال مشتریان در ساعات پرترافیک کند می‌شود. نسخه‌های پشتیبان نیز در همان ساختمان نگهداری می‌شوند و سازمان برنامه مناسبی برای بازیابی بحران ندارد.

در مرحله ارزیابی مشخص می‌شود سامانه حسابداری به قفل سخت‌افزاری وابسته است و انتقال آن در شرایط فعلی امکان‌پذیر نیست.

برنامه مهاجرت به شکل زیر طراحی می‌شود:

• پورتال مشتریان به محیط کانتینری منتقل می‌شود.
• پایگاه داده به سرویس مدیریت‌شده انتقال پیدا می‌کند.
• فایل‌ها در فضای ذخیره‌سازی ابری قرار می‌گیرند.
• CRM ابتدا با روش Rehost منتقل می‌شود.
• سامانه حسابداری موقتاً داخل سازمان باقی می‌ماند.
• ارتباط میان دفتر و کلود از طریق VPN برقرار می‌شود.
• پایگاه داده دسترسی مستقیم از اینترنت نخواهد داشت.
• ورود مدیران با MFA انجام می‌شود.
• لاگ فعالیت‌ها به‌صورت متمرکز نگهداری می‌شود.

ابتدا محیط آزمایشی پورتال منتقل می‌شود. پس از بررسی استقرار، مانیتورینگ، پشتیبان‌گیری و بازیابی، محیط تولید در یک بازه کم‌ترافیک انتقال پیدا می‌کند.

این مثال نشان می‌دهد مهاجرت موفق لزوماً به‌معنای انتقال هم‌زمان تمام سرویس‌ها نیست.

نقش DevOps در مهاجرت به زیرساخت ابری

DevOps باعث می‌شود ایجاد و مدیریت زیرساخت قابل تکرار و کنترل‌شده باشد. به‌جای ایجاد دستی منابع، می‌توان زیرساخت را با کد تعریف کرد.

کاربردهای DevOps در مهاجرت شامل موارد زیر هستند:

• ایجاد زیرساخت با Terraform
• پیکربندی خودکار با Ansible
• کانتینرسازی با Docker
• راه‌اندازی CI/CD
• مدیریت نسخه نرم‌افزار
• استقرار خودکار
• بازگشت نسخه ناموفق
• مانیتورینگ سرویس‌ها
• مدیریت متمرکز لاگ‌ها
• بررسی امنیت کد
• مدیریت تنظیمات و Secrets

هدف DevOps استفاده از ابزارهای پیچیده نیست. هدف اصلی، کاهش خطای انسانی و ایجاد فرایندهای پایدار است.

شاخص‌های موفقیت مهاجرت ابری

برای ارزیابی نتیجه پروژه، شاخص‌های قبل و بعد از مهاجرت را مقایسه کنید. شاخص‌های مهم عبارت‌اند از:

• میزان دسترس‌پذیری
• زمان پاسخ نرم‌افزار
• تعداد خطاها
• زمان بازیابی سرویس
• میزان اطلاعات قابل‌بازیابی
• هزینه ماهانه
• زمان آماده‌سازی محیط جدید
• تعداد عملیات دستی
• تعداد رخدادهای امنیتی
• زمان انتشار نسخه جدید
• رضایت کاربران
• تعداد قطعی‌ها

پرسش‌های متداول (FAQ)

مهاجرت به زیرساخت ابری چقدر زمان می‌برد؟
زمان مهاجرت به تعداد سرویس‌ها، حجم اطلاعات، وابستگی‌ها و میزان تغییر نرم‌افزار بستگی دارد. انتقال یک سرویس مستقل ممکن است چند روز یا چند هفته طول بکشد، اما مهاجرت کامل یک سازمان ممکن است چند ماه زمان نیاز داشته باشد.

آیا زیرساخت ابری همیشه ارزان‌تر است؟
خیر. زیرساخت ابری انعطاف و سرعت بیشتری فراهم می‌کند، اما بدون کنترل منابع و هزینه‌ها ممکن است گران‌تر از زیرساخت فعلی باشد.

آیا باید نرم‌افزار را بازنویسی کنیم؟
خیر. برخی نرم‌افزارها بدون تغییر منتقل می‌شوند، بعضی به اصلاحات محدود نیاز دارند و تنها برخی سامانه‌ها باید بازطراحی شوند.

چگونه بدون قطعی مهاجرت کنیم؟
با استفاده از همگام‌سازی اطلاعات، اجرای هم‌زمان محیط قدیم و جدید، انتقال تدریجی ترافیک و طراحی برنامه Cutover می‌توان زمان قطعی را کاهش داد.

مهم‌ترین ریسک مهاجرت ابری چیست؟
شناخت ناقص وابستگی‌ها، از دست‌رفتن اطلاعات، تنظیم اشتباه دسترسی‌ها، افزایش هزینه و نداشتن برنامه بازگشت از مهم‌ترین ریسک‌ها هستند.

آیا اطلاعات حساس را می‌توان به کلود منتقل کرد؟
بله، اما باید محل نگهداری داده، رمزگذاری، مدیریت کلید، قوانین مرتبط و سطح دسترسی به‌دقت بررسی شوند.

آیا Kubernetes برای هر پروژه لازم است؟
خیر. Kubernetes برای پروژه‌هایی با تعداد زیاد سرویس کانتینری و نیاز به مقیاس‌پذیری خاص مناسب است. استفاده از آن برای پروژه‌های کوچک ممکن است پیچیدگی ایجاد کند.

بهترین سرویس برای شروع مهاجرت چیست؟
بهتر است یک سرویس واقعی با ریسک محدود، وابستگی مشخص و اهمیت متوسط انتخاب شود.

بعد از مهاجرت چه کاری باید انجام شود؟
کنترل هزینه، مانیتورینگ، آزمایش بازیابی، حذف دسترسی‌های موقت، بررسی امنیت و بهینه‌سازی منابع ضروری هستند.

چگونه ارائه‌دهنده مناسب را انتخاب کنیم؟
کیفیت دیتاسنتر، موقعیت جغرافیایی، پشتیبانی، SLA، تعرفه ترافیک، ابزارهای امنیتی، امکان پشتیبان‌گیری و شرایط خروج اطلاعات را بررسی کنید.

سخن آخر شارن

مهاجرت به زیرساخت ابری می‌تواند هزینه نگهداری تجهیزات، محدودیت توسعه منابع و ریسک خرابی سرورها را کاهش دهد. با این حال، موفقیت این پروژه به ارزیابی دقیق، انتخاب معماری مناسب، اجرای مرحله‌ای، پشتیبان‌گیری مطمئن، امنیت و مانیتورینگ مستمر وابسته است.

بهترین روش این است که مهاجرت را با بررسی کامل زیرساخت فعلی آغاز کنید، سرویس‌ها را براساس اهمیت دسته‌بندی کنید و پیش از انتقال سامانه‌های حیاتی، یک مهاجرت آزمایشی انجام دهید. همچنین برای هر مرحله باید برنامه بازگشت مشخصی وجود داشته باشد تا در صورت بروز مشکل، فعالیت سازمان متوقف نشود.

اگر برای بررسی سرورها، طراحی معماری، انتقال اطلاعات، راه‌اندازی سیستم پشتیبان‌گیری یا پیاده‌سازی زیرساخت ابری سازمان خود به مشاوره تخصصی نیاز دارید، کارشناسان شارن می‌توانند شرایط مجموعه شما را بررسی کنند.

شارن با ارائه خدمات شبکه، سرور، مجازی‌سازی، امنیت، مانیتورینگ و پشتیبانی زیرساخت، به کسب‌وکارها کمک می‌کند مسیر مهاجرت به فضای ابری را با برنامه‌ریزی دقیق و ریسک کمتر طی کنند. برای دریافت مشاوره و آشنایی با خدمات زیرساخت و شبکه شارن، به وب‌سایت sharen.co مراجعه کنید.