ویونیکس / زیرساخت و ابر
طراحی و نوسازی زیرساخت سازمانی
طراحی و نوسازی سرور، شبکه و محیط ابری با در نظر گرفتن مهاجرت سرویس‌ها، بازیابی اطلاعات و نیازهای تیم نگه‌داری.
شناخت وضعیت فعلی
اول وضعیت زیرساخت موجود را روشن کنید
پیش از پیشنهاد پلتفرم یا افزایش ظرفیت، سامانه‌ها، وابستگی‌ها و محدودیت‌های فعلی را بررسی می‌کنیم. باید روشن شود کدام بخش قابل استفاده است، چه چیزی نیاز به اصلاح دارد و دلیل هر تغییر چیست.
فهرست سامانه‌ها و وابستگی‌ها
مسئول هر سامانه، نیاز پردازشی و ذخیره‌سازی، مسیرهای شبکه، جابه‌جایی داده، دسترسی‌ها و روش بکاپ مشخص می‌شوند. وابستگی به سرویس‌ها یا تجهیزات قدیمی نیز در برنامهٔ تغییر در نظر گرفته می‌شود.
محدودیت‌های مؤثر بر طراحی
بازهٔ مجاز قطعی، محل استقرار، کیفیت ارتباطات، سیاست‌های داخلی، مجوز نرم‌افزارها و توان تیم برای نگه‌داری بررسی می‌شوند. صرفاً قابل اجرا بودن یک معماری، دلیل کافی برای مناسب‌بودن آن نیست.
طراحی پیش از مهاجرت
معماری باید با نیاز سرویس و روش نگه‌داری سازگار باشد
زیرساخت اختصاصی، سرویس ابری و معماری ترکیبی کاربردهای متفاوتی دارند. محل استقرار، ظرفیت، ارتباطات، جداسازی و بازیابی را در کنار هم بررسی می‌کنیم؛ انتقال همهٔ سرویس‌ها به یک محیط، هدف ثابت تمام پروژه‌ها نیست.
پردازش و بستر اجرا
طراحی سرور و مجازی‌سازی، انتخاب محل اجرای سامانه، تخصیص منابع و تعیین تنظیمات پایهٔ قابل نگه‌داری برای سیستم‌عامل و پلتفرم.
سازگاری سامانه، ظرفیت مورد نیاز و شرایط نگه‌داری در انتخاب‌ها مؤثرند.
شبکه و دسترسی
آدرس‌دهی، مسیریابی، تفکیک شبکه، ارتباط سرویس‌ها و مسیرهای مدیریتی متناسب با محدوده‌های دسترسی توافق‌شده.
ارتباط برنامه‌ها، سرویس‌های وابسته و دسترسی تیم نگه‌داری بررسی می‌شود.
ذخیره‌سازی و بازیابی
طراحی ذخیره‌سازی، محدودهٔ بکاپ، مدت نگه‌داری و روش بازیابی بر اساس نیاز داده و سرویس‌های منتخب.
هدف بازیابی و آزمایش بازگردانی اطلاعات باید مشخص شود؛ وجود بکاپ به‌تنهایی کافی نیست.
تغییرات زیرساختی قابل تکرار
هرجا به یکسان‌بودن تنظیمات و بازبینی تغییرات کمک کند، از خودکارسازی و زیرساخت به‌صورت کد استفاده می‌کنیم. تنظیمات در منبع کنترل‌شده نگه‌داری می‌شوند، اطلاعات محرمانه جدا می‌مانند و تغییرات پیش از اجرا بررسی می‌شوند. ابزار بر اساس محیط انتخاب می‌شود.
نیازهای بهره‌برداری از ابتدا در طراحی باشد
شاخص‌های سلامت، لاگ‌ها، مسئول هشدارها، به‌روزرسانی و بررسی بکاپ هم‌زمان با معماری مشخص می‌شوند. تیم مسئول باید بتواند محیط را نگه‌داری کند، بدون این‌که کار به دانسته‌های ثبت‌نشدهٔ یک فرد وابسته باشد.
مهاجرت با کنترل اثر تغییر
مهاجرت را به تغییرات قابل کنترل تقسیم کنید
مهاجرت را به یک جابه‌جایی بزرگ و بدون امکان بازگشت محدود نکنید. برای یک سامانه یا محدودهٔ مشخص، بررسی‌های لازم را آزمایش می‌کنیم و پیش از انتقال ترافیک یا دادهٔ عملیاتی، شرایط جابه‌جایی نهایی و بازگشت را تعیین می‌کنیم.
برای نمونه، انتقال یک اپلیکیشن ممکن است به آماده‌بودن هم‌زمان ظرفیت، مسیرهای شبکه، همگام‌سازی داده، دسترسی‌ها و مانیتورینگ وابسته باشد. بالا آمدن سرور به‌تنهایی نشان نمی‌دهد که کاربران می‌توانند از برنامه استفاده کنند.
آماده‌سازی و بررسی مقصد
ظرفیت، مسیرهای ارتباطی، سرویس‌های لازم و تست‌های کاربردی در محیط امن بررسی می‌شوند. محدودیت‌های آزمایش نیز ثبت می‌شوند.
تعیین شرط انتقال و بازگشت
بازهٔ تغییر، مسئول اجرا، مسیر اطلاع‌رسانی، کنترل یکسان‌بودن داده و شرایط بازگشت مشخص می‌شوند. در انتقال داده باید از ثبت هم‌زمان و ناسازگار اطلاعات جلوگیری شود.
بررسی پایداری پیش از کنارگذاشتن مسیر قبلی
پس از انتقال، عملکرد سرویس برای کاربر، وابستگی‌ها، مانیتورینگ و بکاپ بررسی می‌شوند. حذف منابع قبلی فقط پس از تحقق معیار پذیرش و شرایط نگه‌داری توافق‌شده انجام می‌شود.
تثبیت و تحویل زیرساخت
زیرساخت همراه با مستندات و مسئولیت روشن تحویل شود
پس از تغییر، سلامت سرویس بررسی و موارد باقی‌مانده رفع یا ثبت می‌شوند. در تحویل، معماری نهایی به راهنمای اجرایی، ارجاع تنظیمات و مسئولیت افراد مرتبط می‌شود. اگر پشتیبانی مستمر لازم باشد، محدوده و پوشش آن جداگانه توافق می‌شود.
نتیجهٔ بررسی‌ها و منابع اجرایی
مستندات توافق‌شده می‌توانند شامل معماری و وابستگی‌ها، ارجاع تنظیمات، نتیجهٔ تست‌ها، روش بازیابی، مسئولیت دسترسی و اقدام‌های باز باشند. خروجی‌ها برای همان پروژه تعیین می‌شوند و بستهٔ ثابت برای همهٔ سازمان‌ها نیستند.
برای شروع، شرح کلی زیرساخت را آماده کنید
سامانه‌های درگیر، محل اجرای آن‌ها، مشکل یا تغییر مورد نظر و محدودیت‌های عملیاتی را توضیح دهید.