"यहाँ कोई बॉस नहीं है": Sberbank Technologies में Open Source और Apache Ignite के साथ काम करने के बारे में

"ओपन सोर्स" शब्दों में, कई लोग या तो एक उत्साही लगते हैं जो शाम को अपने पसंदीदा प्रोजेक्ट, या एक छोटी सी कंपनी में काम करते हैं जो एक खुले उत्पाद का समर्थन करके पैसा कमाता है। लेकिन अगर आप केवल उनके बारे में सोचते हैं, तो आप समुदाय के एक महत्वपूर्ण और दिलचस्प खंड को याद करेंगे। एक बार "उद्यम" और "ओपन सोर्स" शब्द विलोम प्रतीत होते थे, लेकिन अब बड़े निगम न केवल सक्रिय रूप से ओएसएस-परियोजनाओं का उपयोग करते हैं, बल्कि वे स्वयं उनके लिए योगदान करेंगे।

समय के साथ, Sbertech OSS समुदाय में तेजी से सक्रिय हो गया है, और हमने उनसे इसके बारे में पूछने का फैसला किया है। सख्त बैंकिंग विशिष्टता स्वतंत्रता के खुले स्रोत की भावना के साथ कैसे जोड़ती है? ओपन सोर्स के लिए क्या आवश्यकताएं हैं जो अन्य कंपनियों के पास नहीं हो सकती हैं? क्या Sbertech में कोई कर्मचारी हैं जो खुले स्रोत को अपने मुख्य कार्य कार्यों के रूप में लिखते हैं? भविष्य के लिए आपकी क्या योजनाएं और इच्छाएं हैं? एंटोन चुरेव , जो नि: शुल्क और मुक्त स्रोत की देखरेख करते हैं, ने हमें यह सब और अधिक के बारे में बताया।



ओलेग: हाय एंटोन। आइए आपको थोड़ा-बहुत खाबरोवियों से मिलवाते हैं। अपने बारे में बताएं: आप कौन हैं, क्या कर रहे हैं?

एंटोन: मैं एक इंजीनियर हूं, जो अपने खाली समय में ही विकसित होता है। अब मैं फ्री और ओपन सोर्स उत्पादों के विकास और अनुप्रयोग के लिए Sbertech प्रथाओं और दक्षताओं में निर्माण कर रहा हूं। आपको यह समझने की जरूरत है कि ये थोड़ी अलग चीजें हैं।

- हां, मैं समझता हूं, एक-दो बार जब स्टेलमैन के साथ बात करते हुए मैंने फ्री को ओपन कहा था और उसके बाद मैंने ऐसा व्याख्यान सुना, जो मुझे जीवन भर याद रहे :-): खैर, आपकी स्थिति क्या है?

- फ्री एंड ओपन सोर्स के विकास का क्यूरेटर। और खुला स्रोत उत्साह :)

- क्या आप "ओपन सोर्स के कार्यान्वयन के लिए दक्षताओं" के बारे में थोड़ा और डिकोड कर सकते हैं? यह किसी तरह का गुप्त ज्ञान लगता है।

- कुछ लोग कल्पना करते हैं कि निगमों के लिए ओपन सोर्स का क्या मतलब है। एक ओर, ये नवाचार हैं और कमोडिटी विकसित करने की आवश्यकता का अभाव है, अपने उत्पादों के प्रतिस्पर्धी लाभों पर ध्यान केंद्रित करें, पुन: उपयोग करें और लागत को कम करें। अक्सर ये ऐसी परियोजनाएं हैं जो वास्तव में उद्योग के मानक बन गए हैं। एक ही हडोप को लें - हर कोई इसे जानता है, हर कोई इसे जानता है, यह लंबे समय से एक मानक है। या सबसे आम डेटाबेस - शीर्ष पांच तीन खुले स्रोत उत्पाद हैं - MySQL, PostgreSQL और MongoDB।

