في هذه الصفحة
المقدمة
هنشوف في المقال ده ازاي فريق المهندسين في Meta اشتغلوا على انهم يسرعوا من عملية التحقيق في مشاكل الـ System Reliability باستخدام نظام جديد مدعوم بالـ AI عشان يحددوا الـ Root Cause بتاع المشكلة.
النظام ده بيستخدم خليط ما بين "heuristic-based retrieval" و "large language model-based ranking" عشان يسرع عملية تحديد السبب الجذري أثناء التحقيقات. ومن خلال اختبار النظام، فريق المهندسين في Meta لقى إنه وصل لدقة بتوصل لـ 42% في تحديد الأسباب الجذرية للتحقيقات وقت ما بتبدأ علطول، خصوصًا المشاكل المتعلقة بالـ "web monorepo".
والـ الـ heuristic-based retrieval هو أسلوب بيستخدم قواعد وإرشادات معينة، أو ما يُسمى بالـ "heuristics"، عشان يسهل عملية البحث والتصفية في كميات كبيرة من البيانات أو التغييرات. الفكرة الأساسية في الـ "heuristics" هي إنها مش بتعتمد على الدقة المطلقة، ولكنها بتعتمد على تقنيات سريعة وفعالة لتقليل مساحة البحث بشكل كبير، حتى لو أدى ده لتقليل دقة بسيطة في النتائج.
فالتحقيق في المشاكل حاجة أساسية عشان نضمن استقرار النظام، وده ضروري عشان نحل المشاكل بسرعة. فعشان كده Meta بتستثمر في تطوير أدوات التحقيق بتاعتها زي أداة "Hawkeye" اللي بيستعملوها داخليًا عشان يعملوا "debugging" للـ Workflows الخاصة بالـ machine learning.
شكل الـ Investigations في Meta
كل تحقيق بيكون مختلف عن التاني، ولكن مما لاشك فيه أن تحديد السبب الجذري للمشكلة هو ضروري جدًا عشان نعرف نحل المشكلة بطريقة صحيحة وسليمة. فالتحقيق في المشاكل اللي بتحصل في أنظمة معتمدة على الـ "monolithic repositories" بيكون صعب من ناحية الـ Scalability بكل تأكيد، وده عشان بيبقى فيه عدد كبير من التغييرات من فرق مختلفة. بالإضافة لكده، الأشخاص اللي بيحلوا المشكلة محتاجين يبنوا فكرة عن المشكلة عشان يبدأوا يشتغلوا عليها، زي إيه اللي اتعطل، الأنظمة اللي متأثرة، والناس اللي ممكن تتأثر بالمشكلة. فلازم يكون معاهم Context واضح عشان يقدروا يفهموا طبيعة المشكلة اللي بيتعاملوا معاها.
التحديات دي بتخلي عملية التحقيق في الـ (anomalies) معقدة وممكن تاخد وقت طويل. فالـ AI بيوفر فرصة لتبسيط العملية دي، وتقليل الوقت اللي محتاجينه، وكمان مساعدة الأشخاص اللي بيحققوا في المشكلة يقدروا ياخدوا قرارات بشكل أفضل. فهم ركزوا على بناء نظام قادر على تحديد التغييرات في الكود اللي ممكن تكون السبب الجذري لمشكلة معينة.
Root Cause Isolation
النظام بيستخدم "heuristics-based retriever" جديد، قادر إنه يقلل مساحة البحث من آلاف التغييرات لعدد قليل من مئات التغييرات من غير ما يقلل الدقة بشكل كبير، زي مثلاً استخدام "code and directory ownership" أو استكشاف "runtime code graph" للأنظمة المتأثرة. فبعد ما بيقللوا مساحة البحث لعدد قليل من التغييرات المهمة للتحقيق الجاري، بيعتمدوا وقتها على نظام "LLM-based ranker" عشان يحدد السبب الجذري وسط التغييرات دي كلها ويختزلهم لعدد بسيط مكون من 5 Candidates يدوروا فيهم.
تقدروا دلوقتي تشتركوا في النشرة الأسبوعية لاقرأ-تِك بشكل مجاني تمامًا عشان يجيلكوا كل جديد بشكل أسبوعي فيما يخص مواضيع متنوعة وبشروحات بسيطة وسهلة وبجودة عالية 🚀
النشرة هيكون ليها شكل جديد ومختلف عن شكلها القديم وهنحاول انها تكون مميزة ومختلفة وخليط بين المحتوى الأساسي اللي بينزل ومفاجآت تانية كتير 🎉
Eqraatech - اقرأ-تِك
بفضل الله قمنا بإطلاق قناة اقرأ-تِك على التليجرام مجانًا للجميع 🚀
آملين بده اننا نفتح باب تاني لتحقيق رؤيتنا نحو إثراء المحتوى التقني باللغة العربية ، ومساعدة لكل متابعينا في انهم يوصلوا لجميع أخبار اقرأ-تِك من حيث المقالات ومحتوى ورقة وقلم والنشرة الأسبوعية وكل جديد بطريقة سريعة وسهلة
مستنينكوا تنورونا , وده رابط القناة 👇
وطبعا مما لا شك فيه أن الـ LLM Ranker اللي بعتمدوا عليه هو مبني في الأساس باستعمال LLAMA Model عشان يقللوا من مساحة البحث لأقل عدد ممكن يقدروا يدوروا فيه.
