વેબિનારનું ટ્રાન્સક્રિપ્શન "SRE - હાઇપ અથવા ભવિષ્ય?"

વેબિનારમાં ખરાબ ઑડિયો છે, તેથી અમે ટ્રાન્સક્રિપ્ટ બનાવી છે.

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

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

સમસ્યા એ છે કે અમારી પાસે DevOpsની સ્પષ્ટ વ્યાખ્યા અને DevOpsનું સ્પષ્ટ અમલીકરણ નથી. મેં 2 વર્ષ પહેલાં યેકાટેરિનબર્ગમાં એક કોન્ફરન્સમાં વાત કરી હતી અને અત્યાર સુધી DevOps વિભાગ “DevOps શું છે” રિપોર્ટ સાથે શરૂ થયો હતો. 2017 માં, ડેવોપ્સ લગભગ 10 વર્ષનો છે, પરંતુ અમે હજી પણ તે શું છે તે વિશે દલીલ કરી રહ્યા છીએ. અને આ એક ખૂબ જ વિચિત્ર પરિસ્થિતિ છે જેને ગૂગલે થોડા વર્ષો પહેલા હલ કરવાનો પ્રયાસ કર્યો હતો.

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

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

તેઓ પૂછે છે કે શું SRE અને devops વચ્ચેનો તફાવત વર્ણવવામાં આવશે. તેણીનું હમણાં જ વર્ણન કરવામાં આવ્યું છે. અમે સંસ્થામાં SRE ના સ્થાન વિશે વાત કરી શકીએ છીએ. ક્લાસિક DevOps અભિગમથી વિપરીત, જ્યાં Ops હજુ પણ એક અલગ વિભાગ છે, SRE એ વિકાસ ટીમનો ભાગ છે. તેઓ ઉત્પાદન વિકાસમાં સામેલ છે. ત્યાં પણ એક અભિગમ છે જ્યાં SRE એ ભૂમિકા છે જે એક વિકાસકર્તાથી બીજામાં પસાર થાય છે. તેઓ કોડ રિવ્યૂમાં એ જ રીતે ભાગ લે છે જેમ કે, ઉદાહરણ તરીકે, UX ડિઝાઇનર્સ, પોતે ડેવલપર્સ અને ક્યારેક પ્રોડક્ટ મેનેજર. SRE આ જ સ્તરે કાર્ય કરે છે. અમને તેમની મંજૂરીની જરૂર છે, અમને તેમની સમીક્ષાની જરૂર છે, જેથી દરેક જમાવટ માટે SRE કહે છે: “ઠીક છે, આ જમાવટ, આ ઉત્પાદન વિશ્વસનીયતાને નકારાત્મક અસર કરશે નહીં. અને જો તે થાય, તો તે કેટલીક સ્વીકાર્ય મર્યાદાઓની અંદર હશે. અમે આ વિશે પણ વાત કરીશું.

તદનુસાર, SRE કોડ ફેરફારો પર વીટો ધરાવે છે. અને સામાન્ય રીતે, જો SRE ખોટી રીતે લાગુ કરવામાં આવે તો આ કેટલાક નાના સંઘર્ષ તરફ દોરી જાય છે. સાઇટ વિશ્વસનીયતા એન્જિનિયરિંગ વિશેના તે જ પુસ્તકમાં, ઘણા ભાગો, એક કરતાં વધુ, આ સંઘર્ષોને કેવી રીતે ટાળવા તે જણાવે છે.

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

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

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

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

આ બધું ખોટું છે, અલબત્ત. અને આ લોકોને વ્યવહારમાં આ પ્રકારના કોડથી ઘણી વાર નુકસાન થાય છે, કારણ કે વસ્તુઓ તૂટી જાય છે. વસ્તુઓ ક્યારેક સૌથી અણધારી રીતે તૂટી જાય છે. કેટલીકવાર લોકો કહે છે કે ના, તે ક્યારેય થશે નહીં. અને તે હજુ પણ થાય છે. ઘણી વાર થાય છે. અને તેથી જ કોઈ ક્યારેય 100% ઉપલબ્ધતા માટે પ્રયત્ન કરતું નથી, કારણ કે 100% ઉપલબ્ધતા ક્યારેય થતી નથી. આ ધોરણ છે. અને તેથી જ જ્યારે અમે સેવાની ઉપલબ્ધતા વિશે વાત કરીએ છીએ ત્યારે અમે હંમેશા નાઈન વિશે વાત કરીએ છીએ. 2 નાઇન્સ, 3 નાઇન્સ, 4 નાઇન્સ, 5 નાઇન્સ. જો આપણે આને ડાઉનટાઇમ સમયમાં ભાષાંતર કરીએ, તો, ઉદાહરણ તરીકે, 5 નાઇન એ દર વર્ષે 5 મિનિટના ડાઉનટાઇમ કરતાં થોડો વધારે છે, 2 નાઇન એ 3,5 દિવસનો ડાઉનટાઇમ છે.

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

