सीएमजी प्रभाव 2016 सम्मेलन की समीक्षा

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



अंतर्राष्ट्रीय सीएमजी प्रभाव सम्मेलन सालाना आईटी सिस्टम के प्रदर्शन में सुधार के क्षेत्र में अमेरिकन एसोसिएशन ऑफ स्पेशलिस्ट्स द्वारा आयोजित किया जाता है। वार्षिक सीएमजी सम्मेलन 1980 से आयोजित किया गया है।

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

सम्मेलन में दुनिया के 15 से अधिक देशों से 120 रिपोर्टें प्रस्तुत की गईं, जिनमें मुख्य रूप से यूएसए, कनाडा और यूरोपीय देश थे। यह 7 नवंबर से 11 नवंबर, 2016 तक पांच दिनों के लिए किया गया था। ऑपरेशन का तरीका इस प्रकार था: प्लेनरी सेशन में रिपोर्ट सुबह 8 बजे से शुरू होती थी और दोपहर के लंच ब्रेक के साथ 19:00 शाम तक 8 कमरों में सेक्शनल रिपोर्ट के साथ जारी रहती थी। सम्मेलन का प्रत्येक कार्य दिवस एक सामान्य बुफे के साथ समाप्त हुआ, जिसके दौरान सभी वक्ताओं के साथ व्यक्तिगत रूप से संवाद करना और प्रस्तुत रिपोर्ट पर चर्चा करना संभव था। यह पसंद करना मुश्किल था कि कौन सी रिपोर्ट में भाग लेना है, क्योंकि समानांतर सत्रों में ब्याज की रिपोर्ट अलग-अलग कमरों में एक साथ थीं।

इस लेख में मैं उन रिपोर्टों का संक्षेप में वर्णन करूंगा जो मुझे सबसे ज्यादा पसंद आईं।

1974 में आईटी सिस्टम कंप्यूटर प्रबंधन समूह के प्रदर्शन में सुधार करने में विशेषज्ञ अमेरिकन एसोसिएशन ने सिस्टम प्रदर्शन का आकलन करने के लिए अपने पेशेवर योगदान के लिए वार्षिक अब्राहम माइकलसन पुरस्कार की स्थापना की। यह पुरस्कार पारंपरिक रूप से CMG प्रभाव सम्मेलन में प्रदान किया जाता है।

कॉन्फ्रेंस उद्घाटन और मिशेलसन पुरस्कार एए की प्रस्तुति

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

समय पर स्कैलेबिलिटी और प्रदर्शन> 1M समवर्ती उपयोगकर्ता प्राप्त करना
लुकास स्लीवका, ग्रिंडर

मेरे लिए अगली दिलचस्प प्रस्तुति उन लोगों की रिपोर्ट थी। ग्रिंड्र डायरेक्टर लुकास क्रीम। ग्रिंडर एक ऑनलाइन डेटिंग एप्लीकेशन है। लुकाश ने कंपनी के परिवर्तन के बारे में एक साथ बात की थी, और विकास संस्कृति (वे घसीटना पर स्विच किया), और प्रणाली के तकनीकी परिवर्तन के बारे में। ग्रिंडर के 2.5 मिलियन से अधिक उपयोगकर्ता हैं, जिनमें से 1 मिलियन सक्रिय हैं। रूपांतरण से पहले मुख्य उपयोगकर्ता संयुक्त राज्य अमेरिका और कनाडा में थे, क्योंकि वे संयुक्त राज्य अमेरिका से दूर चले गए, उपयोगकर्ताओं की संख्या कम हो गई।



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

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

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

क्या आपकी क्षमता उपलब्ध है?
इगोर ट्रूबिन, कैपिटल वन बैंक

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

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

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

डिजिटल अनुभव क्षमता योजना
एमी स्पेलमैन और रिचर्ड गिमार्क

IoT बिजनेस मेट्रिक्स, आईटी मेट्रिक्स और फैसिलिटी मेट्रिक्स के लिए प्लानिंग टॉक।

