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

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

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

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

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

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

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

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

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

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

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

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

مهاجرت ابری یا 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ها
• نرم‌افزارهای داخلی
• تجهیزات شبکه
• نسخه‌های پشتیبان

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

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

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

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

• پایگاه داده روی سرور دیگر
• پوشه اشتراکی
• سرویس احراز هویت
• آدرس 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 مراجعه کنید.