એક મહત્વપૂર્ણ પ્રશ્ન એ છે કે બાકીના ઘટકોની વિશ્વસનીયતા શું છે. કારણ કે 4 અને 5 નાઈન વચ્ચેનો તફાવત 2 વિશ્વસનીયતા નાઈનવાળા સ્માર્ટફોન પર દેખાશે નહીં. આશરે કહીએ તો, જો વર્ષમાં 10 વખત તમારી સેવામાં સ્માર્ટફોન પર કંઈક તૂટી જાય છે, તો સંભવતઃ 8 વખત OS બાજુ પર બ્રેકડાઉન થયું છે. વપરાશકર્તા આ માટે વપરાય છે, અને વર્ષમાં એક વધારાનો સમય તેના પર ધ્યાન આપશે નહીં. વધતી વિશ્વસનીયતા અને નફામાં વધારો કરવાની કિંમતની તુલના કરવી જરૂરી છે.
ફક્ત SRE પરના પુસ્તકમાં 4 નાઇનથી 3 નાઇન્સમાં વધારો કરવાનું એક સારું ઉદાહરણ છે. તે તારણ આપે છે કે ઉપલબ્ધતામાં વધારો 0,1% કરતા થોડો ઓછો છે. અને જો સેવાની આવક દર વર્ષે $1 મિલિયન છે, તો આવકમાં વધારો $900 છે. જો નવ દ્વારા ઉપલબ્ધતામાં વધારો કરવાથી દર વર્ષે $900 કરતાં ઓછો ખર્ચ થાય છે, તો વધારો નાણાકીય અર્થમાં છે. જો તેનો વાર્ષિક ખર્ચ $900 કરતાં વધુ હોય, તો તેનો અર્થ હવે રહેતો નથી, કારણ કે આવકમાં વધારો ફક્ત શ્રમ ખર્ચ અને સંસાધન ખર્ચની ભરપાઈ કરતું નથી. અને 3 નાઈન આપણા માટે પૂરતા હશે.

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

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

ચાલો કહીએ કે SLA આના જેવું હોઈ શકે છે. આ સેવા સમગ્ર વર્ષ દરમિયાન 99,95% સમય ઉપલબ્ધ છે. અથવા 99 ક્રિટિકલ ટેક્નિકલ સપોર્ટ ટિકિટ પ્રતિ ક્વાર્ટરમાં 3 કલાકની અંદર બંધ થઈ જશે. અથવા 85% પ્રશ્નોના જવાબ દર મહિને 1,5 સેકન્ડની અંદર આપવામાં આવશે. એટલે કે, આપણે ધીરે ધીરે સમજી રહ્યા છીએ કે ભૂલો અને નિષ્ફળતા એકદમ સામાન્ય છે. આ એક સ્વીકાર્ય પરિસ્થિતિ છે, અમે તેના માટે આયોજન કરી રહ્યા છીએ, અમે તેના પર અમુક અંશે ગણતરી પણ કરી રહ્યા છીએ. એટલે કે, SRE એવી સિસ્ટમ્સ બનાવે છે જે ભૂલો કરી શકે છે, જે ભૂલોને સામાન્ય રીતે પ્રતિસાદ આપવી જોઈએ, અને તેને ધ્યાનમાં લેવી જોઈએ. અને જો શક્ય હોય તો, તેઓએ ભૂલોને એવી રીતે હેન્ડલ કરવી જોઈએ કે વપરાશકર્તા કાં તો તેમની નોંધ ન કરે, અથવા તેમની નોંધ લે, પરંતુ ત્યાં એક પ્રકારનો ઉપાય છે જેથી બધું સંપૂર્ણપણે અલગ ન થઈ જાય.

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

આગળની શરતો કે જેના વિશે આપણે વાત કરીશું, જે વિશ્વસનીયતા સાથે, ભૂલો સાથે, અપેક્ષાઓ સાથે કામ કરવા માટે ખૂબ જ મહત્વપૂર્ણ છે, તે છે MTBF અને MTTR. MTBF નિષ્ફળતાઓ વચ્ચેનો સરેરાશ સમય છે. MTTR એટલે પુનઃપ્રાપ્તિ માટેનો સમય, પુનઃપ્રાપ્તિ માટે સરેરાશ સમય. એટલે કે, ભૂલ શોધાઈ તે ક્ષણથી કેટલો સમય પસાર થયો, ભૂલ દેખાય તે ક્ષણથી સેવા સંપૂર્ણપણે સામાન્ય કામગીરીમાં પુનઃસ્થાપિત થઈ ત્યાં સુધી. MTBF મુખ્યત્વે કોડ ગુણવત્તા પર કામ કરીને સુધારેલ છે. એટલે કે, હકીકત એ છે કે SRE "ના" કહી શકે છે. અને આખી ટીમે એ સમજવાની જરૂર છે કે જ્યારે SRE “ના” કહે છે, ત્યારે તે કહે છે કે તે હાનિકારક છે, એટલા માટે નહીં કે તે ખરાબ છે, પરંતુ એટલા માટે કે અન્યથા દરેકને નુકસાન થશે.