इस तथ्य के बारे में एक रिपोर्ट कि कई बुनियादी ढांचे अब अपनी बैंडविड्थ की सीमा के करीब काम कर रहे हैं, और क्या होगा जब IoT हर जगह काम करेगा। मेरे लिए, रिपोर्ट में सबसे दिलचस्प इसका पैमाना था। यही है, ऐसे पेशेवर हैं जो साइट के लिए, संगठन के लिए योजना बनाते हैं, और यह एक संपूर्ण उद्योग है। हम इतने बड़े पैमाने पर दृष्टि को कितनी बार बढ़ाते हैं?

बिगडाटा एनालिटिक्स पर आधारित एंटरप्राइज़ प्रदर्शन आश्वासन
बोरिस ज़िबित्सकर

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

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

भविष्यवाणी के साथ वास्तविक व्यवहार की तुलना करके परिणामों की विश्वसनीयता को सत्यापित करने के लिए एक महत्वपूर्ण बिंदु है।

शीर्ष 10 प्रदर्शन में ऑनलाइन संगठनों के लाखों खर्च का दोष है
क्रेग हाइड, कठोरता और कठोरता

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

मुझे क्रेग की स्लाइड्स नहीं मिलीं, लेकिन यहां कंपनी के कर्मचारियों में से एक द्वारा एक ही विषय पर एक रिपोर्ट दी गई है।

जोखिम भरा व्यवसाय
जेफ बुज़ेन

जेफ के बारे में कुछ शब्द - वह हार्वर्ड में एक शिक्षक है, जो 3 पुस्तकों के लेखक हैं, पहला 71 में प्रकाशित हुआ था, और आखिरी 2015 में - रीथिंकिंग रैंडमनेस: ए न्यू फाउंडेशन फॉर स्टोचस्टिक मॉडलिंग, विकी लेख , जेफ के साथ साक्षात्कार ।

मॉडलिंग और पूर्वानुमान प्रदर्शन पर रिपोर्ट। जेफ एक प्रणाली को मॉडल करते समय उत्पन्न होने वाले जोखिमों का वर्णन करता है - मॉडल जोखिम, सिस्टम लोड मापदंडों का जोखिम, पूर्वानुमान जोखिम, आवेदन जोखिम, उपयोग का जोखिम - कार्य के लिए। जेफ विस्तार से वर्णन करता है कि सिस्टम को मॉडलिंग करते समय उत्पन्न होने वाले सभी संभावित जोखिम और यह अनुमान लगाने का प्रयास करता है कि संसाधनों की कितनी आवश्यकता होगी और किस प्रकार की प्रणाली की उपलब्धता की आवश्यकता है। विकल्प क्योंकि SLA लिखना आवश्यक नहीं है - 90% अनुरोध 0.5 सेकंड में निष्पादित होते हैं। कम जोखिम भरा - कतार की लंबाई समय के 33x90% से कम है। उनकी किताब उसी के बारे में है। शास्त्रीय गणित से हम जो पूर्वानुमान लगाते हैं वह हमेशा सही लागू परिणाम नहीं देता है, हालांकि सूत्र सही हो सकते हैं। मॉडल की मान्यताओं पर भविष्यवाणियां बहुत निर्भर करती हैं। विकल्प के विश्लेषण (AoA, विश्लेषण का विकल्प) के आधार पर पूर्वानुमान का उपयोग करना अधिक श्रेयस्कर है।

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

BigData से मूल्य कैसे प्राप्त करें?
रेनाटो बोनोमिनी, स्टेफानो डोनी, मूवेरी

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

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

मोविरी ब्लॉग ।

प्रदर्शन या क्षमता? विभिन्न कार्यों के लिए अलग-अलग दृष्टिकोण
अलेक्जेंडर गिलगुर, फेसबुक

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

यहां आप अलेक्जेंडर द्वारा लेख पढ़ सकते हैं।
स्लाइड करता है ।

कैसे शुरू करें जब आपको नहीं पता कि कहां से शुरू करें।
जस्टिन मार्टिन, सर्नर

