SRE (સાઇટ રિલાયબિલિટી એન્જિનિયરિંગ) એ વેબ પ્રોજેક્ટ્સની ઉપલબ્ધતાને સુનિશ્ચિત કરવાનો અભિગમ છે. તે DevOps માટેનું માળખું માનવામાં આવે છે અને DevOps પ્રેક્ટિસ લાગુ કરવામાં સફળતા કેવી રીતે પ્રાપ્ત કરવી તે વિશે વાત કરે છે. આ લેખમાં અનુવાદ પ્રકરણ 4 સેવા સ્તરના ઉદ્દેશ્યો પુસ્તકો સાઇટ વિશ્વસનીયતા એન્જિનિયરિંગ Google માંથી. મેં આ અનુવાદ જાતે તૈયાર કર્યો અને મોનિટરિંગ પ્રક્રિયાઓને સમજવામાં મારા પોતાના અનુભવ પર આધાર રાખ્યો. ટેલિગ્રામ ચેનલમાં મોનિટરિમ_તે и Habré પર છેલ્લી પોસ્ટ મેં સેવા સ્તરના લક્ષ્યો વિશે સમાન પુસ્તકના પ્રકરણ 6 નો અનુવાદ પણ પ્રકાશિત કર્યો.

બિલાડી દ્વારા અનુવાદ. વાંચનનો આનંદ માણો!

જો ખરેખર કયા સૂચકાંકો મહત્વના છે અને તેનું માપન અને મૂલ્યાંકન કેવી રીતે કરવું તે અંગે કોઈ સમજણ ન હોય તો સેવાનું સંચાલન કરવું અશક્ય છે. આ માટે, અમે અમારા વપરાશકર્તાઓને સેવાના ચોક્કસ સ્તરને વ્યાખ્યાયિત કરીએ છીએ અને પ્રદાન કરીએ છીએ, પછી ભલે તેઓ અમારા આંતરિક API અથવા સાર્વજનિક ઉત્પાદનનો ઉપયોગ કરે.

સર્વિસ લેવલ ઈન્ડિકેટર્સ (SLIs), સર્વિસ લેવલ ઓબ્જેક્ટિવ્સ (SLOs), અને સર્વિસ લેવલ એગ્રીમેન્ટ્સ (SLAs) ને સમજવા માટે અમે અમારા અંતર્જ્ઞાન, અનુભવ અને વપરાશકર્તાઓની ઈચ્છાનો ઉપયોગ કરીએ છીએ. આ પરિમાણો મુખ્ય મેટ્રિક્સનું વર્ણન કરે છે કે જેને અમે મોનિટર કરવા માંગીએ છીએ અને જો અમે અપેક્ષિત ગુણવત્તાની સેવા પ્રદાન ન કરી શકીએ તો અમે પ્રતિક્રિયા કરીશું. આખરે, યોગ્ય મેટ્રિક્સ પસંદ કરવાથી જો કંઈક ખોટું થાય તો યોગ્ય ક્રિયાઓનું માર્ગદર્શન કરવામાં મદદ મળે છે અને SRE ટીમને સેવાના સ્વાસ્થ્યમાં વિશ્વાસ પણ મળે છે.

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

સેવા સ્તરની પરિભાષા

ઘણા વાચકો સંભવતઃ SLA ની વિભાવનાથી પરિચિત છે, પરંતુ SLI અને SLO શબ્દો સાવચેતીપૂર્વક વ્યાખ્યાને પાત્ર છે કારણ કે સામાન્ય રીતે SLA શબ્દ ઓવરલોડ છે અને સંદર્ભના આધારે તેના ઘણા અર્થો છે. સ્પષ્ટતા માટે, અમે આ મૂલ્યોને અલગ કરવા માંગીએ છીએ.

સૂચકાંકો

SLI એ સેવા સ્તરનું સૂચક છે - પૂરી પાડવામાં આવેલ સેવાના સ્તરના એક પાસાની કાળજીપૂર્વક વ્યાખ્યાયિત માત્રાત્મક માપદંડ.

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

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

