DevOps શું છે

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

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

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

અન્ય વસ્તુઓની સાથે, હું DevOps Moscow સમુદાયના આયોજકોમાંનો એક અને DevOps-Days 2017નો આયોજક છું, પરંતુ મેં 2018નું આયોજન કર્યું નથી. એક્સપ્રેસ 42 ઘણી કંપનીઓ સાથે કામ કરે છે. અમે ત્યાં DevOps વિકસાવીએ છીએ, તે કેવી રીતે થાય છે તે જુઓ, તારણો દોરીએ છીએ, વિશ્લેષણ કરીએ છીએ, દરેકને અમારા તારણો કહીએ છીએ અને લોકોને DevOps પ્રેક્ટિસમાં તાલીમ આપીએ છીએ. સામાન્ય રીતે, અમે આ બાબતે અમારા અનુભવ અને કુશળતા વધારવા માટે અમારા શ્રેષ્ઠ પ્રયાસો કરી રહ્યા છીએ.

શા માટે DevOps

પ્રથમ પ્રશ્ન જે દરેકને ત્રાસ આપે છે અને હંમેશા છે - શા માટે? ઘણા લોકો માને છે કે DevOps માત્ર ઓટોમેશન છે અથવા સમાન વસ્તુ છે જે દરેક કંપની પાસે પહેલાથી જ હતી.

— અમારી પાસે સતત એકીકરણ હતું - આનો અર્થ એ કે અમારી પાસે પહેલેથી જ DevOps છે, અને આ બધી સામગ્રી શા માટે જરૂરી છે? તેઓ વિદેશમાં મજા કરી રહ્યાં છે, પરંતુ તેઓ અમને કામ કરતા અટકાવી રહ્યાં છે!

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

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

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

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

જ્યારે કોઈ કંપની બજારમાંથી પસાર થાય છે, ક્લાયન્ટ સાથે કામ કરે છે, ત્યારે તે સતત બજારની શોધ કરે છે અને અંતિમ બિંદુ B ને બદલે છે. વધુમાં, કંપની જેટલી વાર તેની દિશા બદલે છે, તેટલી વધુ સફળ થાય છે, કારણ કે તે વધુ બજાર પસંદ કરે છે. વિશિષ્ટ

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

આ પ્રોડક્ટ યુનિલિવર દ્વારા $1 બિલિયનમાં ખરીદવામાં આવી હતી. તે હવે જીલેટ સાથે સ્પર્ધા કરે છે અને અમેરિકન બજારમાં ગ્રાહકોનો નોંધપાત્ર હિસ્સો છીનવી લીધો છે. એક બોક્સ શેવ કહે છે:

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

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

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

ટાઈમ-ટુ-માર્કેટ એ વિચારથી અંતિમ અમલીકરણ સુધીના સમયને ઘટાડવાનો છે.

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

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

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

1968 માં, એક સ્વપ્નદ્રષ્ટા વ્યક્તિ, મેલવિન કોનવે, નીચેનો વિચાર ઘડ્યો.

સંસ્થા કે જે સિસ્ટમ બનાવે છે તે ડિઝાઇન દ્વારા મર્યાદિત છે જે તે સંસ્થાના સંચાર માળખાની નકલ કરે છે.

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

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

પ્રક્રિયાના દૃષ્ટિકોણથી, DevOps પહેલાં, તમામ તબક્કાઓ: વિશ્લેષણ, વિકાસ, પરીક્ષણ, કામગીરી, રેખીય હતા.
DevOps ના કિસ્સામાં, આ બધી પ્રક્રિયાઓ એકસાથે થાય છે.

ટાઈમ-ટુ-માર્કેટ એ એકમાત્ર રસ્તો છે જે કરી શકાય છે. જૂની પ્રક્રિયામાં કામ કરતા લોકો માટે, આ કંઈક અંશે કોસ્મિક અને સામાન્ય રીતે એવું લાગે છે.

તો શા માટે તમારે DevOpsની જરૂર છે?

ડિજિટલ ઉત્પાદન વિકાસ માટે. જો તમારી કંપની પાસે ડિજિટલ પ્રોડક્ટ નથી, તો DevOpsની જરૂર નથી - તે ખૂબ જ મહત્વપૂર્ણ છે.

DevOps ક્રમિક સોફ્ટવેર ઉત્પાદનની ગતિ મર્યાદાઓને દૂર કરે છે. તેમાં બધી પ્રક્રિયાઓ એક સાથે થાય છે.

