🧔🏻 👩‍👧‍👧 😜 كيفية دمج منصتين في منصة واحدة ولا تسيء إلى المستخدمين. تجربة مطوري Yandex.Kew 👲🏼 🤰🏾 👩🏿‍🍳

في العام الماضي ، انضمت خدمة TheQuestion إلى Yandex. في ذلك الوقت ، كانت هناك بالفعل خدمة مماثلة من الأسئلة والأجوبة - Yandex.Znatoki. كان للخبراء جمهور كبير والعديد من الأسئلة المثيرة للاهتمام ، ولكن لم يكن هناك ما يكفي من الخبراء الذين يمكنهم تقديم إجابات عالية الجودة لهذه الأسئلة. على العكس من ذلك ، كان لدى المجتمع مجتمع قوي من الخبراء ، لكنه افتقر إلى أسئلة مثيرة للاهتمام. كانت الخطوة المنطقية هي الجمع بين الخدمتين للحصول على الأفضل من كل منهما. ولكن كيف نفعل ذلك إذا كان لكل خدمة قاعدتها التكنولوجية الخاصة والمحتوى والمستخدمين؟

اليوم سأتحدث عن كيفية حل فريقنا لهذه المشكلة من وجهة نظر تكنولوجية. ستكتشف أي خيارات للجمع تم أخذها في الاعتبار والخيارات التي اخترناها في النهاية. سأخبرك عن "واجهة برمجة التطبيقات للتبديل" وترحيل قاعدة البيانات وتجميع الملفات الشخصية واختبار الخلفية. ومع ذلك - حول ليلة التحرك دون الحق في ارتكاب خطأ. سترى أننا لم يكن لدينا بالملل.

إن مهمة دمج خدمتين في خدمة واحدة ليست جديدة ، ولكن هذا لا يسهل الأمر. يعرف التاريخ العديد من الأمثلة الناجحة (وليس كذلك) للتكامل ، ولكن للأسف ، لا توجد "رصاصة فضية" وتعليمات واضحة "افعل ذلك وكل شيء سينجح". كل شيء يعتمد إلى حد كبير على تفاصيل الخدمات التي يتم دمجها والنتيجة المرجوة.

في حالتنا ، كان الهدف هو: أن كل المحتوى المكتوب على كل موقع كان متاحًا على خدمة موحدة ، ويمكن لمؤلفيه إدارته.

لذا ، كيف تجمع بين الخدمتين "الأسئلة والأجوبة" ، اللتين تبدو متشابهة جدًا ، ولكنها مختلفة كثيرًا في الجوهر؟ يشبه نقل المحتوى والمستخدمين من خدمة إلى أخرى إلى حد كبير الانتقال من شقة قديمة إلى أخرى جديدة.

فقط في حالتنا ، يمكن للمستخدم أن يعيش في وقت واحد في شقتين (خبراء و TheQuestion) ، وتحتاج إلى نقلها بعناية إلى الثالثة. تحتاج إلى نقل جميع الأثاث والنباتات والقط ، وحتى ورق الجدران إلى شقة جديدة (أي الأسئلة والإجابات والتعليقات والإعجابات) ، ثم دعوته للانتقال.

كيف نفعل ذلك؟ العديد من الخيارات تتبادر إلى الذهن على الفور.

الخيار 1. سيء للغاية ،
فلنأخذ فقط إحدى الخدمات ، وننقل كل المحتوى إلى آخر (على الرغم من أن هذا لم يعد سهلاً) ونغلق الخدمة الأصلية.

هذا الخيار سيء للغاية من وجهة نظر مستخدم الخدمة الأولى. لقد هدمنا منزله القديم وأجبرناه على الانتقال إلى منزل جديد. لن يحب أي شخص هذا الموقف ، وبدلاً من التحرك ، يمكنه الذهاب إلى الغروب. بالنسبة لنا ، فإن القيمة الرئيسية هي مجتمع المستخدمين ، لذلك لم نخطط للإساءة إلى أي شخص. وانتقل بجرأة إلى خيارات أخرى.