અન્ય પ્રકારનો SLI કે જે SRE માટે મહત્વપૂર્ણ છે તે છે ઉપલબ્ધતા, અથવા સમયનો તે ભાગ કે જે દરમિયાન સેવાનો ઉપયોગ કરી શકાય છે. ઘણીવાર સફળ વિનંતીઓના દર તરીકે વ્યાખ્યાયિત કરવામાં આવે છે, જેને ક્યારેક ઉપજ કહેવાય છે. (આજીવન-સંભવિતતા કે ડેટાને વિસ્તૃત સમયગાળા માટે જાળવી રાખવામાં આવશે-ડેટા સ્ટોરેજ સિસ્ટમ્સ માટે પણ મહત્વપૂર્ણ છે.) જો કે 100% ઉપલબ્ધતા શક્ય નથી, 100% ની નજીકની ઉપલબ્ધતા ઘણીવાર પ્રાપ્ત કરી શકાય છે; ઉપલબ્ધતા મૂલ્યો તરીકે વ્યક્ત કરવામાં આવે છે "નવ" ની સંખ્યા » ઉપલબ્ધતાની ટકાવારી. ઉદાહરણ તરીકે, 99% અને 99,999% પ્રાપ્યતાને "2 નાઇન્સ" અને "5 નાઇન્સ" તરીકે લેબલ કરવામાં આવી શકે છે. Google Compute Engineનું વર્તમાન જણાવેલ ઉપલબ્ધતા લક્ષ્ય "સાડા ત્રણ નવ" અથવા 99,95% છે.

ઉદ્દેશો

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

યોગ્ય SLO પસંદ કરવી એ એક જટિલ પ્રક્રિયા છે. પ્રથમ, તમે હંમેશા ચોક્કસ મૂલ્ય પસંદ કરી શકતા નથી. તમારી સેવા માટે બાહ્ય ઇનકમિંગ HTTP વિનંતીઓ માટે, ક્વેરી પ્રતિ સેકન્ડ (QPS) મેટ્રિક મુખ્યત્વે તમારી સેવાની મુલાકાત લેવાની તમારા વપરાશકર્તાઓની ઇચ્છા દ્વારા નક્કી કરવામાં આવે છે, અને તમે તેના માટે SLO સેટ કરી શકતા નથી.

બીજી બાજુ, તમે એમ કહી શકો છો કે તમે દરેક વિનંતી માટે સરેરાશ લેટન્સી 100 મિલિસેકન્ડ કરતાં ઓછી હોવી જોઈએ. આવો ધ્યેય સેટ કરવાથી તમને તમારા ફ્રન્ટએન્ડને ઓછી વિલંબતા સાથે લખવા અથવા આવી વિલંબતા પૂરી પાડતા સાધનો ખરીદવાની ફરજ પડી શકે છે. (100 મિલિસેકન્ડ્સ દેખીતી રીતે એક મનસ્વી સંખ્યા છે, પરંતુ ઓછા વિલંબિત સંખ્યાઓ પણ વધુ સારી છે. એવા પુરાવા છે જે સૂચવે છે કે ઝડપી ગતિ ધીમી ગતિ કરતાં વધુ સારી છે, અને ચોક્કસ મૂલ્યોથી ઉપરની વપરાશકર્તા વિનંતીઓ પર પ્રક્રિયા કરવામાં લેટન્સી ખરેખર લોકોને દૂર રહેવા દબાણ કરે છે તમારી સેવામાંથી.)

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

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

કરારો

સેવા સ્તરનો કરાર એ તમારા વપરાશકર્તાઓ સાથેનો સ્પષ્ટ અથવા ગર્ભિત કરાર છે જેમાં તેઓ સમાવિષ્ટ SLO ને મળવાના (અથવા ન મળવાના) પરિણામોનો સમાવેશ કરે છે. પરિણામો સૌથી સહેલાઈથી ઓળખી શકાય છે જ્યારે તે નાણાકીય હોય-ડિસ્કાઉન્ટ અથવા દંડ-પરંતુ તેઓ અન્ય સ્વરૂપો લઈ શકે છે. SLO અને SLA વચ્ચેના તફાવત વિશે વાત કરવાની એક સરળ રીત એ છે કે "જો SLO ન મળે તો શું થશે?" જો ત્યાં કોઈ સ્પષ્ટ પરિણામો નથી, તો તમે લગભગ ચોક્કસપણે SLO જોઈ રહ્યા છો.

