قرار است SAP بیاوریم؛ اما آیا زیرساخت ما برای SAP آماده است؟

روایت من از چیزهایی که قبل از استقرار SAP S/4HANA باید درباره سرور، شبکه، امنیت، Backup و Disaster Recovery بدانیم

مدتی است درگیر پروژه‌ای هستم که تقریباً همه‌چیزِ واحد فناوری اطلاعات را تحت تأثیر قرار داده: آماده‌سازی سازمان برای استقرار SAP S/4HANA.

وقتی پای SAP وسط می‌آید، طبیعی است که بیشتر جلسات حول فرایندها بچرخد. مالی چه می‌شود، انبار چطور کار می‌کند، فرایند خرید چه تغییری می‌کند، کدام ماژول‌ها پیاده می‌شوند، Key Userها چه کسانی هستند و چه داده‌هایی باید Migration شوند. همه‌ی این‌ها سؤال‌های درستی هستند. اما از زاویه‌ی یک مدیر IT، یک سؤال دیگر هم هست که به نظرم به اندازه‌ی همه‌ی آن‌ها اهمیت دارد:

SAP قرار است روی چه زیرساختی زندگی کند؟

هرچه بیشتر وارد این پروژه شدم، بیشتر به این نتیجه رسیدم که پروژه‌ی SAP برای تیم IT از روز نصب شروع نمی‌شود؛ خیلی زودتر از آن شروع شده است.

SAP فقط یک نرم‌افزار دیگر نیست

یکی از اولین اشتباه‌هایی که ممکن است مرتکب شویم این است که SAP را مثل یک Application سازمانی دیگر ببینیم. یک VM می‌سازیم، CPU و RAM می‌دهیم، Storage وصل می‌کنیم و تمام.

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

همین تغییر نگاه، نقطه‌ی شروع طراحی زیرساخت SAP است.

سؤال اول نباید این باشد که «چه سروری بخریم؟»

احتمالاً این یکی از اولین سؤال‌هایی است که در هر پروژه‌ی SAP مطرح می‌شود. خود من هم اوایل خیلی زود وارد همین فضا شدم: CPU چه مدلی باشد؟ چقدر RAM لازم داریم؟ Storage چه ظرفیتی داشته باشد؟ شبکه چند گیگابیت باشد؟

اما کمی که جلوتر رفتم متوجه شدم قبل از این‌ها باید چیزهای دیگری روشن شود. چند کاربر همزمان داریم؟ حجم Transactionها چقدر است؟ Data طی سه تا پنج سال آینده چقدر رشد می‌کند؟ چند Environment خواهیم داشت؟ کسب‌وکار چه SLAای انتظار دارد؟ اگر یک Host از مدار خارج شد چه؟ اگر Storage اصلی Fail شد چه؟ اگر کل Data Center در دسترس نبود چه؟ چقدر Data را می‌توانیم از دست بدهیم و کسب‌وکار چند ساعت می‌تواند بدون SAP ادامه دهد؟

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

Business Requirements → Architecture → Sizing → Hardware

نه برعکس.

DEV، QA و PRD فقط سه اسم نیستند

در معماری SAP معمولاً حداقل با سه محیط سروکار داریم: DEV برای توسعه و تغییرات، QA برای تست و اعتبارسنجی، و PRD برای عملیات واقعی سازمان.

در نگاه اول شاید این فقط یک تفکیک فنی به نظر برسد، اما پشت آن یک اصل مهم خوابیده: هیچ تغییری نباید مستقیماً وارد قلب کسب‌وکار شود. همین اصل روی Compute، Storage، Backup، شبکه، امنیت و حتی روش مدیریت تغییرات تیم IT اثر می‌گذارد. از همین‌جا معلوم می‌شود که SAP یک پروژه‌ی Application نیست؛ عملاً بخش بزرگی از معماری فناوری اطلاعات سازمان را درگیر می‌کند.

HANA یعنی RAM مهم است؛ اما Storage هنوز حیاتی است

یکی از جذاب‌ترین بخش‌های معماری S/4HANA خود HANA است: یک In-Memory Database. یعنی Memory دیگر صرفاً یکی از مشخصات سرور نیست، بلکه بخش مهمی از معماری است.

اما همین موضوع گاهی یک تصور اشتباه می‌سازد: «اگر دیتابیس در Memory است، پس Storage دیگر آن‌قدر مهم نیست.» در حالی که Data Persistence، Log، Backup و Recovery همچنان به Storage وابسته‌اند. یعنی باید همزمان دو چیز را جدی بگیریم: Performance در Memory و Persistence در Storage. و این دقیقاً همان‌جایی است که انتخاب درست معماری Storage، Latency، Throughput، Redundancy و مسیر Backup اهمیت پیدا می‌کند.