الخيار 2. Bad
دعنا لا نغير أيًا من الخدمات ، وبدلاً من ذلك ، أطلق خدمة جديدة ومتكاملة وأضف محتوى من الخدمتين الأخريين إليها بشكل دوري (على سبيل المثال ، مرة واحدة في اليوم).

في هذه الحالة ، لا يبدو أننا نجعل المستخدم أسوأ ، ولكننا أيضًا لا نقوم بعمل أفضل. شقته القديمة لا تزال دون تغيير ، ولكن لا فائدة من الانتقال إلى شقة جديدة. يعيش جميع الجيران أيضًا في منزل قديم ، وسيتم نقل زهرة تم شراؤها للتو إلى شقة جديدة فقط بعد يوم واحد. مثل هذه الخدمة الموحدة ليس لديها فرصة لتصبح منزلًا جديدًا.

الخيار 3. جيد ، لكن معقد
، لن نغلق أيًا من الخدمات ، وسنقوم على الفور بتكرار المحتوى والملفات الشخصية على الخدمة المتكاملة ، وسوف ينتقل الأشخاص بمرور الوقت.

يعيش جميع جيران المستخدم (وحتى القط) في وقت واحد في المنزل القديم والجديد. تظهر زهرة اشتريتها للتو على الفور في شقة جديدة. بالضبط ما هو مطلوب! هذا الخيار هو الأكثر راحة من وجهة نظر المستخدم. لذلك اخترناه.

بدء التحرك

يمكن وصف ما فعلناه في نهاية المطاف في عدة جمل. لقد كررنا بالكامل الواجهة الخلفية TheQuestion API بالكامل استنادًا إلى الواجهة الخلفية للخبراء ، وبالتالي الحصول على خلفية واحدة يمكن أن تعمل مع موقعين (وحتى ثلاثة) في وقت واحد. في الوقت نفسه ، ظلت الواجهة الأمامية TheQuestion دون تغيير تقريبًا ، مما يعني أنه من وجهة نظر المستخدمين ، لم يتغير الموقع نفسه عمليًا. تلقى هذا المشروع الاسم الداخلي "مبادلة API". لكن أول الأشياء أولاً.

ما كان لدينا عند المدخل: موقعان مستقلان تمامًا. يعيش خبراء في الغيوم الداخلية لـ Yandex. تمت كتابة الواجهة الخلفية للمتذوقين في Python. تعيش TheQuestion في غيوم Microsoft Azure ، وتتم كتابة الواجهة الخلفية TheQuestion في Go. تحتوي الخدمات على مخطط تخزين بيانات مختلف تمامًا في قواعد البيانات. بالإضافة إلى ذلك ، يحتوي TheQuestion على تطبيقين للهواتف المحمولة (لنظامي التشغيل Android و iOS) ، والذي يحتاج أيضًا إلى الدعم. بشكل عام ، لا يريد العدو أن يوحد حديقة الحيوانات هذه.

المرحلة 0. قُد إلى سحابة Yandex

بالمعنى الدقيق للكلمة ، هذه الخطوة ليست ضرورية لـ "API plugin" ، ولكنها تبسط بشكل كبير الخطوات التالية. في هذه المرحلة ، تخلينا تمامًا عن التخزين الخارجي والمرافق. بدأ TheQuestion باستخدام خوادم Yandex DNS. تم نقل خدمات الإيجار إلى Yandex.Cloud. تم نقل قاعدة البيانات إلى قواعد بيانات ياندكس المدارة. أثناء النقل ، تمكنا أيضًا من العثور على العديد من الأخطاء وإصلاحها في TheQuestion ، على سبيل المثال ، الاتصالات غير المغلقة لـ Redis في كود 2015. كمكافأة ، تلقينا أيضًا قوة إضافية لـ TheQuestion.

المرحلة 1. ترحيل البيانات

