شناخت نیاز
کاربران، داده‌ها، سرویسها و محدودیت‌های ارتباط را ثبت کنید.
سرویس ابری سازمانی چیست؟
سرویس ابری سازمانی میتواند بستری برای اجرای نرمافزار، نگهداری اطلاعات یا همکاری کارکنان باشد. در تعریف NIST از رایانش ابری، منابع قابل پیکربندی از طریق شبکه و متناسب با تقاضا در دسترس قرار می‌گیرند. با این حال، هر سرور متصل به اینترنت الزاماً یک راهکار ابری کامل نیست.
این راهنما برای تصمیم‌گیری دربارهٔ راهاندازی خدمات ابری در سازمان است. آموزش نصب نسخهٔ مشخص یک محصول یا مقایسهٔ قیمت روز ارائه‌دهندگان نیست. هدف، رسیدن به خدمتی است که کاربر بتواند از آن استفاده کند و مسئول سازمان بداند چه چیزی را چگونه مدیریت، حفاظت و بازیابی کند.
انتخاب معماری
مدل خدمت، محل اجرا، دسترسی و هزینه را مشخص کنید.
پایلوت و مهاجرت
ابتدا یک بخش کم‌ریسک را با معیار پذیرش روشن آزمون کنید.
تحویل و نگهداری
عملکرد، بازیابی، مسئولیت‌ها و هزینهٔ دورهای را بررسی کنید.
چه زمانی راهاندازی سرویسهای ابری سازمانی مفید است؟
وقتی کارکنان از چند محل به اطلاعات دسترسی دارند، توسعهٔ یک سرویس با محدودیت منابع روبه‌رو است یا مدیریت نسخه‌های پراکندهٔ فایل دشوار شده، بررسی گزینهٔ ابری منطقی است. انتقال به ابر، پاسخ خودکار همهٔ این مشکلات نیست؛ ابتدا علت مسئله و ابزارهای موجود را مشخص کنید.
- همکاری روی فایل‌ها: تعیین مالک محتوا، مجوز پوشه‌ها و سیاست اشتراک، پیش از انتخاب ابزار ذخیرهسازی.
- اجرای نرمافزار سازمانی: بررسی سازگاری برنامه، پایگاه داده و اتصال کاربران با بستر منتخب.
- توسعهٔ محیط آزمایشی: تخصیص منابع متناسب با کار و تعیین زمان حذف یا نگهداری محیط.
- دسترسی چند شعبه: طراحی هویت و ارتباط همراه با بررسی کیفیت مسیر هر محل.
هدف پروژه را قابل سنجش تعریف کنید: کدام کاربر باید به کدام خدمت دسترسی داشته باشد؟ در چه شرایطی؟ چه مقدار توقف یا از دست رفتن داده قابل قبول است؟ «ابری شدن» بهتنهایی معیار موفقیت نیست.
تفاوت IaaS، PaaS و SaaS در انتخاب خدمت
مدل خدمت، میزان کاری را که تیم سازمان باید انجام دهد تغییر می‌دهد. طبق راهنمای مسئولیت مشترک Microsoft، در IaaS مدیریت ماشین، سیستم‌عامل و برنامه با مشتری است؛ در PaaS می‌توان برنامه را بدون مدیریت ماشین و سیستم‌عامل زیرین مستقر کرد؛ در SaaS از نرمافزار آماده استفاده میشود.
برای انتخاب، فقط فهرست امکانات را مقایسه نکنید. امکان انتقال داده، اتصال به ابزارهای فعلی، دسترسی مدیر، روش بکاپ و توان نگهداری تیم را هم بررسی کنید. ممکن است یک نرمافزار آماده نیاز همکاری را بهتر پاسخ دهد و برای برنامهٔ اختصاصی، بستر متفاوتی لازم باشد.
ابر عمومی، ابر خصوصی یا راهکار ترکیبی؟
در مدل عمومی، زیرساخت برای استفادهٔ عمومی عرضه میشود؛ ابر خصوصی برای استفادهٔ اختصاصی یک سازمان است و لزوماً داخل ساختمان آن قرار ندارد. ابر ترکیبی، بسترهای ابری متمایز را با سازوکار ارتباط و جابه‌جایی داده یا برنامه کنار هم قرار می‌دهد. این تمایزها در تعریف مدل‌های استقرار NIST آمده‌اند. داشتن چند ماشین مجازی در دفتر، بهتنهایی به معنی ساخت ابر خصوصی نیست.
برای تصمیم عملی، محل اطلاعات و نسخه‌های پشتیبان، کیفیت اتصال، قابلیت‌های لازم و مسئول نگهداری را مشخص کنید. اگر برنامه‌ای به سخت‌افزار یا شبکهٔ داخلی وابسته است، انتقال کامل آن ممکن است مناسب نباشد. ماندن بخشی از سرویسها در سازمان هم باید با نقشهٔ ارتباط و هویت روشن همراه شود؛ ترکیبی بودن نباید به پراکندگی بی‌مدیریت تبدیل شود.
پیش‌نیازهای راهاندازی خدمات ابری
- فهرست کاربران، شعب، نرم‌افزارها و سرویسهای فعلی و وابستگی آن‌ها
- حجم داده، نرخ تغییر، حساسیت و مدت نگهداری موردنیاز
- کیفیت اینترنت، تأخیر مسیر و روش دسترسی کاربران از محل‌های واقعی
- مالک حساب سازمانی، دامنه، مجوزها و مسئول تمدید یا پرداخت اشتراک
- شرایط استفاده، دسترسی و پشتیبانی ارائهدهنده در زمان انتخاب
- هدف بازیابی، زمان توقف قابل‌تحمل و مسیر خروج یا انتقال داده
سازگاری را از عملکرد واقعی نرمافزار بسنجید. وابستگی به DNS داخلی، سرویس هویت، فایل محلی یا قفل سخت‌افزاری ممکن است روش اجرا را تغییر دهد. برای برنامهٔ حیاتی، پیش از خرید نهایی، قابلیت‌های ضروری را با سازنده و بستر منتخب تطبیق دهید.
اینترنت و تجربهٔ کاربر را جدا از ظرفیت سرور بسنجید
منابع بیشتر روی سرور، مشکل مسیر ارتباط یا رابط کند برنامه را الزاماً حل نمی‌کنند. بازشدن فایل، ورود کاربر و عملیات رایج را از شعب و دستگاه‌های مورد استفاده آزمون کنید. اگر قطع ارتباط برای کار مجموعه مهم است، مسیر جایگزین یا قابلیت آفلاین باید در طراحی بررسی شود؛ این قابلیت در همهٔ خدمات یکسان نیست.
امنیت ابر و مسئولیت مشترک
ابری بودن، مسئولیت سازمان در حفاظت از داده و هویت کاربران را حذف نمیکند. در مدل مسئولیت مشترک، حدود مسئولیت به نوع خدمت بستگی دارد. مشخص کنید چه کسی حساب‌ها، تنظیمات برنامه و کنترل‌های تحت اختیار سازمان را مدیریت می‌کند؛ این راهنما جای شرایط قرارداد ارائهدهنده نیست.
- حساب‌های شخصی و مدیریتی تفکیک شوند و مجوزها متناسب با نقش باشند.
- احراز هویت چندمرحله‌ای، در بسترهای پشتیبانی‌شده، همراه با روش بازیابی حساب بررسی شود.
- دسترسی همکار خارج‌شده از سازمان و لینک‌های اشتراک قدیمی قابل لغو و پیگیری باشند.
- کلیدها و رمزها در مستندات عمومی، فایل مقاله یا پیام اولیهٔ پشتیبانی قرار نگیرند.
- رخدادهای مهم و تغییر تنظیمات، در محدودهٔ قابل پشتیبانی بستر، قابل بررسی باشند.
محل ذخیرهسازی و نگهداری اطلاعات را بر اساس سیاست سازمان انتخاب کنید. برای دادهٔ حساس، مسئول مربوط باید شرایط دسترسی، محل نسخه‌ها و روش حذف یا خروج داده را تأیید کند. انتخاب نام یک محصول یا فعال‌کردن یک گزینه، جای بررسی این موارد را نمی‌گیرد.
مراحل مهاجرت به سرویس ابری سازمانی
قبل از انتقال، رابطهٔ برنامهها با پایگاه داده، فایل‌ها و سرویس هویت را ثبت کنید. راهنمای برنامه‌ریزی مهاجرت Microsoft نیز بر شناخت وابستگی‌ها و آغاز با پایلوت کم‌ریسک تأکید دارد. روال زیر، چارچوب پیشنهادی تصمیم‌گیری است و دستور نصب یک محصول مشخص نیست.
- ارزیابی وضعیت: ثبت سرویس، مالک داده، کاربران، منابع و محدودیت‌های نرمافزار.
- طراحی مقصد: انتخاب مدل خدمت، ارتباط، هویت، بکاپ، هزینه و اقلام تحویل.
- اجرای پایلوت: آزمون یک بخش کم‌ریسک با دادهٔ غیرحساس و کاربران منتخب.
- آماده‌سازی انتقال: نسخهٔ پشتیبان، زمانبندی، اطلاع‌رسانی و روش هماهنگ‌کردن تغییرات داده.
- انتقال و تغییر مسیر: مهاجرت مرحله‌ای و آزمون ورود، مجوزها و کارکرد نرمافزار.
- پذیرش و نگهداری: ثبت نتیجه، تحویل مسئولیت‌ها و بررسی عملکرد و هزینه پس از راهاندازی.
مسیر بازگشت باید مشخص کند در صورت شکست انتقال، کدام نسخهٔ داده معتبر است. روشن‌کردن هم‌زمان دو نسخهٔ مستقل برنامه و نوشتن کاربران در هر دو، میتواند اختلاف داده ایجاد کند. بستن پروژه فقط با روشن‌شدن سرویس، جای آزمون از سمت کاربر و تأیید صحت اطلاعات را نمی‌گیرد.
بکاپ، افزونگی و امکان خروج از ابر
در انتخاب خدمت، تفاوت نسخهٔ پشتیبان تاریخی، بازیابی فایل حذف‌شده، افزونگی بستر و بازیابی کامل برنامه را روشن کنید. این امکانات برای همهٔ محصولات و طرح‌های اشتراک یکسان نیستند. مشخص کنید چه چیزی، کجا، با چه مدت نگهداری و توسط چه کسی پشتیبان‌گیری میشود.
آزمون بازگردانی باید فقط دریافت فایل بکاپ نباشد: صحت داده، مجوز دسترسی و اجرای دوبارهٔ خدمت هم در دامنهٔ آزمون قرار گیرند. اهداف زمان بازیابی و میزان دادهٔ قابل‌قبول برای از دست رفتن، با نیاز کسب‌وکار هماهنگ شوند. جزئیات این موضوع را در بخش پشتیبان‌گیری و بازیابی اطلاعات دنبال کنید.
پیش از وابسته شدن به یک بستر، امکان خروجی گرفتن از اطلاعات، قالب داده، زمان انتقال و مسئول دریافت نسخهٔ نهایی را بررسی کنید. پایان اشتراک نباید اولین زمانی باشد که سازمان متوجه محدودیت انتقال اطلاعات میشود.
هزینه راهاندازی سرویسهای ابری سازمانی
برآورد را به دو بخش تقسیم کنید: هزینهٔ بررسی، پیکربندی و مهاجرت اولیه؛ و هزینهٔ دورهای سرویس و نگهداری. تعداد کاربران، ظرفیت محاسبات و ذخیرهسازی، انتقال داده، مجوزها، بکاپ، پشتیبانی و قابلیت‌های اضافی ممکن است بر هزینه اثر بگذارند. اقلام مشمول صورتحساب را از تعرفه و قرارداد همان ارائهدهنده بررسی کنید.
یک محیط آزمایشی فراموش‌شده یا داده‌ای که بی‌برنامه رشد می‌کند میتواند بر مصرف اثر بگذارد. موجودی منابع، مالک هر سرویس و زمان بازبینی هزینه را مشخص کنید. برای منابع با مصرف متغیر، تعریف هشدار بودجه مفید است، اما آن را سقف قطعی هزینه فرض نکنید؛ برای مثال، در مستندات بودجهٔ Azure، هشدار بودجه بهتنهایی مصرف را متوقف نمیکند.
هزینهٔ نگهداری سرور داخلی را نیز کامل ببینید: تجهیزات، برق، مجوز، نیروی مدیریت و بازیابی. نتیجهٔ مقایسه برای همهٔ سازمان‌ها یکسان نیست؛ قیمت روز یا درصد صرفه‌جویی بدون شناخت مصرف، مبنای قابل اتکایی نیست.
چک‌لیست تحویل سرویس ابری سازمانی
- کارکرد سرویس و ورود کاربران از محل‌ها و دستگاه‌های توافق‌شده
- تطابق مجوز کاربران عادی و مدیر با نقش‌ها و آزمون لغو دسترسی
- ثبت مالک حساب، دامنه، اشتراک و مسئول تمدید، با تحویل امن دسترسی
- آزمون بکاپ و بازگردانی نمونهٔ مورد توافق همراه با نتیجه و محدودیت‌ها
- ثبت منابع، قواعد هزینه و مسئول بررسی هشدار و صورتحساب
- راهنمای نگهداری، روش خروج داده و مرز مسئولیت سازمان و ارائهدهنده
بررسی و اجرای خدمات ابری در ویوان نت
برای شروع، تعداد تقریبی کاربران، سرویسهای فعلی، حجم داده و هدف اصلی را در بخش پشتیبانی ویوان نت ثبت کنید. رمز، کلید API و فایل حاوی اطلاعات محرمانه را در درخواست عمومی قرار ندهید. پس از نیازسنجی، محدودهٔ بررسی، اجرا و نگهداری قابل تعریف است.
سناریوی آموزشی: همکاری فایل بین دو دفتر
فرض کنید کارکنان دو دفتر، فایل‌های پروژه را با نسخه‌های پراکنده جابه‌جا می‌کنند. مشکل اصلی، نامشخص بودن نسخهٔ معتبر و مجوز دسترسی است. قبل از انتخاب بستر ابری، مالک هر پوشه، کاربران و روش اشتراک با افراد بیرون مجموعه تعریف می‌شوند؛ صرف انتقال فایل‌ها همان مشکل را در محل جدید تکرار می‌کند.
پایلوت با یک پوشهٔ غیرحساس آغاز میشود. ورود کاربر، اشتراک مجاز، لغو دسترسی، کار از هر دو دفتر و بازگردانی یک فایل آزموده می‌شوند. اگر برنامهٔ خاصی به فایل محلی وابسته است، آن وابستگی جدا بررسی میشود و ممکن است نیاز به روش دیگری داشته باشد.
پس از پذیرش پایلوت، انتقال مرحله‌ای با تعیین نسخهٔ معتبر داده انجام میشود. هزینهٔ کاربران و ذخیرهسازی و روش دریافت خروجی نیز ثبت می‌شوند. این مثال پروژهٔ واقعی ویوان نت نیست و نتیجهٔ عددی یا صرفه‌جویی تضمین‌شده ارائه نمیکند.
این راهنما از مجموعهٔ مجازی‌سازی و پردازش ابری ویوان نت است. برای شناخت مجموعه، معرفی ویوان نت را ببینید.
پرسش‌های متداول دربارهٔ سرویسهای ابری سازمانی
سرویس ابری سازمانی چه تفاوتی با سرور مجازی دارد؟
سرور مجازی بخشی از یک بستر محاسباتی است، اما سرویس ابری میتواند نرمافزار آماده، بستر توسعه یا زیرساخت قابل تخصیص باشد. تهیهٔ یک VPS بهتنهایی مدیریت هویت، سیاست داده، بکاپ و تحویل یک سرویس سازمانی کامل را فراهم نمیکند.
ابر عمومی، خصوصی یا ترکیبی؛ کدام مناسبتر است؟
انتخاب به حساسیت و محل داده، سازگاری نرمافزار، کیفیت ارتباط، بودجه و توان نگهداری بستگی دارد. ممکن است بخشی از سرویسها در سازمان بمانند و بخش دیگر روی ابر اجرا شوند؛ انتخاب باید پس از نیازسنجی انجام شود.
آیا انتقال به ابر نیاز به بکاپ را حذف می‌کند؟
خیر. افزونگی و امکانات بازیابی هر سرویس باید بررسی شوند و با نیاز نگهداری نسخه و بازگردانی سازمان تطبیق داده شوند. روش بکاپ، مسئول اجرا و آزمون بازیابی باید روشن باشند؛ عنوان ابری بهتنهایی کافی نیست.
آیا مهاجرت به ابر بدون قطعی انجام میشود؟
به حجم داده، روش انتقال و وابستگی برنامهها بستگی دارد. پایلوت، زمانبندی تغییر مسیر، هماهنگی آخرین داده و مسیر بازگشت باید پیش از مهاجرت تعریف شوند؛ نبود قطعی برای همهٔ پروژهها قابل تضمین نیست.
در صورت قطع اینترنت، سرویس ابری در دسترس می‌ماند؟
سرویس بیرونی به مسیر ارتباط وابسته است. امکان کار آفلاین یا مسیر جایگزین به قابلیت محصول و طراحی بستگی دارد و باید آزموده شود؛ داشتن سرویس در ابر به معنی دسترسی دائمی کاربران نیست.
هزینه راهاندازی سرویسهای ابری سازمانی چگونه محاسبه میشود؟
تعداد کاربران، نوع سرویس، منابع و ذخیرهسازی، مصرف انتقال داده، مجوز یا اشتراک، مهاجرت، بکاپ و نگهداری اثر دارند. هزینهٔ اجرای اولیه و هزینهٔ دورهای باید جدا برآورد و بر اساس تعرفه و شرایط واقعی ارائهدهنده بررسی شوند.
منابع فنی و مطالعهٔ بیشتر
برای جزئیات بستر منتخب، مستندات همان محصول و شرایط روز ارائهدهنده را بررسی کنید. ارجاع به Microsoft به معنی محدود بودن این راهنما به Azure نیست.