HA با Backup فرق دارد

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

فرض کنید یک Host خراب می‌شود و سرویس روی Host دیگری ادامه پیدا می‌کند. عالی است؛ بخشی از High Availability را داریم. اما اگر Data Corruption اتفاق بیفتد چه؟ اگر اطلاعاتی اشتباه حذف شود؟ اگر Ransomware به داده‌ها برسد؟ اگر Storage اصلی دچار خرابی جدی شود؟

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

«بکاپ داریم» جمله‌ای است که دیگر برایم کافی نیست

تقریباً در همه‌ی سازمان‌ها این جمله را شنیده‌ایم: «نگران نباشید، Backup داریم.» اما سؤال مهم‌تر این است: آخرین Restore موفق چه زمانی انجام شده؟

همین یک سؤال نگاه ما به Backup را کاملاً عوض می‌کند. چون هدف Backup این نیست که Job با وضعیت سبز تمام شود؛ هدف این است که روزی که همه‌چیز خراب شد، بتوانیم اطلاعات و سرویس را برگردانیم.

در محیطی مثل SAP باید به چند لایه فکر کرد: Backup عملیاتی، Retention مناسب، نسخه‌ی مستقل، Immutable یا Offline Copy، Replication و از همه مهم‌تر Restore Test. Backupی که هیچ‌وقت Restore نشده، از نظر من هنوز اثبات نشده است.

حالا فرض کنیم کل Data Center از دسترس خارج شود

اینجاست که وارد بحث جدی‌تری می‌شویم: Disaster Recovery.

قطعی گسترده‌ی برق، آتش‌سوزی، مشکل ارتباطی، خرابی Storage، حمله‌ی سایبری یا یک حادثه‌ی فیزیکی می‌تواند شرایطی بسازد که دیگر Failover یک VM کافی نباشد. اما قبل از خرید هر تجهیزی برای DR Site، دو عدد باید مشخص شوند:

RPO: چه میزان Data را می‌توانیم از دست بدهیم؟ پنج دقیقه؟ سی دقیقه؟ چهار ساعت؟

RTO: کسب‌وکار حداکثر چه مدت می‌تواند SAP نداشته باشد؟ سی دقیقه؟ دو ساعت؟ یک روز؟

این دو عدد صرفاً Technical Metric نیستند؛ تصمیم‌های کسب‌وکارند. چون هرچه RPO و RTO سخت‌گیرانه‌تر شوند، هزینه و پیچیدگی معماری هم بالا می‌رود. به همین دلیل DR را نباید از خرید تجهیزات شروع کرد. DR از Business Impact شروع می‌شود.

شبکه؛ بخشی که کمتر درباره‌اش حرف می‌زنیم

در جلسات زیرساخت SAP معمولاً CPU و RAM و Storage جذاب‌ترند. اما در نهایت کاربر از طریق شبکه به همه‌ی این منابع می‌رسد. ممکن است سرور قدرتمند و Storage بسیار سریعی داشته باشیم، اما Latency، Packet Loss، Oversubscription یا طراحی نامناسب Core Network تجربه‌ی کاربر را خراب کند.

برای همین ترجیح می‌دهم Performance را در کل مسیر ببینم:

User → Access Network → Core → Firewall → Application → HANA → Storage

Performance واقعی SAP حاصل عملکرد کل این زنجیره است، نه Benchmark یک سرور.

Firewall فقط برای اینترنت نیست

ورود SAP فرصت خوبی است تا معماری امنیت سازمان هم دوباره بررسی شود. آیا کاربران باید مستقیماً به Server Network دسترسی داشته باشند؟ Backup Network چقدر از Production جداست؟ Management Network چطور محافظت شده؟ ارتباط بین Zoneها چگونه کنترل می‌شود؟ چه کسی به چه سرویسی دسترسی دارد؟

در معماری مدرن، Firewall فقط دیواری بین اینترنت و شبکه‌ی داخلی نیست. باید به Segmentation و حتی East-West Traffic هم فکر کرد. اصل ساده است: دسترسی باید بر اساس «نیاز» ایجاد شود، نه بر اساس «امکان». وقتی ERP یکی از حیاتی‌ترین دارایی‌های اطلاعاتی سازمان می‌شود، این اصل اهمیت بیشتری پیدا می‌کند.

هدف Monitoring: قبل از کاربر بفهمیم

یکی از اهدافی که برای زیرساخت SAP برای خودم تعریف کرده‌ام خیلی ساده است: IT باید قبل از کاربر متوجه مشکل شود.

اگر CPU رفتار غیرعادی دارد، اگر Memory Pressure ایجاد شده، اگر Storage Latency بالا رفته، اگر Backup شکست خورده، اگر Interface شبکه Error می‌دهد، اگر ظرفیت Disk رو به اتمام است یا اگر سرویسی حیاتی از دسترس خارج شده، اولین Alert نباید تماس واحد مالی یا انبار باشد.

