أم أنه من الممكن؟ وبطبيعة الحال، يعد ترحيل أنظمة SAP عملية معقدة ومضنية، ويتطلب نجاحها عملاً منسقًا جيدًا من جميع المشاركين. وإذا تم تنفيذ الهجرة في وقت قصير، تصبح المهمة أكثر تعقيدا. لا يقرر الجميع القيام بذلك. ربما يكون هنالك عده اسباب. على سبيل المثال، العملية نفسها طويلة ومعقدة من الناحية التنظيمية. بالإضافة إلى وجود خطر توقف النظام غير المخطط له. أو أن العملاء ليسوا متأكدين من أنهم بعد خضوعهم لمثل هذه العملية سيحصلون على فوائد تتناسب مع الجهود المبذولة. ومع ذلك، هناك استثناءات.
سنتحدث أدناه عن الصعوبات التي يواجهها العملاء في عملية ترحيل أنظمة SAP وصيانتها، ومناقشة سبب عدم توافق الصور النمطية دائمًا مع الواقع، ومشاركة دراسة حالة حول كيفية تمكننا من ترحيل أنظمة العميل إلى البنية التحتية الجديدة في ما يزيد قليلا عن ثلاثة أشهر.
استضافة أنظمة SAP
قبل خمس سنوات فقط، كان من الصعب تخيل أن العملاء سيبدأون على نطاق واسع في استخدام موارد الاستضافة لتطبيقات SAP. وفي معظم الحالات تم تنفيذها داخل المؤسسة. ومع ذلك، مع تطور نماذج الاستعانة بمصادر خارجية وسوق الخدمات السحابية، بدأت النظرة العالمية للعملاء تتغير. ما هي الحجج التي تؤثر على الاختيار لصالح السحابة لـ SAP؟
- بالنسبة للمبتدئين الذين خططوا للتو لتنفيذ SAP، تعد البنية التحتية السحابية تقريبًا خيارًا قياسيًا - قابلية توسيع الموارد لتلبية الاحتياجات الحالية للنظام والإحجام عن تحويل الموارد إلى تطوير الكفاءات غير الأساسية.
- في الشركات التي لديها مشهد نظامي كبير، بمساعدة استضافة أنظمة SAP، يصل مدراء تكنولوجيا المعلومات إلى مستوى مختلف نوعيًا من إدارة المخاطر، لأن الشريك مسؤول عن اتفاقية مستوى الخدمة.
- الحجة الثالثة الأكثر شيوعًا هي التكلفة العالية لبناء البنية التحتية لتنفيذ سيناريوهات التوفر العالي والاسترداد.
- عامل 2027 – أعلن البائع عن نهاية دعم الأنظمة القديمة في عام 2027. وهذا يعني نقل قاعدة البيانات إلى HANA، الأمر الذي يستلزم تكاليف التحديث وشراء قوة حاسوبية جديدة.
يمكن الآن اعتبار سوق استضافة SAP في روسيا ناضجًا تمامًا. وهذا يوفر فرصة كبيرة للعملاء الذين يرغبون في تغيير منصات الاستضافة الخاصة بهم. ومع ذلك، فإن مثل هذه المشاريع يمكن أن تسبب القلق بين الشركات بسبب تعقيد إجراءات الهجرة. وهذا يجبر العملاء على وضع متطلبات متزايدة على مقدمي الخدمات، الذين يجب أن يتمتعوا ليس فقط بكفاءات استثنائية في استضافة وصيانة أنظمة SAP، ولكن أيضًا بخبرة ناجحة في مجال الترحيل.
ما هي صعوبات تغيير استضافة SAP؟
الاستضافة مختلفة. عدم الاتساق مع مستوى الخدمة المعلن، والعديد من "لكن" والعلامات النجمية مع التحفظات في نص صغير، والموارد والقدرات المحدودة لمزود الاستضافة، والافتقار إلى المرونة في مسائل التواصل مع العميل، والبيروقراطية، والقيود الفنية، وانخفاض كفاءة الدعم الفني المتخصصين، بالإضافة إلى العديد من الفروق الدقيقة الأخرى - هذه ليست سوى جزء صغير من المزالق التي قد يواجهها العملاء عند تشغيل أنظمة أعمالهم في البنى التحتية الاستعانة بمصادر خارجية. في كثير من الأحيان، بالنسبة للعميل، يبقى كل هذا في الظل، في غابة عقد متعدد الصفحات، ويظهر في عملية استخدام الخدمات.
في مرحلة ما، يصبح من الواضح للعميل أن مستوى الخدمة التي يتلقاها بعيد عن توقعاته. وهذا نوع من المحفز لإيجاد حلول لتصحيح الوضع، وفي حالة الفشل، عندما تتراكم المشكلات إلى الحد الأقصى ويصبح الأمر مؤلمًا للغاية، ينتقلون إلى الإجراءات النشطة لتطوير خيارات بديلة في اتجاه تغيير مزود الخدمة .
لماذا ينتظرون حتى اللحظة الأخيرة؟ السبب بسيط - عملية ترحيل الأنظمة للعملاء ليست دائمًا شفافة ومفهومة. من الصعب على العميل تقييم المخاطر الفعلية المرتبطة بعملية الترحيل. يمكننا القول أن الهجرة بالنسبة للعملاء هي نوع من الصندوق الأسود: فهي غير واضحة، السعر، وتوقف النظام، والمخاطر وكيفية التخفيف منها، وبشكل عام فهي مظلمة ومخيفة. يبدو الأمر كما لو أنه إذا لم ينجح الأمر، فسوف تدور الرؤوس في الأعلى وعند فناني الأداء.
SAP هو نظام على مستوى المؤسسة، وهو معقد، وبعبارة ملطفة، ليس رخيصًا. ويتم إنفاق ميزانيات مناسبة على تنفيذها وتعديلها وصيانتها، ويعتمد عمر المؤسسة على توفرها وتشغيلها بشكل صحيح. والآن تخيل عواقب إيقاف بعض الإنتاج الضخم. هذه هي الخسائر المالية التي يمكن حسابها بالأرقام التي تحتوي على عدد كبير من الأصفار، بالإضافة إلى المخاطر المتعلقة بالسمعة وغيرها من المخاطر التي لا تقل أهمية.
سنقوم بتحليل الصعوبات التي قد تنشأ في كل مرحلة في حالة ترحيل أنظمة SAP من أحد عملائنا.
إعداد وتصميم
الهجرة هي صيغة لها العديد من الأجزاء المختلفة. ومن أهمها مرحلة تصميم وإعداد البنية التحتية المستهدفة (الجديدة).
كنا بحاجة إلى التعمق في التنفيذ الحالي للأنظمة وهندستها المعمارية. في البنية التحتية المستهدفة، قمنا بتكرار الحلول الموجودة في مكان ما، واستكملناها وقمنا بتحسينها في بعض النقاط، وأعدناها في مكان ما، وفكرنا في الحلول واخترناها لضمان التسامح مع الأخطاء والتوافر، كما قمنا أيضًا بتوحيد جميع الموارد قدر الإمكان.
أثناء عملية التصميم، تم إجراء العديد من التمارين المختلفة، والتي مكنت في النهاية من الاستعداد قدر الإمكان للهجرة ومراعاة جميع أنواع الفروق الدقيقة والمزالق (سنتحدث عنها لاحقًا).
ما انتهينا إليه هو بنية تحتية سحابية خاصة مصممة بشكل فردي بناءً على مركز البيانات الخاص بنا:
- خوادم فعلية مخصصة لـ SAP HANA؛
- منصة المحاكاة الافتراضية VMware لخوادم التطبيقات وخدمات البنية التحتية؛
- قنوات الاتصال المكررة بين مراكز البيانات لـ L2 VPN؛
- نظامان رئيسيان للتخزين لفصل المنتج عن "كل شيء آخر"؛
- SRC يعتمد على Veritas Netbackup مع خادم منفصل ورف قرص ومكتبة أشرطة.
وإليك كيفية تنفيذ كل هذا من الناحية الفنية.
SAP
- لاستخدام التخزين بشكل فعال لـ HANA الإنتاجية، استخدمنا الأقراص المشتركة دون النسخ المتماثل لقاعدة البيانات النظامية باستخدام SAP. تم تغليف كل هذا في مجموعة Active-Standby SUSE HAE القائمة على جهاز تنظيم ضربات القلب. نعم، يكون وقت الاسترداد أطول قليلاً من النسخ المتماثل، لكننا نوفر مساحة التخزين بمقدار النصف، ونتيجة لذلك، نوفر ميزانية العميل.
- في بيئات ما قبل الإنتاج، تم التخلي عن مجموعات HANA، ولكن من الناحية الفنية تم تكرار تكوين الإنتاج.
- تم توزيع بيئات الاختبار والتطوير عبر عدة خوادم أخرى بدون مجموعات في تكوين MCOS.
- تم جعل جميع خوادم التطبيقات افتراضية واستضافتها في برنامج VMware.
شبكة
- لقد قمنا بفصل خطوط شبكات التحكم والإنتاج فعليًا باستخدام مجموعات من المحولات، وتحويل تلك الإنتاجية نحو مراكز بيانات العميل.
- لقد قمنا بتثبيت عدد كافٍ من واجهات الشبكة حتى لا نخلط بين تدفقات حركة المرور الكبيرة.
- لنقل البيانات من أنظمة التخزين، قمنا بإنشاء مصانع FC SAN الكلاسيكية.
شد
- تم ترك الحمل الإنتاجي وما قبل الإنتاج لـ SAP على مصفوفة الفلاش بالكامل.
- تم وضع بيئات اختبار المطورين وخدمات البنية التحتية في مصفوفة هجينة منفصلة.
متلازمة القولون المتهيّج
- تم صنعه باستخدام Veritas Netbackup.
- أضفنا القليل إلى البرامج النصية المضمنة لإجراء نسخ احتياطي لتكوينات MCOS.
- نضع النسخ التشغيلية على رف القرص من أجل الاسترداد السريع، ونستخدم الأشرطة للتخزين على المدى الطويل.
رصد
- تم تثبيت جميع الأجهزة ونظام التشغيل وSAP تحت Zabbix.
- لقد جمعنا العديد من لوحات المعلومات المفيدة في Grafana.
- عند حدوث تنبيه، يمكن لـ Zabbix إنشاء طلب في نظام إدارة الحوادث، وقد قمنا بتنفيذه في Jira. المعلومات مكررة أيضًا في قناة Telegram.
تیلیجرام
الصحة العامة لهانا
حالة خادم تطبيق SAP:
خدمات البنية التحتية
- لخدمة مساحات الأسماء الداخلية، تم رفع مجموعة من خوادم DNS، والتي تتم مزامنتها مع خوادم العميل.
- لقد أنشأنا خادم ملفات منفصلاً لتبادل البيانات.
- لتخزين التكوينات المختلفة، تمت إضافة Gitlab.
- للحصول على معلومات حساسة مختلفة، استخدمنا HashiCorp Vault.
عملية الهجرة
بشكل عام، تتكون عملية الهجرة من المراحل التالية:
- إعداد جميع وثائق المشروع اللازمة؛
- المفاوضات مع المزود الحالي - حل القضايا التنظيمية؛
- شراء وتسليم وتركيب معدات جديدة للمشروع؛
- ترحيل الاختبار وتصحيح الأخطاء؛
- نقل الأنظمة ومكافحة الهجرة.
في نهاية شهر أكتوبر 2019، وقعنا عقدًا، ثم قمنا بتصميم الهندسة المعمارية، وبعد الاتفاق مع العميل، قمنا بطلب المعدات اللازمة.
ما تحتاج إلى الاهتمام به أولاً هو وقت تسليم المعدات. في المتوسط، يستغرق تسليم الأجهزة المعتمدة لـ SAP NAHA التي تلبي متطلبات الشركة المصنعة للبرامج لمنصات الأجهزة من 10 إلى 12 أسبوعًا. ومع الأخذ في الاعتبار الموسمية (وقع تنفيذ المشروع بالضبط في العام الجديد)، كان من الممكن زيادة هذه الفترة بشهر آخر. وبناء على ذلك، كان من الضروري تسريع العملية قدر الإمكان: لقد عملنا مع الموزع والمورد واتفقنا على التسليم السريع بالطائرة (بدلاً من الطرق البرية والبحرية).
تم قضاء شهري نوفمبر وديسمبر في الاستعداد للهجرة واستلام بعض المعدات. لقد قمنا بالتحضير على منصة اختبار في سحابتنا العامة، حيث قمنا بتنفيذ جميع الخطوات الرئيسية واكتشفنا الصعوبات والمشاكل المحتملة:
- إعداد خطة مفصلة للتفاعل بين أعضاء فريق المشروع بمواعيد دقيقة بدقيقة؛
- بناء منصة اختبار لقاعدة البيانات وخوادم التطبيقات بنفس الطريقة تقريبًا كما هو الحال في البنية التحتية المستهدفة؛
- تكوين قنوات الاتصال وخدمات البنية التحتية اللازمة لاختبار تشغيل عمليات التكامل؛
- تم وضع سيناريوهات شاملة؛
- ساعدتنا السحابة أيضًا في إنشاء قوالب جهاز افتراضي تم تكوينها مسبقًا، والتي قمنا بعد ذلك باستيرادها ونشرها ببساطة في المشهد المستهدف.
قبل وقت قصير من عطلة رأس السنة الجديدة، وصلت إلينا الدفعة الأولى من المعدات. هذا جعل من الممكن نشر بعض الأنظمة على أجهزة حقيقية. نظرًا لعدم وصول كل شيء، قمنا بتوصيل المعدات البديلة، والتي تمكنا من الاتفاق على توريدها مع البائع والموزعين. لقد استلمنا بقايا البنية التحتية المستهدفة في المرحلة النهائية.
وللوفاء بالموعد النهائي، كان على مهندسينا التضحية بعطلة رأس السنة الجديدة وبدء العمل على إعداد البنية التحتية المستهدفة في 2 يناير، في منتصف العطلات. نعم، يحدث هذا أحيانًا عندما تكون النار مشتعلة ولا توجد خيارات أخرى. وكان أداء الأنظمة التي يعتمد عليها عمر المؤسسة على المحك.
بدا الترتيب العام للهجرة على النحو التالي: أولاً، الأنظمة الأقل أهمية (مشهد التطوير، ومشهد الاختبار)، ثم الأنظمة الإنتاجية. تمت المرحلة الأخيرة من الهجرة في أواخر يناير وأوائل فبراير.
تم التخطيط لعملية الترحيل بدقة. هذه خطة شاملة تحتوي على قائمة بجميع المهام ووقت الإنجاز والأشخاص المسؤولين. لقد تم بالفعل تنفيذ جميع الخطوات في اختبار الترحيل، لذلك في الترحيل المباشر كان من الضروري فقط اتباع الخطة وتنسيق العملية.
تمت الهجرة بشكل منهجي على عدة مراحل. هناك نظامان في كل مرحلة.
وكانت نتيجة السباق السريع لمدة ثلاثة أشهر هو وجود نظام يعمل بكامل طاقته في مركز بيانات CROC. بشكل عام، تم تحقيق نتيجة إيجابية من خلال العمل الجماعي، حيث بلغت مساهمة وتفاني جميع المشاركين في العملية الحد الأقصى.
دور العميل في المشروع
لم يكن التواصل مع المزود الذي كان عميلنا يغادره أمرًا سهلاً. وهذا أمر مفهوم، فقد كانوا الأخيرين في قائمة الأشخاص المهتمين بإكمال المشروع بنجاح. تولى العميل مهمة تصعيد جميع مشكلات الاتصال والتعامل معها وتعامل مع ذلك بنسبة 100500%. شكر خاص له على هذا. وبدون هذه المشاركة المجدية في العملية، كان من الممكن أن تكون نتيجة المشروع مختلفة تماما.
نظرًا لإضفاء الطابع الرسمي على العمليات من جانب المزود "السابق"، تم تنفيذ دعم البنية التحتية من قبل متخصصين كانوا بعيدين عن المشكلات حرفيًا، وكانوا في ذلك الوقت لا يزالون عملاءهم. على سبيل المثال، قد تستغرق عملية تصدير نفس قاعدة البيانات من ساعة إلى خمس ساعات. ثم بدا أن هذا كان نوعًا من السحر، وهو سر لم يُكشف لنا أبدًا. ربما كان مهندسو الدعم الفني منغمسين في التأمل في هذه الأثناء، متناسين أن هناك مواعيد نهائية في مكان ما في روسيا البعيدة، والمهندسون بدون سلطات رأس السنة، والعميل يبكي ويعاني...
نتائج المشروع
وكانت الخطوة الأخيرة للترحيل هي نقل الأنظمة للصيانة.
نحن الآن نقدم خدمة نافذة واحدة لطلبات العملاء ونغطي النطاق الكامل للمهام المتعلقة بدعم مكونات البنية التحتية وأساس SAP جنبًا إلى جنب مع شريكنا - itelligence. يعيش العميل في سحابة خاصة لمدة ستة أشهر. فيما يلي إحصائيات حالات الخدمة خلال هذا الوقت:
- 90 حادثة (تم حل 20% منها دون إشراك العميل)
- تم حلها ضمن اتفاقية مستوى الخدمة – 100%
- عمليات إيقاف تشغيل النظام غير المجدولة - 0
إذا كانت لديك مشاكل مشابهة لتلك التي يواجهها عميلنا، وتريد معرفة المزيد حول كيفية حلها، فاكتب إلى: [البريد الإلكتروني محمي]
المصدر: www.habr.com