સ્લર્મ SRE. Booking.com અને Google.com ના નિષ્ણાતો સાથે સંપૂર્ણ પ્રયોગ

અમારી ટીમને પ્રયોગો ગમે છે. દરેક સ્લર્મ એ અગાઉના લોકોનું સ્થિર પુનરાવર્તન નથી, પરંતુ અનુભવનું પ્રતિબિંબ અને સારામાંથી વધુ સારામાં સંક્રમણ છે. પરંતુ સાથે સ્લર્મ SRE અમે સંપૂર્ણપણે નવું ફોર્મેટ લાગુ કરવાનું નક્કી કર્યું - સહભાગીઓને "લડાઇ" માટે શક્ય તેટલી નજીકની શરતો આપવા માટે.

જો આપણે સઘન અભ્યાસક્રમ દરમિયાન અમે શું કર્યું તેની ટૂંકમાં રૂપરેખા આપીએ તો: “અમે બનાવીએ છીએ, અમે તોડીએ છીએ, અમે સમારકામ કરીએ છીએ,
અમે અભ્યાસ કરીએ છીએ." માત્ર સિદ્ધાંતમાં SRE નું મૂલ્ય ઓછું છે - માત્ર પ્રેક્ટિસ, વાસ્તવિક ઉકેલો, વાસ્તવિક સમસ્યાઓ.

સહભાગીઓને ટીમોમાં વિભાજિત કરવામાં આવ્યા હતા જેથી જોરશોરથી સ્પર્ધાત્મક ભાવના કોઈને ઊંઘી ન શકે અથવા આઇફોન પર "એન્ગ્રી બર્ડ્સ" શરૂ ન કરે, દિમિત્રી એનાટોલીયેવિચના ઉદાહરણને અનુસરીને.

ચાર માર્ગદર્શકો દ્વારા સહભાગીઓને સમસ્યાઓ, ભૂલો, ભૂલો અને કાર્યો પ્રદાન કરવામાં આવ્યા હતા. ઇવાન ક્રુગ્લોવ, Booking.com (નેધરલેન્ડ) પર મુખ્ય વિકાસકર્તા. બેન ટેલર, Booking.com (યુએસએ) પર મુખ્ય વિકાસકર્તા. એડ્યુઅર્ડ મેદવેદેવ, ટંગસ્ટન લેબ્સ (જર્મની) ખાતે સીટીઓ. Evgeniy Varavva, Google (સાન ફ્રાન્સિસ્કો) ના સામાન્ય વિકાસકર્તા.

તદુપરાંત, સહભાગીઓને ટીમોમાં વિભાજિત કરવામાં આવે છે અને એકબીજા સાથે સ્પર્ધા કરે છે. રસપ્રદ?

સ્પર્ધાની શરૂઆત પહેલાં ઇવાન, બેન, એડ્યુઅર્ડ અને એવજેની ગરીબ સ્લર્મ SRE સહભાગીઓને માયાળુ લેનિનવાદી સ્ક્વિન્ટ્સ સાથે જુએ છે.

તેથી કાર્ય:

અમે અમારા છીએ, નવી દુનિયા બનાવીશું...

મૂવી ટિકિટ એગ્રીગેટર વેબસાઇટ છે. માર્ગદર્શકો દ્વારા પૂર્વ-કાર્ય કરેલ દૃશ્યમાં ઘટનાઓની શોધ કરવામાં આવે છે (જોકે કોઈ ખાસ કરીને અત્યાધુનિક અને કપટી સુધારણાને બાકાત રાખતું નથી), સાઇટની કામગીરી વિવિધ મેટ્રિક્સ દ્વારા વર્ણવવામાં આવે છે. સમસ્યાઓ ખૂબ જ અલગ હોઈ શકે છે: મૌલિન રૂજ થિયેટર માટેની ટિકિટો ડેટાબેઝમાં લોડ થતી નથી; ફિલ્મો અને પ્રદર્શનના પોસ્ટરો 10 સેકન્ડથી વધુ સમયમાં ડેટાબેઝમાં લોડ થાય છે; વ્યક્તિગત ફિલ્મનું વર્ણન થીજી જાય છે; 0,1% ઓર્ડર પહેલાથી જ આરક્ષિત છે; સમય સમય પર ચુકવણી પ્રક્રિયા સિસ્ટમ એક કે બે મિનિટ માટે ક્રેશ થાય છે. અને ઘણી, ઘણી, ઘણી બધી અપ્રિય વસ્તુઓ જે સ્લર્મ SRE સહભાગીને તેની વાસ્તવિક નોકરી પર પડી શકે છે.