SRE સામાન્ય રીતે SLA બનાવવામાં સામેલ નથી કારણ કે SLA વ્યવસાય અને ઉત્પાદનના નિર્ણયો સાથે ગાઢ રીતે જોડાયેલા છે. SRE, જોકે, નિષ્ફળ SLO ના પરિણામોને ઘટાડવામાં મદદ કરવામાં સામેલ છે. તેઓ SLI નક્કી કરવામાં પણ મદદ કરી શકે છે: દેખીતી રીતે, કરારમાં SLO ને માપવા માટે એક ઉદ્દેશ્ય માર્ગ હોવો જોઈએ અથવા મતભેદ હશે.

Google શોધ એ એક મહત્વપૂર્ણ સેવાનું ઉદાહરણ છે કે જેની પાસે સાર્વજનિક SLA નથી: અમે ઈચ્છીએ છીએ કે દરેક વ્યક્તિ શક્ય તેટલી અસરકારક રીતે શોધનો ઉપયોગ કરે, પરંતુ અમે વિશ્વ સાથે કોઈ કરાર પર હસ્તાક્ષર કર્યા નથી. જો કે, જો શોધ અનુપલબ્ધ હોય તો હજુ પણ પરિણામો છે - અનુપલબ્ધતાના પરિણામે અમારી પ્રતિષ્ઠામાં ઘટાડો તેમજ જાહેરાતની આવકમાં ઘટાડો થાય છે. અન્ય ઘણી Google સેવાઓ, જેમ કે Google for Work, વપરાશકર્તાઓ સાથે સ્પષ્ટ સેવા સ્તર કરાર ધરાવે છે. કોઈ ચોક્કસ સેવા પાસે SLA છે કે કેમ તે ધ્યાનમાં લીધા વિના, SLI અને SLO ને વ્યાખ્યાયિત કરવું અને સેવાનું સંચાલન કરવા માટે તેનો ઉપયોગ કરવો મહત્વપૂર્ણ છે.

આટલો સિદ્ધાંત - હવે અનુભવ કરવો.

વ્યવહારમાં સૂચકો

આપેલ છે કે અમે નિષ્કર્ષ પર આવ્યા છીએ કે સેવા સ્તરને માપવા માટે યોગ્ય મેટ્રિક્સ પસંદ કરવાનું મહત્વપૂર્ણ છે, હવે તમે કેવી રીતે જાણો છો કે સેવા અથવા સિસ્ટમ માટે કયા મેટ્રિક્સ મહત્વપૂર્ણ છે?

તમે અને તમારા વપરાશકર્તાઓ શું કાળજી લે છે?

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

SLI ના સંદર્ભમાં સેવાઓને સામાન્ય રીતે કેટલાક ભાગોમાં વિભાજિત કરી શકાય છે જે તેમને સંબંધિત છે:

