How We Mapped a 35-Million-Line Mainframe in 4 Days - Stephen Chin, Neo4j & Neeraj Deshmukh, Blitzy

لدينا جلسة مثيرة للغاية من أجلكم. ربما لا تدركون حجم الأنظمة والبنية التحتية التي تدير التمويل الحديث، وكل ما يحدث في الحي المالي بمدينة نيويورك، والتي تعتمد على أنظمة قديمة جداً تحتاج إلى الكثير من التحديث. ربما تتفاعلون معها عبر هواتفكم المحمولة ، ربما تستخدمون تطبيقات البنوك، لكنكم لا تدركون أن هناك قواعد عمل، ومهام دفعية تعمل ليلاً، وعقود بيانات مختلفة تعمل في الخلفية. وهي تعمل على بنية تحتية يخشى الناس بصراحة لمسها، أليس كذلك؟ إذا أجريت تغييراً بسيطاً في سطر واحد من الكود، فإنك تخاطر بكسر النظام بالكامل. وهذه حقيقة ممتعة عن نفسي. فأنا الآن معروف بعملي في علاقات المطورين، ومؤتمرات الذكاء الاصطناعي، وتأليف الكتب.

قبل 30 عاماً، كنت مطور "جافا" أقوم بنقل كود "كوبول" من الحواسيب المركزية، وأحاول معرفة كيفية تحديث التطبيقات. كانت مشاريع تستغرق سنوات، وعملاً شاقاً للغاية حيث تصادف حتماً أخطاءً ومشاكل صغيرة. لم يكن بإمكانك اختبارها بدقة كافية لتغطية جميع الحالات الاستثنائية، وكانت مشاريع صعبة للغاية وغالباً ما كانت تفشل. لذا، أعتقد أن ما سنعرضه لكم اليوم مذهل لأنه مسار جديد للأمام، حيث يمكنك قيادة التغيير والقيام بذلك بالفعل، ولكن لِمَ لا تخبرنا قليلاً عن كيفية عمل هذا يا نيراج؟ >> شكراً لك يا ستيف. حسناً، سنقوم بذلك من خلال مثال، أليس كذلك؟ في سياق نظام تجريبي عام طورته أمازون قبل بضع سنوات. هذا هو عرض بطاقات AWS التوضيحي.

وسنأخذ مثالاً محدداً هنا حيث نحاول حساب الفائدة، أليس كذلك؟ وكما ترون في هذا المخطط الصغير، لدينا مهمة دفعية تستدعي برنامج الفائدة الذي يحصل على ملفات التعريف والتخطيطات، ثم ينشئ بيانات VSAM بشكل أساسي، أليس كذلك؟ وهكذا، المخرجات هنا هي أموال، وبالطبع تعتمد النتيجة على المدخلات، والوظيفة التي تشغلها، وتحديثات الحساب، وليس فقط صيغة حساب الفائدة، أليس كذلك؟ لذا، دعونا نتذكر هذا المثال. سنعود إليه باستمرار، وسنركز على هذا الموضوع مراراً وتكراراً بينما نتقدم في حديثنا. لذا، عندما أريد تحديث هذا وأطلب من الذكاء الاصطناعي تغيير تلك الصيغة من " كوبول" إلى "جافا"، فكل ما سيفعله هو العثور على الصيغة ومحاولة تحويلها، أليس كذلك؟ ما لا تجده هو دقة السجل، وتحديثات الحساب، ومخرجات المعاملة، وعقد الدفعة.

وإذا فاتك أي من هذه، فلن تضمن الحصول على النتائج الصحيحة. إذن، الفشل هنا ليس في أن الذكاء الاصطناعي لا يستطيع كتابة الكود. بل في أن الذكاء الاصطناعي لا يعرف المواقع الأربعة عشر الأخرى التي يُستخدم فيها ذلك المنطق أو ذلك الكود. >> حسناً، وهذا يبدو مخيفاً بعض الشيء. أعني ، بالإضافة إلى عدم معرفة الذكاء الاصطناعي للكود، ذلك الأنبوب يبدو وكأنه على وشك الانفجار. >> أجل، وبالطبع، لا يعرف الذكاء الاصطناعي أن ذلك سيحدث في أي لحظة الآن. إذاً، يا ستيفن، قد تعتقد أن توسيع السياق سيحل هذه المشكلة. لماذا لا يحدث ذلك؟ >> أجل. أعتقد أن أحد الأمور التي تحدث عنها مقدم العرض السابق قليلاً هو كيف اعتمدنا جميعاً على نماذج أفضل، وعلى امتلاك أنظمة أفضل، وأنظمة ذكاء اصطناعي أفضل لحل هذا. وبصراحة، لم ينجح الأمر مع هذه الأنواع من حالات الاستخدام والسبب هو السياق. يمكنك استخدام قواعد بيانات المتجهات للحصول على وتوسيع سياقك، لكن كل ما تقدمه لك هو عمليات بحث عن التشابه. يمكنك استخدام قواعد البيانات العلائقية أيضاً، وهذا يمنحك مستودعاً أكبر بكثير. يمكنك ربطها بخادم MCP، لكن مرة أخرى، أنت محدود بنوع من القفزة الواحدة والبحث عن الحقائق والمعلومات عبر استعلامات SQL. ما يمنحك إياه الرسم البياني هو معلومات سياقية دقيقة ومتعددة القفزات لنموذجك.

