"لا يوجد رئيس هنا": حول العمل مع Open Source و Apache Ignite في Sberbank Technologies

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

بمرور الوقت ، كان Sbertech نشطًا بشكل متزايد في مجتمع OSS ، وقررنا أن نسألهم عن ذلك. كيف تتحد الخصوصية المصرفية الصارمة مع روح الحرية مفتوحة المصدر؟ ما هي متطلبات المصادر المفتوحة التي قد لا تمتلكها الشركات الأخرى؟ هل هناك أي موظفين في Sbertech يكتبون المصادر المفتوحة كمهام عملهم الرئيسية؟ ما هي خططك ورغباتك المستقبلية؟ أخبرنا أنطون شورايف ، الذي يشرف على Free & Open Source ، عن كل هذا وأكثر.



أوليغ: مرحبًا أنتون. دعونا نقدم لك الخبروفيت قليلاً. أخبر نفسك: من أنت ، ماذا تفعل؟

أنطون: أنا مهندس ، مع ذلك ، يتطور فقط في أوقات فراغه. الآن أنا تبني في ممارسات وكفاءات Sbertech لتطوير وتطبيق منتجات مجانية ومفتوحة المصدر. عليك أن تفهم أن هذه أشياء مختلفة قليلاً.

- نعم ، أفهم ، عدة مرات عندما تحدثت مع Stallman دعوت Free as Open وبعد ذلك استمعت إلى محاضرة تذكرتها مدى الحياة :-) حسنًا ، ما هو موقفك؟

- أمين تطوير المصدر الحر والمفتوح. ومتحمس المصدر المفتوح :)

- هل يمكنك فك شفرة أكثر قليلاً عن "الكفاءات لتنفيذ المصدر المفتوح"؟ يبدو وكأنه نوع من المعرفة السرية.

- قليل من الناس يتصورون ما يعنيه المصدر المفتوح للشركات. من ناحية ، هذه هي الابتكارات وغياب الحاجة إلى تطوير السلع ، والتركيز على المزايا التنافسية لمنتجاتها ، وإعادة استخدامها وخفض التكاليف. غالبًا ما تكون هذه مشروعات أصبحت بالفعل معايير الصناعة. خذ نفس Hadoop - الجميع يعرفه ، الجميع يعرفه ، لقد كان معيارًا منذ فترة طويلة. أو أكثر قواعد البيانات شيوعًا - أهم خمس منتجات هي ثلاثة مصادر مفتوحة المصدر - MySQL و PostgreSQL و MongoDB.

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

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

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

- والثاني؟

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

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

- ما هي التراخيص التي تحبها؟

- أكاديمي.

- يا! لنكن أكثر تحديدًا. هناك MIT / BSD ، وما إلى ذلك ، وهناك تراخيص الحقوق المتروكة للفيروسات مثل Affero GPL. أي من هؤلاء؟

- حسنا جيد. لا يمكنك أن تحب أو لا تحب الترخيص. تم صنع المنتج لمهمة محددة وسيتم استخدامه بطريقة محددة. عند استخدام المصدر المفتوح ، تكون مهمتك هي التأكد من أنك تقدم منتجك أو خدمتك دون انتهاك حقوق الأطراف الثالثة. في هذه الحالة ، بالطبع ، يمكنك استخدام الحقوق المتروكة (على سبيل المثال ، GPL) ، إذا تأكدت من استخدامها حتى لا تنتهك القيود وحقوق أي شخص آخر. بالطبع ، هناك صعوبات أقل عند استخدام التراخيص الأكاديمية ، وذلك ببساطة لأنها تحمل قيودًا أقل وبالتالي يسهل اتباعها. باختصار ، أسمي MIT "الأكاديمي" ، BSD ، Apache ، إلخ.

- حسنًا ، هل يجب على المطورين العاديين التعامل مع أمن المعلومات؟ أم أنها مخصصة لقسم منفصل؟

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

"من الواضح أن حراس الأمن هؤلاء يعرفون كل شيء." وما الذي يحتاج المطور العادي إلى معرفته في هذا الصدد؟ ما هي النقاط الأساسية؟

