المجتمع الذي أشر إليه في المقال أعلاه هو مثال جيد لمجتمع كانت عملياته تنكسر بسبب عدم كفاية القابلية للتوسع. لم تكن بروتوكولات الإشراف لدينا قابلة للتوسع، لذلك استغلنا الفرصة عند انتقالنا من vB إلى Discourse لمراجعتها. كان هذا القرار الصحيح.
شكرًا لك لمشاركة نتائج هذا النوع من الأبحاث. من الواضح أن هذا المنتدى مثال رائع على مجتمع منتديات نابض بالحياة، ومثال ممتاز على الاستخدام الصحيح لبرنامج منتديات Discourse. كمدير لمجتمع صغير لا يزال في مرحلة النمو، هناك الكثير مما يمكن تعلمه من النموذج المطبق هنا.
إن استعدادك لمشاركة الخبرات المستفادة من قاعدة عملائك مفيد للغاية ومُقدّر.
لديّ قصة صغيرة وممتعة عن تأخير مفرط في توسيع نطاق إحدى مجتمعاتتي التي تضم 1.2 مليون عضو.
تُعد SkyscraperCity واحدة من أكبر المجتمعات، إن لم تكن أكبر مجتمع مخصص للعمارة والبيئة الحضرية والهياكل الحضرية في العالم. لكل منطقة في العالم تتمتع بمستوى كبير من التطور الحضري والهياكل الأكبر المرتبطة بها قسمها الخاص. ومن الطبيعي أن تحتوي على كمية هائلة من الصور المشتركة داخلها، لأن أعضاء هذا المجتمع يحبون حقًا حقًا إظهار ومناقشة ناطحات السحاب التي يتم الحديث عنها.
لم تظهر المشكلة في المكان الذي كنت تتوقعه.
لم تكن المشكلة في تأخير توسيع نطاق معالجة الصور والمرفقات. كان هذا عاملاً معروفًا، وتم بناء المنصة للتعامل معه.
حدثت المشكلة مع زيادة عدد المناطق الحضرية المميزة، ومع كل فئة جديدة فردية، وفئة فرعية، وفئة فرعية فرعية فرعية بناءً على القارة، والأمة، والولاية، وأخيرًا المدينة، والتي يمكن أن يكون لها أي عدد من الأحياء. لقد توسع هيكل المعلومات للمجتمع بما يتجاوز قدرة المنصة على التعامل مع كل تلك المناطق التي أصبحت نشطة. كانت تنحني تحت وزن كل تلك الفئات، وتباطأ الأداء إلى حد الزحف الكامل. كان التنقل من صفحة إلى أخرى مؤلمًا للغاية، ناهيك عن إنشاء منشور!
كانت المنصة المحددة بناءً مخصصًا قديمًا من XenForo مبنيًا على أشجار العقد للفئات، ولم تكن مصممة للتعامل مع مئات وآلاف الفئات الفردية كجزء من الهيكل. بالطريقة التي تم بناؤها بها، تشغل كل عقدة قدرًا جيدًا من الموارد، لذا كلما زاد عدد العقد في نقطة معينة، قل استقرار المنصة. كنرجسيًا كما أنا، كانت الطريقة التي وصفتها للمجتمع للتصور تشبيهها حلقة معينة من Star Trek: The Next Generation، عندما اكتشفوا أن محركات الوارب كانت تخترق ثقوبًا في نسيج الزمكان بشكل متكرر أكثر من اللازم، مما يضعف الفضاء في منطقة ذات حركة مرور عالية.
كانت الفئات الزاوية (الفئات الفرعية الفرعية الفرعية الفرعية وما إلى ذلك) تسبب “ضررًا” لاستقرار المنصة بنفس الطريقة التي كان فيها مئات محركات الوارب التي يتم تشغيلها في منطقة فضائية شائعة وحولها تسبب انهيار تلك المنطقة.
لم يكن الحل مختلفًا عن حل الاتحاد، حيث تقوم بخفض السرعة وتقييد الاختراقات. لذلك قمنا بمراجعة شاملة لهيكل المعلومات، ودمجنا العديد من الفئات ذات المستوى الأدنى وحتى بعض الفئات الأعلى، واستقر النظام.
بالطبع، لا تظهر هذه المشكلة مع Discourse، لأن Discourse يعامل الفئات بشكل أفضل بكثير كحاويات من الدرجة الأولى، بدلاً من شجرة هيكلية ضخمة واحدة. شبكة فطرية أو قنوات انتقال فائق السرعة، إذا شئت. لكن هذا بالتأكيد أحد أبرز الأمثلة التي لدي على التوسع مبكرًا جدًا، وليس بالضرورة في المكان الذي كنت تتوقع أن يأتي منه التأثير.
لقد رأيتُ حالات مشابهة — ليس في المجتمعات التي أديرها، بل في قاعدة عملائنا. جاءت إلينا علامة تجارية ضخمة لن أذكر اسمها، تبحث عن نقل مجتمعها إلى Discourse. إنهم يقدمون برامج ملاحة، وكان لديهم فئات فرعية لكل موقع جغرافي يغطونه.
في ذلك الوقت، كنا قلقين بشأن الحمل على وظائف الإدارة في حال وجود آلاف الفئات. رفضنا إنشاء طبقات أعمق وحاولنا إقناعهم بقوة استخدام الوسوم (Tags)، لكنهم لم يترددوا في الرفض. انسحبنا من الصفقة لأنها لم تكن ستعمل بطريقة نراها مستدامة.
تصميم هياكل معلومات قابلة للتوسع أمر بالغ الأهمية.