इसके बारे में सामान्य तौर पर प्रदर्शन की निगरानी करना आवश्यक है। लेकिन सच तो यह है! कई लोग निगरानी के बिना रहते हैं और उनके साथ सब कुछ ठीक होता है। वास्तव में, कई को इसकी आवश्यकता नहीं है। जब तक वे हब पर अपनी अद्भुत साइट के बारे में एक लेख प्रकाशित नहीं करते हैं, और लोग उन्हें देखने नहीं जाते हैं कि वहां क्या है। या जब तक कुछ और कई, कई उपयोगकर्ताओं के लिए नेतृत्व नहीं करता है।



रिपोर्ट में, जस्टिन काफी सरलता से बताता है कि आरंभ करने के लिए क्या किया जा सकता है। 90 दिनों में क्षमता प्रबंधन

चरणों

1. अपने सिस्टम के लिए पीक आवर्स निर्धारित करें
2. अपनी परियोजना की प्रदर्शन सीमाओं की जांच करें (वह क्षण जब सिस्टम पहले से ही प्रसंस्करण अनुरोधों को रोक देता है और प्रदर्शन नीचा दिखाना शुरू करता है)
3. उत्पादकता में कमी को कम करें
4. आवश्यकता को संतुलित करें - हो सकता है कि आप पीक आवर्स से कम व्यस्त समय में कुछ भार स्थानांतरित कर सकें।

लिंक्डिन जस्टिन । स्लाइड को सम्मेलन के बारे में लेख में देखा जा सकता है, जिसे मैं अंत में प्रकाशित करूंगा।

बिग क्लाउड इन्फ्रास्ट्रक्चर में डायनेमिक लोड बैलेंसिंग और कंटीन्यूअस सर्विस डिलीवरी
यूरी अर्दुलोव, रिंगकंट्रल

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

जीवनचक्र वर्चुअलाइजेशन के साथ लागत, देरी और असफल रिलीज से बचना
टॉड डेकापुआ, सीएससी डिजिटल ब्रांड सेवाएं

टॉड की रिपोर्ट इस बात पर ध्यान केंद्रित करती है कि रिलीज के मुद्दों को कैसे कम किया जाए और महत्वपूर्ण विचार यह है कि किसी कार्यक्रम का परीक्षण करते समय कार्यक्रम के संपूर्ण जीवन चक्र पर विचार करना महत्वपूर्ण है।

4 प्रमुख घटक:

1. उपयोगकर्ता - उपयोगकर्ता वर्चुअलाइजेशन आपके वास्तविक सिस्टम उपयोगकर्ताओं के व्यवहार का अनुकरण करता है।
2. सेवाएं - सेवाओं का एक वर्चुअलाइजेशन होना चाहिए ताकि आप शुरू से अंत तक पूरी प्रक्रिया के संचालन की जांच कर सकें।
3. नेटवर्क - नेटवर्क संचालन की स्थिति का अनुकरण।
4. डेटा - डेटा वर्चुअलाइजेशन एक बिक्री के साथ अनुप्रयोग कॉल का अनुकरण करने के लिए जो वास्तविकता में क्या होगा के करीब हैं।

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

यहाँ टॉड की प्रस्तुति से एक उदाहरण दिया गया है:





टॉड - प्रदर्शन अनुकूलन , प्रदर्शन परीक्षण और उनकी व्याख्या पर एक पुस्तक के लेखक।

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

मेट्रिक्स-ड्रिवेन डिवाइप्स को लागू करना: क्यों और कैसे!
एंड्रियास ग्रैबनर, डायनाट्रेस

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

– , - , . .

, – – , , , , 1 . , , . ?

? Agile Facebook – , .

, Scrum Agile! enterprise 3 ,



, , DevOps, . , . , , . performance advocate .
.

Performance Testing in New Contexts
(Eric Proegler), Soasta

2000, , . , TV , . , 20 , 50 . BlazeMeter (Jmeter), Selenium, Gatling, Grinder. , . (Tableau) , , . , . .

slideshare.

.

, « ». . , , , , .

. , , , . . .

Debbie Sheetz. BMC . . .

MathWorks, .

, , , , . , , .

.

CMG impact , .