عندما تصبح قدرات الخدمة السحابية شحيحة بالفعل ، وينظر إلى الانتقال إلى الإصدار المعبأ على أنه الخطوة المنطقية التالية لمواصلة تطوير بوابة الشركة ونظام CRM ، يطرح السؤال للشركات ، وكيفية القيام بذلك ، وما الذي ينتظرها ، وهل سيتم الاحتفاظ بكل شيء بعد النقل؟
يبدو أن كل شيء بسيط للغاية:
- قم بتوسيع المضيف مع الصندوق ؛
- نكتب الدعم الفني.
- نطلب نسخة احتياطية ؛
- نتطلع إلى تلقيها ؛
- ننشر النسخة الاحتياطية ونستمتع بالإمكانيات الواسعة للإصدار المحاصر.
لكن الممارسة تظهر أن الانتقال من السحابة إلى النسخة المعبأة بعيد عن التافهة ويتطلب خطة عمل واضحة ، وتحليل المخاطر المحتملة والتأهب لحقيقة أن كل شيء سيذهب بشكل خاطئ.
تم الاتصال بنا من قبل مطور كبير مع نظام CRM عالي التحميل يعتمد على سحابة Bitrix24. عمل مديرو المبيعات من عدة فروع للشركة بنشاط في CRM ، وتم دمج البوابة الإلكترونية مع Asterisk IP telephony لإنشاء قوائم العملاء المحتملين وتسجيل المحادثات مع العملاء وتسجيل حقائق المكالمات في بطاقة العميل في CRM. تم إنشاء أكثر من 100 عميل محتمل يوميًا في CRM من خلال قنوات مختلفة.
كان من الواضح أن أي وقت بسيط أثناء النقل إلى النسخة المعبأة يهدد العميل بخسائر فادحة. بعد أن تحدثنا مع العميل حول جدية الانتقال والمخاطر المحتملة ، بدأنا العمل.
بادئ ذي بدء ، قمنا بتحليل الحالات والمنشورات الموجودة حول نقل السحابة إلى الصندوق ، وقمنا بقائمة تفصيلية بالأخطاء التي قد نواجهها:
- التطبيقات التي تعمل في السحابة ليست في العلبة ؛
- قد تختلف تكلفة تراخيص التطبيقات للإصدار السحابي والمربع ؛
- خطر فقدان بعض البيانات بسبب فارق زمني أثناء النقل ؛
- سيستمر بعض المستخدمين من الفروع المختلفة في العمل على الخدمة السحابية بعد النقل ، وسيكون من الضروري أيضًا البحث عن الكيانات التي أنشأوها في CRM ونقلها ؛
- في البوابة المغلقة ، لن يعمل تطبيق الهاتف المحمول للخدمة ؛
- بعد النقل ، لن يتمكن بعض المستخدمين من تسجيل الدخول باستخدام كلمة المرور القديمة الخاصة بهم ؛
- قد تكون هناك أعطال في روبوت الدردشة ؛
- إعادة تعيين التفويض المتكرر عند العمل على البوابة الإلكترونية ؛
- لا يمكن عرض سوى جزء من تعليقات المهمة ؛
- ستكون قاعدة البيانات بدون فهرس بحث.
بعد ذلك ، تم تجميع خوارزمية واضحة للإجراءات مع تفصيل حسب الأدوار ، والتي كان يتعين على المقاول والعميل تنفيذها:
1 المرحلة (وسط الاستعجال)- نشر بيئة الإنتاج (المقاول) ؛
- اختبار البيئة المنتشرة (المقاول) ؛
- نشر النسخة المعبأة على المضيفين (المقاول) ؛
- شراء وتركيب شهادة SSL للمكالمات الهاتفية (شراء العملاء ، تركيب المقاول) ؛
- اختبار النسخة المعبأة - الأداء ، المعلمات ، الاختبارات الداخلية (المقاول).
- نشر بيئة ما قبل الإنتاج - نسخة كاملة من الإنتاج (المقاول).
2 المرحلة (عالية الاستعجال)- تطبيق لتفريغ النسخ الاحتياطي. التنسيق مع الدعم الفني لخدمة تاريخ النسخ الاحتياطي (العميل) ؛
- إعلام المستخدمين بتاريخ النسخ الاحتياطي ووضع خطة للتخزين المؤقت للمعلومات من CRM (العميل) ؛
- نشر نسخة احتياطية عن الإنتاج (المقاول) ؛
- إنشاء البوابة بعد النسخ الاحتياطي (المقاول) ؛
- إنشاء خادم هاتفي للعمل مع البوابة (العميل) ؛
- إنشاء وحدة الهاتفية (المقاول) ؛
- اختبار المهاتفة الأولية (العميل) ؛
- اختبار متعمق لإدارة علاقات العملاء والاتصالات الهاتفية والعمليات التجارية لإدارة علاقات العملاء (قسم مبيعات العملاء) ؛
- بيان الصحة. حذف بيانات الاختبار (العميل) ؛
- إيقاف مديري المبيعات في الخدمة السحابية (العميل) ؛
- نقل المعاملات والعملاء وجهات الاتصال من لحظة إنشاء النسخة الاحتياطية من النسخة السحابية إلى الصندوق (المقاول) ؛
- بدء عمل مديري المبيعات على النسخة المعبأة (العميل).
3 مراحل (مستوى الاستعجال منخفض)- اختبار النسخة المعبأة في غضون 2-3 أيام (العميل) ؛
- الموافقة على الأداء الكامل (العميل) ؛
- تحديث ما قبل الإنتاج - نقل نسخة كاملة من الإنتاج (المقاول).
بعد أن وضعنا هذه الخطة ولدينا قائمة تحقق بأخطاء محتملة ، أدركنا أن لدينا الكثير من المخاطر بسبب العدد الكبير من الشكوك:
- ما مدى سرعة تقديم الخدمة النسخ الاحتياطي؟
- كم من الوقت يستغرق نشر نسخة احتياطية ، بالنظر إلى أن قاعدة بيانات CRM ضخمة؟
- ما مدى سرعة إعادة تكوين الوحدة النمطية وخادم الاتصال الهاتفي للعمل بشكل صحيح مع CRM؟
- ما هي الأخطاء المحددة التي يمكن أن تظهر على البوابة ، وما مدى أهمية المستخدمين للعمل ، وكم من الوقت يستغرق إصلاحها؟
لقد أدركنا أن لدينا فترة زمنية غير محددة ، والتي ، كلما زادت ، من شأنها أن تجلب المزيد والمزيد من الخسائر للعميل. لتقليل الفجوة الزمنية ، كان من الضروري فهم مقدار الوقت الذي نقضيه في نقل البوابة وتصحيحها.
لذا توصلنا إلى استنتاج مفاده أن نسخة احتياطية واحدة من السحابة لن تكون كافية ، ومن أجل تقليل الخسائر ، من الضروري نشر نسخة احتياطية واحدة - لتحديد جميع المخاطر المحتملة وتقدير الفاصل الزمني ، ثم نسخة احتياطية ثانية يمكننا التخطيط لها بطريقة لتقليل الخسائر .
يوفر Bitrix نسخة احتياطية واحدة ومرة واحدة فقط ، حيث أن عملية النقل من السحابة إلى الصندوق معقدة تقنيًا. بالانتقال إلى الدعم الفني وربط العميل بهذه المشكلة ، لا يزال لدينا الضوء الأخضر لتوفير نسختين احتياطيتين من السحابة في أوقات مختلفة. تم الاتفاق على وقت النسخ الاحتياطي الأول وبدأت عملية النقل.
الحجم والسرعة والأجزاء المكسورة
من أجل فهم مقدار الوقت الذي سيستغرقه الوقت ، بدأنا في الاحتفاظ بمجلة نسجل فيها كل خطوة.
لذا ، بدأت البوابة في النسخ الاحتياطي للخدمة ليلة الخميس ، أي أن CRM كانت لديها أحدث البيانات في نهاية يوم الخميس ، وزودتنا برابط للنسخ الاحتياطي بعد ظهر الجمعة. واجهنا هنا الصعوبة الأولى - كان النسخ الاحتياطي يزن حوالي 30 غيغابايت ، وكانت سرعة التنزيل من خوادم Amazon.com التي استضافت السحابة بعيدة عن المثالية (بمتوسط 800 كيلوبت / ثانية). بعد حساب الوقت تقريبًا الذي تم فيه تحميل عدة أجزاء من النسخة الاحتياطية ، أدركنا أن الأمر سيستغرق حوالي 10 ساعات لتنزيل النسخة الاحتياطية فقط.
كانت المشكلة التالية هي ظهور أخطاء أثناء ضخ أجزاء مختلفة من النسخ الاحتياطي ، والتي تم اكتشافها فقط عند نشرها. تسببت هذه الأجزاء ، كقاعدة عامة ، أيضًا في عدم تطابق تجزئة التجزئة ، ولهذا كان من الضروري تحديد الجزء المكسور من الأرشيف في نص الخطأ ونقله يدويًا عبر SSH ، وبعد ذلك تم إعادة فتح الحزمة من الصفر للنسخ الاحتياطي بأكمله.
بعد نجاحنا في تحميل ونشر نسخة احتياطية على مضيفينا ، تلقينا نسخة صالحة للعمل من السحابة في الصندوق وانتقلنا إلى الخطوة التالية - اختبار البوابة وتصحيحها.
البق الطفيفة ودفع وسحب الخبيثة
لدهشتنا ، كان اختبار الصناديق بسلاسة نسبيًا. لقد اختبرنا CRM ، وذهبنا عبر جميع أدوات الخدمة ، وتحققنا من وظيفة المراسلة ، وأجرينا اختبارات داخلية وكشفنا عن 3 أخطاء فقط:
- اختفى رمز مرفق الملف في برنامج المراسلة ولم يعمل إرسال الملفات في برنامج المراسلة ككل ؛
- تحتوي الروابط في الإشعارات على عنوان بدون نطاق ، على سبيل المثال: الشركة / الشخصية / المستخدم / 1250 / المهام / المهمة / العرض ، على التوالي ، لم تكن تعمل ؛
- تعذر على بعض المستخدمين تسجيل الدخول إلى البوابة الإلكترونية بسبب خطأ غير صحيح في تسجيل الدخول / كلمة المرور.
علمنا بعدم القدرة على تسجيل الدخول بعد النقل مقدمًا ، تحذر الخدمة على الفور من هذا عند تقديم نسخة احتياطية. لسوء الحظ ، لا يمكن حل هذه المشكلة إلا من خلال المستخدمين الذين يقومون باسترداد كلمة المرور أو تغيير كلمات المرور يدويًا لكل مستخدم بواسطة المسؤول ، نظرًا لأن كلمات المرور من Bitrix24.Network لا يتم تخزينها على البوابة الإلكترونية.
تم حل الخطأ الذي يحتوي على روابط في الإشعارات بسرعة كافية - عن طريق تسجيل نطاق المدخل في إعدادات الموقع وإعدادات الوحدة الرئيسية.
لكن رمز إرفاق الملف المفقود في برنامج المراسلة قدم الكثير من المخاوف. استغرقت المهمة ساعتين أخريين من المحاولات غير الناجحة لفهم سبب الأيقونة المفقودة. ونتيجة لذلك ، وجدنا أن السبب كان بعيدًا عن وحدة القرص ، كما كان من المفترض في الأصل. يكمن السبب في خادم الدفع غير المتصل في إعدادات وحدة الدفع والسحب ، والتي تقوم تلقائيًا بإيقاف نقل الملفات في برنامج المراسلة.
الاختبار النهائي
بعد اختبار وتصحيح البوابة بنجاح ، تم إعداد تقرير مفصل للعميل ، وكانت الخطوة التالية هي الاختبار العميق من قبل قسم مبيعات عملاء CRM ، بالإضافة إلى إعداد خادم الهاتف الهاتفي للعمل مع الصندوق واختبار المكالمات.
أثناء الاختبار ، لم يتم تحديد مشاكل كبيرة. لقد قمنا بنشر مضيف اختبار وقمنا بتدوير نسخة كاملة من البوابة القتالية ، في حالة امتلاكنا لنسخة 100٪ من البوابة ، ووفقًا لذلك يمكننا إجراء مقارنة في الإعدادات إذا كانت هناك أخطاء غير قياسية لم يتم اكتشافها عند اختبار النسخة الاحتياطية الأولى.
بعد نشر نسخة من البوابة ، انتقلنا إلى تحليل المجلة ، حيث قمنا بإصلاح الأخطاء ووقت حلها. بعد تحليل المجلة بالتفصيل ، قمنا بتحديث خطة نقل النسخة الاحتياطية الثانية ، وأدركنا كم يمكن أن نفقد العملاء المحتملين أثناء النقل النهائي ، وخصصنا وقتًا إضافيًا للاستيراد اليدوي للعملاء المحتملين المفقودين من الإصدار السحابي. كما تمت مناقشة جميع التفاصيل والمخاطر مع العميل وتم إرسال خطاب إلى الدعم الفني للخدمة مع طلب لإعداد نسخة احتياطية ثانية.
النسخ الاحتياطي الثاني ولماذا يمكن أن يحدث كل شيء خاطئ؟
بعد الاتفاق على وقت إنشاء النسخ الاحتياطي أيضًا يوم الخميس ، أعددنا الفريق للإجراءات التشغيلية بحلول الساعة 12 ظهرًا يوم الجمعة. في غضون 12-13 ساعة ، تلقينا الرابط الذي طال انتظاره وبدأنا في التنزيل. بعد بضع ساعات ، كان من الواضح أن الأرشيف لن يتم ضخه لمدة 10 ساعات ، ولكن حوالي 14! عرض النطاق الترددي لقناة مزودنا وخوادم Amazon.com في هذا اليوم ترك الكثير مما هو مرغوب فيه. كنا نستعد للعمل الليلي ، حيث استمر العملاء المحتملين في الانخفاض ، وكان العميل ينتظر تقريرًا لبدء إعداد خادم الهاتفية.
كما يحدث غالبًا ، لم يكن كل شيء يسير وفقًا للخطة. كانت الخطوة التالية هي نقل العملاء المحتملين المتراكمين من الإصدار السحابي إلى الصندوق - العملية بسيطة وواضحة ، ولكن لها فروق دقيقة خاصة بها. إذا قمت في قائمة العملاء المحتملين بتحديد العملاء المتوقعين الذين يحتاجون إلى التصدير والنقر فوق "تصدير إلى CSV" ، فسيتم إلغاء تحميل جميع العملاء المتوقعين الحاليين في CRM ، وليس فقط العملاء المحتملين المحددين. من المنطقي أنه مع قاعدة بيانات كبيرة ، سقطت السحابة في خطأ. كان الحل هو استخدام مرشح ، في هذه الحالة فقط تم تفريغ العملاء المتوقعين بشكل صحيح.
مرت اختبارات أخرى دون مفاجآت ، كما علمنا بالفعل: ما الذي لن ينجح ، وكيفية إصلاحه وأين. بعد أن تم بنجاح الاتصال بالاختبار الهاتفي واختباره ، عمل مديرو المبيعات يوم الاثنين بالفعل بشكل كامل مع CRM في النسخة المعبأة. وبالفعل في أمر العمل لمدة أسبوع قمنا بضبط البوابة ، وعمل نسخة احتياطية منها ، وقمنا بعمل نسخة نهائية من البوابة إلى مضيف الاختبار.
استغرقت عملية النقل بأكملها حوالي أسبوع من العمل من لحظة التخطيط إلى الإعدادات النهائية.
ونتيجة لذلك ، أود أن أشير إلى أهمية التخطيط لمثل هذه المشاريع المعقدة والمحفوفة بالمخاطر ، والمشاركة الإلزامية للعميل في العملية والتحدث عن المخاطر المحتملة ، على الرغم من أنه ، كما تظهر الممارسة ، فإن الانحرافات عن الخطة ليست استثناءً.