शुक्र है, चूंकि साइट विश्वसनीयता इंजीनियरिंग Google में आंतरिक रूप से विकसित हुई है और केवल हाल ही में व्यापक समुदाय में अपना रास्ता बनाने के लिए शुरू हुई है, यह काफी अच्छी तरह से परिभाषित है। क्या है नहीं है, हालांकि, है वेब संचालन (या "सिस्टम प्रशासन" - स्पष्टता की कमी का एक उदाहरण के रूप में, आप अपने प्रश्न में दोनों का उपयोग करें)। दो चीजों के बीच के अंतर पर चर्चा करना मुश्किल है जब आप पूरी तरह से निश्चित नहीं हैं कि उनमें से एक क्या है।
लेकिन मैं एक साहसी साथी हूं, इसलिए मैं इसे एक शॉट दूंगा।
बहुत पारंपरिक दुकानों में, डेवलपर्स और sysadmins एक दूसरे से बहुत खामोश हैं। देवता एक ऐप का निर्माण करते हैं, फिर जैसे ही उनका कोड हो गया है, उनकी नौकरी को पूरा करने पर विचार करें। Sysadmins बिल्ड कलाकृतियों को लेते हैं (जो कि केवल कोड हो सकता है, अगर यह एक व्याख्या की गई भाषा है) और इसे उत्पादन सर्वर पर तैनात करें। एप्लिकेशन को सुचारू रूप से चलाने के लिए, और सामान्य रूप से उत्पादन वातावरण का प्रबंधन करना सिसडमिन्स का काम है। हालांकि, अक्सर एप्लिकेशन में आर्किटेक्चर मुद्दों से प्रदर्शन समस्याएं आती हैं; sysadmins को यह जानने के लिए प्रोग्रामिंग ज्ञान नहीं है कि ऐप क्या कर रहा है, और डेवलपर्स को पता नहीं है कि ऐप उत्पादन ट्रैफ़िक के साथ उत्पादन टोपोलॉजी में कैसे कार्य करता है, इसलिए समस्या को हल करने के लिए कोई भी खुद से सुसज्जित नहीं है।
इसके अतिरिक्त, डेवलपर्स को आमतौर पर इस बात पर आंका जाता है कि वे कितनी जल्दी नई सुविधाओं का उत्पादन कर सकते हैं, जबकि sysadmins को इस बात पर आंका जाता है कि उत्पादन में ऐप कितना टूटता है। चूंकि परिवर्तन ब्रेक्जिट के प्रमुख कारणों में से एक है, यह दो विभागों को एक-दूसरे के साथ जोड़ता है - एक पुरानी प्रतिद्वंद्विता जो व्यवसाय और इसमें शामिल लोगों को नुकसान पहुंचाती है।
कुछ बिंदु पर, कुछ डेवलपर-केंद्रित कंपनियों को इस बात पर इतना गुस्सा आया कि उन्होंने "NoOps" का अभ्यास शुरू कर दिया - उन्होंने अपने परिचालन विभागों और उनके साथ आने वाली कथित बाधाओं को समाप्त कर दिया। वास्तव में, इसका मतलब था कि डेवलपर्स ने संचालन भूमिकाएं निभाईं, लेकिन अपने पुराने खिताबों को बनाए रखा।
में NoOps आसपास के एक चर्चा , जॉन Allspaw, तो Etsy पर तकनीकी संचालन के उपाध्यक्ष और के एक संपादक सम्मानित वेब संचालन पुस्तक , Etsy पर परिभाषित भूमिकाओं इस तरह:
Etsy संचालन के लिए जिम्मेदार है:
- आउटेज का जवाब, ऑन-कॉल लेता है
- अलर्टिंग सिस्टम थ्रॉल्डिंग, डिज़ाइन
- वास्तुकला डिजाइन और समीक्षा
- बिल्डिंग मेट्रिक्स संग्रह
- अनुप्रयोग कॉन्फ़िगरेशन
- इन्फ्रास्ट्रक्चर बिल्डआउट / प्रबंधन
Etsy विकास के लिए जिम्मेदार है:
- आउटेज का जवाब, ऑन-कॉल लेता है
- अलर्टिंग सिस्टम थ्रॉल्डिंग, डिज़ाइन
- वास्तुकला डिजाइन और समीक्षा
- बिल्डिंग मेट्रिक्स संग्रह
- अनुप्रयोग कॉन्फ़िगरेशन
- शिपिंग सार्वजनिक-सामना कोड
उन सूचियों में से कोई भी व्यापक नहीं हैं, मुझे यकीन है कि मैं वहां कुछ याद कर रहा हूं। जबकि Etsy Ops ने उत्पादन-परिवर्तन अनुप्रयोग परिवर्तन किए हैं, वे कुछ कम (लेकिन कभी-कभी बहुत गहरे) होते हैं। जबकि अस्सी देव बावर्ची परिवर्तन करते हैं, वे कम लेकिन वास्तविक हैं। यदि जिम्मेदारियों में बहुत अधिक अंतर है, तो अंतर क्यों, आप पूछ सकते हैं? डोमेन विशेषज्ञता और पृष्ठभूमि। टीसीपी की शुरुआत धीमी गति से होती है, इस बारे में कई देवताओं को गहन जानकारी नहीं है, लेकिन ऑप्स करता है। कई ऑप्स को सॉर्टिंग या प्रासंगिकता एल्गोरिदम का व्यापक ज्ञान नहीं है, लेकिन देव करता है। ऑप्स को स्वीकार्य सटीकता के साथ संसाधन उपयोग का पूर्वानुमान लगाने में वर्षों का अनुभव है, देव नहीं करता है। देव को सभी लेयर्स 1-7 के पार कार्यभार विकल्पों को वितरित करने के पेशेवरों और विपक्षों के बारे में पता नहीं हो सकता है, शायद केवल 7 पर, ऑप्स करता है। एक डेवलपर के लिए इकाई-संबंध मॉडलिंग स्वाभाविक हो सकता है, यह ऑप्स के लिए नहीं हो सकता है। अंत में, वे दोनों बाइजेंटाइन विफलता परिदृश्य और लचीलापन पैटर्न के विभिन्न रूपों के समाधान की खोज करते हैं, सभी स्तरों और परतों पर।
उनकी दुनिया में, डेवलपर्स और ऑप्स इंजीनियरों के पास बहुत ही उच्च-स्तरीय कौशल सेट और जिम्मेदारियां थीं; जहाँ वे अलग थे उनकी विशेषज्ञता में था। उनकी अलग-अलग विशिष्टताओं ने उन्हें समस्याओं को हल करने के लिए एक साथ काम करने के लिए प्रोत्साहित किया, और उनके सामान्य आधार-स्तरीय कौशल ने उन्हें एक भाषा दी जिसमें ऐसा करना था।
यह आम तौर पर उन वेब परिचालनों की परिभाषा है जो मैं ज्यादातर मामलों के लिए भूमि पर करता हूं। तो यह वह है जिसे हम जारी रखना चाहते हैं।
तो फिर, साइट विश्वसनीयता इंजीनियरिंग क्या है?
Google SRE पुस्तक SRE की परिभाषा के साथ खुलती है ... और फिर एक और एक ... और फिर एक अध्याय को भूमिका को परिभाषित करने के लिए जारी रखता है और एक पूरी पुस्तक को विशिष्टताओं को कवर करता है। यहां तक कि जब एक संगठन में विकसित किया जाता है, तो ऐसा लगता है कि नौकरी को एक एकल सहमत परिभाषा तक सीमित करना मुश्किल है।
शुरुआत करने के लिए, हमें 2003 तक वापस चलने की आवश्यकता है, जब बेन ट्रेयनर ने Google में शामिल हो गए और यह स्थापित किया कि पहली साइट विश्वसनीयता इंजीनियरिंग टीम क्या है। याद रखें कि कुछ पैराग्राफ पहले हम 2010 की शुरुआत में थे; लेकिन 2003 में, उद्योग अभी भी sysadmin / डेवलपर को चीजों के प्राकृतिक तरीके के रूप में विभाजित करने के लिए बहुत सुंदर था। इसलिए जब बेन कहता है कि एसआरई तब होता था जब एक सॉफ्टवेयर इंजीनियर एक ऑपरेशन टीम बनाता था, तो यह दो दुनियाओं की तुलना में कहीं अधिक कट्टरपंथी पिघलने की तुलना में अब प्रकट होता है।
प्रस्तावना में दी गई परिभाषा व्यक्तिगत रूप से तीन शब्दों में से प्रत्येक पर जोर देती है:
- इंजीनियरिंग - कंप्यूटर विज्ञान और इंजीनियरिंग अवधारणाओं का उपयोग समस्याओं को हल करने के लिए
- विश्वसनीयता , सिस्टम को अधिक मापनीय, अधिक विश्वसनीय और अधिक कुशल बनाने पर ध्यान केंद्रित करता है
- सेवा - "साइट" का बाद का विकास, जोर देकर कहा कि SRE नेटवर्क सेवाओं के लिए जिम्मेदार हैं
परिचय अध्याय साइट विश्वसनीयता इंजीनियरिंग के सिद्धांतों को सूचीबद्ध करता है:
- इंजीनियरिंग पर एक टिकाऊ ध्यान केंद्रित करना - लगातार पृष्ठों और अन्य "टोल" से बचने के लिए पूर्व-खाली कार्रवाई करना।
- एक सेवा के एसएलओ का उल्लंघन किए बिना अधिकतम परिवर्तन वेग को जारी रखना - एक ऐसा विषय जो आसानी से अपने कई-सौ शब्दों के उत्तर दे सकता है, लेकिन डेवलपर्स को परिवर्तन करने में मदद करने के रूप में मोटे तौर पर संक्षेप में , जब तक कि वे बहुत सारे मुद्दों का कारण नहीं बनते।
- निगरानी - स्वचालित अलर्ट जब चीजें गलत हो जाती हैं
- आपातकालीन प्रतिक्रिया - चीजों को ठीक करना जब वे टूट गए हों
- परिवर्तन प्रबंधन
- क्षमता की योजना
- प्रोविजनिंग
- दक्षता और प्रदर्शन - यह सुनिश्चित करना कि एक सेवा एक अपेक्षित स्तर पर प्रदर्शन करती है - अड़चनें उपयोगकर्ताओं को नुकसान पहुंचाती हैं, लेकिन अतिरिक्त क्षमता पैसे खर्च करती है
मैं साइट विश्वसनीयता इंजीनियरिंग को आधुनिक वेब संचालन के एक विशेष उपसमूह के रूप में वर्गीकृत करूँगा। एक एसआरई संगठन हर चीज को स्वचालित करने पर बहुत अधिक ध्यान केंद्रित करता है , एक हद तक जो काफी बड़ी कंपनियों में केवल लागत प्रभावी है। त्रुटि बजट जैसे विचार केवल तभी काम कर सकते हैं जब आपकी सेवा में कई, कई अनुरोध हों, अन्यथा आप दानेदारता खो देते हैं (एक छोटी सेवा के लिए, एक विशेष त्रुटि मिनट के आधार पर आपके अनुरोधों के 0-20% को प्रभावित कर सकती है)। सुरक्षा जैसे संबंधित क्षेत्र एसआरई परिभाषा से अनुपस्थित हैं, क्योंकि बड़ी कंपनियों के पास सच एसआरई टीम है जो सुरक्षा के लिए टीमों को समर्पित करती है।
Google द्वारा परिभाषित SRE प्रोग्राम, वेब ऑप्स Google की विशिष्ट आवश्यकताओं के लिए विकसित किया गया है, और आवश्यक रूप से कहीं और लागू नहीं है।
हालाँकि, हाल ही में साइट विश्वसनीयता इंजीनियरिंग का व्यापक उद्योग उपयोग में विस्तार हुआ है। मेरी वर्तमान नौकरी का शीर्षक एक एसआरई है, भले ही मैं एक बहुत छोटी कंपनी में काम करता हूं और मेरी नौकरी का विवरण जॉन अल्लसॉव 2012 एटसी वेब ऑप्स परिभाषा के साथ बहुत अच्छी तरह से फिट बैठता है। मेरा सिद्धांत है कि हम एक ही क्षेत्र के विकास की जासूसी के लिए एक आशुलिपि के रूप में खिताबों के माध्यम से प्रगति कर रहे हैं:
- हमने सिसड्मिन के रूप में शुरुआत की ।
- फिर जैसे-जैसे वेब साइटें एक "चीज" बन गईं, वेब पोस्टिंग इंजीनियरों को संदर्भित करने के लिए जॉब पोस्टिंग शुरू हुई, जो कि उन लोगों से वेब में विशिष्ट हैं, जिन्होंने सामान्य कार्यालय आईटी को भी संभाला है।
- तब DevOps को उन लोगों को अलग करना चाहिए था जो अपने वेब ऑप्स वर्कलोड को कम करने के लिए प्रोग्रामिंग का उपयोग कर रहे थे।
- लेकिन देवओप्स स्पष्ट परिभाषा की कमी के कारण पिघल गए , हमने यह बताने के लिए साइट विश्वसनीयता इंजीनियरिंग को अपनाया कि हम ऐसे लोगों की तलाश कर रहे हैं जो ऑन-कॉल सपोर्टिंग प्रोडक्शन सर्विसेज हैं।
तो एक sysadmin और एक SRE के बीच अंतर क्या है? जिस वर्ष उन्होंने अपना खिताब प्राप्त किया। पारंपरिक संचालन और साइट विश्वसनीयता इंजीनियरिंग के बीच अंतर क्या है? SRE महज ऑप्स का वर्तमान अवतार है, नए टूल (हेल्लो, कंटेनर!) और, के रूप में नेटवर्क प्रोग्राम अधिक बड़े और अधिक महत्वपूर्ण होते जा रहे हैं, प्रथाओं पर एक बढ़ा फोकस जो एक इंजीनियर को और अधिक करने की अनुमति देता है ।