والسبب في أهمية هذا السياق هو أن نموذجك لا يمكنه تقديم النتائج الصحيحة لأنه لا يستطيع الاستفادة من سياقه الخاص. لذا، فإن معظم النماذج في الوقت الحاضر يتم الإعلان عنها بنوافذ سياق تصل إلى مليون رمز (token). لكن ما مقدار السياق القابل للاستخدام الذي تحصل عليه فعلياً؟ والواقع هو أنك تحصل على 200 ألف أو أقل من السياق القابل للاستخدام، أليس كذلك؟ تشير الدراسات إلى أن الدقة تنخفض بشكل كبير كلما زدت ملء السياق، وهذا يعني أنه يجب عليك تقديم سياق دقيق وصحيح. >> أجل، السياق الفعال هذه الأيام يبلغ حوالي 20 إلى 30%، مما يعني حوالي 200 إلى 300 ألف سطر من الكود. إذا كان برنامجك أكبر من ذلك، فهذا مؤسف. ستبدأ في فقدان المعلومات. >> السياق تسلسلي، لكن المعلومات لها علاقات . المعلومات لها روابط بينها. وهذا هو المفتاح لكيفية ترتيب بياناتك بشكل صحيح.

>> أجل. أعني هنا، الكود يصبح رسماً بيانياً ، أليس كذلك؟ يمكنك رؤية كل هذه العلاقات التي يتم تعيينها هنا الآن. آه، و مثل، البرنامج موجود هناك. يتضمن المهمة التي تنفذه، ونسخ الكتاب التي يتم تضمينها، وما إلى ذلك، والمخرجات. الجزء المهم هنا هو الأشياء الموجودة على اليمين. إذًا، كل حافة في الرسم البياني تحتفظ بهويتها، أليس كذلك؟ من أين جاءت في المستودع؟ ما هو إصدارها؟ ما هي الرموز التي تلمسها؟ هناك دليل للملف ولنطاق المصدر، وكيف تم استخراجه. ويستمر تحديث الرسم البياني مع كل دمج؛ فبمجرد تغير الكود، يتغير الرسم البياني أيضًا. وبهذه الطريقة تحافظ على حداثته، وتجعله جاريًا ، وتبطل الأشياء التي لم تعد صالحة. >> نعم، ويمكنك أن ترى أن الكود يمثل إلى حد كبير مشكلة ذات شكل بياني. فقط من خلال البنية والعلاقات، إنه شيء يحتوي على الكثير من الترابطات. أم، ماذا عن أن تتحدث عن كيفية عمل هذا بالنسبة للوكلاء؟ >> بالتأكيد. لذا، كل وكيل في "بيتسي" لديه حزمة سياق مهمة محددة، أليس كذلك؟ وهذا يتضمن ما هو وصف المهمة، وأيضًا إلى أين تنتمي في ذلك الرسم البياني، أليس كذلك؟ هناك شريحة من المصدر. أليس كذلك؟ ما هي القيود التي فرضتها، وما هي الأدلة المتاحة لديها، وما هي الأسئلة التي لم

