كيفية القضاء على القلق وتقليل وقت الاستجابة للحوادث وإبقاء النفقات ضمن الميزانية منذ بدأ عملي في مجال التكنولوجيا عام 1992، تعرضت للعديد من السيناريوهات التي كانت تتطلب مني "القيام بالمزيد مع القليل". سواء كان ذلك يعني تسليم المزيد من الأعمال بفريق أقل عددًا أو العمل ضمن موارد Hardware محدودة، فإن هذا التفكير كان موضوعًا مستمرًا. واحدة من تجاربي البارزة كانت عندما كنت معماريًا خلفيًا في مشروع تحديث السحابة. للحد من التكاليف، طُلب منا تقليل أو إلغاء سجلات الخدمة (Service-Level Logging) التي كنا نعتمد عليها بشدة في تضييق الأخطاء وتحليل الحوادث. كان القرار مدفوعًا بارتفاع تكلفة امتصاص السجلات (Log Ingestion) على منصة الرصد (Observability Platform). حققنا النجاح حتى فشلنا في البداية، نجحت هذه الاستراتيجية. ولكن عندما ظهرت مشكلة غير متوقعة، اكتشفنا أننا بحاجة إلى تلك السجلات المفقودة. كانت هذه السجلات هي الطريقة الوحيدة لتحديد السبب الجذري للمشكلة. بدونها، مر الوقت دون حل، وزادت الشكوك والقلق على الفريق بأكمله. كان بإمكاننا بقاء سجل بسيط ومُهيكل للأخطاء (مثل المثال أدناه) يمكن فلترته بسهولة في منصة السجلات باستخدام استعلام بسيط (مثل الاستعلام أدناه) مما يساعدنا على فهم وتشخيص وإصلاح المشكلة. json { "timestamp": "2025-03-21T14:05:03Z", "service": "preference-engine", "level": "ERROR", "message": "Worker queue overflow: unable to dispatch to worker pool", "requestId": "abc123", "userId": "admin_42" } استعلام السجلات: _sourceCategory=prod/preference-engine "Worker queue overflow" | count by userId, requestId الادخار لا يعني الجوع للموارد يجب أن تكون واضحة أن فكرة "القيام بالمزيد مع القليل" ليست سيئة بطبيعتها. العديد من الشركات الناشئة تزدهر من خلال التركيز على الأولويات الرئيسية واستخدام برامج خفيفة وكفؤة. يمكن أن يؤدي التصميم البسيط إلى جودة أفضل، شريطة أن تظل الأدوات الأساسية في مكانها. لكن هذا لم يكن النوع الجيد من الادخار. كان لدينا موعد نهائي ثابت للانتقال إلى السحابة، حيث كنا نتسابق ضد تاريخ إلغاء المتصفح. هذا يعني إعادة كتابة الخدمات لتكون متوافقة مع السحابة، والتنسيق مع الفرق العميلة، والتسليم تحت الضغط. كنا نعتمد على السجلات لحل المشاكل وتحديد السبب الجذري للسيناريوهات غير المتوقعة. هذا كان جيدًا في البداية، حيث أدخلنا السجلات اللازمة أثناء العمل على كل طريقة. ولكن عندما تم تقليص السجلات، أصبح الفريق مكشوفًا. فقدت شبكتنا الأمنة الأولى. تحديد السبب الجذري بدون شبكة أمان الاختبارات الداخلية ذهبت بشكل جيد. مع اقتراب الإنتاج، كنا واثقين من هندستنا السحابية الجديدة. لقد حللنا المشاكل المعروفة في الاختبار وتلبينا الموعد النهائي. لكننا أدركنا قريبًا أن ثقتنا كانت خاطئة وأن تغطيتنا للاختبارات كانت ناقصة. بمجرد انتقالنا إلى الإنتاج وبدء العملاء الحقيقيين في استخدام المنصة، بدأت الحالات الحدية غير المتوقعة في الظهور. بدون سجلات مفصلة أو رصد كافٍ، لم يكن لدينا أي طريقة لمعاينة المشكلة. لم تكن البيانات المحدودة المتوفرة كافية لتحديد ما حدث. لو كان لدينا سجلات لكل من الاختبارات الخلفية والعملاء الأماميين، لعلمنا بما يحدث وأبلغنا الفريق (والعميل). لكن بدون السجلات، كان من المستحيل تقريبًا إعادة إنتاج الحوادث محليًا بسبب التباين الكبير في حالات الاستخدام الواقعية. حاولنا إعادة تفعيل السجلات جزئيًا، لكن هذا أدى مرة أخرى إلى زيادة تكلفة الامتصاص دون تقديم معلومات قابلة للتنفيذ. في بعض الحالات، لم نتمكن من تحديد السبب الجذري على الإطلاق. هذا وضع غاية في الصعوبة: معرفة وجود مشكلة تؤثر على العملاء ولكن عدم القدرة على تفسيرها. خلق هذا شعورًا شائعًا بالعجز في جميع أنحاء الفريق. MTTR مقابل جودة الإشارة كان هناك مشكلة أخرى وهي أن في تحليلات الحوادث، كان يتم التعامل مع الوقت المتوسط ​​للاستعادة (Mean Time to Recovery - MTTR) كمؤشر رئيسي. ولكن اكتشفنا أن MTTR غالبًا ما يكون مجرد عرض وليس سببًا جذريًا. عادةً ما تظهر مقاييس الصناعة أن الفرق المتقدمة تحقق MTTR في أقل من ساعة. ولكن ما أدركناه هو أن السرعة ليست مجرد تلقائية — بل هي إشارات عالية الدقة. لا تساعد الإشارات منخفضة الدقة، مثل الأخطاء العامة 500 أو تأخير الإشعارات من مقاييس المجموع، حقًا. فهي تضيف فقط الغموض وتضيع الموارد (مثل الوقت الثمين للتقييم والميزانية للسجلات). بالمقابل، تقطع الإشارات المفصلة والساياقية، مثل السجلات المهيكلة التي تحتوي على userId، requestId، وأثر الخدمة، مباشرة إلى السبب الجذري. يمكن أن تقلل منصات الرصد من MTTR، ولكن فقط إذا كانت البيانات التي تقوم بامتصاصها قابلة للتنفيذ. إذا لم تقدم سجلاتك إجابة لهذه الأسئلة، فإن MTTR ليس يتعلق بسرعة الفريق — بل بوضوح الإشارة. كيف كان يمكن أن ينقذنا نموذج Sumo Logic ما الذي يمكن أن يكون مختلفًا وأفضل في مشروع تحديث السحابة الخاص بي؟ كنا بحاجة إلى أدوات أفضل للتحليلات السجلية ومراقبة أداء التطبيق (Application Performance Monitoring - APM). بالإضافة إلى ذلك، كنا بحاجة إلى إدارة السجلات، مراقبات الخدمة، إشعارات، ومقاييس محددة ترتبط بنجاح الوظائف. كانت رغبتي في كل مشروع هي أن يكون لكل ميزة جديدة مقاييس مرتبطة بنجاحها. وكنت أرغب في استعادة سجلاتي! في مقال سابق لي بعنوان "DevSecOps: حان الوقت لدفع ثمن الطلب الخاص بك، وليس الامتصاص"، استكشفت كيف أحدثت Sumo Logic ثورة في مجال الرصد من خلال تقديم نموذج الدفع مقابل التحليل. يمكن امتصاص السجلات باستمرار، ولكنك تدفع فقط عند الحاجة إلى استعلام أو تحليل. هل أنت فريق بدون تغطية كاملة لاختبارات الوحدات؟ هل تعاني من نقص الإشعارات الفورية أو المقاييس الدقيقة؟ هل أنت على ميزانية محددة؟ هل تشعر بالجوع من نقص السجلات؟ مع امتصاص مجاني تمامًا، يمكن للفرق تسجيل ما يحتاجون إليه دون قلق. وعندما يحدث الحادث أخيرًا (وهو سيحدث)، يمكن تشغيل التحليل عند الطلب، بتكلفة معقولة ترتبط مباشرة بتأثير العميل أو استمرارية الأعمال. هذا يجعل المسؤولين عن الميزانية سعداء، وكذلك أنت. ولكن انتظري: تحتاج أيضًا إلى تriage مساعدة الآلة لتنظيف استعلاماتك لكن هناك خطوة أخرى. الرصد الحديث ليس مجرد الحصول على كل تلك البيانات الجميلة للسجلات — بل أيضًا معرفة أين تنظر في هذه البيانات. كما ذكرت سابقًا، تحتاج إلى إشارات عالية الدقة ومنظمة. عندما يكون لديك امتصاص غير محدود، تكون لديك كمية كبيرة من البيانات. عند بدء البحث عن المعلومات، تحتاج إلى نقطة بداية. لمساعدتك، تقدم Sumo Logic أدوات تriage مساعدة الآلة تجمع تلقائيًا السلوك الشاذ، تحدد القيم الشاذة، وتظهر الإشارات المرتبطة عبر الخدمات قبل كتابة استعلام واحد. في الخلفية، تستخدم Sumo Logic خوارزميات إحصائية وتعلم الآلة ل: تجميع بيانات السجل المزعجة في مجموعات قابلة للتنفيذ (Log Signatures). تقليص الأنماط التي تمثل مجموعات الأحداث المرتبطة. مثال على العمليات: _sourceCategory=prod/* error | logreduce هذا الأمر الوحيد يصنف بيانات السجل المزعجة في مجموعات مثل: Error: Worker queue overflow Error: Auth token expired for user * Error: Timeout in service * بعد التجميع، يمكن للفرق التحول إلى سياق أعمق: | where message matches "Auth token expired*" | count by userId, region النتيجة؟ بحث أقل دون وجه، طرق قرار أسرع، قلق أقل خلال الحادث. الخلاصة فلسفة "القيام بالمزيد مع القليل" لا يجب أن تضع الفرق الهندسية في موقع عائق. لكن يجب أن تكون مصحوبة بالأدوات الصحيحة. بدون هذه الأدوات، يمكن أن يشعر حتى أكثر الفرق قدرة بأنهم يتنقلون عشوائيًا خلال الحادث، مما يؤدي إلى الإحباط والضغط. تذكر قراءي معيتي الشخصية: "ركز وقتك على تقديم ميزات/وظائف تزيد من قيمة الملكية الفكرية الخاصة بك. استفد من الإطارات البرمجية والمنتجات والخدمات في كل شيء آخر." في هذا المقال، ناقشنا كيف يمكن أن يساعد نموذج امتصاص الصفر الكلفة في تحقيق هذا الهدف. فهو يساعد الفرق على تحديد الأسباب الجذرية بسرعة، تقليل وقت التوقف، وخفض مستويات الضغط — كل ذلك دون تجاوز الميزانية. دعونا نحتفظ بتلك السجلات! تعتبر Sumo Logic شركة رائدة في مجال الرصد، حيث تقدم حلولًا متكاملة تساعد الفرق الهندسية في إدارة البيانات بكفاءة وفعالية. نموذج الدفع مقابل التحليل الذي تقدمه يسمح للفرق بتخزين البيانات دون تكبد تكاليف كبيرة، ثم استخدامها عند الحاجة بتكاليف مبررة.