• કસ્ટમ ફ્રન્ટ-એન્ડ સિસ્ટમ્સ, જેમ કે અમારા ઉદાહરણમાંથી શેક્સપિયર સેવા માટે શોધ ઇન્ટરફેસ. તેઓ ઉપલબ્ધ હોવા જોઈએ, તેમાં કોઈ વિલંબ ન હોવો જોઈએ અને પૂરતી બેન્ડવિડ્થ હોવી જોઈએ. તદનુસાર, પ્રશ્નો પૂછી શકાય છે: શું આપણે વિનંતીનો જવાબ આપી શકીએ? વિનંતીનો જવાબ આપવામાં કેટલો સમય લાગ્યો? કેટલી વિનંતીઓ પર પ્રક્રિયા કરી શકાય છે?
• સ્ટોરેજ સિસ્ટમ્સ. તેઓ ઓછી પ્રતિસાદ વિલંબતા, ઉપલબ્ધતા અને ટકાઉપણુંને મહત્ત્વ આપે છે. સંબંધિત પ્રશ્નો: ડેટા વાંચવા કે લખવામાં કેટલો સમય લાગે છે? શું અમે વિનંતી પર ડેટા ઍક્સેસ કરી શકીએ છીએ? જ્યારે અમને તેની જરૂર હોય ત્યારે શું ડેટા ઉપલબ્ધ છે? આ મુદ્દાઓની વિગતવાર ચર્ચા માટે પ્રકરણ 26 જુઓ ડેટા ઇન્ટિગ્રિટી: તમે જે વાંચો છો તે જ તમે લખો છો.
• ડેટા પ્રોસેસિંગ પાઇપલાઇન્સ જેવી મોટી ડેટા સિસ્ટમ્સ થ્રુપુટ અને ક્વેરી પ્રોસેસિંગ લેટન્સી પર આધાર રાખે છે. સંબંધિત પ્રશ્નો: કેટલા ડેટા પર પ્રક્રિયા કરવામાં આવે છે? વિનંતિ પ્રાપ્ત થવાથી પ્રતિસાદ જારી કરવા સુધીની મુસાફરીમાં ડેટાને કેટલો સમય લાગે છે? (સિસ્ટમના કેટલાક ભાગોમાં ચોક્કસ તબક્કામાં વિલંબ પણ થઈ શકે છે.)

સૂચકોનો સંગ્રહ

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

એકત્રીકરણ

સરળતા અને ઉપયોગમાં સરળતા માટે, અમે ઘણીવાર કાચા માપને એકીકૃત કરીએ છીએ. આ કાળજીપૂર્વક કરવું જોઈએ.

કેટલાક મેટ્રિક્સ સરળ લાગે છે, જેમ કે પ્રતિ સેકન્ડની વિનંતીઓ, પરંતુ આ દેખીતી રીતે સીધું માપ પણ સમય જતાં ડેટાને એકીકૃત કરે છે. શું માપન ખાસ કરીને સેકન્ડ દીઠ એકવાર પ્રાપ્ત થાય છે અથવા પ્રતિ મિનિટ વિનંતીઓની સંખ્યા પર માપન સરેરાશ છે? બાદમાંનો વિકલ્પ માત્ર થોડીક સેકન્ડો જ રહેતી વિનંતીઓની ઘણી ઊંચી સંખ્યાને છુપાવી શકે છે. એક એવી સિસ્ટમનો વિચાર કરો જે સમ સંખ્યાઓ સાથે અને બાકીના સમયે 200 સાથે પ્રતિ સેકન્ડ 0 વિનંતીઓ આપે છે. પ્રતિ સેકન્ડ 100 વિનંતીઓના સરેરાશ મૂલ્યના સ્વરૂપમાં સ્થિર અને બે વાર તાત્કાલિક લોડ સમાન વસ્તુ નથી. તેવી જ રીતે, સરેરાશ ક્વેરી લેટન્સીઝ આકર્ષક લાગે છે, પરંતુ તે એક મહત્વપૂર્ણ વિગત છુપાવે છે: શક્ય છે કે મોટાભાગની ક્વેરીઝ ઝડપી હશે, પરંતુ ઘણી ક્વેરીઝ ધીમી હશે.

મોટાભાગના સૂચકાંકોને સરેરાશ કરતાં વિતરણ તરીકે વધુ સારી રીતે જોવામાં આવે છે. ઉદાહરણ તરીકે, SLI લેટન્સી માટે, કેટલીક વિનંતીઓ પર ઝડપથી પ્રક્રિયા કરવામાં આવશે, જ્યારે કેટલીકમાં હંમેશા વધુ સમય લાગશે, ક્યારેક વધુ સમય લાગશે. એક સરળ સરેરાશ આ લાંબા વિલંબને છુપાવી શકે છે. આકૃતિ એક ઉદાહરણ બતાવે છે: જો કે સામાન્ય વિનંતીને સેવા આપવા માટે લગભગ 50 ms લાગે છે, 5% વિનંતીઓ 20 ગણી ધીમી છે! માત્ર સરેરાશ વિલંબના આધારે દેખરેખ અને ચેતવણી આખા દિવસ દરમિયાન વર્તનમાં ફેરફાર દર્શાવતી નથી, જ્યારે હકીકતમાં કેટલીક વિનંતીઓ (સૌથી ટોચની લાઇન)ની પ્રક્રિયાના સમયમાં નોંધપાત્ર ફેરફારો થાય છે.