بغض النظر عن الخيار الذي تريده لدمج الخدمات ، سيتعين علينا دمج البيانات في أي حال. بالنسبة لقاعدة بيانات واحدة ، قرروا أخذ PostgreSQL - تم استخدام نظام إدارة قواعد البيانات (DBMS) هذا بالفعل في كل من الخبراء و TheQuestion. من أجل عدم إعادة تعقيد المشروع ، لم يبدأوا في إنشاء قاعدة ثالثة للخدمة المتكاملة ، ولكنهم ببساطة أخذوا قاعدة بيانات Znatokov وقاموا بتوسيعها بحيث يمكنها قبول جميع بيانات TheQuestion. كان هذا أول تحد تكنولوجي رئيسي.

يجب تحويل كل إدخال في كل جدول من قاعدة بيانات TheQuestion ووضعه في قاعدة بيانات الخبراء. ثم - اربط كل عمود من قاعدة وأخرى. يجب تحويل العديد من الحقول بشكل بسيط من تنسيق إلى آخر. لذا ، كانت المهمة الفرعية الكبيرة المنفصلة هي تحويل تنسيق تخزين النص (التنسيق الفعلي للسؤال أو تخزين الإجابة) من QML (TheQuestion) إلى Markdown (Experts).

قمنا بإعداد عملية منتظمة (عدة مرات في اليوم) لنقل البيانات الجديدة من قاعدة بيانات إلى أخرى ، ولكن في نفس الوقت تأكدنا من أن البيانات من TheQuestion لم يتم عرضها في أي مكان حتى الانتهاء من المرحلة التالية. نظرًا لأن "عدة مرات في اليوم" بعيدًا عن الوعد "على الفور" ، وقد تكون البيانات في حالة غير متناسقة مع نفس البيانات الموجودة على TheQuestion ، مما قد يؤدي إلى تضليل المستخدمين. فلماذا بدأنا بترحيل البيانات إذا كانت الخلفية غير جاهزة بعد؟

أولاً ، بهذه الطريقة ، حققنا الاستقرار في العملية. ثانيًا ، لقد قللوا من كمية البيانات الجديدة التي ستحتاج إلى نقلها في المستقبل ، وهذا أمر مهم ، حيث يجب دفع كل المحتوى المستورد من خلال الترميز للجودة ، والمحتوى غير المناسب ، والرسائل غير المرغوب فيها ، والاحتيال.

المرحلة 2. "تبديل API"

لذا ، قمنا بحل المشاكل الأولى - لقد تعلمنا أخذ المحتوى من قاعدة بيانات TheQuestion وحتى عرضه إذا كنت ترغب في ذلك. الآن كان من الضروري جعل هذا المحتوى يدخل إلى قاعدة البيانات المدمجة على الفور ، وليس عدة مرات في اليوم.

للقيام بذلك ، كان من الضروري إعادة كتابة الواجهة الخلفية TheQuestion بالكامل بكل المنطق الضروري. بشكل دقيق ، اسم المشروع ، "Swap API" ، لا يعكس الجوهر بالكامل. سيكون من الأصح أن نسميها "خلفية مبادلة". والحقيقة هي أنه بالإضافة إلى التنفيذ المباشر لجميع "الأقلام" اللازمة لعمل الواجهة الأمامية للسؤال ، كان لا بد من تحقيق إمكانيات أخرى. واجهنا العديد من المهام الرئيسية.

تفويضياندكس لديها نظام ترخيص مستخدم مركزي - Yandex.Passport. وبالطبع ، استخدم الخبراء جواز السفر. لتسجيل الدخول إليها ، يجب أن يكون لديك حساب في Yandex. كانت تلك هي المشكلة. لم يقم جميع مستخدمي TheQuestion بتسجيل الدخول إلى الموقع من خلال Yandex (على الرغم من وجود مثل هذه الفرصة). لم يكن لدى العديد من المستخدمين تسجيل الدخول إلى Yandex على الإطلاق وخضعوا للشبكات الاجتماعية (فكونتاكتي ، فيسبوك ...). بطبيعة الحال ، كان علينا الحفاظ على هذه الوظيفة عند الانتقال. لذلك ، قمنا بتطبيق إذن "غير جواز السفر".

