स्लर्म SRE. Booking.com आणि Google.com मधील तज्ञांसह एक संपूर्ण प्रयोग

आमच्या टीमला प्रयोग आवडतात. प्रत्येक स्लर्म ही मागील गोष्टींची स्थिर पुनरावृत्ती नसते, परंतु अनुभवाचे प्रतिबिंब आणि चांगल्याकडून चांगल्याकडे संक्रमण असते. पण सह स्लर्म SRE आम्ही पूर्णपणे नवीन स्वरूप लागू करण्याचा निर्णय घेतला - सहभागींना शक्य तितक्या जवळच्या परिस्थिती "लढाऊ" देण्यासाठी.

गहन अभ्यासक्रमादरम्यान आम्ही काय केले ते थोडक्यात सांगितल्यास: “आम्ही बांधतो, आम्ही तोडतो, आम्ही दुरुस्ती करतो,
आम्ही अभ्यास करत आहोत." SRE ची किंमत केवळ थिअरीमध्ये कमी आहे - फक्त सराव, वास्तविक उपाय, वास्तविक समस्या.

सहभागींना संघांमध्ये विभागले गेले होते जेणेकरुन जोमदार स्पर्धात्मक भावना कोणालाही झोपू देणार नाही किंवा दिमित्री अनातोलीविचच्या उदाहरणाचे अनुसरण करून आयफोनवर “अँग्री बर्ड्स” लाँच करू देणार नाही.

चार मार्गदर्शकांद्वारे सहभागींना समस्या, त्रुटी, बग आणि कार्ये प्रदान करण्यात आली. इव्हान क्रुग्लोव्ह, Booking.com (नेदरलँड्स) मधील मुख्य विकसक. बेन टायलर, Booking.com (यूएसए) मधील मुख्य विकसक. एडवर्ड मेदवेदेव, टंगस्टन लॅब्स (जर्मनी) येथे सीटीओ. Evgeniy Varavva, Google (San Francisco) चे सामान्य विकासक.

शिवाय, सहभागी संघांमध्ये विभागले गेले आहेत आणि एकमेकांशी स्पर्धा करतात. मनोरंजक?

स्पर्धा सुरू होण्यापूर्वी इव्हान, बेन, एडुआर्ड आणि इव्हगेनी गरीब स्लर्म एसआरई सहभागींकडे दयाळू लेनिनिस्ट स्क्विंटसह पाहतात.

तर कार्य:

आम्ही आमचे आहोत, नवीन जग घडवू.

मूव्ही तिकीट एग्रीगेटर वेबसाइट आहे. पूर्व-काम केलेल्या परिस्थितीत मार्गदर्शकांद्वारे घटनांचा शोध लावला जातो (जरी कोणीही विशेषत: अत्याधुनिक आणि कपटी सुधारणा वगळता), साइटच्या कार्यप्रदर्शनाचे वर्णन विविध मेट्रिक्सद्वारे केले जाते. समस्या खूप भिन्न असू शकतात: मौलिन रूज थिएटरची तिकिटे डेटाबेसमध्ये लोड केलेली नाहीत; चित्रपट आणि कामगिरीचे पोस्टर 10 सेकंदांपेक्षा जास्त वेळात डेटाबेसमध्ये लोड केले जातात; वैयक्तिक चित्रपटाचे वर्णन गोठवते; 0,1% ऑर्डर आधीच आरक्षित आहेत; वेळोवेळी पेमेंट प्रोसेसिंग सिस्टम एक किंवा दोन मिनिटांसाठी क्रॅश होते. आणि बर्‍याच, अनेक, अनेक अप्रिय गोष्टी ज्या स्लर्म SRE सहभागीला त्याच्या वास्तविक नोकरीवर येऊ शकतात.

आम्ही काहीही हाताळायला तयार आहोत...आणि प्रत्येकाला.

आमच्या दीर्घकालीन वेबसाइटमध्ये अनेक सूक्ष्म सेवा आहेत. त्याचे कार्य सर्व सिनेमांमधील शो, किंमती आणि उपलब्ध जागांवरील डेटा एकत्रित करणे आहे; ते चित्रपटाच्या घोषणा दर्शविते, तुम्हाला सिनेमा, शो, हॉल आणि ठिकाण निवडण्याची परवानगी देते, बुक करणे आणि तिकिटांसाठी पैसे देणे. सर्वसाधारणपणे, प्रत्येक गोष्ट ज्याचे दर्शक फक्त स्वप्न पाहू शकतात. परंतु साइटच्या स्थिरतेसाठी आणि प्रवेशयोग्यतेसाठी काय टायटॅनिक संघर्ष चालू आहे याची देखील वापरकर्त्याला शंका नाही.

गहन साइटसाठी, आम्ही SLO, SLI, SLA निर्देशक तयार केले, आर्किटेक्चर आणि पायाभूत सुविधा विकसित केल्या, साइट तैनात केली, मॉनिटरिंग आणि अलर्टिंग सेट केले. आणि आम्ही निघून जातो.

SLO, SLI, SLA

SLI - सेवा पातळी निर्देशक. SLO ही सेवा पातळीची उद्दिष्टे आहेत. SLA - सेवा पातळी करार.

