ફરી એકવાર DevOps અને SRE વિશે

ચેટ ચર્ચા પર આધારિત AWS મિન્સ્ક સમુદાય

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

પ્રાગૈતિહાસિક

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

DevOps પ્રેક્ટિસનો જન્મ

પછી ગંભીર લોકો આવ્યા અને કહ્યું - આ કોઈ ઉદ્યોગ નથી, તમે આ રીતે કામ કરી શકતા નથી. અને તેઓ જીવન ચક્રના મોડલ લાવ્યા. અહીં, ઉદાહરણ તરીકે, વી-મોડેલ છે.

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

પ્રેક્ટિસ શું છે તેના વિષય પર ગીતાત્મક વિષયાંતર
પ્રેક્ટિસ દ્વારા મારો અર્થ ટેકનોલોજી અને શિસ્તનું સંયોજન છે. ટેરાફોર્મ કોડનો ઉપયોગ કરીને ઇન્ફ્રાસ્ટ્રક્ચરનું વર્ણન કરવાની પ્રથા એક ઉદાહરણ છે. શિસ્ત એ છે કે કોડ સાથે ઇન્ફ્રાસ્ટ્રક્ચરનું વર્ણન કેવી રીતે કરવું, તે વિકાસકર્તાના માથામાં છે, અને ટેક્નોલોજી એ ટેરાફોર્મ છે.

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

તે બધું ફરીથી સારું નથી, ભગવાનનો આભાર

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

Google દ્વારા SRE

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

DevOps વિચારોનો વિકાસ

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

SRE Google પર નથી

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

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

સોર્સ: www.habr.com