DevOps કોણ છે?

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

અમે હજુ પણ સહકાર્યકરોને શોધી રહ્યા છીએ, કારણ કે DevOps લેબલની પાછળ વિવિધ પ્રકારના એન્જિનિયરોનું એક ખૂબ મોટું સ્તર છુપાયેલું છે.

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

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

તો DevOps એન્જિનિયરો કોણ છે?

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

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

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

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

ચોક્કસ સંસાધનના નિષ્ણાત જ્ઞાનના સ્તરમાં સમાન "સ્વિંગ" આજે પણ ચાલુ છે. પરંતુ આપણે થોડું વિષયાંતર કરીએ છીએ, ત્યાં ઘણા બધા મુદ્દાઓ છે જે પ્રકાશિત કરવા યોગ્ય છે.

બિલ્ડ એન્જિનિયર/રિલીઝ એન્જિનિયર

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

ઓપ્સ ખૂબ અલગ છે

અમે આગળ વધીએ છીએ અને જવાબદારીઓની વિશાળ શ્રેણીની હાજરી અને લાયકાત ધરાવતા કર્મચારીઓની અછત અમને સખત વિશેષતા તરફ ધકેલે છે, જેમ કે વરસાદ પછી મશરૂમ્સ, વિવિધ કામગીરી દેખાય છે:

• TechOps - enikey સિસ્ટમ એડમિનિસ્ટ્રેટર્સ ઉર્ફ હેલ્પડેસ્ક એન્જિનિયર
• LiveOps - સિસ્ટમ એડમિનિસ્ટ્રેટર્સ મુખ્યત્વે ઉત્પાદન વાતાવરણ માટે જવાબદાર છે
• CloudOps - જાહેર વાદળો Azure, AWS, GCP, વગેરેમાં વિશેષતા ધરાવતા સિસ્ટમ સંચાલકો.
• PlatOps/InfraOps/SysOps - ઈન્ફ્રાસ્ટ્રક્ચર સિસ્ટમ એડમિનિસ્ટ્રેટર્સ.
• નેટઓપ્સ - નેટવર્ક એડમિનિસ્ટ્રેટર્સ
• સેકઓપ્સ - માહિતી સુરક્ષામાં વિશેષતા ધરાવતા સિસ્ટમ સંચાલકો - પીસીઆઈ અનુપાલન, સીઆઈએસ અનુપાલન, પેચિંગ, વગેરે.

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

આ પ્રકારનું કાર્ય અને જવાબદારીઓ કરવા માટે, આ વ્યક્તિ પાસે માત્ર વિકાસ અને પરીક્ષણ પ્રક્રિયાઓ જ નહીં, પણ ઉત્પાદન ઈન્ફ્રાસ્ટ્રક્ચર તેમજ સંસાધન આયોજનનું સંચાલન કરવા માટેના સાધનો હોવા જોઈએ. આ સમજણમાં DevOps ક્યાં તો ITમાં, અથવા R&Dમાં, અથવા તો PMOમાં પણ સ્થિત ન હોઈ શકે; આ તમામ ક્ષેત્રોમાં તેનો પ્રભાવ હોવો જોઈએ - કંપનીના ટેકનિકલ ડિરેક્ટર, ચીફ ટેકનિકલ ઓફિસર.

શું તમારી કંપનીમાં આ સાચું છે? - મને શંકા છે. મોટા ભાગના કિસ્સાઓમાં, આ કાં તો IT અથવા R&D છે.