लेकिन कुछ लोग सोचते हैं कि OpenSource का उपयोग करने में बहुत सी छिपी हुई लागतें शामिल हैं। यह कहना नहीं है कि हमने कुछ खुला स्रोत पाया और हमारी सभी समस्याओं को हल कर दिया। उदाहरण के लिए, "कानूनी स्वच्छता" के बारे में बड़े सवाल हैं। विक्रेता सॉफ़्टवेयर के साथ काम करते समय, सब कुछ बहुत स्पष्ट है: मैंने एक लाइसेंस लिया, आप इस पर काम करते हैं और समर्थन का उपयोग करते हैं। ओपन सोर्स के साथ काम करते समय, डेवलपर्स और उपयोगकर्ताओं की दया पर बहुत कुछ छोड़ दिया जाता है। इस मामले में, कानूनी और कानूनी मुद्दे पहले स्थानों में से एक हैं। इसके अलावा, रूस में बारीकियां हैं। यदि दुनिया भर में बौद्धिक संपदा की अवधारणा काफी विकसित है और हर कोई समझता है कि यह बहुत महत्वपूर्ण है कि एक विशिष्ट स्वामी है, तो रूस में ऐतिहासिक रूप से सब कुछ अलग तरीके से निकला। यहां हम बौद्धिक संपदा से इतने सावधान और सम्मान से नहीं हैं, हालांकि यह बेहद गलत है। और यदि आप ओपन सोर्स के उपयोग की "स्वच्छता" सुनिश्चित नहीं कर सकते, तो आप इसके उपयोग की गुणवत्ता सुनिश्चित नहीं कर सकते।

- क्या मैं स्पष्ट कर सकता हूं? रूस में जीपीएल लाइसेंस की कानूनी स्थिति क्या है? उदाहरण के लिए, जीपीएल स्थानीय कानूनों में संशोधन की अनुमति नहीं देता है और क्षेत्रीय प्रतिबंधों को इंगित नहीं करता है। इसलिए, इस तरह का एक समझौता रूसी संघ के क्षेत्र में स्थापित कानूनी शासन के अनुकूल नहीं है, और यह बहुत, बहुत बुरा है।

- मैं लाइसेंस को कुछ जोन में नहीं बांटना चाहता। Sberbank एक वैश्विक कंपनी है, इसलिए सॉफ्टवेयर का उपयोग संयुक्त राज्य अमेरिका और यूरोपीय संघ दोनों में किया जा सकता है। और, जैसा कि मैं इसे समझता हूं (मैं एक वकील नहीं हूं, लेकिन मेरे सर्वोत्तम ज्ञान के लिए), के क्षेत्र में कॉपीराइट धारक के लाइसेंस के प्रतिबंधों के उल्लंघन के मामले में, उदाहरण के लिए, यूएसए, हम यूएसए के कानूनों के तहत जिम्मेदार होंगे। इसे देखते हुए, आपको अधिकारों को हासिल करने और दूसरे की बौद्धिक संपदा के लिए आवश्यकताओं को पूरा करने में बहुत सावधानी बरतने की आवश्यकता है। उन लेखकों का सम्मान करें जिन्होंने हमें अपने काम का उपयोग करने की अनुमति दी, जिसके कारण हमने त्वरित, अनुकूलित समाधान, हमारी समस्याओं को हल किया और अंततः हमारे ग्राहकों को गुणवत्ता सेवा प्रदान की। आइए अधिकारों और आवश्यकताओं का अनुपालन करें। यह पहला काम है।

- और दूसरा?

- दूसरा कार्य सूचना सुरक्षा है। यह स्पष्ट है कि अधिकांश लाइसेंस में एक डिस्क्लेमर होता है जिसमें कहा जाता है कि लेखक / डेवलपर / योगदानकर्ता इस सॉफ़्टवेयर के संचालन के कारण होने वाले संभावित नुकसान के लिए ज़िम्मेदार नहीं है। यह सही है, यह एक जिम्मेदारी है जो उपभोक्ता को हस्तांतरित करता है और उससे परिपक्वता की आवश्यकता होती है। सब कुछ मुफ्त नहीं है।