- نموذج التهديدات وحماية القنوات وحماية البيانات. ما هو عرضة للتهديدات: ربما تكون هذه واجهة مستخدم أو نقل بيانات عبر شبكة (يتم توزيع كل شيء معنا ، لذا فهذه مشكلة مهمة جدًا). الأدوات الأساسية مثل التشفير و SSL و TLS والمصادقة والتفويض ومعالجة الرمز المميز وما إلى ذلك. لست بحاجة لمعرفة الكثير.

- تقول الشائعات أن لديك أي علاقة بـ Apache Ignite :-)

- من حيث المساهمة ، هذا هو المشروع الرئيسي الذي أعمل عليه حاليا. تنتمي المشاركة في Apache Ignite إلى مهمتي الثانية - لضمان استثمار متوازن في مشاريع مجانية ومفتوحة المصدر. وهذا يعني كلا من الاستخدام المختص للمنتجات (من الواضح أن استخدام المكتبات هو استثمار ، فنحن ، كمستخدمين ، نزيد من جاذبية المنتج) ، بالإضافة إلى التطوير والمساهمة.

بالنسبة لي ، ربما ، هذه المهمة أكثر أهمية. نشيد بتلك المنتجات التي نستخدمها في شركتنا ، وبفضلها قمنا ببناء الكثير من المنتجات والأنظمة. نحن نحاول تحسينها والتأكد من إمكانية استخدامها في شركات مثل شركتنا: لتحسين ، وتحقيق حالة المؤسسة.

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

- كثير من الناس يعرفون أن Sbertech يستخدم GridGain ، وأنت تتحدث عن Apache Ignite. ما الفرق بين الاثنين؟

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

- بما أن Ignite مفتوح ، يمكنك التحدث عنه قليلاً ، أليس كذلك؟ هل تستغلها فقط أو تفعل شيئًا لإنهائها ، والتفاعل مع المطورين؟

- نقوم بتعديله بشكل مكثف. يتم تحديد اتجاهات المهام بوضوح ، على سبيل المثال ، ضمان الأداء مع مراعاة تفاصيل Sberbank: على نطاق واسع ، محيط البيانات ، نشاط تشغيلي مرتفع. لذلك ، يجب أن تكون سريعة وكثير. أعني بهذا الكمون والإنتاجية.

والثاني هو ضمان الموثوقية ، أي التوافر والتسامح مع الخطأ.

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

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

بشكل منفصل ، هناك مهمة القضاء على الديون والعيوب التقنية (الموجودة دائمًا). ربما يمكن أن يعزى إلى الموثوقية.

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

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

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

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

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

- واحدة من الحالات الأكثر إثارة للاهتمام التي أخبرتها Sbertech علنًا هي الطبقة الدلالية الدلالية. كمية ضخمة من البيانات تنتشر عبر شبكة داخل الذاكرة. كيف أثر ذلك على الجزء المفتوح من Ignite وما مدى إثارة هذه التطورات للمجتمع؟

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

- بقدر ما أتذكر ، فإن بنية المجموعة هي حلقة. أي عندما ننضم إلى الحلقة ، في البداية نذهب إلى المنسق ثم نذهب على طول الحلقة حتى نجد الذيل. والمزيد من العناصر ، والمزيد من الوقت ، أليس كذلك؟

"نعم ، نوعًا ما." في الوقت نفسه ، مع زيادة عدد العقد في الهيكل ، يزداد حجم الرسائل التي يتم إرسالها على طول الحلقة وعدد الانتقالات بين المشاركين. هذا لا يعني أن الخاتم قرار سيئ ، ولكنه في بعض الحالات لا يصلح. لذلك ، منذ نهاية عام 2017 ، نحن في المجتمع ننهي إدارة الطوبولوجيا بحيث يمكن للمستخدمين اختيار مخطط إدارة الطبولوجيا: حلقة (أحيانًا تناسبها تمامًا) أو نجمة على Zookeeper.

- ومن أين أتى الخاتم؟ لماذا؟ أين هي مثالية؟

- يعد هذا حلاً رائعًا على طوبولوجيا 100-200 عقد في مركز بيانات واحد. يسمح لك بمزامنة جميع العقد ببساطة وموثوقية ، يتم ترتيبها فقط. إذا ذهبنا إلى النجم ، فسيبدأون في العمل بالتوازي وأسرع ، ولكن في نفس الوقت تصبح مزامنتهم أكثر صعوبة. أي أن الحلقة يمكن أن تكون أكثر استقرارًا وموثوقية ، توافق؟

