बैंकलाई किन AIOps र छाता अनुगमन चाहिन्छ, वा ग्राहक सम्बन्ध केमा आधारित छ?

Habré मा प्रकाशनहरूमा, मैले पहिले नै मेरो टोलीसँग साझेदारी निर्माण गर्ने मेरो अनुभवको बारेमा लेखेको छु (यहाँ नयाँ व्यवसाय सुरु गर्दा साझेदारी सम्झौता कसरी बनाउने भन्ने बारे कुरा गर्छ ताकि व्यवसाय टुट्न नपरोस्)। र अब म ग्राहकहरूसँग साझेदारी कसरी निर्माण गर्ने भन्ने बारे कुरा गर्न चाहन्छु, किनकि तिनीहरू बिना त्यहाँ छुट्टिने कुरा हुनेछैन। मलाई आशा छ कि यो लेख स्टार्टअपहरूका लागि उपयोगी हुनेछ जसले ठूला व्यवसायहरूलाई आफ्नो उत्पादन बेच्न थालेका छन्।

म हाल MONQ डिजिटल ल्याब नामक स्टार्टअपको नेतृत्व गरिरहेको छु, जहाँ मेरो टोली र म कर्पोरेट IT लाई समर्थन गर्ने र सञ्चालन गर्ने प्रक्रियाहरूलाई स्वचालित बनाउन उत्पादन विकास गर्दैछौं। बजारमा प्रवेश गर्नु सजिलो काम होइन र हामीले थोरै गृहकार्यको साथ सुरु गर्यौं, बजार विशेषज्ञहरू, हाम्रा साझेदारहरू मार्फत गयौं र बजार विभाजन गर्यौं। मुख्य प्रश्न बुझ्नु थियो "हामी कसको पीडालाई राम्रोसँग निको पार्न सक्छौं?"

बैंकहरूले यसलाई शीर्ष 3 खण्डहरूमा बनायो। र निस्सन्देह, सूचीमा पहिलो Tinkoff र Sberbank थिए। हामीले बैंकिङ बजार विज्ञहरूलाई भेट्दा उनीहरूले भने: आफ्नो उत्पादन त्यहाँ परिचय गरौं, बैंकिङ बजारको बाटो खुला हुनेछ। हामीले त्यहाँ र त्यहाँ दुबै प्रवेश गर्ने प्रयास गर्यौं, तर असफलताले हामीलाई Sberbank मा पर्खिरहेको थियो, र Tinkoff का केटाहरू रूसी स्टार्टअपहरूसँग उत्पादक सञ्चारको लागि धेरै खुला भए (सायद त्यस समयमा Sber को कारणले गर्दा। किनेको हाम्रा पश्चिमी प्रतिद्वन्द्वीहरूमध्ये झण्डै एक अर्ब)। एक महिनाभित्र हामीले पाइलट प्रोजेक्ट सुरु गर्‍यौं। यो कसरी भयो, पढ्नुहोस्।

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

हामीले बनाउने उत्पादन इन्टरप्राइज सफ्टवेयर, AIOps (IT सञ्चालनका लागि कृत्रिम बुद्धिमत्ता, वा ITOps) खण्डसँग सम्बन्धित छ। कम्पनीमा प्रक्रिया परिपक्वताको स्तर बढ्दै जाने जस्ता प्रणालीहरू लागू गर्ने मुख्य लक्ष्यहरू:

1. आगो निभाउनुहोस्: असफलताहरू पहिचान गर्नुहोस्, भग्नावशेषबाट अलर्टहरूको स्ट्रिम खाली गर्नुहोस्, जिम्मेवारहरूलाई कार्यहरू र घटनाहरू तोक्नुहोस्;
2. IT सेवाको दक्षता बढाउनुहोस्: घटनाहरू समाधान गर्न समय घटाउनुहोस्, असफलताका कारणहरू संकेत गर्नुहोस्, IT स्थितिको पारदर्शिता बढाउनुहोस्;
3. व्यापार दक्षता बढाउनुहोस्: म्यानुअल श्रमको मात्रा घटाउनुहोस्, जोखिम कम गर्नुहोस्, ग्राहक वफादारी बढाउनुहोस्।