અમે કંઈપણ સંભાળવા તૈયાર છીએ...અને દરેકને.

અમારી સહનશીલ વેબસાઈટમાં ઘણી બધી માઈક્રોસેવાઓ છે. તેનું કાર્ય તમામ સિનેમાઘરોમાંથી શો, કિંમતો અને ઉપલબ્ધ બેઠકો પરના ડેટાને એકત્ર કરવાનું છે; તે મૂવીની જાહેરાતો બતાવે છે, તમને સિનેમા, શો, હોલ અને સ્થળ પસંદ કરવા, ટિકિટ બુક કરવા અને ચૂકવણી કરવાની મંજૂરી આપે છે. સામાન્ય રીતે, તે બધું જે દર્શક ફક્ત સ્વપ્ન કરી શકે છે. પરંતુ વપરાશકર્તાને શંકા પણ નથી થતી કે સાઇટની સ્થિરતા અને સુલભતા માટે અંદરથી શું ટાઇટેનિક સંઘર્ષ ચાલી રહ્યો છે.

સઘન સાઇટ માટે, અમે SLO, SLI, SLA સૂચકાંકો જનરેટ કર્યા, આર્કિટેક્ચર અને ઇન્ફ્રાસ્ટ્રક્ચર વિકસિત કર્યું, સાઇટને તૈનાત કરી, મોનિટરિંગ અને એલર્ટિંગ સેટ કર્યું. અને આપણે દૂર જઈએ છીએ.

SLO, SLI, SLA

SLI - સેવા સ્તર સૂચકાંકો. SLO એ સેવા સ્તરના લક્ષ્યો છે. SLA - સેવા સ્તરના કરારો.

SLA એ ITIL પદ્ધતિનો શબ્દ છે જે સેવાના ગ્રાહક અને તેના સપ્લાયર વચ્ચેના ઔપચારિક કરારને સૂચવે છે, જેમાં સેવાનું વર્ણન, પક્ષકારોના અધિકારો અને જવાબદારીઓ અને સૌથી અગત્યનું, આની જોગવાઈ માટે ગુણવત્તાનું સંમત સ્તર. સેવા

SLO એ સેવા સ્તરનો ઉદ્દેશ છે: સેવા સ્તર માટે લક્ષ્ય મૂલ્ય અથવા મૂલ્યોની શ્રેણી જે SLI દ્વારા માપવામાં આવે છે. SLO માટે સામાન્ય મૂલ્ય "SLI ≤ લક્ષ્ય" અથવા "નીચલી મર્યાદા ≤ SLI ≤ ઉપલી મર્યાદા" છે.

SLI એ સેવા સ્તરનું સૂચક છે - પૂરી પાડવામાં આવેલ સેવાના સ્તરના એક પાસાની કાળજીપૂર્વક વ્યાખ્યાયિત માત્રાત્મક માપદંડ. મોટાભાગની સેવાઓ માટે, કી SLI ને વિનંતી લેટન્સી તરીકે ગણવામાં આવે છે - વિનંતીનો પ્રતિસાદ પરત કરવામાં કેટલો સમય લાગે છે. અન્ય સામાન્ય SLIsમાં ભૂલ દરનો સમાવેશ થાય છે, જે ઘણી વખત પ્રાપ્ત થયેલી તમામ વિનંતીઓના અપૂર્ણાંક તરીકે દર્શાવવામાં આવે છે, અને સિસ્ટમ થ્રુપુટ, સામાન્ય રીતે પ્રતિ સેકન્ડ વિનંતીઓમાં માપવામાં આવે છે.

સૌ પ્રથમ, અમે વિમાનો તોડીશું, અને પછી છોકરીઓ અને પછી છોકરીઓ...

