ثلاث سنوات في مؤسسة Wikimedia (2022–2025) علّمتني أن الأنظمة التي تخدم ما يقارب نصف كوكب الأرض مرة في الشهر هي في معظمها PHP غير مُبهرج، وتخزين مؤقّت (caching) مدروس، وثقافة تشغيلية — لا الأشياء الفلكية المعمارية التي تكافئها محادثات المؤتمرات. هذا المنشور رسالة حبّ صادقة إلى الكود الممل على نطاق واسع، من شخص قضى ثلاث سنوات داخل أحد أوضح الأمثلة العاملة عليه.

ما هي Wikipedia تشغيلياً

Wikipedia ليست موقعاً واحداً. هي مئات الطبعات اللغوية، تعمل على codebase مشترك (MediaWiki)، يدعمها أسطول MySQL مُضبَط بدقّة، يتقدّمه Varnish وطبقة cache مخصّصة، تُخدَم عبر PoPs عالمية متعدّدة. مؤسسة الهندسة أصغر مما يخمّن معظم من هم خارجها. المؤسسة المموَّلة بالتبرّعات لها ميزانية ضيّقة، وبنك عميق من المساهمين المتطوّعين، وثقافة تتراكم لأكثر من عشرين عاماً.

يمكنك رسم مخطّط معمارية لها في خمس دقائق. لا تستطيع بناءها في أقل من عقد.

كيف بدا العمل عليها

سأقول الشيء غير الأمين أولاً: حين دخلتُ Wikimedia، كنتُ أتوقّع العمل على نظام يبدو كأنه يجب أن يكون في متحف. الواقع كان أقرب إلى آلة موسيقية مُضبَطة بإتقان حيث الضبط نفسه هو السبب في نجاحها. الكود نفسه ليس الأقدم ولا الأحدث الذي لمستُه. ما هو فريد هو الحكمة التشغيلية المتراكمة المدموجة في كل قرار عن كيفية تشغيل الكود.

بشكل ملموس:

  • التخزين المؤقّت من الدرجة الأولى. كل ميزة تبدأ بـ”كيف يتخزّن هذا مؤقّتاً؟” — لا كاهتمام أداء لاحق، بل كسؤال تصميم بوّابي. إن كانت ميزة ما تُقلّل من قابلية التخزين المؤقّت، فتلك محادثة تصميم، لا جولة ضبط أداء.
  • MySQL آلة موسيقية مُضبَطة. خطط الاستعلام تُراجَع. الفهارس تُكتسَب. “دعنا نضيف فهرساً” ليست شيئاً موجوداً — الفهارس لها تكلفة مستمرة على هذا النطاق، والمحادثة عن إن كانت التكلفة مبرَّرة بحجم الاستعلام، لا إن كان الفهرس يجعل الاستعلام أسرع. هذا مستوى من الانضباط لم أره في الشركات الأصغر.
  • عمليات النشر مُدرَّبة. عملية القطار — كيف يصل الكود للإنتاج كل أسبوع — مُنقَّحة لأكثر من عقد. هي وثيقة منشورة. الجميع يعرف ما يحدث متى. لا نشر مفاجئ.
  • المراقبة متجذّرة عميقاً. حين تحدث حادثة، ذاكرة العضلات لأي لوحة تحكّم تفتح، أي مصدر سجل تستعلم، أي مسؤول استعداد (on-call) تُنبّه، بُنيت على مدى سنوات. مكتوبة. مُدرَّبة. المهندسون الجدد يتعلّمونها كطقس، لا كمرجع.

لا شيء من تلك الأربعة معماري. إنها عادات تشغيلية تراكمت. هذا هو الخندق الحقيقي.

ما عملتُ عليه

لن أُبالغ في حجم بصمتي. في ثلاث سنوات ساهمتُ في تحسينات الأداء والموثوقية والمراقبة — معظمها backend، معظمها في مناطق تنقل تجربتي السابقة مع PHP عالي الإنتاجية وMySQL بسلاسة. شحنتُ تغييرات بنية تحتية أصغر، شاركتُ في مراجعات معمارية لأنظمة أكبر من تأليفي الفردي، وساهمتُ في عمل معايير طُرح في جميع أنحاء مؤسسة الهندسة.