ભંડોળની અછત અને પ્રવૃત્તિના આ ત્રણ ક્ષેત્રોમાંથી ઓછામાં ઓછા એકને પ્રભાવિત કરવાની ક્ષમતા સમસ્યાઓના વજનને જ્યાં આ ફેરફારો લાગુ કરવા માટે સરળ છે તે તરફ ખસેડશે, જેમ કે સ્ટેટિક અનુસાર "ગંદા" કોડના સંબંધમાં રિલીઝ પર તકનીકી પ્રતિબંધોનો ઉપયોગ. વિશ્લેષક સિસ્ટમો. એટલે કે, જ્યારે PMO કાર્યક્ષમતાના પ્રકાશન માટે સખત સમયમર્યાદા નક્કી કરે છે, ત્યારે R&D આ સમયમર્યાદાની અંદર ઉચ્ચ-ગુણવત્તાવાળા પરિણામ આપી શકતું નથી અને તે શક્ય તેટલું શ્રેષ્ઠ ઉત્પાદન કરી શકે છે, પાછળથી રિફૅક્ટરિંગને છોડી દે છે, IT સંબંધિત DevOps તકનીકી માધ્યમોનો ઉપયોગ કરીને રિલીઝને અવરોધે છે. . પરિસ્થિતિને બદલવાની સત્તાનો અભાવ, જવાબદાર કર્મચારીઓના કિસ્સામાં, તેઓ જેને પ્રભાવિત કરી શકતા નથી તેના માટે અતિ-જવાબદારીના અભિવ્યક્તિ તરફ દોરી જાય છે, ખાસ કરીને જો આ કર્મચારીઓ ભૂલો સમજે અને જુએ, અને તેમને કેવી રીતે સુધારવું - "આનંદ એ અજ્ઞાન છે", અને આ કર્મચારીઓના બર્નઆઉટ અને નુકસાનના પરિણામે.

DevOps સંસાધન બજાર

ચાલો વિવિધ કંપનીઓમાંથી DevOps હોદ્દાઓ માટે ઘણી ખાલી જગ્યાઓ જોઈએ.

અમે તમારી સાથે મળવા માટે તૈયાર છીએ જો તમે:

1. તમે Zabbix ધરાવો છો અને જાણો છો કે પ્રોમિથિયસ શું છે;
2. Iptables;
3. BASH પીએચડી વિદ્યાર્થી;
4. પ્રોફેસર જવાબી;
5. Linux ગુરુ;
6. ડીબગીંગનો ઉપયોગ કેવી રીતે કરવો અને વિકાસકર્તાઓ (php/java/python) સાથે મળીને એપ્લિકેશન સમસ્યાઓ કેવી રીતે શોધવી તે જાણો;
7. રૂટીંગ તમને ઉન્માદ બનાવતું નથી;
8. સિસ્ટમ સુરક્ષા પર નોંધપાત્ર ધ્યાન આપો;
9. "કંઈપણ અને બધું" બેકઅપ લો, અને આ "કંઈપણ અને બધું" સફળતાપૂર્વક પુનઃસ્થાપિત કરો;
10. તમે જાણો છો કે સિસ્ટમને એવી રીતે કેવી રીતે રૂપરેખાંકિત કરવી કે લઘુત્તમમાંથી મહત્તમ મેળવવા માટે;
11. Postgres અને MySQL પર સૂતા પહેલા પ્રતિકૃતિ સેટ કરો;
12. CI/CD સેટઅપ અને એડજસ્ટ કરવું તમારા માટે નાસ્તો/લંચ/ડિનર જેટલું જરૂરી છે.
13. AWS સાથે અનુભવ છે;
14. કંપની સાથે વિકાસ માટે તૈયાર;

તેથી:

• 1 થી 6 સુધી - સિસ્ટમ એડમિનિસ્ટ્રેટર
• 7 - થોડું નેટવર્ક એડમિનિસ્ટ્રેશન, જે સિસ્ટમ એડમિનિસ્ટ્રેટર, મિડલ લેવલમાં પણ બંધબેસે છે
• 8 - થોડી સુરક્ષા, જે મિડલ લેવલ સિસ્ટમ એડમિનિસ્ટ્રેટર માટે ફરજિયાત છે
• 9-11 - મિડલ સિસ્ટમ એડમિનિસ્ટ્રેટર
• 12 — સોંપેલ કાર્યો પર આધાર રાખીને, ક્યાં તો મિડલ સિસ્ટમ એડમિનિસ્ટ્રેટર અથવા બિલ્ડ એન્જિનિયર
• 13 - વર્ચ્યુઅલાઈઝેશન - મિડલ સિસ્ટમ એડમિનિસ્ટ્રેટર, અથવા કહેવાતા CloudOps, ચોક્કસ હોસ્ટિંગ સાઇટની સેવાઓનું અદ્યતન જ્ઞાન, ભંડોળના કાર્યક્ષમ ઉપયોગ માટે અને જાળવણી પરના ભારને ઘટાડવા માટે