आपको इस जिम्मेदारी के लिए भुगतान करना होगा और निश्चित रूप से, इन जोखिमों के साथ काम करना चाहिए। सभी कंपनियां ऐसा नहीं कर सकती हैं। हमारे पास सूचना सुरक्षा का बहुत मजबूत विभाग है - हम भाग्यशाली हैं। इसलिए, हम सामान्य रूप से कमजोरियों और दुर्भावनापूर्ण कोड की उपस्थिति के बारे में गंभीर हैं। हर कोई जो ओपन सोर्स का उपयोग करने की योजना बना रहा है, उसे सभी जोखिमों को ध्यान में रखना चाहिए - न केवल कानूनी, बल्कि सूचना सुरक्षा के मामले में भी।

- आपको कौन से लाइसेंस पसंद हैं?

- शैक्षणिक।

- ओ! चलो और अधिक विशिष्ट हो। MIT / BSD इत्यादि है, और Affero GPL की तरह वायरस कॉपीलेफ्ट लाइसेंस हैं। इनमें से कौन?

- अच्छा, अच्छा। आप किसी लाइसेंस से प्यार या नापसंद नहीं कर सकते। उत्पाद एक विशिष्ट कार्य के लिए बनाया गया है और एक विशिष्ट तरीके से उपयोग किया जाएगा। ओपन सोर्स का उपयोग करते समय, आपका काम यह सुनिश्चित करना है कि आप तीसरे पक्ष के अधिकारों का उल्लंघन किए बिना अपना उत्पाद या सेवा प्रदान करें। इस मामले में, यदि आप उनके उपयोग को सुनिश्चित करते हैं, तो निश्चित रूप से, आप कॉपीलेफ्ट्स (उदाहरण के लिए, जीपीएल) का उपयोग कर सकते हैं, ताकि वे प्रतिबंधों और किसी और के अधिकारों का उल्लंघन न करें। बेशक, शैक्षणिक लाइसेंस का उपयोग करते समय कम कठिनाइयां होती हैं, केवल इसलिए कि वे कम प्रतिबंधों को ले जाते हैं और इसलिए उनका पालन करना आसान होता है। संक्षेप में, मैं "अकादमिक" MIT, BSD, Apache, इत्यादि कहता हूं।

- ठीक है, क्या सामान्य डेवलपर्स को सूचना सुरक्षा से निपटना पड़ता है? या यह एक अलग विभाग को आवंटित किया गया है?

- सभी डेवलपर्स को सूचना सुरक्षा की मूल बातें और उनके सिस्टम के लिए इसकी सुरक्षा के सिद्धांतों को समझना चाहिए। लेकिन हमारे मामले में, हम व्यक्तिगत डेवलपर्स के साथ काम करते हैं जो सूचना सुरक्षा के लिए खतरों के विशेषज्ञ हैं। इसके अलावा, हम न केवल खुले स्रोत उत्पादों के विश्लेषण के लिए, बल्कि एल्गोरिदम और डिजाइन समाधानों के विश्लेषण के लिए भी उनकी ओर मुड़ते हैं।

"यह स्पष्ट है कि ये विशेष सुरक्षा गार्ड सब कुछ जानते हैं।" और इस संबंध में एक सामान्य डेवलपर को क्या जानने की आवश्यकता है? मूल बिंदु क्या हैं?

- खतरों का मॉडल, चैनलों की सुरक्षा, डेटा सुरक्षा। खतरों का खतरा क्या है: शायद यह एक नेटवर्क पर एक उपयोगकर्ता इंटरफ़ेस या डेटा ट्रांसमिशन है (सब कुछ हमारे साथ वितरित किया जाता है, इसलिए यह एक बहुत ही महत्वपूर्ण मुद्दा है)। बुनियादी उपकरण जैसे एन्क्रिप्शन, एसएसएल, टीएलएस, प्रमाणीकरण, प्राधिकरण, टोकन हैंडलिंग आदि। आपको बहुत कुछ जानने की आवश्यकता नहीं है

