स्लम एसआरई. बुकिंग.कॉम और Google.com के विशेषज्ञों के साथ एक संपूर्ण प्रयोग

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

यदि हम संक्षेप में बताएं कि गहन पाठ्यक्रम के दौरान हमने क्या किया: "हम बनाते हैं, हम तोड़ते हैं, हम मरम्मत करते हैं,
हम पढ़ाई कर रहे हैं।" एसआरई का महज़ सिद्धांत में कोई महत्व नहीं है - केवल अभ्यास, वास्तविक समाधान, वास्तविक समस्याएं।

प्रतिभागियों को टीमों में विभाजित किया गया था ताकि एक जोरदार प्रतिस्पर्धी भावना किसी को भी सो जाने या दिमित्री अनातोलियेविच के उदाहरण का अनुसरण करते हुए iPhone पर "एंग्री बर्ड्स" लॉन्च करने की अनुमति न दे।

प्रतिभागियों को चार सलाहकारों द्वारा समस्याएं, गड़बड़ियां, बग और कार्य प्रदान किए गए। इवान क्रुगलोव, बुकिंग.कॉम (नीदरलैंड) के प्रमुख डेवलपर। बेन टायलर, बुकिंग.कॉम (यूएसए) के प्रमुख डेवलपर। एडुआर्ड मेदवेदेव, टंगस्टन लैब्स (जर्मनी) में सीटीओ। एवगेनी वरव्वा, गूगल (सैन फ्रांसिस्को) में जनरल डेवलपर।

इसके अलावा, प्रतिभागियों को टीमों में विभाजित किया जाता है और एक दूसरे के साथ प्रतिस्पर्धा करते हैं। दिलचस्प?

इवान, बेन, एडुआर्ड और एवगेनी प्रतियोगिता शुरू होने से पहले गरीब स्लम एसआरई प्रतिभागियों को दयालु लेनिनवादी दृष्टि से देखते हैं।

तो कार्य:

हम अपने हैं, हम एक नई दुनिया बसाएँगे...

एक मूवी टिकट एग्रीगेटर वेबसाइट है। घटनाओं का आविष्कार सलाहकारों द्वारा पूर्व-कार्य परिदृश्य में किया जाता है (हालांकि कोई भी विशेष रूप से परिष्कृत और कपटी सुधार को बाहर नहीं करता है), साइट के प्रदर्शन को विभिन्न मैट्रिक्स द्वारा वर्णित किया गया है। समस्याएँ बहुत भिन्न हो सकती हैं: मौलिन रूज थिएटर के टिकट डेटाबेस में लोड नहीं किए जाते हैं; फिल्मों और प्रदर्शनों के पोस्टर 10 सेकंड से अधिक समय में डेटाबेस में लोड हो जाते हैं; एक व्यक्तिगत फिल्म का विवरण रुक जाता है; 0,1% ऑर्डर पहले से ही आरक्षित हैं; समय-समय पर भुगतान प्रसंस्करण प्रणाली एक या दो मिनट के लिए क्रैश हो जाती है। और कई, कई, कई अप्रिय चीजें जो स्लम एसआरई प्रतिभागी को उसकी वास्तविक नौकरी में परेशान कर सकती हैं।

हम कुछ भी...और हर किसी को संभालने के लिए तैयार हैं।

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

गहन साइट के लिए, हमने एसएलओ, एसएलआई, एसएलए संकेतक तैयार किए, वास्तुकला और बुनियादी ढांचे का विकास किया, साइट को तैनात किया, निगरानी और चेतावनी स्थापित की। और हम चले जाते हैं.

एसएलओ, एसएलआई, एसएलए

एसएलआई - सेवा स्तर संकेतक। एसएलओ सेवा स्तर के लक्ष्य हैं। एसएलए - सेवा स्तर समझौते।

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

एसएलओ एक सेवा स्तर का उद्देश्य है: सेवा स्तर के लिए एक लक्ष्य मूल्य या मूल्यों की सीमा जिसे एसएलआई द्वारा मापा जाता है। एसएलओ के लिए एक सामान्य मान "एसएलआई ≤ लक्ष्य" या "निचली सीमा ≤ एसएलआई ≤ ऊपरी सीमा" है।

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

सबसे पहले, हम विमानों को तोड़ेंगे, और फिर लड़कियों को, और फिर लड़कियों को...

आंतरिक और बाहरी कारकों ने पहले मिनट से ही एसएलओ को "खराब" करना शुरू कर दिया। सब कुछ प्रशासकों के सिर पर गिर गया - डेवलपर गलतियाँ, बुनियादी ढाँचे की विफलताएँ, आगंतुकों की आमद, और DDoS हमले। वह सब कुछ जो एसएलओ को खराब करता है।

"- प्रिय प्रतिभागियों, मैं आपको खुश करने के लिए जल्दबाजी करता हूं, पहली चीज जो आप असफल होते हैं वह है... सब कुछ!"

साथ ही, वक्ताओं ने स्थिरता, त्रुटि बजट, परीक्षण अभ्यास, रुकावटों के प्रबंधन और परिचालन भार पर चर्चा की।

हम स्टॉकर नहीं हैं, बढ़ई नहीं हैं...

फिर प्रतिभागियों ने चीजों को ठीक करना शुरू कर दिया - मुख्य बात यह समझना है कि पहले क्या लेना है।

"- भगवान, मैंने इसे इस तरह, इस रूप में और ऐसी स्थिति में टूटते कभी नहीं देखा!"

तो, एक दुर्घटना घटी. भुगतान प्रसंस्करण सेवा बंद है. कम से कम समय में कार्यक्षमता बहाल करने के लिए कैसे कार्य करें?

विशेषज्ञ, प्रतिभागियों को स्नेहपूर्वक देखते हुए, एक और तरकीब तैयार कर रहे हैं।

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

"कैसी भयावहता सामने आई है?"

साँस छोड़ें... और व्यायाम समाप्त करें

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

“और कौन पीड़ा चाहता है! - मैं!"

टीमों की सफलताएँ इलेक्ट्रॉनिक स्कोरबोर्ड पर सख्ती से और स्पष्ट रूप से दर्ज की गईं।

प्रथम स्थान के लिए - हितधारकों से बोनस।

स्रोत: www.habr.com