بحث الموقع.نفذت TheQuestion بحثًا عن الأسئلة والأجوبة والمستخدمين والموضوعات. للبحث ، تم استخدام حل أبو الهول طرف ثالث. من الواضح ، إذا كنا نتحدث عن خدمة واحدة ، فيجب أن يكون البحث هو نفسه ، أي أنه لا يمكن أن يعمل على نظامين في وقت واحد. وبالتالي ، تم التخلي عن Sphinx لصالح محرك بحث داخلي مع دعم الوظائف الضرورية والفهرسة لجميع محتوى TheQuestion.

شحن الصفحات في Zen و Turbo . في وقت الانضمام ، كانت TheQuestion تستخدم بالفعل تقنيات Yandex. تم دعم صفحات Turbo ، وسقط محتوى مثير للاهتمام في موجز Zen. كل هذا كان لا بد من دعمه في "واجهة برمجة التطبيقات البديلة".

الإخطارات في الخدمة والتطبيقات والقوائم البريدية.كل ما يتعلق بإخطار المستخدمين: الاشتراكات والرسائل الإخبارية بمحتوى مثير للاهتمام والتحدث عن الإعجابات والتعليقات وغير ذلك الكثير. كان يجب نقل كل هذا بعناية وعدم نسيانه.

نظام إدارة الموقع . تشير هذه الفقرة إلى كل ما يتعلق بالإدارة الداخلية للخدمة: الإشراف والتحليلات وما إلى ذلك.

نظام تصنيف المستخدم الموحد.هذه المهمة لم تكن تقنية بل منطقية. من الناحية الرسمية ، ليس من الضروري تطوير نظام تصنيف موحد لـ "واجهة برمجة تطبيقات المبادلة" ، ولكن هذا النظام لا يزال مطلوبًا للخدمة المتكاملة المستقبلية. في كلا الموقعين ، تم تصنيف المستخدمين لكمية وجودة المحتوى الذي تم إنشاؤه. لم يتم الكشف عن تفاصيل التقييم ، ولكن كلما أجبت على الأسئلة في كثير من الأحيان ، كان تقييمك أعلى. كانت مبادئ التصنيف هي نفسها في كلتا الخدمتين ، لكن الصيغة نفسها والعوامل كانت مختلفة تمامًا. كان من الضروري ليس فقط المقارنة الصحيحة والصادقة بين مستخدمي Znatokov و TheQuestion فيما بينهم ، ولكن أيضًا لتعلم التفكير في تصنيف واحد لأولئك الخبراء الذين كتبوا على خدمتين في وقت واحد.

وإعادة كتابة جميع واجهات برمجة التطبيقات.سواء أحببتم ذلك أم لا ، كانت هذه المهمة الأكثر أهمية وصعوبة. كانت العديد من العمليات على الخدمات متشابهة ، لذلك أخذناها من الخبراء ولم نكتب من الصفر. ولكن كان هناك أيضًا الكثير من الأشياء الجديدة ، على سبيل المثال ، خطوط مستقيمة من المستخدمين أو مسودة إجابات. ونتيجة لذلك ، قمنا بإعادة كتابة أكثر من 100 "أقلام" في "واجهة برمجة تطبيقات المبادلة" وقمنا بتنفيذ أكثر من 50 من موارد REST.

بعد أن قمنا بتنفيذ جميع الوظائف الموضحة أعلاه ، كان من الممكن البدء في التحرك. ولكن قبل أن نقوم بخدعة واحدة.

من الواضح أنه قبل تبديل ونشر "واجهة برمجة تطبيقات المبادلة" في الإنتاج ، كان يجب اختبارها جيدًا. بادئ ذي بدء ، كان من الضروري اختباره وظيفيا ، أي التحقق مباشرة من أداء الموقع بأكمله على واجهة برمجة التطبيقات الجديدة. ثانيًا ، إنه مرهق. أردنا أن نتأكد بنسبة 100٪ من أن تصميمنا لن "يكمن" تحت الحمل. وبطبيعة الحال ، أجرينا بانتظام "إطلاق الحمولة" ، مما أظهر أن لدينا عرضًا جيدًا للأداء. ولكن في مسائل أداء الخدمة ، من الأفضل دائمًا تشغيلها بأمان. أي ، حتى أفضل اختبارات الحمل الاصطناعية تختلف بطريقة أو بأخرى عن حمل الإنتاج. لذلك ، قررنا ، قبل تبديل API ، لملء عبء الإنتاج على جناحنا.