تتم الإجابة عليها بعد والتي يُفترض أن يعمل الوكيل عليها الآن. آه، وهذا ما نعنيه بسياق الكود اللانهائي، أليس كذلك؟ الأمر لا يتعلق بتذكر كامل المعلومات في قاعدة الكود الخاصة بك، في أصول برمجياتك . يتعلق الأمر أساسًا بالوصول إلى المعلومات الصحيحة في الوقت المناسب، وفي المكان المناسب. لذا، تعمل "بيتسي" بفعالية كمترجم لكامل المعرفة في المؤسسة، أليس كذلك؟ تبدأ بالهندسة العكسية لأصول البرمجيات بأكملها . تستخرج منطق الأعمال، وسير العمل، والتبعيات المخفية. ثم تحصل على المتطلبات والقواعد من المستخدم لتقول، ماذا تريد أن تفعل بهذا؟ وتحول ذلك إلى خطة عمل قابلة للتنفيذ للوكيل، أليس كذلك؟ هذه هي المواصفات التي ستستخدمها لإجراء ذلك التغيير المستقبلي. لاحظ الكتلة التالية هناك، يوجد موافقة بشرية، أليس كذلك؟ لا يحدث شيء بدون وجود إنسان يتولى القيادة ويتخذ القرارات في كل نقطة رئيسية، أليس كذلك؟ ولكن بمجرد مراجعة الخطة والموافقة عليها من قبل الإنسان، ينطلق الوكلاء للقيام بإنشاء الكود. ولكن هناك أيضًا تحقق مدمج في كل خطوة. تتمثل النتيجة النهائية في الحصول على تعليمات برمجية مختبرة وموثقة في شكل طلب سحب، بالإضافة إلى وثائق إثبات لما تم إنجازه وكيفية

التحقق منه في شكل دليل للمشروع. لذا توجد موافقة بشرية في كل خطوة مهمة. ولأن لديك حق الوصول إلى المستودع بالكامل ، وتمتلك أيضاً التعليمات الخاصة بكيفية بناء البيئة وتشغيل الكود، فأنت لست مقيداً بمعلومات ثابتة فقط. يمكنك فعلياً مراقبة سلوك وقت التشغيل وإجراء التغييرات وفقاً لذلك. إذاً، الرسم البياني المعرفي هو المحرك الأساسي لكل هذا، أليس كذلك؟ لكن هذا ليس الشيء الوحيد الذي يساعد هنا. هناك أمران آخران يضاعفان من الأثر الذي يحدثه هذا. الأول هو التنسيق فائق النطاق. فنحن نمتلك آلاف الوكلاء الذين يتشاركون جميعاً في هذه الخطة. كل وكيل لديه حق الوصول إلى السياق الفعلي ولا يضيع أي شيء بينهم. أضف إلى ذلك التحقق الشامل، أليس كذلك؟ تتم عمليات الاختبار في كل مرحلة من مراحل إنشاء الكود. نحن في الواقع ننفق موارد حوسبة على الاختبار أكثر مما ننفقه على إنشاء الكود. وهذا يؤدي إلى كود آمن تماماً للإنتاج، تمت تجربته والتحقق منه على مستوى المؤسسة، لذا من الآمن دمجه في أنظمة الإنتاج الخاصة بك.

إذاً، خطة عمل الوكيل هي المواصفات، أليس كذلك؟ تلك هي الخطة قبل البدء في أي عمل فعلي، وهي تحدد النطاق، وما الذي سيتم تحويله، وما يجب الحفاظ عليه، أليس كذلك؟ ويقوم خبير في المجال، أي إنسان، بمراجعة ذلك والتأكد من توافقه مع توقعاتهم والموافقة عليه، وهذا يقترن بضوابط أربعة متأصلة في كل خطوة. هناك سياق على مستوى النظام، وهو الرسم البياني المعرفي الذي تحدثنا عنه، أليس كذلك؟ كل تغيير يؤثر على النظام بأكمله، لذا يجب أن يكون الجميع على دراية بذلك، أليس كذلك؟ هناك تحقق مستمر. أي اختبار ثم اختبار ثم اختبار، أليس كذلك؟ لا يوجد بديل لذلك. لديك حواجز حماية واضحة لمعالجة متطلبات الأمن والحوكمة والامتثال الخاصة بك. هذه أمور متأصلة في أي صناعة خاضعة للتنظيم وبالطبع في القطاع المالي، أليس كذلك؟ ثم يأتي دور الإنسان في القيادة لأن القرارات المهمة يتخذها أشخاص حقيقيون. الذكاء الاصطناعي لا يتخذها بشكل مستقل.

وهذا بالطبع يحافظ على السلوكيات، أليس كذلك؟ يجب نقل السلوكيات الحالية كما هي إلى الكود المحدث، فكيف يمكنك التحقق من ذلك؟ بالضبط. في هذه الحالة، نحن نريد الحفاظ على الأموال مثل الدقة والتقريب. نحن نريد الحفاظ على الحالة، والأرصدة، وسجلات المعاملات، والإخفاقات، والعمليات، وكل شيء، أليس كذلك؟ إذا كانت لدينا عيوب، فيجب أيضًا إدارتها بقرارات صريحة. يجب الحفاظ على القواعد أيضًا، وعليك إثبات التكافؤ. لا يمكنك اعتبار الأمر مجرد افتراض أو وعد. لذا، الطريقة التي نقوم بها بذلك هي إجراء اختبار على خط الأساس. هناك اختبار مماثل يحدث على النظام الحديث ، ونحن ننظر إلى المدخلات والمخرجات، والقيم المرجعة، وما هي الحالات التي يتم حفظها، وكيف تبدو مخرجات المعاملة، أليس كذلك؟ ما هي نتائج الأخطاء؟ ليس فقط المسار السعيد، بل كيف تتعامل مع المواقف السيئة؟ ويجب أن تتطابق كل هذه الأمور تمامًا في سياق كل عملية، ولا يجب أن تكون هناك أي اختلافات.