- अफवाह यह है कि आप अपाचे इग्नाइट के साथ कुछ भी करना है :-)

- योगदान के संदर्भ में, यह मुख्य परियोजना है जिस पर मैं वर्तमान में काम कर रहा हूं। अपाचे इग्नाइट में भागीदारी मेरे दूसरे कार्य से संबंधित है - नि: शुल्क और मुक्त स्रोत परियोजनाओं में संतुलित निवेश सुनिश्चित करने के लिए। इसका तात्पर्य उत्पादों के सक्षम उपयोग से है (यह स्पष्ट है कि पुस्तकालयों का उपयोग एक निवेश है, हम, उपयोगकर्ताओं के रूप में, उत्पाद का आकर्षण बढ़ाते हैं), साथ ही साथ विकास और योगदान भी करते हैं।

मेरे लिए, शायद, यह कार्य और भी महत्वपूर्ण है। हम उन उत्पादों को श्रद्धांजलि देते हैं जो हम अपनी कंपनी में उपयोग करते हैं, और धन्यवाद जिसके लिए हमने बहुत सारे उत्पादों और प्रणालियों का निर्माण किया। हम उन्हें बेहतर बनाने की कोशिश करते हैं और हमारी जैसी कंपनियों में उपयोग की संभावना सुनिश्चित करते हैं: अनुकूलन करने के लिए, एक उद्यम राज्य में लाएं।

अपाचे इग्नाइट एकमात्र प्रोजेक्ट नहीं है, लेकिन हम इसमें बहुत ही गहनता से तस्करी करेंगे, क्योंकि बैंक में प्रमुख प्लेटफार्मों में से एक अपाचे इग्नाइट के आधार पर बनाया जा रहा है। इग्नाइट एक वितरित कंप्यूटिंग ग्रिड है जो आपको मेमोरी में डेटा को स्टोर और प्रोसेस करने की अनुमति देता है, और वास्तव में यह हमारे व्यवसाय के आईटी परिदृश्य का आधार है। इसलिए, हम इसके विकास में बेहद रुचि रखते हैं।

- बहुत से लोग जानते हैं कि Sbertech GridGain का उपयोग करता है, और आप Apache इग्नाइट के बारे में बात कर रहे हैं। दोनों में क्या अंतर है?

- ग्रिडगैन एक ओपन कोर उत्पाद है जो एक ओपन कोर के आधार पर बनाया गया है, जो इग्नाइट है। और ग्रिडगैन इस कोर के लिए प्लग-इन का एक सेट है, जो रखरखाव और संचालन प्रक्रियाओं को सरल करता है, कई महत्वपूर्ण सूचना सुरक्षा और विश्वसनीयता आवश्यकताओं को प्रदान करता है। लेकिन, वास्तव में, कोर सबसे महत्वपूर्ण हिस्सा है, और प्लगइन्स आपको एक वास्तविक उद्यम में यह सब शोषण करने की अनुमति देते हैं। और बैंक पहले से ही ग्रिडगैन का संचालन करता है।

- चूंकि इग्नाइट खुला है, आप इसके बारे में थोड़ी बात कर सकते हैं, है ना? क्या आप केवल इसका शोषण करते हैं या इसे खत्म करने के लिए कुछ करते हैं, डेवलपर्स के साथ बातचीत करते हैं?

- हम इसे तीव्रता से संशोधित करते हैं। कार्यों की दिशा स्पष्ट रूप से परिभाषित की जाती है, उदाहरण के लिए, Sberbank की बारीकियों को ध्यान में रखते हुए प्रदर्शन सुनिश्चित करना: बड़े पैमाने पर, डेटा का महासागर, उच्च परिचालन गतिविधि। इसलिए, यह तेज और बहुत कुछ होना चाहिए। इससे मेरा मतलब है कि विलंबता और थ्रूपुट।

