DevOpsForum 2019. તમે DevOps લાગુ કરવા માટે રાહ જોઈ શકતા નથી

મેં તાજેતરમાં લોગ્રોકોન દ્વારા હોસ્ટ કરેલ DevOpsForum 2019 માં હાજરી આપી હતી. આ કોન્ફરન્સમાં, સહભાગીઓએ વ્યવસાય અને વિકાસ અને માહિતી ટેકનોલોજી સેવા નિષ્ણાતો વચ્ચે અસરકારક ક્રિયાપ્રતિક્રિયા માટે ઉકેલો અને નવા સાધનો શોધવાનો પ્રયાસ કર્યો.

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

Raiffeisenbank, Alfastrakhovanie, Mango Telecomના ઓટોમેશનના અમલીકરણના અનુભવ અને કટ હેઠળની અન્ય વિગતોના ભાષણોનો અંશો.

મારું નામ યાના છે, હું ટેસ્ટર તરીકે કામ કરું છું, હું ઓટોમેશન તેમજ DevOps કરું છું અને મને કોન્ફરન્સ અને મીટઅપ્સમાં જવાનું ગમે છે. છેલ્લા બે વર્ષોમાં, હું ઓલેગ બુનીનની કોન્ફરન્સ (હાઈલોડ++, ટીમલીડ કોન્ફ), જગ ઈવેન્ટ્સ (હેઈઝનબગ, જેપોઈન્ટ), ટેસ્ટકોન મોસ્કો, ડેવઓપ્સ પ્રો મોસ્કો, બિગ ડેટા મોસ્કોમાં ગયો છું.

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

Raiffeisenbank ખાતે પાઇપલાઇનના છેડે પ્રકાશ

સામાન્ય રીતે, હું સાઈડલાઈન પર સ્પીકર્સનો શિકાર કરું છું જે મને રુચિ ધરાવે છે. DevOpsForum 2019 પર, Raiffeisenbank ના વક્તા, Mikhail Bizhan, એ મારી રુચિ જગાવી. તેમના ભાષણ દરમિયાન, તેમણે કેવી રીતે તેમની ટીમો ધીમે ધીમે DevOps પર જોડાઈ રહી છે, તેમને તેની શા માટે જરૂર છે, અને DevOps પરિવર્તનના વિચારને વ્યવસાયમાં કેવી રીતે વેચવો તે વિશે વાત કરી. ઠીક છે, સામાન્ય રીતે, મેં પાઇપલાઇનના અંતમાં પ્રકાશ કેવી રીતે જોવો તે વિશે વાત કરી.

મિખાઇલ બિઝાન, રાયફિસેનબેંકમાં ઓટોમેશન ડિરેક્ટર

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

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

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

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

મેંગો ટેલિકોમ ખાતે પરીક્ષણનું ઓટોમેશન

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

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

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

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

પ્રસ્તુતિઓ વચ્ચે, હું કોન્ફરન્સ ભાગીદારોના બૂથની આસપાસ ફર્યો અને ઘણી બધી સામગ્રી ચોરી/જીત્યો. ઓહ, મને હેન્ડઆઉટ ગમે છે!

Alfastrakhovanie ખાતે વિકાસ નિર્દેશક સાથે રાઉન્ડ ટેબલ અને DevOps મુદ્દાઓ

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

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

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

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

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

સોર્સ: www.habr.com