किरिल सफ़ोनोव: "यह समुद्र के पार छोटी नौकाओं में दौड़ने जैसा है"

आईटी कंपनियों में प्रौद्योगिकी, प्रक्रियाओं, बुनियादी ढांचे और लोगों पर पॉडकास्ट के पहले मुद्दे का परिचय (आप यहां शून्य मुद्दे को सुन और पढ़ सकते हैं )। आज, CTOcast पर जाने वाले RuTarget के तकनीकी निदेशक किरिल सफोनोव हैं।



पॉडकास्ट सुनो



पॉडकास्ट के पाठ संस्करण का पहला भाग

पॉडकास्ट का पाठ संस्करण (भाग 2)

अलेक्जेंडर अस्टापेंको: अब मैं प्रौद्योगिकियों की चर्चा से दूर जाने और लोगों के बारे में थोड़ी बात करने का प्रस्ताव करता हूं। आपकी साइट के मुख्य पृष्ठ पर आपको जानकारी मिल सकती है कि Google और Yandex विज्ञापन प्रणाली के प्रोग्रामर कंपनी में काम करते हैं। उद्योग में सर्वश्रेष्ठ पेशेवरों को गति प्राप्त करने के लिए क्या प्रेरित करता है, लेकिन फिर भी एक स्टार्टअप?



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



अलेक्जेंडर अस्टापेंको: बिल्कुल। लेकिन ऐसे लोगों को ढूंढना कोई मामूली काम नहीं है। मैं समझता हूं और आपके साथ साक्षात्कार को पढ़ने के बाद, मुझे यकीन था कि खोज करते समय, आपको वास्तव में कठिनाइयों का सामना करना पड़ा था और यहां तक ​​कि बाहरी एचआर को भी शामिल करना था जो उम्मीदवारों की स्क्रीनिंग, प्रारंभिक फ़िल्टरिंग करेंगे। Google और Yandex को छोड़कर, आप RTB तकनीकों से संबंधित ऐसे असामान्य विशेषज्ञों को और कहाँ देख सकते हैं?



किरिल सफोनोव: शायद, यहां तक ​​कि Google और यैंडेक्स भी 100% उपयुक्त कंपनियां नहीं हैं, जहां आप लोगों को खोज सकते हैं। वास्तव में, रूसी बाजार में काम करने वाली कई अन्य विज्ञापन कंपनियाँ हैं जो किसी न किसी तरह से RTB से संबंधित हैं: बैनर, विज्ञापन स्पॉट, और इसी तरह की कंपनियां। और इन कंपनियों में लोगों की तलाश करना समझदारी है। सेंट पीटर्सबर्ग और मास्को में, मुझे लगता है, बहुत सारे लोग हैं, और वहां किसी को खोजने के लिए अच्छे मौके हैं।



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



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



पावेल पावलोव: आपने साक्षात्कार और लोगों के चयन की प्रक्रिया का उल्लेख किया। क्या RuTarget में नौकरी के लिए साक्षात्कार से जुड़ी कोई विशेषताएं हैं? आप उम्मीदवारों के बीच वास्तव में योग्य पेशेवरों का चयन कैसे करते हैं? आप किन गुणों पर ध्यान देते हैं?



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



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



किरिल सफोनोव: किसी भी मामले में परीक्षण कार्यक्रम लिखते समय, एल्गोरिदम के बारे में एक प्रश्न पॉप जाएगा। कहीं जाना नहीं है।



पावेल पावलोव: आपने उल्लेख किया कि आप स्काइप पर उन लोगों के साथ साक्षात्कार आयोजित करते हैं जो अन्य शहरों में हैं। उन्हें सेंट पीटर्सबर्ग में अपने घर पर आमंत्रित करें या दूर से काम करें?



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



अलेक्जेंडर अस्टापेंको: शायद एक दूरस्थ टीम के साथ काम करने के लिए सबसे अच्छा अभ्यास है? उन सभी को कैसे रखा जा सकता है ताकि हर कोई, जैसा कि वे कहते हैं, एक पृष्ठ पर है?



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



अलेक्जेंडर अस्टापेंको: कितने लोग अब आपके लिए काम करते हैं? कंपनी में कौन सी इकाइयाँ हैं? यह कैसे संरचित है?



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



अलेक्जेंडर अस्टापेंको: मैं देख रहा हूं। सिरिल, आप RuTarget में CTO के रूप में क्या कार्य करते हैं? और विभिन्न प्रकार की गतिविधि के लिए सप्ताह भर में आपका समय कैसे वितरित किया जाता है?



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



पावेल पावलोव: यह पता चला है कि आग की पहली रेखा आप पर गिरती है और अन्य लोगों को नहीं सौंपी जाती है?



किरिल सफोनोव: वास्तव में, हाँ। यह हो रहा है।