हाम्रो अनुभवमा, सबै ठूला आईटी पूर्वाधारहरूसँग समान रूपमा निगरानीको साथ बैंकहरूसँग निम्न "पीडाहरू" छन्:

• "कसलाई थाहा छ": त्यहाँ धेरै प्राविधिक विभागहरू छन्, लगभग सबैसँग कम्तिमा एउटा अनुगमन प्रणाली छ, र धेरैसँग एक भन्दा बढी छ;
• अलर्टहरूको "लामखुट्टे झुण्ड": प्रत्येक प्रणालीले सयौं उत्पन्न गर्छ र तिनीहरूसँग जिम्मेवार सबैलाई बमबारी गर्छ (कहिलेकाहीँ विभागहरू बीच पनि)। प्रत्येक अधिसूचनामा नियन्त्रणको फोकस निरन्तर कायम राख्न गाह्रो छ; ठूलो संख्याको कारणले तिनीहरूको जरुरीता र महत्त्व समतल गरिएको छ;
• ठूला बैंकहरू - क्षेत्रका नेताहरू आफ्ना प्रणालीहरूलाई निरन्तर रूपमा अनुगमन गर्न, असफलताहरू कहाँ छन् भनेर जान्न मात्र चाहँदैनन्, तर AI को वास्तविक जादू पनि - प्रणालीहरूलाई आत्म-निरीक्षण, आत्म-पूर्वानुमान र आत्म-सही बनाउन।

जब हामी Tinkoff मा पहिलो बैठकमा आएका थियौं, हामीलाई तुरुन्तै भनिएको थियो कि उनीहरूलाई अनुगमनमा कुनै समस्या छैन र उनीहरूलाई कुनै पनि चोट पुर्याउँदैन, र मुख्य प्रश्न यो थियो: "हामीले पहिले नै राम्रो गरिसकेकाहरूलाई के प्रस्ताव गर्न सक्छौं?"

कुराकानी लामो थियो, हामीले तिनीहरूको माइक्रो सेवाहरू कसरी निर्माण गरिन्छ, विभागहरूले कसरी काम गर्छन्, कुन पूर्वाधार समस्याहरू बढी संवेदनशील छन्, कुन प्रयोगकर्ताहरूका लागि कम संवेदनशील छन्, "ब्लाइन्ड स्पटहरू" कहाँ छन्, र तिनीहरूका लक्ष्यहरू र SLAहरू के हुन् भनेर छलफल गर्‍यौं।

वैसे, बैंकको SLAs साँच्चै प्रभावशाली छन्। उदाहरणका लागि, प्राथमिकता XNUMX नेटवर्क उपलब्धता घटना समाधान हुन केही मिनेट मात्र लाग्न सक्छ। यहाँ त्रुटि र डाउनटाइमको लागत, अवश्य पनि, प्रभावशाली छ।

नतिजाको रूपमा, हामीले सहयोगका धेरै क्षेत्रहरू पहिचान गर्यौं:

1. पहिलो चरण घटना समाधानको गति बढाउन छाता अनुगमन हो
2. दोस्रो चरण जोखिम कम गर्न र आईटी विभाग मापन गर्न लागत कम गर्न प्रक्रिया स्वचालन हो।

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

एक धेरै महत्त्वपूर्ण कुरा, हाम्रो विचारमा, ग्राहकहरु संग सम्बन्ध मा ईमानदारी छ। पहिलो कुराकानी र इजाजतपत्रको लागतको गणना पछि, यो भनियो कि लागत धेरै कम भएकोले, यो तुरुन्तै लाइसेन्स किन्न लायक हुन सक्छ (हरियो बैंकको बारेमा माथिको लेखबाट Dynatrace Klyuch-Astrom को तुलनामा, हाम्रो इजाजतपत्रको लागत एक अर्बको तिहाइ होइन, तर 12 गीगाबाइटको लागि प्रति महिना 1 हजार रूबल, Sber को लागी यो धेरै गुणा सस्तो हुनेछ)। तर हामीले तुरुन्तै उनीहरूलाई हामीसँग के छ र के छैन भन्यौं। सायद ठूलो इन्टिग्रेटरबाट बिक्री प्रतिनिधिले "हो, हामी सबै गर्न सक्छौं, अवश्य पनि हाम्रो इजाजतपत्र किन्नुहोस्" भन्न सक्छ, तर हामीले हाम्रा सबै कार्डहरू टेबलमा राख्ने निर्णय गर्यौं। प्रक्षेपणको समयमा, हाम्रो बक्समा प्रोमेथियससँग एकीकरण थिएन, र स्वचालन सबसिस्टमको साथ नयाँ संस्करण जारी हुन लागेको थियो, तर हामीले यसलाई अझै ग्राहकहरूलाई पठाएका छैनौं।

