Slurm SRE। Booking.com र Google.com का विशेषज्ञहरु संग एक पूर्ण प्रयोग

हाम्रो टोलीले प्रयोगहरू मन पराउँछ। प्रत्येक स्लर्म अघिल्लोको स्थिर पुनरावृत्ति होइन, तर अनुभवको प्रतिबिम्ब हो र राम्रोबाट राम्रोमा परिवर्तन हुन्छ। तर संग Slurm SRE हामीले पूर्ण रूपमा नयाँ ढाँचा लागू गर्ने निर्णय गर्‍यौं - सहभागीहरूलाई "लडाई" को लागी सकेसम्म नजिकको अवस्था दिन।

यदि हामीले गहन पाठ्यक्रमको दौडान हामीले के गर्‍यौं भनेर संक्षिप्त रूपमा वर्णन गर्छौं: "हामी निर्माण गर्छौं, हामी तोड्छौं, हामी मर्मत गर्छौं,
हामी अध्ययन गर्दैछौं।" SRE मात्र सिद्धान्तमा थोरै मूल्यवान छ - केवल अभ्यास, वास्तविक समाधान, वास्तविक समस्याहरू।

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

सहभागीहरूलाई समस्या, गल्ती, बग र कार्यहरू चार मेन्टरहरूद्वारा प्रदान गरिएको थियो। Ivan Kruglov, Booking.com (नेदरल्याण्ड्स) मा प्रमुख विकासकर्ता। बेन टायलर, Booking.com (USA) मा प्रमुख विकासकर्ता। Eduard Medvedev, CTO मा Tungsten Labs (जर्मनी)। Evgeniy Varavva, गुगल (सान फ्रान्सिस्को) मा सामान्य विकासकर्ता।

यसबाहेक, सहभागीहरू टोलीमा विभाजित छन् र एकअर्कासँग प्रतिस्पर्धा गर्छन्। रोचक?

इभान, बेन, एडवार्ड र इभगेनीले प्रतियोगिता सुरु हुनुअघि दयालु लेनिनवादी स्क्विन्टहरूका साथ गरीब स्लर्म SRE सहभागीहरूलाई हेर्छन्।

त्यसैले कार्य:

हामी हाम्रै हौँ, नयाँ संसार बनाउने छौँ ।

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

हामी जे पनि गर्न तयार छौं ... र सबैलाई।

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

गहन साइटको लागि, हामीले SLO, SLI, SLA सूचकहरू, विकास वास्तुकला र पूर्वाधारहरू, साइट तैनाती, अनुगमन र सतर्कता सेट अप गर्यौं। र हामी टाढा जान्छौं।

SLO, SLI, SLA

SLI - सेवा स्तर सूचकहरू। SLO हरू सेवा स्तरका लक्ष्यहरू हुन्। SLA - सेवा स्तर सम्झौता।

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

SLO भनेको सेवा स्तरको उद्देश्य हो: SLI द्वारा मापन गरिएको सेवा स्तरको लागि लक्षित मान वा मानहरूको दायरा। SLO को लागि सामान्य मान "SLI ≤ लक्ष्य" वा "तल्लो सीमा ≤ SLI ≤ माथिल्लो सीमा" हो।

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

सबै भन्दा पहिले, हामी विमानहरू तोड्नेछौं, र त्यसपछि केटीहरू, र त्यसपछि केटीहरू ...

आन्तरिक र बाह्य कारकहरूले पहिलो मिनेटदेखि नै SLO लाई "बिगार" गर्न थाले। सबै कुरा प्रशासकहरूको टाउकोमा पर्यो - विकासकर्ता गल्तीहरू, पूर्वाधार विफलताहरू, आगन्तुकहरूको आगमन, र DDoS आक्रमणहरू। SLO लाई बिग्रने सबै कुरा।

"- प्रिय सहभागीहरू, म तपाईंलाई खुसी पार्न हतार गर्छु, तपाईं असफल हुनु पहिलो कुरा हो ... सबै कुरा!"

बाटोमा, वक्ताहरूले स्थिरता, त्रुटि बजेट, परीक्षण अभ्यास, अवरोधहरूको व्यवस्थापन र परिचालन लोडको बारेमा छलफल गरे।

हामी सिकर्मी होइनौं, सिकर्मी होइनौं...

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

"- हे प्रभु, मैले यसलाई यसरी, यो रूप र यस्तो स्थितिमा कहिल्यै फुटेको देखेको छैन!"

तर, दुर्घटना भयो । भुक्तानी प्रशोधन सेवा बन्द छ। कम से कम सम्भावित समयमा कार्यक्षमता पुनर्स्थापित गर्न कसरी कार्य गर्ने?

विज्ञहरू, सहभागीहरूलाई मायाले हेर्दै, अर्को चाल तयार गर्दैछन्।

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

"कस्तो त्रास बाहिर आयो?!"

श्वास छोड्नुहोस् ... र व्यायाम समाप्त गर्नुहोस्

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

“अरू कसलाई पीडा चाहियो र ! - म!"

टोलीको सफलता सख्त र स्पष्ट रूपमा इलेक्ट्रोनिक स्कोरबोर्डमा रेकर्ड गरिएको थियो।

पहिलो स्थानहरूको लागि - सरोकारवालाहरूबाट बोनस।

स्रोत: www.habr.com