મુશ્કેલી વધે છે. જ્યારે DevOps પ્રચારકો તમને કહે છે કે તે તમારા માટે સૉફ્ટવેર રિલીઝ કરવાનું સરળ બનાવશે, ત્યારે આ બકવાસ છે.

DevOps સાથે, વસ્તુઓ ફક્ત વધુ જટિલ બનશે.

એવિટો સ્ટેન્ડ પરની કોન્ફરન્સમાં, તમે જોઈ શકો છો કે ડોકર કન્ટેનર જમાવવું તે કેવું હતું - એક અવાસ્તવિક કાર્ય. જટિલતા નિષેધાત્મક બની જાય છે; તમારે એક જ સમયે ઘણા બોલમાં જગલ કરવું પડશે.

DevOps કંપનીમાં પ્રક્રિયા અને સંસ્થાને સંપૂર્ણપણે બદલી નાખે છે — વધુ સ્પષ્ટ રીતે, તે બદલાય છે તે DevOps નથી, પરંતુ ડિજિટલ ઉત્પાદન છે. DevOps પર આવવા માટે, તમારે હજુ પણ આ પ્રક્રિયાને સંપૂર્ણપણે બદલવાની જરૂર છે.

નિષ્ણાત માટે પ્રશ્નો

તમારી પાસે શું છે? કંપનીમાં કામ કરતી વખતે અને નિષ્ણાત તરીકે વિકાસ કરતી વખતે તમે તમારી જાતને પૂછી શકો તેવા પ્રશ્નો.

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

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

શું તમારી કંપની ડિજિટલ પ્રોડક્ટના માળખામાં માર્કેટ લીડર્સમાંની એક છે? Spotify, Yandex, Uber એ એવી કંપનીઓ છે જે હવે તકનીકી પ્રગતિની ટોચ પર છે.

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

સંસ્થા

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

"કુવાઓ" ની સમસ્યા

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

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

DevOps દિશાહિનતાની આ ક્ષણમાંથી પસાર થવાનું સૂચન કરે છે અને એક સામાન્ય ક્રિયાપ્રતિક્રિયા નકશો બનાવવા માટે બધા વિભાગો સાથે મળીને કામ કરે છે.

આમાં બે પરિબળો અવરોધે છે.

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

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

- અમે ફક્ત CI શરૂ કરવા માગતા હતા, પરંતુ તે બહાર આવ્યું કે મેનેજમેન્ટને તેની જરૂર નથી.

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

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

લોકો કોઈને કોઈ તારા કે ધ્વજ માટે લડી રહ્યા છે, દરેક વ્યક્તિ પોતાની કુશળતા ખોદી રહ્યા છે.

પરિણામે, જ્યારે આ બધાને એકસાથે જોડવાનું અને એક સામાન્ય પાઈપલાઈન બનાવવાનું કાર્ય ઉદ્ભવે છે, અને હવે તારા અને ધ્વજ માટે લડવાની કોઈ જરૂર નથી, ત્યારે પ્રશ્ન ઊભો થાય છે - તેમ છતાં શું કરવું? અમારે કોઈક રીતે કરાર પર આવવાની જરૂર છે, પરંતુ કોઈએ અમને શાળામાં આ કેવી રીતે કરવું તે શીખવ્યું નથી. અમને શાળાથી શીખવવામાં આવે છે: આઠમા ધોરણ - વાહ! - સાતમા ધોરણની સરખામણીમાં! અહીં પણ એવું જ છે.

શું તે તમારી કંપનીમાં સમાન છે?

આ તપાસવા માટે, તમે તમારી જાતને નીચેના પ્રશ્નો પૂછી શકો છો.

શું ટીમો સામાન્ય સાધનોનો ઉપયોગ કરે છે અને તે સામાન્ય ટૂલ્સના ફેરફારોમાં યોગદાન આપે છે?

ટીમો કેટલી વાર પુનઃસંગઠિત કરે છે - એક ટીમમાંથી કેટલાક નિષ્ણાતો બીજી ટીમમાં જાય છે? તે DevOps વાતાવરણમાં છે કે આ સામાન્ય બની જાય છે, કારણ કે કેટલીકવાર વ્યક્તિ ફક્ત સમજી શકતી નથી કે નિપુણતાનું બીજું ક્ષેત્ર શું કરી રહ્યું છે. તે બીજા વિભાગમાં જાય છે, ત્યાં બે અઠવાડિયા સુધી કામ કરે છે અને આ વિભાગ સાથેના અભિગમ અને ક્રિયાપ્રતિક્રિયાનો નકશો પોતાના માટે બનાવે છે.

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