दूसरी विश्वसनीयता सुनिश्चित करने के लिए है, अर्थात उपलब्धता और दोष सहिष्णुता।

तीसरा परिचालन क्षमता, TCO प्रबंधन है। Sberbank के आकार को देखते हुए, संसाधनों के उपयोग में थोड़ी सी भी कमी, उदाहरण के लिए, एक निश्चित प्रतिशत द्वारा डिस्क, हमारे पैमानों पर जबरदस्त बचत देता है।

और चौथा कार्यात्मक विकास का कार्य है। वास्तव में, मुख्य बात Sberbank तकनीकी स्टैक के अन्य घटकों के साथ इंटरफेस और एकीकरण का विकास है। यह एक परिपक्व और एकीकृत आईटी वास्तुकला के निर्माण के मामले में उपयोगी और महत्वपूर्ण है।

अलग से, तकनीकी ऋण और दोष (जो हमेशा मौजूद हैं) को समाप्त करने का कार्य है। इसे शायद विश्वसनीयता के लिए जिम्मेदार ठहराया जा सकता है।

- स्पष्टीकरण के लिए इन बिंदुओं पर चलते हैं। आप कहते हैं कि आप प्रदर्शन में सुधार लाने के लिए काम कर रहे हैं, विलंबता, थ्रूपुट, यह सब है। सवाल है - क्या इग्नाइट को इससे कोई समस्या है? मेरा मतलब है, क्या इसमें कुछ बदलाव है या यह एक आदर्श उत्पाद है?

- नहीं, उत्पाद को आदर्श नहीं माना जा सकता। प्रत्येक रिलीज में, हम विशिष्ट घटकों पर दोनों सामान्य बेंचमार्क और माइक्रोबैनचर्च चलाते हैं, हम लगातार प्रदर्शन पर काम कर रहे हैं - हमें यहां नहीं रुकना चाहिए। कार्य मुश्किल है, क्योंकि घटकों और समाधान पहले से ही काफी कड़े हैं, प्रदर्शन लगभग लोहे की सीमा पर है। यह जटिलता जोड़ता है, लेकिन सुधार के लिए हमेशा जगह है। हमारे पास अलग-अलग उपयोग के मामले हैं, नए उपयोगकर्ता कार्य दिखाई देते हैं, जिसमें अनुकूलन की संभावना है। उदाहरण के लिए, डेटा की विशिष्ट प्रकृति के लिए टेप ड्राइव का अनुकूलन करें। नेटवर्क परत को अनुकूलित करने के लिए कार्य हैं, जो फिर से, व्यक्तिगत मामलों पर निर्भर करता है। इसलिए, आपको हमेशा अपनी उंगली को नाड़ी पर रखने की आवश्यकता है।

"आपने कहा था कि आप समुदाय में वापस योगदान देंगे।" और विभिन्न मामलों और उनके लिए अनुकूलन के बारे में ये सभी निर्णय कुछ प्रकार के व्यापार हैं। जब हम अपने ट्रेडऑफ़ लेते हैं और उन्हें समुदाय में लाते हैं, तो यह पता चल सकता है कि समुदाय के लोगों की स्थिति थोड़ी भिन्न है, अलग प्राथमिकताएं हैं। सहभागिता कैसे व्यवस्थित करें और अभी भी उस कोड को कॉपी करें जो आपके मामलों के लिए आवश्यक है?