ફરીથી, ઘણા બધા લેખો છે, ઘણી બધી પદ્ધતિઓ છે, ઘણી બધી રીતો છે, તે પુસ્તકમાં પણ કે જેનો હું વારંવાર ઉલ્લેખ કરું છું, કેવી રીતે ખાતરી કરવી કે અન્ય વિકાસકર્તાઓ SRE ને નફરત કરવાનું શરૂ ન કરે. MTTR, બીજી બાજુ, તમારા SLO (સર્વિસ લેવલ ઓબ્જેક્ટિવ) પર કામ કરવા વિશે છે. અને આ મોટે ભાગે ઓટોમેશન છે. કારણ કે, ઉદાહરણ તરીકે, અમારો SLO એ ક્વાર્ટર દીઠ 4 નાઈનનો અપટાઇમ છે. આનો અર્થ એ છે કે 3 મહિનામાં અમે 13 મિનિટનો ડાઉનટાઇમ આપી શકીએ છીએ. અને તે તારણ આપે છે કે અમારું MTTR સંભવતઃ 13 મિનિટથી વધુ ન હોઈ શકે. જો આપણે ઓછામાં ઓછા 13 ડાઉનટાઇમ પર પ્રતિક્રિયા આપવા માટે 1 મિનિટનો સમય લઈએ, તો તેનો અર્થ એ છે કે અમે ક્વાર્ટર માટેનું આખું બજેટ પહેલેથી જ ખતમ કરી દીધું છે. અમે SLOનું ઉલ્લંઘન કરી રહ્યા છીએ. નિષ્ફળતા પર પ્રતિક્રિયા આપવા અને તેને સુધારવા માટે 13 મિનિટનો સમય મશીન માટે ઘણો છે, પરંતુ વ્યક્તિ માટે બહુ ઓછો છે. કારણ કે જ્યારે કોઈ વ્યક્તિ ચેતવણી મેળવે છે, જ્યારે તે પ્રતિક્રિયા આપે છે, જ્યારે તે ભૂલને શોધી કાઢે છે, તે પહેલાથી જ થોડી મિનિટો છે. જ્યાં સુધી કોઈ વ્યક્તિ સમજે નહીં કે તેને કેવી રીતે ઠીક કરવું, બરાબર શું ઠીક કરવું, શું કરવું, તે થોડી વધુ મિનિટ લેશે. અને હકીકતમાં, જો તમારે ફક્ત સર્વરને રીબૂટ કરવાની જરૂર હોય, જેમ કે તે બહાર આવ્યું છે, અથવા નવો નોડ વધારવો, તો MTTR મેન્યુઅલી લગભગ 7-8 મિનિટ લે છે. પ્રક્રિયાને સ્વચાલિત કરતી વખતે, MTTR ઘણી વાર એક સેકન્ડ સુધી પહોંચે છે, ક્યારેક મિલિસેકન્ડમાં. Google સામાન્ય રીતે મિલિસેકન્ડ્સ વિશે વાત કરે છે, પરંતુ વાસ્તવમાં, અલબત્ત, વસ્તુઓ એટલી સારી નથી.

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

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

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

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

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

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

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

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

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

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

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

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

તદનુસાર, દેખરેખનું નિરીક્ષણ અને સંગઠન કોઈપણ કદની કંપની માટે ઉપયોગી છે. અને સામાન્ય રીતે, વિચારવાની આ રીત, જ્યાં ભૂલો સ્વીકાર્ય છે, જ્યાં બજેટ છે, જ્યાં ઉદ્દેશ્ય અસ્તિત્વમાં છે, 3-વ્યક્તિના સ્ટાર્ટઅપથી શરૂ કરીને, કોઈપણ કદની કંપની માટે ફરીથી ઉપયોગી છે.

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

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

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

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

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

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

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