هذا هو وعدنا بتقديم ذلك. إذن هذه طبقة، أليس كذلك؟ هذا لا يحدث فقط في النهاية. هذا متأصل في نسيج توليد الكود نفسه. كل سطر كود يتم توليده يتم بناؤه واختباره باختبارات الوحدة. يجب تجميع البناء. تكامل وقت التشغيل، يجب أن يتناسب مع الإطار الحالي الذي لديك. يجب أن يكون تكافؤ بياناتك موجودًا في كل عملية كتابة، ويجب أن يكون سير العمل من البداية إلى النهاية متطابقًا. إذن هذا رمز من أحد العملاء حيث قمنا بذلك بالفعل ، أليس كذلك؟ تنتج الوظيفة المحولة مخرجات متطابقة تمامًا بايت مقابل بايت مع خط أساس الحاسوب المركزي الذهبي. هذا من شركة تأمين ضمن قائمة فورتشن 100. إليك مثال ممتع. >> هذا شيء يمكنني الخوض فيه كمطور جافا قديم حيث ارتكبنا الكثير من الأخطاء مع الأعداد العشرية الكبيرة والتقريب في تنفيذنا. إذن يمكن للذكاء الاصطناعي القيام بذلك بشكل أفضل، أليس كذلك؟ >> صحيح. أعني أنك قد تعتقد ذلك، أليس كذلك؟ لأنك تستطيع حساب نسخة جافا من هذه الصيغة لحساب الفائدة، أليس كذلك؟ كوبول يتصرف بشكل مختلف عن جافا. تحتوي جافا على تقريب للأعلى متأصل فيها. ما يعنيه ذلك هو أن الكود الحديث يتم تجميعه، ويولد نتائج تعتقد أنها صحيحة لأنه يتصرف مثل كود جافا العادي، أليس كذلك؟ لكن لديك هذا الاختلاف البسيط بمقدار سنت واحد الذي حدث بسبب التقريب المتأصل. لو لم يكن لديك اختبار

التكافؤ هذا، لما اكتشفت هذا الأمر. والآن تخيل حدوث هذا عبر مليون معاملة. أمر ممتع . كان ذلك مجرد مثال بسيط، أليس كذلك؟ لكن الآن يمكنك التفكير في محرك تداول كامل حيث يتم تطبيق هذا عبر سير العمل بأكمله. هذا شيء فعلناه لبنك من المستوى الأول حيث كان لدينا نظام متجانس يحتوي على إجراءات مخزنة ووصول للكتابة عبر قواعد بيانات متعددة. تم تحويل ذلك إلى ست وحدات وظيفية باستخدام PostgreSQL و Java و TypeScript و Python، وهي حزمة برمجية حديثة بالكامل وبمستوى تكافؤ تام. أليس كذلك؟ وقد استغرق الأمر 18 يوماً فقط، في حين كانت خطتهم الأصلية تخصيص 18 أسبوع عمل هندسي لهذا المشروع. أليس كذلك؟ كان هذا يتم بالطريقة البشرية التقليدية. ومع Blitzz، تم تقليص المدة إلى 18 يوماً. أليس كذلك؟ لقد كتبنا أكثر من 4000 اختبار. كان الكود البرمجي الحديث أقل من نصف حجم الحزمة القديمة و كان العميل سعيداً. لا شك في إمكانية استخدام Blitzz لتحديث النظام بأكمله، هذا ما قالوه. مثال آخر، تعيين نظام حاسوب مركزي (Mainframe) مكون من 35 مليون سطر برمجي. هذا شيء أنفقوا عليه مع شركة تكامل أنظمة حوالي ثمانية أشهر وعدة ملايين من الدولارات دون نتائج ملموسة. قامت Blitzz

