एआई या एआई

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

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

यह स्पष्ट है कि इन कार्यों को स्वचालित करने की आवश्यकता है। इसलिए, हमने बीपीएमएन ऑर्केस्ट्रा, प्रोसेस प्लानर, मॉनिटरिंग सिस्टम से सर्वश्रेष्ठ लेने का फैसला किया और लॉग और त्रुटियों को पार्स करने की क्षमता के साथ इस सेट को समृद्ध किया। बेशक, प्रत्येक प्रकार के सिस्टम के लिए अपनी तरह के सबसे अच्छे प्रतिनिधियों पर विचार किया गया था। लेकिन उद्योग की बारीकियों के लिए कोई मेल नहीं मिला। इसलिए - इसे स्वयं करें।

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



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

• हम त्रुटि से निपटने को स्वचालित कैसे करना चाहते हैं?
• विसंगति विश्लेषण के आधार पर परिदृश्यों को कैसे सही किया जाए?
• सामान्य तौर पर, किसी व्यक्ति को ऐसी प्रणाली के संचालन में कितना हस्तक्षेप करना चाहिए, किस मात्रा में और किन स्थानों पर?

मैं एक बार फिर ध्यान देता हूं कि यह सब मिशन-क्रिटिकल सिस्टम की उत्पादकता पर वास्तविक समय में किए जाने की जरूरत है जो दसियों और प्रति सेकेंड हजारों लेनदेन करता है। और यहां हमें परिस्थितियों में खोज और समस्या निवारण (तथाकथित समस्या निवारण) को हल करना था:

• प्रक्रियाओं में आवधिक अद्यतन
• विकासशील वाहक आधार
• दूरसंचार सेवाओं के सेट में बदलाव

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

ऐ

चूँकि हम अनन्त प्रचार के युग में रहते हैं, हमने विकास को कृत्रिम बुद्धिमत्ता का आधार बनाने का निर्णय लिया - ताकि यह बुद्धि त्रुटियों और विसंगतियों को पहचान सके, विफलताओं की भविष्यवाणी करती है और उन्हें तुरंत सुधारती है। बड़ी कंपनियां और छोटे स्टार्टअप पहले से ही ऐसे समाधान बना रहे हैं और यहां तक ​​कि समान समाधान भी लागू कर रहे हैं। उनके आवेदन का मुख्य दायरा: आईटी इंफ्रास्ट्रक्चर के निर्माण, रखरखाव और समर्थन के लिए संचालन। इसे AIOps - Aritific Intelligence (IT के लिए) ऑपरेशंस कहा जाता है, और सबसे लोकप्रिय buzzword NoOps है, अर्थात, पूरी तरह से स्वचालित IT ऑपरेशन।

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

विपक्ष:

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

ऐ मेरे दिमाग नहीं

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

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



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

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

क्या गलत हो सकता है?

वह सब है!

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

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

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

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

और फिर यह निकला ...

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

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