أكملت Cloudflare في 12 أغسطس ترحيل مدونتها إلى EmDash، وهو نظام إدارة محتوى مبني للعمل مع Astro وCloudflare، ضمن مشروع لم يقتصر على إعادة تصميم الواجهة. فقد استخدمت الشركة مدونتها بوصفها «العميل صفر» لاختبار المنصة الجديدة على حركة إنتاج حقيقية، مع التركيز على قابلية التوسع، وسرعة الاستجابة، وسلامة التحول من النظام القديم.
وتقول Cloudflare إن عملية الترحيل كشفت احتياجات مرتبطة بحجم المدونة وتعقيدها، كما أتاحت للفريق تحسين EmDash قبل طرحه على نطاق أوسع. وبما أن النتائج والقياسات واردة من الشركة نفسها، فهي تمثل تجربة تشغيلية منشورة من طرف واحد وليست اختباراً مستقلاً للمنصة.
اختبار المنصة قبل اختبار الأداء
بدأ الفريق بسؤال عملي: هل يعمل EmDash فعلاً مع احتياجات Cloudflare؟ ولهذا اختبر مسارات أساسية مثل إنشاء المنشورات ونشرها وإلغاء نشرها وجدولتها، وإضافة الوسائط، إلى جانب البحث في كيانات المحتوى وإدارة أسماء الكتّاب.
ظهرت الفجوات الأكبر في التعامل مع الحجم الكبير للوسائط والمحتوى، وفي تفاصيل الترجمة وتحسين محركات البحث وسياسات أمن المحتوى (CSP). كما احتاج محرر الإدارة إلى تحسينات في العثور على كتل HTML المخصصة، ومعالجة أخطاء داخل محرر المحتوى، وإبقاء شريط التنسيق ظاهراً أثناء تحرير المنشورات الطويلة.
وكانت المنشورات المجدولة أبرز مشكلة مكتشفة؛ إذ لم تعمل حتى إصدار EmDash 0.19.0. وتوضح هذه النقطة قيمة اختبار مسارات التشغيل كاملة قبل الاعتماد على نظام جديد، لأن الخلل لم يكن سيظهر بالضرورة في اختبار إنشاء المحتوى أو نشره فوراً.
اختبارات ضغط تحاكي حركة متقلبة
تراوحت الحركة المعتادة على Cloudflare Blog حول 75 طلباً في الثانية، لكنها قد تتجاوز 5,000 طلب في الثانية، سواء بالتزامن مع انتشار منشور جديد أو بسبب طفرات غير مرتبطة بوقت نشر محدد. لذلك صمم الفريق اختبارات باستخدام أداة k6 مفتوحة المصدر، شملت زيادة تدريجية للحمل حتى ثلاثة أضعاف خط الأساس، واختباراً يبدأ من صفر ويصل إلى 100 طلب في الثانية خلال عشر دقائق، واختبار انفجار فوري عند 7,000 طلب في الثانية لمدة دقيقة.
اعتمدت معايير الفشل على ثلاثة مؤشرات: ألا تتجاوز أخطاء HTTP من فئة 5xx نسبة 0.01%، وألا يتجاوز زمن استجابة 95% من الطلبات 500 ميلي ثانية، وألا يتجاوز زمن استجابة 99% منها ثانية واحدة. هذه الحدود حولت سؤال «هل المنصة سريعة؟» إلى شروط تشغيلية قابلة للقياس.
بنية متعددة الطبقات ومسار رجوع واضح
اختارت Cloudflare تشغيل EmDash على Cloudflare Worker خلف Workers Cache، مع استخدام ذاكرة كائنات جديدة في EmDash مبنية على Workers KV، وتكامل Hyperdrive مع PlanetScale. وأسهمت طبقات التخزين المؤقت في تقديم 99.5% من الملفات الثابتة من الذاكرة المؤقتة، ونحو 70% من إجمالي الطلبات منها، وفق بيانات الشركة، ما خفف الضغط على قاعدة البيانات.
ولمنع توقف الخدمة أثناء الانتقال، أنشأ الفريق Proxy Worker يوزع الطلبات بين المدونة القديمة والموقع الجديد. وكان يحدد إصدار التجربة عبر ملف تعريف ارتباط، مع إمكانية إعادة الطلبات إلى النظام القديم عند ظهور أخطاء 500 في الموقع الجديد. كما استخدم اتصالاً مباشراً بين Workers عبر ربط الخدمة NEW_BLOG لتجنب المرور باسم نطاق عام وعمليات DNS وTLS واتصال HTTP خارجي.
بدأ الإطلاق التدريجي عند 1% من الحركة، ثم ارتفع إلى 5% و15% قبل الوصول إلى 100% في نهاية اليوم. سمح ذلك بمراقبة الحمل الحقيقي واكتشاف الحالات الطرفية من دون تعريض غالبية القراء لتغيير غير مستقر.
ما الذي تغير عملياً؟
تقول Cloudflare إن البنية الجديدة حافظت على زمن استجابة أكثر استقراراً مقارنة بالمنصة السابقة، مع مكاسب أداء وأخطاء محدودة أثناء خدمة ما يصل إلى 850 طلباً في الثانية. وخلال Agents Week، نُشرت 18 تدوينة خلال تسعة أيام وحققت قرابة 3 ملايين مشاهدة، وخدم Worker الجديد ما يصل إلى 450 طلباً في الثانية من دون مشكلات ملحوظة. كما امتصت حماية DDoS المدمجة هجوماً بلغ 28,000 طلب في الثانية في 10 أغسطس، بحسب الشركة.
شمل التغيير أيضاً الواجهة، التي أعيد بناؤها وفق أنماط نظام التصميم Kumo، مع دعم أصلي للوضعين الفاتح والداكن اعتماداً على تفضيلات النظام ومفتاح تبديل يدوي. ونُقلت دعوة الاشتراك بالبريد الإلكتروني إلى نهاية المقال، وأضيف فهرس «في هذه الصفحة» وخيار «ناقش عبر الإنترنت» لتحسين التنقل والمشاركة.
وأتاحت واجهات EmDash الجديدة ونقاط بحث الذكاء الاصطناعي إنشاء خادم MCP لمدونة Cloudflare خلال بضع ساعات، مع أدوات للبحث عن المنشورات وسردها واسترجاعها وسرد الوسوم. كما يتيح خادم MCP الخاص بـEmDash للكتّاب تصفح المحتوى وإنشاءه وتحريره ونشره وجدولته وإزالة الملفات من دون تكلفة إضافية، وفق المصدر.
تظل تجربة التحرير نفسها غير مكتملة؛ فقد واصلت Cloudflare تسجيل مشكلات صغيرة وأخطاء مرتبطة بالمنشورات المجدولة، وقالت إنها رفعتها إلى فريق EmDash وتتوقع إصلاحها قبل Birthday Week. لذلك لا تقدم الحالة دليلاً على أن المنصة خالية من القيود، لكنها توضح ممارسة قابلة للتطبيق: اختبار مسارات المحتوى قبل الأداء، تحديد عتبات فشل صريحة، بناء مسار رجوع، ثم توسيع النشر تدريجياً بدلاً من تنفيذ انتقال شامل دفعة واحدة.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.