50, 85, 95, અને 99 પર્સેન્ટાઇલ સિસ્ટમ લેટન્સી. Y અક્ષ લઘુગણક ફોર્મેટમાં છે.

સૂચકાંકો માટે પર્સન્ટાઇલ્સનો ઉપયોગ કરવાથી તમે વિતરણનો આકાર અને તેની લાક્ષણિકતાઓ જોઈ શકો છો: ઉચ્ચ ટકાવારી સ્તર, જેમ કે 99 અથવા 99,9, સૌથી ખરાબ મૂલ્ય દર્શાવે છે, જ્યારે 50 ટકાવારી (જેને મધ્યક તરીકે પણ ઓળખવામાં આવે છે) સૌથી વધુ વારંવારની સ્થિતિ દર્શાવે છે. મેટ્રિક પ્રતિભાવ સમયનો ફેલાવો જેટલો વધારે છે, તેટલી વધુ લાંબી ચાલતી વિનંતીઓ વપરાશકર્તાના અનુભવને અસર કરે છે. ઉચ્ચ ભાર હેઠળ અને કતારોની હાજરીમાં અસર વધારે છે. વપરાશકર્તા અનુભવ સંશોધન દર્શાવે છે કે લોકો સામાન્ય રીતે ઉચ્ચ પ્રતિભાવ સમયના તફાવત સાથે ધીમી સિસ્ટમ પસંદ કરે છે, તેથી કેટલીક SRE ટીમો માત્ર ઉચ્ચ ટકાવારી સ્કોર્સ પર ધ્યાન કેન્દ્રિત કરે છે, તેના આધારે કે જો 99,9 પર્સેન્ટાઇલ પર મેટ્રિકનું વર્તન સારું હોય, તો મોટાભાગના વપરાશકર્તાઓને સમસ્યાઓનો અનુભવ થશે નહીં. .

આંકડાકીય ભૂલો પર નોંધ

અમે સામાન્ય રીતે મૂલ્યોના સમૂહના સરેરાશ (અંકગણિત સરેરાશ)ને બદલે ટકાવારી સાથે કામ કરવાનું પસંદ કરીએ છીએ. આ અમને વધુ વિખરાયેલા મૂલ્યોને ધ્યાનમાં લેવાની મંજૂરી આપે છે, જે ઘણીવાર સરેરાશ કરતાં નોંધપાત્ર રીતે અલગ (અને વધુ રસપ્રદ) લાક્ષણિકતાઓ ધરાવે છે. કમ્પ્યુટિંગ સિસ્ટમ્સની કૃત્રિમ પ્રકૃતિને લીધે, મેટ્રિક મૂલ્યો ઘણીવાર વિકૃત હોય છે, ઉદાહરણ તરીકે, કોઈપણ વિનંતી 0 ms કરતા ઓછા સમયમાં પ્રતિસાદ પ્રાપ્ત કરી શકતી નથી, અને 1000 ms ની સમય સમાપ્તિનો અર્થ એ છે કે વધુ મૂલ્યો સાથે સફળ પ્રતિસાદ ન હોઈ શકે. સમયસમાપ્તિ કરતાં. પરિણામે, આપણે સ્વીકારી શકતા નથી કે સરેરાશ અને મધ્યક સમાન અથવા એકબીજાની નજીક હોઈ શકે છે!

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

પ્રમાણભૂત સૂચકાંકો