पायलट प्रोजेक्ट सुरु भयो, यसको सिमाना तोकियो र हामीलाई २ महिना दिइएको थियो। मुख्य कार्यहरू थिए:

• प्लेटफर्मको नयाँ संस्करण तयार गर्नुहोस् र यसलाई बैंकको पूर्वाधारमा प्रयोग गर्नुहोस्
• 2 निगरानी प्रणाली जडान गर्नुहोस् (Zabbix र Prometheus);
• Slack मा र SMS मार्फत जिम्मेवार व्यक्तिहरूलाई सूचनाहरू पठाउनुहोस्;
• स्वत: उपचार लिपिहरू चलाउनुहोस्।

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

हामीले पाइलट सेटअप गर्दा, हामीले समयभन्दा अगाडि नै परियोजना बन्द गर्न सक्ने एउटा नयाँ समस्याको सामना गर्‍यौं: तत्काल मेसेन्जरहरू र SMS मार्फत अलर्टहरू पठाउन, हामीलाई Microsoft Azure सर्भरहरूमा आगमन र बहिर्गमन जडानहरू चाहिन्छ। Slack मा अलर्टहरू पठाउन) र बाह्य पठाउने सेवा SMS। तर यस परियोजनामा, सुरक्षा विशेष ध्यान थियो। बैंकको नीति अनुसार यस्तो “प्वाल” कुनै पनि हालतमा खोल्न पाइँदैन । बन्द लुपबाट सबै काम गर्नुपर्थ्यो। हामीलाई हाम्रो आफ्नै आन्तरिक सेवाहरूको API प्रयोग गर्न प्रस्ताव गरिएको थियो जसले Slack र SMS मार्फत अलर्टहरू पठाउँदछ, तर हामीसँग त्यस्ता सेवाहरू बक्स बाहिर जडान गर्ने अवसर थिएन।

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

तर हामीसँग ठ्याक्कै एक महिना बाँकी थियो, जसमा हामीले सबै चीजहरू स्थापना गर्न, कन्फिगर गर्न र स्वचालन डिप्लोय गर्नुपर्ने थियो।

हाम्रा प्रमुख आर्किटेक्ट सर्गेईका अनुसार प्लगइन प्रणाली लागू गर्न कम्तिमा एक महिना लाग्छ।

हामीसँग समय थिएन...

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

पायलटको परिणामको रूपमा, धेरै महत्त्वपूर्ण प्राविधिक नतिजाहरू र निष्कर्षहरू प्राप्त गरियो:

हामीले अलर्टहरू प्रशोधन गर्नका लागि नयाँ कार्यक्षमता परीक्षण गर्यौं

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

"सिंथेटिक ट्रिगर" इन्टरफेस। जडान गरिएको निगरानी प्रणालीहरूबाट अलर्टहरूको प्रशोधन सेटअप गर्दै

प्रणाली को "स्वास्थ्य" को राज्य निर्माण

अलर्टहरूमा आधारित, अनुगमन घटनाहरू सिर्जना गरियो जसले कन्फिगरेसन एकाइहरू (CUs) को स्वास्थ्यलाई असर गर्यो। हामी एक स्रोत-सेवा मोडेल (RSM) लागू गर्दैछौं, जसले कि त आन्तरिक CMDB प्रयोग गर्न सक्छ वा बाह्य एक जडान गर्न सक्छ - पायलट परियोजनाको क्रममा ग्राहकले आफ्नै CMDB जडान गरेन।

संसाधन-सेवा मोडेलसँग काम गर्नको लागि इन्टरफेस। पायलट RSM।

ठीक छ, वास्तवमा, ग्राहकको अन्तमा एकल निगरानी स्क्रिन छ, जहाँ विभिन्न प्रणालीहरूबाट घटनाहरू देखिने छन्। हाल, दुई प्रणालीहरू "छाता" मा जडित छन् - Zabbix र Prometheus, र प्लेटफर्मको आन्तरिक निगरानी प्रणाली।