મેનેજરો માટે કંપનીની સિદ્ધિઓને ધ્યાનમાં લીધા વિના વ્યક્તિગત સિદ્ધિઓ પ્રાપ્ત કરવી કેટલું મહત્વપૂર્ણ છે?

જો તમે તમારા માટે આ પ્રશ્નોના જવાબ આપો, તો તે સ્પષ્ટ થઈ જશે કે શું તમને તમારી કંપનીમાં આવી સમસ્યા છે.

કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચર

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

મોટેભાગે, કોડ તરીકે ઇન્ફ્રાસ્ટ્રક્ચર નીચે મુજબ માનવામાં આવે છે:

- ચાલો બેશમાં દરેક વસ્તુને સ્વચાલિત કરીએ, સ્ક્રિપ્ટોથી પોતાને આવરી લઈએ જેથી સંચાલકો પાસે ઓછું મેન્યુઅલ કામ હોય!

પરંતુ તે સાચું નથી.

કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચરનો અર્થ એ છે કે તમે જે IT સિસ્ટમ સાથે કામ કરો છો તેનું વર્ણન સતત તેની સ્થિતિને સમજવા માટે કોડના સ્વરૂપમાં કરો.

અન્ય ટીમો સાથે મળીને, તમે કોડના રૂપમાં એક નકશો બનાવો છો જેને દરેક વ્યક્તિ સમજી શકે અને નેવિગેટ કરી શકે. તે શું કરે છે તેનાથી કોઈ ફરક પડતો નથી - રસોઇયા, જવાબી, મીઠું અથવા કુબરનેટ્સમાં YAML ફાઇલોનો ઉપયોગ - તેમાં કોઈ તફાવત નથી.

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

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

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

કોડ શ્રેષ્ઠ કોડ પ્રથાઓ અનુસાર જાળવવામાં આવે છે: સંયુક્ત વિકાસ, કોડ સમીક્ષા, XP-પ્રોગ્રામિંગ, પરીક્ષણ, પુલ વિનંતીઓ, કોડ ઇન્ફ્રાસ્ટ્રક્ચર માટે CI - આ બધું યોગ્ય છે અને તેનો ઉપયોગ કરી શકાય છે.

કોડ બધા એન્જિનિયરો માટે સામાન્ય ભાષા બની જાય છે.

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

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

કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચર એ ઈન્ફ્રાસ્ટ્રક્ચર કોડને અલગ સ્તરોમાં અલગ કરવાનું છે.

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


આધાર સ્તર - આ રીતે OS, બેકઅપ્સ અને અન્ય નિમ્ન-સ્તરની વસ્તુઓ ગોઠવવામાં આવે છે, ઉદાહરણ તરીકે, કુબરનેટ્સ મૂળભૂત સ્તરે કેવી રીતે જમાવવામાં આવે છે.

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

સ્તર જ્યાં એપ્લિકેશન બનાવવામાં આવે છે અને અગાઉના બે સ્તરોની ટોચ પર તેઓ કેવી રીતે પ્રગટ થશે તેનું વર્ણન કરે છે.

પ્રશ્નો પર નિયંત્રણ રાખો

શું તમારી કંપની પાસે સામાન્ય ઈન્ફ્રાસ્ટ્રક્ચર રિપોઝીટરી છે? શું તમે તમારા ઈન્ફ્રાસ્ટ્રક્ચરમાં ટેક્નિકલ ડેટનું સંચાલન કરી રહ્યા છો? શું તમે ઈન્ફ્રાસ્ટ્રક્ચર રિપોઝીટરીમાં વિકાસ પ્રથાઓનો ઉપયોગ કરો છો? શું તમારું ઈન્ફ્રાસ્ટ્રક્ચર સ્તરોમાં કાપવામાં આવ્યું છે? તમે Base-service-APP ડાયાગ્રામ ચકાસી શકો છો. પરિવર્તન કરવું કેટલું મુશ્કેલ છે?

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

સતત ડિલિવરી

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

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

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

સતત અર્થ પહોંચાડે છે

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

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

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

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

વિવિધ જમાવટ વ્યૂહરચના. ઉદાહરણ તરીકે, તમે અલગ-અલગ ક્લાયન્ટ્સ પર કોડને અલગ રીતે ચકાસવા માટે, કોડ કેવી રીતે કામ કરે છે અને 100 મિલિયન વપરાશકર્તાઓ માટે તેને રોલઆઉટ કરવામાં આવે છે તેના કરતાં ઘણી વહેલી તકે માહિતી મેળવવા માટે તમે AB પરીક્ષણ અથવા કેનેરી ડિપ્લોયમેન્ટનો ઉપયોગ કરો છો.