અમે SLI માટે સામાન્ય લાક્ષણિકતાઓને માનક બનાવવાની ભલામણ કરીએ છીએ જેથી તમારે દર વખતે તેમના વિશે અનુમાન ન કરવું પડે. કોઈપણ વિશેષતા કે જે પ્રમાણભૂત પેટર્નને સંતોષે છે તેને વ્યક્તિગત SLI ના સ્પષ્ટીકરણમાંથી બાકાત રાખવામાં આવી શકે છે, ઉદાહરણ તરીકે:

• એકત્રીકરણ અંતરાલો: "સરેરાશ 1 મિનિટથી વધુ"
• એકત્રીકરણ વિસ્તારો: "ક્લસ્ટરમાંના તમામ કાર્યો"
• માપ કેટલી વાર લેવામાં આવે છે: “દર 10 સેકન્ડે”
• કઈ વિનંતીઓ શામેલ છે: "બ્લેક બોક્સ મોનિટરિંગ જોબ્સમાંથી HTTP મેળવો"
• ડેટા કેવી રીતે મેળવવામાં આવે છે: "સર્વર પર માપવામાં આવેલ અમારા મોનિટરિંગ બદલ આભાર"
• ડેટા એક્સેસ લેટન્સી: "છેલ્લી બાઈટનો સમય"

પ્રયત્નો બચાવવા માટે, દરેક સામાન્ય મેટ્રિક માટે ફરીથી વાપરી શકાય તેવા SLI નમૂનાઓનો સમૂહ બનાવો; તેઓ દરેક માટે ચોક્કસ SLI નો અર્થ શું છે તે સમજવાનું સરળ બનાવે છે.

વ્યવહારમાં ગોલ

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

તમારા લક્ષ્યોને વ્યાખ્યાયિત કરો

મહત્તમ સ્પષ્ટતા માટે, SLO ને કેવી રીતે માપવામાં આવે છે અને તે કઈ શરતો હેઠળ માન્ય છે તે વ્યાખ્યાયિત કરવું જોઈએ. ઉદાહરણ તરીકે, અમે નીચેનું કહી શકીએ (બીજી લાઇન પ્રથમ જેવી જ છે, પરંતુ SLI ડિફોલ્ટનો ઉપયોગ કરે છે):

• ગેટ RPC કૉલ્સમાંથી 99% (સરેરાશ 1 મિનિટથી વધુ) 100ms (બધા બેકએન્ડ સર્વર પર માપવામાં આવે છે) કરતાં ઓછા સમયમાં પૂર્ણ થશે.
• ગેટ RPC કૉલ્સમાંથી 99% 100ms કરતાં ઓછા સમયમાં પૂર્ણ થશે.

જો પ્રદર્શન વણાંકોનો આકાર મહત્વપૂર્ણ છે, તો તમે બહુવિધ SLO નો ઉલ્લેખ કરી શકો છો:

• 90% મેળવો RPC કૉલ્સ 1 ms કરતાં ઓછા સમયમાં પૂર્ણ થાય છે.
• 99% મેળવો RPC કૉલ્સ 10 ms કરતાં ઓછા સમયમાં પૂર્ણ થાય છે.
• 99.9% મેળવો RPC કૉલ્સ 100 ms કરતાં ઓછા સમયમાં પૂર્ણ થાય છે.

જો તમારા વપરાશકર્તાઓ વિજાતીય વર્કલોડ જનરેટ કરે છે: બલ્ક પ્રોસેસિંગ (જેના માટે થ્રુપુટ મહત્વપૂર્ણ છે) અને ઇન્ટરેક્ટિવ પ્રોસેસિંગ (જેના માટે લેટન્સી મહત્વપૂર્ણ છે), તો દરેક લોડ વર્ગ માટે અલગ લક્ષ્યો વ્યાખ્યાયિત કરવા યોગ્ય હોઈ શકે છે:

• 95% ગ્રાહક વિનંતીઓને થ્રુપુટની જરૂર છે. એક્ઝિક્યુટ કરેલ RPC કૉલ્સની ગણતરી <1 સે.
• 99% ગ્રાહકો લેટન્સી વિશે કાળજી રાખે છે. ટ્રાફિક <1 KB અને ચાલતા <10 ms સાથે RPC કૉલ્સની ગણતરી સેટ કરો.

