أعادت Atlassian بناء منصة اكتشاف الحوادث التي تغذي نظامها الآلي لإنشاء الحوادث، بالاعتماد على Apache Kafka وApache Flink على Kubernetes وOpenTelemetry. ووفق القياسات المنشورة بعد 18 شهراً من العمل، انخفض زمن وصول الحدث إلى المقياس من أكثر من 40 ثانية إلى أقل من 10 ثوانٍ، بينما ارتفعت القدرة المستدامة من نحو 500 مليون حدث يومياً إلى أكثر من مليار حدث يومياً عند استخدام أخذ عينات بنسبة 50%.
المشروع لا يقدم نفسه كقصة نجاح مكتملة. فقد ارتفعت نسبة استدعاء الحوادث الواقعة ضمن نطاق الرصد من نحو 60% إلى ذروة بلغت 86% في يونيو 2026، قبل أن تهبط إلى 64% في أغسطس. كما بقيت الدقة أقل من المستوى المستهدف، ما دفع الفريق إلى الفصل بين جودة الكاشف نفسه وبين مدى تغطية المنتجات والتجارب التي جرى تجهيزها بالقياس.
منصة مبنية حول تدفق الأحداث
تدير Atlassian أكثر من عشرة منتجات سحابية لملايين المستأجرين، وتنتج هذه المنتجات مليارات الأحداث يومياً من تفاعلات المستخدمين. تتضمن الأحداث بداية المهمة ونتيجتها، مع بيانات عن المستأجر والمستخدم والتجربة ورمز HTTP. وتستخدم المنصة هذه البيانات للإجابة سريعاً عن ثلاثة أسئلة: هل توجد مشكلة؟ ما حجم أثرها؟ ومن الفريق الذي يجب تنبيهه وبأي درجة خطورة؟
في التصميم الجديد، تُرشح الأحداث عند حافلة Apache Kafka بدلاً من استهلاك كامل التدفق داخل التطبيق. ويُحفظ مرشح الاشتراك، البالغ نحو 770 سطراً من YAML، كجزء من الإعدادات البرمجية. ثم يعالج تطبيق واحد من Apache Flink 1.20 الأحداث على Kubernetes، مع إثرائها ببيانات المستأجر، وإرسال المقاييس عبر OpenTelemetry، وتجميع أثر الحوادث في نوافذ مدتها 60 ثانية.
استخدم الفريق Apache Parquet في تخزين الكميات المجمعة، ومخزناً متعدد المناطق للقيم الرئيسية، فيما يوفر Impact API إجابات عن عدد المستخدمين والمستأجرين المتأثرين. ويحوّل محرك AutoHOT التنبيهات إلى حوادث، ويطبق مصفوفة خطورة، ويمنع التنبيهات العابرة، ثم يعيد تقييم الأثر كل دقيقة.
مكاسب الأداء والتكلفة
- انخفض عدد الآلات الافتراضية من نحو 90 آلة، إضافة إلى طبقات الطوابير والتخزين المؤقت، إلى أربع حاويات Kubernetes.
- تراجع التشغيل الشهري من نحو 20 ألف دولار إلى حوالي 650 دولاراً، أي انخفاض يقارب 97%.
- أصبح التعافي من توقف المعالجة ممكناً عبر إعادة تشغيل أحداث Kafka خلال نحو 20 دقيقة من دون فقدان البيانات.
- انخفض زمن استعلام لوحة الأثر من نحو 10 ثوانٍ إلى قرابة ثانية واحدة.
- وصل التطابق مع المسار القديم إلى 99.9% خلال تشغيل متوازٍ دام أسبوعين.
اعتمد التصميم على HyperLogLog لحساب المستخدمين الفريدين المتأثرين بدلاً من حفظ معرفات المستخدمين، مع خطأ يقارب 1.5%. كما استُخدمت مفاتيح تخزين idempotent لجعل إعادة تشغيل Kafka قابلة للتعافي من دون مضاعفة الصفوف. وأبقى الفريق أسماء المقاييس القديمة عبر مسار StatsD، الأمر الذي سمح للوحات SLO والكواشف القائمة بالاستمرار من دون تغيير عند الانتقال.
لماذا لا تكفي أرقام الأداء؟
تكشف نتائج الحوادث أن تسريع خط البيانات لا يساوي بالضرورة تغطية أفضل. خلال تسعة أشهر، وقعت 263 حادثة كبيرة، لكن 117 حادثة فقط، أي 44.5%، أصابت تجارب مجهزة بالرصد. واكتُشفت 80 من هذه الحوادث، ما يعني أن النظام التقط 30.4% فقط من إجمالي الحوادث الكبيرة في تلك الفترة.
كما اختلفت الدقة باختلاف نوع التنبيه. بلغت دقة حوادث Sev2 التي أنشأها النظام آلياً نحو 85% خلال السنة المالية، بينما تراوحت دقة الإنذارات المبكرة الأقل خطورة بين 70% و79%. وأسهم كبح التذبذبات في خفض تذاكر الإنذارات العابرة المرفوضة بنحو 80%. وفي المقابل، أدى تأخر نظام المقاييس إلى اعتبار انخفاض البيانات صفراً، ما ولّد موجة إنذارات كاذبة؛ وعولج ذلك بإضافة تأخير أدنى قدره 120 ثانية على كواشف انخفاض الحجم.
القيود التي بقيت مفتوحة
أكبر مشكلة منطقية هي أن الصمت قد يبدو صحة. فتوقف قاعدة بيانات بالكامل قد يمنع تحميل الصفحة، وبالتالي لا ينتج أحداث فشل أصلاً. كما أن توقف خط الأحداث نفسه قد يجعل الكاشف أعمى. لذلك أضاف الفريق كواشف انخفاض حجم البيانات وفحوص حداثة القياس، ويخطط لضم إشارات مستقلة مثل أخطاء الحافة 5xx والمجسات الاصطناعية.
وجد الفريق أيضاً أن اكتشاف الحادثة وقياس أثرها مشكلتان منفصلتان. ففي إحدى الحوادث أُنشئت التذكرة مبكراً، لكن النظام قدّر الأثر بنحو ألفي مستخدم، بينما تجاوز العدد الحقيقي 80 ألفاً. كما انهارت واجهة Impact API تحت ضغط نحو 100 مستخدم متزامن لأنها كانت تدمج مخططات HyperLogLog عند وقت القراءة من دون تجميع مسبق أو تخزين مؤقت.
وتظل نقطة الضعف الأهم أن بوابة الأحداث واشتراك Kafka ووظيفة Flink تعمل في منطقة واحدة، رغم أن محرك القرار يعمل بنمط نشط-نشط في منطقتين. وهذا يعني أن عطلاً إقليمياً قد يبقي الحوسبة سليمة لكنه يعطل مصدر الاكتشاف نفسه.
القراءة التحريرية من certi.news
القيمة الأساسية في تجربة Atlassian ليست في اختيار Flink أو Kafka منفردين، بل في ربط قرارات البنية بمقاييس تشغيلية قابلة للمراجعة: التصفية عند الحافلة، المفاتيح idempotent، مراقبة المنصة بأدوات OpenTelemetry نفسها، والتمييز بين recall وcoverage. وتوضح النتائج أن تحسين الكفاءة يمكن أن يخفض التكلفة والزمن بوضوح، لكنه لا يعالج تلقائياً فجوات القياس أو الحوادث التي لا تنتج إشارات عميلة.
تخطط Atlassian لنقل الكواشف إلى مخزن السلاسل الزمنية المغذى عبر OpenTelemetry، وتوسيع خط Flink إلى نمط نشط-نشط بين المناطق، وإضافة تجميع يومي وتخزين مؤقت أمام Impact API. كما تستهدف recall ودقة يتجاوز كل منهما 90% ضمن النطاق المجهز بالرصد، مع زمن P90 لاكتشاف حوادث Sev3 أقل من 90 دقيقة. وتبقى هذه أهدافاً مستقبلية وليست نتائج محققة وفق المادة المنشورة.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.