આંતરિક અને બાહ્ય પરિબળોએ પ્રથમ મિનિટથી જ SLO ને "બગાડવાનું" શરૂ કર્યું. બધું જ એડમિનિસ્ટ્રેટર્સના માથા પર પડ્યું - ડેવલપરની ભૂલો, ઇન્ફ્રાસ્ટ્રક્ચર નિષ્ફળતાઓ, મુલાકાતીઓનો ધસારો અને DDoS હુમલા. બધું જે SLO ને બગડે છે.

"- પ્રિય સહભાગીઓ, હું તમને ખુશ કરવા ઉતાવળ કરું છું, તમે નિષ્ફળ થાવ તે પ્રથમ વસ્તુ છે ... બધું!"

રસ્તામાં, વક્તાઓએ સ્થિરતા, ભૂલ બજેટ, પરીક્ષણ પ્રેક્ટિસ, વિક્ષેપોનું સંચાલન અને ઓપરેશનલ લોડ વિશે ચર્ચા કરી.

અમે સ્ટોકર નથી, સુથાર નથી ...

પછી સહભાગીઓએ વસ્તુઓને ઠીક કરવાનું શરૂ કર્યું - મુખ્ય વસ્તુ એ સમજવું છે કે પ્રથમ શું પકડવું.

"- પ્રભુ, મેં તેને આ રીતે, આ સ્વરૂપમાં અને આવી સ્થિતિમાં ક્યારેય તૂટતા જોયા નથી!"

જેથી અકસ્માત સર્જાયો હતો. ચુકવણી પ્રક્રિયા સેવા બંધ છે. ટૂંકી શક્ય સમયમાં કાર્યક્ષમતાને પુનઃસ્થાપિત કરવા માટે કેવી રીતે કાર્ય કરવું?

નિષ્ણાતો, સહભાગીઓને પ્રેમથી જોઈને, બીજી યુક્તિ તૈયાર કરી રહ્યા છે.

દરેક ટીમ અકસ્માતને દૂર કરવા માટે જૂથના કાર્યનું આયોજન કરે છે - સાથીદારોને સામેલ કરે છે, રસ ધરાવતા પક્ષો (હિતધારકો) ને સૂચિત કરે છે. તે જ સમયે, પ્રાથમિકતાઓ સેટ કરવામાં આવે છે. આ રીતે, સહભાગીઓએ અત્યંત મર્યાદિત સમયની પરિસ્થિતિઓમાં દબાણ હેઠળ કામ કરવાની તાલીમ આપી.

"કેવી ભયાનકતા બહાર આવી છે?!"

શ્વાસ બહાર કાઢો... અને કસરત પૂરી કરો

સ્પીકર્સ સાથે મળીને, દરેક સમસ્યાનું નિરાકરણ થયા પછી અને સાઇટને અસ્થાયી રૂપે સ્થિર કરવામાં આવ્યા પછી, ટીમે ઘટનાઓનો SRE દૃષ્ટિકોણથી અભ્યાસ કર્યો. અમે સમસ્યાઓનું વિગતવાર વિશ્લેષણ કર્યું - ઘટનાના કારણો, નાબૂદીની પ્રગતિ. તે પછી, ટીમ-બાય-ટીમ અને સામૂહિક રીતે, અમે તેમને વધુ કેવી રીતે અટકાવવા તે અંગે નિર્ણયો લીધા: મોનિટરિંગમાં કેવી રીતે સુધારો કરવો, આર્કિટેક્ચરને સમજદારીપૂર્વક કેવી રીતે બદલવું, વિકાસ અને કામગીરી માટેના અભિગમને કેવી રીતે સમાયોજિત કરવું, નિયમોને કેવી રીતે સુધારવું. વક્તાઓએ પોસ્ટમોર્ટમ કરાવવાની પ્રથા દર્શાવી હતી.

“બીજું કોને યાતના જોઈએ છે! - હું!"

ઇલેક્ટ્રોનિક સ્કોરબોર્ડ પર ટીમોની સફળતા સખત અને સ્પષ્ટ રીતે નોંધવામાં આવી હતી.

પ્રથમ સ્થાનો માટે - હિતધારકો તરફથી બોનસ.

સોર્સ: www.habr.com