- अन्य कार्यों के साथ अन्य ग्राहक। यह बिल्कुल सच है कि यह एक मानक समस्या है। यह सब समाधान की वास्तुकला पर निर्भर करता है। यदि समाधान शामिल है, उदाहरण के लिए, प्लग-इन एक्सटेंशन बनाने की क्षमता, प्लग-इन, विभिन्न उपयोगकर्ता समाधानों के लिए लाइब्रेरी - आप बाहर निकल सकते हैं। उदाहरण के लिए, यदि कोई तुलनित्र है, तो उपयोगकर्ता हमेशा एक समाधान विकसित कर सकता है जो इस तुलनित्र को इनपुट में पारित करेगा, और यह विशिष्ट परिस्थितियों के आधार पर समस्या को हल करेगा। एक बार फिर, क्षमताओं बहुत वास्तुकला पर निर्भर हैं। अन्य ग्राहकों के बारे में सोचे बिना केवल मोटे तौर पर कोड और हमारे कार्य के लिए मूर्तिकला करना गलत है - ऐसे पुल अनुरोध समीक्षा के माध्यम से नहीं जाते हैं।

हर कोई समझता है कि एक ओपन सोर्स प्रोजेक्ट क्या है, और सामान्य तौर पर, आप इसे प्रभावित कर सकते हैं। बेशक, ऐसे समुदाय हैं जिनमें निगम स्पष्ट रूप से मौजूद हैं जो अपने हितों में विकास को प्रभावित करते हैं, लेकिन अगर हम शुद्ध ओपन सोर्स खेलते हैं, तो यह योग्यता (योग्य के अधिकार) के साथ तुलना में सही होगा। साबित करें कि आपका निर्णय अच्छा है, और फिर इसे बनाया जाएगा। अभिनय, जैसा कि अक्सर बंद विकास में होता है, अर्थात "मैं मालिक हूं, मैंने कहा" की स्थिति से काम नहीं चलेगा।

- सबसे दिलचस्प मामलों में से एक है जो Sbertech ने सार्वजनिक रूप से बताया सिंगल सेमेटिक लेयर है। एक इन-मेमोरी ग्रिड में बड़ी मात्रा में डेटा फैलता है। इसने इग्नाइट के खुले हिस्से को कैसे प्रभावित किया है और ये समुदाय के लिए कितने दिलचस्प हैं?

- हां, इस तरह के घटनाक्रम चल रहे हैं, और हम बहुत तीव्रता से स्कैलेबिलिटी और एक्सेसिबिलिटी सुनिश्चित करने के लिए काम कर रहे हैं। हमें ऐसे मामले मिले जिनमें वर्तमान टोपोलॉजी प्रबंधन योजना इष्टतम नहीं है, क्योंकि इसकी अस्थायी जटिलता नोड्स की संख्या से बढ़ती है, जैसा कि हम चाहते हैं। यह कुछ हद तक लक्ष्य की उपलब्धि को जटिल करता है।

- जहां तक ​​मुझे याद है, क्लस्टर आर्किटेक्चर एक रिंग है। यही है, जब हम रिंग में शामिल होते हैं, तो शुरुआत में हम समन्वयक के पास जाते हैं और फिर हम रिंग के साथ जाते हैं जब तक हमें पूंछ नहीं मिलती। और अधिक तत्व, अधिक समय, सही?

"हाँ," उसी समय, टोपोलॉजी में नोड्स की संख्या में वृद्धि के साथ, दोनों संदेशों के आकार जो रिंग के साथ प्रसारित होते हैं और प्रतिभागियों के बीच संक्रमण की संख्या बढ़ जाती है। यह कहना नहीं है कि एक अंगूठी एक बुरा निर्णय है, लेकिन कुछ मामलों में यह फिट नहीं है। इसलिए, 2017 के अंत से, हम समुदाय में टोपोलॉजी प्रबंधन को अंतिम रूप दे रहे हैं ताकि उपयोगकर्ता एक टोपोलॉजी प्रबंधन योजना चुन सकें: एक अंगूठी (कभी-कभी यह पूरी तरह से फिट होती है) या ज़ुकीपर पर एक स्टार।

- और अंगूठी कहां से आई? क्यों है? यह कहां तक ​​सही है?