"نعم بالطبع." ولكن هل يمكن القيام بذلك بحيث يمكن تغيير هذا الهيكل بواسطة بعض المعلمات في التكوين ، كيف الإعداد؟

- نعم ، نحن نقوم بذلك الآن ، نحن نضمن كلا الطبولوجيا في الإصدار. ربما ، لا تغطي عمليات التنفيذ المقترحة بالفعل جميع حالات المستخدمين ، وبمجرد ظهور تطبيقات جديدة ، سنحاول ضمان معالجتها الفعالة.

- بقدر ما أفهم ، هذه مراجعة معقدة إلى حد ما. وهذه المراجعة تتم من قبل الناس في سبرتخ خلال ساعات العمل أو في المساء من أجل المتعة؟

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

- حسنًا ، هؤلاء هم الأشخاص الذين يحلون مشكلة أثناء ساعات العمل ، ولكن في نفس الوقت هم أعضاء في المجتمع.

- نعم ، الجزء الأكثر أهمية من عمل المطورين لدينا يحدث في المجتمع. لكنني أرى أيضًا من رفاقنا مثل هذه الالتزامات التي ظهرت في ساعة أو ليلتين أو ثلاث ليال.

- وهؤلاء الموظفين لن يواجهوا مشكلة من حقيقة أنهم يعملون في بنك ، على نظام مغلق ، ويلتزمون في نفس الوقت بمصدر مفتوح؟

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

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

- بالحديث عن مشروع Apache Ignite ، خلال الربع الأخير ، بلغت مساهمتنا في المشروع 8-10٪ من جميع التغييرات ، ونحن نسعى لزيادة هذه النسبة. لقد كتبنا كثيرًا ، وهذا ليس فقط تطوير وتحسين الوظائف الحالية ، بل نعمل أيضًا على وظائف جديدة للمشروع. هذا تحدٍّ للمجتمع ، ومسؤوليتنا ، إذ أنه بعد ضمه ، فإن المجتمع إلى حد ما لديه مهمة دعمه.

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

- لكن دعنا نقول ، كانت هناك عدة تقارير من برنامج سبرتخ من PRPRB بشأن "فنغ شوي الخاص". هل أحتاج إلى كتابة أي أدوات وصفحات إدارية إضافية لدعم ذلك؟

- واجهات التشغيل تتطور باستمرار. تعد وحدة التحكم الإدارية في Oracle نفسها أكثر دراية للحفاظ على وظائف أكثر. ما إذا كان يلزم إعادة إنتاجه بالكامل هو سؤال آخر.

- وفي شكل مفتوح ، يمكنك رؤية وحدة تحكم الإدارة؟

"نعم بالطبع." تم نشر وحدة تحكم الويب ، Visor ، CLI - كل شيء عام.

- وإذا نظرت إليها عالميًا ، فما هي الاتجاهات والأهداف العامة؟

- الآن نحن أكثر تركيزًا على تطوير Apache Ignite ، الذي يلبي أولويات الشركة. لكن مجموعتنا التكنولوجية لا تنتهي عند هذا الحد. Open Source , , . , , . ( ), , . . , . . .

— , . - ?

— — , availability, durability, fault tolerance ..

— , .

— , — . , Open Source . . , .

— - , , ? , - , ceph?

— , ceph — . , , , .

— - ? ?

— OpenStack.

— , OpenStack — , . - , , ?

— OpenStack , , , Cloud Foundry, .

— ?

— :-) , ( ) . , — , , .

— .

— , - Open Source .

, . , , -.

— -?

— , , , -: , .. , , , , . . , Open Source, , , .

. , . -, , . . , , , .

, , ( -, , , ) — . , , , .

— .

— , . , «», , « , » «, ». , . , , . , , , . — , .

— , ? , … , , .

— . , , , , . , , ( ). , , , .
, , - .
Open Source . , . . , .

— ? ?

— , . , , – . — , ROI, .., .

— , - . , : , . , - Spring Hibernate, , , , . , , , . , .

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