SLO ને 100% વખત મળવાનો આગ્રહ રાખવો અવાસ્તવિક અને અનિચ્છનીય છે: આ નવી કાર્યક્ષમતા અને જમાવટની રજૂઆતની ગતિને ઘટાડી શકે છે અને ખર્ચાળ ઉકેલોની જરૂર છે. તેના બદલે, ભૂલ બજેટને મંજૂરી આપવી વધુ સારું છે - સિસ્ટમ ડાઉનટાઇમની ટકાવારી મંજૂર - અને આ મૂલ્યનું દૈનિક અથવા સાપ્તાહિક નિરીક્ષણ કરો. વરિષ્ઠ મેનેજમેન્ટ માસિક અથવા ત્રિમાસિક મૂલ્યાંકન ઇચ્છે છે. (ભૂલ બજેટ એ અન્ય SLO સાથે સરખામણી કરવા માટે એક SLO છે.)

SLO ઉલ્લંઘનની ટકાવારી ભૂલ બજેટ સાથે સરખાવી શકાય છે (જુઓ પ્રકરણ 3 અને વિભાગ "ભૂલ બજેટ માટે પ્રેરણા"), પ્રક્રિયામાં ઇનપુટ તરીકે ઉપયોગમાં લેવાતા તફાવત મૂલ્ય સાથે કે જે નક્કી કરે છે કે નવા પ્રકાશનો ક્યારે જમાવવા.

લક્ષ્ય મૂલ્યો પસંદ કરી રહ્યા છીએ

ઉત્પાદન અને વ્યવસાયિક હિતોને કારણે આયોજન મૂલ્યો (SLOs) પસંદ કરવી એ સંપૂર્ણ તકનીકી પ્રવૃત્તિ નથી જે પસંદ કરેલ SLIs, SLOs (અને સંભવતઃ SLAs) માં પ્રતિબિંબિત થવી જોઈએ. તેવી જ રીતે, સ્ટાફિંગ, બજાર માટેનો સમય, સાધનસામગ્રીની ઉપલબ્ધતા અને ધિરાણ સંબંધિત મુદ્દાઓ અંગે માહિતીની આપ-લે કરવાની જરૂર પડી શકે છે. SRE એ આ વાર્તાલાપનો ભાગ હોવો જોઈએ અને વિવિધ વિકલ્પોના જોખમો અને સદ્ધરતાને સમજવામાં મદદ કરવી જોઈએ. અમે થોડા પ્રશ્નો લઈને આવ્યા છીએ જે વધુ ઉત્પાદક ચર્ચાને સુનિશ્ચિત કરવામાં મદદ કરી શકે છે:

વર્તમાન પ્રદર્શનના આધારે લક્ષ્ય પસંદ કરશો નહીં.
જ્યારે સિસ્ટમની શક્તિઓ અને મર્યાદાઓને સમજવી મહત્વપૂર્ણ છે, ત્યારે તર્ક વિના મેટ્રિક્સને અનુકૂલન કરવાથી તમને સિસ્ટમ જાળવવાથી અવરોધિત કરી શકાય છે: તે લક્ષ્યોને પ્રાપ્ત કરવા માટે પરાક્રમી પ્રયત્નોની જરૂર પડશે જે નોંધપાત્ર પુનઃડિઝાઇન વિના પ્રાપ્ત કરી શકાશે નહીં.

તે સરળ રાખો
જટિલ SLI ગણતરીઓ સિસ્ટમની કામગીરીમાં ફેરફારોને છુપાવી શકે છે અને સમસ્યાનું કારણ શોધવાનું મુશ્કેલ બનાવે છે.

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

