सेल्फ-हीलिंग सिस्टम के बारे में आर्किटेक्चर हमें क्या सिखा सकता है

प्लेटो द्वारा पुनर्प्रकाशित

अनुयायियों: 0

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

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

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

पाठ 1: एज केस हमेशा सिस्टम की कमजोरियों का फायदा उठाएंगे

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

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

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

पुनर्प्राप्त करने के लिए औसत समय (MTTR)/पता लगाने के लिए औसत समय (MTTD) को कम करने के लिए, DevOps टीमों को किनारे के मामलों की उच्च संभावना को स्वीकार करना चाहिए और स्व-शिक्षण समाधानों को पहले से तैनात करने के लिए काम करना चाहिए। यह सबक बहुत दूर तक जाता है, क्योंकि इंजीनियरिंग में दूरदर्शिता महत्वपूर्ण है।

पाठ 2: "विमान को उड़ते हुए बनाना" एक कभी न ख़त्म होने वाला चक्र बनाता है

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

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

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

सॉफ़्टवेयर इंजीनियरों, DevOps टीमों और SRE को उन प्रक्रियाओं और उपकरणों को प्राथमिकता देनी चाहिए जो उपलब्धता के बारे में भारी मात्रा में जानकारी से मूल्य निकालते हैं। केवल एक गंभीर त्रुटि को देखने के बजाय, उन्हें एक विमानन इंजीनियर की किताब से एक पृष्ठ लेना चाहिए और तेजी से महत्वपूर्ण निर्णय लेना चाहिए। ऐसा करने का रहस्य AI में छिपा है।

पाठ 3: एआई स्व-उपचार प्रणालियों के लिए एक मूलभूत निर्माण खंड है

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

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

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

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