- यह एक डेटा सेंटर में 100-200 नोड्स के टोपोलॉजी पर एक अद्भुत समाधान है। आपको सभी नोड्स को बस और मज़बूती से सिंक्रनाइज़ करने की अनुमति देता है, वे बस क्रम में जाते हैं। यदि हम तारे में जाते हैं, तो वे समानांतर, तेजी से काम करना शुरू करते हैं, लेकिन एक ही समय में उन्हें सिंक्रनाइज़ करना अधिक कठिन हो जाता है। यही है, अंगूठी अधिक स्थिर और विश्वसनीय हो सकती है, सहमत हैं?

"हाँ, बिल्कुल।" लेकिन क्या ऐसा किया जा सकता है कि इस टोपोलॉजी को विन्यास में कुछ पैरामीटर द्वारा बदला जा सकता है, सेटिंग कैसी है?

- हां, हम अभी कर रहे हैं, हम रिलीज में दोनों टोपोलॉजी को शामिल करते हैं। संभवतः, पहले से प्रस्तावित कार्यान्वयन उपयोगकर्ताओं के सभी मामलों को कवर नहीं करते हैं, और जैसे ही नए दिखाई देते हैं, हम उनके प्रभावी प्रसंस्करण को सुनिश्चित करने का प्रयास करेंगे।

- जहां तक ​​मैं समझता हूं, यह एक जटिल जटिलता है। और यह संशोधन सेर्तेख में लोगों द्वारा काम के घंटों के दौरान, या शाम को आनंद के लिए किया जाता है?

- यह समुदाय द्वारा किया जाता है, जिसमें पीबीटी कर्मचारी शामिल होते हैं, जिनका कार्य घंटों के दौरान मुख्य कार्य इस परियोजना में योगदान करना है। टोपोलॉजी समस्या उत्पाद कोर के प्रमुख समाधानों में से एक को प्रभावित करती है, इसलिए मुख्य बोझ डिस्कवरीएसपीआई अनुरक्षकों पर पड़ा, लेकिन मुझे आशा है कि हमारे डेवलपर्स की भागीदारी ने भी परिणाम को सकारात्मक रूप से प्रभावित किया है।

- ठीक है, अर्थात्, ये ऐसे लोग हैं जो काम के घंटों के दौरान एक समस्या का समाधान करते हैं, लेकिन एक ही समय में समुदाय के सदस्य होते हैं।

- हाँ, हमारे डेवलपर्स के काम का सबसे महत्वपूर्ण हिस्सा समुदाय में होता है। लेकिन मैं अपने लोगों से ऐसे कमिट भी देखता हूं जो एक घंटे, दो, तीन रातों में दिखाई देते हैं।

- और इन कर्मचारियों को इस तथ्य से कोई समस्या नहीं होगी कि वे एक बैंक में काम करते हैं, एक बंद प्रणाली पर, और एक ही समय में एक खुले स्रोत के लिए प्रतिबद्ध हैं?

- नहीं, यह नहीं होगा। सभी प्रतिभागी आधिकारिक कॉर्पोरेट योगदानकर्ता हैं। निवेश के लिए दिशा और निर्णय का निर्माण कंपनी के प्रबंधन के स्तर पर किया गया था, और हाँ, समर्पित कॉर्पोरेट योगदानकर्ताओं का यह समूह, जो कंपनी के सभी और टीसी मानकों के अनुसार, कंपनी के हितों में ओपन सोर्स उत्पाद विकसित करता है। हां - यह विकास और ओपन सोर्स है, हां - यह काम के घंटों के दौरान है, और गैर-काम के घंटों के दौरान भी है, लेकिन यह पहले से ही है अगर समुदाय इसके लिए पूछता है।

- हमने सिर्फ कुछ बाहरी मामलों के बारे में बात की है जो समुदाय तय करता है। लेकिन सबसे अधिक संभावना है, कंपनी को अपने स्वयं के एकीकरण बनाने की जरूरत है, इसके कुछ मामलों में सुधार करें ... क्या आपने बहुत कुछ लिखा है? या यह सिर्फ थोड़ा डोपिल्का है?