આ ખાલી જગ્યાનો સારાંશ આપતાં, અમે કહી શકીએ કે મિડલ/વરિષ્ઠ સિસ્ટમ એડમિનિસ્ટ્રેટર છોકરાઓ માટે પૂરતા છે.

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

ચાલો બીજી ખાલી જગ્યા ધ્યાનમાં લઈએ:

1. ઉચ્ચ-લોડ સિસ્ટમો બનાવવાનો અનુભવ;
2. Linux OS, સામાન્ય સિસ્ટમ સોફ્ટવેર અને વેબ સ્ટેક (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK) નું ઉત્તમ જ્ઞાન;
3. વર્ચ્યુઅલાઈઝેશન સિસ્ટમ્સનો અનુભવ (KVM, VMWare, LXC/Docker);
4. સ્ક્રિપ્ટીંગ ભાષાઓમાં નિપુણતા;
5. નેટવર્ક પ્રોટોકોલ નેટવર્ક્સના સંચાલન સિદ્ધાંતોની સમજ;
6. ખામી-સહિષ્ણુ સિસ્ટમોના નિર્માણના સિદ્ધાંતોની સમજ;
7. સ્વતંત્રતા અને પહેલ;

ચાલો જોઈએ:

• 1 - સિનિયર સિસ્ટમ એડમિનિસ્ટ્રેટર
• 2 - આ સ્ટેકમાં મૂકવામાં આવેલા અર્થના આધારે - મધ્ય/વરિષ્ઠ સિસ્ટમ એડમિનિસ્ટ્રેટર
• 3 - કામનો અનુભવ, સહિત, તેનો અર્થ હોઈ શકે છે - "ક્લસ્ટર વધાર્યું ન હતું, પરંતુ વર્ચ્યુઅલ મશીન બનાવ્યું અને તેનું સંચાલન કર્યું, ત્યાં એક ડોકર હોસ્ટ હતો, કન્ટેનરની ઍક્સેસ ઉપલબ્ધ ન હતી" - મધ્ય સિસ્ટમ એડમિનિસ્ટ્રેટર
• 4 - જુનિયર સિસ્ટમ એડમિનિસ્ટ્રેટર - હા, એક એડમિન જે ભાષાને ધ્યાનમાં લીધા વિના, મૂળભૂત ઓટોમેશન સ્ક્રિપ્ટ્સ કેવી રીતે લખવી તે જાણતો નથી, એડમિન નહીં - enikey.
• 5 - મિડલ સિસ્ટમ એડમિનિસ્ટ્રેટર
• 6 - સિનિયર સિસ્ટમ એડમિનિસ્ટ્રેટર

સારાંશ માટે - મધ્યમ/વરિષ્ઠ સિસ્ટમ એડમિનિસ્ટ્રેટર

બીજો કોઈ:

1. વિકાસ અનુભવ;
2. CI/CD પ્રક્રિયાઓ બનાવવા માટે એક અથવા વધુ ઉત્પાદનોનો ઉપયોગ કરવાનો અનુભવ. Gitlab CI એક ફાયદો થશે;
3. કન્ટેનર અને વર્ચ્યુઅલાઈઝેશન સાથે કામ કરવું; જો તમે ડોકરનો ઉપયોગ કરો છો, તો સારું, પરંતુ જો તમે k8s નો ઉપયોગ કરો છો, તો સરસ!
4. ચપળ ટીમમાં કામ કરવાનો અનુભવ;
5. કોઈપણ પ્રોગ્રામિંગ ભાષાનું જ્ઞાન;

જોઈએ:

• 1 - હમ્મ... છોકરાઓનો અર્થ શું છે? =) મોટે ભાગે તેઓ પોતે જાણતા નથી કે તેની પાછળ શું છુપાયેલું છે
• 2 - બિલ્ડ એન્જિનિયર
• 3 - મિડલ સિસ્ટમ એડમિનિસ્ટ્રેટર
• 4 - નરમ કૌશલ્ય, અમે તેને હમણાં માટે ધ્યાનમાં લઈશું નહીં, જો કે ચપળ એ બીજી વસ્તુ છે જે અનુકૂળ રીતે અર્થઘટન કરવામાં આવે છે.
• 5 - ખૂબ વર્બોઝ - તે સ્ક્રિપ્ટીંગ ભાષા અથવા સંકલિત ભાષા હોઈ શકે છે. મને આશ્ચર્ય થાય છે કે શું શાળામાં પાસ્કલ અને બેઝિકમાં લખવું તેમને અનુકૂળ પડશે? =)

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

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