نمطان من ذلك الوقت سأحملهما إلى الأبد:

1. مراجعات المعمارية كغراء تنظيمي. تُدير Wikimedia عملية مراجعة معمارية منظّمة. يُكتَب مقترح، يُعمَّم، يُناقَش، يُراجَع، ويُعتمَد في النهاية. المراجعة بطيئة — أحياناً أسابيع — والبطء هو الميزة. يُجبر المقترحات على النضج، ويعطي كثيراً من المساهمين (لا مجرّد مهندسي الموظّفين) صوتاً في الاتجاه. في الشركات الأصغر رأيتُ محاولات مشابهة تتعفّن إلى مجرّد ختم. في Wikimedia نجحت لأن الثقافة توقّعت مشاركة حقيقية. هذه القطعة المفقودة من معظم ثقافات مراجعة التصميم.

2. معاملة المساهمين المتطوّعين كمهندسين من الدرجة الأولى. قاعدة مساهمي Wikimedia من المتطوّعين تتجاوز الموظّفين المدفوعين بفارق شاسع. كل قرار تصميم، كل تغيير API، كل نمط كود يجب أن يكون مقروءاً ومُرحَّباً به لأشخاص ليس لديهم standups معك. هذا قيد صحيّ بشكل لافت على القرارات الهندسية. معظم أمراض codebases الداخلية فقط — النكات الذكية، التقاليد غير المكتوبة، الـabstractions السحرية — لا تصمد حين يكون الجمهور العالم بأسره.

ما علّمني هذا عن النطاق

حين دخلتُ، ظننتُ أن “نطاق Wikipedia” يعني أن المشكلة الصعبة هي حجم حركة المرور. ليست كذلك. المشكلة الصعبة هي نصف المليون شخص الذين يُحرّرون المحتوى، رسم بيانات المحتوى المتراكم لعشرين عاماً، والانضباط التشغيلي المطلوب للسماح لكل ذلك بالاستمرار في العمل مع شحن ميزات في نفس الوقت.

حركة المرور تخدمها Varnish. ذاك الجزء محلول.

تجربة التحرير، سير عمل المحتوى، التوجيه متعدّد اللغات، نظام منع الإساءة، أدوات المجتمع، التعامل مع الإهمال، عقد الـAPI مع مئات الأدوات من طرف ثالث — تلك هي المشاكل التي تستهلك الاهتمام الهندسي. ولا شيء منها يُيسَّر بالتخلّي عن codebase الـPHP المملّة. كان سيُصعَّب، لأنك كنت ستخسر الحكمة المتراكمة مع codebase.

لماذا غادرتُ (وما أخذتُه)

غادرتُ Wikimedia في أبريل 2025 لعمل أكثر تطبيقياً على الهندسة بمساعدة الذكاء الاصطناعي والأنظمة الوكيلية local-first — وهو، في تقلّب أقدّره، بالضبط نوع مشكلة الانضباط المملّة التي درّبتني Wikimedia على التفكير فيها جيداً. لوحة التحكّم لوكيل (Fulcrum) ليست نظاماً رائعاً معمارياً. إنها آلة حالات، وسجل، وطبقة ذاكرة، ومنسّق. ستصبح مثيرة بالطريقة التي يكون بها مجموعة Wikipedia مثيرة: في الانضباط التشغيلي، لا المعمارية.

أكبر شيء أخذتُه من Wikimedia هو قناعة أن معظم الأنظمة “المملّة” مملّة لأن أحداً ما اكتسب الملل. أمضى شخص ما سنوات في سداد الأجزاء المثيرة. كتب شخص ما دليل التشغيل. جادل شخص ما من أجل مراجعة المعمارية البطيئة.

لو أعطيتُ نصيحة واحدة لكل مهندس سأعمل معه بقية مسيرتي: كن مريباً من الأنظمة المثيرة. اسأل من يدفع ثمن الإثارة. عادةً هي دورة الاستعداد، وستلاحق في النهاية.