"સતત વિતરિત કરો" આના જેવો દેખાય છે.

ડિલિવરી પ્રક્રિયા Dev, CI, Test, PreProd, Prod એ અલગ વાતાવરણ નથી, આ ફાયરપ્રૂફ રકમવાળા સ્ટેજ અથવા સ્ટેશનો છે કે જેનામાંથી તમારી આર્ટિફેક્ટ પસાર થાય છે.

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

સ્વ-પરીક્ષણ પ્રશ્નો

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

જો બધા જવાબો હા છે, તો તમે અતિ સરસ છો! ટિપ્પણીઓમાં તમારા જવાબો લખો - મને આનંદ થશે).

પ્રતિસાદ

આ બધામાં સૌથી મુશ્કેલ પ્રથા છે. DevOpsConf કોન્ફરન્સમાં, Infobip ના એક સાથીદાર, તેના વિશે વાત કરતા, તેમના શબ્દોમાં થોડો મૂંઝવણમાં હતો, કારણ કે આ ખરેખર એક ખૂબ જ જટિલ પ્રથા છે કે તમારે દરેક વસ્તુનું નિરીક્ષણ કરવાની જરૂર છે!

ઉદાહરણ તરીકે, લાંબા સમય પહેલા, જ્યારે મેં Qik પર કામ કર્યું હતું અને અમને સમજાયું કે અમારે દરેક વસ્તુનું નિરીક્ષણ કરવાની જરૂર છે. અમે આ કર્યું, અને હવે અમારી પાસે Zabbix માં 150 વસ્તુઓ છે, જેનું સતત નિરીક્ષણ કરવામાં આવે છે. તે ડરામણું હતું, તકનીકી નિર્દેશકે તેના મંદિર પર તેની આંગળી ટ્વિસ્ટ કરી:

- ગાય્સ, તમે અસ્પષ્ટ કંઈક સાથે સર્વર પર બળાત્કાર કેમ કરો છો?

પરંતુ પછી એક ઘટના બની જેણે બતાવ્યું કે આ ખરેખર ખૂબ જ શાનદાર વ્યૂહરચના છે.

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

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

- મિત્રો, દોઢ અઠવાડિયા પહેલા તમને શું થયું હતું?

જવાબમાં, અમે એક રસપ્રદ વાર્તા સાંભળી કે કેવી રીતે તેઓએ UI ને ફરીથી ડિઝાઇન કર્યું. તે અસંભવિત છે કે કોઈ તરત જ કહેશે કે તેઓએ HTTP લાઇબ્રેરી બદલી છે. એન્ડ્રોઇડ ક્લાયંટ માટે, તે બાથરૂમમાં સાબુ બદલવા જેવું છે - તેઓને યાદ નથી. પરિણામે, 40 મિનિટની વાતચીત પછી, અમને જાણવા મળ્યું કે તેઓએ HTTP લાઇબ્રેરી બદલી છે, અને તેના ડિફૉલ્ટ સમય બદલાઈ ગયા છે. આના કારણે API સર્વર પર ટ્રાફિકની વર્તણૂક બદલાઈ ગઈ, જેના કારણે બ્રોકરની અંદર રેસ ઊભી થઈ અને તે ક્રેશ થવા લાગી.

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

ડિલિવરી પ્રક્રિયાના દરેક તબક્કે આર્ટિફેક્ટનું શું થાય છે તે વિશેની તમામ માહિતી એકત્રિત કરો - ઉત્પાદનમાં નહીં.

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

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

સ્વ-નિયંત્રણ માટે પ્રશ્નો

શું તમારું મોનિટરિંગ અને લૉગિંગ તમારા માટે વિકાસ સાધન છે? કોડ લખતી વખતે, શું તમારા સહિત તમારા વિકાસકર્તાઓ તેનું નિરીક્ષણ કેવી રીતે કરવું તે વિશે વિચારે છે?

શું તમે ગ્રાહકોની સમસ્યાઓ વિશે સાંભળો છો? શું તમે ક્લાયંટને મોનિટરિંગ અને લોગિંગથી વધુ સારી રીતે સમજો છો? શું તમે મોનિટરિંગ અને લોગીંગથી સિસ્ટમને વધુ સારી રીતે સમજો છો? શું તમે સિસ્ટમ બદલો છો કારણ કે તમે જોયું છે કે સિસ્ટમમાં વલણ વધી રહ્યું છે અને તમે સમજો છો કે બીજા 3 અઠવાડિયામાં બધું મરી જશે?