للقيام بذلك ، في الواجهة الأمامية لـ TheQuestion ، قمنا بتنفيذ ازدواجية جميع طلبات GET (بمعنى طلبات البيانات ، وليس التعديلات) في واجهات برمجة تطبيقات واحدة في وقت واحد: "API القديم" TheQuestion ، الذي كان في ذلك الوقت هو الرئيسي ، و "واجهة برمجة التطبيقات المبادلة" الثانوية. في الوقت نفسه ، لم تنتظر الواجهة الأمامية استجابة بسيطة لواجهة برمجة التطبيقات ولم تتعامل مع الأخطاء ، ولكن بهذه الطريقة تمكنا من اختبار الواجهة الخلفية على المستخدمين الحقيقيين.

المرحلة 3. ثم تذكرنا حول التطبيقات

لا ، بالطبع ، تذكرناهم كل هذا الوقت ، لكننا واجهنا مشكلة واحدة. أولئك الذين عملوا مع تطبيقات الهاتف المحمول يعرفون أن الإزعاج معهم هو أكثر بكثير من إزعاج الموقع. هذا يرجع في المقام الأول إلى توزيع الإصدارات الجديدة.

أولاً ، تحتاج إلى العمل مع الخدمات الخارجية لـ App Store و Google Play وانتظر حتى تنجح الإصدارات الجديدة في التحقق (وأحيانًا قد يستغرق التحقق وقتًا طويلاً). ثانيًا ، حتى إذا اجتاز تطبيقك الاختبار بالفعل وظهر في المتجر ، فإن هذا لا يعني أن المستخدمين سيقومون بإجراء تحديث.

في حالة الواجهة الأمامية للموقع ، يتحكم المطورون أنفسهم عند إصدار إصدار جديد ، وهم يعرفون على وجه اليقين أنه بعد ذلك سيتلقى جميع المستخدمين نسخة محدثة من الموقع. في حالة الطلبات ، لا يوجد مثل هذا الضمان. للحصول على مثل هذا الضمان ، غالبًا ما يستخدمون "التحديث القسري" للتطبيق. قليل من الناس يحبون هذه الطريقة ، وبالطبع ، دائمًا ، إذا أمكن ، تحتاج إلى الحفاظ على التوافق مع الإصدارات السابقة بين التطبيق والواجهة الخلفية. لذلك ، اتخذنا مسار إجراء التغييرات بدقة على الجانب الخلفي مع الحد الأدنى من التغييرات على الواجهة الأمامية في التطبيقات. ولكن ، كما يحدث غالبًا ، تواجه الخطة واقعًا قاسيًا.

كانت بعض التغييرات أسهل بكثير في الواجهة الأمامية مما كانت عليه في الواجهة الخلفية ، وبالتالي ، في عملية تطوير "واجهة برمجة التطبيقات للمكون الإضافي" ، كانت الواجهة الأمامية قليلاً ، ولكنها تغيرت. على وجه الخصوص ، استخدمت قاعدة بيانات TheQuestion القديمة معرفات رقمية 64 بت. تستخدم قاعدة بيانات خبراء ، وبالتالي ، قاعدة البيانات المدمجة و API الجديدة لـ TheQuestion معرفات سلسلة 128 بت. بشكل عام ، بالنسبة للواجهة الأمامية المكتوبة في Node.js ، هذا الاختلاف ليس مهمًا. ولكن بالنسبة للتطبيقات المكتوبة بشدة ، تبين أن هذا مميت. فقدنا التوافق مع الإصدارات السابقة ، وتعذّر على التطبيقات القديمة العمل مع "واجهة برمجة تطبيقات المكوِّن الإضافي".