- पिछली तिमाही के दौरान अपाचे इग्नाइट प्रोजेक्ट के बारे में बोलते हुए, परियोजना में हमारा योगदान सभी परिवर्तनों के 8-10 प्रतिशत तक था, और हम इस प्रतिशत को बढ़ाने का प्रयास करते हैं। हमने बहुत कुछ लिखा है, और यह न केवल मौजूदा कार्यक्षमता का विकास और अनुकूलन है, हम परियोजना के लिए नई कार्यक्षमता पर भी काम कर रहे हैं। यह समुदाय के लिए एक चुनौती है, और हमारे लिए जिम्मेदारी है, क्योंकि इसके समावेश के बाद, समुदाय को कुछ हद तक इसका समर्थन करने का कार्य है।

कार्य न केवल समुदाय से, बल्कि कंपनी के भीतर के उपयोगकर्ताओं से भी प्रकट हो सकते हैं: आर्किटेक्ट, विकास और रखरखाव टीम। इन कार्यों पर परियोजना का विकास भी उत्पाद को महत्वपूर्ण रूप से प्रभावित करता है।

- लेकिन, बता दें, इसके "विशेष फेंग शुई" के संबंध में PRPRB के Sbertekh कार्यक्रम की कई रिपोर्टें थीं। क्या मुझे इसका समर्थन करने के लिए कोई अतिरिक्त टूल और व्यवस्थापक पृष्ठ लिखने की आवश्यकता है?

- ऑपरेशन के लिए इंटरफेस लगातार विकसित हो रहे हैं। उसी ओरेकल का प्रबंधन कंसोल बनाए रखने के लिए अधिक परिचित है और जिसकी अधिक कार्यक्षमता है। क्या इसे पूरी तरह से पुन: पेश करने की आवश्यकता है एक और सवाल है।

- और खुले रूप में, आप प्रबंधन कंसोल देख सकते हैं?

"हाँ, बिल्कुल।" वेब कंसोल प्रकाशित, Visor, CLI - सब कुछ सार्वजनिक है।

- और यदि आप इसे विश्व स्तर पर अधिक देखते हैं, तो सामान्य निर्देश और लक्ष्य क्या हैं?

- अब हम अपाचे इग्नाइट के विकास पर अधिक ध्यान केंद्रित कर रहे हैं, जो कंपनी की प्राथमिकताओं को पूरा करता है। लेकिन हमारे तकनीकी ढेर खत्म नहीं होते हैं। Open Source , , . , , . ( ), , . . , . . .

— , . - ?

— — , availability, durability, fault tolerance ..

— , .

— , — . , Open Source . . , .

— - , , ? , - , ceph?

— , ceph — . , , , .

— - ? ?

— OpenStack.

— , OpenStack — , . - , , ?

— OpenStack , , , Cloud Foundry, .

— ?

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

— .

— , - Open Source .

, . , , -.

— -?

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

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

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

— .

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

— , ? , … , , .

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

— ? ?

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

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

- शायद यही कारण है कि सिस्टम डेवलपर्स की तुलना में बाजार पर अधिक अच्छे आवेदक हैं। मुझे बहुत खुशी है कि हम वर्तमान टीम को इकट्ठा करने में कामयाब रहे, जहां सभी लोग बहुत उज्ज्वल हैं। यह आश्चर्यजनक है कि वे कैसे सोचते हैं और काम करते हैं, वे लगभग किसी भी समस्या को हल कर सकते हैं। मुझे उम्मीद है कि हम और भी प्रतिभाशाली डेवलपर्स को आकर्षित कर सकते हैं। इसलिए, कोई यह सुनिश्चित करने के लिए नहीं कह सकता है कि रूस में किसी को सिस्टम डेवलपर्स की आवश्यकता नहीं है।