بالهندسة العكسية لذلك في غضون أربعة أيام ، وإليك ما قالوه. لقد كانوا في غرفة مظلمة ومعهم مصباح يدوي يفحصون كل وحدة على حدة. أما Blitzz فتشبه تشغيل الضوء الساطع ورؤية الغرفة بأكملها دفعة واحدة. هذا ما يمكن أن يفعله الذكاء الاصطناعي المدعوم بطبقة معرفية من أجلك. مثال آخر، قمنا بتحديث نظام متجانس مكون من 25 مليون سطر برمجي. كان هذا نظاماً لإدارة السياسات. مرة أخرى، مقارنة بالعمل البشري المدعوم بالذكاء الاصطناعي، كانت أدوات الوكيل المعتمدة على بيئة التطوير ( IDE) ستستغرق وقتاً معيناً. لقد أنجزنا ذلك أسرع بتسع مرات. تم إنجاز 85%من الكود بشكل مستقل. وما يقرب من 90%منه وصل إلى مرحلة الإنتاج. يمتد هذا إلى أنظمة مختلفة وشركات مختلفة. طالما أنك تفهم النظام بأكمله قبل تغييره باستخدام الذكاء الاصطناعي، فأنت في أمان. ولا يتوقف الأمر عند التحديث فحسب، أليس كذلك؟ في نهاية المطاف، التحول هو الهدف. بريدج (Bridge) ليست مجرد منصة للتحديث. بل هي منصة للتحول. يمكنك القيام بتطوير منتجات جديدة . يمكنك إضافة ميزات جديدة. يمكنك القيام بمعالجة الثغرات الأمنية والكشف عنها.

تُفتح جميع أنواع حالات الاستخدام عندما يكون لديك هذا النطاق بالكامل متاحاً لك. وبالعودة إلى عرض البطاقة التوضيحي، بعد أن قمت بتحديثه، قد ترغب في إضافة ميزة جديدة، مثل سعر ترويجي لمسار الفائدة، أليس كذلك؟ أنت تمتلك بالفعل مسار المعرفة المطور الآن لأنك تمتلك النظام الحديث. لقد تم تحديث طبقتك المعرفية. لقد رسخت قواعد الحوكمة الخاصة بك. لقد قمت بتوسيع مجموعة الاختبارات الخاصة بك. لذا أصبح هذا الآن أسهل بكثير وأسرع وأقل تكلفة مما كان عليه من قبل. ثم يمكنك تجاوز نطاق الكود لتوسيع هذا النوع من المعرفة وتطبيقه على حالات جديدة ، كحالات الاستخدام التي توفر أدلة جاهزة للتدقيق ومسائل الامتثال. كما ترون، هذا يتجاوز مجرد البرمجيات ليرسم خارطة عمل الشركة بالكامل الآن.

>> نعم، أعتقد أن بإمكانكم رؤية قوة بناء طبقة مؤسسية حديثة فوق رسم بياني معرفي. الأمر يبدأ برسم بياني، ثم بناء قواعد وعمليات العمل، مما يتيح لك إنشاء أنظمة متكاملة لا تحل فقط مشكلة التحديث، بل تمنحك أيضًا إمكانيات لتوسيع أعمالك. يمكنك الآن إجراء، على سبيل المثال، امتثال "دورا" على نظامك بالكامل للتأكد من تلبيته للمتطلبات التنظيمية. يمكنك تتبع تغييرات قواعد العمل. يمكنك كشف الاحتيال المالي وبناء حالات استخدام تتعقب أنواعًا أخرى من المشكلات، ويمتد هذا إلى أبعد من ذلك حيث يمكنك تطوير نظامك وتحقيق المزيد من القيمة منه. نود أن نترك لكم بعض المراجع لتستفيدوا منها. أحدها هو مؤتمر "نودز"، وهو رمز الاستجابة السريعة على اليسار، ويقدم 24 ساعة كاملة من الجلسات التعليمية حول الرسوم البيانية المعرفية وكيفية تطبيق هذه المفاهيم في أنظمتك الخاصة. ونيراج، هل تود الحديث عن >> نعم، "ساندبوكس"، وهو رمز الاستجابة السريعة على اليمين، سيسمح لك بإدخال الكود الخاص بك ورؤية ذلك بنفسك. لا تأخذوا كلامنا على محمل التسليم فقط.

يمكنكم أيضًا الاطلاع على العرض التوضيحي لتحديث بطاقات AWS الذي عرضناه هنا كمثال . >> حسنًا، شكرًا جزيلاً لانضمامكم إلى جلستنا في مدينة نيويورك. وإذا كانت لديكم أي أسئلة أخرى، فلا تترددوا في زيارة جناح Neo4j أو التحدث إلينا بعد العرض. شكرًا لكم. >> شكرًا جزيلاً لكم.