ચાલો ફરી એકવાર સારાંશ આપીએ - મધ્ય/વરિષ્ઠ સિસ્ટમ એડમિનિસ્ટ્રેટર તેમના માટે પૂરતા હશે.

ગ્રામમાં કેટલું વજન કરવું

સૂચિત ખાલી જગ્યાઓ માટે સૂચિત પગારની શ્રેણી 90k-200k છે
હવે હું સિસ્ટમ એડમિનિસ્ટ્રેટર્સ અને DevOps એન્જિનિયર્સના નાણાકીય પુરસ્કારો વચ્ચે સમાંતર દોરવા માંગુ છું.

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

એક અનુભવ:

1. 3 વર્ષ સુધી - જુનિયર
2. 6 વર્ષ સુધી - મધ્યમ
3. 6 થી વધુ - વરિષ્ઠ

કર્મચારી શોધ સાઇટ ઓફર કરે છે:
સિસ્ટમ સંચાલકો:

1. જુનિયર - 2 વર્ષ - 50k ઘસવું.
2. મધ્યમ - 5 વર્ષ - 70k ઘસવું.
3. વરિષ્ઠ - 11 વર્ષ - 100k ઘસવું.

DevOps એન્જિનિયર્સ:

1. જુનિયર - 2 વર્ષ - 100k ઘસવું.
2. મધ્યમ - 3 વર્ષ - 160k ઘસવું.
3. વરિષ્ઠ - 6 વર્ષ - 220k ઘસવું.

"DevOps" ના અનુભવ મુજબ, અનુભવનો ઉપયોગ કરવામાં આવ્યો હતો કે ઓછામાં ઓછા કોઈક રીતે SDLC ને અસર કરે છે.

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

DevOps એન્જિનિયરોને તાલીમ આપવાની પ્રક્રિયા પણ માત્ર ચોક્કસ કાર્યો, ઉપયોગિતાઓના સમૂહ સુધી મર્યાદિત છે અને તે પ્રક્રિયાઓ અને તેમની નિર્ભરતાની સામાન્ય સમજ આપતી નથી. તે ચોક્કસપણે સારું છે જ્યારે કોઈ વ્યક્તિ ટેરાફોર્મનો ઉપયોગ કરીને AWS EKS નો ઉપયોગ કરી શકે છે, આ ક્લસ્ટરમાં Fluentd sidecar અને AWS ELK સ્ટેક સાથે 10 મિનિટમાં લોગિંગ સિસ્ટમ માટે, કન્સોલમાં માત્ર એક આદેશનો ઉપયોગ કરીને, પરંતુ જો તે સમજી શકતો નથી લૉગ્સ પર પ્રક્રિયા કરવાનો સિદ્ધાંત અને તે શું જરૂરી છે, જો તમે તેના પર મેટ્રિક્સ કેવી રીતે એકત્રિત કરવા અને સેવાના અધોગતિને ટ્રૅક કરવા તે જાણતા નથી, તો તે હજી પણ તે જ એન્કી હશે જે કેટલીક ઉપયોગિતાઓનો ઉપયોગ કેવી રીતે કરવો તે જાણે છે.

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

તો તેઓ કોણ છે? DevOps કે લોભી સિસ્ટમ સંચાલકો? =)

કેવી રીતે જીવવાનું ચાલુ રાખવું?

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

કામદારો - જાણો. તમારા જ્ઞાનમાં સતત સુધારો કરો, પ્રક્રિયાઓના એકંદર ચિત્રને જુઓ અને તમારા ધ્યેયના માર્ગને ટ્રૅક કરો. તમે જે ઈચ્છો તે બની શકો છો, તમારે માત્ર પ્રયાસ કરવો પડશે.

સોર્સ: www.habr.com