SLA ही एक ITIL कार्यपद्धती संज्ञा आहे जी सेवेचे ग्राहक आणि पुरवठादार यांच्यातील औपचारिक करार दर्शवते, ज्यामध्ये सेवेचे वर्णन, पक्षांचे अधिकार आणि दायित्वे आणि सर्वात महत्त्वाचे म्हणजे, या तरतुदीसाठी दर्जाची मान्य पातळी असते. सेवा

SLO हे सेवा पातळीचे उद्दिष्ट आहे: SLI द्वारे मोजले जाणारे सेवा स्तरासाठी लक्ष्य मूल्य किंवा मूल्यांची श्रेणी. SLO साठी एक सामान्य मूल्य "SLI ≤ लक्ष्य" किंवा "लोअर लिमिट ≤ SLI ≤ वरची मर्यादा" आहे.

SLI हे सेवा स्तर सूचक आहे - प्रदान केलेल्या सेवेच्या पातळीच्या एका पैलूचे काळजीपूर्वक परिभाषित परिमाणवाचक माप. बर्‍याच सेवांसाठी, की SLI ही विनंती विलंब मानली जाते - विनंतीला प्रतिसाद देण्यासाठी किती वेळ लागतो. इतर सामान्य SLI मध्ये त्रुटी दर समाविष्ट आहे, बहुतेक वेळा प्राप्त झालेल्या सर्व विनंत्यांचा एक अंश म्हणून व्यक्त केला जातो आणि सिस्टम थ्रूपुट, सामान्यत: प्रति सेकंद विनंत्यांमध्ये मोजले जाते.

सर्व प्रथम, आम्ही विमाने तोडू, आणि नंतर मुली आणि नंतर मुली ...

अंतर्गत आणि बाह्य घटकांनी पहिल्याच मिनिटापासून एसएलओला “बिघडवणे” सुरू केले. सर्व काही प्रशासकांच्या डोक्यावर पडले - विकसकाच्या चुका, पायाभूत सुविधांमध्ये बिघाड, अभ्यागतांचा ओघ आणि DDoS हल्ले. SLO बिघडवणारी प्रत्येक गोष्ट.

"- प्रिय सहभागींनो, मी तुम्हाला खूश करण्यासाठी घाई करतो, तुम्ही अयशस्वी व्हाल ही पहिली गोष्ट आहे... सर्वकाही!"

वाटेत, वक्त्यांनी स्थिरता, त्रुटी बजेट, चाचणी सराव, व्यत्ययांचे व्यवस्थापन आणि ऑपरेशनल लोड यावर चर्चा केली.

आम्ही स्टोकर नाही, सुतार नाही...

मग सहभागींनी गोष्टी दुरुस्त करण्यास सुरुवात केली - मुख्य गोष्ट म्हणजे प्रथम काय पकडायचे हे समजून घेणे.

"- प्रभू, मी ते कधीही या स्वरूपात, अशा स्थितीत तुटलेले पाहिले नाही!"

त्यामुळे अपघात झाला. पेमेंट प्रक्रिया सेवा बंद आहे. कमीत कमी वेळेत कार्यक्षमता पुनर्संचयित करण्यासाठी कसे कार्य करावे?

तज्ञ, सहभागींकडे प्रेमाने पाहत, आणखी एक युक्ती तयार करत आहेत.

प्रत्येक कार्यसंघ अपघात दूर करण्यासाठी गटाचे कार्य आयोजित करतो - सहकाऱ्यांचा समावेश होतो, स्वारस्य असलेल्या पक्षांना (भागधारकांना) सूचित करतो. त्याच वेळी, प्राधान्यक्रम सेट केले जातात. अशा प्रकारे, सहभागींनी अत्यंत मर्यादित वेळेच्या परिस्थितीत दबावाखाली काम करण्याचे प्रशिक्षण दिले.

"कसली भयपट बाहेर आली आहे?!"

श्वास सोडा... आणि व्यायाम पूर्ण करा

स्पीकर्ससह, प्रत्येक समस्येचे निराकरण झाल्यानंतर आणि साइट तात्पुरते स्थिर झाल्यानंतर, टीमने घटनांचा SRE दृष्टिकोनातून अभ्यास केला. आम्ही समस्यांचे तपशीलवार विश्लेषण केले - घटनेची कारणे, निर्मूलनाची प्रगती. त्यानंतर, टीम-बाय-टीम आणि एकत्रितपणे, आम्ही त्यांना आणखी कसे प्रतिबंधित करावे याबद्दल निर्णय घेतले: निरीक्षण कसे सुधारायचे, आर्किटेक्चर सुज्ञपणे कसे बदलायचे, विकास आणि ऑपरेशनचा दृष्टीकोन कसा समायोजित करायचा, नियम कसे दुरुस्त करायचे. वक्त्यांनी शवविच्छेदन करण्याच्या पद्धतीचे प्रात्यक्षिक दाखवले.

“आणखी कोणाला यातना पाहिजे! - मी!"

संघांचे यश इलेक्ट्रॉनिक स्कोअरबोर्डवर काटेकोरपणे आणि स्पष्टपणे नोंदवले गेले.

प्रथम स्थानांसाठी - भागधारकांकडून बोनस.

स्त्रोत: www.habr.com