ત્યાં કોઈ DevOps એન્જિનિયરો નથી. પછી કોણ અસ્તિત્વ ધરાવે છે, અને તેની સાથે શું કરવું?

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

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

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

સંસ્કૃતિ અને પ્રક્રિયાઓ વિશે

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

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

"જ્યારે સાથીઓ વચ્ચે કોઈ કરાર નથી,
તેમના માટે વસ્તુઓ સારી રહેશે નહીં,
અને તેમાંથી કંઈ બહાર આવશે નહીં, ફક્ત યાતના.
એક સમયે એક હંસ, એક ક્રેફિશ અને પાઈક..."

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

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

દુષ્ટ વર્તુળ

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

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

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

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

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

અલબત્ત, સિસ્ટમ એડમિનિસ્ટ્રેટર્સ કે જેમણે પોતાનું નામ બદલીને “devops” રાખ્યું છે તે ઉપરાંત અન્ય સહભાગીઓ છે - ઉદાહરણ તરીકે, વ્યાવસાયિક SREs અથવા ઈન્ફ્રાસ્ટ્રક્ચર-એઝ-કોડ ડેવલપર્સ.

DevOps માં લોકો શું કરે છે (ખરેખર)

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

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

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

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

અલબત્ત, સમસ્યાનો એક તકનીકી ભાગ પણ છે. જો તમારો નવો કોડ એક મહિનામાં પરીક્ષણ કરવામાં આવે છે, પરંતુ તે ફક્ત એક વર્ષ પછી જ બહાર પાડવામાં આવે છે, અને તે બધાને ઝડપી બનાવવું શારીરિક રીતે અશક્ય છે, તો તમે સારી પ્રથાઓ પ્રમાણે જીવી શકશો નહીં. સારી પ્રથાઓ સારા સાધનો દ્વારા સમર્થિત છે. ઉદાહરણ તરીકે, ઈન્ફ્રાસ્ટ્રક્ચર-એઝ-કોડના વિચારને ધ્યાનમાં રાખીને, તમે AWS CloudFormation અને Terraform થી લઈને Chef-Ansible-Puppet સુધી કોઈપણ વસ્તુનો ઉપયોગ કરી શકો છો. તમારે આ બધું જાણવાની અને સક્ષમ બનવાની જરૂર છે, અને આ પહેલેથી જ એક એન્જિનિયરિંગ શિસ્ત છે. કારણને અસર સાથે મૂંઝવવું નહીં તે મહત્વનું છે: પ્રથમ તમે SRE ના સિદ્ધાંતો અનુસાર કાર્ય કરો અને પછી જ કેટલાક વિશિષ્ટ તકનીકી ઉકેલોના સ્વરૂપમાં આ સિદ્ધાંતોનો અમલ કરો. તે જ સમયે, SRE એ ખૂબ જ વ્યાપક પદ્ધતિ છે જે તમને જેનકિન્સ કેવી રીતે સેટ કરવી તે જણાવતી નથી, પરંતુ લગભગ પાંચ મૂળભૂત સિદ્ધાંતો છે:

• ભૂમિકાઓ અને વિભાગો વચ્ચે સુધારેલ સંચાર
• કામના અભિન્ન અંગ તરીકે ભૂલોને સ્વીકારવી
• ધીમે ધીમે ફેરફારો કરવા
• ટૂલિંગ અને અન્ય ઓટોમેશનનો ઉપયોગ
• માપી શકાય તે બધું માપવું

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

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

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

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

આ બધાનું શું કરવું

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

અમે કોન્ફરન્સ કરી રહ્યા છીએ DevOops 2020 મોસ્કો, જે અમે હમણાં જ વાત કરી છે તે બાબતોમાં વધુ ઊંડાણપૂર્વક વિચાર કરવાની તક પૂરી પાડે છે. આ માટે અહેવાલોના ઘણા જૂથો છે:

• પ્રક્રિયાઓ અને સંસ્કૃતિ;
• સાઇટ વિશ્વસનીયતા એન્જિનિયરિંગ;
• મેઘ મૂળ;

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

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

જો તમે DevOps એન્જિનિયર હોવ તો શું કરવું તે સમજવાનું બાકી છે! પ્રથમ, તમે ખરેખર શું કરો છો તે નક્કી કરવાનો પ્રયાસ કરો. સામાન્ય રીતે તેઓ આ શબ્દને બોલાવવાનું પસંદ કરે છે:

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

બીજો વિકલ્પ છે: તમે ચાલુ રાખો અને દાવો કરવાનું ચાલુ રાખો કે તમે છો ખાસ કરીને DevOps એન્જિનિયર અને બીજું કંઈ નહીં, તેનો અર્થ ગમે તે હોય. તો પછી અમારે તમને નિરાશ કરવા પડશે, DevOops એ DevOps એન્જિનિયરો માટે કોન્ફરન્સ નથી!

થી સ્લાઇડ કરો કોન્સ્ટેન્ટિન ડીનર દ્વારા અહેવાલ મ્યુનિકમાં

DevOops 2020 મોસ્કોમાં 29-30 એપ્રિલના રોજ યોજાશે, ટિકિટ પહેલેથી જ ઉપલબ્ધ છે સત્તાવાર વેબસાઇટ પર ખરીદી.

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

સોર્સ: www.habr.com