SRE સાધનો વિશે એક પ્રશ્ન હતો. એટલે કે, શું એવી કોઈ વિશિષ્ટ વસ્તુ છે કે જે SREs નો ઉપયોગ કરશે જે બીજા બધા નહિ કરે? હકીકતમાં, કેટલીક ઉચ્ચ વિશિષ્ટ ઉપયોગિતાઓ છે, કેટલાક સોફ્ટવેર છે જે, ઉદાહરણ તરીકે, લોડનું અનુકરણ કરે છે અથવા કેનેરી A/B પરીક્ષણ કરે છે. પરંતુ મૂળભૂત રીતે, SRE ટૂલિંગ એ છે જેનો તમારા વિકાસકર્તાઓ પહેલેથી ઉપયોગ કરી રહ્યાં છે. કારણ કે SRE વિકાસ ટીમ સાથે સીધો સંપર્ક કરે છે. અને જો તમારી પાસે વિવિધ સાધનો છે, તો તે તારણ આપે છે કે તે સિંક્રનાઇઝ થવામાં સમય લે છે. ખાસ કરીને જો SRE મોટી ટીમોમાં કામ કરે છે, મોટી કંપનીઓમાં જ્યાં ઘણી ટીમો હોઈ શકે છે, કંપની-વ્યાપી માનકીકરણ અહીં ખૂબ મદદરૂપ થશે, કારણ કે જો 50 ટીમો 50 વિવિધ ઉપયોગિતાઓનો ઉપયોગ કરે છે, તો તેનો અર્થ એ કે SRE એ તે બધાને જાણવું જ જોઈએ. અને અલબત્ત આ ક્યારેય થશે નહીં. અને કામની ગુણવત્તા, ઓછામાં ઓછી કેટલીક ટીમોના નિયંત્રણની ગુણવત્તામાં નોંધપાત્ર ઘટાડો થશે.

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

Slurm SRE એ ત્રણ દિવસનો સઘન અભ્યાસક્રમ છે જે લગભગ હું જેની વાત કરી રહ્યો છું તેને આવરી લેશે, પરંતુ વધુ ઊંડાણ સાથે, વાસ્તવિક કેસો સાથે, પ્રેક્ટિસ સાથે, સમગ્ર સઘન અભ્યાસક્રમ વ્યવહારિક કાર્યને ધ્યાનમાં રાખીને કરવામાં આવ્યો છે. લોકોને ટીમોમાં વહેંચવામાં આવશે. તમે બધા વાસ્તવિક કેસ પર કામ કરશો. તદનુસાર, અમારી પાસે Booking.com ઇવાન ક્રુગ્લોવ અને બેન ટાયલરના પ્રશિક્ષકો છે. અમારી પાસે સાન ફ્રાન્સિસ્કોથી Google તરફથી એક અદ્ભુત Evgeniy Varabbas છે. અને હું તમને પણ કંઈક કહીશ. તો અચૂક અમારી મુલાકાત લો.
તેથી, સંદર્ભોની સૂચિ. SRE પર લિંક્સ છે. પ્રથમ તે જ પુસ્તક પર, અથવા તેના બદલે SRE વિશે 2 પુસ્તકો પર, Google દ્વારા લખાયેલ. બીજો કોઈ SLA, SLI, SLO પર નાનો લેખ, જ્યાં શરતો અને તેમની અરજીને થોડી વધુ વિગતમાં સમજાવવામાં આવી છે. આગામી 3 વિવિધ કંપનીઓમાં SRE પરના અહેવાલો છે. પ્રથમ - SRE માટે કીઓ, આ Google ના બેન ટ્રેનરની મુખ્ય નોંધ છે. બીજું - ડ્રૉપબૉક્સ પર SRE. ત્રીજા વિશે ફરી છે Google પર SRE. થી ચોથો અહેવાલ Netflix પર SRE, જેની પાસે 5 દેશોમાં માત્ર 190 મુખ્ય SRE કર્મચારીઓ છે. આ બધું જોવું ખૂબ જ રસપ્રદ છે, કારણ કે જેમ DevOps નો અર્થ જુદી જુદી કંપનીઓ અને અલગ-અલગ ટીમો માટે ખૂબ જ અલગ વસ્તુઓ છે, SRE પાસે સમાન કદની કંપનીઓમાં પણ ઘણી અલગ જવાબદારીઓ છે.

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

રસપ્રદ લેખ: જીવન પસંદગી તરીકે SRE

આટલો સમય મને સાંભળવા બદલ આભાર. હું આશા રાખું છું કે તમે કંઈક શીખ્યા. હું આશા રાખું છું કે તમારી પાસે હજી વધુ શીખવા માટે પૂરતી સામગ્રી હશે. અને પછી મળીશું. આશા છે કે ફેબ્રુઆરીમાં.
વેબિનારનું આયોજન એડ્યુઅર્ડ મેદવેદેવ દ્વારા કરવામાં આવ્યું હતું.

પીએસ: જેઓ વાંચવાનું પસંદ કરે છે, એડ્યુઅર્ડે સંદર્ભોની સૂચિ પ્રદાન કરી છે. જેઓ તેને વ્યવહારમાં સમજવાનું પસંદ કરે છે તેઓનું સ્વાગત છે Slurme SRE.

સોર્સ: www.habr.com