ابتداءً من العام الماضي، بدأت شركتنا في تنظيم فعاليات الهاكاثون. كانت أول مسابقة من هذا القبيل ناجحة للغاية، وكتبنا عنها . أُقيم الهاكاثون الثاني في فبراير 2019 ولم يكن أقل نجاحًا. حول أهداف عقد هذا الأخير منذ وقت ليس ببعيد منظم.
تم تكليف المشاركين بمهمة مثيرة للاهتمام مع الحرية الكاملة في اختيار حزمة التكنولوجيا لتنفيذها. كان من الضروري تنفيذ نظام أساسي لاتخاذ القرار من أجل النشر الملائم لوظائف تسجيل العملاء التي يمكن أن تعمل مع التدفق السريع للتطبيقات، وتتحمل الأحمال الثقيلة، وكان النظام نفسه قابلاً للتطوير بسهولة.
المهمة ليست تافهة ويمكن حلها بعدة طرق، وهذا ما اقتنعنا به خلال عرض العروض النهائية لمشاريع المشاركين. كان هناك 6 فرق من 5 أشخاص في الهاكاثون، وكان لدى جميع المشاركين مشاريع جيدة، ولكن تبين أن منصتنا هي الأكثر تنافسية. لدينا مشروع مثير للاهتمام للغاية، والذي أود أن أتحدث عنه في هذه المقالة.
الحل الذي نقدمه هو نظام أساسي يعتمد على بنية بدون خادم داخل Kubernetes، مما يقلل من الوقت المستغرق لجلب ميزات جديدة إلى الإنتاج. فهو يسمح للمحللين بكتابة التعليمات البرمجية في بيئة مناسبة لهم ونشرها في الإنتاج دون مشاركة المهندسين والمطورين.
ما هو التهديف
Tinkoff.ru، مثل العديد من الشركات الحديثة، لديها نقاط العملاء. التسجيل هو نظام تقييم العملاء يعتمد على الأساليب الإحصائية لتحليل البيانات.
على سبيل المثال، يلجأ إلينا العميل لطلب إصدار قرض له، أو فتح حساب رائد أعمال فردي معنا. إذا كنا نخطط لإصدار قرض له، فنحن بحاجة إلى تقييم ملاءته المالية، وإذا كان الحساب رجل أعمال فردي، فيجب علينا التأكد من أن العميل لن يقوم بإجراء معاملات احتيالية.
أساس اتخاذ مثل هذه القرارات هو النماذج الرياضية التي تحلل البيانات من التطبيق نفسه والبيانات من مخزننا. بالإضافة إلى تسجيل النقاط، يمكن أيضًا استخدام أساليب إحصائية مماثلة في خدمة توليد توصيات فردية للمنتجات الجديدة لعملائنا.
يمكن لطريقة مثل هذا التقييم قبول مجموعة متنوعة من بيانات الإدخال. وفي مرحلة ما يمكننا إضافة معلمة جديدة إلى الإدخال، والتي، بناءً على نتائج التحليل على البيانات التاريخية، ستزيد من معدل التحويل لاستخدام الخدمة.
لدينا ثروة من البيانات حول العلاقات مع العملاء، وحجم هذه المعلومات يتزايد باستمرار. لكي ينجح التسجيل، تتطلب معالجة البيانات أيضًا قواعد (أو نماذج رياضية) تتيح لك أن تقرر بسرعة من سيوافق على الطلب، ومن سيرفض، ومن سيعرض بضعة منتجات أخرى، مع تقييم اهتماماتها المحتملة.
بالنسبة للمهمة التي بين أيدينا، فإننا نستخدم بالفعل نظامًا متخصصًا لاتخاذ القرار ، والتي، بناءً على القواعد التي وضعها المحللون والتقنيون والمطورون، تقرر الموافقة على منتج مصرفي معين أو رفضه للعميل.
هناك العديد من الحلول الجاهزة في السوق، سواء نماذج التسجيل أو أنظمة اتخاذ القرار نفسها. نحن نستخدم أحد هذه الأنظمة في شركتنا. لكن الأعمال التجارية تنمو وتتنوع، ويتزايد عدد العملاء وعدد المنتجات المقدمة، وبالتزامن مع ذلك، تظهر الأفكار حول كيفية تحسين عملية اتخاذ القرار الحالية. من المؤكد أن الأشخاص الذين يعملون مع النظام الحالي لديهم العديد من الأفكار حول كيفية جعله أسهل وأفضل وأكثر ملاءمة، ولكن في بعض الأحيان تكون الأفكار من الخارج مفيدة. تم تنظيم الهاكاثون الجديد بهدف جمع الأفكار السليمة.
مهمة
أقيم الهاكاثون في 23 فبراير. عُرض على المشاركين مهمة قتالية: تطوير نظام صنع القرار الذي يجب أن يفي بعدد من الشروط.
لقد قيل لنا كيف يعمل النظام الحالي وما هي الصعوبات التي تنشأ أثناء تشغيله، بالإضافة إلى الأهداف التجارية التي يجب على النظام الأساسي المطور تحقيقها. يجب أن يتمتع النظام بوقت سريع للتسويق لتطوير القواعد بحيث يدخل كود عمل المحللين إلى مرحلة الإنتاج في أسرع وقت ممكن. وبالنسبة لتدفق الطلبات الواردة، ينبغي أن يميل وقت اتخاذ القرار إلى الحد الأدنى. كما يجب أن يتمتع النظام الذي يتم تطويره بقدرات البيع المتقاطع من أجل منح العميل فرصة شراء منتجات الشركة الأخرى إذا تمت الموافقة عليها من قبلنا ولديها اهتمام محتمل من العميل.
من الواضح أنه من المستحيل كتابة مشروع جاهز للإصدار بين عشية وضحاها، والذي سيدخل بالتأكيد في الإنتاج، ومن الصعب جدًا تغطية النظام بأكمله، لذلك طُلب منا تنفيذ جزء منه على الأقل. تم تحديد عدد من المتطلبات التي يجب أن يفي بها النموذج الأولي. كان من الممكن محاولة تغطية جميع المتطلبات بالكامل، والعمل بالتفصيل على الأقسام الفردية من النظام الأساسي الذي يتم تطويره.
أما بالنسبة للتكنولوجيا، فقد تم منح جميع المشاركين حرية الاختيار الكاملة. كان من الممكن استخدام أي مفاهيم وتقنيات: تدفق البيانات، والتعلم الآلي، وتحديد مصادر الأحداث، والبيانات الضخمة وغيرها.
لدينا الحل
وبعد قليل من العصف الذهني، قررنا أن حل FaaS سيكون مثاليًا لإكمال المهمة.
ولهذا الحل، كان من الضروري إيجاد إطار عمل مناسب بدون خادم لتنفيذ قواعد نظام اتخاذ القرار الذي يجري تطويره. نظرًا لأن Tinkoff تستخدم Kubernetes بشكل نشط لإدارة البنية التحتية، فقد نظرنا إلى العديد من الحلول الجاهزة بناءً عليها، وسأخبرك المزيد عنها لاحقًا.
للعثور على الحل الأكثر فعالية، نظرنا إلى المنتج الذي يتم تطويره من خلال عيون مستخدميه. المستخدمون الرئيسيون لنظامنا هم المحللون المشاركون في تطوير القواعد. يجب نشر القواعد على الخادم، أو، كما في حالتنا، نشرها في السحابة لاتخاذ القرارات اللاحقة. من وجهة نظر المحلل، يبدو سير العمل كما يلي:
- يكتب المحلل برنامجًا نصيًا أو قاعدة أو نموذج تعلم الآلة استنادًا إلى البيانات الواردة من المستودع. كجزء من الهاكاثون، قررنا استخدام Mongodb، لكن اختيار نظام تخزين البيانات ليس مهمًا هنا.
- بعد اختبار القواعد المطورة على البيانات التاريخية، يقوم المحلل بتحميل الكود الخاص به إلى لوحة الإدارة.
- لضمان الإصدار، سيتم نقل جميع التعليمات البرمجية إلى مستودعات Git.
- من خلال لوحة الإدارة، سيكون من الممكن نشر التعليمات البرمجية في السحابة كوحدة وظيفية منفصلة بدون خادم.
يجب أن تمر البيانات الأولية من العملاء عبر خدمة إثراء متخصصة مصممة لإثراء الطلب الأولي بالبيانات من المستودع. وكان من المهم تنفيذ هذه الخدمة بطريقة تعمل مع مستودع واحد (يأخذ منه المحلل البيانات عند تطوير القواعد) للحفاظ على بنية بيانات موحدة.
حتى قبل الهاكاثون، قررنا استخدام إطار العمل بدون خادم. يوجد اليوم عدد كبير جدًا من التقنيات في السوق التي تنفذ هذا النهج. الحلول الأكثر شيوعًا ضمن بنية Kubernetes هي Fission وOpen FaaS وKubeless. هناك حتى .
بعد الموازنة بين جميع الإيجابيات والسلبيات، اخترنا . من السهل جدًا إدارة إطار العمل بدون خادم هذا ويلبي متطلبات المهمة.
للعمل مع الانشطار، تحتاج إلى فهم مفهومين أساسيين: الوظيفة والبيئة. الوظيفة عبارة عن جزء من التعليمات البرمجية مكتوب بإحدى اللغات التي توجد بها بيئة الانشطار. يتضمن Python وJS وGo وJVM والعديد من اللغات والتقنيات الشائعة الأخرى.
الانشطار قادر أيضًا على أداء وظائف مقسمة إلى عدة ملفات، معبأة مسبقًا في أرشيف. يتم ضمان تشغيل الانشطار في مجموعة Kubernetes من خلال حجرات متخصصة، والتي تتم إدارتها بواسطة الإطار نفسه. للتفاعل مع كبسولات المجموعة، يجب تعيين مسار خاص لكل وظيفة، والذي يمكنك من خلاله تمرير معلمات GET أو نص الطلب في حالة طلب POST.
ونتيجة لذلك، خططنا للحصول على حل يسمح للمحللين بنشر نصوص القواعد المطورة دون مشاركة المهندسين والمطورين. يلغي النهج الموصوف أيضًا حاجة المطورين إلى إعادة كتابة كود المحلل إلى لغة أخرى. على سبيل المثال، بالنسبة لنظام اتخاذ القرار الحالي الذي نستخدمه، يتعين علينا كتابة القواعد بتقنيات ولغات عالية التخصص، ونطاقها محدود للغاية، وهناك أيضًا اعتماد قوي على خادم التطبيقات، نظرًا لأن جميع مسودة قواعد البنك يتم نشرها في بيئة واحدة. ونتيجة لذلك، لنشر قواعد جديدة فمن الضروري الافراج عن النظام بأكمله.
في الحل المقترح، ليست هناك حاجة لإصدار القواعد؛ حيث يمكن نشر الكود بسهولة بنقرة زر واحدة. كما تتيح لك إدارة البنية التحتية في Kubernetes عدم التفكير في التحميل والقياس، حيث يتم حل مثل هذه المشكلات خارج الصندوق. كما أن استخدام مستودع بيانات واحد يلغي الحاجة إلى مقارنة البيانات في الوقت الفعلي بالبيانات التاريخية، مما يبسط عمل المحلل.
ما حصلنا عليه
منذ أن أتينا إلى الهاكاثون بحل جاهز (في خيالاتنا)، كل ما كان علينا فعله هو تحويل كل أفكارنا إلى أسطر من التعليمات البرمجية.
مفتاح النجاح في أي هاكاثون هو الإعداد والخطة المكتوبة جيدًا. لذلك، أول شيء فعلناه هو تحديد الوحدات التي ستتكون منها بنية نظامنا وما هي التقنيات التي سنستخدمها.
وكانت بنية مشروعنا على النحو التالي:
يوضح هذا الرسم البياني نقطتي دخول، المحلل (المستخدم الرئيسي لنظامنا) والعميل.
تم تنظيم عملية العمل على هذا النحو. يقوم المحلل بتطوير وظيفة القاعدة ووظيفة إثراء البيانات لنموذجه، ويخزن الكود الخاص به في مستودع Git، وينشر نموذجه على السحابة من خلال تطبيق المسؤول. دعونا نفكر في كيفية استدعاء الوظيفة المنشورة واتخاذ القرارات بشأن الطلبات الواردة من العملاء:
- يقوم العميل بملء نموذج على الموقع وإرسال طلبه إلى المراقب. يأتي التطبيق الذي يجب اتخاذ قرار بشأنه إلى مدخلات النظام ويتم تسجيله في قاعدة البيانات في شكله الأصلي.
- بعد ذلك، يتم إرسال الطلب الأولي للتخصيب، إذا لزم الأمر. يمكنك استكمال الطلب الأولي بالبيانات من الخدمات الخارجية ومن التخزين. يتم أيضًا تخزين الاستعلام المعزز الناتج في قاعدة البيانات.
- يتم تشغيل وظيفة المحلل، والتي تأخذ استعلامًا غنيًا كمدخل وتنتج حلاً يتم كتابته أيضًا على وحدة التخزين.
قررنا استخدام MongoDB كمخزن في نظامنا بسبب تخزين البيانات الموجه نحو المستندات في شكل مستندات JSON، نظرًا لأن خدمات الإثراء، بما في ذلك الطلب الأصلي، قامت بتجميع جميع البيانات من خلال وحدات تحكم REST.
لذلك، كان لدينا XNUMX ساعة لتنفيذ المنصة. قمنا بتوزيع الأدوار بنجاح تام، حيث كان لكل عضو في الفريق مجال مسؤوليته الخاصة في مشروعنا:
- لوحات إدارية أمامية لعمل المحلل، يستطيع من خلالها تنزيل القواعد من نظام التحكم في إصدار النصوص المكتوبة، وتحديد خيارات لإثراء بيانات الإدخال وتحرير نصوص القواعد عبر الإنترنت.
- مسؤول الواجهة الخلفية، بما في ذلك REST API للواجهة الأمامية والتكامل مع VCS.
- إعداد البنية التحتية في Google Cloud وتطوير خدمة إثراء البيانات المصدرية.
- وحدة نمطية لدمج تطبيق الإدارة مع إطار العمل بدون خادم للنشر اللاحق للقواعد.
- نصوص قواعد اختبار أداء النظام بأكمله وتجميع التحليلات على التطبيقات الواردة (القرارات المتخذة) للعرض النهائي.
لنبدأ بالترتيب.
تمت كتابة الواجهة الأمامية لدينا بلغة Angular 7 باستخدام مجموعة أدوات واجهة المستخدم المصرفية. تبدو النسخة النهائية من لوحة الإدارة كما يلي:
نظرًا لضيق الوقت، حاولنا تنفيذ الوظيفة الأساسية فقط. لنشر وظيفة في مجموعة Kubernetes، كان من الضروري تحديد حدث (خدمة تحتاج إلى نشر قاعدة لها في السحابة) ورمز الوظيفة التي تنفذ منطق اتخاذ القرار. لكل عملية نشر لقاعدة الخدمة المحددة، قمنا بكتابة سجل لهذا الحدث. في لوحة الإدارة، يمكنك رؤية سجلات جميع الأحداث.
تم تخزين جميع أكواد الوظيفة في مستودع Git البعيد، والذي يجب أيضًا تعيينه في لوحة الإدارة. لإصدار الكود، تم تخزين جميع الوظائف في فروع مختلفة من المستودع. توفر لوحة الإدارة أيضًا القدرة على إجراء تعديلات على البرامج النصية المكتوبة، بحيث لا يمكنك فقط التحقق من التعليمات البرمجية المكتوبة قبل نشر وظيفة الإنتاج، ولكن أيضًا إجراء التغييرات اللازمة.
بالإضافة إلى وظائف القواعد، قمنا أيضًا بتنفيذ القدرة على إثراء بيانات المصدر تدريجيًا باستخدام وظائف الإثراء، والتي كان رمزها أيضًا عبارة عن نصوص برمجية يمكن من خلالها الانتقال إلى مستودع البيانات، والاتصال بخدمات الجهات الخارجية وإجراء الحسابات الأولية . لتوضيح الحل الذي نقدمه، قمنا بحساب علامة البروج للعميل الذي ترك الطلب وحددنا مشغل الهاتف المحمول الخاص به باستخدام خدمة REST التابعة لجهة خارجية.
تمت كتابة الواجهة الخلفية للنظام بلغة Java وتم تنفيذها كتطبيق Spring Boot. لقد خططنا في البداية لاستخدام Postgres لتخزين بيانات الإدارة، ولكن كجزء من hackathon، قررنا أن نقتصر على H2 بسيط لتوفير الوقت. على الواجهة الخلفية، تم تنفيذ التكامل مع Bitbucket لإصدار وظائف إثراء الاستعلام والبرامج النصية للقواعد. للتكامل مع مستودعات Git البعيدة، استخدمنا ، وهو نوع من الأغلفة لأوامر CLI، مما يسمح لك بتنفيذ أي تعليمات git باستخدام واجهة برمجية ملائمة. لذلك كان لدينا مستودعين منفصلين لوظائف وقواعد الإثراء، وتم تقسيم جميع البرامج النصية إلى أدلة. من خلال واجهة المستخدم، كان من الممكن تحديد الالتزام الأخير لبرنامج نصي لفرع عشوائي من المستودع. عند إجراء تغييرات على التعليمات البرمجية من خلال لوحة الإدارة، تم إنشاء التزامات التعليمات البرمجية التي تم تغييرها في المستودعات البعيدة.
لتنفيذ فكرتنا، كنا بحاجة إلى بنية تحتية مناسبة. قررنا نشر مجموعة Kubernetes الخاصة بنا في السحابة. كان خيارنا هو Google Cloud Platform. تم تثبيت إطار عمل Fission بدون خادم على مجموعة Kubernetes، والتي قمنا بنشرها في Gcloud. في البداية، تم تنفيذ خدمة إثراء البيانات المصدر كتطبيق Java منفصل مغلف في Pod داخل مجموعة k8s. ولكن بعد العرض التوضيحي الأولي لمشروعنا في منتصف الهاكاثون، أوصينا بجعل خدمة الإثراء أكثر مرونة لإتاحة الفرصة لاختيار كيفية إثراء البيانات الأولية للتطبيقات الواردة. ولم يكن لدينا خيار سوى جعل خدمة الإثراء أيضًا بدون خادم.
للعمل مع Fission، استخدمنا Fission CLI، والذي يجب تثبيته أعلى Kubernetes CLI. يعد نشر الوظائف في مجموعة k8s أمرًا بسيطًا للغاية؛ تحتاج فقط إلى تعيين مسار داخلي والدخول إلى الوظيفة للسماح بحركة المرور الواردة إذا كان الوصول خارج المجموعة مطلوبًا. لا يستغرق نشر وظيفة واحدة عادةً أكثر من 10 ثوانٍ.
العرض النهائي للمشروع وتلخيصه
لتوضيح كيفية عمل نظامنا، قمنا بوضع نموذج بسيط على خادم بعيد حيث يمكنك تقديم طلب لأحد منتجات البنك. للطلب، كان عليك إدخال الأحرف الأولى من اسمك وتاريخ الميلاد ورقم الهاتف.
انتقلت البيانات من نموذج العميل إلى وحدة التحكم، التي أرسلت في نفس الوقت طلبات لجميع القواعد المتاحة، بعد أن قامت مسبقًا بإثراء البيانات وفقًا للشروط المحددة، وحفظتها في مخزن مشترك. في المجمل، قمنا بنشر ثلاث وظائف لاتخاذ القرارات بشأن التطبيقات الواردة وأربع خدمات لإثراء البيانات. بعد تقديم الطلب، تلقى العميل قرارنا:
بالإضافة إلى الرفض أو الموافقة، تلقى العميل أيضًا قائمة بالمنتجات الأخرى، التي أرسلنا طلباتها بالتوازي. هذه هي الطريقة التي أظهرنا بها إمكانية البيع المتبادل في منصتنا.
كان هناك إجمالي 3 منتجات مصرفية وهمية متاحة:
- تنسب إليه.
- لعبة
- القرض العقاري.
أثناء العرض التوضيحي، قمنا بنشر وظائف معدة ونصوص إثرائية لكل خدمة.
تتطلب كل قاعدة مجموعتها الخاصة من بيانات الإدخال. لذلك، للموافقة على الرهن العقاري، قمنا بحساب علامة زودياك العميل وربطها بمنطق التقويم القمري. للموافقة على اللعبة، تأكدنا من أن العميل قد بلغ سن الرشد، ولإصدار القرض، أرسلنا طلبًا إلى خدمة خارجية مفتوحة لتحديد مشغل الهاتف الخلوي، وتم اتخاذ القرار بشأنه.
لقد حاولنا أن نجعل عرضنا مثيرًا للاهتمام وتفاعليًا، ويمكن لجميع الحاضرين الذهاب إلى النموذج الخاص بنا والتحقق من توفر خدماتنا الخيالية لهم. وفي نهاية العرض التقديمي، أظهرنا تحليلات الطلبات المستلمة، والتي أظهرت عدد الأشخاص الذين استخدموا خدمتنا، وعدد الموافقات، والرفض.
لجمع التحليلات عبر الإنترنت، قمنا أيضًا بنشر أداة ذكاء الأعمال مفتوحة المصدر وثبته في وحدة التخزين الخاصة بنا. تتيح لك قاعدة التعريف إنشاء شاشات تحتوي على تحليلات للبيانات التي تهمنا؛ كل ما تحتاجه هو تسجيل اتصال بقاعدة البيانات، وتحديد الجداول (في حالتنا، مجموعات البيانات، منذ أن استخدمنا MongoDB)، وتحديد المجالات التي تهمنا .
ونتيجة لذلك، حصلنا على نموذج أولي جيد لمنصة صنع القرار، وخلال العرض التوضيحي، يمكن لكل مستمع التحقق من أدائه شخصيًا. الحل المثير للاهتمام والنموذج الأولي النهائي والعرض التوضيحي الناجح سمح لنا بالفوز، على الرغم من المنافسة القوية من الفرق الأخرى. أنا متأكد من أنه يمكن أيضًا كتابة مقال مثير للاهتمام حول مشروع كل فريق.
المصدر: www.habr.com