एनालिटिक्स इन्टरफेस। एकल निगरानी स्क्रिन।

प्रक्रिया स्वचालन सुरु गरियो

अनुगमन घटनाहरूले पूर्व-कन्फिगर गरिएका कार्यहरूको सुरुवातलाई ट्रिगर गर्‍यो - अलर्टहरू पठाउने, लिपिहरू चलाउने, घटनाहरू दर्ता गर्ने/समृद्धि गर्ने - पछि यो विशेष ग्राहकसँग प्रयास गरिएको थिएन, किनभने पायलट परियोजनामा ​​सेवा डेस्कसँग कुनै एकीकरण थिएन।

कार्य सेटिंग्स इन्टरफेस। Slack मा अलर्टहरू पठाउनुहोस् र सर्भर रिबुट गर्नुहोस्।

विस्तारित उत्पादन कार्यक्षमता

स्वचालन स्क्रिप्टहरू छलफल गर्दा, ग्राहकले bash समर्थन र एक इन्टरफेसको लागि सोध्यो जसमा यी स्क्रिप्टहरू सुविधाजनक रूपमा कन्फिगर गर्न सकिन्छ। नयाँ संस्करणले अलि बढी गरेको छ (cURL, SSH र SNMP को समर्थनको साथ Lua मा पूर्ण तार्किक निर्माणहरू लेख्ने क्षमता) र कार्यात्मकता लागू गरेको छ जसले तपाईंलाई स्क्रिप्टको जीवन चक्र (सिर्जना, सम्पादन, संस्करण नियन्त्रण) व्यवस्थापन गर्न अनुमति दिन्छ। , मेट्नुहोस् र अभिलेख)।

Autohealing स्क्रिप्ट संग काम को लागी इन्टरफेस। SSH मार्फत सर्भर रिबुट लिपि।

कुञ्जी खोजीहरू

पायलटको समयमा, प्रयोगकर्ता कथाहरू पनि सिर्जना गरिएको थियो जसले हालको कार्यक्षमता सुधार गर्दछ र ग्राहकको लागि मूल्य बढाउँछ, यहाँ तिनीहरूमध्ये केही छन्:

• अलर्टबाट सिधै अटोहिलिंग स्क्रिप्टमा चरहरू फर्वार्ड गर्ने क्षमता लागू गर्नुहोस्;
• सक्रिय निर्देशिका मार्फत प्लेटफर्ममा प्राधिकरण थप्नुहोस्।

र हामीले थप विश्वव्यापी चुनौतिहरू प्राप्त गर्यौं - अन्य क्षमताहरूसँग उत्पादनलाई "निर्माण" गर्न:

• नियम र एजेन्टहरूको सट्टा ML मा आधारित स्रोत-सेवा मोडेलको स्वचालित निर्माण (सम्भवतः अहिले मुख्य चुनौती);
• अतिरिक्त स्क्रिप्टिङ र तर्क भाषाहरूको लागि समर्थन (र यो जाभास्क्रिप्ट हुनेछ)।

मेरो विचारमा सबैभन्दा महत्त्वपूर्णयो पाइलटले के देखाउँछ दुई चीजहरू छन्:

1. इमानदारी र खुलापनको आधारमा प्रभावकारी सञ्चार निर्माण गर्दा ग्राहकसँगको साझेदारी प्रभावकारीताको कुञ्जी हो, र ग्राहक छोटो समयमा महत्त्वपूर्ण परिणामहरू प्राप्त गर्ने टोलीको हिस्सा बन्छ।
2. कुनै पनि परिस्थितिमा "अनुकूलन" र "बैसाखी" निर्माण गर्न आवश्यक छैन - केवल प्रणाली समाधानहरू। यो अलि बढी समय खर्च गर्न राम्रो छ, तर प्रणाली समाधान बनाउनुहोस् जुन अन्य ग्राहकहरूले प्रयोग गर्नेछ। वैसे, यो के भयो, प्लगइन प्रणाली र Azure मा निर्भरता उन्मूलन अन्य ग्राहकहरु (नमस्ते, संघीय कानून 152) लाई अतिरिक्त मूल्य प्रदान गर्यो।

स्रोत: www.habr.com