في مرحلة ما ، ظهر حتى مشروع يسمى "plugin API for plugin API" ، كان جوهره كتابة طبقة صغيرة بين الواجهة الخلفية الجديدة والتطبيقات التي من شأنها تحويل جميع البيانات إلى التنسيق القديم. ومع ذلك ، تخلينا بسرعة عن هذه الفكرة. سوف تتحول هذه الطبقة إلى "عكاز" جامد للغاية ، والذي سيجلب لنا بالتأكيد العديد من المشاكل. على سبيل المثال ، لا يمكنك فقط أخذ وترجمة معرفات 128 بت إلى 64 بت. كان علي أن أترجم مع فقدان المعلومات ، وبالتالي ، التصادمات المحتملة حسب المعرّف ، أو الاحتفاظ بجدول وسيط مع مراسلات المعرّفات القديمة والجديدة (لجميع عناصر قاعدة البيانات). كلاهما ، وآخر - ليس أفضل حل معماري.

بالإضافة إلى ID ، كان هناك عدد من التغييرات الأخرى التي كان من الأسهل دعمها على الواجهة الأمامية والتطبيق. ونتيجة لذلك ، قررنا تنفيذ التغييرات في التطبيقات وما زلنا نستخدم التحديث القسري. في وقت قصير طورنا إصدارات جديدة من التطبيقات المتوافقة مع "واجهة برمجة التطبيقات المبادلة" ، لأنه لم تكن هناك الكثير من التغييرات من الواجهة الأمامية ولم تكن خطيرة للغاية. تم إرسالها إلى App Store و Google Play ، وتم الإشراف عليها بنجاح وبدأت في الانتظار.

المرحلة العاشرة. دعنا نذهب!

لذلك كل رمز مكتوب. تم اختبار وإطلاق الحامل مع "واجهة برمجة التطبيقات البديلة". تم اختبار الإصدارات الجديدة من التطبيق في المتاجر وهي جاهزة للنشر. الآن يجب طرح كل هذا في الإنتاج.

نظرًا لحقيقة أن نسخ البيانات الجديدة من قاعدة البيانات القديمة إلى قاعدة البيانات الجديدة يتم بشكل غير متزامن ويستغرق بعض الوقت ، لا يمكنك تبديل الواجهة الخلفية (وقاعدة البيانات الموجودة تحتها) على موقع العمل. قد يؤدي هذا إلى فقدان أو تضارب بيانات المستخدم. لذلك ، اخترنا موعدًا وحذرنا المستخدمين وأعدنا لوحة "العمل الفني قيد التقدم".

ثم جاءت الساعة ، أو بالأحرى ليلة X. بدت خطة التنفيذ كما يلي:

على موقع TheQuestion ، نعلق رسالة "العمل جارٍ".
نقوم بنقل التطبيقات إلى وضع للقراءة فقط. يمكن للمستخدمين قراءة المحتوى من قاعدة البيانات القديمة ، ولكن لا يمكنهم إنشاء واحدة جديدة.
TheQuestion Readonly. : . , , .
. , .
.
, , API.
API . — , API .
, , .
« », API.
.

حسنًا ، هذا لا يبدو مخيفًا جدًا. في الواقع ، كل شيء سار بسلاسة تامة. من المفاجآت التي واجهناها ، ربما كان وقت نشر التطبيق في App Store طويلًا جدًا (تم التحقق من التطبيق مسبقًا ، وكان الأمر يتعلق فقط بالظهور في المتجر). في النهاية ، استغرق الأمر عدة ساعات ، ولهذا تأخرت العملية برمتها قليلاً.

بالإضافة إلى ذلك ، في عملية التبديل ، كانت هناك ميزة رئيسية واحدة أدت إلى تعقيد كل شيء عدة مرات وزيادة المسؤولية. والحقيقة هي أنه لا يمكن عكس عملية التبديل.