બને તેટલા ઓછા SLO નો ઉપયોગ કરો
સિસ્ટમ વિશેષતાઓના સારા કવરેજની ખાતરી કરવા માટે પૂરતી સંખ્યામાં SLO પસંદ કરો. તમે પસંદ કરો છો તે SLO ને સુરક્ષિત કરો: જો તમે ચોક્કસ SLO નો ઉલ્લેખ કરીને અગ્રતા વિશેની દલીલ ક્યારેય જીતી શકતા નથી, તો તે SLO ને ધ્યાનમાં લેવું કદાચ યોગ્ય નથી. જો કે, તમામ સિસ્ટમ વિશેષતાઓ SLO માટે યોગ્ય નથી: SLO નો ઉપયોગ કરીને વપરાશકર્તાના આનંદના સ્તરની ગણતરી કરવી મુશ્કેલ છે.

પૂર્ણતાનો પીછો ન કરો
તમે હંમેશા SLO ની વ્યાખ્યાઓ અને ધ્યેયોને સમયાંતરે સુધારી શકો છો કારણ કે તમે લોડ હેઠળના સિસ્ટમના વર્તન વિશે વધુ શીખો છો. વધુ પડતા કડક ધ્યેયને પસંદ કરવા કરતાં ફ્લોટિંગ ધ્યેય સાથે પ્રારંભ કરવું વધુ સારું છે કે જેને તમે પ્રાપ્ય ન જણાય ત્યારે હળવા થવું પડે.

SLOs SREs અને ઉત્પાદન વિકાસકર્તાઓ માટે કાર્યને પ્રાથમિકતા આપવા માટે મુખ્ય ડ્રાઈવર બની શકે છે અને હોવા જોઈએ કારણ કે તેઓ વપરાશકર્તાઓ માટે ચિંતા દર્શાવે છે. સારો SLO એ વિકાસ ટીમ માટે ઉપયોગી અમલીકરણ સાધન છે. પરંતુ જો ટીમ વધુ પડતી આક્રમક SLO હાંસલ કરવા માટે પરાક્રમી પ્રયાસો કરે અથવા SLO ખૂબ નીચું હોય તો નબળું ઉત્પાદન જો નબળી રીતે ડિઝાઇન કરેલ SLO વ્યર્થ કાર્ય તરફ દોરી શકે છે. SLO એ એક શક્તિશાળી લીવર છે, તેનો સમજદારીપૂર્વક ઉપયોગ કરો.

તમારા માપને નિયંત્રિત કરો

SLI અને SLO એ સિસ્ટમનું સંચાલન કરવા માટે વપરાતા મુખ્ય ઘટકો છે:

• SLI સિસ્ટમ્સનું નિરીક્ષણ કરો અને માપો.
• SLI ને SLO સાથે સરખાવો અને નક્કી કરો કે શું કાર્યવાહી જરૂરી છે.
• જો ક્રિયા જરૂરી હોય, તો ધ્યેય હાંસલ કરવા માટે શું કરવાની જરૂર છે તે શોધો.
• આ ક્રિયા પૂર્ણ કરો.

ઉદાહરણ તરીકે, જો પગલું 2 બતાવે છે કે વિનંતીનો સમય સમાપ્ત થઈ ગયો છે અને જો કંઈ કરવામાં ન આવે તો થોડા કલાકોમાં SLO તોડી નાખશે, તો પગલું 3 એ પૂર્વધારણાનું પરીક્ષણ શામેલ હોઈ શકે છે કે સર્વર્સ CPU બંધાયેલા છે અને વધુ સર્વર્સ ઉમેરવાથી લોડનું વિતરણ થશે. SLO વિના, તમે જાણતા નથી કે શું (અથવા ક્યારે) પગલાં લેવા.

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

તમારા વપરાશકર્તાઓ માટે વાસ્તવિક અપેક્ષાઓ સેટ કરવા માટે, નીચેની એક અથવા બંને યુક્તિઓનો ઉપયોગ કરો:

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

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

વ્યવહારમાં કરારો

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

અંત સુધી અનુવાદ વાંચવા બદલ આભાર. મોનિટરિંગ વિશે મારી ટેલિગ્રામ ચેનલ પર સબ્સ્ક્રાઇબ કરો મોનિટરિમ_તે и માધ્યમ પર બ્લોગ.

સોર્સ: www.habr.com