Monitoring یک Dashboard زیبا روی مانیتور NOC نیست. برای من Monitoring یعنی Observability + Alerting + History + Capacity Planning. بخش History هم خیلی مهم است؛ چون وقتی کسی می‌گوید «SAP این هفته کند شده»، به جای حدس زدن، Data داریم.

زیرساخت را فقط برای امروز طراحی نکنیم

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

شاید امروز ۲۰۰ کاربر کلیدی داشته باشیم. اما سه سال دیگر چه؟ ممکن است شرکت جدیدی به مجموعه اضافه شود، ماژول جدیدی فعال شود، Interfaceهای بیشتری ساخته شوند، BI گسترش پیدا کند، حجم Transactionها بالا برود و Data چند برابر شود.

پس یکی از سؤال‌های مهم طراحی باید این باشد: این Architecture چقدر Headroom دارد؟ زیرساخت Enterprise نباید در روز Go-Live تقریباً تمام ظرفیتش را مصرف کرده باشد. ما فقط ظرفیت نمی‌خریم؛ ظرفیت رشد می‌خریم.

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

می‌توان بهترین سرور را خرید، سریع‌ترین Storage را نصب کرد، Core Network قدرتمند ساخت، Firewall Enterprise گذاشت و Backup و DR هم طراحی کرد. اما یک سؤال باقی می‌ماند: بعد از Go-Live چه کسی این اکوسیستم را نگه می‌دارد؟

ورود SAP فقط سخت‌افزار جدید نمی‌خواهد؛ تیم Infrastructure هم باید وارد مرحله‌ی جدیدی شود. Virtualization، Storage، Backup & Recovery، شبکه، امنیت، Linux، Monitoring، Capacity Management و Disaster Recovery دیگر موضوعات جدا از هم نیستند. همه‌ی آن‌ها بخشی از یک سرویس حیاتی شده‌اند: SAP Platform.

به همین دلیل معتقدم یکی از مهم‌ترین سرمایه‌گذاری‌های قبل از Go-Live شاید اصلاً سخت‌افزار نباشد؛ توسعه‌ی تیم IT است.

SAP می‌تواند فرصتی برای بازطراحی IT باشد

در ابتدا شاید SAP را یک پروژه‌ی ERP ببینیم. اما هرچه بیشتر وارد آن می‌شویم، می‌بینیم که برای واحد IT می‌تواند چیزی بسیار بزرگ‌تر باشد: فرصتی برای بازنگری در Data Center، شبکه، Cybersecurity، Backup، DR، Monitoring، مستندسازی، Change Management و حتی ساختار و مهارت‌های تیم.

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

چیزی که در این مسیر یاد گرفتم

هرچه بیشتر وارد طراحی زیرساخت SAP شدم، بیشتر فهمیدم سؤال اصلی این نیست که «چه تجهیزاتی بخریم؟» سؤال بهتر این است:

می‌خواهیم SAP با چه سطحی از Availability، Performance، Security و Recoverability در سازمان زندگی کند؟

وقتی جواب این سؤال روشن شود، تازه می‌توان درباره‌ی سرور، Storage، سوئیچ، Firewall، Backup و DR تصمیم گرفت.

اگر فردا SAP روی این زیرساخت باشد، آماده‌ایم؟

اگر سازمان شما هم در مسیر استقرار S/4HANA است، پیشنهاد می‌کنم قبل از جلسه‌ی خرید تجهیزات، یک جلسه‌ی دیگر برگزار کنید. روی تخته این کلمات را بنویسید: Compute، Memory، Storage، Network، Security، Backup، Disaster Recovery، Monitoring و در آخر People.

بعد مقابل تک‌تک آن‌ها فقط یک سؤال بپرسید: اگر فردا SAP به این بخش وابسته باشد، آیا واقعاً آماده‌ایم؟

پاسخ صادقانه به همین سؤال شاید از ده‌ها جلسه‌ی بررسی Specification تجهیزات ارزشمندتر باشد. چون موفقیت SAP فقط این نیست که سیستم در روز Go-Live بالا بیاید. موفقیت واقعی این است که سه سال بعد هم سریع، امن، پایدار، قابل بازیابی و قابل توسعه باقی مانده باشد.

و این دقیقاً همان‌جایی است که نقش زیرساخت شروع می‌شود.

رامین دوروزه مدیر فناوری اطلاعات

اگر شما هم تجربه‌ای در آماده‌سازی زیرساخت برای SAP، ERPهای Enterprise یا طراحی DR و HA داشته‌اید، خوشحال می‌شوم دیدگاهتان را در بخش نظرات بخوانم.