على الرغم من أن عملية نسخ البيانات وتحويلها من قاعدة بيانات TheQuestion القديمة إلى قاعدة البيانات الجديدة والمتكاملة تم إعدادها وتصحيحها بالنسبة لنا ، لم تكن هناك عملية نسخ عكسي (من قاعدة البيانات الجديدة إلى القديمة). هذا يعني أنه بمجرد أن نفتح الموقع على "واجهة برمجة تطبيقات المبادلة" وبدء حركة مرور المستخدم ، فإن جميع الأسئلة والإجابات والتعليقات والإعجابات التي تم إنشاؤها حديثًا لم يعد من السهل الوصول إلى قاعدة بيانات TheQuestion القديمة. إذا حدث خطأ ما بعد الفتح ، على سبيل المثال ، لا يمكن لقاعدة بيانات واحدة التعامل مع الحمل ، فلن يكون من الممكن استرجاع كل شيء بسرعة.

في الواقع ، بالطبع ، أبالغ. على أي حال ، لن نفقد بيانات المستخدم. كانت لدينا خطة B وطريقة لإجراء نسخ احتياطي للبيانات يدويًا من قاعدة بيانات جديدة إلى قاعدة بيانات قديمة. ولكن سيستغرق الأمر بعض الوقت ، ولم يكن التراجع سيحدث بدون ألم للمستخدمين.

لحسن الحظ ، نجحت الخطة "أ" ، ولم يكن هناك شيء يمكن التراجع عنه.

المرحلة الأخيرة

لذلك ، تم تغيير الواجهة الخلفية ، وتم دمج قاعدة البيانات ، ولم يتم نسيان تطبيقات الهاتف المحمول. بالنسبة للمستخدمين ، لم يتغير شيء ، لأن موقع Yandex.Ku ، الذي كان من المفترض أن يجمع بين البيانات من كلا الموقعين ، لم يتم إطلاقه بعد في ذلك الوقت. ولإطلاقها ، كنا بحاجة إلى حل مشكلة أخرى.

في البداية ، كتبت أنه كان علينا الجمع ليس فقط بين الأسئلة والإجابات من خدمتين في واحدة جديدة ، ولكن أيضًا المستخدمين. كان يجب أن يكون المستخدمون قادرين على رؤية المحتوى الخاص بهم على Kew ، ولكن أيضًا إدارته على Kew. من الناحية الفنية ، ليس من الصعب الجمع بين البيانات ونقل حقوق الإدارة. من الأصعب بكثير التأكد من أن الحقوق تنتقل إلى الشخص الذي ينبغي نقلها إليه.

عند الانتقال من Znatokov إلى Kew ، كل شيء بسيط: في كلتا الحالتين ، يتم استخدام نفس حساب Yandex. لكن TheQuestion له حسابه الخاص ، والذي لا يمكن التصريح به في Kew. لحسن الحظ ، فكرنا في هذا مسبقًا. قبل وقت طويل من الإجراءات الموضحة أعلاه ، قمنا بتمكين مستخدمي TheQuestion لربط ملفاتهم الشخصية في Yandex. وبحلول وقت الدمج المادي للخدمات ، قام بذلك أكثر من 90٪ من المستخدمين النشطين. سمح لنا هذا ببدء ترحيل المحتوى والمستخدمين دون ألم.

مجموع

عندما انتقلنا ، أردنا إنقاذ كل مستخدم ، لذلك ذهبنا بوعي إلى الخيار الأكثر استهلاكًا للوقت والمخاطر وهو الجمع بين المنصات. أنشأنا قاعدة تكنولوجية موحدة ، وتعلمنا كيفية نقل المحتوى والملفات الشخصية على الفور. وبدلاً من الإغلاق غير المتوقع وإعادة التوطين القسري ، حافظوا على وظائف الخدمات القديمة ، وأطلقوا خدمة جديدة وشرحوا مزاياها.

أطلقنا Yandex.Kew العام الماضي. الآن أكثر من 80 ٪ من المؤلفين النشطين في TheQuestion و Znatokov انتقلوا طواعية إلى منزل جديد.

كيفية دمج منصتين في منصة واحدة ولا تسيء إلى المستخدمين. تجربة مطوري Yandex.Kew