पावेल पावलोव: यह है कि आप क्या चाहते थे या इसे कुछ बदलने, कुछ अन्य गतिविधियों पर स्विच करने की कोशिश करने का कोई मतलब है? या क्या आपको लगता है कि यह सबसे अच्छा समाधान है, आपकी विशेषज्ञता को देखते हुए, समस्याओं को जल्दी से हल करने की क्षमता?



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



अलेक्जेंडर अस्टापेंको: सिरिल, क्या अब आप एक तकनीकी विशेषज्ञ या एक प्रबंधक की तरह अधिक महसूस करते हैं, जो उन समस्याओं को चलाता है और हल करता है जहां वे जलते हैं?



किरिल सफोनोव: एक तकनीकी विशेषज्ञ जो समस्याओं का समाधान करता है। मैं ऐसा कहूंगा।



पावेल पावलोव: आपको पहले से ही एक अन्य कंपनी में सीटीओ के साथ काम करने का अनुभव था। इसी तरह के कार्यों या RuTarget में कुछ परिवर्तन हुआ?



किरिल सफोनोव: अंतर यह है कि एक उच्च गति और अधिक वास्तविक, विविध कार्य हैं जिन्हें संबोधित किया जाना है।



पावेल पावलोव: क्या JetBrains में अधिक विकास कार्य थे?



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



पावेल पावलोव: अर्थात्, सिद्धांत रूप में, छोटी कंपनियों के लिए क्लासिक स्थिति, चलो कहते हैं, आत्मा में स्टार्टअप।



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



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



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



पावेल पावलोव: क्या यह स्पष्ट है कि इससे संबंधित सर्वोत्तम प्रथाएं हैं? क्या समाधान उपयोग किया जाता है?



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



पावेल पावलोव: जेटब्रेन्स?



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



पावेल पावलोव: क्या उच्च स्तर की कोड कवरेज होनी चाहिए?



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



पावेल पावलोव: यह पता चलता है कि परीक्षण संचालित विकास का उपयोग पद्धतिपूर्वक किया जाता है: पहले एक परीक्षण लिखा जाता है, फिर एक पैच?



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



पावेल पावलोव: मैं अभी भी कोड समीक्षा के विषय को बंद करना चाहूंगा। आपने कहा कि कोई अच्छा समाधान नहीं है, लेकिन हम पहले से ही जानते हैं कि यह किसके पास होगा। क्या आप दो या तीन फैसलों का नाम दे सकते हैं जो आप अन्य लोगों को नहीं सुझाएंगे?



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



पावेल पावलोव: क्या आप ऐसे फैसलों का उदाहरण दे सकते हैं?



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

GitHub पर होस्टिंग समाधान हैं, लेकिन चूंकि हमारे पास स्थानीय रूप से एक रिपॉजिटरी है और हमारे स्वयं का एक बग ट्रैकर है, ऐसे समाधान हमें शोभा नहीं देते हैं।



पावेल पावलोव: अगर टीम में कुछ क्यूए हैं, तो उन लोगों का परीक्षण करना जो सीधे विकास से संबंधित नहीं हैं?



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



अलेक्जेंडर अस्टापेंको: साइरिल, इस नस में, मैं स्पष्ट करना चाहूंगा कि क्या आपके काउंटर-एजेंटों का समर्थन करने की प्रक्रिया, उदाहरण के लिए, डेटा प्रदाता, सेगमेंटो जैसी कंपनियां, जो ग्राहकों को समाप्त करने के लिए आरटीबी सेवाएं बेचती हैं, किसी तरह संगठित होती हैं।



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



पावेल पावलोव: यह पता चला है कि अगर समस्याओं की रिपोर्ट करने के लिए एक प्रणाली है, तो किसी भी सिस्टम प्रशासक या उन लोगों की कोई आवश्यकता नहीं है जो समर्थन करेंगे, आइए हम कहते हैं, सिस्टम और बड़े?



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



पावेल पावलोव: क्या वे अग्निशमन या सिस्टम को बदलने से अधिक चिंतित हैं? जिस समय कुछ बुरा होता है, क्या आप इसे ठीक कर रहे हैं या लोग मदद कर रहे हैं?



किरिल सफोनोव: इस तरह से आग बुझाने की आवश्यकता नहीं है, क्योंकि सिस्टम को कॉन्फ़िगर किया गया है ताकि यदि कोई इकाई विफल हो जाए, तो यह आपातकालीन मोड में चला जाता है, और बाहर से ऐसा व्यवहार करता है जैसे कि सब कुछ ठीक है। हम सिर्फ दांव नहीं लगाते हैं और कैप के साथ प्रतिक्रिया देते हैं। किसी भी आवश्यक कार्रवाई की आवश्यकता नहीं है। आगे हमें पता चलता है कि समस्या क्या है। कभी-कभी यह हिस्सा तकनीकी होता है, कभी-कभी भाग प्रशासक।