એકવાર તમારી પાસે આ ત્રણ ઘટકો થઈ ગયા પછી, તમે તમારી કંપનીમાં કયા પ્રકારનું ઇન્ફ્રાસ્ટ્રક્ચર પ્લેટફોર્મ ધરાવો છો તે વિશે વિચારી શકો છો.

ઈન્ફ્રાસ્ટ્રક્ચર પ્લેટફોર્મ

મુદ્દો એ નથી કે તે અલગ-અલગ સાધનોનો સમૂહ છે જે દરેક કંપની પાસે છે.

ઈન્ફ્રાસ્ટ્રક્ચર પ્લેટફોર્મનો મુદ્દો એ છે કે બધી ટીમો આ સાધનોનો ઉપયોગ કરે છે અને તેમને એકસાથે વિકસાવે છે.

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

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

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

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

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

આ યોજના

આ ઈન્ફ્રાસ્ટ્રક્ચર પ્લેટફોર્મનો મૂળભૂત ડાયાગ્રામ છે જે તમને DevOps કંપનીમાં તમામ પ્રેક્ટિસ અને પ્રક્રિયાઓ સેટ કરવામાં મદદ કરશે.

ચાલો જોઈએ કે તે શું સમાવે છે.

સંસાધન ઓર્કેસ્ટ્રેશન સિસ્ટમ, જે એપ્લિકેશન અને અન્ય સેવાઓને CPU, મેમરી, ડિસ્ક પ્રદાન કરે છે. આના ઉપર - નિમ્ન સ્તરની સેવાઓ: મોનીટરીંગ, લોગીંગ, સીઆઈ/સીડી એન્જીન, આર્ટીફેક્ટ સ્ટોરેજ, સિસ્ટમ કોડ તરીકે ઈન્ફ્રાસ્ટ્રકચર.

ઉચ્ચ સ્તરની સેવાઓ: સેવા તરીકે ડેટાબેઝ, સેવા તરીકે કતાર, સેવા તરીકે લોડ બેલેન્સ, સેવા તરીકે ઇમેજનું કદ બદલવાનું, સેવા તરીકે બિગ ડેટા ફેક્ટરી. આના ઉપર - પાઇપલાઇન જે તમારા ક્લાયંટને સતત સંશોધિત કોડ પહોંચાડે છે.

તમારું સૉફ્ટવેર ક્લાયંટ માટે કેવી રીતે કાર્ય કરે છે તે વિશે તમને માહિતી પ્રાપ્ત થાય છે, તેને બદલો, ફરીથી આ કોડ સપ્લાય કરો, માહિતી પ્રાપ્ત કરો - અને તેથી તમે સતત ઇન્ફ્રાસ્ટ્રક્ચર પ્લેટફોર્મ અને તમારા સોફ્ટવેર બંનેનો વિકાસ કરો છો.

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

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

પ્લેટફોર્મની રચના

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

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

તમારી પાસે શું છે?

ફરીથી, પ્રશ્નો તમે તમારી જાતને પૂછી શકો છો.

શું ઈન્ફ્રાસ્ટ્રક્ચર પ્લેટફોર્મ સમર્પિત છે? તેના વિકાસ માટે કોણ જવાબદાર છે? શું તમે તમારા ઈન્ફ્રાસ્ટ્રક્ચર પ્લેટફોર્મના સ્પર્ધાત્મક ફાયદાઓને સમજો છો?

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

તેથી, DevOps...

... આ એક જટિલ સિસ્ટમ છે, તેમાં આ હોવું જોઈએ:

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

તમે આ રેખાકૃતિનો ઉપયોગ કરી શકો છો, તેમાં હાઇલાઇટ કરીને તમારી કંપનીમાં તમારી પાસે પહેલેથી જ શું છે તે અમુક સ્વરૂપમાં છે: શું તે વિકસિત થયું છે અથવા હજુ પણ વિકસાવવાની જરૂર છે.

તે થોડા અઠવાડિયામાં સમાપ્ત થઈ જશે DevOpsConf 2019. RIT++ ના ભાગ રૂપે. કોન્ફરન્સમાં આવો, જ્યાં તમને સતત ડિલિવરી, કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચર અને DevOps ટ્રાન્સફોર્મેશન વિશે ઘણા શાનદાર રિપોર્ટ્સ મળશે. તમારી ટિકિટ બુક કરો, છેલ્લી કિંમતની અંતિમ તારીખ 20 મે છે

સોર્સ: www.habr.com