تاثیر معماری ابری بر پایداری داده‌ های فروش در سازمان‌ های بزرگ

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

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

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

پایداری داده های فروش را چگونه اندازه بگیریم؟

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

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

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

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

معماری ابری چه چیزی را در مسیر خرابی تغییر می دهد؟

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

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

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

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

تکثیر داده با نسخه پشتیبان چه تفاوتی دارد؟

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

تکثیر داده برای حفظ نسخه های مرتبط و پشتیبانی از تداوم سرویس کاربرد دارد؛ نسخه پشتیبان امکان برگشت به وضعیت قبلی را فراهم می کند. طراحی مناسب باید هر دو نیاز را در نظر بگیرد و مشخص کند خطای انسانی، خرابی زیرساخت و حذف عمدی اطلاعات چگونه مدیریت می شوند.

نوع تکثیر هم اهمیت دارد. در PostgreSQL، تکثیر جریانی به صورت پیش فرض ناهم زمان است و هنگام خرابی سرور اصلی ممکن است بخشی از تراکنش های تأییدشده هنوز به سرور جایگزین نرسیده باشند. میزان داده در معرض ازدست رفتن به تأخیر تکثیر هنگام جابه جایی وابسته است.

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

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

هزینه نگهداری؛ فراتر از خرید سرور و اجاره ماهانه

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

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

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

جدول زیر موضوعات اصلی مقایسه را نشان می دهد؛ نتیجه مالی هر ردیف به شرایط سازمان و قرارداد سرویس وابسته است.

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

هزینه های پنهان در گزارش گیری و محیط آزمایشی

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

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

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

شاخص «هزینه زیرساخت به ازای هر هزار سفارش» می تواند برای مقایسه دوره ها مفید باشد. این شاخص را کنار زمان پاسخ و نرخ خطا بررسی کنید. کاهش صورت حساب از طریق حذف ظرفیت لازم برای ساعات شلوغ، ممکن است به ازدست رفتن سفارش یا افزایش زمان انتظار منجر شود.

امنیت لایه های داده و تقسیم مسئولیت ها

انتقال اطلاعات به ابر، مسئولیت امنیتی سازمان را تمام نمی کند. محدوده مسئولیت تغییر می کند. در مدل مسئولیت مشترک، ارائه دهنده بخشی از زیرساخت را اداره می کند و مشتری همچنان درباره داده، مجوزها و تنظیمات محیط خود مسئولیت دارد؛ جزئیات این تقسیم به نوع سرویس وابسته است.

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

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

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

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

رمزگذاری؛ کلید بازیابی را هم نگه دارید

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

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

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

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

اینترنت و اتصال شعب؛ بخش مهمی از پایداری فروش

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

داشتن مسیر ارتباطی جایگزین می تواند کمک کند، ولی دو قرارداد الزاماً دو مسیر مستقل ایجاد نمی کنند. باید وابستگی های فیزیکی و تجهیزات مشترک بررسی شوند. همچنین برنامه به زمان انتظار مناسب، تلاش مجدد کنترل شده و پیام قابل فهم برای کاربر نیاز دارد.

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

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

ارتباط معماری فروش با CRM و سانترال سازمان

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

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

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

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

معماری ترکیبی و آزمون پیش از تصمیم نهایی

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

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

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

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

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